From nobody Fri Apr 1 02:02:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B468312D0EA; Fri, 1 Apr 2016 02:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nus2YxZ4ILrW; Fri, 1 Apr 2016 02:02:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80D912D0BB; Fri, 1 Apr 2016 02:02: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 8A90E764; Fri, 1 Apr 2016 11:02: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 Ef8dE2PSE8pk; Fri, 1 Apr 2016 11:01: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; Fri, 1 Apr 2016 11:02:11 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8608120050; Fri, 1 Apr 2016 11:02:11 +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 nYYlau6nEVKJ; Fri, 1 Apr 2016 11:02:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44AEF20046; Fri, 1 Apr 2016 11:02:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A8093A6F1CB; Fri, 1 Apr 2016 11:02:07 +0200 (CEST) Date: Fri, 1 Apr 2016 11:02:07 +0200 From: Juergen Schoenwaelder To: "Rajiv Asati (rajiva)" Message-ID: <20160401090207.GA50653@elstar.local> Mail-Followup-To: "Rajiv Asati (rajiva)" , "netmod@ietf.org" , "mpls@ietf.org" References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.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: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 09:02:17 -0000 Operational state often has a different lifetime than config. Hence, keeping config and operational state together in the same structure (with the same naming) causes you problems down the road. /js On Thu, Mar 31, 2016 at 06:44:06PM +0000, Rajiv Asati (rajiva) wrote: > > While working on MPLS LDP yang model (https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang), we noticed the possible confusion around structuring intended config, applied config and derived state *. > > On one hand, one may have 'intended-config’ (RW) and ‘applied-config’ (RO) in the same construct (container), and ‘derived state’ (RO) in a separate construct (container). > > This keeps config together, but doesn’t help operational state, which requires > Both Applied-config and derived-state. > > On the other hand hand, one may have ‘intended-config’ in one construct (container), and ‘applied-config’ and ‘derived state’ in a separate construct (container). > > This simplifies figuring operational-state, but divides the config types. > > There are pros & cons either way. It would be good to have some guidance/text around guiding one over another, so that other models can leverage. Otherwise, we are going to end up with yet one more discrepancy (among various protocols YANG models), & confusing if not inefficient modeling. > > Perhaps, we ditch both of the above approaches, and settle on keeping all three of them in the same construct. It might simplify the organization a bit. Of course, that also has 2 options - have all the data types in intended-config, and then in applied-config and then in derived-state. Or have intended-config, applied-config and derived-state for each data type. Latter might be slightly better, given that not every data type will have all three. > > > Thoughts? > > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > > > * https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs > https://tools.ietf.org/html/draft-openconfig-netmod-opstate > > _______________________________________________ > 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 Apr 1 14:54:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0412D71A for ; Fri, 1 Apr 2016 14:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30YdWSnEe0Dj for ; Fri, 1 Apr 2016 14:54:09 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA07212D6F3 for ; Fri, 1 Apr 2016 14:54:08 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 35533E04E3DA0; Fri, 1 Apr 2016 21:54:04 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u31Ls7aR013309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2016 21:54:07 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 u31Ls6jT013719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Apr 2016 21:54:07 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.144]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 1 Apr 2016 17:54:06 -0400 From: "Sterne, Jason (Nokia - CA)" To: EXT Dean Bogdanovic Thread-Topic: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? Thread-Index: AdGK7a6OzNQGHCpiSOaljaNEPY627QAYzYUAAEPae+A= Date: Fri, 1 Apr 2016 21:54:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CC23DC1US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 21:54:11 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CC23DC1US70TWXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVhbiwNCg0KRnJvbSB3aGF0IEFjZWUgbWVudGlvbnMgaXQgZG9lc27igJl0IHNlZW0gdGhh dCBJT1MtWFIgc3VwcG9ydHMgbWF0Y2hpbmcgb24gaW50ZXJmYWNlIGZvciBBQ0xzLg0KDQpXaGVu IEkgbG9vayBhdCBCcm9jYWRlIEkgZG9u4oCZdCBzZWUgaXQgZWl0aGVyLiAgTWF5YmUgc29tZW9u ZSBmcm9tIEJyb2NhZGUgY291bGQgcHJvdmlkZSBhbiBleGFtcGxlIG9mIHRoZSBjb25maWcgaWYg aXQgaXMgc3VwcG9ydGVkID8NCmh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxv Yi9tYXN0ZXIvdmVuZG9yL2Jyb2NhZGUvYnJvY2FkZS1pcC1hY2Nlc3MtbGlzdC55YW5nDQooSSBh bHNvIGNoZWNrZWQgdGhlaXIgdXNlciBndWlkZXMpDQoNCkkgdGhpbmsgaXQgaXMgbW9yZSByZWxl dmFudCB0byBsb29rIGF0IEFDTCBmdW5jdGlvbmFsaXR5IGZvciB0aGlzIChub3QgbG9nIGZpbHRl cmluZyBvciBvdGhlciBtaXNjLiBmaWx0ZXJpbmcgY2FwYWJpbGl0aWVzIGluIGFyZWFzIG91dHNp ZGUgb2YgQUNMcykuICBJIHJlYWxseSBkb27igJl0IHRoaW5rIHRoaXMgaGFzIHdpZGVzcHJlYWQg c3VwcG9ydCBhbmQgaXQgaXNu4oCZdCBjb3JlIGZ1bmN0aW9uYWxpdHkgLT4gYXNzaWduaW5nIGFu IEFDTCB0byBhbiBpbnRlcmZhY2UgaXMgaG93IGl0IGlzIG5vcm1hbGx5IGRvbmUuDQoNClJlZ2Fy ZHMsDQpKYXNvbg0KDQpGcm9tOiBFWFQgRGVhbiBCb2dkYW5vdmljIFttYWlsdG86aXZhbmRlYW5A Z21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMxLCAyMDE2IDI6MjYNClRvOiBTdGVy bmUsIEphc29uIChOb2tpYSAtIENBKQ0KQ2M6IG5ldG1vZCBXRw0KU3ViamVjdDogUmU6IFtuZXRt b2RdIFJlbW92ZSBpbnB1dC1pbnRlcmZhY2UgKG1ldGFkYXRhKSBmcm9tIG5ldG1vZC1hY2wtbW9k ZWwtMDcgPw0KDQoNCk9uIE1hciAzMCwgMjAxNiwgYXQgOTozNiBQTSwgU3Rlcm5lLCBKYXNvbiAo Tm9raWEgLSBDQSkgPGphc29uLnN0ZXJuZUBub2tpYS5jb208bWFpbHRvOmphc29uLnN0ZXJuZUBu b2tpYS5jb20+PiB3cm90ZToNCg0KSGkgYWxsLA0KDQpUaGUgQUNMIG1vZGVsIGlzIGNvbnZlcmdp bmcgb24gYSBzbWFsbCBjb3JlIHNldCBvZiBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgZmFpcmx5IGNv bW1vbi4NCg0KQnV0IEkgdGhpbmsgdGhlIG1hdGNoaW5nIG9uIGlucHV0LWludGVyZmFjZSBzaG91 bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBtb2RlbCAob3IgYXQgdGhlIGxlYXN0IHB1dCBpbnNpZGUg YSBmZWF0dXJlIGZsYWcpLg0KDQpNYXRjaGluZyBvbiBiYXNpYyBJUHY0L0lQdjQvTUFDIGhlYWRl ciBmaWVsZHMgaXMgY29tbW9uIGZ1bmN0aW9uYWxpdHkuICBCdXQgaGF2aW5nIHRoYXQgaW5wdXQt aW50ZXJmYWNlIG1hdGNoIG9uIG1ldGFkYXRhIGluIHRoZSBjb3JlIG1vZGVsIGlzIG91dCBvZiBw bGFjZS4gIEl0IHNob3VsZCBiZSBsZWZ0IHRvIGZ1cnRoZXIgZXh0ZW5zaW9uIGRyYWZ0cyBvciB2 ZW5kb3Igc3BlY2lmaWMgYXVnbWVudGF0aW9ucyAoYWxvbmcgd2l0aCB3aGF0ZXZlciBvdGhlciBt ZXRhZGF0YSBtaWdodCBiZSB1c2VmdWwgb3IgdmVuZG9yLXNwZWNpZmljKS4NCg0KQUNMcyBhcmUg dHlwaWNhbGx5IGFzc2lnbmVkIHRvIGludGVyZmFjZXMgYXMgc2hvd24gaW4gc2VjdGlvbiBBLjMu IG9mIHRoZSBBQ0wgZHJhZnQuICAgVGhhdCBpcyB0aGUgbW9zdCBjb21tb24gdXNlIGNhc2UuDQoN CkFjdHVhbGx5IG1hdGNoaW5nIG9uIGlucHV0LWludGVyZmFjZSBpbiB0aGUgQUNMIHJ1bGVzIHRo ZW1zZWx2ZXMgaXMgbm90IGJhc2ljIGNvcmUgQUNMIGZ1bmN0aW9uYWxpdHkuICBOb2tpYSBTUiBP UyBkb2VzIG5vdCBoYXZlIHRoYXQgY2FwYWJpbGl0eS4gIERvZXMgSU9TLVhSID8gIEJyb2NhZGUg PyAgb3RoZXJzID8NCg0KQ2lzY28gYW5kIEp1bmlwZXIgc3VwcG9ydCBtYXRjaGluZyBvbiBpbnB1 dCBpbnRlcmZhY2UuIEl0IGlzIHVzZWZ1bCB3aGVuIHlvdSB3YW50IHRvIGZpbHRlciBvbiBnZW5l cmFsIHRyYWZmaWMgY29taW5nIGZyb20gaW50ZXJmYWNlLg0KDQpDaXNjbw0KbWF0Y2ggaW5wdXQt aW50ZXJmYWNlDQptYXRjaCBpbnB1dC12bGFuDQoNCg0KSnVub3MNCmZhbWlseSBhbnkgew0KICAg ICAgICAgICAgZmlsdGVyIEwyX2ZpbHRlciB7DQogICAgICAgICAgICAgICAgICAgICAgICB0ZXJt IHQxIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gew0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJmYWNlIGZlLTAv MC8wLjA7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGVuIHsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHBvbGljZXIgcDE7DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb3VudCBjMTsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgIH0NCn0NCg0KQnJvY2FkZSBzdXBwb3J0cyBtYXRjaGluZyBiYXNlZCBvbiBpbnRlcmZhY2Us IERlbGwgc3VwcG9ydHMgVkxBTiBtYXRjaGluZywgQXJpc3RhIHN1cHBvcnRzIGlucHV0IGludGVy ZmFjZSBtYXRjaGluZywgUmVkYmFjayBzdXBwb3J0cyBtYXRjaGluZyBhZ2FpbnN0IGlucHV0IGlu dGVyZmFjZSBmb3IgbG9nZ2luZywgc28gaXQgaXMgcHJldHR5IHN0YW5kYXJkIGFjcm9zcyBtdWx0 aXBsZSB2ZW5kb3JzDQoNCkRlYW4NCg0KICAgICBJZiBzb21lIG1ham9yIGltcGxlbWVudGF0aW9u cyBkb27igJl0IGRvIGl0LCBhbmQgaXQgaXNu4oCZdCBuZWNlc3NhcnkgZm9yIHR5cGljYWwgYmFz aWMgQUNMIHVzZSwgdGhlbiBpdCBzaG91bGQgYmUgcmVtb3ZlZCAob3IgZmVhdHVyZSBmbGFnZ2Vk KS4NCg0KUmVnYXJkcywNCkphc29uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQoNCg== --_000_A125E53CE190A749957C19483DC79F9F5CC23DC1US70TWXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFi LXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIERlYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIHdoYXQgQWNlZSBtZW50aW9ucyBp dCBkb2VzbuKAmXQgc2VlbSB0aGF0IElPUy1YUiBzdXBwb3J0cyBtYXRjaGluZyBvbiBpbnRlcmZh Y2UgZm9yIEFDTHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIEkgbG9vayBhdCBCcm9jYWRlIEkgZG9u4oCZdCBz ZWUgaXQgZWl0aGVyLiZuYnNwOyBNYXliZSBzb21lb25lIGZyb20gQnJvY2FkZSBjb3VsZCBwcm92 aWRlIGFuIGV4YW1wbGUgb2YgdGhlIGNvbmZpZyBpZiBpdCBpcyBzdXBwb3J0ZWQgPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vWWFuZ01v ZGVscy95YW5nL2Jsb2IvbWFzdGVyL3ZlbmRvci9icm9jYWRlL2Jyb2NhZGUtaXAtYWNjZXNzLWxp c3QueWFuZyI+aHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy9ibG9iL21hc3Rlci92 ZW5kb3IvYnJvY2FkZS9icm9jYWRlLWlwLWFjY2Vzcy1saXN0Lnlhbmc8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPihJIGFsc28gY2hlY2tlZCB0aGVpciB1c2VyIGd1aWRlcyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgdGhpbmsgaXQgaXMgbW9yZSByZWxldmFudCB0byBsb29rIGF0IEFDTCBmdW5jdGlv bmFsaXR5IGZvciB0aGlzIChub3QgbG9nIGZpbHRlcmluZyBvciBvdGhlciBtaXNjLiBmaWx0ZXJp bmcgY2FwYWJpbGl0aWVzIGluIGFyZWFzIG91dHNpZGUgb2YgQUNMcykuJm5ic3A7IEkgcmVhbGx5 DQogZG9u4oCZdCB0aGluayB0aGlzIGhhcyB3aWRlc3ByZWFkIHN1cHBvcnQgYW5kIGl0IGlzbuKA mXQgY29yZSBmdW5jdGlvbmFsaXR5IC0mZ3Q7IGFzc2lnbmluZyBhbiBBQ0wgdG8gYW4gaW50ZXJm YWNlIGlzIGhvdyBpdCBpcyBub3JtYWxseSBkb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFzb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFWFQgRGVh biBCb2dkYW5vdmljIFttYWlsdG86aXZhbmRlYW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBNYXJjaCAzMSwgMjAxNiAyOjI2PGJyPg0KPGI+VG86PC9iPiBTdGVybmUs IEphc29uIChOb2tpYSAtIENBKTxicj4NCjxiPkNjOjwvYj4gbmV0bW9kIFdHPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbbmV0bW9kXSBSZW1vdmUgaW5wdXQtaW50ZXJmYWNlIChtZXRhZGF0YSkg ZnJvbSBuZXRtb2QtYWNsLW1vZGVsLTA3ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDMwLCAyMDE2LCBhdCA5OjM2IFBNLCBT dGVybmUsIEphc29uIChOb2tpYSAtIENBKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJu ZUBub2tpYS5jb20iPmphc29uLnN0ZXJuZUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgQUNMIG1vZGVsIGlzIGNvbnZlcmdp bmcgb24gYSBzbWFsbCBjb3JlIHNldCBvZiBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgZmFpcmx5IGNv bW1vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+QnV0IEkgdGhpbmsgdGhlIG1hdGNoaW5nIG9uIGlucHV0LWludGVy ZmFjZSBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBtb2RlbCAob3IgYXQgdGhlIGxlYXN0IHB1 dCBpbnNpZGUgYSBmZWF0dXJlIGZsYWcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXRjaGluZyBvbiBiYXNpYyBJ UHY0L0lQdjQvTUFDIGhlYWRlciBmaWVsZHMgaXMgY29tbW9uIGZ1bmN0aW9uYWxpdHkuJm5ic3A7 IEJ1dCBoYXZpbmcgdGhhdCBpbnB1dC1pbnRlcmZhY2UgbWF0Y2ggb24gbWV0YWRhdGEgaW4gdGhl IGNvcmUgbW9kZWwgaXMgb3V0IG9mIHBsYWNlLiZuYnNwOyBJdCBzaG91bGQgYmUNCiBsZWZ0IHRv IGZ1cnRoZXIgZXh0ZW5zaW9uIGRyYWZ0cyBvciB2ZW5kb3Igc3BlY2lmaWMgYXVnbWVudGF0aW9u cyAoYWxvbmcgd2l0aCB3aGF0ZXZlciBvdGhlciBtZXRhZGF0YSBtaWdodCBiZSB1c2VmdWwgb3Ig dmVuZG9yLXNwZWNpZmljKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5BQ0xzIGFyZSB0eXBpY2FsbHkgYXNzaWduZWQgdG8gaW50ZXJmYWNlcyBhcyBzaG93biBp biBzZWN0aW9uIEEuMy4gb2YgdGhlIEFDTCBkcmFmdC4mbmJzcDsmbmJzcDsgVGhhdCBpcyB0aGUg bW9zdCBjb21tb24gdXNlIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFjdHVhbGx5IG1hdGNoaW5nIG9uIGlu cHV0LWludGVyZmFjZSBpbiB0aGUgQUNMIHJ1bGVzIHRoZW1zZWx2ZXMgaXMgbm90IGJhc2ljIGNv cmUgQUNMIGZ1bmN0aW9uYWxpdHkuJm5ic3A7IE5va2lhIFNSIE9TIGRvZXMgbm90IGhhdmUgdGhh dCBjYXBhYmlsaXR5LiZuYnNwOyBEb2VzIElPUy1YUiA/Jm5ic3A7IEJyb2NhZGUNCiA/Jm5ic3A7 IG90aGVycyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpc2NvIGFuZCBKdW5pcGVyIHN1 cHBvcnQgbWF0Y2hpbmcgb24gaW5wdXQgaW50ZXJmYWNlLiBJdCBpcyB1c2VmdWwgd2hlbiB5b3Ug d2FudCB0byBmaWx0ZXIgb24gZ2VuZXJhbCB0cmFmZmljIGNvbWluZyBmcm9tIGludGVyZmFjZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lz Y288bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1h dGNoIGlucHV0LWludGVyZmFjZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+bWF0Y2ggaW5wdXQtdmxhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1bm9zPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZmFtaWx5IGFueSB7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ZmlsdGVyIEwyX2ZpbHRlciB7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQp0 ZXJtIHQxIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ZnJvbSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPmludGVyZmFjZSBmZS0wLzAvMC4wOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj59PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PnRoZW4gezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5wb2xpY2VyIHAxOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5jb3VudCBjMTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+fTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KfTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPn08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJvY2FkZSBzdXBwb3J0cyBtYXRjaGlu ZyBiYXNlZCBvbiBpbnRlcmZhY2UsIERlbGwgc3VwcG9ydHMgVkxBTiBtYXRjaGluZywgQXJpc3Rh IHN1cHBvcnRzIGlucHV0IGludGVyZmFjZSBtYXRjaGluZywgUmVkYmFjayBzdXBwb3J0cyBtYXRj aGluZyBhZ2FpbnN0IGlucHV0IGludGVyZmFjZSBmb3IgbG9nZ2luZywgc28gaXQgaXMgcHJldHR5 IHN0YW5kYXJkIGFjcm9zcyBtdWx0aXBsZSB2ZW5kb3JzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBzb21lIG1h am9yIGltcGxlbWVudGF0aW9ucyBkb27igJl0IGRvIGl0LCBhbmQgaXQgaXNu4oCZdCBuZWNlc3Nh cnkgZm9yIHR5cGljYWwgYmFzaWMgQUNMIHVzZSwgdGhlbiBpdCBzaG91bGQgYmUgcmVtb3ZlZCAo b3IgZmVhdHVyZSBmbGFnZ2VkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkphc29uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bmV0 bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A125E53CE190A749957C19483DC79F9F5CC23DC1US70TWXCHMBA11z_-- From nobody Fri Apr 1 16:00:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2112D68E for ; Fri, 1 Apr 2016 16:00: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8OsmdI_UDKX for ; Fri, 1 Apr 2016 16:00:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC0512D51F for ; Fri, 1 Apr 2016 16:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jA0Mq9jGpSWi8JFpQUSBc8NzorFY9XEFTraNTNtHctY=; b=YGhcAp2zoskJNRSBpoMMy+5q9j8KYXO2q6DWKAWK9C2JLKmys91wi8O7YifcaFCNnnNB8wypvuEOb48h4eIuQiyxpkw3hi9tmrmJ77N+2pQfWEtr2DBP/+T9w5kolzW3SeYjiFia+SgitaH0iG2/FqBwiZDJO3SCNhfcD+p1IhY= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 1 Apr 2016 23:00:27 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0447.026; Fri, 1 Apr 2016 23:00:27 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: kw comments on draft-voit-netmod-yang-mount-requirements Thread-Index: AQHRjGpIAXTtA9WPbEeTJ8PJQRAdLQ== Date: Fri, 1 Apr 2016 23:00:27 +0000 Message-ID: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 71dd2a77-60f2-4cc0-ba2f-08d35a816acf x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 5:KH5kmTMlVUHdqaGb3P1hwcEn6txeqA3diGRK7lZM3ULkfQW+GU0J+qQBj0uw5vE4TkFDXnXKQTs7Vk4esEyMgQ0pOxOHAgXYKFIDPTw2Rq+p/OYa6CgXjLb1sJSUGlcYyQ/Jep26jrlRFlJXGvfXUQ==; 24:gKNi8PlQ07H7qA9Gz+q9llqkRFw4EuoyMkdsMwuHmYR2uoJZAwZJEFyNPG9C+5C/zsEk1Z1Hu6aVVRQm+y9mUQKiDYUD0P3Um1e8U3ZU1BI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2906002)(4001350100001)(16236675004)(3660700001)(3280700002)(230783001)(5008740100001)(83506001)(82746002)(11100500001)(54356999)(5640700001)(50986999)(5002640100001)(2900100001)(83716003)(450100001)(110136002)(77096005)(122556002)(10400500002)(189998001)(99286002)(81166005)(107886002)(1096002)(1220700001)(33656002)(87936001)(5004730100002)(36756003)(86362001)(2501003)(92566002)(66066001)(1730700002)(2351001)(102836003)(6116002)(3846002)(229853001)(106116001)(586003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_51F6361D5F32449F80D626A4B3569DC1junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2016 23:00:27.7557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Subject: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 23:00:32 -0000 --_000_51F6361D5F32449F80D626A4B3569DC1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0FzIGEgY29udHJpYnV0b3JdDQoNCk5vdGU6IHRoaXMgaXMgYSAtMDAgZG9jdW1lbnQsIGJ1dCBv bmx5IGJlY2F1c2UgdGhlIGRyYWZ0J3MgbmFtZSBjaGFuZ2VkLiAgSW4gcmVhbGl0eSB0aGlzIGlz IGxpa2UgYSBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wNC4gICAg TG9va2luZyBhdCB0aGUgZGlmZnMsIHRoZXJlIGFyZW4ndCBtYW55IGNoYW5nZXMsIG1vc3RseSBj bGVhbnVwIGFuZCBhZGRpbmcgdGhlICJzY2hlbWEgbW91bnQiIGNvbmNlcHQuICAgVGhhdCBpcywg dGhlIG5ldyAieWFuZyBtb3VudCIgdGVybSBpcyB1c2UgdG8gY292ZXIgYWxsIG9mICJzY2hlbWEg bW91bnQiLCAiYWxpYXMgbW91bnQiLCBhbmQgInBlZXIgbW91bnQiLg0KDQpNeSBjb21tZW50IGlz IG1vc3RseSBoaWdoLWxldmVsLiAgIEknbSB3b25kZXJpbmcgYWJvdXQgdGhlIG5lZWQgZm9yIHRo aXMgZHJhZnQgdG8gaW5jbHVkZSBzY2hlbWEgbW91bnQgYXQgYWxsLiAgIFRoYXQgaXMsIGEgc2No ZW1hIG1vdW50IHNvbHV0aW9uIGRyYWZ0IGlzIG5vdyBhbiBhZG9wdGVkIFdHIGl0ZW0sIGFuZCBJ J20gdW5zdXJlIGlmIHRoZSBhdXRob3JzIG9mIHRoYXQgZHJhZnQgYXJlIGxvb2tpbmcgdG8gdGhp cyBvbmUgdG8gZGVmaW5lIHJlcXVpcmVtZW50cy4gIFBlcmhhcHMgdGhlIGdvYWwgaXMgdG8gZGVm aW5lIHRoZSB1bWJyZWxsYSB0ZXJtICJ5YW5nIG1vdW50IiwgYnV0IHRvIGJlIGhvbmVzdCwgSSBk b24ndCByZWFsbHkgc2VlIGEgbmVlZCB0byBoYXZlIGEgdGVybSB0aGF0IHNwYW5zIGJvdGggc2No ZW1hIGFuZCBkYXRhIG1vdW50cy4gICBJJ20gbm90IHN1cmUgaG93IG90aGVycyBmZWVsIGFib3V0 IHRoaXMsIGJ1dCBteSB0aG91Z2h0cyBhcmUgdGhhdCB3ZSBzaG91bGQgZGVmaW5lIHRlcm1zIGxp a2U6DQoNCi0gc2NoZW1lLW1vdW50DQotIGRhdGEtbW91bnQNCi0gcmVtb3RlIGRhdGEgbW91bnQg ICAoYS5rLmEuIHBlZXIgbW91bnQpDQotIGxvY2FsIGRhdGEgbW91bnQgICAgICAgIChhLmsuYS4g YWxpYXMgbW91bnQpDQoNCk1vcmUgc28gdGhhbjoNCg0KeWFuZy1tb3VudA0KLSBzY2hlbWUtbW91 bnQNCi0gYWxpYXMtbW91bnQNCi0gcGVlci1tb3VudA0KDQoNCkkgcmVhbGl6ZSB0aGF0IHRoZSBm dWxsLWltcGFjdCBvZiB0aGlzIGNoYW5nZSB3b3VsZCBpbXBhY3QgZHJhZnQtY2xlbW0tbmV0bW9k LW1vdW50LCBidXQgSSdkIGxpa2UgdXMgdG8gc2V0dGxlIG9uIGxvbmctdGVybSB0ZXJtcyBhcyBz b29uIGFzIHBvc3NpYmxlLg0KDQpNeSBvdGhlciBoaWdoLWxldmVsIHRob3VnaHQgaXMsIGFzc3Vt aW5nIHRoZSBzY2hlbWEtbW91bnQgcmVxdWlyZW1lbnRzIGFyZSByZW1vdmVkIGZyb20gdGhpcyBk cmFmdCwgd291bGQgdGhlcmUgcmVhbGx5IGJlIGEgbmVlZCBmb3IgdGhpcyByZXF1aXJlbWVudHMg ZHJhZnQ/ICAtIGlzIGl0IGV4cGVjdGVkIHRvIGdldCBwdWJsaXNoZWQgb3Igd291bGQgaXQgYmUg YWxsb3dlZCB0byBleHBpcmUsIGFzIHNvb24gYXMgdGhlIFdHIGFkb3B0cyBkcmFmdC1jbGVtbS1u ZXRtb2QtbW91bnQsIGFzIHRoZW4gaXQncyBwdXJwb3NlIHdvdWxkJ3ZlIGJlZW4gc2VydmVkPyAg IEkgcmVhbGl6ZSB0aGF0IHdlIGhhdmUgYSBwcmVjZWRlbnQgd2l0aCBvcHN0YXRlLXJlcXMsIGJ1 dCBJIG1pZ2h0IGNsYWltIHRoYXQgdGhhdCBkb2Mgd2FzIG5lY2Vzc2FyeSBhcyB3ZSAodGhlIFdH KSByZWFsbHkgZGlkbid0IHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50cyBhbmQgd2UgaGFkIHRv IGRvY3VtZW50IHRoZW0uICBJbiB0aGlzIGNhc2UsIGl0IHNlZW1zIHRoYXQgYWxpYXMvcGVlci9k YXRhLW1vdW50IGhhcyBmZXdlciBwYXJ0aWVzIGludm9sdmVkIGFuZCwgaW4gZmFjdCwgaXMgcGFy dGlhbGx5IGRvY3VtZW50aW5nIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIChPREwpLiAgTWF5 YmUgbXkgcXVlc3Rpb24gaXMsIHdvdWxkIGl0IG1ha2UgbG9uZy10ZXJtIHNlbnNlIHRvIG1lcmdl IHRoZSByZXF1aXJlbWVudHMgdGV4dCBpbnRvIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudD8NCg0K VGhhbmtzLA0KS2VudA0KDQoNCg== --_000_51F6361D5F32449F80D626A4B3569DC1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <103044C8E83D874DBF2E567AABA0B504@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5bQXMgYSBjb250 cmlidXRvcl08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdGU6IHRoaXMgaXMgYSAt MDAgZG9jdW1lbnQsIGJ1dCBvbmx5IGJlY2F1c2UgdGhlIGRyYWZ0J3MgbmFtZSBjaGFuZ2VkLiAm bmJzcDtJbiByZWFsaXR5IHRoaXMgaXMgbGlrZSBhIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91 bnQtcmVxdWlyZW1lbnRzLTA0LiAmbmJzcDsgJm5ic3A7TG9va2luZyBhdCB0aGUgZGlmZnMsIHRo ZXJlIGFyZW4ndCBtYW55IGNoYW5nZXMsIG1vc3RseSBjbGVhbnVwIGFuZCBhZGRpbmcgdGhlICZx dW90O3NjaGVtYSBtb3VudCZxdW90OyBjb25jZXB0Lg0KICZuYnNwOyBUaGF0IGlzLCB0aGUgbmV3 ICZxdW90O3lhbmcgbW91bnQmcXVvdDsgdGVybSBpcyB1c2UgdG8gY292ZXIgYWxsIG9mICZxdW90 O3NjaGVtYSBtb3VudCZxdW90OywgJnF1b3Q7YWxpYXMgbW91bnQmcXVvdDssIGFuZCAmcXVvdDtw ZWVyIG1vdW50JnF1b3Q7LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkgY29tbWVu dCBpcyBtb3N0bHkgaGlnaC1sZXZlbC4gJm5ic3A7IEknbSB3b25kZXJpbmcgYWJvdXQgdGhlIG5l ZWQgZm9yIHRoaXMgZHJhZnQgdG8gaW5jbHVkZSBzY2hlbWEgbW91bnQgYXQgYWxsLiAmbmJzcDsg VGhhdCBpcywgYSBzY2hlbWEgbW91bnQgc29sdXRpb24gZHJhZnQgaXMgbm93IGFuIGFkb3B0ZWQg V0cgaXRlbSwgYW5kIEknbSB1bnN1cmUgaWYgdGhlIGF1dGhvcnMgb2YgdGhhdCBkcmFmdCBhcmUg bG9va2luZyB0byB0aGlzIG9uZSB0byBkZWZpbmUNCiByZXF1aXJlbWVudHMuICZuYnNwO1Blcmhh cHMgdGhlIGdvYWwgaXMgdG8gZGVmaW5lIHRoZSB1bWJyZWxsYSB0ZXJtICZxdW90O3lhbmcgbW91 bnQmcXVvdDssIGJ1dCB0byBiZSBob25lc3QsIEkgZG9uJ3QgcmVhbGx5IHNlZSBhIG5lZWQgdG8g aGF2ZSBhIHRlcm0gdGhhdCBzcGFucyBib3RoIHNjaGVtYSBhbmQgZGF0YSBtb3VudHMuICZuYnNw OyBJJ20gbm90IHN1cmUgaG93IG90aGVycyBmZWVsIGFib3V0IHRoaXMsIGJ1dCBteSB0aG91Z2h0 cyBhcmUgdGhhdCB3ZSBzaG91bGQgZGVmaW5lDQogdGVybXMgbGlrZTo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPi0gc2NoZW1lLW1vdW50PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPi0mbmJzcDtk YXRhLW1vdW50PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPi0gcmVtb3RlIGRhdGEgbW91bnQgJm5ic3A7IChhLmsu YS4gcGVlciBtb3VudCk8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LSBsb2NhbCBkYXRhIG1vdW50ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyhhLmsuYS4gYWxpYXMgbW91bnQpPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5Nb3JlIHNvIHRoYW46PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwv c3Bhbj55YW5nLW1vdW50PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPi0gc2NoZW1lLW1vdW50PC9kaXY+DQo8ZGl2 PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9z cGFuPi0gYWxpYXMtbW91bnQ8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LSBwZWVyLW1vdW50PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSByZWFsaXplIHRoYXQgdGhl IGZ1bGwtaW1wYWN0IG9mIHRoaXMgY2hhbmdlIHdvdWxkIGltcGFjdCBkcmFmdC1jbGVtbS1uZXRt b2QtbW91bnQsIGJ1dCBJJ2QgbGlrZSB1cyB0byBzZXR0bGUgb24gbG9uZy10ZXJtIHRlcm1zIGFz IHNvb24gYXMgcG9zc2libGUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NeSBvdGhl ciBoaWdoLWxldmVsIHRob3VnaHQgaXMsIGFzc3VtaW5nIHRoZSBzY2hlbWEtbW91bnQgcmVxdWly ZW1lbnRzIGFyZSByZW1vdmVkIGZyb20gdGhpcyBkcmFmdCwgd291bGQgdGhlcmUgcmVhbGx5IGJl IGEgbmVlZCBmb3IgdGhpcyByZXF1aXJlbWVudHMgZHJhZnQ/ICZuYnNwOy0gaXMgaXQgZXhwZWN0 ZWQgdG8gZ2V0IHB1Ymxpc2hlZCBvciB3b3VsZCBpdCBiZSBhbGxvd2VkIHRvIGV4cGlyZSwgYXMg c29vbiBhcyB0aGUgV0cgYWRvcHRzDQogZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50LCBhcyB0aGVu IGl0J3MgcHVycG9zZSB3b3VsZCd2ZSBiZWVuIHNlcnZlZD8gJm5ic3A7IEkgcmVhbGl6ZSB0aGF0 IHdlIGhhdmUgYSBwcmVjZWRlbnQgd2l0aCBvcHN0YXRlLXJlcXMsIGJ1dCBJIG1pZ2h0IGNsYWlt IHRoYXQgdGhhdCBkb2Mgd2FzIG5lY2Vzc2FyeSBhcyB3ZSAodGhlIFdHKSByZWFsbHkgZGlkbid0 IHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50cyBhbmQgd2UgaGFkIHRvIGRvY3VtZW50IHRoZW0u DQogJm5ic3A7SW4gdGhpcyBjYXNlLCBpdCBzZWVtcyB0aGF0IGFsaWFzL3BlZXIvZGF0YS1tb3Vu dCBoYXMgZmV3ZXIgcGFydGllcyBpbnZvbHZlZCBhbmQsIGluIGZhY3QsIGlzIHBhcnRpYWxseSBk b2N1bWVudGluZyBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiAoT0RMKS4gJm5ic3A7TWF5YmUg bXkgcXVlc3Rpb24gaXMsIHdvdWxkIGl0IG1ha2UgbG9uZy10ZXJtIHNlbnNlIHRvIG1lcmdlIHRo ZSByZXF1aXJlbWVudHMgdGV4dCBpbnRvIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudD8NCiAmbmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+S2Vu dDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_51F6361D5F32449F80D626A4B3569DC1junipernet_-- From nobody Sat Apr 2 04:39:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48C812D1A2 for ; Sat, 2 Apr 2016 04:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ8RlwbFR75Q for ; Sat, 2 Apr 2016 04:39:05 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DAF12D17E for ; Sat, 2 Apr 2016 04:39:04 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id s5so47531445qkd.0 for ; Sat, 02 Apr 2016 04:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=4m1ImNavxZsSSu1uakoOe+mt1lqh+2nFZ1lZapi2Qms=; b=PJ0l6sZso1VQ9nvxsjXEsRaONElNOZ4NPXBiDUaogceebvq8zfuy7+EFhoLWa1luWQ xsXKuVRQZfIIN+TLXr2U3k0Bm7yq7O7RSj2VG9R5F7jMokDzq3bKly9FJo80YwXhN+QZ l4/t/8vFf/AxgMh/ty0ghROFu/iH7R7Af9IGV27wteFqEU9YOY7P16Zvw8gFiNFA6dj/ Kmu2WM0YVpjweKCPVdGNWP0Hamg8lFFcgdWhZ8a/GOSLrhD25faJIsUyzOcnuiKIoi5G dTcFtRSYNSow0DWd0OUJDI94Wr2rbvcMqzl1+NyO4RtZNFLTIoYJTzR52RIsHjOIP0NC RG2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4m1ImNavxZsSSu1uakoOe+mt1lqh+2nFZ1lZapi2Qms=; b=JKphmyV7Oltx9HWd+yJhFabfXOx8qILVd8oPhY0BTcKTucO1xOb43mOzt/ZPq3Xbs2 CF1+7dVZeV0gg0yinOW4HBrvxGzk45rKFJNhh3oVg1cXE/SYnXwnCTHyrqYlnkd0WYFa JgD1cJ0e6z/uKvQtnDSu6l1LQHEOxTJn2Ed2VqK94IgNq8RyqnR8w2+cQxsShqISc36J Lni+jPkr5EVgS+a0IiAPS3dj1bDpDCF0UrLO1Y+tulgzSxp6qTvArjymwHzODIb0SjDo /b1GDWFy14m5VbVLKjC2wWusdFCpkDKYYMv2BZx02uf5+PX1QeIOmEjD3jB3/uYs4sA5 TRDw== X-Gm-Message-State: AD7BkJL1C7dQVTpz8qNGPFId0N6aOn+hlKBgxBhKkjPVM5TGmMfF8VUQxdhlikQpOkrywg== X-Received: by 10.55.76.84 with SMTP id z81mr23520331qka.17.1459597143742; Sat, 02 Apr 2016 04:39:03 -0700 (PDT) Received: from [172.16.1.10] ([200.61.9.66]) by smtp.gmail.com with ESMTPSA id d187sm8068985qhc.38.2016.04.02.04.39.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 04:39:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F3EB2809-1F8A-41C1-9479-078D3333607B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: Date: Sat, 2 Apr 2016 08:39:56 -0300 Message-Id: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> References: To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 11:39:07 -0000 --Apple-Mail=_F3EB2809-1F8A-41C1-9479-078D3333607B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Acee, > On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee) = wrote: >=20 > Hi Dean,=20 >=20 > From: netmod > on behalf of Dean Bogdanovic = > > Date: Thursday, March 31, 2016 at 5:26 AM > To: "Sterne, Jason (Nokia - CA)" > > Cc: netmod WG > > Subject: Re: [netmod] Remove input-interface (metadata) from = netmod-acl-model-07 ? >=20 >=20 >> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) = > wrote: >>=20 >> Hi all, >> =20 >> The ACL model is converging on a small core set of functionality that = is fairly common. >> =20 >> But I think the matching on input-interface should be removed from = the model (or at the least put inside a feature flag). >> =20 >> Matching on basic IPv4/IPv4/MAC header fields is common = functionality. But having that input-interface match on metadata in the = core model is out of place. It should be left to further extension = drafts or vendor specific augmentations (along with whatever other = metadata might be useful or vendor-specific). >> =20 >> ACLs are typically assigned to interfaces as shown in section A.3. of = the ACL draft. That is the most common use case. >> =20 >> Actually matching on input-interface in the ACL rules themselves is = not basic core ACL functionality. Nokia SR OS does not have that = capability. Does IOS-XR ? Brocade ? others ? >=20 > Cisco and Juniper support matching on input interface. It is useful = when you want to filter on general traffic coming from interface. >=20 > Cisco > match input-interface > match input-vlan >=20 > These are =E2=80=9Cclass-map=E2=80=9D sub-commands - not = =E2=80=9Caccess-list" sub-commands. So you are referring to the general = functionality rather than specifically functionality supported by = access-list?=20 According to the Cisco website = (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/sof= tware/release/12-2_55_se/configuration/guide/3750xscg/swacl.html) Note The ACL must be an extended named ACL. <>=E2=80=93 match input-interface interface-id-list <>=E2=80=93 match ip dscp dscp-list <>=E2=80=93 match ip precedence ip-precedence-list >=20 >=20 >=20 > Junos > family any { > filter L2_filter { > term t1 { > from { > interface fe-0/0/0.0; > } > then { > policer p1; > count c1; > } > } > } > } >=20 > Brocade supports matching based on interface, Dell supports VLAN = matching, Arista supports input interface matching, Redback supports = matching against input interface for logging, >=20 > If you are referring to =E2=80=9Clog-input=E2=80=9D, this indicates to = include the input-interface in the log message. Cisco supports this as = well.=20 >=20 > Thanks, > Acee=20 >=20 >=20 > so it is pretty standard across multiple vendors >=20 > Dean >=20 >> If some major implementations don=E2=80=99t do it, and it = isn=E2=80=99t necessary for typical basic ACL use, then it should be = removed (or feature flagged). >> =20 >> Regards, >> Jason=20 >> =20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_F3EB2809-1F8A-41C1-9479-078D3333607B Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_9A845F92-C431-4775-96D9-D88B1333A777" --Apple-Mail=_9A845F92-C431-4775-96D9-D88B1333A777 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Acee,

On Mar 31, 2016, at 8:17 AM, Acee Lindem = (acee) <acee@cisco.com> wrote:

Hi Dean, 

From: netmod <netmod-bounces@ietf.org> on behalf of Dean Bogdanovic = <ivandean@gmail.com>
Date: Thursday, March = 31, 2016 at 5:26 AM
To: "Sterne, Jason = (Nokia - CA)" <jason.sterne@nokia.com>
Cc: netmod WG <netmod@ietf.org>
Subject: Re: [netmod] = Remove input-interface (metadata) from netmod-acl-model-07 ?


On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) = <jason.sterne@nokia.com> wrote:

Hi all,
 
The ACL model is converging on a small core set of = functionality that is fairly common.
 
But I think the matching on input-interface should be = removed from the model (or at the least put inside a feature = flag).
 
Matching on basic IPv4/IPv4/MAC header fields is common = functionality.  But having that input-interface match on metadata = in the core model is out of place.  It should be left to further = extension drafts or vendor specific augmentations (along with whatever other metadata might be useful or vendor-specific).
 
ACLs are typically assigned to interfaces as shown in = section A.3. of the ACL draft.   That is the most common use = case.
 
Actually matching on input-interface in the ACL rules = themselves is not basic core ACL functionality.  Nokia SR OS does = not have that capability.  Does IOS-XR ?  Brocade ?  = others ?

Cisco and Juniper support matching on input interface. = It is useful when you want to filter on general traffic coming from = interface.

Cisco
match input-interface
match input-vlan

These are =E2=80=9Cclass-map=E2=80=9D  sub-commands = - not =E2=80=9Caccess-list" sub-commands. So you are referring to the = general functionality rather than specifically functionality supported = by access-list? 

According to the Cisco website (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x= _3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swacl.html= )

Note The ACL must be an = extended named ACL.

=E2=80=933D"" match input-interface interface-id-list

=E2=80=933D"" match ip dscp dscp-list

=E2=80=933D"" match ip precedence ip-precedence-list




Junos
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
}
}

Brocade supports matching based on interface, Dell = supports VLAN matching, Arista supports input interface matching, = Redback supports matching against input interface for logging,

If you are referring to =E2=80=9Clog-input=E2=80=9D, = this indicates to include the input-interface in the log message. Cisco = supports this as well. 

Thanks,
Acee 


so it is pretty standard across multiple vendors

Dean

     If some major implementations = don=E2=80=99t do it, and it isn=E2=80=99t necessary for typical basic = ACL use, then it should be removed (or feature flagged).
 
Regards,
Jason 
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_9A845F92-C431-4775-96D9-D88B1333A777 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=blank.gif Content-Type: image/gif; name="blank.gif" Content-Id: R0lGODlhAgACAIAAAP///wAAACH5BAEAAAAALAAAAAACAAIAAAIChFEAOw== --Apple-Mail=_9A845F92-C431-4775-96D9-D88B1333A777-- --Apple-Mail=_F3EB2809-1F8A-41C1-9479-078D3333607B-- From nobody Sat Apr 2 04:48:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91B612D530 for ; Sat, 2 Apr 2016 04:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDbXcGQcCv5u for ; Sat, 2 Apr 2016 04:48:02 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 0C68312D1A2 for ; Sat, 2 Apr 2016 04:48:01 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id y89so116288792qge.2 for ; Sat, 02 Apr 2016 04:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vFslwlSHgqoLTpC79Ooq2JMfSkuDOja0PoTJUJwaj7M=; b=lHJnBJ0B1pYk28G4V+eR3u7hsw6ypsoFz44om+iM/CTVH2znxQBm600JfEZjrfU8cK PjmodbQKtytiQ04izH2Mq7U2V+NzqrXsaHvPNywaCd7fK8Apirxql+vW4M585/qLEucV UDzehZi4TwPoEIiHgjGf33AOGN/f93mSFMf9aQSC3XQJHR9q6xl8jhoPQMD8gOA1QPBS CDHE4O5rnchRgJCZ++Gzu+dXtS5cPI7oECekgVzbwVTNrMd9BYi4Eo1qIEu1TbeJHZ79 1pTxke3onFH8/MgM2FT6wDu2Zjg4pg2CI7LuFIMBonevTALQGtL0A5ObE8Peyv7Wp6tA Fs4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vFslwlSHgqoLTpC79Ooq2JMfSkuDOja0PoTJUJwaj7M=; b=Z4Mi3PHgl1ClbjoATv/t67cKdIDtz71Tnl3Se1KCMfLgfVTu0ybNwcO+ouRgO4pjIn vKdbJb1GA0BKl3/I0TZmalbsFGVfi8uaSaleJ5FbZCRj4NdeNEgMew9bRhe/LSQI+fVP AVDoxe6x9TIuvK1XwPwH4V+dEEWjuq/bb/mk0P+SRuWj/b4zRn0ZxJU1MeRqdEztwXYL nmKUROX3ewCmOZvlm1C0Us/9put0ixCqFSM6Bj2c1bJZ4qlzKm7WqHx0Do8al/4vQlxy OmgxlIgkq+Wr4OMIa9q/RC+cJJRfyw6n/SZIekLSCoPt4jdkA9zzwb53aRvGgkUwk/iJ bMWQ== X-Gm-Message-State: AD7BkJJIqDf6OU1CQgKabq33JSYidBSSsZ10k47FY33yrBC5+KnAK2r1hIayjRRZGjX/Pw== X-Received: by 10.140.179.134 with SMTP id z128mr1677677qhz.40.1459597681011; Sat, 02 Apr 2016 04:48:01 -0700 (PDT) Received: from [172.16.1.10] ([200.61.9.66]) by smtp.gmail.com with ESMTPSA id d6sm8181766qkb.13.2016.04.02.04.47.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 04:48:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_58D59953-6C76-4806-A939-F618C9DF9A81" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: Date: Sat, 2 Apr 2016 08:48:54 -0300 Message-Id: References: To: "Sterne, Jason (Nokia - CA)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 11:48:05 -0000 --Apple-Mail=_58D59953-6C76-4806-A939-F618C9DF9A81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jason, > On Apr 1, 2016, at 6:54 PM, Sterne, Jason (Nokia - CA) = wrote: >=20 > Hi Dean, > =20 > =46rom what Acee mentions it doesn=E2=80=99t seem that IOS-XR supports = matching on interface for ACLs. I replied to Acee=E2=80=99s comment in separate email, as I found some = examples on the web, but it looks as older versions of software. > =20 > When I look at Brocade I don=E2=80=99t see it either. Maybe someone = from Brocade could provide an example of the config if it is supported ? > = https://github.com/YangModels/yang/blob/master/vendor/brocade/brocade-ip-a= ccess-list.yang = > (I also checked their user guides) Brocade gives examples of using ACLs in route-maps and provide examples = http://www.brocade.com/content/html/en/configuration-guide/netiron-05900-r= outingguide/GUID-83F457B7-4CFB-4852-AC08-59BCD9E2AF7C.html > =20 > I think it is more relevant to look at ACL functionality for this (not = log filtering or other misc. filtering capabilities in areas outside of = ACLs). I really don=E2=80=99t think this has widespread support and it = isn=E2=80=99t core functionality -> assigning an ACL to an interface is = how it is normally done. I=E2=80=99ll add this item to the open issue and will ask WG at the = meeting for opinion. > =20 > Regards, > Jason > =20 > From: EXT Dean Bogdanovic [mailto:ivandean@gmail.com = ]=20 > Sent: Thursday, March 31, 2016 2:26 > To: Sterne, Jason (Nokia - CA) > Cc: netmod WG > Subject: Re: [netmod] Remove input-interface (metadata) from = netmod-acl-model-07 ? > =20 > =20 > On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) = > wrote: > =20 > Hi all, > =20 > The ACL model is converging on a small core set of functionality that = is fairly common. > =20 > But I think the matching on input-interface should be removed from the = model (or at the least put inside a feature flag). > =20 > Matching on basic IPv4/IPv4/MAC header fields is common functionality. = But having that input-interface match on metadata in the core model is = out of place. It should be left to further extension drafts or vendor = specific augmentations (along with whatever other metadata might be = useful or vendor-specific). > =20 > ACLs are typically assigned to interfaces as shown in section A.3. of = the ACL draft. That is the most common use case. > =20 > Actually matching on input-interface in the ACL rules themselves is = not basic core ACL functionality. Nokia SR OS does not have that = capability. Does IOS-XR ? Brocade ? others ? > =20 > Cisco and Juniper support matching on input interface. It is useful = when you want to filter on general traffic coming from interface. > =20 > Cisco > match input-interface > match input-vlan > =20 > =20 > Junos > family any { > filter L2_filter { > term t1 { > from { > interface fe-0/0/0.0; > } > then { > policer p1; > count c1; > } > } > } > } > =20 > Brocade supports matching based on interface, Dell supports VLAN = matching, Arista supports input interface matching, Redback supports = matching against input interface for logging, so it is pretty standard = across multiple vendors > =20 > Dean > =20 > If some major implementations don=E2=80=99t do it, and it isn=E2=80= =99t necessary for typical basic ACL use, then it should be removed (or = feature flagged). > =20 > Regards, > Jason=20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_58D59953-6C76-4806-A939-F618C9DF9A81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Jason,

On = Apr 1, 2016, at 6:54 PM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:

Hi = Dean,
 
=46rom what Acee = mentions it doesn=E2=80=99t seem that IOS-XR supports matching on = interface for ACLs.

I replied to Acee=E2=80=99s comment in separate email, = as I found some examples on the web, but it looks as older versions of = software.
 
When I look at Brocade = I don=E2=80=99t see it either.  Maybe someone from Brocade could = provide an example of the config if it is supported ?
https://github.com/YangModels/yang/blob/master/vendor/brocade/b= rocade-ip-access-list.yang
(I = also checked their user = guides)

Brocade gives examples of using ACLs in route-maps and = provide examples
http://www.brocade.com/content/html/en/configuration-guide/neti= ron-05900-routingguide/GUID-83F457B7-4CFB-4852-AC08-59BCD9E2AF7C.html<= br class=3D"">
 
I think it is more = relevant to look at ACL functionality for this (not log filtering or = other misc. filtering capabilities in areas outside of ACLs).  I = really don=E2=80=99t think this has widespread support and it isn=E2=80=99= t core functionality -> assigning an ACL to an interface is how it is = normally done.

I=E2=80=99ll add this item to the open issue and will = ask WG at the meeting for opinion.

 
Regards,
Jason
 
From: EXT Dean = Bogdanovic [mailto:ivandean@gmail.com] 
Sent: Thursday, March 31, 2016 = 2:26
To: Sterne, Jason (Nokia - = CA)
Cc: netmod WG
Subject: Re: [netmod] Remove = input-interface (metadata) from netmod-acl-model-07 ?
 
 
On = Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> = wrote:
 
Hi= all,
 
The ACL model is converging on a small core set = of functionality that is fairly common.
 
But I think the matching on input-interface = should be removed from the model (or at the least put inside a feature = flag).
 
Matching on basic IPv4/IPv4/MAC header fields is = common functionality.  But having that input-interface match on = metadata in the core model is out of place.  It should be left to = further extension drafts or vendor specific augmentations (along with = whatever other metadata might be useful or vendor-specific).
 
ACLs are typically assigned to interfaces as shown in section = A.3. of the ACL draft.   That is the most common use case.
 
Actually matching on input-interface in the ACL = rules themselves is not basic core ACL functionality.  Nokia SR OS = does not have that capability.  Does IOS-XR ?  Brocade ?  = others ?
 
Cisco and Juniper support matching on input = interface. It is useful when you want to filter on general traffic = coming from interface.
 
Cisco
match = input-interface
match input-vlan
 
 
Junos
family= any {
        &= nbsp;   filter L2_filter = {
        &= nbsp;           &nb= sp;   term t1 {
        &= nbsp;           &nb= sp;            = ;   from {
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  interface = fe-0/0/0.0;
        &= nbsp;           &nb= sp;            = ;   }
        &= nbsp;           &nb= sp;            = ;   then {
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  policer p1;
        &= nbsp;           &nb= sp;            = ;            &= nbsp;  count= c1;
        &= nbsp;           &nb= sp;            = ;   }
        &= nbsp;           &nb= sp;   }
        &= nbsp;   }
}
 
Brocade supports matching based on interface, Dell = supports VLAN matching, Arista supports input interface matching, = Redback supports matching against input interface for logging, so it is = pretty standard across multiple vendors
 
Dean
 
     = If some major implementations don=E2=80=99t do it, and it isn=E2=80=99t = necessary for typical basic ACL use, then it should be removed (or = feature flagged).
 
Regards,
Jason 
 
_______________________________________________netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_58D59953-6C76-4806-A939-F618C9DF9A81-- From nobody Sat Apr 2 04:58:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A548912D55E for ; Sat, 2 Apr 2016 04:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI9HppapxrcZ for ; Sat, 2 Apr 2016 04:58:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732F612D552 for ; Sat, 2 Apr 2016 04:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q/a8Z/ZkNmXMY6XbB5bxML9Cm+iYWvm8xqfI7jRKVZ8=; b=glO8Eq5cwJkGOQrjVoQC2wAdc3jvP3LqQMCoVvONbj1Jcp9d6H1DtpBa8nmq2eGKRFxzGU5nQGqYmwKJtRaRq4kv4LRzEXctSoL6WCNBaAYKDCz8TokfpoMyBBCwp2KHBqbJzt0oCysoRhkndFzHOeNsim+xBzSqLmKwMV5J+3g= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (81.132.199.159) by HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) with Microsoft SMTP Server (TLS) id 15.1.443.7; Sat, 2 Apr 2016 11:57:43 +0000 Message-ID: <00ee01d18cd6$78724620$4001a8c0@gateway.2wire.net> From: t.petch To: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , Andy Bierman , "Clyde Wildes (cwildes)" References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com> Date: Sat, 2 Apr 2016 12:54:45 +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.132.199.159] X-ClientProxiedBy: HE1PR08CA0008.eurprd08.prod.outlook.com (25.161.112.18) To HE1PR07MB1625.eurprd07.prod.outlook.com (25.166.124.21) X-MS-Office365-Filtering-Correlation-Id: 75761750-0e7d-486f-e3b4-08d35aee002f X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 2:YLTSmdInb6qoLCRcBhWuLUgl/GYoxPR1zZ+elIvxCQPUkjBjLdXI696esIRgbSCXCarGo44UoXksGGSorehVlsAWkfAI7izsGZ4qselFUvujzpW9LfY0wx8uYh/MGUgN2yUu9zcgG99rrCV7TreaixR9FFJd3UmCCiC85G9KGbbq8A3N52MKcC2GJJ/9tpPR; 3:I0xLkut7sXUGcyuHOHbM8ae+sKKgCXn2mgG2k3oRljgJr30RL0eockleZNWtaVxoXbxSdyVKgimjx+bsY+/PDoCsF6Fbd7t8l8GOpV5UAl0EMkBsjvJWtgr3BkTpjRtv X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1625; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 25:idlxJsLGj/mS6TEUA9ijKVmDkb/rep7FfrkKK41uqyS5scZjf3eA+4tztMCeUfwTG2BLi+bzFtYlhzaDpytUerO9V4r/nZXApHbLeUL6D9fEEos3Q4nMciA+ogCSlNoaFOO1etiuKoyKuwval+ohNEp6qHFiDKyA/kv8gXQEZ9iWnVS27C743Un2sX/buZaz2jGawaT8bHoxPNaeGHEPZOM+e/MLLs+u7icc1uFEX9ylN71akgGdqD9ASHBpkKaVLZYayZ9QKr6qlh9dD1Mby7A7cz6/bC1iXYcyLhQuFjmD51DPbWJu3RLeHnYLrCxa8CJ7LAqT+U+tfeAlww9JOnHlgVviXQnp6FhXIbDCl8krxT/vUueWnKk8S5a4Dq57BLqYfGTxPNKbpyCLCzqRfSWflhC8VGd8deIyHTAbd1Wg2gpD2vsXG+oo39e7FJd20z59+1OrMK7zxXcdQcCreHV3urDrFRixVV60RSBmjW2X+2sFCh/B+XTu+xWqkki41C3pNTshXspVRER7SWDp3sD49FYRZUDUSYAYGR7Y9Sdw6rUhq9ZGPvBfwpriGA7vXIHAVEAq1mpg8g2emoYKS6kIgdHkx4tMz6k5C5MiI91Lomf4PMOQoCtqz/nqPs3q/KjpkLOZPzLg6+Q67kd73EEGaQUQDCNEUmtyuCLzPGloSSPjGqVDJV/znc2nF9uAcBWR8cfjta7SExRCcaxj3w== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR07MB1625; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1625; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 4:bbyfJyxTMCbPp6tfUI4HWMP4QCDhUJcxKgCBLk5KxBiMFIGp9xJTC+gTPZ9RSXcW21FxXmkFrFqIL4TaKs6G15X+/p1ztYGKUrmnkvnfLZ93PC+fMPKQkAHCytDwkCz8HaYh2IjRAf8VZDDY8Vfbbn9lACDP1LJNEQgXFeE5VRM0h+Nf4T/DLVdOZowrOHm5hetHCFdcattKmjP/BeOBseOat6SQTg5wyq4cpDBu+rIOGDJGlgGXnSIYjLHvCI8odR352yA406cOJHgP7b0tRpkHGojHNIVyVxtjWzKU1kJZ0eZ2poH/WtrAkF7YR6laVW9LLubhycC9OeBaCwcahaAbSLaim3Et4K+PCzgjLkJEvl4Gssx+WSzH89Bs/BMBR9bLzALGgvju716mbWSnGWnE6k2YSEZAY89QSjQFAec= X-Forefront-PRVS: 09007040D4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(24454002)(164054003)(13464003)(377424004)(92566002)(230700001)(47776003)(50466002)(81166005)(81816999)(189998001)(81686999)(62236002)(19580405001)(5008740100001)(19580395003)(50986999)(14496001)(66066001)(77096005)(44716002)(5001770100001)(15975445007)(93886004)(76176999)(5004730100002)(42186005)(4326007)(33646002)(230783001)(3846002)(2906002)(586003)(23756003)(6116002)(86362001)(61296003)(1096002)(84392002)(50226001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1625; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1625; 23:YQ4D01+t/+GEh8V9Et2I9ufCCqfp0GEo9CQZ8ZH?= =?iso-8859-1?Q?SHLuSxv+9YUMxB4PgvBoU1DHxEYAEzhAVzyw8q38pmQ1I+5/dRLJZKimPB?= =?iso-8859-1?Q?wijCGwvpIbecEdxotAr4lB90jXL/NcDIeQ3CtTi4O/pE5kWNM9djs8Gxwn?= =?iso-8859-1?Q?2DzU7cMDDbX2J0pHQpL5zFFBRWMAYFqdiEc4TYSEXzjSm6IhdWt+vijd3S?= =?iso-8859-1?Q?iwLx6ClWEPcLylTKWzqpDjWvX3CFfm5ypGXfrUU49T3aiXFkY5cFXcJCKG?= =?iso-8859-1?Q?DDlmenf3f/h8SV7YreHnpFT0gpFkpsWRIh1ly5zkHe664aCj9brsrjqM4L?= =?iso-8859-1?Q?18WtZFMI3v9UHNkgPqfX84nWsM6zJUFe5cFLAepZ07FwfSXt22QOnZsdvM?= =?iso-8859-1?Q?dQNNCt3bNva4Mlrp4SESblZoaKbivoKoDAqkRTYMej1yfNVc4UjZ7hUhAC?= =?iso-8859-1?Q?U7/XK8rS+Szz6YXR8dT7rFtZ4hwurqxIB//IBFWe71lQEejrxxyQ3ozttR?= =?iso-8859-1?Q?NhSlDUbklCdxtP/oUIdyl5ltI28wUyW6X8aNQCCfaWnxj9HaFhMgahsjP5?= =?iso-8859-1?Q?56xXba5xPpYd0cet6h8aYST3aMBoltSiE0ge3JtJRk9SMBEdPEFVEbgNN5?= =?iso-8859-1?Q?NToiozta/Sux8jz0iADMNSiFPq/WnFVAQq6FQZhUueyA9QbTFObXEcAiPT?= =?iso-8859-1?Q?TxGWhkeuyp4boD+3CKQXT0Vruzi17l3GOHEsL4C/2bez/1MrxxMKHCRo0q?= =?iso-8859-1?Q?qZetfqPyXjaztbntHGAEKkkj4rkYeYAbafNgwr6c4URXSbsjqgb7XLFg0X?= =?iso-8859-1?Q?uHpiMh1Voeq0aj86d3NIw08AWDwW1MIKaR+tqWzvR8eHSV9W4jddqnU2S8?= =?iso-8859-1?Q?CJ56LpMsGaxHH8ELzVn8K221VvGJwZxwpTCkn0HQ09UF513E7VfByKynj7?= =?iso-8859-1?Q?PMocnxuOsDq866KK2WFu06Zyo5vGy6Ux8kiF57f6OGaPeYRLqrkizQDIOV?= =?iso-8859-1?Q?XCeJM6oy+r5wqbm5KDUvqZvZButN4JHAnwBqrRx4qDNR3V4nHsB9Jmtqzn?= =?iso-8859-1?Q?0wN0BJT2Gh7BQhT/lE9KooqkOXeruAhBRHEZ0FsyNmUlbzqOy50I3lxQGF?= =?iso-8859-1?Q?gqAVtssVGPJUSqU7MQ7goVNDNE/wkzdfWhpHeexjLla+qffW2KpM4Iqsvn?= =?iso-8859-1?Q?mc1AggHPbDzL5X1GxsC7FfNwVBNF9owxp2qCS/ZPDGX1/wvPID9+MmdaHl?= =?iso-8859-1?Q?a/nwn0H1Wz8b6fmt2?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 5:wjv3vkibBWzfln/+KIj43GsA/a+8RpVzINl6knVggHsmm0MIehNHimu1cG6lm6TBePZztKVJXfnK8k0U4cQ1a3V4ptDdeHkC+UYGqrQf1QGEB5TIserbsGBVnfejeyDOjJhqX3s1YzMEYuLe2N8/gA==; 24:PzyAiblLVjKAYSUMxVPrU9Q3LDS9nH/kFJG+mFgXeXvg0pmp9kBjyfi1QSY7rlibtlPhdLnktTb15B9q1kU5guf1bi5SHjmG8sj13aNW+i4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2016 11:57:43.7007 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1625 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 11:58:12 -0000 ---- Original Message ----- From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" Cc: "t.petch" ; Sent: Monday, March 28, 2016 9:55 PM Hi Andy We did solicit and incorporate feature support from at least 5+ vendors for this model. The model represents a minimal common feature set. They are also hierarchical as Clyde noted below. Thanks Kiran If I remember my mathematical teminology, I prefer a highest common factor, to which augmentations can be applied, whereas others prefer a lowest common denominator, partitioned by features. I do not doubt that everything you model is there in implementations but I prefer a widely, preferably universal, core which can then be added to. It is a judgement call rather than an engineering one, a matter of philosophy even, so I leave it up to rough consensus. Tom Petch From: Andy Bierman > Date: Monday, March 28, 2016 at 3:32 PM To: "Clyde Wildes (cwildes)" > Cc: "t.petch" >, "netmod@ietf.org" >, Kiran Koushik Agrahara Sreenivasa > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (cwildes) > wrote: Tom, I understand your concern with the complexity of the model. That said, as we progressed we encountered some vendors and some IETF RFC authors who requested that a particular feature of interest be included. We felt that we had to make features that were not implemented by two or more vendors a YANG feature to gain acceptance. Which is preferred in this case: augmentation to add features; deviation not-supported statements to remove features; or the use of feature statements? During early model development our YANG doctor advisor advocated using feature. I read your post on "features - a Cartesian explosion" post. Note that in the case of the latest ietf-syslog model four of the features are nested such that they are not encountered unless a higher level feature is enabled. What would your preference be: - remove the feature statements and ask vendors to supply deviation statements for those leaves not implemented - remove all leaves conditioned by feature and ask vendors to supply annotated models with augmentation - leave things as they are It sounds like B would be your preference? I agree with Tom. IMO if the functionality is not supported by at least 2 vendors then remove it from the standard. The vendor can write a module that augments the base module. Thanks, Clyde Andy On 3/28/16, 10:09 AM, "t.petch" > wrote: > >----- Original Message ----- >From: "Clyde Wildes (cwildes)" > >To: > >Cc: "Martin Bjorklund" >; "t.petch" >>; "Kiran Koushik Agrahara Sreenivasa (kkoushik)" >> >Sent: Sunday, March 20, 2016 7:53 PM > >> Hi, >> >> This revision incorporates feedback from Martin Bjorklunk (19 >comments) and Tom Petch (10 comments). Thanks to both of you for your >valuable feedback! >> >> Regarding Tom's comment - "4.1 What a lot of features? Again, makes >things more complex, more error prone - are they all really needed?": We >started the draft two years ago and it has evolved from feedback >received from all of the folks that appear in the Acknowledgements >section. Please review the current draft where I believe that I address >all of your comments except possibly this one. The tradeoff is to leave >the feature specific functionality out of the draft and leave it to the >implementations to add back through augmentation. That said most of the >features that are called out have been implemented by at least two >vendors, but not all, leading to the feature designation. > >Clyde > >Yeeees; I did a separate post on the topic thinking that an implementor >might share my concerns about the large number of possible variations in >an implementation when there were a large number of features, that >perhaps there should be guidelines about it, but it did not get any >traction. It is one those issues where I think, in a year or two's >time, others might share my concern, but not yet:-(. > >I don't doubt that the variation exists and needs modelling, just that >such use of 'features' may have unfortunate consequences - but I have no >alternative suggestion. > >Tom Petch > >> Thanks, >> >> Clyde >> >> >> >> On 3/20/16, 8:10 AM, "netmod on behalf of internet-drafts@ietf.org" > on behalf of internet-drafts@ietf.org> wrote: >> >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> >This draft is a work item of the NETCONF Data Modeling Language of >the IETF. >> > >> > Title : SYSLOG YANG Model >> > Authors : Clyde Wildes >> > Kiran Koushik >> > Filename : draft-ietf-netmod-syslog-model-07.txt >> > Pages : 34 >> > Date : 2016-03-20 >> > >> >Abstract: >> > This document describes a data model for the Syslog protocol which >is >> > used to convey event notification messages. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ >> > >> >There's also a htmlized version available at: >> >https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-07 >> > >> >A diff from the previous version is available at: >> >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-07 >> > >> > >> >Please note that it may take a couple of minutes from the time of >submission >> >until the htmlized version and diff are available at tools.ietf.org. >> > >> >Internet-Drafts are also available by anonymous FTP at: >> >ftp://ftp.ietf.org/internet-drafts/ >> > >> >_______________________________________________ >> >netmod mailing list >> >netmod@ietf.org >> >https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Apr 2 05:42:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD01212D10D for ; Sat, 2 Apr 2016 05:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Rval6o0gG4 for ; Sat, 2 Apr 2016 05:42:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0133212D149 for ; Sat, 2 Apr 2016 05:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31963; q=dns/txt; s=iport; t=1459600945; x=1460810545; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DQQvdqvs0ILQpLdHk4kbEPsl5V6lie83IUIaZF12Bog=; b=g6hmHJ8GM0LpdSwt5tF28eKaCfk05aBq6MVX19hlgUwOzALxTEvW96Wz H7597nbfgxt6UcxMh2NT1OCUitezvk0VrwWtJqJQN7vYHrOB5BYWdRhI5 ikPknpuy+/XX5Ao0sB7lfFK6Bce1neoMQ93z07VqQiiiRfuOPoWiTHVxt A=; X-Files: blank.gif : 43 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAgBhvf9W/4ENJK1dgmtMU30Gql6EZ?= =?us-ascii?q?otVDoFyFwEEgkGCZkoCHIEKOBQBAQEBAQEBZSeEQQEBAQQBAQECHkEKCxACAQg?= =?us-ascii?q?OAwMBAgYBAhgHAwICAhUBCQUBCxQJCAIEDgQBBgiIBAMSDrMRjAINhRcBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQENCIpqgkGCBRkNCYJKglYFiEyFAYU4hEsxAYMfgWY?= =?us-ascii?q?BhwyBdYpVhDqHRIdVAR4BQ4NnbAGHJ34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,431,1454976000"; d="gif'147?scan'147,208,217,147";a="256511641" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Apr 2016 12:42:23 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u32CgNmJ013237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Apr 2016 12:42:23 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 08:42:21 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sat, 2 Apr 2016 08:42:21 -0400 From: "Acee Lindem (acee)" To: Dean Bogdanovic Thread-Topic: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? Thread-Index: AQHRiy9QFzBlKCUK2Eu8wY4yL7QnTp9zZ1EAgANuIAD//85egA== Date: Sat, 2 Apr 2016 12:42:21 +0000 Message-ID: References: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> In-Reply-To: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/mixed; boundary="_004_D325357456730aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 12:42:28 -0000 --_004_D325357456730aceeciscocom_ Content-Type: multipart/alternative; boundary="_000_D325357456730aceeciscocom_" --_000_D325357456730aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVhbiwNCg0KRnJvbTogRGVhbiBCb2dkYW5vdmljIDxpdmFuZGVhbkBnbWFpbC5jb208bWFp bHRvOml2YW5kZWFuQGdtYWlsLmNvbT4+DQpEYXRlOiBTYXR1cmRheSwgQXByaWwgMiwgMjAxNiBh dCA3OjM5IEFNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNp c2NvLmNvbT4+DQpDYzogIlN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIiA8amFzb24uc3Rlcm5l QG5va2lhLmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+LCBuZXRtb2QgV0cgPG5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbmV0 bW9kXSBSZW1vdmUgaW5wdXQtaW50ZXJmYWNlIChtZXRhZGF0YSkgZnJvbSBuZXRtb2QtYWNsLW1v ZGVsLTA3ID8NCg0KSGkgQWNlZSwNCg0KT24gTWFyIDMxLCAyMDE2LCBhdCA4OjE3IEFNLCBBY2Vl IExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdy b3RlOg0KDQpIaSBEZWFuLA0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBEZWFuIEJvZ2Rh bm92aWMgPGl2YW5kZWFuQGdtYWlsLmNvbTxtYWlsdG86aXZhbmRlYW5AZ21haWwuY29tPj4NCkRh dGU6IFRodXJzZGF5LCBNYXJjaCAzMSwgMjAxNiBhdCA1OjI2IEFNDQpUbzogIlN0ZXJuZSwgSmFz b24gKE5va2lhIC0gQ0EpIiA8amFzb24uc3Rlcm5lQG5va2lhLmNvbTxtYWlsdG86amFzb24uc3Rl cm5lQG5va2lhLmNvbT4+DQpDYzogbmV0bW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gUmVtb3ZlIGlucHV0LWludGVy ZmFjZSAobWV0YWRhdGEpIGZyb20gbmV0bW9kLWFjbC1tb2RlbC0wNyA/DQoNCg0KT24gTWFyIDMw LCAyMDE2LCBhdCA5OjM2IFBNLCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSA8amFzb24uc3Rl cm5lQG5va2lhLmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+IHdyb3RlOg0KDQpI aSBhbGwsDQoNClRoZSBBQ0wgbW9kZWwgaXMgY29udmVyZ2luZyBvbiBhIHNtYWxsIGNvcmUgc2V0 IG9mIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBmYWlybHkgY29tbW9uLg0KDQpCdXQgSSB0aGluayB0 aGUgbWF0Y2hpbmcgb24gaW5wdXQtaW50ZXJmYWNlIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhl IG1vZGVsIChvciBhdCB0aGUgbGVhc3QgcHV0IGluc2lkZSBhIGZlYXR1cmUgZmxhZykuDQoNCk1h dGNoaW5nIG9uIGJhc2ljIElQdjQvSVB2NC9NQUMgaGVhZGVyIGZpZWxkcyBpcyBjb21tb24gZnVu Y3Rpb25hbGl0eS4gIEJ1dCBoYXZpbmcgdGhhdCBpbnB1dC1pbnRlcmZhY2UgbWF0Y2ggb24gbWV0 YWRhdGEgaW4gdGhlIGNvcmUgbW9kZWwgaXMgb3V0IG9mIHBsYWNlLiAgSXQgc2hvdWxkIGJlIGxl ZnQgdG8gZnVydGhlciBleHRlbnNpb24gZHJhZnRzIG9yIHZlbmRvciBzcGVjaWZpYyBhdWdtZW50 YXRpb25zIChhbG9uZyB3aXRoIHdoYXRldmVyIG90aGVyIG1ldGFkYXRhIG1pZ2h0IGJlIHVzZWZ1 bCBvciB2ZW5kb3Itc3BlY2lmaWMpLg0KDQpBQ0xzIGFyZSB0eXBpY2FsbHkgYXNzaWduZWQgdG8g aW50ZXJmYWNlcyBhcyBzaG93biBpbiBzZWN0aW9uIEEuMy4gb2YgdGhlIEFDTCBkcmFmdC4gICBU aGF0IGlzIHRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZS4NCg0KQWN0dWFsbHkgbWF0Y2hpbmcgb24g aW5wdXQtaW50ZXJmYWNlIGluIHRoZSBBQ0wgcnVsZXMgdGhlbXNlbHZlcyBpcyBub3QgYmFzaWMg Y29yZSBBQ0wgZnVuY3Rpb25hbGl0eS4gIE5va2lhIFNSIE9TIGRvZXMgbm90IGhhdmUgdGhhdCBj YXBhYmlsaXR5LiAgRG9lcyBJT1MtWFIgPyAgQnJvY2FkZSA/ICBvdGhlcnMgPw0KDQpDaXNjbyBh bmQgSnVuaXBlciBzdXBwb3J0IG1hdGNoaW5nIG9uIGlucHV0IGludGVyZmFjZS4gSXQgaXMgdXNl ZnVsIHdoZW4geW91IHdhbnQgdG8gZmlsdGVyIG9uIGdlbmVyYWwgdHJhZmZpYyBjb21pbmcgZnJv bSBpbnRlcmZhY2UuDQoNCkNpc2NvDQptYXRjaCBpbnB1dC1pbnRlcmZhY2UNCm1hdGNoIGlucHV0 LXZsYW4NCg0KVGhlc2UgYXJlIOKAnGNsYXNzLW1hcOKAnSAgc3ViLWNvbW1hbmRzIC0gbm90IOKA nGFjY2Vzcy1saXN0IiBzdWItY29tbWFuZHMuIFNvIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBn ZW5lcmFsIGZ1bmN0aW9uYWxpdHkgcmF0aGVyIHRoYW4gc3BlY2lmaWNhbGx5IGZ1bmN0aW9uYWxp dHkgc3VwcG9ydGVkIGJ5IGFjY2Vzcy1saXN0Pw0KDQpBY2NvcmRpbmcgdG8gdGhlIENpc2NvIHdl YnNpdGUgKGh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9zd2l0Y2hlcy9sYW4v Y2F0YWx5c3QzNzUweF8zNTYweC9zb2Z0d2FyZS9yZWxlYXNlLzEyLTJfNTVfc2UvY29uZmlndXJh dGlvbi9ndWlkZS8zNzUweHNjZy9zd2FjbC5odG1sKQ0KDQpOb3RlIFRoZSBBQ0wgbXVzdCBiZSBh biBleHRlbmRlZCBuYW1lZCBBQ0wuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQoNCuKAkyBtYXRjaCBpbnB1dC1pbnRlcmZhY2UgaW50ZXJmYWNlLWlkLWxpc3QNCg0K4oCTIG1h dGNoIGlwIGRzY3AgZHNjcC1saXN0DQoNCuKAkyBtYXRjaCBpcCBwcmVjZWRlbmNlIGlwLXByZWNl ZGVuY2UtbGlzdA0KDQpJZiB5b3UgY3V0IHRoZSBsaW5lIGFib3ZlIHRoaXMgeW914oCZZCBzZWUg dGhlc2UgYXJlIGNsYXNzLW1hcCBjb21tYW5kcyBhcyBJIHN0YXRlZCBwcmV2aW91c2x5Lg0KDQoN CiAgICBXaXRoIElQdjQgUW9TIEFDTHMsIGlmIHlvdSBlbnRlciB0aGUgY2xhc3MtbWFwIHsgbWF0 Y2gtYWxsIHwgbWF0Y2gtYW55IH0gY2xhc3MtbWFwLW5hbWUgZ2xvYmFsIGNvbmZpZ3VyYXRpb24g Y29tbWFuZCwgeW91IGNhbiBlbnRlciB0aGVzZSBtYXRjaCBjb21tYW5kczoNCg0KICAgICAgICAg 4oCTIG1hdGNoIGFjY2Vzcy1ncm91cCBhY2wtbmFtZQ0KDQogICAgICAgICAgICBOb3RlIFRoZSBB Q0wgbXVzdCBiZSBhbiBleHRlbmRlZCBuYW1lZCBBQ0wuDQoNCiAgICAgICAgIOKAkyBtYXRjaCBp bnB1dC1pbnRlcmZhY2UgaW50ZXJmYWNlLWlkLWxpc3QNCg0KICAgICAgICAg4oCTIG1hdGNoIGlw IGRzY3AgZHNjcC1saXN0DQoNCiAgICAgICAgIOKAkyBtYXRjaCBpcCBwcmVjZWRlbmNlIGlwLXBy ZWNlZGVuY2UtbGlzdA0KDQogICAgWW91IGNhbm5vdCBlbnRlciB0aGUgbWF0Y2ggYWNjZXNzLWdy b3VwIGFjbC1pbmRleCBjb21tYW5kLg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkp1bm9zDQpmYW1pbHkgYW55IHsNCmZpbHRlciBMMl9maWx0ZXIgew0KdGVybSB0MSB7DQpm cm9tIHsNCmludGVyZmFjZSBmZS0wLzAvMC4wOw0KfQ0KdGhlbiB7DQpwb2xpY2VyIHAxOw0KY291 bnQgYzE7DQp9DQp9DQp9DQp9DQoNCkJyb2NhZGUgc3VwcG9ydHMgbWF0Y2hpbmcgYmFzZWQgb24g aW50ZXJmYWNlLCBEZWxsIHN1cHBvcnRzIFZMQU4gbWF0Y2hpbmcsIEFyaXN0YSBzdXBwb3J0cyBp bnB1dCBpbnRlcmZhY2UgbWF0Y2hpbmcsIFJlZGJhY2sgc3VwcG9ydHMgbWF0Y2hpbmcgYWdhaW5z dCBpbnB1dCBpbnRlcmZhY2UgZm9yIGxvZ2dpbmcsDQoNCklmIHlvdSBhcmUgcmVmZXJyaW5nIHRv IOKAnGxvZy1pbnB1dOKAnSwgdGhpcyBpbmRpY2F0ZXMgdG8gaW5jbHVkZSB0aGUgaW5wdXQtaW50 ZXJmYWNlIGluIHRoZSBsb2cgbWVzc2FnZS4gQ2lzY28gc3VwcG9ydHMgdGhpcyBhcyB3ZWxsLg0K DQpUaGFua3MsDQpBY2VlDQoNCg0Kc28gaXQgaXMgcHJldHR5IHN0YW5kYXJkIGFjcm9zcyBtdWx0 aXBsZSB2ZW5kb3JzDQoNCkRlYW4NCg0KICAgICBJZiBzb21lIG1ham9yIGltcGxlbWVudGF0aW9u cyBkb27igJl0IGRvIGl0LCBhbmQgaXQgaXNu4oCZdCBuZWNlc3NhcnkgZm9yIHR5cGljYWwgYmFz aWMgQUNMIHVzZSwgdGhlbiBpdCBzaG91bGQgYmUgcmVtb3ZlZCAob3IgZmVhdHVyZSBmbGFnZ2Vk KS4NCg0KUmVnYXJkcywNCkphc29uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQoNCg0K --_000_D325357456730aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1343770D34E7F04A8029E65F8CBB5ADA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGkgRGVhbiwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7 IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkct TEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNv bGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RGVhbiBCb2dkYW5vdmljICZs dDs8YSBocmVmPSJtYWlsdG86aXZhbmRlYW5AZ21haWwuY29tIj5pdmFuZGVhbkBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+ U2F0dXJkYXksIEFwcmlsIDIsIDIwMTYgYXQgNzozOSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86 YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDtTdGVybmUsIEphc29uIChOb2tpYSAt IENBKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20iPmph c29uLnN0ZXJuZUBub2tpYS5jb208L2E+Jmd0OywgbmV0bW9kIFdHICZsdDs8YSBocmVmPSJtYWls dG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIFJlbW92 ZSBpbnB1dC1pbnRlcmZhY2UgKG1ldGFkYXRhKSBmcm9tIG5ldG1vZC1hY2wtbW9kZWwtMDcgPzxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpIaSBBY2VlLA0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiBNYXIgMzEsIDIwMTYsIGF0IDg6MTcgQU0sIEFjZWUgTGluZGVtIChhY2Vl KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiBjbGFzcz0iIj5hY2VlQGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSBEZWFuLCZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9u dC1zaXplOiAxMXB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBib3JkZXItd2lkdGg6IDFwdCBtZWRpdW0g bWVkaXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgcGFkZGluZzogM3B0IDBpbiAw aW47IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPkZyb206IDwvc3Bhbj5uZXRtb2Qg Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGVhbiBCb2dkYW5vdmlj ICZsdDs8YSBocmVmPSJtYWlsdG86aXZhbmRlYW5AZ21haWwuY29tIiBjbGFzcz0iIj5pdmFuZGVh bkBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIiBjbGFzcz0iIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1hcmNoIDMxLCAyMDE2IGF0 IDU6MjYgQU08YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xh c3M9IiI+VG86IDwvc3Bhbj4mcXVvdDtTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20iIGNsYXNzPSIiPmphc29u LnN0ZXJuZUBub2tpYS5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIiBjbGFzcz0iIj5DYzogPC9zcGFuPm5ldG1vZCBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+U3Vi amVjdDogPC9zcGFuPlJlOiBbbmV0bW9kXSBSZW1vdmUgaW5wdXQtaW50ZXJmYWNlIChtZXRhZGF0 YSkgZnJvbSBuZXRtb2QtYWNsLW1vZGVsLTA3ID88YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7IiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTWFyIDMw LCAyMDE2LCBhdCA5OjM2IFBNLCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmphc29uLnN0ZXJuZUBub2tpYS5jb20iIGNsYXNzPSIiPmphc29uLnN0ZXJuZUBu b2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIi IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgYWxsLDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIEFDTCBtb2RlbCBpcyBjb252 ZXJnaW5nIG9uIGEgc21hbGwgY29yZSBzZXQgb2YgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIGZhaXJs eSBjb21tb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5CdXQgSSB0aGluayB0aGUgbWF0Y2hpbmcgb24gaW5wdXQtaW50ZXJmYWNlIHNob3VsZCBiZSBy ZW1vdmVkIGZyb20gdGhlIG1vZGVsIChvciBhdCB0aGUgbGVhc3QgcHV0IGluc2lkZSBhIGZlYXR1 cmUgZmxhZykuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5NYXRjaGluZyBvbiBiYXNpYyBJUHY0L0lQdjQvTUFDIGhlYWRlciBmaWVsZHMgaXMgY29tbW9u IGZ1bmN0aW9uYWxpdHkuJm5ic3A7IEJ1dCBoYXZpbmcgdGhhdCBpbnB1dC1pbnRlcmZhY2UgbWF0 Y2ggb24gbWV0YWRhdGEgaW4gdGhlIGNvcmUgbW9kZWwgaXMgb3V0IG9mIHBsYWNlLiZuYnNwOyBJ dCBzaG91bGQgYmUgbGVmdCB0byBmdXJ0aGVyIGV4dGVuc2lvbiBkcmFmdHMgb3IgdmVuZG9yIHNw ZWNpZmljIGF1Z21lbnRhdGlvbnMgKGFsb25nDQogd2l0aCB3aGF0ZXZlciBvdGhlciBtZXRhZGF0 YSBtaWdodCBiZSB1c2VmdWwgb3IgdmVuZG9yLXNwZWNpZmljKS48L2Rpdj4NCjwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiIgc3R5bGU9ImZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QUNM cyBhcmUgdHlwaWNhbGx5IGFzc2lnbmVkIHRvIGludGVyZmFjZXMgYXMgc2hvd24gaW4gc2VjdGlv biBBLjMuIG9mIHRoZSBBQ0wgZHJhZnQuJm5ic3A7Jm5ic3A7IFRoYXQgaXMgdGhlIG1vc3QgY29t bW9uIHVzZSBjYXNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+QWN0dWFsbHkgbWF0Y2hpbmcgb24gaW5wdXQtaW50ZXJmYWNlIGluIHRoZSBBQ0wgcnVs ZXMgdGhlbXNlbHZlcyBpcyBub3QgYmFzaWMgY29yZSBBQ0wgZnVuY3Rpb25hbGl0eS4mbmJzcDsg Tm9raWEgU1IgT1MgZG9lcyBub3QgaGF2ZSB0aGF0IGNhcGFiaWxpdHkuJm5ic3A7IERvZXMgSU9T LVhSID8mbmJzcDsgQnJvY2FkZSA/Jm5ic3A7IG90aGVycyA/PC9kaXY+DQo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Q2lzY28gYW5kIEp1bmlwZXIgc3VwcG9ydCBtYXRjaGluZyBvbiBp bnB1dCBpbnRlcmZhY2UuIEl0IGlzIHVzZWZ1bCB3aGVuIHlvdSB3YW50IHRvIGZpbHRlciBvbiBn ZW5lcmFsIHRyYWZmaWMgY29taW5nIGZyb20gaW50ZXJmYWNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2lzY288L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+bWF0Y2ggaW5wdXQtaW50ZXJmYWNlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPm1hdGNo IGlucHV0LXZsYW48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9zcGFuPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhlc2UgYXJlIOKAnGNsYXNzLW1hcOKAnSAmbmJzcDtzdWItY29tbWFuZHMg LSBub3Qg4oCcYWNjZXNzLWxpc3QmcXVvdDsgc3ViLWNvbW1hbmRzLiBTbyB5b3UgYXJlIHJlZmVy cmluZyB0byB0aGUgZ2VuZXJhbCBmdW5jdGlvbmFsaXR5IHJhdGhlciB0aGFuIHNwZWNpZmljYWxs eSBmdW5jdGlvbmFsaXR5IHN1cHBvcnRlZCBieSBhY2Nlc3MtbGlzdD8mbmJzcDs8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K QWNjb3JkaW5nIHRvIHRoZSBDaXNjbyB3ZWJzaXRlICg8YSBocmVmPSJodHRwOi8vd3d3LmNpc2Nv LmNvbS9jL2VuL3VzL3RkL2RvY3Mvc3dpdGNoZXMvbGFuL2NhdGFseXN0Mzc1MHhfMzU2MHgvc29m dHdhcmUvcmVsZWFzZS8xMi0yXzU1X3NlL2NvbmZpZ3VyYXRpb24vZ3VpZGUvMzc1MHhzY2cvc3dh Y2wuaHRtbCIgY2xhc3M9IiI+aHR0cDovL3d3dy5jaXNjby5jb20vYy9lbi91cy90ZC9kb2NzL3N3 aXRjaGVzL2xhbi9jYXRhbHlzdDM3NTB4XzM1NjB4L3NvZnR3YXJlL3JlbGVhc2UvMTItMl81NV9z ZS9jb25maWd1cmF0aW9uL2d1aWRlLzM3NTB4c2NnL3N3YWNsLmh0bWw8L2E+KTxiciBjbGFzcz0i Ij4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgbWFyZ2luOiAwcHggMHB4IDBweCAwLjc1aW47 IHRleHQtaW5kZW50OiAtMC40aW47IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPk5vdGU8L2I+Jm5i c3A7VGhlIEFDTCBtdXN0IGJlIGFuIGV4dGVuZGVkIG5hbWVkIEFDTC48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDEzcHg7IiBjbGFzcz0iIj4NCjxociBjbGFzcz0iTm90ZTMiIHN0eWxlPSJtYXJnaW4tbGVmdDog MC43NWluOyBtYXJnaW4tcmlnaHQ6IDBlbTsgbWFyZ2luLXRvcDogNXB4OyB0ZXh0LWluZGVudDog MGVtOyBib3JkZXItc3R5bGU6IHNvbGlkOyBib3JkZXItY29sb3I6IHJnYigxMjgsIDEyOCwgMTI4 KTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDE3MCwgMTcwLCAxNzApOyI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDEzcHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVy Ij4NCjwvZGl2Pg0KPHAgY2xhc3M9InBCdTJfQnVsbGV0MiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBsaXN0LXN0eWxlLXR5cGU6IG5vbmU7IG1hcmdp bjogMHB4IDBweCA3cHggMC41NWluOyB0ZXh0LWluZGVudDogLTAuM2luOyI+DQo8YSBuYW1lPSJw Z2ZJZC0xNjA4Mzk2IiBjbGFzcz0iIj48L2E+4oCTPGltZyBhbHQ9IiIgd2lkdGg9IjE5IiBoZWln aHQ9IjIiIGJvcmRlcj0iMCIgc3R5bGU9ImJvcmRlcjogMHB4OyIgYXBwbGUtaW5saW5lPSJ5ZXMi IGlkPSJDQzdBRDJGRS00OUQwLTRGMUItOEYyQi00RTU4MEZDOENBNDgiIGFwcGxlLXdpZHRoPSJ5 ZXMiIGFwcGxlLWhlaWdodD0ieWVzIiBzcmM9ImNpZDpBODdFRDI5MS1CNzAwLTQ2OTYtOTZGQS1D OTZFMUY0MTE2MkMiIGNsYXNzPSIiPiZuYnNwOzxiIGNsYXNzPSJjQm9sZCI+bWF0Y2gNCiBpbnB1 dC1pbnRlcmZhY2U8L2I+Jm5ic3A7PGVtIGNsYXNzPSJjRW1waGFzaXMiPmludGVyZmFjZS1pZC1s aXN0PC9lbT48c3BhbiBzdHlsZT0ibWFyZ2luLWxlZnQ6IC0wLjVlbTsiIGNsYXNzPSIiPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0icEJ1Ml9CdWxsZXQyIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGxpc3Qtc3R5bGUtdHlwZTogbm9uZTsgbWFyZ2luOiAw cHggMHB4IDdweCAwLjU1aW47IHRleHQtaW5kZW50OiAtMC4zaW47Ij4NCjxhIG5hbWU9InBnZklk LTE2MDgzOTciIGNsYXNzPSIiPjwvYT7igJM8aW1nIGFsdD0iIiB3aWR0aD0iMTkiIGhlaWdodD0i MiIgYm9yZGVyPSIwIiBzdHlsZT0iYm9yZGVyOiAwcHg7IiBhcHBsZS1pbmxpbmU9InllcyIgaWQ9 Ijc1OUNBREQxLTFGMkUtNDY1Ri04QTQ5LUI0REIxOEEzMEU5NCIgYXBwbGUtd2lkdGg9InllcyIg YXBwbGUtaGVpZ2h0PSJ5ZXMiIHNyYz0iY2lkOkE4N0VEMjkxLUI3MDAtNDY5Ni05NkZBLUM5NkUx RjQxMTYyQyIgY2xhc3M9IiI+Jm5ic3A7PGIgY2xhc3M9ImNCb2xkIj5tYXRjaA0KIGlwIGRzY3A8 L2I+Jm5ic3A7PGVtIGNsYXNzPSJjRW1waGFzaXMiPmRzY3AtbGlzdDwvZW0+PHNwYW4gc3R5bGU9 Im1hcmdpbi1sZWZ0OiAtMC41ZW07IiBjbGFzcz0iIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InBC dTJfQnVsbGV0MiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmOyBsaXN0LXN0eWxlLXR5cGU6IG5vbmU7IG1hcmdpbjogMHB4IDBweCA3cHggMC41NWluOyB0 ZXh0LWluZGVudDogLTAuM2luOyI+DQo8YSBuYW1lPSJwZ2ZJZC0xNjA4Mzk4IiBjbGFzcz0iIj48 L2E+4oCTPGltZyBhbHQ9IiIgd2lkdGg9IjE5IiBoZWlnaHQ9IjIiIGJvcmRlcj0iMCIgc3R5bGU9 ImJvcmRlcjogMHB4OyIgYXBwbGUtaW5saW5lPSJ5ZXMiIGlkPSJGNTdENDhBNi1GMkRGLTQzNkMt OEE5My0yODhBRUM5QjJDREQiIGFwcGxlLXdpZHRoPSJ5ZXMiIGFwcGxlLWhlaWdodD0ieWVzIiBz cmM9ImNpZDpBODdFRDI5MS1CNzAwLTQ2OTYtOTZGQS1DOTZFMUY0MTE2MkMiIGNsYXNzPSIiPiZu YnNwOzxiIGNsYXNzPSJjQm9sZCI+bWF0Y2gNCiBpcCBwcmVjZWRlbmNlPC9iPiZuYnNwOzxlbSBj bGFzcz0iY0VtcGhhc2lzIj5pcC1wcmVjZWRlbmNlLWxpc3Q8L2VtPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIj5JZiB5b3UgY3V0IHRoZSBsaW5lIGFib3ZlIHRoaXMgeW914oCZ ZCBzZWUgdGhlc2UgYXJlJm5ic3A7PGI+Y2xhc3MtbWFwDQo8L2I+Y29tbWFuZHMgYXMmbmJzcDtJ IHN0YXRlZCBwcmV2aW91c2x5LiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5i c3A7IFdpdGggSVB2NCBRb1MgQUNMcywgaWYgeW91IGVudGVyIHRoZSA8Yj5jbGFzcy1tYXAgeyBt YXRjaC1hbGwgfCBtYXRjaC1hbnkgfQ0KPC9iPmNsYXNzLW1hcC1uYW1lIGdsb2JhbCBjb25maWd1 cmF0aW9uIGNvbW1hbmQsIHlvdSBjYW4gZW50ZXIgdGhlc2UgPGI+bWF0Y2g8L2I+IGNvbW1hbmRz OjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO+KAkyA8Yj5tYXRjaCBhY2Nlc3MtZ3JvdXA8L2I+IGFjbC1uYW1lPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBOb3RlIFRoZSBBQ0wgbXVzdCBiZSBhbiBleHRlbmRlZCBuYW1lZCBBQ0wuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A74oCTPGI+IG1hdGNoIGlucHV0LWludGVyZmFjZTwvYj4gaW50ZXJmYWNlLWlkLWxpc3Q8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDvigJMgPGI+bWF0Y2ggaXAgZHNjcDwvYj4gZHNjcC1saXN0PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCTIDxiPm1h dGNoIGlwIHByZWNlZGVuY2U8L2I+IGlwLXByZWNlZGVuY2UtbGlzdDwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyBZb3UgY2Fubm90IGVudGVyIHRoZSA8Yj5tYXRj aCBhY2Nlc3MtZ3JvdXA8L2I+IGFjbC1pbmRleCBjb21tYW5kLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClRoYW5r cyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkFjZWU8L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8cCBjbGFzcz0icEJ1Ml9CdWxsZXQyIiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGxpc3Qtc3R5bGUt dHlwZTogbm9uZTsgbWFyZ2luOiAwcHggMHB4IDdweCAwLjU1aW47IHRleHQtaW5kZW50OiAtMC4z aW47Ij4NCjxzcGFuIHN0eWxlPSJtYXJnaW4tbGVmdDogLTAuNWVtOyIgY2xhc3M9IiI+PC9zcGFu PjwvcD4NCjxkaXYgY2xhc3M9IiI+PGVtIGNsYXNzPSJjRW1waGFzaXMiPjxiciBjbGFzcz0iIj4N CjwvZW0+PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1z aXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBB RERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SnVub3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPmZhbWlseSBh bnkgezwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5maWx0ZXIgTDJfZmlsdGVyIHs8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlIj48L3NwYW4+dGVybSB0MSB7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmZyb20gezwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5pbnRlcmZhY2UgZmUtMC8wLzAuMDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+fTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFi LXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj50aGVuIHs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+cG9saWNlciBwMTs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+Y291bnQgYzE7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPn08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+fTwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0 ZS1zcGFjZTpwcmUiPjwvc3Bhbj59PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPn08L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJyb2NhZGUgc3Vw cG9ydHMgbWF0Y2hpbmcgYmFzZWQgb24gaW50ZXJmYWNlLCBEZWxsIHN1cHBvcnRzIFZMQU4gbWF0 Y2hpbmcsIEFyaXN0YSBzdXBwb3J0cyBpbnB1dCBpbnRlcmZhY2UgbWF0Y2hpbmcsIFJlZGJhY2sg c3VwcG9ydHMgbWF0Y2hpbmcgYWdhaW5zdCBpbnB1dCBpbnRlcmZhY2UgZm9yIGxvZ2dpbmcsPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9zcGFuPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SWYgeW91IGFyZSByZWZlcnJpbmcgdG8g4oCcbG9nLWlucHV04oCdLCB0aGlzIGluZGlj YXRlcyB0byBpbmNsdWRlIHRoZSBpbnB1dC1pbnRlcmZhY2UgaW4gdGhlIGxvZyBtZXNzYWdlLiBD aXNjbyBzdXBwb3J0cyB0aGlzIGFzIHdlbGwuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xp ZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPnNvIGl0IGlzIHByZXR0eSBzdGFuZGFyZCBhY3Jvc3MgbXVsdGlwbGUgdmVuZG9y czwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+RGVhbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHNvbWUgbWFqb3IgaW1wbGVtZW50YXRpb25z IGRvbuKAmXQgZG8gaXQsIGFuZCBpdCBpc27igJl0IG5lY2Vzc2FyeSBmb3IgdHlwaWNhbCBiYXNp YyBBQ0wgdXNlLCB0aGVuIGl0IHNob3VsZCBiZSByZW1vdmVkIChvciBmZWF0dXJlIGZsYWdnZWQp LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVnYXJk cyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SmFzb248c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0K PC9zcGFuPjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ bmV0bW9kDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5uZXRtb2RA aWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D325357456730aceeciscocom_-- --_004_D325357456730aceeciscocom_ Content-Type: image/gif; name="blank.gif" Content-Description: blank.gif Content-Disposition: attachment; filename="blank.gif"; size=43; creation-date="Sat, 02 Apr 2016 12:42:21 GMT"; modification-date="Sat, 02 Apr 2016 12:42:21 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhAgACAIAAAP///wAAACH5BAEAAAAALAAAAAACAAIAAAIChFEAOw== --_004_D325357456730aceeciscocom_-- From nobody Mon Apr 4 04:50:22 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3712D5B4; Mon, 4 Apr 2016 04:50:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404115017.15630.93807.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 04:50:17 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:50:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Model Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-01.txt Pages : 9 Date : 2016-04-04 Abstract: The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish models of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG models. A consistent terminology would help with the categorization of models, assist in the analysis the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG-related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 4 07:54:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3FC12D790 for ; Mon, 4 Apr 2016 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8DKImGi0jlr for ; Mon, 4 Apr 2016 07:54:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D452A12D785 for ; Mon, 4 Apr 2016 07:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3sy7xFURWsf57DcUJ85XSG8PQ+ho6AuvMokdk7UMsVc=; b=iobw8iLAPjaSWwaJmONAFwdq/W2td5Jr/c8loXVj6ByLVH0ujs7YMebvaX2CuHzf7fGrV32YPW2hg8pFLyahIuHfH9jF066MCwT2AJXC0l7waquE/a4CdUNg+CqBaOfDL+bwdbRHlMguEdnYYBJ7xhw1edn6DyyylBvYx4oCjEk= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 4 Apr 2016 14:54:08 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0447.027; Mon, 4 Apr 2016 14:54:08 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: kw review of draft-liu-netmod-yang-schedule Thread-Index: AQHRjoHX/KUnGqB1j0+ZVGgEbqY4Mg== Date: Mon, 4 Apr 2016 14:54:08 +0000 Message-ID: <8DC36161-54BC-435B-B8BA-AA72A153451F@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: e9852023-749a-4455-57dd-08d35c98f9ca x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 5:Gz+tjJ96tJaEx2+UtU/4Vl3lCN48Gv3zyT+sLBomp9Re1S3GUVjwkhE9L6mLzUyN0PdqNP1heLZUNMyU9D9Odd0ulHJ7XXB+EoS8F4psGiflOVzGjMhd7uyuPwP6phePa8TC1p1e0EH4jRtRkZ6OHg==; 24:EX4yxHpv0kBLTrTMDC6Vd3rRyPQE/qoHe/f/fuzQB60Llp60Vgbm8qRMYK7gmotZNsvn8dkoBDgmyd2wFtBVGPl+XRtOoAMGtGRYKEq65Ns= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 0902222726 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(3280700002)(77096005)(15975445007)(122556002)(2501003)(54356999)(2906002)(5002640100001)(16236675004)(6116002)(33656002)(586003)(102836003)(10400500002)(3846002)(1730700002)(50986999)(83716003)(2900100001)(83506001)(230783001)(450100001)(5004730100002)(81166005)(3660700001)(5640700001)(110136002)(107886002)(92566002)(189998001)(11100500001)(19580395003)(5008740100001)(86362001)(36756003)(4001350100001)(66066001)(229853001)(82746002)(1096002)(106116001)(1220700001)(2351001)(87936001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8DC3616154BC435BB8BAAA72A153451Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2016 14:54:08.3850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Subject: [netmod] kw review of draft-liu-netmod-yang-schedule X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:54:43 -0000 --_000_8DC3616154BC435BB8BAAA72A153451Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpbQXMgYSBjb250cmlidXRvcl0NCg0KV2hpbGUgaXQncyBjbGVhciB3aGF0IHRoaXMgZG9jdW1l bnQgaXMgdHJ5aW5nIHRvIGFjaGlldmUgYXQgYSBoaWdoIGxldmVsLCBpdCBpcyB1bmNsZWFyIHdo eSB0aGUgc29sdXRpb24gaXMgbmVlZGVkLiAgIEEgIm1vdGl2YXRpb24iIHNlY3Rpb24gZXhwbGFp bmluZyB3aHkgdGhpcyBzaG91bGQgYmUgc3RhbmRhcmRpemVkIHdvdWxkIGJlIG5pY2UuDQoNCldo ZW4gcmVhZGluZyB0aGlzIGRyYWZ0LCBJIHdhcyByZW1pbmRlZCBvZiBteSBsb25nIGV4cGlyZWQg ZHJhZnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tY29uZGl0aW9u YWwtZW5hYmxlbWVudC0wMC4gIFRoYXQgZHJhZnQgcHJvdmlkZWQgYSBtb3JlIGdlbmVyYWwgc29s dXRpb24sIGluIHRoYXQgaXQgZW5hYmxlZCBzdWItdHJlZXMgdG8gYmUgZW5hYmxlZC9kaXNhYmxl ZCBmb3IgYW55IHJlYXNvbi4gIEl0IHdhcyBwcmltYXJpbHkgZm9jdXNlZCBvbiBzdXBwb3J0aW5n IGNvbW1lbnRzLCBidXQgaXQgZGlkIGNhbGwgb3V0IHRoYXQgZXhwcmVzc2lvbnMgY291bGQgaW5j bHVkZSB0aW1lLCB0aG91Z2ggaXQgZGlkbid0IGZsdXNoIG91dCB0aGF0IHRob3VnaHQgdG8gYW55 IGV4dGVudC4NCg0KT3RoZXIgdGhhbiBkcmFmdC1rd2F0c2VuLWNvbmRpdGlvbmFsLWVuYWJsZW1l bnQgYmVpbmcgYSBtb3JlIGdlbmVyaWMgc29sdXRpb24sIGFub3RoZXIgZGlmZmVyZW5jZSBpcyB0 aGF0IHRoaXMgZHJhZnQgZW5hYmxlcyB0aGUgbW9kdWxlLWRlc2lnbmVyIHRvIHNwZWNpZnkgd2hl cmUgaW4gdGhlIGRhdGEgbW9kZWwgdGhlIGdyb3VwaW5nIGlzIHVzZWQsIHdoZXJlYXMgbXkgb2xk IGRyYWZ0IGxldCB0aGUgY2xpZW50IGVuYWJsZWQvZGlzYWJsZWQgbm9kZXMgYW55d2hlcmUgaW4g dGhlIGRhdGEgbW9kZWwsIHBvdGVudGlhbGx5IHByb2R1Y2luZyBub25zZW5zaWNhbCByZXN1bHRz LCB0aG91Z2ggd2UgaGF2ZSB0byBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdvdWxkIGZhaWwgYW55 IGludmFsaWQgcmVzdWx0cy4NCg0KUmVnYXJkaW5nIHRoaXMgc29sdXRpb24sIEkgaGF2ZSBzb21l IHNwZWNpZmljIHF1ZXN0aW9uczoNCg0KMSkgd2h5IGlzIHRoZSAic2NoZWR1bGUiIG5vZGUgYSBs aXN0PyAgSG93IGlzIGEgbGlzdCB0byBiZSBwcm9jZXNzZWQ/ICAgQXJlIHRoZXJlIGFueSBvdmVy bGFwcGluZyBpc3N1ZXM/DQoNCjIpIGRvZXMgdGhlICJzY2hlZHVsZS1pZCIgbGVhZiBoYXZlIGFu eSB1c2VmdWwgcHVycG9zZSBvdGhlciB0aGFuIGJlaW5nIHRoZSBsaXN0J3Mga2V5Pw0KDQozKSB0 aGUgInNjaGVkdWxlLWR1cmF0aW9uIiBub2RlJ3MgcGF0dGVybiBtYXRjaGVzIFhTRCdzICJkdXJh dGlvbiIgdHlwZSwgaXMgaXQgdGhlIGludGVudCB0byBwcm9jZXNzIGl0IGFzIHN1Y2g/DQoNCjQp IHRoZSBkcmFmdC1pZXRmLW5ldGNvbmYtc2VydmVyLW1vZGVsIGRyYWZ0IG9yaWdpbmFsbHkgaGFk IGEgZHVyYXRpb24tbGlrZSB2YWx1ZSwgYnV0IHRoZSBXRyBjb25zZW5zdXMgd2FzIGF0IHRoZSB0 aW1lIHdhcyB0byBpbnN0ZWFkIHVzZSBhbiB1bnNpZ25lZCBpbnRlZ2VyIHZhbHVlIHdpdGggYSAi dW5pdHMiIHZhbHVlIChlLmcuLCBzZWNvbmRzLCBtaW51dGVzLCBldGMuKS4gIFRoZSBjbGFpbSB3 YXMgdGhhdCwgd2hlbiBsYXJnZSB2YWx1ZXMgd2hlcmUgbmVlZGVkIChlLmcuLCAzNjAwLXNlY29u ZHMgaW5zdGVhZCBvZiAxLWhvdXIpLCB0aGF0IHRoZSBjbGllbnQgY291bGQgYWx3YXlzIGRvIHRo ZSBtYXRoLiAgQW55IHRob3VnaHRzIG9uIHRoYXQ/DQoNCjUpIGFyZSB0aGVyZSBhbnkgaXNzdWVz IHdpdGggdGhlICJyZXBlYXQtaW50ZXJ2YWwiIG5vZGU/ICBJJ20gc3BlY2lmaWNhbGx5IHRoaW5r aW5nIGFib3V0IHRoZSBpbnRlcnZhbCBiZWluZyBleHByZXNzZWQgaW4gdGVybXMgb2YgaG91cnMg YW5kIGRheXMgaW4gdGhlIGNvbnRleHQgb2YgZGF5bGlnaHQgc2F2aW5ncyBhbmQgbGVhcCB5ZWFy Li4uDQoNCg0KTml0OiBzb21lIGV4YW1wbGVzIGluIHRoZSBkcmFmdCB3b3VsZCd2ZSBiZWVuIG5p Y2UuDQoNClRoYW5rcywNCktlbnQNCg0KDQoNCg== --_000_8DC3616154BC435BB8BAAA72A153451Fjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+W0FzIGEgY29udHJpYnV0b3JdPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5XaGlsZSBpdCdzIGNsZWFyIHdoYXQgdGhpcyBkb2N1bWVudCBpcyB0cnlpbmcgdG8gYWNoaWV2 ZSBhdCBhIGhpZ2ggbGV2ZWwsIGl0IGlzIHVuY2xlYXIgd2h5IHRoZSBzb2x1dGlvbiBpcyBuZWVk ZWQuICZuYnNwOyBBICZxdW90O21vdGl2YXRpb24mcXVvdDsgc2VjdGlvbiBleHBsYWluaW5nIHdo eSB0aGlzIHNob3VsZCBiZSBzdGFuZGFyZGl6ZWQgd291bGQgYmUgbmljZS48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PldoZW4gcmVhZGluZyB0aGlzIGRyYWZ0LCBJIHdhcyByZW1pbmRl ZCBvZiBteSBsb25nIGV4cGlyZWQgZHJhZnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWt3YXRzZW4tY29uZGl0aW9uYWwtZW5hYmxlbWVudC0wMC4gJm5ic3A7VGhhdCBkcmFmdCBw cm92aWRlZCBhIG1vcmUgZ2VuZXJhbCBzb2x1dGlvbiwgaW4gdGhhdCBpdCBlbmFibGVkIHN1Yi10 cmVlcyB0byBiZSBlbmFibGVkL2Rpc2FibGVkIGZvciBhbnkgcmVhc29uLiAmbmJzcDtJdA0KIHdh cyBwcmltYXJpbHkgZm9jdXNlZCBvbiBzdXBwb3J0aW5nIGNvbW1lbnRzLCBidXQgaXQgZGlkIGNh bGwgb3V0IHRoYXQgZXhwcmVzc2lvbnMgY291bGQgaW5jbHVkZSB0aW1lLCB0aG91Z2ggaXQgZGlk bid0IGZsdXNoIG91dCB0aGF0IHRob3VnaHQgdG8gYW55IGV4dGVudC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pk90aGVyIHRoYW4gZHJhZnQta3dhdHNlbi1jb25kaXRpb25hbC1lbmFi bGVtZW50IGJlaW5nIGEgbW9yZSBnZW5lcmljIHNvbHV0aW9uLCBhbm90aGVyIGRpZmZlcmVuY2Ug aXMgdGhhdCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlIG1vZHVsZS1kZXNpZ25lciB0byBzcGVjaWZ5 IHdoZXJlIGluIHRoZSBkYXRhIG1vZGVsIHRoZSBncm91cGluZyBpcyB1c2VkLCB3aGVyZWFzIG15 IG9sZCBkcmFmdCBsZXQgdGhlIGNsaWVudCBlbmFibGVkL2Rpc2FibGVkDQogbm9kZXMgYW55d2hl cmUgaW4gdGhlIGRhdGEgbW9kZWwsIHBvdGVudGlhbGx5IHByb2R1Y2luZyBub25zZW5zaWNhbCBy ZXN1bHRzLCB0aG91Z2ggd2UgaGF2ZSB0byBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdvdWxkIGZh aWwgYW55IGludmFsaWQgcmVzdWx0cy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJl Z2FyZGluZyB0aGlzIHNvbHV0aW9uLCBJIGhhdmUgc29tZSBzcGVjaWZpYyBxdWVzdGlvbnM6PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4xKSB3aHkgaXMgdGhlICZxdW90O3NjaGVkdWxl JnF1b3Q7IG5vZGUgYSBsaXN0PyAmbmJzcDtIb3cgaXMgYSBsaXN0IHRvIGJlIHByb2Nlc3NlZD8g Jm5ic3A7IEFyZSB0aGVyZSBhbnkgb3ZlcmxhcHBpbmcgaXNzdWVzPyZuYnNwOzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+MikgZG9lcyB0aGUgJnF1b3Q7c2NoZWR1bGUtaWQmcXVvdDsg bGVhZiBoYXZlIGFueSB1c2VmdWwgcHVycG9zZSBvdGhlciB0aGFuIGJlaW5nIHRoZSBsaXN0J3Mg a2V5PzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+MykgdGhlICZxdW90O3NjaGVkdWxl LWR1cmF0aW9uJnF1b3Q7IG5vZGUncyBwYXR0ZXJuIG1hdGNoZXMgWFNEJ3MgJnF1b3Q7ZHVyYXRp b24mcXVvdDsgdHlwZSwgaXMgaXQgdGhlIGludGVudCB0byBwcm9jZXNzIGl0IGFzIHN1Y2g/PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj40KSB0aGUgZHJhZnQtaWV0Zi1uZXRjb25mLXNl cnZlci1tb2RlbCBkcmFmdCBvcmlnaW5hbGx5IGhhZCBhIGR1cmF0aW9uLWxpa2UgdmFsdWUsIGJ1 dCB0aGUgV0cgY29uc2Vuc3VzIHdhcyBhdCB0aGUgdGltZSB3YXMgdG8gaW5zdGVhZCB1c2UgYW4g dW5zaWduZWQgaW50ZWdlciB2YWx1ZSB3aXRoIGEgJnF1b3Q7dW5pdHMmcXVvdDsgdmFsdWUgKGUu Zy4sIHNlY29uZHMsIG1pbnV0ZXMsIGV0Yy4pLiAmbmJzcDtUaGUgY2xhaW0gd2FzIHRoYXQsIHdo ZW4gbGFyZ2UgdmFsdWVzDQogd2hlcmUgbmVlZGVkIChlLmcuLCAzNjAwLXNlY29uZHMgaW5zdGVh ZCBvZiAxLWhvdXIpLCB0aGF0IHRoZSBjbGllbnQgY291bGQgYWx3YXlzIGRvIHRoZSBtYXRoLiAm bmJzcDtBbnkgdGhvdWdodHMgb24gdGhhdD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PjUpIGFyZSB0aGVyZSBhbnkgaXNzdWVzIHdpdGggdGhlICZxdW90O3JlcGVhdC1pbnRlcnZhbCZx dW90OyBub2RlPyAmbmJzcDtJJ20gc3BlY2lmaWNhbGx5IHRoaW5raW5nIGFib3V0IHRoZSBpbnRl cnZhbCBiZWluZyBleHByZXNzZWQgaW4gdGVybXMgb2YgaG91cnMgYW5kIGRheXMgaW4gdGhlIGNv bnRleHQgb2YgZGF5bGlnaHQgc2F2aW5ncyBhbmQgbGVhcCB5ZWFyLi4uPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tml0OiBzb21lIGV4YW1wbGVzIGlu IHRoZSBkcmFmdCB3b3VsZCd2ZSBiZWVuIG5pY2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PktlbnQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNf T1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8DC3616154BC435BB8BAAA72A153451Fjunipernet_-- From nobody Mon Apr 4 10:48:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1096B12D13D for ; Mon, 4 Apr 2016 10:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhQknhssIHBA for ; Mon, 4 Apr 2016 10:48:27 -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 42E3A12D115 for ; Mon, 4 Apr 2016 10:48:27 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:7a:9024:c9f4:5e8] (unknown [IPv6:2001:67c:370:176:7a:9024:c9f4:5e8]) by mail.nic.cz (Postfix) with ESMTPSA id 6080A1800D0 for ; Mon, 4 Apr 2016 19:48:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459792105; bh=JSYd3U6jYUscjVOKWCqp1Gg1xRahHRZgtqrO6/V1/cU=; h=From:Date:To; b=hirk7/2GTWGx/oSamPD+S6dqVpUc+HU4auC+LeyV9WDN6AczjBTzxvunTc8qWti6A gF5DlUH2+Mu/uoBb2iZ2k9HyfnxcvM9R+nVcB7QVE6720jHP76Y3pyNNgP3y7fhvyZ h+OnxBnM3QZud7ACq3FkXih1HuWrJGU8WUwwliSY= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 4 Apr 2016 14:48:19 -0300 To: NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:48:29 -0000 Hi, in the thread [1], we agreed that it is necessary to prevent actions = (and notifications) being defined on a state data node that is (or its = ancestor is) a list for which no keys are defined because then the = instance to which the action is tied may not be uniquely defined. The = rfc6020bis-11 doesn't address this situation though. Is it still = possible to add a corresponding text to sections 7.15 and 7.16? Lada [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 4 11:31:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578A812D0B0 for ; Mon, 4 Apr 2016 11:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrIB7jDkEE9n for ; Mon, 4 Apr 2016 11:31:46 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A970D12D1DC for ; Mon, 4 Apr 2016 11:24:16 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id B93AF296FBA12 for ; Mon, 4 Apr 2016 18:24:12 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u34IOFJB020381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Apr 2016 18:24:15 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u34IOFkW024717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Apr 2016 18:24:15 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.144]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 4 Apr 2016 14:24:15 -0400 From: "Sterne, Jason (Nokia - CA)" To: netmod WG Thread-Topic: a few editorial comments on structural-mount-02 Thread-Index: AdGOny+3jLoLJd5sQjO3ttKby4mkhQ== Date: Mon, 4 Apr 2016 18:24:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CC25FEEUS70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: [netmod] a few editorial comments on structural-mount-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:31:47 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CC25FEEUS70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, A couple of minor points for the structural mount draft that I noticed whil= e reading it recently: The XML instance data in Appendix B seems to have inside the context but that doesn't match the YANG model above it. It would be great to show an example for section 3.2. Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5CC25FEEUS70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
A couple of minor points for the structural mount draft that I noticed= while reading it recently:
 
The XML instance data in Appendix B seems to have <root> inside = the <transport> context but that doesn’t match the YANG model a= bove it.
 
It would be great to show an example for section 3.2.
 
Regards,
Jason
 
 
 
 
 
 --_000_A125E53CE190A749957C19483DC79F9F5CC25FEEUS70TWXCHMBA11z_-- From nobody Mon Apr 4 11:57:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A3012D7F7 for ; Mon, 4 Apr 2016 11:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRzzoqEchikI for ; Mon, 4 Apr 2016 11:57:47 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF15212D7EF for ; Mon, 4 Apr 2016 11:57:46 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id c126so66199365lfb.2 for ; Mon, 04 Apr 2016 11:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YKSKr0JabV+IU40bra+Xp2dG1NrNNJrz5clA+z4IW/A=; b=GvuT8mvj13xiBaU9TsFpJUE1lCJyX30C45k47z8pZeVOCOA6vxaSnspYoSoeFRu6tX 6yihfWb8H5SaWT/x/XmCvqxeOL4cdwSqvY+dMrNh3ZBRlX/eBHrfjBusZgkbAQZc+h5V Onsq5WoG996PjUxlMnrJ5l1ZbDDiPJ/Ux4p8EWH7UnveChfK1KsCiWFMPI6gCVwTxSvr GLa6OmyK1EwTrfYmpd4M/F+19FqRUpQfIWMZpcnd2rNubU2zkET6IdedZRerTg7K7Bv1 lRdI+EtyO7bysQT4TJ2LMRnQoiUscNIkWfSS5fY4a6WOPIOENEBo14xRQTA4LZ0ei4ZZ K6xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YKSKr0JabV+IU40bra+Xp2dG1NrNNJrz5clA+z4IW/A=; b=ZbOfFKK8scTDRtSOcqWDEgG4cqVoj9kK8WioVI+XqTj38s+4HvRS3FoAZyogW6s7O1 GlOOZuazBal6G10lWaA3w6mviII0s8KLw2vn4LfBft6152uVaJ0iEWghStWGglmrkDH+ 51mmFgbGMxyY0h9j4WxpAH7/usQdCGckvRhl5Js83f/am5Vje8pj6q8ZQnwl8834eW2K S+9kzaamTyT8cNyqGBPgPzESmZf9wcrXjuyfXVLnlN1hw5CyO6zQyfoimRqgSsxYLoiJ tYl8hS1F73+yxHX+OfqmsYqwT4MplTSIRv/vrtwVXS2SrwoI7fNN1ye6hHKAPcOAcQXQ ugqA== X-Gm-Message-State: AD7BkJInZm+39cLbqHnlsLG27kpbktJoae/KksuOWQhV0W2X6i8FryXq7SE4wznyq1RlREGyDm5Ex9nxGvG38g== MIME-Version: 1.0 X-Received: by 10.25.78.80 with SMTP id c77mr4082738lfb.62.1459796264930; Mon, 04 Apr 2016 11:57:44 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 4 Apr 2016 11:57:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 11:57:44 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114194e4d0e31d052fad4d33 Archived-At: Cc: NETMOD WG Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:57:49 -0000 --001a114194e4d0e31d052fad4d33 Content-Type: text/plain; charset=UTF-8 Hi, I do not see any reason to prohibit this use of action-stmt or notification-stmt. If the list has no keys then there is no need to distinguish instances because the data model defines no such semantics. What breaks if this is allowed? Andy On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka wrote: > Hi, > > in the thread [1], we agreed that it is necessary to prevent actions (and > notifications) being defined on a state data node that is (or its ancestor > is) a list for which no keys are defined because then the instance to which > the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't > address this situation though. Is it still possible to add a corresponding > text to sections 7.15 and 7.16? > > Lada > > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114194e4d0e31d052fad4d33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I do not see any reason to prohibit= this use of action-stmt
or notification-stmt.=C2=A0 If the list = has no keys then there is
no need to distinguish instances becaus= e the data model defines
no such semantics.

<= div>What breaks if this is allowed?


Andy


On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <lhotka@nic.= cz> wrote:
Hi,

in the thread [1], we agreed that it is necessary to prevent actions (and n= otifications) being defined on a state data node that is (or its ancestor i= s) a list for which no keys are defined because then the instance to which = the action is tied may not be uniquely defined. The rfc6020bis-11 doesn'= ;t address this situation though. Is it still possible to add a correspondi= ng text to sections 7.15 and 7.16?

Lada

[1] https://www.ietf.org/mail-arch= ive/web/netmod/current/msg14936.html

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




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

--001a114194e4d0e31d052fad4d33-- From nobody Mon Apr 4 12:01:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B0612D823 for ; Mon, 4 Apr 2016 12:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhPSVmLhEgCQ for ; Mon, 4 Apr 2016 12:01: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 215B612D82D for ; Mon, 4 Apr 2016 12:01:14 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:c4b:a9d0:8316:210] (unknown [IPv6:2001:67c:370:176:c4b:a9d0:8316:210]) by mail.nic.cz (Postfix) with ESMTPSA id 0B17E1800E0; Mon, 4 Apr 2016 21:01:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459796472; bh=dn98Ktm5h8m0/MuznpQQhHJAiBvFZEwy7ObTG/qs4Qc=; h=From:Date:To; b=bOCV8zaB+PlMYC8/12QGTPUmiYz+ns7NlT8jQWL9k+8S4L/430i/XcA4IDEs9zm5/ +BI7vlnKpk172Se14bTzthi47jqrA7WD5WKnS6oPhJoG4/Kqelqk/yun1CeOt7qTOb pPBf4JdwTKpjK0D1Q18J6ZHhNPIqpQkkTks9Twdc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 4 Apr 2016 16:01:09 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <95F3A380-A2E6-4225-8A3A-5E01885DB8FD@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:01:43 -0000 > On 04 Apr 2016, at 15:57, Andy Bierman wrote: >=20 > Hi, >=20 > I do not see any reason to prohibit this use of action-stmt > or notification-stmt. If the list has no keys then there is > no need to distinguish instances because the data model defines > no such semantics. If such a keyless list has multiple entries, how can an action request = specify which of the list entries it is tied to? >=20 > What breaks if this is allowed? The behaviour is undefined. Lada >=20 >=20 > Andy >=20 >=20 > On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka = wrote: > Hi, >=20 > in the thread [1], we agreed that it is necessary to prevent actions = (and notifications) being defined on a state data node that is (or its = ancestor is) a list for which no keys are defined because then the = instance to which the action is tied may not be uniquely defined. The = rfc6020bis-11 doesn't address this situation though. Is it still = possible to add a corresponding text to sections 7.15 and 7.16? >=20 > Lada >=20 > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html >=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 Mon Apr 4 12:16:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D787612D804 for ; Mon, 4 Apr 2016 12:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WzAVLjTBXT1 for ; Mon, 4 Apr 2016 12:15:57 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C641812D824 for ; Mon, 4 Apr 2016 12:15:56 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id bc4so174238259lbc.2 for ; Mon, 04 Apr 2016 12:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eB13s41txDQELvjEHXeY/FmV/eht4EKTlZLp7B8Se6M=; b=QjU3M6/ATnliE5TGxw39DvzI32bZozZFqEp/lybFfxmz2sGb5LJV7W2i+zPgMUeSpq lmeXjXHXTY+hhteG5pqufM81BGTQoMIossyjB6jIZHyKrrvLY5l1iN4M07IlRVrtzN7N a+cZG+BXHekXVH7JY1toX/l2mnXjBCT5C54SLHr/XFoDfgdRbjah4gpn0J9ek1sNgDtS Nyx4Bl2YXTyxvXlPGEFzhh1XZM5mRViz06VyeuL7aIOALaUOmsckND6ihGCe0LenzkjO 2aMsu/0ypaBNXqbdSqzMFNenZziIldA8Y+7MrF70elI6jjT3Btm5Cmnyh3JMvFRfpokc fxvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eB13s41txDQELvjEHXeY/FmV/eht4EKTlZLp7B8Se6M=; b=iT1HedsxKMn7VjNLyLW9mKKmqnHBjdmhHAYmAVowiLPxqvxYc4dC8EA2ohhQ6i0pE/ 1hhhibmxQ9ld93rHpsRA3Rtdei2/L+0twekHewwG+CmD1//tH6iaX6wSWS4dlodBuf6s /5nssGUMXfsz9GLopOMarnamDukut3NrMS7ynweNT/CBPyMbcDXnJWmxqMkAMZhE5rTV 426RLeRy9159kbt0NFhqcDDzUELJIhAnCf43iQctTwgCupGkE2/Zj+pODsxa/nAE+zJu YDLGCEN2M5R3vlHH2mH5zap8A2PXyjDj6ggNG9WK1mIMKSKZokQl5ex8G1N5f4hoQFwV DgBg== X-Gm-Message-State: AD7BkJJQ/+sXZZKrG77SX0FCL/fdzZEyHpFShHwIIy4LtCZ7syC2EaydB8NPCUxd0VRs7tnb5qsIiViijMfBRQ== MIME-Version: 1.0 X-Received: by 10.112.129.169 with SMTP id nx9mr9016026lbb.96.1459797354881; Mon, 04 Apr 2016 12:15:54 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 4 Apr 2016 12:15:54 -0700 (PDT) In-Reply-To: <95F3A380-A2E6-4225-8A3A-5E01885DB8FD@nic.cz> References: <95F3A380-A2E6-4225-8A3A-5E01885DB8FD@nic.cz> Date: Mon, 4 Apr 2016 12:15:54 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b3441dac8461c052fad8eb8 Archived-At: Cc: NETMOD WG Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:16:10 -0000 --047d7b3441dac8461c052fad8eb8 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: > > > On 04 Apr 2016, at 15:57, Andy Bierman wrote: > > > > Hi, > > > > I do not see any reason to prohibit this use of action-stmt > > or notification-stmt. If the list has no keys then there is > > no need to distinguish instances because the data model defines > > no such semantics. > > If such a keyless list has multiple entries, how can an action request > specify which of the list entries it is tied to? > it must be be relevant to distinguish instances or else the designer would have defined a key. > > > > > What breaks if this is allowed? > > The behaviour is undefined. > > IMO lists without keys are a really bad idea. But the semantics are fully defined according to YANG. If the list has no keys then there is no instance information relevant to the data model. The action or notification is passed all the keys (happens to be zero in this case). > Lada > Andy > > > > > > > Andy > > > > > > On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka wrote: > > Hi, > > > > in the thread [1], we agreed that it is necessary to prevent actions > (and notifications) being defined on a state data node that is (or its > ancestor is) a list for which no keys are defined because then the instance > to which the action is tied may not be uniquely defined. The rfc6020bis-11 > doesn't address this situation though. Is it still possible to add a > corresponding text to sections 7.15 and 7.16? > > > > Lada > > > > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html > > > > -- > > 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 > > > > > --047d7b3441dac8461c052fad8eb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka <lhotka@nic.cz>= wrote:

> On 04 Apr 2016, at 15:57, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> I do not see any reason to prohibit this use of action-stmt
> or notification-stmt.=C2=A0 If the list has no keys then there is
> no need to distinguish instances because the data model defines
> no such semantics.

If such a keyless list has multiple entries, how can an action request spec= ify which of the list entries it is tied to?

it must be be relevant to distinguish instances or else the designer<= /div>
would have defined a key.
=C2=A0

>
> What breaks if this is allowed?

The behaviour is undefined.



IMO lists without keys = are a really bad idea.
But the semantics are fully defined accord= ing to YANG.
If the list has no keys then there is no instance in= formation
relevant to the data model.=C2=A0 The action or notific= ation is passed
all the keys (happens to be zero in this case).


=C2=A0
Lada


Andy
=C2= =A0

>
>
> Andy
>
>
> On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi,
>
> in the thread [1], we agreed that it is necessary to prevent actions (= and notifications) being defined on a state data node that is (or its ances= tor is) a list for which no keys are defined because then the instance to w= hich the action is tied may not be uniquely defined. The rfc6020bis-11 does= n't address this situation though. Is it still possible to add a corres= ponding text to sections 7.15 and 7.16?
>
> Lada
>
> [1] https://www.ietf.org/mail= -archive/web/netmod/current/msg14936.html
>
> --
> 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





--047d7b3441dac8461c052fad8eb8-- From nobody Mon Apr 4 12:32:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F1A12D838 for ; Mon, 4 Apr 2016 12:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j7qZC2XQJgA for ; Mon, 4 Apr 2016 12:32:10 -0700 (PDT) Received: from rc-edge-01.assia-inc.com (rc-edge-01.assia-inc.com [12.180.103.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3DD12D7A6 for ; Mon, 4 Apr 2016 12:32:10 -0700 (PDT) Received: from RC-MAIL-01.assia-inc.local (172.17.0.46) by rc-edge-01.assia-inc.com (172.17.0.67) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 4 Apr 2016 12:32:05 -0700 Received: from RC-MAIL-01.assia-inc.local ([fe80::f469:7fc:86c9:1f02]) by rc-mail-01.assia-inc.local ([fe80::f469:7fc:86c9:1f02%10]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 12:32:07 -0700 From: "Kenneth Kerpez (New Jersey)" To: "netmod@ietf.org" Thread-Topic: draft-ietf-netmod-yang-model-classification-01 Thread-Index: AQHRjqis43JG0gZsC0uMTzCYsTZr9w== Date: Mon, 4 Apr 2016 19:32:06 +0000 Message-ID: <9wxv7dmwq4rp4gn9xfxsdxk1.1459797903397@email.android.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9wxv7dmwq4rp4gn9xfxsdxk11459797903397emailandroidcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: internally-submitted e-mail X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Archived-At: Subject: Re: [netmod] draft-ietf-netmod-yang-model-classification-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:32:12 -0000 --_000_9wxv7dmwq4rp4gn9xfxsdxk11459797903397emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft-ietf-netmod-yang-model-classification-01 could also consider a na= ming convention. In the Broadband Forum (BBF) we name files bbf-module-name= -submodule.yang. ietf-name.yang is common. So perhaps - is a convention. Ken Kerpez ASSIA, Inc. Cell +1 908 432-1600 Landline +1908 876-4270 -------- Original message -------- From: netmod-request@ietf.org Date: 04/04/2016 2:57 PM (GMT-05:00) To: netmod@ietf.org Subject: netmod Digest, Vol 97, Issue 5 Send netmod mailing list submissions to netmod@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/netmod or, via email, send a message with subject or body 'help' to netmod-request@ietf.org You can reach the person managing the list at netmod-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of netmod digest..." Today's Topics: 1. I-D Action: draft-ietf-netmod-yang-model-classification-01.txt (internet-drafts@ietf.org) 2. kw review of draft-liu-netmod-yang-schedule (Kent Watsen) 3. actions and keyless lists (Ladislav Lhotka) 4. a few editorial comments on structural-mount-02 (Sterne, Jason (Nokia - CA)) 5. Re: actions and keyless lists (Andy Bierman) ---------------------------------------------------------------------- Message: 1 Date: Mon, 04 Apr 2016 04:50:17 -0700 From: internet-drafts@ietf.org To: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-01.txt Message-ID: <20160404115017.15630.93807.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language of the IETF= . Title : YANG Model Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-01.tx= t Pages : 9 Date : 2016-04-04 Abstract: The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish models of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG models. A consistent terminology would help with the categorization of models, assist in the analysis the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG-related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificatio= n/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-model-classifica= tion-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ------------------------------ Message: 2 Date: Mon, 4 Apr 2016 14:54:08 +0000 From: Kent Watsen To: "netmod@ietf.org" Subject: [netmod] kw review of draft-liu-netmod-yang-schedule Message-ID: <8DC36161-54BC-435B-B8BA-AA72A153451F@juniper.net> Content-Type: text/plain; charset=3D"utf-8" [As a contributor] While it's clear what this document is trying to achieve at a high level, i= t is unclear why the solution is needed. A "motivation" section explainin= g why this should be standardized would be nice. When reading this draft, I was reminded of my long expired draft https://to= ols.ietf.org/html/draft-kwatsen-conditional-enablement-00. That draft prov= ided a more general solution, in that it enabled sub-trees to be enabled/di= sabled for any reason. It was primarily focused on supporting comments, bu= t it did call out that expressions could include time, though it didn't flu= sh out that thought to any extent. Other than draft-kwatsen-conditional-enablement being a more generic soluti= on, another difference is that this draft enables the module-designer to sp= ecify where in the data model the grouping is used, whereas my old draft le= t the client enabled/disabled nodes anywhere in the data model, potentially= producing nonsensical results, though we have to assume that the server wo= uld fail any invalid results. Regarding this solution, I have some specific questions: 1) why is the "schedule" node a list? How is a list to be processed? Are= there any overlapping issues? 2) does the "schedule-id" leaf have any useful purpose other than being the= list's key? 3) the "schedule-duration" node's pattern matches XSD's "duration" type, is= it the intent to process it as such? 4) the draft-ietf-netconf-server-model draft originally had a duration-like= value, but the WG consensus was at the time was to instead use an unsigned= integer value with a "units" value (e.g., seconds, minutes, etc.). The cl= aim was that, when large values where needed (e.g., 3600-seconds instead of= 1-hour), that the client could always do the math. Any thoughts on that? 5) are there any issues with the "repeat-interval" node? I'm specifically = thinking about the interval being expressed in terms of hours and days in t= he context of daylight savings and leap year... Nit: some examples in the draft would've been nice. Thanks, Kent -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Mon, 4 Apr 2016 14:48:19 -0300 From: Ladislav Lhotka To: NETMOD WG Subject: [netmod] actions and keyless lists Message-ID: Content-Type: text/plain; charset=3Dus-ascii Hi, in the thread [1], we agreed that it is necessary to prevent actions (and n= otifications) being defined on a state data node that is (or its ancestor i= s) a list for which no keys are defined because then the instance to which = the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't a= ddress this situation though. Is it still possible to add a corresponding t= ext to sections 7.15 and 7.16? Lada [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ------------------------------ Message: 4 Date: Mon, 4 Apr 2016 18:24:14 +0000 From: "Sterne, Jason (Nokia - CA)" To: netmod WG Subject: [netmod] a few editorial comments on structural-mount-02 Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hello, A couple of minor points for the structural mount draft that I noticed whil= e reading it recently: The XML instance data in Appendix B seems to have inside the context but that doesn't match the YANG model above it. It would be great to show an example for section 3.2. Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 4 Apr 2016 11:57:44 -0700 From: Andy Bierman To: Ladislav Lhotka Cc: NETMOD WG Subject: Re: [netmod] actions and keyless lists Message-ID: Content-Type: text/plain; charset=3D"utf-8" Hi, I do not see any reason to prohibit this use of action-stmt or notification-stmt. If the list has no keys then there is no need to distinguish instances because the data model defines no such semantics. What breaks if this is allowed? Andy On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka wrote: > Hi, > > in the thread [1], we agreed that it is necessary to prevent actions (and > notifications) being defined on a state data node that is (or its ancesto= r > is) a list for which no keys are defined because then the instance to whi= ch > the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't > address this situation though. Is it still possible to add a correspondin= g > text to sections 7.15 and 7.16? > > Lada > > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------------------------------ End of netmod Digest, Vol 97, Issue 5 ************************************* --_000_9wxv7dmwq4rp4gn9xfxsdxk11459797903397emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The draft-ietf-netmod-yang-model-classification-01 could also consider= a naming convention. In the Broadband Forum (BBF) we name files bbf-module= -name-submodule.yang. ietf-name.yang is common. So perhaps <sdo>-<= module/submodule name> is a convention.


Ken Kerpez
ASSIA, Inc.
Cell +1 908 432-1600
Landline +1908 876-4270


-------- Original message --------
From: netmod-request@ietf.org
Date: 04/04/2016 2:57 PM (GMT-05:00)
To: netmod@ietf.org
Subject: netmod Digest, Vol 97, Issue 5

Send netmod mailing list submissions to
        netmod@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/netmod or, via email, send a message with subject or body 'help' to
        netmod-request@ietf.org

You can reach the person managing the list at
        netmod-owner@ietf.org

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


Today's Topics:

   1. I-D Action:
      draft-ietf-netmod-yang-model-classification-= 01.txt
      (internet-drafts@ietf.org)
   2. kw review of draft-liu-netmod-yang-schedule (Kent Watsen)    3. actions and keyless lists (Ladislav Lhotka)
   4. a few editorial comments on structural-mount-02
      (Sterne, Jason (Nokia - CA))
   5. Re: actions and keyless lists (Andy Bierman)


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

Message: 1
Date: Mon, 04 Apr 2016 04:50:17 -0700
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: netmod@ietf.org
Subject: [netmod] I-D Action:
        draft-ietf-netmod-yang-model-cla= ssification-01.txt
Message-ID: <20160404115017.15630.93807.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the NETCONF Data Modeling Language of the IETF= .

        Title    &nb= sp;      : YANG Model Classification
        Authors    &= nbsp;    : Dean Bogdanovic
            &nb= sp;            = Benoit Claise
            &nb= sp;            = Carl Moberg
        Filename    =     : draft-ietf-netmod-yang-model-classification-01.txt
        Pages    &nb= sp;      : 9
        Date    &nbs= p;       : 2016-04-04

Abstract:
   The YANG [RFC6020] data modeling language is currently being    considered for a wide variety of applications throughout the    networking industry at large.  Many standards-defining or= ganizations
   (SDOs), open source software projects, vendors and users are u= sing
   YANG to develop and publish models of configuration, state dat= a and
   operations for a wide variety of applications.  At the sa= me time,
   there is currently no well-known terminology to categorize var= ious
   types of YANG models.

   A consistent terminology would help with the categorization of=
   models, assist in the analysis the YANG data modeling efforts = in the
   IETF and other organizations, and bring clarity to the YANG-re= lated
   discussions between the different groups.

   This document describes a set of concepts and associated terms= to
   support consistent classification of YANG models.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-mode= l-classification/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classi= fication-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-y= ang-model-classification-01


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

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



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

Message: 2
Date: Mon, 4 Apr 2016 14:54:08 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] kw review of draft-liu-netmod-yang-schedule
Message-ID: <8DC36161-54BC-435B-B8BA-AA72A153451F@juniper.net>
Content-Type: text/plain; charset=3D"utf-8"


[As a contributor]

While it's clear what this document is trying to achieve at a high level, i= t is unclear why the solution is needed.   A "motivation&quo= t; section explaining why this should be standardized would be nice.

When reading this draft, I was reminded of my long expired draft https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00.&nb= sp; That draft provided a more general solution, in that it enabled sub-tre= es to be enabled/disabled for any reason.  It was primarily focused on= supporting comments, but it did call out that expressions could include time, though it didn't flush out that thoug= ht to any extent.

Other than draft-kwatsen-conditional-enablement being a more generic soluti= on, another difference is that this draft enables the module-designer to sp= ecify where in the data model the grouping is used, whereas my old draft le= t the client enabled/disabled nodes anywhere in the data model, potentially producing nonsensical results, tho= ugh we have to assume that the server would fail any invalid results.

Regarding this solution, I have some specific questions:

1) why is the "schedule" node a list?  How is a list to be p= rocessed?   Are there any overlapping issues?

2) does the "schedule-id" leaf have any useful purpose other than= being the list's key?

3) the "schedule-duration" node's pattern matches XSD's "dur= ation" type, is it the intent to process it as such?

4) the draft-ietf-netconf-server-model draft originally had a duration-like= value, but the WG consensus was at the time was to instead use an unsigned= integer value with a "units" value (e.g., seconds, minutes, etc.= ).  The claim was that, when large values where needed (e.g., 3600-seconds instead of 1-hour), that the client could= always do the math.  Any thoughts on that?

5) are there any issues with the "repeat-interval" node?  I'= m specifically thinking about the interval being expressed in terms of hour= s and days in the context of daylight savings and leap year...


Nit: some examples in the draft would've been nice.

Thanks,
Kent



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/b= rowse/netmod/attachments/20160404/03fad290/attachment.html>

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

Message: 3
Date: Mon, 4 Apr 2016 14:48:19 -0300
From: Ladislav Lhotka <lhotka@nic.cz>
To: NETMOD WG <netmod@ietf.org>
Subject: [netmod] actions and keyless lists
Message-ID: <E50B7C98-C786-4D8E-9943-55CB952D3CDD@nic.cz>
Content-Type: text/plain; charset=3Dus-ascii

Hi,

in the thread [1], we agreed that it is necessary to prevent actions (and n= otifications) being defined on a state data node that is (or its ancestor i= s) a list for which no keys are defined because then the instance to which = the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't address this situation though. Is it st= ill possible to add a corresponding text to sections 7.15 and 7.16?

Lada

[1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html

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






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

Message: 4
Date: Mon, 4 Apr 2016 18:24:14 +0000
From: "Sterne, Jason (Nokia - CA)" <jason.sterne@nokia.com>=
To: netmod WG <netmod@ietf.org>
Subject: [netmod] a few editorial comments on structural-mount-02
Message-ID:
        <A125E53CE190A749957C19483DC7= 9F9F5CC25FEE@US70TWXCHMBA11.zam.alcatel-lucent.com>
       
Content-Type: text/plain; charset=3D"us-ascii"

Hello,

A couple of minor points for the structural mount draft that I noticed whil= e reading it recently:

The XML instance data in Appendix B seems to have <root> inside the &= lt;transport> context but that doesn't match the YANG model above it.
It would be great to show an example for section 3.2.

Regards,
Jason





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/b= rowse/netmod/attachments/20160404/f73fc059/attachment.html>

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

Message: 5
Date: Mon, 4 Apr 2016 11:57:44 -0700
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: NETMOD WG <netmod@ietf.org>
Subject: Re: [netmod] actions and keyless lists
Message-ID:
        <CABCOCHSphD124J3B8fCYh+a= -bA75Bt9X+a1UvOGSKibEyGUW3g@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi,

I do not see any reason to prohibit this use of action-stmt
or notification-stmt.  If the list has no keys then there is
no need to distinguish instances because the data model defines
no such semantics.

What breaks if this is allowed?


Andy


On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrot= e:

> Hi,
>
> in the thread [1], we agreed that it is necessary to prevent actions (= and
> notifications) being defined on a state data node that is (or its ance= stor
> is) a list for which no keys are defined because then the instance to = which
> the action is tied may not be uniquely defined. The rfc6020bis-11 does= n't
> address this situation though. Is it still possible to add a correspon= ding
> text to sections 7.15 and 7.16?
>
> Lada
>
> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.i= etf.org/mailman/listinfo/netmod
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/b= rowse/netmod/attachments/20160404/d53c2f7b/attachment.html>

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

Subject: Digest Footer

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


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

End of netmod Digest, Vol 97, Issue 5
*************************************
 --_000_9wxv7dmwq4rp4gn9xfxsdxk11459797903397emailandroidcom_-- From nobody Mon Apr 4 12:54:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA5E12D83F for ; Mon, 4 Apr 2016 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrUs1OKNpGAD for ; Mon, 4 Apr 2016 12:54: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 169FE12D85B for ; Mon, 4 Apr 2016 12:54: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 A40C5132F; Mon, 4 Apr 2016 21:54:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5D7kUJF49Thj; Mon, 4 Apr 2016 21:54:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 4 Apr 2016 21:54:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9FDB20045; Mon, 4 Apr 2016 21:54:42 +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 C53cF_VP0Zl3; Mon, 4 Apr 2016 21:54: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 0A2DD20043; Mon, 4 Apr 2016 21:54:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E5013A70AC5; Mon, 4 Apr 2016 21:54:40 +0200 (CEST) Date: Mon, 4 Apr 2016 21:54:40 +0200 From: Juergen Schoenwaelder To: "Kenneth Kerpez (New Jersey)" Message-ID: <20160404195438.GD56870@elstar.local> Mail-Followup-To: "Kenneth Kerpez (New Jersey)" , "netmod@ietf.org" References: <9wxv7dmwq4rp4gn9xfxsdxk1.1459797903397@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9wxv7dmwq4rp4gn9xfxsdxk1.1459797903397@email.android.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-yang-model-classification-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 04 Apr 2016 19:54:48 -0000 On Mon, Apr 04, 2016 at 07:32:06PM +0000, Kenneth Kerpez (New Jersey) wrote: > The draft-ietf-netmod-yang-model-classification-01 could also consider a naming convention. In the Broadband Forum (BBF) we name files bbf-module-name-submodule.yang. ietf-name.yang is common. So perhaps - is a convention. > > > Ken Kerpez > ASSIA, Inc. > Cell +1 908 432-1600 > Landline +1908 876-4270 > See RFC 6020 section 7.1: It is RECOMMENDED to choose module names that will have a low probability of colliding with standard or other enterprise modules and submodules, e.g., by using the enterprise or organization name as a prefix for the module name. RFC 6020bis says in section 5.1: Developers of YANG modules and submodules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. Within a server, all module names MUST be unique. So yes, using a prefix like bbf- for BBF module names is a good 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 Mon Apr 4 12:57:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72A512D852; Mon, 4 Apr 2016 12:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JFPSSRNgoRz; Mon, 4 Apr 2016 12:57:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D7E12D64E; Mon, 4 Apr 2016 12:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4300; q=dns/txt; s=iport; t=1459799827; x=1461009427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e/hHVts3lRt2j0pc9FY5+oyiKHyRnpuuuzfsOO4bI00=; b=F+PrnIw6hgD7KTdJKNBe6NriEKd0rz+ybJS99qvree5kCCUTJNkvWlHx xXdr3U+Z6gFxF7EOYnb1JzkrcKsOpARZMP2aGlR0/on26OHvDppFOu4rI KANyxm/T3qr5db9DOxgJvyMPshnOQmHo4gycqIGD3jrtjzcSMhL20PlHU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAkxgJX/4UNJK1aA4M3U30GuyEBD?= =?us-ascii?q?YFyFwqFIkoCHIEeOBQBAQEBAQEBZSeEQQEBAQMBAQEBIBE6CwUHAgICAQgOAgE?= =?us-ascii?q?DAQIBAgIfBwICAhkMCxUICAIEDgWIHwgOrHyRUQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARUEeIUkgXWCVYRVCyaCOSuCKwWYAQGFcogVgWiETYhajxkBHgEBQoIygTV?= =?us-ascii?q?shyh+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="255851151" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 19:57:06 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34Jv6iU006598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 19:57:06 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:57:05 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 14:57:05 -0500 From: "Rajiv Asati (rajiva)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ91JyyAgAUq7AA= Date: Mon, 4 Apr 2016 19:57:05 +0000 Message-ID: References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> In-Reply-To: <20160401090207.GA50653@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.12.15] Content-Type: text/plain; charset="utf-8" Content-ID: <0A7EB26C856AB44FA6227A80EE87FF60@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:57:10 -0000 SGkgSnVlcmdlbiwNCg0KPiBPcGVyYXRpb25hbCBzdGF0ZSBvZnRlbiBoYXMgYSBkaWZmZXJlbnQg bGlmZXRpbWUgdGhhbiBjb25maWcuIEhlbmNlLA0KDQoNCkhtbS4uQ291bGQgeW91IHBsZWFzZSBj bGFyaWZ5IHRoZSBhYm92ZSBhIGJpdCBtb3JlPw0KDQotLSANCkNoZWVycywNClJhaml2IA0KDQoN Cg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KUmVw bHktVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPg0KRGF0ZTogRnJpZGF5LCBBcHJpbCAxLCAyMDE2IGF0IDU6MDIgQU0NClRvOiBS YWppdiBBc2F0aSA8cmFqaXZhQGNpc2NvLmNvbT4NCkNjOiAibmV0bW9kQGlldGYub3JnIiA8bmV0 bW9kQGlldGYub3JnPiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtuZXRtb2RdIFlBTkcgLSBJbnRlbmRlZC1Db25maWcgJiBBcHBsaWVkLUNvbmZpZyAmIERl cml2ZWQtU3RhdGUgJiBPcGVyYXRpb25hbC1zdGF0ZS4uLmdycnJyLi4uICEhDQoNCj5PcGVyYXRp b25hbCBzdGF0ZSBvZnRlbiBoYXMgYSBkaWZmZXJlbnQgbGlmZXRpbWUgdGhhbiBjb25maWcuIEhl bmNlLA0KPmtlZXBpbmcgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBzdGF0ZSB0b2dldGhlciBpbiB0 aGUgc2FtZSBzdHJ1Y3R1cmUNCj4od2l0aCB0aGUgc2FtZSBuYW1pbmcpIGNhdXNlcyB5b3UgcHJv YmxlbXMgZG93biB0aGUgcm9hZC4NCj4NCj4vanMNCj4NCj5PbiBUaHUsIE1hciAzMSwgMjAxNiBh dCAwNjo0NDowNlBNICswMDAwLCBSYWppdiBBc2F0aSAocmFqaXZhKSB3cm90ZToNCj4+IA0KPj4g V2hpbGUgd29ya2luZyBvbiBNUExTIExEUCB5YW5nIG1vZGVsIChodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcmF6YS1tcGxzLWxkcC1tbGRwLXlhbmcpLCB3ZSBub3RpY2VkIHRoZSBw b3NzaWJsZSBjb25mdXNpb24gYXJvdW5kIHN0cnVjdHVyaW5nIGludGVuZGVkIGNvbmZpZywgYXBw bGllZCBjb25maWcgYW5kIGRlcml2ZWQgc3RhdGUgKi4NCj4+IA0KPj4gT24gb25lIGhhbmQsIG9u ZSBtYXkgaGF2ZSAnaW50ZW5kZWQtY29uZmln4oCZIChSVykgYW5kIOKAmGFwcGxpZWQtY29uZmln 4oCZIChSTykgaW4gdGhlIHNhbWUgY29uc3RydWN0IChjb250YWluZXIpLCBhbmQg4oCYZGVyaXZl ZCBzdGF0ZeKAmSAoUk8pIGluIGEgc2VwYXJhdGUgY29uc3RydWN0IChjb250YWluZXIpLiANCj4+ IA0KPj4gCVRoaXMga2VlcHMgY29uZmlnIHRvZ2V0aGVyLCBidXQgZG9lc27igJl0IGhlbHAgb3Bl cmF0aW9uYWwgc3RhdGUsIHdoaWNoIHJlcXVpcmVzDQo+PiAJQm90aCBBcHBsaWVkLWNvbmZpZyBh bmQgZGVyaXZlZC1zdGF0ZS4NCj4+IA0KPj4gT24gdGhlIG90aGVyIGhhbmQgaGFuZCwgb25lIG1h eSBoYXZlIOKAmGludGVuZGVkLWNvbmZpZ+KAmSBpbiBvbmUgY29uc3RydWN0IChjb250YWluZXIp LCBhbmQg4oCYYXBwbGllZC1jb25maWfigJkgYW5kIOKAmGRlcml2ZWQgc3RhdGXigJkgaW4gYSBz ZXBhcmF0ZSBjb25zdHJ1Y3QgKGNvbnRhaW5lcikuIA0KPj4gDQo+PiAJVGhpcyBzaW1wbGlmaWVz IGZpZ3VyaW5nIG9wZXJhdGlvbmFsLXN0YXRlLCBidXQgZGl2aWRlcyB0aGUgY29uZmlnIHR5cGVz Lg0KPj4gDQo+PiBUaGVyZSBhcmUgcHJvcyAmIGNvbnMgZWl0aGVyIHdheS4gSXQgd291bGQgYmUg Z29vZCB0byBoYXZlIHNvbWUgZ3VpZGFuY2UvdGV4dCBhcm91bmQgZ3VpZGluZyBvbmUgb3ZlciBh bm90aGVyLCBzbyB0aGF0IG90aGVyIG1vZGVscyBjYW4gbGV2ZXJhZ2UuIE90aGVyd2lzZSwgd2Ug YXJlIGdvaW5nIHRvIGVuZCB1cCB3aXRoIHlldCBvbmUgbW9yZSBkaXNjcmVwYW5jeSAoYW1vbmcg dmFyaW91cyBwcm90b2NvbHMgWUFORyBtb2RlbHMpLCAmIGNvbmZ1c2luZyBpZiBub3QgaW5lZmZp Y2llbnQgbW9kZWxpbmcuDQo+PiANCj4+IFBlcmhhcHMsIHdlIGRpdGNoIGJvdGggb2YgdGhlIGFi b3ZlIGFwcHJvYWNoZXMsIGFuZCBzZXR0bGUgb24ga2VlcGluZyBhbGwgdGhyZWUgb2YgdGhlbSBp biB0aGUgc2FtZSBjb25zdHJ1Y3QuIEl0IG1pZ2h0IHNpbXBsaWZ5IHRoZSBvcmdhbml6YXRpb24g YSBiaXQuIE9mIGNvdXJzZSwgdGhhdCBhbHNvIGhhcyAyIG9wdGlvbnMgLSBoYXZlIGFsbCB0aGUg ZGF0YSB0eXBlcyBpbiBpbnRlbmRlZC1jb25maWcsIGFuZCB0aGVuIGluIGFwcGxpZWQtY29uZmln IGFuZCB0aGVuIGluIGRlcml2ZWQtc3RhdGUuIE9yIGhhdmUgaW50ZW5kZWQtY29uZmlnLCBhcHBs aWVkLWNvbmZpZyBhbmQgZGVyaXZlZC1zdGF0ZSBmb3IgZWFjaCBkYXRhIHR5cGUuIExhdHRlciBt aWdodCBiZSBzbGlnaHRseSBiZXR0ZXIsIGdpdmVuIHRoYXQgbm90IGV2ZXJ5IGRhdGEgdHlwZSB3 aWxsIGhhdmUgYWxsIHRocmVlLg0KPj4gDQo+PiANCj4+IFRob3VnaHRzPyANCj4+IA0KPj4gLS0g DQo+PiBDaGVlcnMsDQo+PiBSYWppdiBBc2F0aQ0KPj4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlciwg Q2lzY28NCj4+IA0KPj4gDQo+PiAqIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMtMDQ+DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZQ0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcg bGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPkZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0K From nobody Mon Apr 4 13:08:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDD112D84B for ; Mon, 4 Apr 2016 13:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_q_zeQU27eg for ; Mon, 4 Apr 2016 13:08: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 D78E812D14B for ; Mon, 4 Apr 2016 13:08:42 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:c4b:a9d0:8316:210] (unknown [IPv6:2001:67c:370:176:c4b:a9d0:8316:210]) by mail.nic.cz (Postfix) with ESMTPSA id 6EA0218010E; Mon, 4 Apr 2016 22:08:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459800521; bh=q/L5AaoDeklLzqGDUrkhXbOnew5xOUg6dtlSVPOkf4M=; h=From:Date:To; b=n2SXTMxMfKL+b/RkQCbun+V76zawzaoqpfGS5/YyWxh8HgyM2l00T8TYYBhm19Rrh buZnT524uFFtHqYSkxYv1zQYVKRF84ICuepZi7ShCkku81MFwpDq4f/fDC9Q6/P9DX /Dg/xMyhKLzYtqdJdOXsSma/At2EJUU/r76Ywpks= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 4 Apr 2016 17:08:37 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> References: <95F3A380-A2E6-4225-8A3A-5E01885DB8FD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:08:45 -0000 > On 04 Apr 2016, at 16:15, Andy Bierman wrote: >=20 >=20 > On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka = wrote: >=20 > > On 04 Apr 2016, at 15:57, Andy Bierman wrote: > > > > Hi, > > > > I do not see any reason to prohibit this use of action-stmt > > or notification-stmt. If the list has no keys then there is > > no need to distinguish instances because the data model defines > > no such semantics. >=20 > If such a keyless list has multiple entries, how can an action request = specify which of the list entries it is tied to? >=20 > it must be be relevant to distinguish instances or else the designer > would have defined a key. > =20 >=20 > > > > What breaks if this is allowed? >=20 > The behaviour is undefined. >=20 >=20 >=20 > IMO lists without keys are a really bad idea. > But the semantics are fully defined according to YANG. > If the list has no keys then there is no instance information > relevant to the data model. The action or notification is passed > all the keys (happens to be zero in this case). To my understanding, each action request has to specify the unique = instance that's the "receiver" of the action. If this cannot be done, it = is IMO a problem in the spec. An alternative implementation of actions would be to use instance = identifiers instead of an explicit data hierarchy, and in this case it = would be possible to use indices for identifying entries. But the = hierarchy provides no such option. It's not a big issue, but there is already a couple of rules regarding = where actions can and cannot be defined, so this would be another one = intended to avoid potential ambiguity. Lada >=20 >=20 > =20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > > > Andy > > > > > > On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka = wrote: > > Hi, > > > > in the thread [1], we agreed that it is necessary to prevent actions = (and notifications) being defined on a state data node that is (or its = ancestor is) a list for which no keys are defined because then the = instance to which the action is tied may not be uniquely defined. The = rfc6020bis-11 doesn't address this situation though. Is it still = possible to add a corresponding text to sections 7.15 and 7.16? > > > > Lada > > > > [1] = https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html > > > > -- > > 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 Apr 4 13:44:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B19B12D815; Mon, 4 Apr 2016 13:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRH7c151dO0n; Mon, 4 Apr 2016 13:44:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F075012D869; Mon, 4 Apr 2016 13:43:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B36F254; Mon, 4 Apr 2016 22:43:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ak8rj3oQdGtg; Mon, 4 Apr 2016 22:43: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; Mon, 4 Apr 2016 22:43:58 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15EB720045; Mon, 4 Apr 2016 22:43:58 +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 0h34jNDHhV4b; Mon, 4 Apr 2016 22:43:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CA8F20043; Mon, 4 Apr 2016 22:43:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D7EE3A70C01; Mon, 4 Apr 2016 22:43:57 +0200 (CEST) Date: Mon, 4 Apr 2016 22:43:56 +0200 From: Juergen Schoenwaelder To: "Rajiv Asati (rajiva)" Message-ID: <20160404204356.GA57133@elstar.local> Mail-Followup-To: "Rajiv Asati (rajiva)" , "netmod@ietf.org" , "mpls@ietf.org" References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@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: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 04 Apr 2016 20:44:01 -0000 On Mon, Apr 04, 2016 at 07:57:05PM +0000, Rajiv Asati (rajiva) wrote: > Hi Juergen, > > > Operational state often has a different lifetime than config. Hence, > > > Hmm..Could you please clarify the above a bit more? > The classic example: When I pull out a configured interface, the operational state of this interface is gone but not the config - if I put the interface back, it should come up configured as before. Obviously, I can also have operational state of an interface that has not been configured yet. /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 Apr 4 14:12:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930F612D6E0 for ; Mon, 4 Apr 2016 14:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA7HMRDjKNHO for ; Mon, 4 Apr 2016 14:12:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDAA12D89B for ; Mon, 4 Apr 2016 14:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10302; q=dns/txt; s=iport; t=1459804356; x=1461013956; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+uSv2j4lxdUHs0uaTK1wcDCq0G1qr15PS4Pk7qcjQY4=; b=XoKZHndQ6kvb3asteY22Rd12mWaLFR2pKFM6i7WKHzdPyUsN/d8A1Tc7 3zqKZIf8HCU6I2PDURGkFXi9B7rrPARDwz1woCNBgMkDu3tvEZmrb4mng +zlb07IK+rE/HaF0oZtG5gcC7fJp3FDuRC4HqGi389EuZgTvlOpYq6w/5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQA42AJX/4YNJK1dgzdTfQa7IQENg?= =?us-ascii?q?XIXDIUgSgIcgR84FAEBAQEBAQFlJ4RBAQEBBAEBASAROAIIAwwEAgEIEQMBAQE?= =?us-ascii?q?BAgIjAwICAiULFAEICAIEDgWIJgEOrQ+RXQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RV8hSSBdQiCTYc/K4IrBZMYhGkBhXKIFYFoToN/gyiEF4Ebg32LHAEeAQFCggQ?= =?us-ascii?q?ZgUpsAYcnAX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,442,1454976000"; d="scan'208";a="89973941" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 21:12:35 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u34LCZMb003683 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 21:12:35 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 16:12:34 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 16:12:34 -0500 From: "Clyde Wildes (cwildes)" To: "t.petch" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt Thread-Index: AQHRgrqqbdiJAOKHdkK+l/uGNO0H6J9ijKMAgAyYBbqAAAxjgIAAfzwAgAAGT4CABvG3S4ADniAA Date: Mon, 4 Apr 2016 21:12:34 +0000 Message-ID: <73ABB15F-1A72-4239-B85A-38EA6C8AFE91@cisco.com> References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com> <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com> <00ee01d18cd6$78724620$4001a8c0@gateway.2wire.net> In-Reply-To: <00ee01d18cd6$78724620$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.106.41] Content-Type: text/plain; charset="utf-8" Content-ID: <033603AF7B781440A815A3F1E5EEF3D6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , netmod WG Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:12:40 -0000 VG9tLA0KDQpJIHRvb2sgYW4gYWN0aW9uIGl0ZW0gaW4gdGhlIE5ldG1vZCByZXZpZXcgb2YgdGhl IGl0ZW0tc3lzbG9nIG1vZGVsIHRvIGFzayB5b3UgaWYgeW91IGFyZSBvayB3aXRoIHRoZSByZXN1 bHRpbmcgZHJhZnQgcHVibGlzaGVkIGFzIGEgcmVzdWx0IE1hcnRpbidzIGFuZCB5b3VyIGNvbW1l bnRzLg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lz bG9nLW1vZGVsLTA3DQoNCkRpZmZzIGZyb20gdjYgdG8gdjc6DQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvcmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZ1cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXN5 c2xvZy1tb2RlbC0wNy50eHQNCg0KUGxlYXNlIGNvbW1lbnQuDQoNClRoYW5rcywNCg0KQ2x5ZGUN Cg0KDQoNCk9uIDQvMi8xNiwgNDo1NCBBTSwgInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29t PiB3cm90ZToNCg0KPi0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJLaXJhbiBL b3VzaGlrIEFncmFoYXJhIFNyZWVuaXZhc2EgKGtrb3VzaGlrKSINCj48a2tvdXNoaWtAY2lzY28u Y29tPg0KPkNjOiAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+OyA8bmV0bW9kQGlldGYu b3JnPg0KPlNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTYgOTo1NSBQTQ0KPg0KPkhpIEFuZHkN Cj4NCj5XZSBkaWQgc29saWNpdCBhbmQgaW5jb3Jwb3JhdGUgZmVhdHVyZSBzdXBwb3J0IGZyb20g YXQgbGVhc3QgNSsgdmVuZG9ycw0KPmZvciB0aGlzIG1vZGVsLg0KPlRoZSBtb2RlbCByZXByZXNl bnRzIGEgbWluaW1hbCBjb21tb24gZmVhdHVyZSBzZXQuIFRoZXkgYXJlIGFsc28NCj5oaWVyYXJj aGljYWwgYXMgQ2x5ZGUgbm90ZWQgYmVsb3cuDQo+DQo+VGhhbmtzDQo+S2lyYW4NCj4NCj48dHA+ DQo+DQo+SWYgSSByZW1lbWJlciBteSBtYXRoZW1hdGljYWwgdGVtaW5vbG9neSwgSSBwcmVmZXIg YSBoaWdoZXN0IGNvbW1vbg0KPmZhY3RvciwgdG8gd2hpY2ggYXVnbWVudGF0aW9ucyBjYW4gYmUg YXBwbGllZCwgd2hlcmVhcyBvdGhlcnMgcHJlZmVyIGENCj5sb3dlc3QgY29tbW9uIGRlbm9taW5h dG9yLCBwYXJ0aXRpb25lZCBieSAgZmVhdHVyZXMuDQo+DQo+SSBkbyBub3QgZG91YnQgdGhhdCBl dmVyeXRoaW5nIHlvdSBtb2RlbCBpcyB0aGVyZSBpbiBpbXBsZW1lbnRhdGlvbnMgYnV0DQo+SSBw cmVmZXIgYSB3aWRlbHksIHByZWZlcmFibHkgdW5pdmVyc2FsLCBjb3JlIHdoaWNoIGNhbiB0aGVu IGJlIGFkZGVkDQo+dG8uDQo+DQo+SXQgaXMgYSBqdWRnZW1lbnQgY2FsbCByYXRoZXIgdGhhbiBh biBlbmdpbmVlcmluZyBvbmUsIGEgbWF0dGVyIG9mDQo+cGhpbG9zb3BoeSBldmVuLCBzbyBJIGxl YXZlIGl0IHVwIHRvIHJvdWdoIGNvbnNlbnN1cy4NCj4NCj5Ub20gUGV0Y2gNCj4NCj5Gcm9tOiBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29t Pj4NCj5EYXRlOiBNb25kYXksIE1hcmNoIDI4LCAyMDE2IGF0IDM6MzIgUE0NCj5UbzogIkNseWRl IFdpbGRlcyAoY3dpbGRlcykiDQo+PGN3aWxkZXNAY2lzY28uY29tPG1haWx0bzpjd2lsZGVzQGNp c2NvLmNvbT4+DQo+Q2M6ICJ0LnBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0 ZmNAYnRjb25uZWN0LmNvbT4+LA0KPiJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4iDQo+PG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4sIEtpcmFu IEtvdXNoaWsgQWdyYWhhcmENCj5TcmVlbml2YXNhIDxra291c2hpa0BjaXNjby5jb208bWFpbHRv Omtrb3VzaGlrQGNpc2NvLmNvbT4+DQo+U3ViamVjdDogUmU6IFtuZXRtb2RdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0wNy50eHQNCj4NCj5PbiBNb24sIE1hciAy OCwgMjAxNiBhdCAxMjo1NyBQTSwgQ2x5ZGUgV2lsZGVzIChjd2lsZGVzKQ0KPjxjd2lsZGVzQGNp c2NvLmNvbTxtYWlsdG86Y3dpbGRlc0BjaXNjby5jb20+PiB3cm90ZToNCj5Ub20sDQo+DQo+SSB1 bmRlcnN0YW5kIHlvdXIgY29uY2VybiB3aXRoIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBtb2RlbC4g VGhhdCBzYWlkLA0KPmFzIHdlIHByb2dyZXNzZWQgd2UgZW5jb3VudGVyZWQgc29tZSB2ZW5kb3Jz IGFuZCBzb21lIElFVEYgUkZDIGF1dGhvcnMNCj53aG8gcmVxdWVzdGVkIHRoYXQgYSBwYXJ0aWN1 bGFyIGZlYXR1cmUgb2YgaW50ZXJlc3QgYmUgaW5jbHVkZWQuIFdlIGZlbHQNCj50aGF0IHdlIGhh ZCB0byBtYWtlIGZlYXR1cmVzIHRoYXQgd2VyZSBub3QgaW1wbGVtZW50ZWQgYnkgdHdvIG9yIG1v cmUNCj52ZW5kb3JzIGEgWUFORyBmZWF0dXJlIHRvIGdhaW4gYWNjZXB0YW5jZS4gV2hpY2ggaXMg cHJlZmVycmVkIGluIHRoaXMNCj5jYXNlOiBhdWdtZW50YXRpb24gdG8gYWRkIGZlYXR1cmVzOyBk ZXZpYXRpb24gbm90LXN1cHBvcnRlZCBzdGF0ZW1lbnRzDQo+dG8gcmVtb3ZlIGZlYXR1cmVzOyBv ciB0aGUgdXNlIG9mIGZlYXR1cmUgc3RhdGVtZW50cz8gRHVyaW5nIGVhcmx5IG1vZGVsDQo+ZGV2 ZWxvcG1lbnQgb3VyIFlBTkcgZG9jdG9yIGFkdmlzb3IgYWR2b2NhdGVkIHVzaW5nIGZlYXR1cmUu DQo+DQo+SSByZWFkIHlvdXIgcG9zdCBvbiAiZmVhdHVyZXMgLSBhIENhcnRlc2lhbiBleHBsb3Np b24iIHBvc3QuIE5vdGUgdGhhdA0KPmluIHRoZSBjYXNlIG9mIHRoZSBsYXRlc3QgaWV0Zi1zeXNs b2cgbW9kZWwgZm91ciBvZiB0aGUgZmVhdHVyZXMgYXJlDQo+bmVzdGVkIHN1Y2ggdGhhdCB0aGV5 IGFyZSBub3QgZW5jb3VudGVyZWQgdW5sZXNzIGEgaGlnaGVyIGxldmVsIGZlYXR1cmUNCj5pcyBl bmFibGVkLg0KPg0KPldoYXQgd291bGQgeW91ciBwcmVmZXJlbmNlIGJlOg0KPi0gcmVtb3ZlIHRo ZSBmZWF0dXJlIHN0YXRlbWVudHMgYW5kIGFzayB2ZW5kb3JzIHRvIHN1cHBseSBkZXZpYXRpb24N Cj5zdGF0ZW1lbnRzIGZvciB0aG9zZSBsZWF2ZXMgbm90IGltcGxlbWVudGVkDQo+LSByZW1vdmUg YWxsIGxlYXZlcyBjb25kaXRpb25lZCBieSBmZWF0dXJlIGFuZCBhc2sgdmVuZG9ycyB0byBzdXBw bHkNCj5hbm5vdGF0ZWQgbW9kZWxzIHdpdGggYXVnbWVudGF0aW9uDQo+LSBsZWF2ZSB0aGluZ3Mg YXMgdGhleSBhcmUNCj4NCj5JdCBzb3VuZHMgbGlrZSBCIHdvdWxkIGJlIHlvdXIgcHJlZmVyZW5j ZT8NCj4NCj4NCj5JIGFncmVlIHdpdGggVG9tLg0KPklNTyBpZiB0aGUgZnVuY3Rpb25hbGl0eSBp cyBub3Qgc3VwcG9ydGVkIGJ5IGF0IGxlYXN0IDIgdmVuZG9ycyB0aGVuDQo+cmVtb3ZlIGl0IGZy b20gdGhlIHN0YW5kYXJkLiAgVGhlIHZlbmRvciBjYW4gd3JpdGUgYSBtb2R1bGUNCj50aGF0IGF1 Z21lbnRzIHRoZSAgYmFzZSBtb2R1bGUuDQo+DQo+DQo+DQo+VGhhbmtzLA0KPg0KPkNseWRlDQo+ DQo+DQo+DQo+QW5keQ0KPg0KPg0KPg0KPg0KPg0KPk9uIDMvMjgvMTYsIDEwOjA5IEFNLCAidC5w ZXRjaCINCj48aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+ IHdyb3RlOg0KPg0KPj4NCj4+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj5Gcm9tOiAi Q2x5ZGUgV2lsZGVzIChjd2lsZGVzKSINCj48Y3dpbGRlc0BjaXNjby5jb208bWFpbHRvOmN3aWxk ZXNAY2lzY28uY29tPj4NCj4+VG86IDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4+DQo+PkNjOiAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPG1haWx0bzpt YmpAdGFpbC1mLmNvbT4+Ow0KPiJ0LnBldGNoIg0KPj48aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWls dG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+OyAiS2lyYW4gS291c2hpaw0KPkFncmFoYXJhIFNyZWVu aXZhc2EgKGtrb3VzaGlrKSINCj4+PGtrb3VzaGlrQGNpc2NvLmNvbTxtYWlsdG86a2tvdXNoaWtA Y2lzY28uY29tPj4NCj4+U2VudDogU3VuZGF5LCBNYXJjaCAyMCwgMjAxNiA3OjUzIFBNDQo+Pg0K Pj4+IEhpLA0KPj4+DQo+Pj4gVGhpcyByZXZpc2lvbiBpbmNvcnBvcmF0ZXMgZmVlZGJhY2sgZnJv bSBNYXJ0aW4gQmpvcmtsdW5rICgxOQ0KPj5jb21tZW50cykgYW5kIFRvbSBQZXRjaCAoMTAgY29t bWVudHMpLiBUaGFua3MgdG8gYm90aCBvZiB5b3UgZm9yIHlvdXINCj4+dmFsdWFibGUgZmVlZGJh Y2shDQo+Pj4NCj4+PiBSZWdhcmRpbmcgVG9tJ3MgY29tbWVudCAtICI0LjEgV2hhdCBhIGxvdCBv ZiBmZWF0dXJlcz8gIEFnYWluLCBtYWtlcw0KPj50aGluZ3MgbW9yZSBjb21wbGV4LCBtb3JlIGVy cm9yIHByb25lIC0gYXJlIHRoZXkgYWxsIHJlYWxseSBuZWVkZWQ/IjoNCj5XZQ0KPj5zdGFydGVk IHRoZSBkcmFmdCB0d28geWVhcnMgYWdvIGFuZCBpdCBoYXMgZXZvbHZlZCBmcm9tIGZlZWRiYWNr DQo+PnJlY2VpdmVkIGZyb20gYWxsIG9mIHRoZSBmb2xrcyB0aGF0IGFwcGVhciBpbiB0aGUgQWNr bm93bGVkZ2VtZW50cw0KPj5zZWN0aW9uLiBQbGVhc2UgcmV2aWV3IHRoZSBjdXJyZW50IGRyYWZ0 IHdoZXJlIEkgYmVsaWV2ZSB0aGF0IEkgYWRkcmVzcw0KPj5hbGwgb2YgeW91ciBjb21tZW50cyBl eGNlcHQgcG9zc2libHkgdGhpcyBvbmUuIFRoZSB0cmFkZW9mZiBpcyB0byBsZWF2ZQ0KPj50aGUg ZmVhdHVyZSBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IG91dCBvZiB0aGUgZHJhZnQgYW5kIGxlYXZl IGl0IHRvIHRoZQ0KPj5pbXBsZW1lbnRhdGlvbnMgdG8gYWRkIGJhY2sgdGhyb3VnaCBhdWdtZW50 YXRpb24uIFRoYXQgc2FpZCBtb3N0IG9mIHRoZQ0KPj5mZWF0dXJlcyB0aGF0IGFyZSBjYWxsZWQg b3V0IGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBieSBhdCBsZWFzdCB0d28NCj4+dmVuZG9ycywgYnV0 IG5vdCBhbGwsIGxlYWRpbmcgdG8gdGhlIGZlYXR1cmUgZGVzaWduYXRpb24uDQo+Pg0KPj5DbHlk ZQ0KPj4NCj4+WWVlZWVzOyBJIGRpZCBhIHNlcGFyYXRlIHBvc3Qgb24gdGhlIHRvcGljIHRoaW5r aW5nIHRoYXQgYW4gaW1wbGVtZW50b3INCj4+bWlnaHQgc2hhcmUgbXkgY29uY2VybnMgYWJvdXQg dGhlIGxhcmdlIG51bWJlciBvZiBwb3NzaWJsZSB2YXJpYXRpb25zDQo+aW4NCj4+YW4gaW1wbGVt ZW50YXRpb24gd2hlbiB0aGVyZSB3ZXJlIGEgbGFyZ2UgbnVtYmVyIG9mIGZlYXR1cmVzLCB0aGF0 DQo+PnBlcmhhcHMgdGhlcmUgc2hvdWxkIGJlIGd1aWRlbGluZXMgYWJvdXQgaXQsIGJ1dCBpdCBk aWQgbm90IGdldCBhbnkNCj4+dHJhY3Rpb24uICBJdCBpcyBvbmUgdGhvc2UgaXNzdWVzIHdoZXJl IEkgdGhpbmssIGluIGEgeWVhciBvciB0d28ncw0KPj50aW1lLCBvdGhlcnMgbWlnaHQgc2hhcmUg bXkgY29uY2VybiwgYnV0IG5vdCB5ZXQ6LSguDQo+Pg0KPj5JIGRvbid0IGRvdWJ0IHRoYXQgdGhl IHZhcmlhdGlvbiBleGlzdHMgYW5kIG5lZWRzIG1vZGVsbGluZywganVzdCB0aGF0DQo+PnN1Y2gg dXNlIG9mICdmZWF0dXJlcycgbWF5IGhhdmUgdW5mb3J0dW5hdGUgY29uc2VxdWVuY2VzIC0gYnV0 IEkgaGF2ZQ0KPm5vDQo+PmFsdGVybmF0aXZlIHN1Z2dlc3Rpb24uDQo+Pg0KPj5Ub20gUGV0Y2gN Cj4+DQo+Pj4gVGhhbmtzLA0KPj4+DQo+Pj4gQ2x5ZGUNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiAz LzIwLzE2LCA4OjEwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZg0KPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiINCj4+PG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m DQo+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+PiB3cm90ZToNCj4+Pg0KPj4+ID4NCj4+PiA+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+PmRpcmVjdG9yaWVzLg0K Pj4+ID5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBORVRDT05GIERhdGEgTW9kZWxp bmcgTGFuZ3VhZ2Ugb2YNCj4+dGhlIElFVEYuDQo+Pj4gPg0KPj4+ID4gICAgICAgIFRpdGxlICAg ICAgICAgICA6IFNZU0xPRyBZQU5HIE1vZGVsDQo+Pj4gPiAgICAgICAgQXV0aG9ycyAgICAgICAg IDogQ2x5ZGUgV2lsZGVzDQo+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgS2lyYW4gS291 c2hpaw0KPj4+ID4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1v ZGVsLTA3LnR4dA0KPj4+ID4gUGFnZXMgICAgICAgICAgIDogMzQNCj4+PiA+IERhdGUgICAgICAg ICAgICA6IDIwMTYtMDMtMjANCj4+PiA+DQo+Pj4gPkFic3RyYWN0Og0KPj4+ID4gICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgZm9yIHRoZSBTeXNsb2cgcHJvdG9jb2wNCj53 aGljaA0KPj5pcw0KPj4+ID4gICB1c2VkIHRvIGNvbnZleSBldmVudCBub3RpZmljYXRpb24gbWVz c2FnZXMuDQo+Pj4gPg0KPj4+ID4NCj4+PiA+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4gPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC8NCj4+PiA+DQo+Pj4gPlRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+ID5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA3DQo+Pj4gPg0K Pj4+ID5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1z eXNsb2ctbW9kZWwtMDcNCj4+PiA+DQo+Pj4gPg0KPj4+ID5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj5zdWJtaXNzaW9u DQo+Pj4gPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQNCj50b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPj4+ID4NCj4+PiA+ SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K Pj4+ID5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+ID4NCj4+PiA+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+bmV0bW9k IG1haWxpbmcgbGlzdA0KPj4+ID5uZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4NCj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+ Pg0KPj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0K Pg0K From nobody Mon Apr 4 14:36:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0710512D14A for ; Mon, 4 Apr 2016 14:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw3MBwFWzfAX for ; Mon, 4 Apr 2016 14:36:18 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D6A12D666 for ; Mon, 4 Apr 2016 14:36:18 -0700 (PDT) Received: by mail-lb0-x22c.google.com with SMTP id qe11so180648185lbc.3 for ; Mon, 04 Apr 2016 14:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QjaTnAN8hvOMPAL6Fjhc4FsR9tKdXbC0aHK35FacbZw=; b=MMcNWkBMbsib2nkhazIfxWxRRUk30NOOianU+W5GABJazvUdm95jqiexvBuA91Ksc9 OivQn4H4BOX6x/gB7plHZsLkmehfQwd1QlS55oxfk1LgWhSLpW+qOYcr6o/aLmnqgFgi zlTH8Xvb4Gy4Bg7luNKCX+3cCs6Bsw4x9Z+slJ8B1PDDqEX3P18AvnjsN3/eLo7QyzDU 5nzuPmIhtlmbfvwS6l8XNFVpfZqX/UQ6DENfGRFKyswbm3HN5uLbMDsT2b6gxmDr+N0I yjtHW9iNTWKHf/c0JAggaxrI02wvghCgiINUIGS7VyHqdNOwQ0to4cRlJ12MMVklVB6l wrYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QjaTnAN8hvOMPAL6Fjhc4FsR9tKdXbC0aHK35FacbZw=; b=HtOylEnm8s7dC8VTGgN7QKRwnC3NigsI3BPG109yJNVx4JnTpKWQ/ZAuNfclfVRosZ h86kR7urxLbeCu6/RLX/8gZWcbmpSdTyH5IaDUkuiS2AQ25YZPTPzcoQGduNVUMee7d6 XWPV7zyp7gLKYAVJjVJ2AbSU5Z+YzgU7ZbKzaqelKkbrSHMoD3Vx9nlw6Eea6/XwewHo RWGZ2+L6Bh/pB8+dRwqRRA5NpqYh8jlnXXqTH/dm94SpSF6XdoxdBY3vJpfpeUttK01d 4ZyjZ/06BfiDOqpR0ucfPfTj9CMrVxchASIcejNQyO6WASV8vHuIPgU+E9hwCx52yyff wZ2g== X-Gm-Message-State: AD7BkJK3pGiUeZmvJuoFXiUuDV3GCjMuFYFAkkxjrjmINUj5gJjBcOSdIofAHKUjyMDUPITLq2FpdG/CrVE1hQ== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr7455579lbc.94.1459805776202; Mon, 04 Apr 2016 14:36:16 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Mon, 4 Apr 2016 14:36:16 -0700 (PDT) In-Reply-To: <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> References: <95F3A380-A2E6-4225-8A3A-5E01885DB8FD@nic.cz> <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> Date: Mon, 4 Apr 2016 14:36:16 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c259a8bb6143052faf8444 Archived-At: Cc: NETMOD WG Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:36:21 -0000 --001a11c259a8bb6143052faf8444 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: > > > On 04 Apr 2016, at 16:15, Andy Bierman wrote: > > > > > > On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: > > > > > On 04 Apr 2016, at 15:57, Andy Bierman wrote: > > > > > > Hi, > > > > > > I do not see any reason to prohibit this use of action-stmt > > > or notification-stmt. If the list has no keys then there is > > > no need to distinguish instances because the data model defines > > > no such semantics. > > > > If such a keyless list has multiple entries, how can an action request > specify which of the list entries it is tied to? > > > > it must be be relevant to distinguish instances or else the designer > > would have defined a key. > > > > > > > > > > What breaks if this is allowed? > > > > The behaviour is undefined. > > > > > > > > IMO lists without keys are a really bad idea. > > But the semantics are fully defined according to YANG. > > If the list has no keys then there is no instance information > > relevant to the data model. The action or notification is passed > > all the keys (happens to be zero in this case). > > To my understanding, each action request has to specify the unique > instance that's the "receiver" of the action. If this cannot be done, it is > IMO a problem in the spec. > > An alternative implementation of actions would be to use instance > identifiers instead of an explicit data hierarchy, and in this case it > would be possible to use indices for identifying entries. But the hierarchy > provides no such option. > > It's not a big issue, but there is already a couple of rules regarding > where actions can and cannot be defined, so this would be another one > intended to avoid potential ambiguity. > > I agree actions were not considered when keyless lists were allowed in YANG. There was an assumption that this data is always read-only that is no longer true in YANG 1.1. I certainly prefer adding a restriction than redoing the way actions work. Using /foo[5] does not work because entry "5" might move or get deleted, so the numbering is not stable. > Lada > > Andy > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > Andy > > > > > > > > > On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka > wrote: > > > Hi, > > > > > > in the thread [1], we agreed that it is necessary to prevent actions > (and notifications) being defined on a state data node that is (or its > ancestor is) a list for which no keys are defined because then the instance > to which the action is tied may not be uniquely defined. The rfc6020bis-11 > doesn't address this situation though. Is it still possible to add a > corresponding text to sections 7.15 and 7.16? > > > > > > Lada > > > > > > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html > > > > > > -- > > > 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 > > > > > --001a11c259a8bb6143052faf8444 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 04 Apr 2016, at 16:15, Andy Bierman <andy@yumaworks.com> wrote:
>
>
> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 04 Apr 2016, at 15:57, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > I do not see any reason to prohibit this use of action-stmt
> > or notification-stmt.=C2=A0 If the list has no keys then there is=
> > no need to distinguish instances because the data model defines > > no such semantics.
>
> If such a keyless list has multiple entries, how can an action request= specify which of the list entries it is tied to?
>
> it must be be relevant to distinguish instances or else the designer > would have defined a key.
>
>
> >
> > What breaks if this is allowed?
>
> The behaviour is undefined.
>
>
>
> IMO lists without keys are a really bad idea.
> But the semantics are fully defined according to YANG.
> If the list has no keys then there is no instance information
> relevant to the data model.=C2=A0 The action or notification is passed=
> all the keys (happens to be zero in this case).

To my understanding, each action request has to specify the unique instance= that's the "receiver" of the action. If this cannot be done,= it is IMO a problem in the spec.

An alternative implementation of actions would be to use instance identifie= rs instead of an explicit data hierarchy, and in this case it would be poss= ible to use indices for identifying entries. But the hierarchy provides no = such option.

It's not a big issue, but there is already a couple of rules regarding = where actions can and cannot be defined, so this would be another one inten= ded to avoid potential ambiguity.


I agree actions were not considered wh= en keyless lists were allowed in YANG.
There was an assumption th= at this data is always read-only that is no
longer true in YANG 1= .1.

I certainly prefer adding a restriction than r= edoing the way actions work.
Using /foo[5] does not work because = entry "5" might move or get deleted,
so the numbering i= s not stable.



=C2=A0=
Lada


Andy
=C2=A0
>
>
>
> Lada
>
>
> Andy
>
>
> >
> >
> > Andy
> >
> >
> > On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> >
> > in the thread [1], we agreed that it is necessary to prevent acti= ons (and notifications) being defined on a state data node that is (or its = ancestor is) a list for which no keys are defined because then the instance= to which the action is tied may not be uniquely defined. The rfc6020bis-11= doesn't address this situation though. Is it still possible to add a c= orresponding text to sections 7.15 and 7.16?
> >
> > Lada
> >
> > [1] https://www.ietf.org= /mail-archive/web/netmod/current/msg14936.html
> >
> > --
> > 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





--001a11c259a8bb6143052faf8444-- From nobody Mon Apr 4 19:40:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84B12D5B0 for ; Mon, 4 Apr 2016 19:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owyD4_1ZOS8S for ; Mon, 4 Apr 2016 19:40:16 -0700 (PDT) Received: from BLU004-OMC3S26.hotmail.com (blu004-omc3s26.hotmail.com [65.55.116.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445BC12D0C3 for ; Mon, 4 Apr 2016 19:40:16 -0700 (PDT) Received: from BLU436-SMTP134 ([65.55.116.73]) by BLU004-OMC3S26.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 4 Apr 2016 19:40:14 -0700 X-TMN: [FhGWY1Nbe8tUz7bb9jyHC5JsWFekWrcL] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Mon, 4 Apr 2016 23:39:57 -0300 From: Ashesh Mishra To: Thread-Topic: IETF-95 Meeting Notes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3542658009_2446239" X-OriginalArrivalTime: 05 Apr 2016 02:40:10.0650 (UTC) FILETIME=[79234FA0:01D18EE4] Archived-At: Subject: [netmod] IETF-95 Meeting Notes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:40:18 -0000 --B_3542658009_2446239 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable All, Please review the notes from today=B9s NETMOD WG sessions and make revisions if we missed any comment that was made during the meetings. http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-netmod?useMonospaceFont= =3D true ONLY add comments that were made DURING the meetings. :) Thanks, NETMOD WG. --B_3542658009_2446239 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
All,

Please review the notes from today’s NETMOD WG sessions and make revi= sions if we missed any comment that was made during the meetings. 


ONLY a= dd comments that were made DURING the meetings. :)

= Thanks,
NETMOD WG.


--B_3542658009_2446239-- From nobody Mon Apr 4 20:33:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089FB12D658 for ; Mon, 4 Apr 2016 20:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g6Q-xo1li7l for ; Mon, 4 Apr 2016 20:33:33 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id D7AC712D648 for ; Mon, 4 Apr 2016 20:33:32 -0700 (PDT) Received: (qmail 31694 invoked by uid 0); 5 Apr 2016 03:33:28 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 5 Apr 2016 03:33:28 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id eTZM1s00M2SSUrH01TZQ8a; Mon, 04 Apr 2016 21:33:28 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=8-vk5mV8h8H12RRskxsA:9 a=8g8Dk5d-OE7kieuX:21 a=rzuJohY4cSxtvhwM: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:References:To:Subject; bh=gvsqjr9lVmB1XB3odDsppRzt3VDpHHyJuVmZRvAncjY=; b=Bdm6IEB+vMsrBJyqB7fsIyD56t Z0Vsk0EfPDx1BM7wvYtjdsz1lmRT635MM1o3WAipu5hlrWUWG9GFYvDt/uqcoIw2TmX28y6QumSJY sj/93dKorSVNSKuuvkdpdeT2O; Received: from box313.bluehost.com ([69.89.31.113]:40932 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anHk1-0002fu-2r for netmod@ietf.org; Mon, 04 Apr 2016 21:33:21 -0600 To: netmod@ietf.org References: From: Lou Berger Message-ID: <570331F0.9050705@labn.net> Date: Mon, 4 Apr 2016 23:33:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] IETF-95 Meeting Notes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 03:33:36 -0000 On 4/4/2016 10:39 PM, Ashesh Mishra wrote: > All, > > Please review the notes from today’s NETMOD WG sessions and make > revisions if we missed any comment that was made during the meetings. > > http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-netmod?useMonospaceFont=true > > ONLY add comments that were made DURING the meetings. :) > > Thanks, > NETMOD WG. > > Kudos to Ashesh and all who helped out contributing to the session and the notes. Here's the actual initial raw notes... NETMOD Agenda For IETF 95 Monday, April 4th, 2016 15:50-17:20 Monday Afternoon session II 17:40-19:40 Monday Afternoon session III Room: Atlantico C Update presentation links in Agenda (@Chairs) 0 Title: Agenda & Intro Draft: n/a Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-0.pptx Presenter: Chairs Notes: Lou: New IPR rules. Chairs will request IPR disclosures from authors/contributors at various steps. 1 Title: YANG Summary Draft: n/a Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-1.pdf Presenter: Benoit Claise Notes: Mehmet: Do we have crieria defined with which we can analyze which models are relevant for standardization? Benoit: Two answer. 1. L3VPN service model (L3SM) will help determine with server YANG models are required 2. The other WG will have to decide for themselves Eliot: Should we hold progress to wait for OpState and Mount compatibility? Benoit: They need focus and need to be resolved. Dean: Merge pyang 1.1 into main branch. Have an option to complile with 1.0 or 1.1. Lada: That's what's being worked on. Charles: Is it possible to tie pyang to ID-to-nits or to xml2rfc? 2 Title: Opstate & schema mount update Draft: n/a Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-2.pptx Presenter: Chairs Notes: Kent: Open items with requirements doc: Data node locality, simulatenous access to intended and applied config, telemetry data. John Messenger(?): Crystalizing requirement document helps focus the work, but maybe not everyone will agree with it. Lou: Requirements are good/right, but they are not the full set that will be captured in the full solution. We'll know what's really right when we implement it. At this time, we believe requirements document is good enough to proceed with the solution. 3 Title: Schema Mount Draft: structual-mount/ysdl Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-3.pdf Presenter: Ladislav Lhotka / Martin Bjorklund Notes: Chris: What is the difference between schema and a model? Lada: Good question, but I'm not going to answer that now. (?) Jason Sterne: In the logical device, if we want to put interfaces and ACLs to mount point, can't we add references from ACL to interface? Lada: The sub-schema would contain both, interfaces and ACLs. So you will be able to refer between the interface and ACL. Can't refer from logical device to parent device. Eric Voit: There is also alias-mount. Will be discussed later, but is not covered by schema mount. Andy: Concern that schema-mount throwing away YANG statements will result in invalid models Lada: Within a logical mount point, one can refer to other leafs, but not leafs in another root/mount point. Andy: I am fine with that restriction. Benoit: Is it possible that we'd have a deviation in a model and another one in the mount? Lada: ??? Dean Bogdanovic: Support schema node identifier option instead of mount-point extension to yang. Lou: Different use cases (??) where mount-point fits better. Andy: Anydata tells clients that there may be nodes Lada: We need to discuss this more. 4 Title: Needing an extensible Mount syntax across Schema, Alias, & Peers Draft: http://tools.ietf.org/html/draft-clemm-netmod-mount Draft: http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-4.pptx Presenter: Eric Voit Notes: Dean Bogdanovic: Terminology is a bit different from Lada's presentation Eric: Shouldn't be any difference. Lada: Don't think there's any difference. Dean: Okay. Chris: Are the alias and peer mount client driven (does the client control them)? Eric: peer mount is not signaled today. Defined in the mount point. Mount server is the source of the info that is mounted from the client. Kent: with regards to defining an extensible syntax, this needs to be discussed on the list. Lou: Is the peer/alias mount requested by the server or the client? Eric: he element doing the requesting of mounted data is the client. This is where the mountpoint exists. The server doesn't have to know that the data is being represented as Mounted. 5 Title: Guidelines for Authors and Reviewers of YANG Data Model Documents Draft: http://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-5.pdf Presenter: Andy Bierman Notes: Issue: "the anyxml statement MUST NOT be used to represent a conceptual subtree of YANG data nodes Martin: "Must not use anyxml" is okay in 6087-bis. These recommnedations are more strict than the language allows. Lou: personal preference to not having options, thus MUST NOT is prefered Issue closed => leave the text unchanged John:??? Andy: not in the draft yet Andy: Should --ietf pyang option be used on examples? Maybe/maybe-not. If not, then use ... tags Benoit: Should the tag be suggested to other SDOs? Mahesh: Other SDOs submit yang models as separate files so this issue doesn't always apply to them. Kent Watsen: things "example" refers to XML instance documents, maybe a better word can be found Andy: Requesting recommendations for other conventions that should be in this draft. Acee: is this going to be in this document or another Andy + chairs: this one Mahesh: I prefer in a BCP Rajiv: Recommend a proper structure for a yang model (graphical representation + guideline). Also, recommend what is contained in the operational-state. 1720: Beverage and Snack Break 6 Title: QoS YANG Model Draft: http://tools.ietf.org/html/draft-asechou-netmod-qos-yang Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-12.pptx Presenter: Mahesh Jethanandani Notes: Kent: Does this document replace the 03 diffserv document? Mahesh: Yes. Lou: Why was the model renamed? Mahesh: Original model excluded anything L2 related. Idea is that this model should be extensible to other layers/features. Dean: Common abstraction of QoS is difficult because of different implementations from vendors. Need more active participation from other vendors. Benoit: SUPA has YANG model for policy and does such abstraction well. Mahesh: Havne't reviewed it. Will do. Dean: There's no way to extend what SUPA is doing for policy for the QoS model. ??? from Ericcson (?): There's a QoS model in rtgwg. 7 Title: SYSLOG YANG Model Draft: http://tools.ietf.org/html/draft-ietf-netmod-syslog-model Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-6.pptx Presenter: Clyde Wildes Notes: Kent: Is there a desire to extend this to support TLS? Clyde: Current draft supports this. Data elements to support key exchange not added. Lou: What's left for this draft? Clyde: Benoit asked to make change to examples (?). Lou: Is the document ready after these changes? Clyde: Yes. 8 Title: YANG Model Classification Draft: http://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-7.pptx Presenter: Dean Bogdanovic Notes: Jason Sterne: Why do we use extension vs augmentation in "vendor specific extension" Dean: May have multiple identities that not all vendors support. Kent: how much left until ready to Last Call Dean: it's ready now, assuming the WG is okay with the changes made to this version of the draft Lou: what about going deeper and add more catagories (e.g. OAM)? Dean: customers have said that it's too complicated Lou: but the OpenConfig folks had a more detailed model 9 Title: ACL YANG Model Draft: http://tools.ietf.org/html/draft-ietf-netmod-acl-model Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-8.pptx Presenter: Dean Bogdanovic Notes: Jason Sterne: Feels that interfaces shouldn't be part of base model, doesn't think there is broad support Elliot Lear: there many be a need for other motdels to define separate ACLs for input and output interfaces Chairs: call for if interface should be in base: 6 prefer NOT having it in the doc at all 5 prefer having it in, but as a feature 2 prefer having it in the doc as required 10 Title: Routing Cfg YANG Model Draft: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-9.pptx Presenter: Acee Lindem Notes: 11 Title: Network Device YANG Organizational Model Draft: http://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-10.pptx Presenter: Acee Lindem Notes: Dean Bogdanovic: Why are we putting the ietf keychain in top-level instead of system managemnet? Acee: Would ACL go there too? Dean: It's HW specific. Acee: Devices put keychains at the top of the tree so that they can be used across. Sue Hares: Put ACLs and filters at the same level. Dean: do you think they (keychain and ACLs) should be at the same level Benoit: how does it makes sense for the routing design team to define a model that impacts models outside of the routing area? Dean: Splitting it up into different WGs would be complex and cause the models to get watered down Lou: this draft is informational, should have no impact. Lou: do we want a structure or not? Chris Hopps: Benoit, would it be ok if we just talked to other groups and kept the document progressing in routing area/wg? Lou: when we lost /device, we decided to make the draft Informational guy in red t-shirt (Jeff Tantsura?): would like to see it be stronger than Informational Jeff Haas ???: Jason Sterne: RFC LNE and NI ... rest can be informational Chris Hopps: some think there should be no structure Andy B: don't go with absolute paths Lou: call for support (strong guideline vs Informational) Strong Guideline: 8 Informational: 6 Go away: 6 Don't care: 1 12 Title: Subscribing to YANG datastore push updates Draft: http://tools.ietf.org/html/draft-ietf-netconf-yang-push Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-11.pptx Presenter: Eric Voit Notes: Chairs: The details of this draft belong in NetConf. Discussion belongs there. 13 Title: YANG Data Model for Configuration Scheduling Draft: http://tools.ietf.org/html/draft-liu-netmod-yang-schedule Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-13.pptx Presenter: Xufeng Liu Notes: Jason Sterne: have you considered any alternate (point-cut like) approach of having a list that can point to subtrees where scheduling is desired? Kent Watsen: Why do we want to standardize a grouping? Lou: It didn't seem to belong to teas wg. Scheduling was beyond the scope of the te topology wg document. Jeff Haas: I2RS had discussion on calendar objects as part of ephemeral state. This is a nice mechanism since the info is not ephemeral. Andy: All sibling nodes and sub-trees are activated/deactivated based on schedule? How does this work with validation? Xufeng: The schema tree won't change. This is applicable to object. Jeff Haas: This does not affect the config. 14 Title: BBF YANG Models Draft: n/a Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-14.pptx Presenter: William Lupton Notes: Benoit: something about the guidelines draft? Balaz: can you put your mouldes on IETF github? Chairs: please discuss on list 15 Title: Manufacturer Usage Descriptions Draft: https://tools.ietf.org/html/draft-lear-ietf-netmod-mud-00 Draft: https://tools.ietf.org/html/draft-lear-ietf-netmod-acl-dnsname-00 Slides: http://www.ietf.org/proceedings/95/slides/slides-95-netmod-14.pptx Presenter: Eliot Lear Notes: Adjourn 19:40 From nobody Tue Apr 5 02:13:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2076212D147 for ; Tue, 5 Apr 2016 02:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYiNyhVRVI45 for ; Tue, 5 Apr 2016 02:13: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 ACA5E12D133 for ; Tue, 5 Apr 2016 02:13:50 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id CF53F1AE035B; Tue, 5 Apr 2016 11:13:48 +0200 (CEST) Date: Tue, 05 Apr 2016 11:13:48 +0200 (CEST) Message-Id: <20160405.111348.2035777235753418640.mbj@tail-f.com> To: jason.sterne@nokia.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] a few editorial comments on structural-mount-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 09:13:57 -0000 Hi Jason, "Sterne, Jason (Nokia - CA)" wrote: > Hello, > > A couple of minor points for the structural mount draft that I > noticed while reading it recently: > > The XML instance data in Appendix B seems to have inside the > context but that doesn't match the YANG model above it. You're right, I'll fix. > It would be great to show an example for section 3.2. There is such an example in Appendix B.1. I'll add a reference to that example from 3.2. /martin From nobody Tue Apr 5 02:38:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF112D197 for ; Tue, 5 Apr 2016 02:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDWCTRxbeANu for ; Tue, 5 Apr 2016 02:38:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CABF312D10B for ; Tue, 5 Apr 2016 02:38:23 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 1AE721AE035B; Tue, 5 Apr 2016 11:38:23 +0200 (CEST) Date: Tue, 05 Apr 2016 11:38:22 +0200 (CEST) Message-Id: <20160405.113822.1614298419822308565.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 09:38:26 -0000 Hi, Kent Watsen wrote: > [As a contributor] > > Note: this is a -00 document, but only because the draft's name > changed. In reality this is like a > draft-voit-netmod-peer-mount-requirements-04. Looking at the diffs, > there aren't many changes, mostly cleanup and adding the "schema > mount" concept. That is, the new "yang mount" term is use to cover > all of "schema mount", "alias mount", and "peer mount". > > My comment is mostly high-level. I'm wondering about the need for > this draft to include schema mount at all. That is, a schema mount > solution draft is now an adopted WG item, and I'm unsure if the > authors of that draft are looking to this one to define requirements. > Perhaps the goal is to define the umbrella term "yang mount", but to > be honest, I don't really see a need to have a term that spans both > schema and data mounts. I'm not sure how others feel about this, but > my thoughts are that we should define terms like: > > - scheme-mount > - data-mount > - remote data mount (a.k.a. peer mount) > - local data mount (a.k.a. alias mount) > > More so than: > > yang-mount > - scheme-mount > - alias-mount > - peer-mount Listening to Eric's presentation yesterday, I realized that I have a slightly different view on these terms. I prefer to separate the *schema* (data model) from how things are implemented. The various proposals for specific implementations (peer mount and alias mount etc) all need a "schema mount" to take of defining a proper data model. (This was the whole point of defining structural-mount...) For example, suppose we have: container logical-devices { list logical-device { key name; ... yangmnt:mount-point logical-device; } } With the associated yang-library, a client might learn that ietf-interfaces is mounted under the "logical-device" mount mount. Now, the client knows that there are paths: /logical-devices/logical-device/if:interfaces/if:interface but the client doesn't necessarily have to know if the the interfaces data is implemented w/ "peer mount" or some other mechanism. So, in my view, we have: schema mount | +---- peer mount +---- alias mount +---- other cool mount As a concrete example, peer mount might be used like this (example taken from draft-clemm-netmod-mount-03): import ietf-schema-mount { prefix yangmnt; } import ietf-peer-mount { prefix pmnt; } ... list network-element { key "element-id"; leaf element-id { type element-ID; } container element-address { ... // choice definition that allows to specify // host name, // IP addresses, URIs, etc } yangmnt:mount-point "interfaces" { pmnt:target "./element-address"; pmnt:subtree "/if:interfaces"; } ... } A client that knows about the generic, abstract schema mount can work with this, without knowing anything of the specific implementation of peer mount. [Actually, since peer mount is just one implementation technique, I'd prefer to decouple the definition of this implementation detail from the data model, but that's a different topic.] /martin From nobody Tue Apr 5 03:05:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58B912D50C for ; Tue, 5 Apr 2016 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql6DRecdye2c for ; Tue, 5 Apr 2016 03:05:54 -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 5FB0312D1ED for ; Tue, 5 Apr 2016 03:05:49 -0700 (PDT) Received: (qmail 13545 invoked by uid 0); 5 Apr 2016 10:05:42 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 5 Apr 2016 10:05:42 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id eh5a1s00e2SSUrH01h5d1V; Tue, 05 Apr 2016 11:05:39 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=fq3DThPIIJnwEtLcq_sA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=+AO4JEtZ4jLE81s9I9+QjpStn8Dnsx8iP1RS9beK06M=; b=FgzazG6SxDkYy5aoLCgeDhBwOG efIk6ABm0Yfm21bbazJPt9HELHdtrryORl7eErbFEpE5RhJFa3/obl8Q6NLWk4tKC6qx88Gvnpxhi qOFkgitsUL+tFw7+byIWjINzd; Received: from box313.bluehost.com ([69.89.31.113]:58447 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anNrd-0001Nw-OQ; Tue, 05 Apr 2016 04:05:37 -0600 To: netmod WG References: <56F01EB7.5000804@labn.net> From: Lou Berger Message-ID: <57038DEC.9020703@labn.net> Date: Tue, 5 Apr 2016 06:05:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56F01EB7.5000804@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod chairs Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-structural-mount-02 as draft-ietf-netmod-schema-mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 10:05:56 -0000 This poll is complete and the document is adopted, Authors, Please resubmit the draft with the only change being to rename the draft to draft-ietf-netmod-schema-mount-00 Thank you! Lou (and co-chairs) On 3/21/2016 12:17 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-bjorklund-netmod-structural-mount-02 a working group document with > the name draft-ietf-netmod-schema-mount. > > This adoption is a little bit unusual in that, per our last interim, we > know that this document is likely to see significant changes in > technical (solution) details as it progresses through normal WG process. > And the -01 version is expected to be done in combination with > Lada/draft-lhotka-netmod-ysdl. > > Please send email to the list indicating "yes/support" or "no/do not > support". Note that Yes indicates your support for working on a schema > mount solution, rather than the specific solution. If you have specific > technical proposals/suggestions that you'd like to voice please feel > free to also do so - but please use a new/different thread so we can > keep the process and technical discussions separate. > > The poll ends April 4, 2016 > (after our in-person meeting, but authors / main contributors are not > expected to be present in BA. So please discuss on list.) > > Thank you, > > NETMOD Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Apr 5 04:57:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A6C12D505 for ; Tue, 5 Apr 2016 04:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfongul8IaV9 for ; Tue, 5 Apr 2016 04:57: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 1229312D1D6 for ; Tue, 5 Apr 2016 04:57:00 -0700 (PDT) Received: from [10.10.0.186] (unknown [190.111.246.211]) by mail.nic.cz (Postfix) with ESMTPSA id 182331800CC; Tue, 5 Apr 2016 13:56:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459857418; bh=NJgf9ryvgf8DhYf2b2FcETODp0akLIrVZag1r0+AbPY=; h=From:Date:To; b=msFDaFYLrGZhZ+D3tTs2fZvnopRINkm3MoX2gWygTMgxNQFg21fB7kiE09zZsKE3u SikZifzhKAv38VTDp7kg7IrdEsedu+PbdvMxggC28o4vy+Ta1T9cEPKVIAqoLxlEGQ Qe7Wc+4IcOIZx5yk9orHbKLaTiIhIBEsJclS1KqI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160405.113822.1614298419822308565.mbj@tail-f.com> Date: Tue, 5 Apr 2016 08:56:53 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <16B50CA8-0076-413D-87D1-FFBE6A54175C@nic.cz> References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 11:57:04 -0000 > On 05 Apr 2016, at 06:38, Martin Bjorklund wrote: >=20 > Hi, >=20 > Kent Watsen wrote: >> [As a contributor] >>=20 >> Note: this is a -00 document, but only because the draft's name >> changed. In reality this is like a >> draft-voit-netmod-peer-mount-requirements-04. Looking at the diffs, >> there aren't many changes, mostly cleanup and adding the "schema >> mount" concept. That is, the new "yang mount" term is use to cover >> all of "schema mount", "alias mount", and "peer mount". >>=20 >> My comment is mostly high-level. I'm wondering about the need for >> this draft to include schema mount at all. That is, a schema mount >> solution draft is now an adopted WG item, and I'm unsure if the >> authors of that draft are looking to this one to define requirements. >> Perhaps the goal is to define the umbrella term "yang mount", but to >> be honest, I don't really see a need to have a term that spans both >> schema and data mounts. I'm not sure how others feel about this, but >> my thoughts are that we should define terms like: >>=20 >> - scheme-mount >> - data-mount >> - remote data mount (a.k.a. peer mount) >> - local data mount (a.k.a. alias mount) >>=20 >> More so than: >>=20 >> yang-mount >> - scheme-mount >> - alias-mount >> - peer-mount >=20 > Listening to Eric's presentation yesterday, I realized that I have a > slightly different view on these terms. >=20 > I prefer to separate the *schema* (data model) from how things are > implemented. The various proposals for specific implementations (peer Yes, I expressed this opinion already in Yokohama. Moreover, Eliot's = presentation indicated that there are use cases in which YANG is used = for modelling data outside the context of a management protocol. So IMO = it is legitimate to require that even with schema mount it is possible = to write a compact specification of the complete schema. Such a schema = is static as before, the only change is that we have more flexibility in = composing the modules, whereas currently they can be only put side by = side. Also, there needn't be any mechanism like peer mount, all data may = be local. Perhaps this use case is really different from the more dynamic = situation where the server needs to fetch the subschemas at runtime and = the data are contributed by an external entity. Lada > mount and alias mount etc) all need a "schema mount" to take of > defining a proper data model. (This was the whole point of defining > structural-mount...) >=20 > For example, suppose we have: >=20 > container logical-devices { > list logical-device { > key name; > ... > yangmnt:mount-point logical-device; > } > } >=20 > With the associated yang-library, a client might learn that > ietf-interfaces is mounted under the "logical-device" mount mount. >=20 > Now, the client knows that there are paths: >=20 > /logical-devices/logical-device/if:interfaces/if:interface >=20 > but the client doesn't necessarily have to know if the the interfaces > data is implemented w/ "peer mount" or some other mechanism. >=20 >=20 > So, in my view, we have: >=20 > schema mount > | > +---- peer mount > +---- alias mount > +---- other cool mount >=20 >=20 >=20 > As a concrete example, peer mount might be used like this (example > taken from draft-clemm-netmod-mount-03): >=20 > import ietf-schema-mount { > prefix yangmnt; > } > import ietf-peer-mount { > prefix pmnt; > } >=20 > ... >=20 > list network-element { > key "element-id"; > leaf element-id { > type element-ID; > } > container element-address { > ... // choice definition that allows to specify > // host name, > // IP addresses, URIs, etc > } > yangmnt:mount-point "interfaces" { > pmnt:target "./element-address"; > pmnt:subtree "/if:interfaces"; > } > ... > } >=20 >=20 > A client that knows about the generic, abstract schema mount can work > with this, without knowing anything of the specific implementation of > peer mount. >=20 > [Actually, since peer mount is just one implementation technique, I'd > prefer to decouple the definition of this implementation detail from > the data model, but that's a different topic.] >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 5 07:09:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981B712D1D9 for ; Tue, 5 Apr 2016 07:09: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOpDvjsy2BxB for ; Tue, 5 Apr 2016 07:09:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4B0912D50A for ; Tue, 5 Apr 2016 07:09:40 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id CEC961AE035B; Tue, 5 Apr 2016 16:09:38 +0200 (CEST) Date: Tue, 05 Apr 2016 16:09:38 +0200 (CEST) Message-Id: <20160405.160938.373639996260156222.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <2448C449-A257-40FE-9C97-7B05700F00EE@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] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:09:44 -0000 Andy Bierman wrote: > On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: > > > > > > On 04 Apr 2016, at 16:15, Andy Bierman wrote: > > > > > > > > > On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: > > > > > > > On 04 Apr 2016, at 15:57, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > I do not see any reason to prohibit this use of action-stmt > > > > or notification-stmt. If the list has no keys then there is > > > > no need to distinguish instances because the data model defines > > > > no such semantics. > > > > > > If such a keyless list has multiple entries, how can an action request > > specify which of the list entries it is tied to? > > > > > > it must be be relevant to distinguish instances or else the designer > > > would have defined a key. > > > > > > > > > > > > > > What breaks if this is allowed? > > > > > > The behaviour is undefined. > > > > > > > > > > > > IMO lists without keys are a really bad idea. > > > But the semantics are fully defined according to YANG. > > > If the list has no keys then there is no instance information > > > relevant to the data model. The action or notification is passed > > > all the keys (happens to be zero in this case). > > > > To my understanding, each action request has to specify the unique > > instance that's the "receiver" of the action. If this cannot be done, it is > > IMO a problem in the spec. > > > > An alternative implementation of actions would be to use instance > > identifiers instead of an explicit data hierarchy, and in this case it > > would be possible to use indices for identifying entries. But the hierarchy > > provides no such option. > > > > It's not a big issue, but there is already a couple of rules regarding > > where actions can and cannot be defined, so this would be another one > > intended to avoid potential ambiguity. > > > > > I agree actions were not considered when keyless lists were allowed in YANG. > There was an assumption that this data is always read-only that is no > longer true in YANG 1.1. > > I certainly prefer adding a restriction than redoing the way actions work. > Using /foo[5] does not work because entry "5" might move or get deleted, > so the numbering is not stable. How about: An action MUST NOT have any ancestor node that is a list node without a "key" statement. (and ditto for notifs) /martin From nobody Tue Apr 5 07:39:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3F912D566 for ; Tue, 5 Apr 2016 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSsncRpKaAsB for ; Tue, 5 Apr 2016 07:38:57 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D5512D1CE for ; Tue, 5 Apr 2016 07:38:56 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id vo2so10728192lbb.1 for ; Tue, 05 Apr 2016 07:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8pV1KYu8Eay9KNmZWUk8Rzcy3U2Upvg706ltQbI0neA=; b=Vh/ZY1xN8WGd4q7DH1X5XKAKxeDLu4wHAG6DDF039nFiHhkt7yioWphbXUoKNlQHvi WdvG5YgZAj8O2E5D5im81kcq53oLQ5MFcrY3eUcF0oNHPyyesp2eTxNK3l8VqvnaRBf4 HrtF41XHVhSiQQ6wfaZjaMwfiR15yDeqUAecP4vCZi43nAbVDbPFD9A9EDLvlKjDWRVz /0LldckE3TVOZ4omoveWkhfMua1qU5pVY4hh6IGoZL0jpwzTl0Ois7kC4J4lOm2Aw+Qu uV17WNIIx20NYXCscFvmrFlVeXzT7hWkkAYArOnrH6Kfm2m0AuepfM1noWpc4meYzZUo z1mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8pV1KYu8Eay9KNmZWUk8Rzcy3U2Upvg706ltQbI0neA=; b=fupneVB6mFppajrvkUcjYXtf92HzTCo/L7dJvjaaFohUn9BcbEo2JrtFOf8b39vWGT N8a79eyRqS9/e5lfuoQk5/KMClCAbTHhgyK7t/CCSHlJQRSlPZ7zpNmrwM4vUBPh8ykQ yoicRNP5RmpRSjiqv5F9aruDwaNvYQ6hezau+jMHlStksAs6rNlanfVfx4B6WhV9dqvm IaXsV+JYM4kEsld0oMv1PLk5ENIuyHIxYohLnMeWMhHAxn1AYj2FxOkK7u0ziT4jY7ss 8ODAC2JQhlf2FfFqBEWbMlK3CuuJ6MVFuKEDDEpxjvXoD15fzNqVt/tai33LyWQePGGF 2ktw== X-Gm-Message-State: AD7BkJL5canMdvK5zcBuxZjopnSPfpbz3iQQyw8V4G33/oXaPzaAsL6DUbVTFOai/0P6qijif54d0E0UMv0bbg== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr4399800lbb.119.1459867134509; Tue, 05 Apr 2016 07:38:54 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 5 Apr 2016 07:38:54 -0700 (PDT) In-Reply-To: <20160405.160938.373639996260156222.mbj@tail-f.com> References: <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> <20160405.160938.373639996260156222.mbj@tail-f.com> Date: Tue, 5 Apr 2016 07:38:54 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b3a8bd2f8d871052fbdcdd3 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:39:06 -0000 --047d7b3a8bd2f8d871052fbdcdd3 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 7:09 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: > > > > > > > > > On 04 Apr 2016, at 16:15, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka > wrote: > > > > > > > > > On 04 Apr 2016, at 15:57, Andy Bierman wrote: > > > > > > > > > > Hi, > > > > > > > > > > I do not see any reason to prohibit this use of action-stmt > > > > > or notification-stmt. If the list has no keys then there is > > > > > no need to distinguish instances because the data model defines > > > > > no such semantics. > > > > > > > > If such a keyless list has multiple entries, how can an action > request > > > specify which of the list entries it is tied to? > > > > > > > > it must be be relevant to distinguish instances or else the designer > > > > would have defined a key. > > > > > > > > > > > > > > > > > > What breaks if this is allowed? > > > > > > > > The behaviour is undefined. > > > > > > > > > > > > > > > > IMO lists without keys are a really bad idea. > > > > But the semantics are fully defined according to YANG. > > > > If the list has no keys then there is no instance information > > > > relevant to the data model. The action or notification is passed > > > > all the keys (happens to be zero in this case). > > > > > > To my understanding, each action request has to specify the unique > > > instance that's the "receiver" of the action. If this cannot be done, > it is > > > IMO a problem in the spec. > > > > > > An alternative implementation of actions would be to use instance > > > identifiers instead of an explicit data hierarchy, and in this case it > > > would be possible to use indices for identifying entries. But the > hierarchy > > > provides no such option. > > > > > > It's not a big issue, but there is already a couple of rules regarding > > > where actions can and cannot be defined, so this would be another one > > > intended to avoid potential ambiguity. > > > > > > > > I agree actions were not considered when keyless lists were allowed in > YANG. > > There was an assumption that this data is always read-only that is no > > longer true in YANG 1.1. > > > > I certainly prefer adding a restriction than redoing the way actions > work. > > Using /foo[5] does not work because entry "5" might move or get deleted, > > so the numbering is not stable. > > How about: > > An action MUST NOT have any ancestor node that is a list node without > a "key" statement. > OK > > (and ditto for notifs) > > > /martin > --047d7b3a8bd2f8d871052fbdcdd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 7:09 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> >
> > > On 04 Apr 2016, at 16:15, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > >
> > > On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > > On 04 Apr 2016, at 15:57, Andy Bierman <andy@yumaworks.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I do not see any reason to prohibit this use of action-= stmt
> > > > or notification-stmt.=C2=A0 If the list has no keys the= n there is
> > > > no need to distinguish instances because the data model= defines
> > > > no such semantics.
> > >
> > > If such a keyless list has multiple entries, how can an acti= on request
> > specify which of the list entries it is tied to?
> > >
> > > it must be be relevant to distinguish instances or else the = designer
> > > would have defined a key.
> > >
> > >
> > > >
> > > > What breaks if this is allowed?
> > >
> > > The behaviour is undefined.
> > >
> > >
> > >
> > > IMO lists without keys are a really bad idea.
> > > But the semantics are fully defined according to YANG.
> > > If the list has no keys then there is no instance informatio= n
> > > relevant to the data model.=C2=A0 The action or notification= is passed
> > > all the keys (happens to be zero in this case).
> >
> > To my understanding, each action request has to specify the uniqu= e
> > instance that's the "receiver" of the action. If th= is cannot be done, it is
> > IMO a problem in the spec.
> >
> > An alternative implementation of actions would be to use instance=
> > identifiers instead of an explicit data hierarchy, and in this ca= se it
> > would be possible to use indices for identifying entries. But the= hierarchy
> > provides no such option.
> >
> > It's not a big issue, but there is already a couple of rules = regarding
> > where actions can and cannot be defined, so this would be another= one
> > intended to avoid potential ambiguity.
> >
> >
> I agree actions were not considered when keyless lists were allowed in= YANG.
> There was an assumption that this data is always read-only that is no<= br> > longer true in YANG 1.1.
>
> I certainly prefer adding a restriction than redoing the way actions w= ork.
> Using /foo[5] does not work because entry "5" might move or = get deleted,
> so the numbering is not stable.

How about:

=C2=A0 An action MUST NOT have any ancestor node that is a list node withou= t
=C2=A0 a "key" statement.

OK<= /div>
=C2=A0

(and ditto for notifs)


/martin

--047d7b3a8bd2f8d871052fbdcdd3-- From nobody Tue Apr 5 09:40:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5212D76A for ; Tue, 5 Apr 2016 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er2XkgZUnNi0 for ; Tue, 5 Apr 2016 09:40:48 -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 A752F12D739 for ; Tue, 5 Apr 2016 09:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1060; q=dns/txt; s=iport; t=1459874448; x=1461084048; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WllVjvlRf//AIHLxP31BpMyWzZ5dnv20RsbL0qNcv2E=; b=kYFH5Ysm2wHu9zTPZwUvQbCq+DYnmAtaDCvtFuYKnuUfzmFINtlddUnu P4pFjkweNGh45d6hXUzLxSA+J0T+SaCtbR2Ks9RY+MskMngU7LneehiNN tk+RQR0JGaZHY/ejQH53tK/HRmbFsRngfSYQOWr9YC4tAYx2nFlYuOVtg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBy6QNX/5NdJa1egzdTgQO7MAENg?= =?us-ascii?q?XIhhgqBHTgUAQEBAQEBAWUcC4RIIxFXASICJgIEMBUSBIg6Dp5hj12RaQEBAQE?= =?us-ascii?q?BAQEDAQEBAQEBAQEBEwR8hSSBdYoVK4IrBZgBAYVyiBWPD48ZAR4BAUKDaYglf?= =?us-ascii?q?gEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,444,1454976000"; d="scan'208";a="257050594" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2016 16:40:47 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u35GelHj016089 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Apr 2016 16:40:47 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 11:40:45 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 11:40:45 -0500 From: "Rajiv Asati (rajiva)" To: "netmod@ietf.org" Thread-Topic: rfc6087bis - 2 comments for your consideration Thread-Index: AQHRj1nmEXke33GBbUSsnADZOKbacQ== Date: Tue, 5 Apr 2016 16:40:45 +0000 Message-ID: <2B3AB1C2-417B-49A2-A4EE-9A7BE171C61D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.126.21] Content-Type: text/plain; charset="utf-8" Content-ID: <81DC0AAA42DDE545A562456E49D9F8F3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [netmod] rfc6087bis - 2 comments for your consideration X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:40:50 -0000 DQoxKSBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gZXhwYW5kIHNlY3Rpb24gNC4zIGEgYml0IG1vcmUg dG8gYWRkIGFub3RoZXIgZXhhbXBsZSBvZiB0aGUgdHJlZSB3aXRoIHNvbWUgc3BlY2lmaWNzIHRo YXQgY2F0ZXIgdG8gbW9zdCBvZiB0aGUgcHJvdG9jb2xzIHdvcmsgYmVpbmcgZG9uZSBpbiBvdGhl ciBXR3MuIFNvbWV0aGluZyBhbG9uZyB0aGUgbGluZSBvZiB0aGUgZm9sbG93aW5nOg0KDQoJQ29u ZmlnIChpbnRlbmRlZCkNCglTdGF0ZSAoZGVyaXZlZCB3aXRoIG9yIHdpdGhvdXQgYXBwbGllZCkg DQoJTm90aWZpY2F0aW9uDQoJUlBDDQoJLi4gDQoNCg0KQXV0aG9ycyBvZiBudW1lcm91cyBZQU5H IG1vZGVscyBjb3VsZCByZWZlciB0byB0aGUgYWJvdmUgZ3VpZGVsaW5lIGFuZCB1c2UgaXQgYXMg YSBzdGFydGluZyBwb2ludC4NCg0KMikgSXQgd291bGQgYmUgaGVscGZ1bCBpZiB0aGUgZ3VpZGVs aW5lIHN1Z2dlc3RlZCBhIHByZWZlcmVuY2UgKHllcywgcmVjb21tZW5kYXRpb24gd291bGQgYmUg YmV0dGVyKSBmb3Iga2VlcGluZyAgYXBwbGllZCBzdGF0ZSBhbmQgZGVyaXZlZCBzdGF0ZSB0b2dl dGhlciAoaW4gdGhlIHNhbWUgY29udGFpbmVyLCBwZXIgZWFjaCBmaWVsZCkgb3Igc2VwYXJhdGUg KGNvbnRhaW5lcnMpOyANCg0KLS0NCkNoZWVycywNClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVk IEVuZ2luZWVyLCBDaXNjbw0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1uZXRtb2QtcmZjNjA4N2Jpcw0KDQoNCg0KDQoNCg== From nobody Tue Apr 5 09:52:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3FE12D164 for ; Tue, 5 Apr 2016 09:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id again-vkHLSg for ; Tue, 5 Apr 2016 09:52:13 -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 4B0A312D0F3 for ; Tue, 5 Apr 2016 09:52:12 -0700 (PDT) Received: from [10.10.0.186] (unknown [190.111.246.211]) by mail.nic.cz (Postfix) with ESMTPSA id 3E877180134; Tue, 5 Apr 2016 18:52:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459875131; bh=3tpz9f/PKrBJYA7ivprepZP8KJOyia8swstq4jK2ujg=; h=From:Date:To; b=PwwmiJlxNUEuKm5seV+i8E7lrFAdcdhevHfU9iTwS6cT16Wd0kE7qwXOLY0O5m+dn qIRumJNNAnrfpYJxi0t72deELPRsRam8hO8es5yIxSJKkDCiDZtouPbh9MNOQDb5It xN8Cg0bqW0grD7yJIZ7G+NdgSl9TcoJAfSheX0YE= Content-Type: multipart/alternative; boundary="Apple-Mail=_849ED7AC-A817-4C65-8046-5882F9AE4050" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160405.160938.373639996260156222.mbj@tail-f.com> Date: Tue, 5 Apr 2016 13:52:04 -0300 Message-Id: <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> References: <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> <20160405.160938.373639996260156222.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:52:15 -0000 --Apple-Mail=_849ED7AC-A817-4C65-8046-5882F9AE4050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: >> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka = wrote: >>=20 >>>=20 >>>> On 04 Apr 2016, at 16:15, Andy Bierman wrote: >>>>=20 >>>>=20 >>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka = wrote: >>>>=20 >>>>> On 04 Apr 2016, at 15:57, Andy Bierman wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I do not see any reason to prohibit this use of action-stmt >>>>> or notification-stmt. If the list has no keys then there is >>>>> no need to distinguish instances because the data model defines >>>>> no such semantics. >>>>=20 >>>> If such a keyless list has multiple entries, how can an action = request >>> specify which of the list entries it is tied to? >>>>=20 >>>> it must be be relevant to distinguish instances or else the = designer >>>> would have defined a key. >>>>=20 >>>>=20 >>>>>=20 >>>>> What breaks if this is allowed? >>>>=20 >>>> The behaviour is undefined. >>>>=20 >>>>=20 >>>>=20 >>>> IMO lists without keys are a really bad idea. >>>> But the semantics are fully defined according to YANG. >>>> If the list has no keys then there is no instance information >>>> relevant to the data model. The action or notification is passed >>>> all the keys (happens to be zero in this case). >>>=20 >>> To my understanding, each action request has to specify the unique >>> instance that's the "receiver" of the action. If this cannot be = done, it is >>> IMO a problem in the spec. >>>=20 >>> An alternative implementation of actions would be to use instance >>> identifiers instead of an explicit data hierarchy, and in this case = it >>> would be possible to use indices for identifying entries. But the = hierarchy >>> provides no such option. >>>=20 >>> It's not a big issue, but there is already a couple of rules = regarding >>> where actions can and cannot be defined, so this would be another = one >>> intended to avoid potential ambiguity. >>>=20 >>>=20 >> I agree actions were not considered when keyless lists were allowed = in YANG. >> There was an assumption that this data is always read-only that is no >> longer true in YANG 1.1. >>=20 >> I certainly prefer adding a restriction than redoing the way actions = work. >> Using /foo[5] does not work because entry "5" might move or get = deleted, >> so the numbering is not stable. >=20 > How about: >=20 > An action MUST NOT have any ancestor node that is a list node without > a "key" statement. Or rather: An action MUST NOT be defined for a node that is a list without a "key" = statement, or has a list node without a "key" statement as its ancestor. Lada >=20 > (and ditto for notifs) >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_849ED7AC-A817-4C65-8046-5882F9AE4050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 05 Apr = 2016, at 11:09, Martin Bjorklund <mbj@tail-f.com> wrote:

Andy= Bierman <andy@yumaworks.com> wrote:
On Mon, = Apr 4, 2016 at 1:08 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:


On 04 Apr 2016, at = 16:15, Andy Bierman <andy@yumaworks.com> wrote:


On Mon, Apr 4, 2016 at 12:01 PM, Ladislav = Lhotka <lhotka@nic.cz> wrote:

On 04 Apr 2016, at = 15:57, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I do not see any reason to = prohibit this use of action-stmt
or notification-stmt. =  If the list has no keys then there is
no need to = distinguish instances because the data model defines
no = such semantics.

If such a = keyless list has multiple entries, how can an action request
specify which of the list entries it is tied = to?

it = must be be relevant to distinguish instances or else the designer
would have defined a key.



What = breaks if this is allowed?

The = behaviour is undefined.



IMO lists without keys are a really bad idea.
But= the semantics are fully defined according to YANG.
If the = list has no keys then there is no instance information
relevant to the data model.  The action or notification = is passed
all the keys (happens to be zero in this = case).

To my understanding, = each action request has to specify the unique
instance = that's the "receiver" of the action. If this cannot be done, it is
IMO a problem in the spec.

An = alternative implementation of actions would be to use instance
identifiers instead of an explicit data hierarchy, and in = this case it
would be possible to use indices for = identifying entries. But the hierarchy
provides no such = option.

It's not a big issue, but there is = already a couple of rules regarding
where actions can and = cannot be defined, so this would be another one
intended = to avoid potential ambiguity.


I agree actions were not considered when keyless = lists were allowed in YANG.
There was an assumption that = this data is always read-only that is no
longer true in = YANG 1.1.

I certainly prefer adding a = restriction than redoing the way actions work.
Using = /foo[5] does not work because entry "5" might move or get deleted,
so the numbering is not stable.

How about:

 An action MUST = NOT have any ancestor node that is a list node without
 a "key" statement.


Or = rather:

An action = MUST NOT be defined for a node that is a list without a "key" statement, = or has a list node without a "key" statement as its ancestor.

Lada


(and ditto for notifs)


/martin

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




= --Apple-Mail=_849ED7AC-A817-4C65-8046-5882F9AE4050-- From nobody Tue Apr 5 09:54:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CD612D0F3 for ; Tue, 5 Apr 2016 09:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XULf1QPdLe-Z for ; Tue, 5 Apr 2016 09:54: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 B40E312D52B for ; Tue, 5 Apr 2016 09:54:34 -0700 (PDT) Received: from [10.10.0.186] (unknown [190.111.246.211]) by mail.nic.cz (Postfix) with ESMTPSA id BA1C1180117; Tue, 5 Apr 2016 18:54:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459875273; bh=kIjvxsZmcQsGkcX4mMOD+cjRQi9HJDuxz8qPDAAIGrc=; h=From:Date:To; b=wIqkx68eaP6005LDfBok1+lj00PtHuSItSwMNI8jHhMV0j47Di27WU5JLFooGp8JW xO8lA+y8CR3tDQ2lET6s++v5RimmlU8KA2sq/zkUCQaxp4Xa8Qpl4W0lPnAc4Yqf+V 20yUVovaNnkkLcy59Smn9TiKWBZK4qBMka/IxmMk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> Date: Tue, 5 Apr 2016 13:54:27 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:54:37 -0000 I just noticed a typo in fourth paragraph of sec. 7.15: s/an the top-level/at the top-level/ Lada > On 05 Apr 2016, at 13:52, Ladislav Lhotka wrote: >=20 >>=20 >> On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: >>=20 >> Andy Bierman wrote: >>> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka = wrote: >>>=20 >>>>=20 >>>>> On 04 Apr 2016, at 16:15, Andy Bierman wrote: >>>>>=20 >>>>>=20 >>>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka = wrote: >>>>>=20 >>>>>> On 04 Apr 2016, at 15:57, Andy Bierman = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I do not see any reason to prohibit this use of action-stmt >>>>>> or notification-stmt. If the list has no keys then there is >>>>>> no need to distinguish instances because the data model defines >>>>>> no such semantics. >>>>>=20 >>>>> If such a keyless list has multiple entries, how can an action = request >>>> specify which of the list entries it is tied to? >>>>>=20 >>>>> it must be be relevant to distinguish instances or else the = designer >>>>> would have defined a key. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> What breaks if this is allowed? >>>>>=20 >>>>> The behaviour is undefined. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> IMO lists without keys are a really bad idea. >>>>> But the semantics are fully defined according to YANG. >>>>> If the list has no keys then there is no instance information >>>>> relevant to the data model. The action or notification is passed >>>>> all the keys (happens to be zero in this case). >>>>=20 >>>> To my understanding, each action request has to specify the unique >>>> instance that's the "receiver" of the action. If this cannot be = done, it is >>>> IMO a problem in the spec. >>>>=20 >>>> An alternative implementation of actions would be to use instance >>>> identifiers instead of an explicit data hierarchy, and in this case = it >>>> would be possible to use indices for identifying entries. But the = hierarchy >>>> provides no such option. >>>>=20 >>>> It's not a big issue, but there is already a couple of rules = regarding >>>> where actions can and cannot be defined, so this would be another = one >>>> intended to avoid potential ambiguity. >>>>=20 >>>>=20 >>> I agree actions were not considered when keyless lists were allowed = in YANG. >>> There was an assumption that this data is always read-only that is = no >>> longer true in YANG 1.1. >>>=20 >>> I certainly prefer adding a restriction than redoing the way actions = work. >>> Using /foo[5] does not work because entry "5" might move or get = deleted, >>> so the numbering is not stable. >>=20 >> How about: >>=20 >> An action MUST NOT have any ancestor node that is a list node = without >> a "key" statement. >=20 >=20 > Or rather: >=20 > An action MUST NOT be defined for a node that is a list without a = "key" statement, or has a list node without a "key" statement as its = ancestor. >=20 > Lada >=20 >>=20 >> (and ditto for notifs) >>=20 >>=20 >> /martin >=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 Tue Apr 5 09:55:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0334A12D7B8 for ; Tue, 5 Apr 2016 09:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5DNxAi4o4TY for ; Tue, 5 Apr 2016 09:55:41 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6433212D798 for ; Tue, 5 Apr 2016 09:55:40 -0700 (PDT) Received: by mail-lb0-x22d.google.com with SMTP id vo2so13334484lbb.1 for ; Tue, 05 Apr 2016 09:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Q/hxvd5aQnIg3i4fK+5ViWMztGQhEiKokjxzqYApsz0=; b=wubsT1tM+C9wbkpOmY8eM3X8p+HMY8Dq9DUGTi3SFgr9dX/cNUHR2O/5g7rXABl4ci b755nSEgyQfDAgzbc4iU2JX9qKGrPVkUBg5+6itKyS9iWcQXx5j/nlDmt5QK8DZwnCjr o4KgEqQoyBRXJkhScjmqcHolIhqnB4MXD0sA6WXrA8yrW2n2l+uIkJVDFRTwEWusrkBZ pRtm7dd0Ugi4NM/u32VO8/ycGLCow12LZtlc8OdJjoANaVCH2Pp86gcouLUOmPobBcZ9 dErTgwzRledpc5+MmEbTsHvTDfqElnFN5q+CQRmCdHtCNe+Kc2wQ2I5qcxvsEu1OHzec l9ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Q/hxvd5aQnIg3i4fK+5ViWMztGQhEiKokjxzqYApsz0=; b=NzrfhyVbZq9hjdUZ8ZOTKbDPDdxkyi/BN3qMcq2zrp0lPQvK743SMgMdWoDQ8quWJU 2jdEYhwEqzFyN9+5EL1fZX2Q8s9sO9synkCTNuHdkX06kiXfzfZmoWWtqJzf9oPyRmhQ EhbFRK3oPwAok5OMko2JRZbyexEvZuPLpjNnoq3dMt1bRtSU2tVBipMcKjFuuFdl2/RS RfutW3BDUIv7/M4v741qYegttdLHbYI6hDWElmsxoM8oJiEK9IGYMGg6YccJTrDAiYKc CYMiIAnncFzTJwFpG7w503TjwjL0w7yHFdpS0HIaP7YKpM8jRsyW3szPULDS7sORK2KT 3L3A== X-Gm-Message-State: AD7BkJL4nH/yvzG+35gOhSH8EEU0wyEO70UjC7gMd5/hEkw4dB0e++uNEhuOPDQGoeJgCRBbsju36HVGbkQ8Mw== MIME-Version: 1.0 X-Received: by 10.112.56.43 with SMTP id x11mr4864714lbp.145.1459875338551; Tue, 05 Apr 2016 09:55:38 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 5 Apr 2016 09:55:38 -0700 (PDT) In-Reply-To: <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> References: <2448C449-A257-40FE-9C97-7B05700F00EE@nic.cz> <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> Date: Tue, 5 Apr 2016 09:55:38 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1133a9eaf89973052fbfb682 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:55:44 -0000 --001a1133a9eaf89973052fbfb682 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 9:52 AM, Ladislav Lhotka wrote: > > On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: > > Andy Bierman wrote: > > On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: > > > On 04 Apr 2016, at 16:15, Andy Bierman wrote: > > > On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: > > On 04 Apr 2016, at 15:57, Andy Bierman wrote: > > Hi, > > I do not see any reason to prohibit this use of action-stmt > or notification-stmt. If the list has no keys then there is > no need to distinguish instances because the data model defines > no such semantics. > > > If such a keyless list has multiple entries, how can an action request > > specify which of the list entries it is tied to? > > > it must be be relevant to distinguish instances or else the designer > would have defined a key. > > > > What breaks if this is allowed? > > > The behaviour is undefined. > > > > IMO lists without keys are a really bad idea. > But the semantics are fully defined according to YANG. > If the list has no keys then there is no instance information > relevant to the data model. The action or notification is passed > all the keys (happens to be zero in this case). > > > To my understanding, each action request has to specify the unique > instance that's the "receiver" of the action. If this cannot be done, it is > IMO a problem in the spec. > > An alternative implementation of actions would be to use instance > identifiers instead of an explicit data hierarchy, and in this case it > would be possible to use indices for identifying entries. But the hierarchy > provides no such option. > > It's not a big issue, but there is already a couple of rules regarding > where actions can and cannot be defined, so this would be another one > intended to avoid potential ambiguity. > > > I agree actions were not considered when keyless lists were allowed in > YANG. > There was an assumption that this data is always read-only that is no > longer true in YANG 1.1. > > I certainly prefer adding a restriction than redoing the way actions work. > Using /foo[5] does not work because entry "5" might move or get deleted, > so the numbering is not stable. > > > How about: > > An action MUST NOT have any ancestor node that is a list node without > a "key" statement. > > > > Or rather: > > An action MUST NOT be defined for a node that is a list without a "key" > statement, or has a list node without a "key" statement as its ancestor. > > correct -- it is ancestor-or-self > Lada > Andy > > > (and ditto for notifs) > > > /martin > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1133a9eaf89973052fbfb682 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 9:52 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

On 05 Apr 2016, at 11:09, Martin Bjorkl= und <mbj@tail-f.com<= /a>> wrote:

Andy Bierman <andy@yumaworks.com> wrote:
On Mon, Apr 4, 2= 016 at 1:08 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:

<= br>
On 04 Apr 2016, at 16:15, Andy Bierman <andy@yumaworks.com= > wrote:


On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka <= ;lhotka@nic.cz> w= rote:

On 04 Apr 2016, at 15:57, Andy Bierm= an <andy@yumawor= ks.com> wrote:

Hi,

I do not see any reason to prohibit= this use of action-stmt
or notification-stmt.=C2=A0 If the list has no = keys then there is
no need to distinguish instances because the data mod= el defines
no such semantics.

If such a keyless list= has multiple entries, how can an action request
specify wh= ich of the list entries it is tied to?

it = must be be relevant to distinguish instances or else the designer
would = have defined a key.



What breaks if= this is allowed?

The behaviour is undefined.


IMO lists without keys are a really bad idea.
But the semantics ar= e fully defined according to YANG.
If the list has no keys then there is= no instance information
relevant to the data model.=C2=A0 The action or= notification is passed
all the keys (happens to be zero in this case).<= br>

To my understanding, each action request has to specify= the unique
instance that's the "receiver" of the action. = If this cannot be done, it is
IMO a problem in the spec.

An alter= native implementation of actions would be to use instance
identifiers in= stead of an explicit data hierarchy, and in this case it
would be possib= le to use indices for identifying entries. But the hierarchy
provides no= such option.

It's not a big issue, but there is already a coupl= e of rules regarding
where actions can and cannot be defined, so this wo= uld be another one
intended to avoid potential ambiguity.


I agree actions were not considered when keyless lists were allow= ed in YANG.
There was an assumption that this data is always read-only t= hat is no
longer true in YANG 1.1.

I certainly prefer adding a re= striction than redoing the way actions work.
Using /foo[5] does not work= because entry "5" might move or get deleted,
so the numbering= is not stable.

How about:

=C2=A0An action MUST = NOT have any ancestor node that is a list node without
=C2=A0a "key= " statement.


Or rather:<= div>
An action MUST NOT be defined for a node that is a list = without a "key" statement, or has a list node without a "key= " statement as its ancestor.


correct -- it is ancestor-or-self=C2=A0
=C2=A0<= /div>
Lada

Andy
=C2=A0


(and ditto for notifs= )


/martin

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





--001a1133a9eaf89973052fbfb682-- From nobody Tue Apr 5 10:05:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02E112D8E8 for ; Tue, 5 Apr 2016 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHr6Tg-yQjHz for ; Tue, 5 Apr 2016 10:05:27 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F56812D858 for ; Tue, 5 Apr 2016 10:05:26 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id c126so15352267lfb.2 for ; Tue, 05 Apr 2016 10:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lnGY447kBexokI3/fYXTJ3JZwvlXuXKg7WNQXJenSlg=; b=Vy+0qFab73++6eINE/TFDyslPJLqGX2DgPhpEErgGiuetAiER9tWoFXCMPwOPfU9Sr XLiYo3SrJp8NjTKAXI6f+zYDkL1RHM53od5xUUaNRVVhHR1LY4mC59MFQrDpKKaYvyV0 PfyocN8SceuayNDcD+FiMGzb5beUG/sWdv2agOrLPd3uIQAalMnxpygzJObpHhCvuMBo a8Yk4yQAjIKnYzcXy1p0Da48+hnNkJvhQGEau64XAJzl0QTUftFVAt9zy7djT9CtyjiE 6s+ND/SFwDu6xuVVtSvvy07ATDJOANwMMNsYD+r6o5pYwXx87IDIK1/J6d1ux+Ch5pWx R4KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lnGY447kBexokI3/fYXTJ3JZwvlXuXKg7WNQXJenSlg=; b=b6PvAAqir63d/csqmZm9wjcVB3MKG786I17Ek9mLYIfHNQG53sqm9lNPcL9ka8YR2m 1LyXp6s/L8HFmlZM68ihdGcdFeu890L/0daAiRpQFhsN/YoZoA1s7heRuelm6UuS/W+W ysHOXtpIVpPMNwPJiB1bpXAwskl9C1usqlzlMxjxNLyCDd5nvhMVUDVkSBMjnzanUM/V Fuz6z9ZKK7tedDLv8LvY8XqvoeSJhJmexRGs41fqn4yhJDJLGs3dW+pCLd2+Yd3Lj0x3 +ReRvuBzpY/d9v03FwIo6wPm3/oycnoBEAGJdvc+NrV34aSgBPDXszG3bhJezrSbRPne Hccw== X-Gm-Message-State: AD7BkJKL220ZdQ9OW4zyK+VWTWLe8dD48rOYPpSgLFKWa7XKrrkyATdiWBNgIxjQMYJVguRQLGJ29p1CNatbyA== MIME-Version: 1.0 X-Received: by 10.25.78.80 with SMTP id c77mr6666583lfb.62.1459875924752; Tue, 05 Apr 2016 10:05:24 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 5 Apr 2016 10:05:24 -0700 (PDT) In-Reply-To: <2B3AB1C2-417B-49A2-A4EE-9A7BE171C61D@cisco.com> References: <2B3AB1C2-417B-49A2-A4EE-9A7BE171C61D@cisco.com> Date: Tue, 5 Apr 2016 10:05:24 -0700 Message-ID: From: Andy Bierman To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=001a114194e4e95269052fbfd97e Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] rfc6087bis - 2 comments for your consideration X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:05:34 -0000 --001a114194e4e95269052fbfd97e Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 9:40 AM, Rajiv Asati (rajiva) wrote: > > 1) It would be useful to expand section 4.3 a bit more to add another > example of the tree with some specifics that cater to most of the protocols > work being done in other WGs. Something along the line of the following: > > Config (intended) > State (derived with or without applied) > Notification > RPC > .. > > > I don't know if one-size-fits-all will be that helpful. The YANG ABNF is the template for these statements. There are specific guidelines about using units, etc. > Authors of numerous YANG models could refer to the above guideline and use > it as a starting point. > > 2) It would be helpful if the guideline suggested a preference (yes, > recommendation would be better) for keeping applied state anehd derived > state together (in the same container, per each field) or separate > (containers); > There is some text already. Some aspects of YANG are left to the designer preferences. Clearly, if state data is within the config node for some functionality then it can only exist if the config exists. The ietf-interfaces module separates state because interfaces that are not in use need to be identified. In CLI they are mixed and every interface is present in "show interfaces", even if "shutdown" is the only config. Why doesn't YANG follow the CLI model? Not sure, but I guess the designers liked separate interfaces and interfaces-state containers. IMO the YANG is cleaner but probably more complicated to use. > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > > Andy > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114194e4e95269052fbfd97e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 9:40 AM, Rajiv Asati (rajiva) = <rajiva@cisco.com<= /a>> wrote:

1) It would be useful to expand section 4.3 a bit more to add another examp= le of the tree with some specifics that cater to most of the protocols work= being done in other WGs. Something along the line of the following:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Config (intended)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 State (derived with or without applied)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Notification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RPC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ..



I don't know if one-size-fits-all = will be that helpful.
The YANG ABNF is the template for these sta= tements.
There are specific guidelines about using units, etc.
=C2=A0
Authors of numerous YANG models could refer to the above guideline and use = it as a starting point.

2) It would be helpful if the guideline suggested a preference (yes, recomm= endation would be better) for keeping=C2=A0 applied state anehd derived sta= te together (in the same container, per each field) or separate (containers= );

There is some text already.

Some aspects of YANG are left to the designer preferences.=
Clearly, if state data is within the config node for some functi= onality
then it can only exist if the config exists.
The ietf-interfaces module separates state because interfaces = that are not in use
need to be identified.=C2=A0 In CLI they are = mixed and every interface is present
in "show interfaces&quo= t;, even if "shutdown" is the only config.
--001a114194e4e95269052fbfd97e-- From nobody Tue Apr 5 10:19:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B5C12D561 for ; Tue, 5 Apr 2016 10:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlOD6Q5HfXgJ for ; Tue, 5 Apr 2016 10:19:01 -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 40AD012D199 for ; Tue, 5 Apr 2016 10:19:01 -0700 (PDT) Received: from [10.10.0.186] (unknown [190.111.246.211]) by mail.nic.cz (Postfix) with ESMTPSA id 41B5518013A for ; Tue, 5 Apr 2016 19:18:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459876739; bh=osj1Kgq0+uxd9OUW3fzutqw18Rtj/uNEvaU+1aBybVQ=; h=From:Date:To; b=m6XrOVJFN4BUQadnCdje7iElBotAhhtK/y7qWiH0M8OLPAsfm0Yv2ABFKi7BSmseo HdSviNyARshmJqL9s2x2rPYFNoG9yEWnvM/ZRDtNdnr+aVudJ9IpXbPW2hUVW69LWa 1WfwKPtjiFilVfM2Ew7e6g+gt/6ZbT97pj5OtUqE= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7BE1AC8F-CBCE-4593-B997-628F39CD04EA@nic.cz> Date: Tue, 5 Apr 2016 14:18:55 -0300 To: NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] schema mount issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:19:03 -0000 Hi, during the NETMOD session yesterday, we didn't have much time to discuss = open issues related to schema mount. So I created three new issues in = the GitHub project: https://github.com/netmod-wg/schema-mount/issues Please express your opinion there. Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 5 10:41:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D22212D645 for ; Tue, 5 Apr 2016 10:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzkAty80dVpt for ; Tue, 5 Apr 2016 10:40:57 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452B112D53D for ; Tue, 5 Apr 2016 10:40:57 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id j11so15812406lfb.1 for ; Tue, 05 Apr 2016 10:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1mU4v56/xbUDf79zvqb4tjjt1ivXHNQhOV+P4E1QZE8=; b=JPzxbYUgpm64CPZ5sbTsVsVp7Kv1xxTeLaTHpEl8VkJPGgAUchZZJ+8uvc9KqLGK04 jBAyy4QXeIyXlvNCAeN9zZ6fqhEZ7CXwArHsCJa693kV/L6u2Dae7zvy01XGE8D6Hjhf hQv82uXNSBMLduVFKM1g2vlI3HwwE2Zml1U2u2ZRTCHPIPfJXfZHqS3A11xglWxsjP+v X5L8dYiy0FAT2DOfBzfz7HY2AQlSasWHxK9tMsl3oJNUe+hyyzf+ltIiIk+Ttnh0mHMa Cmtci3EnyzIWu5qRAaWprZsB9i31ZUv15p//EJyZa7z9VwHYIvkAOLiwwFDRgP3wgGkD y9CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1mU4v56/xbUDf79zvqb4tjjt1ivXHNQhOV+P4E1QZE8=; b=my5pnWMJpx7+CntSzV4ZUcJEQ2XFs5c2jLyEgS5o7ru3A3WKxDP3sFhgBKiL06qI3s zaXqmLj7YNoKqDg5M+tSXPNaprkPWdUfklnqCnRHaLc3C8P5ztl40XbEumvCleJ0hkwV wJat3XOP+XKgnBNqtFEZ8IG9j3X1qk/3HU0CQmA2VcmxirQzjIaVhvRPn6+g6kFJLkav /522CFZZvou4meilL7ZU4NB6p03lRZ8BFlB182gMqQrNlH8NwIlJqQ2O8EqZxhbx81E9 biC0ARvnsn1Bof6O0cBjXgGRomqg6QX2DjwvQ1tJ8kobxEQaVaouYiXZzXzPmpVmKylj nPuA== X-Gm-Message-State: AD7BkJLpD8wDKyJIOalmonOtLK3O1EZ/YlKSpttyk3dSV+xbn9pi2p6yG0GMv44icxhGDOghZcZLTWMub6CnlQ== MIME-Version: 1.0 X-Received: by 10.25.32.65 with SMTP id g62mr6657188lfg.138.1459878055419; Tue, 05 Apr 2016 10:40:55 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 5 Apr 2016 10:40:55 -0700 (PDT) In-Reply-To: <7BE1AC8F-CBCE-4593-B997-628F39CD04EA@nic.cz> References: <7BE1AC8F-CBCE-4593-B997-628F39CD04EA@nic.cz> Date: Tue, 5 Apr 2016 10:40:55 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11403476e8b9a2052fc05845 Archived-At: Cc: NETMOD WG Subject: Re: [netmod] schema mount issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:40:59 -0000 --001a11403476e8b9a2052fc05845 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 5, 2016 at 10:18 AM, Ladislav Lhotka wrote: > Hi, > > during the NETMOD session yesterday, we didn't have much time to discuss > open issues related to schema mount. So I created three new issues in the > GitHub project: > > https://github.com/netmod-wg/schema-mount/issues > > Please express your opinion there. > As a procedural issue I think WG business needs to be conducted on the WG mailing list, not on github. > > Thanks, Lada > > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11403476e8b9a2052fc05845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 5, 2016 at 10:18 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Hi,

during the NETMOD session yesterday, we didn't have much time to discus= s open issues related to schema mount. So I created three new issues in the= GitHub project:

https://github.com/netmod-wg/schema-mount/issues=

Please express your opinion there.

As a= procedural issue I think WG business needs to be conducted
on th= e WG mailing list, not on github.

=C2=A0

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

--001a11403476e8b9a2052fc05845-- From nobody Tue Apr 5 11:09:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B717812D765 for ; Tue, 5 Apr 2016 11:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W33DtaGwJA1S for ; Tue, 5 Apr 2016 11:09:51 -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 995C712D79F for ; Tue, 5 Apr 2016 11:09:51 -0700 (PDT) Received: from [10.10.0.186] (unknown [190.111.246.211]) by mail.nic.cz (Postfix) with ESMTPSA id 1D0FF1801C5; Tue, 5 Apr 2016 20:09:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459879790; bh=gMB/E5XwciQVgG4lKBi3QPiDviXaNhGx/FJOGGSSQjE=; h=From:Date:To; b=CMeTIN7rqFhXgPjh9HKmDvPU3tWej3JsyMo7C8RwR7wksJeialMMqC01ZjgqrRW7F BB81hoD8RhY6Noi6bHV5sBki43djjMwNGg+4GNQErlUdREs2qXDGYQTW4MqgTWra8s uZfMHntk8nng0L/b4d42/tCwSG/C0WfsWsEOjOkw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 5 Apr 2016 15:09:42 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <93699601-DC9D-4F4C-8EA3-509B58020EAE@nic.cz> References: <7BE1AC8F-CBCE-4593-B997-628F39CD04EA@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] schema mount issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:09:53 -0000 > On 05 Apr 2016, at 14:40, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Apr 5, 2016 at 10:18 AM, Ladislav Lhotka = wrote: > Hi, >=20 > during the NETMOD session yesterday, we didn't have much time to = discuss open issues related to schema mount. So I created three new = issues in the GitHub project: >=20 > https://github.com/netmod-wg/schema-mount/issues >=20 > Please express your opinion there. >=20 > As a procedural issue I think WG business needs to be conducted > on the WG mailing list, not on github. I don't mind copying the issues to the mailing list but I think the = issue-oriented style is more practical. Of course we would eventually = need to verify WG consensus in the mailing list. Lada >=20 > =20 >=20 > Thanks, Lada >=20 >=20 > Andy > =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 Tue Apr 5 12:32:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4358612D742 for ; Tue, 5 Apr 2016 12:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPO8nCpraZZD for ; Tue, 5 Apr 2016 12:32:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF7E12D798 for ; Tue, 5 Apr 2016 12:32:36 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 065C21AE035B; Tue, 5 Apr 2016 21:32:34 +0200 (CEST) Date: Tue, 05 Apr 2016 21:32:33 +0200 (CEST) Message-Id: <20160405.213233.1353328448064723938.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> References: <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@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] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 19:32:44 -0000 Ladislav Lhotka wrote: > > > On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > >> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: > >> > >>> > >>>> On 04 Apr 2016, at 16:15, Andy Bierman wrote: > >>>> > >>>> > >>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: > >>>> > >>>>> On 04 Apr 2016, at 15:57, Andy Bierman wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I do not see any reason to prohibit this use of action-stmt > >>>>> or notification-stmt. If the list has no keys then there is > >>>>> no need to distinguish instances because the data model defines > >>>>> no such semantics. > >>>> > >>>> If such a keyless list has multiple entries, how can an action request > >>> specify which of the list entries it is tied to? > >>>> > >>>> it must be be relevant to distinguish instances or else the designer > >>>> would have defined a key. > >>>> > >>>> > >>>>> > >>>>> What breaks if this is allowed? > >>>> > >>>> The behaviour is undefined. > >>>> > >>>> > >>>> > >>>> IMO lists without keys are a really bad idea. > >>>> But the semantics are fully defined according to YANG. > >>>> If the list has no keys then there is no instance information > >>>> relevant to the data model. The action or notification is passed > >>>> all the keys (happens to be zero in this case). > >>> > >>> To my understanding, each action request has to specify the unique > >>> instance that's the "receiver" of the action. If this cannot be done, it is > >>> IMO a problem in the spec. > >>> > >>> An alternative implementation of actions would be to use instance > >>> identifiers instead of an explicit data hierarchy, and in this case it > >>> would be possible to use indices for identifying entries. But the hierarchy > >>> provides no such option. > >>> > >>> It's not a big issue, but there is already a couple of rules regarding > >>> where actions can and cannot be defined, so this would be another one > >>> intended to avoid potential ambiguity. > >>> > >>> > >> I agree actions were not considered when keyless lists were allowed in YANG. > >> There was an assumption that this data is always read-only that is no > >> longer true in YANG 1.1. > >> > >> I certainly prefer adding a restriction than redoing the way actions work. > >> Using /foo[5] does not work because entry "5" might move or get deleted, > >> so the numbering is not stable. > > > > How about: > > > > An action MUST NOT have any ancestor node that is a list node without > > a "key" statement. > > > Or rather: > > An action MUST NOT be defined for a node that is a list without a > "key" statement, or has a list node without a "key" statement as its > ancestor. I don't see the difference. Even in: list foo { action bar { ... } } "foo" is an ancestor to "bar". /martin From nobody Tue Apr 5 12:32:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8489E12D742 for ; Tue, 5 Apr 2016 12:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q24z1R7QOHUI for ; Tue, 5 Apr 2016 12:32: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 04CFF12D76F for ; Tue, 5 Apr 2016 12:32:48 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 483681AE035B; Tue, 5 Apr 2016 21:32:47 +0200 (CEST) Date: Tue, 05 Apr 2016 21:32:47 +0200 (CEST) Message-Id: <20160405.213247.1142344996275989975.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@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] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 19:32:52 -0000 Ladislav Lhotka wrote: > I just noticed a typo in fourth paragraph of sec. 7.15: > > s/an the top-level/at the top-level/ Thanks, fixed. /martin > > Lada > > > On 05 Apr 2016, at 13:52, Ladislav Lhotka wrote: > > > >> > >> On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: > >> > >> Andy Bierman wrote: > >>> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: > >>> > >>>> > >>>>> On 04 Apr 2016, at 16:15, Andy Bierman wrote: > >>>>> > >>>>> > >>>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: > >>>>> > >>>>>> On 04 Apr 2016, at 15:57, Andy Bierman wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I do not see any reason to prohibit this use of action-stmt > >>>>>> or notification-stmt. If the list has no keys then there is > >>>>>> no need to distinguish instances because the data model defines > >>>>>> no such semantics. > >>>>> > >>>>> If such a keyless list has multiple entries, how can an action request > >>>> specify which of the list entries it is tied to? > >>>>> > >>>>> it must be be relevant to distinguish instances or else the designer > >>>>> would have defined a key. > >>>>> > >>>>> > >>>>>> > >>>>>> What breaks if this is allowed? > >>>>> > >>>>> The behaviour is undefined. > >>>>> > >>>>> > >>>>> > >>>>> IMO lists without keys are a really bad idea. > >>>>> But the semantics are fully defined according to YANG. > >>>>> If the list has no keys then there is no instance information > >>>>> relevant to the data model. The action or notification is passed > >>>>> all the keys (happens to be zero in this case). > >>>> > >>>> To my understanding, each action request has to specify the unique > >>>> instance that's the "receiver" of the action. If this cannot be done, it is > >>>> IMO a problem in the spec. > >>>> > >>>> An alternative implementation of actions would be to use instance > >>>> identifiers instead of an explicit data hierarchy, and in this case it > >>>> would be possible to use indices for identifying entries. But the hierarchy > >>>> provides no such option. > >>>> > >>>> It's not a big issue, but there is already a couple of rules regarding > >>>> where actions can and cannot be defined, so this would be another one > >>>> intended to avoid potential ambiguity. > >>>> > >>>> > >>> I agree actions were not considered when keyless lists were allowed in YANG. > >>> There was an assumption that this data is always read-only that is no > >>> longer true in YANG 1.1. > >>> > >>> I certainly prefer adding a restriction than redoing the way actions work. > >>> Using /foo[5] does not work because entry "5" might move or get deleted, > >>> so the numbering is not stable. > >> > >> How about: > >> > >> An action MUST NOT have any ancestor node that is a list node without > >> a "key" statement. > > > > > > Or rather: > > > > An action MUST NOT be defined for a node that is a list without a "key" statement, or has a list node without a "key" statement as its ancestor. > > > > Lada > > > >> > >> (and ditto for notifs) > >> > >> > >> /martin > > > > -- > > 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 > > > > From nobody Tue Apr 5 13:33:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CB212D836 for ; Tue, 5 Apr 2016 13:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkddSKknjrUp for ; Tue, 5 Apr 2016 13:33: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 CF63212D63A for ; Tue, 5 Apr 2016 13:33:18 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:f975:30f7:1835:150] (unknown [IPv6:2001:67c:370:176:f975:30f7:1835:150]) by mail.nic.cz (Postfix) with ESMTPSA id F076718010A; Tue, 5 Apr 2016 22:33:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459888397; bh=ehksBpJjd0g7bFTNR0MTAdy2A+X7xTtF5BPrU/kG9Ak=; h=From:Date:To; b=bfXhw/gFxusvQShCX64O+I2keEvyN3b68jxgs6BcZlWK1/wla92gNj9BtwmxYnNwL HvjWkD9vzK0G4OPOdNWGlyMi/zgldVr5PBTrh3TNrSggL8g63C6KM2rd17P+sH7md9 TS6FCbQP7w7OH0YG72E5gQBc1Yecj6Q3tl1pq0AI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160405.213233.1353328448064723938.mbj@tail-f.com> Date: Tue, 5 Apr 2016 17:33:13 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> <20160405.213233.1353328448064723938.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:33:22 -0000 > On 05 Apr 2016, at 16:32, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: >>>=20 >>> Andy Bierman wrote: >>>> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka = wrote: >>>>=20 >>>>>=20 >>>>>> On 04 Apr 2016, at 16:15, Andy Bierman = wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka = wrote: >>>>>>=20 >>>>>>> On 04 Apr 2016, at 15:57, Andy Bierman = wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I do not see any reason to prohibit this use of action-stmt >>>>>>> or notification-stmt. If the list has no keys then there is >>>>>>> no need to distinguish instances because the data model defines >>>>>>> no such semantics. >>>>>>=20 >>>>>> If such a keyless list has multiple entries, how can an action = request >>>>> specify which of the list entries it is tied to? >>>>>>=20 >>>>>> it must be be relevant to distinguish instances or else the = designer >>>>>> would have defined a key. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> What breaks if this is allowed? >>>>>>=20 >>>>>> The behaviour is undefined. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IMO lists without keys are a really bad idea. >>>>>> But the semantics are fully defined according to YANG. >>>>>> If the list has no keys then there is no instance information >>>>>> relevant to the data model. The action or notification is passed >>>>>> all the keys (happens to be zero in this case). >>>>>=20 >>>>> To my understanding, each action request has to specify the unique >>>>> instance that's the "receiver" of the action. If this cannot be = done, it is >>>>> IMO a problem in the spec. >>>>>=20 >>>>> An alternative implementation of actions would be to use instance >>>>> identifiers instead of an explicit data hierarchy, and in this = case it >>>>> would be possible to use indices for identifying entries. But the = hierarchy >>>>> provides no such option. >>>>>=20 >>>>> It's not a big issue, but there is already a couple of rules = regarding >>>>> where actions can and cannot be defined, so this would be another = one >>>>> intended to avoid potential ambiguity. >>>>>=20 >>>>>=20 >>>> I agree actions were not considered when keyless lists were allowed = in YANG. >>>> There was an assumption that this data is always read-only that is = no >>>> longer true in YANG 1.1. >>>>=20 >>>> I certainly prefer adding a restriction than redoing the way = actions work. >>>> Using /foo[5] does not work because entry "5" might move or get = deleted, >>>> so the numbering is not stable. >>>=20 >>> How about: >>>=20 >>> An action MUST NOT have any ancestor node that is a list node = without >>> a "key" statement. >>=20 >>=20 >> Or rather: >>=20 >> An action MUST NOT be defined for a node that is a list without a >> "key" statement, or has a list node without a "key" statement as its >> ancestor. >=20 > I don't see the difference. Even in: >=20 > list foo { > action bar { ... } > } >=20 > "foo" is an ancestor to "bar". Provided "action" is a schema node which it doesn't seem to be: action: An operation defined for a node in the data tree. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 5 15:03:39 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD5E12D0CC; Tue, 5 Apr 2016 15:03:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405220338.30973.1627.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 15:03:38 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:03:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Structural Mount Author : Martin Bjorklund Filename : draft-ietf-netmod-schema-mount-00.txt Pages : 20 Date : 2016-04-05 Abstract: This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 5 15:04:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288DB12D9B6 for ; Tue, 5 Apr 2016 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIujjf_7FhVk for ; Tue, 5 Apr 2016 15:04:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1507B12D9B1 for ; Tue, 5 Apr 2016 15:04:23 -0700 (PDT) Received: from pluto.hedeland.org (h194n2-hy-a32.ias.bredband.telia.com [81.228.176.194]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FD671AE0439; Wed, 6 Apr 2016 00:04:21 +0200 (CEST) To: Ladislav Lhotka References: <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> <20160405.213233.1353328448064723938.mbj@tail-f.com> From: Per Hedeland X-Enigmail-Draft-Status: N1110 Message-ID: <57043665.7040908@tail-f.com> Date: Wed, 6 Apr 2016 00:04:21 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:04:26 -0000 On 2016-04-05 22:33, Ladislav Lhotka wrote: > >> On 05 Apr 2016, at 16:32, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> >>>> On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: >>>> >>>> Andy Bierman wrote: >>>>> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka wrote: >>>>> >>>>>> >>>>>>> On 04 Apr 2016, at 16:15, Andy Bierman wrote: >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka wrote: >>>>>>> >>>>>>>> On 04 Apr 2016, at 15:57, Andy Bierman wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I do not see any reason to prohibit this use of action-stmt >>>>>>>> or notification-stmt. If the list has no keys then there is >>>>>>>> no need to distinguish instances because the data model defines >>>>>>>> no such semantics. >>>>>>> >>>>>>> If such a keyless list has multiple entries, how can an action request >>>>>> specify which of the list entries it is tied to? >>>>>>> >>>>>>> it must be be relevant to distinguish instances or else the designer >>>>>>> would have defined a key. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> What breaks if this is allowed? >>>>>>> >>>>>>> The behaviour is undefined. >>>>>>> >>>>>>> >>>>>>> >>>>>>> IMO lists without keys are a really bad idea. >>>>>>> But the semantics are fully defined according to YANG. >>>>>>> If the list has no keys then there is no instance information >>>>>>> relevant to the data model. The action or notification is passed >>>>>>> all the keys (happens to be zero in this case). >>>>>> >>>>>> To my understanding, each action request has to specify the unique >>>>>> instance that's the "receiver" of the action. If this cannot be done, it is >>>>>> IMO a problem in the spec. >>>>>> >>>>>> An alternative implementation of actions would be to use instance >>>>>> identifiers instead of an explicit data hierarchy, and in this case it >>>>>> would be possible to use indices for identifying entries. But the hierarchy >>>>>> provides no such option. >>>>>> >>>>>> It's not a big issue, but there is already a couple of rules regarding >>>>>> where actions can and cannot be defined, so this would be another one >>>>>> intended to avoid potential ambiguity. >>>>>> >>>>>> >>>>> I agree actions were not considered when keyless lists were allowed in YANG. >>>>> There was an assumption that this data is always read-only that is no >>>>> longer true in YANG 1.1. >>>>> >>>>> I certainly prefer adding a restriction than redoing the way actions work. >>>>> Using /foo[5] does not work because entry "5" might move or get deleted, >>>>> so the numbering is not stable. >>>> >>>> How about: >>>> >>>> An action MUST NOT have any ancestor node that is a list node without >>>> a "key" statement. >>> >>> >>> Or rather: >>> >>> An action MUST NOT be defined for a node that is a list without a >>> "key" statement, or has a list node without a "key" statement as its >>> ancestor. >> >> I don't see the difference. Even in: >> >> list foo { >> action bar { ... } >> } >> >> "foo" is an ancestor to "bar". > > Provided "action" is a schema node which it doesn't seem to be: > > action: An operation defined for a node in the data tree. IMO it is absolutely clear that it is a schema node - later in the Terminology section: o schema node: A node in the schema tree. One of action, container, leaf, leaf-list, list, choice, case, rpc, input, output, notification, anydata, and anyxml. And "7.15 The action Statement": The "action" statement defines an action node in the schema tree. I can see how the "action" entry in the Terminology section - which apparently talks about the action "concept" rather than the statement or the node - can be confusing, though. And looking for symmetry with "rpc" it gets perhaps even more confusing - there is no literal "rpc" entry, but: o RPC: A Remote Procedure Call. Yeah, but...:-) Anyway, given 4.2.9. Operation Definitions YANG allows the definition of operations. The operations' name, input parameters, and output parameters are modeled using YANG data definition statements. Operations on the top-level in a module are defined with the "rpc" statement. Operations can also be tied to a data node. Such operations are defined with the "action" statement. [snip example] The "rpc" statement is covered in Section 7.14, and the "action" statement in Section 7.15. - it seems to me that the full picture is clear enough. --Per From nobody Tue Apr 5 15:08:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3E212D765 for ; Tue, 5 Apr 2016 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRtkQrpwfE3F for ; Tue, 5 Apr 2016 15:08:03 -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 F2E8F12D0F4 for ; Tue, 5 Apr 2016 15:08:02 -0700 (PDT) Received: (qmail 18412 invoked by uid 0); 5 Apr 2016 22:08:02 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 5 Apr 2016 22:08:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id et7v1s00b2SSUrH01t7yrK; Tue, 05 Apr 2016 23:07:59 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=XH4KuWOnUQH6bLxZi6sA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=Roo10UCze/vvaoryil9kQPxUlz81PkP/INciw7L+6dk=; b=16b8GhrubOA0s9+QI/op8Ye578 4lZYR/8usht0L5gP4aIyqx2tvC/UvDaTtVTlLMG4keirTbpDO+hLVS9y6xLZMrasEeO03uRmQVhbn oIOOzAYCJvsHv2Y7eIcIWcYFh; Received: from box313.bluehost.com ([69.89.31.113]:50850 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anZ8g-0002p8-Bp; Tue, 05 Apr 2016 16:07:58 -0600 To: Andy Bierman , Ladislav Lhotka References: <7BE1AC8F-CBCE-4593-B997-628F39CD04EA@nic.cz> From: Lou Berger Message-ID: <57043738.9000500@labn.net> Date: Tue, 5 Apr 2016 18:07:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: NETMOD WG Subject: Re: [netmod] schema mount issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:08:05 -0000 On 4/5/2016 1:40 PM, Andy Bierman wrote: > > > On Tue, Apr 5, 2016 at 10:18 AM, Ladislav Lhotka > wrote: > > Hi, > > during the NETMOD session yesterday, we didn't have much time to > discuss open issues related to schema mount. So I created three > new issues in the GitHub project: > > https://github.com/netmod-wg/schema-mount/issues > > Please express your opinion there. > > > As a procedural issue I think WG business needs to be conducted > on the WG mailing list, not on github. > +1 capturing issues somewhere is important, and github is a fine place -- but discussion need to be on list. -- it would be great if you could gateway issues to the WG list. Thanks, Lou (as one of three chairs, ;-) > > > > Thanks, Lada > > > Andy > > > -- > 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 From nobody Tue Apr 5 16:35:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5052D12D641 for ; Tue, 5 Apr 2016 16:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI7o03N_ySTV for ; Tue, 5 Apr 2016 16:35:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1904512D5CC for ; Tue, 5 Apr 2016 16:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7396; q=dns/txt; s=iport; t=1459899324; x=1461108924; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mufyhGdiuQrPiPZA1XDrgn6cQeOafWzRsYIax1eIJMI=; b=SPDKHgtO9Fqf+KG4PgL+o4fipYU0lstDbZqR2jMs1KtZX0tbUkpZcXjR w0pITRaO+xNI7qx3mU34VesNx+Gpm0LL00Y4hEw6wX7d66WmJZbrx17ty 41WT6UAEsMrTPxwdElAo86b7KRcAh+UuE29Z/NH20BOzFJ7/7ZMfuvl8w Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBBSwRX/5ldJa1cgzdTfQa7NgENg?= =?us-ascii?q?XIXCoUiSgKBQTgUAQEBAQEBAWUnhEEBAQEDAQEBAWsEBwUHBAIBCBEEAQEBJwc?= =?us-ascii?q?nCxQJCAIEAQ0FCBOIBAgOwEgBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIprhCeFb?= =?us-ascii?q?gWNTTiJfAGOA48VjxsBHgEBQoIEGYFKbIc5AX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,445,1454976000"; d="scan'208";a="88637935" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2016 23:35:23 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u35NZM50001060 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 23:35:22 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 19:35:21 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 19:35:21 -0400 From: "Alexander Clemm (alex)" To: Ladislav Lhotka , =?iso-8859-1?Q?Martin_Bj=F6rklund?= Thread-Topic: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements Thread-Index: AQHRjx7tOw12H05yWU25RG3JKFE7/J97iU2AgABlUaA= Date: Tue, 5 Apr 2016 23:35:21 +0000 Message-ID: <8eab257636824a178c19ebaf83d80dca@XCH-RTP-001.cisco.com> References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> <16B50CA8-0076-413D-87D1-FFBE6A54175C@nic.cz> In-Reply-To: <16B50CA8-0076-413D-87D1-FFBE6A54175C@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.35] 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] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:35:26 -0000 Hi, Martin, Lada, unfortunately I wasn't able to attend the discussion, but I have one commen= t regarding the "definition" vs "implementation" distinction. =20 Clearly, peer-mount and alias-mount have a definition component to it. Thi= s is why the YANG extensions were defined to define mountpoints. This defi= nition component can be aligned with structural mount, and the goal needs t= o be to reuse the same. So far, so good. =20 The aspect that I don't think I agree with is that peer-mount and alias-mou= nt should be treated merely as an "implementation". I think I understand w= here you are coming from - to the user of mounted data, they don't care if = there are other "instances" of the same data and how the data they see is p= opulated. That said, I don't think this viewpoint is entirely correct, bec= ause there are certain semantics associated with it, and also because there= are different implications with regards to mountpoint management which nee= d to be reflected in the model. (For example, for peer-mount, there needs = to be information on the remote system.) =20 For the semantics, I think the fact should be captured when mounted data de= pends on target data. We capture conditions and constraints for semantical= ly accurate models; the fact that the "aliased" data reflects another insta= nce in another subtree is something that sure needs to be captured and unde= rstood. For example, without reflecting this relationship, an application = might try to set an authoritative subtree/datanode to one value, the mounte= d version of it to a different value. So, whether or not there is an alias= , or a peer, to an instance of data is something that should be reflected i= n the model. In other words, I don't think you can see the mountpoint an= d data mounted below it in entire isolation from the rest of the system. A= nother question concerns what you are actually mounting. In alias-mount, t= he mounted subtree may actually have been augmented and have other data nod= es underneath it. Does the mounting apply to also augmenting data? For st= ructural mount, the answer is clearly "no", but for peer-mount it doesn't h= ave to be. =20 --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Tuesday, April 05, 2016 4:57 AM To: Martin Bj=F6rklund Cc: netmod@ietf.org Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requireme= nts > On 05 Apr 2016, at 06:38, Martin Bjorklund wrote: >=20 > Hi, >=20 > Kent Watsen wrote: >> [As a contributor] >>=20 >> Note: this is a -00 document, but only because the draft's name=20 >> changed. In reality this is like a=20 >> draft-voit-netmod-peer-mount-requirements-04. Looking at the diffs,=20 >> there aren't many changes, mostly cleanup and adding the "schema=20 >> mount" concept. That is, the new "yang mount" term is use to cover=20 >> all of "schema mount", "alias mount", and "peer mount". >>=20 >> My comment is mostly high-level. I'm wondering about the need for=20 >> this draft to include schema mount at all. That is, a schema mount=20 >> solution draft is now an adopted WG item, and I'm unsure if the=20 >> authors of that draft are looking to this one to define requirements. >> Perhaps the goal is to define the umbrella term "yang mount", but to=20 >> be honest, I don't really see a need to have a term that spans both=20 >> schema and data mounts. I'm not sure how others feel about this, but=20 >> my thoughts are that we should define terms like: >>=20 >> - scheme-mount >> - data-mount >> - remote data mount (a.k.a. peer mount) >> - local data mount (a.k.a. alias mount) >>=20 >> More so than: >>=20 >> yang-mount >> - scheme-mount >> - alias-mount >> - peer-mount >=20 > Listening to Eric's presentation yesterday, I realized that I have a=20 > slightly different view on these terms. >=20 > I prefer to separate the *schema* (data model) from how things are=20 > implemented. The various proposals for specific implementations (peer Yes, I expressed this opinion already in Yokohama. Moreover, Eliot's presen= tation indicated that there are use cases in which YANG is used for modelli= ng data outside the context of a management protocol. So IMO it is legitima= te to require that even with schema mount it is possible to write a compact= specification of the complete schema. Such a schema is static as before, t= he only change is that we have more flexibility in composing the modules, w= hereas currently they can be only put side by side. Also, there needn't be = any mechanism like peer mount, all data may be local. Perhaps this use case is really different from the more dynamic situation w= here the server needs to fetch the subschemas at runtime and the data are c= ontributed by an external entity. Lada > mount and alias mount etc) all need a "schema mount" to take of > defining a proper data model. (This was the whole point of defining > structural-mount...) >=20 > For example, suppose we have: >=20 > container logical-devices { > list logical-device { > key name; > ... > yangmnt:mount-point logical-device; > } > } >=20 > With the associated yang-library, a client might learn that=20 > ietf-interfaces is mounted under the "logical-device" mount mount. >=20 > Now, the client knows that there are paths: >=20 > /logical-devices/logical-device/if:interfaces/if:interface >=20 > but the client doesn't necessarily have to know if the the interfaces=20 > data is implemented w/ "peer mount" or some other mechanism. >=20 >=20 > So, in my view, we have: >=20 > schema mount > | > +---- peer mount > +---- alias mount > +---- other cool mount >=20 >=20 >=20 > As a concrete example, peer mount might be used like this (example=20 > taken from draft-clemm-netmod-mount-03): >=20 > import ietf-schema-mount { > prefix yangmnt; > } > import ietf-peer-mount { > prefix pmnt; > } >=20 > ... >=20 > list network-element { > key "element-id"; > leaf element-id { > type element-ID; > } > container element-address { > ... // choice definition that allows to specify > // host name, > // IP addresses, URIs, etc > } > yangmnt:mount-point "interfaces" { > pmnt:target "./element-address"; > pmnt:subtree "/if:interfaces"; > } > ... > } >=20 >=20 > A client that knows about the generic, abstract schema mount can work=20 > with this, without knowing anything of the specific implementation of=20 > peer mount. >=20 > [Actually, since peer mount is just one implementation technique, I'd=20 > prefer to decouple the definition of this implementation detail from=20 > the data model, but that's a different topic.] >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 5 18:00:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559F12D138 for ; Tue, 5 Apr 2016 18:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzOCPgijKIU2 for ; Tue, 5 Apr 2016 18:00:13 -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 890F012D0FC for ; Tue, 5 Apr 2016 18:00:13 -0700 (PDT) Received: from [10.10.0.186] (unknown [190.111.246.211]) by mail.nic.cz (Postfix) with ESMTPSA id C6F201800D3; Wed, 6 Apr 2016 03:00:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1459904411; bh=dXrSINGy2+aIGl3uildhECZUrly69OqGMOlwEEEvN5Y=; h=From:Date:To; b=Da2muAXljiczEH4R9WjqXiJ4JXbdTZYkA2+3P+/9Sp7Q1rQYstvQCwvXJ21u/+RVB gbFz26LADJzkN830kDovZhGGVC/10G5gCLCEC7ATNnumA2IJw1syVmvO8ze8w6Fkj5 tGuRq0RFdgBQHAtzZzy4XLsM3ggNv+0PQbpckFYA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <57043665.7040908@tail-f.com> Date: Tue, 5 Apr 2016 22:00:06 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <93C4ECA7-00DE-4FBF-911E-287F8AF6F6A2@nic.cz> References: <20160405.160938.373639996260156222.mbj@tail-f.com> <25D2FA6D-0587-49D1-BBAF-E1DD40603936@nic.cz> <20160405.213233.1353328448064723938.mbj@tail-f.com> <57043665.7040908@tail-f.com> To: Per Hedeland X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] actions and keyless lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 01:00:16 -0000 > On 05 Apr 2016, at 19:04, Per Hedeland wrote: >=20 > On 2016-04-05 22:33, Ladislav Lhotka wrote: >>=20 >>> On 05 Apr 2016, at 16:32, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 05 Apr 2016, at 11:09, Martin Bjorklund wrote: >>>>>=20 >>>>> Andy Bierman wrote: >>>>>> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka = wrote: >>>>>>=20 >>>>>>>=20 >>>>>>>> On 04 Apr 2016, at 16:15, Andy Bierman = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka = wrote: >>>>>>>>=20 >>>>>>>>> On 04 Apr 2016, at 15:57, Andy Bierman = wrote: >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> I do not see any reason to prohibit this use of action-stmt >>>>>>>>> or notification-stmt. If the list has no keys then there is >>>>>>>>> no need to distinguish instances because the data model = defines >>>>>>>>> no such semantics. >>>>>>>>=20 >>>>>>>> If such a keyless list has multiple entries, how can an action = request >>>>>>> specify which of the list entries it is tied to? >>>>>>>>=20 >>>>>>>> it must be be relevant to distinguish instances or else the = designer >>>>>>>> would have defined a key. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> What breaks if this is allowed? >>>>>>>>=20 >>>>>>>> The behaviour is undefined. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> IMO lists without keys are a really bad idea. >>>>>>>> But the semantics are fully defined according to YANG. >>>>>>>> If the list has no keys then there is no instance information >>>>>>>> relevant to the data model. The action or notification is = passed >>>>>>>> all the keys (happens to be zero in this case). >>>>>>>=20 >>>>>>> To my understanding, each action request has to specify the = unique >>>>>>> instance that's the "receiver" of the action. If this cannot be = done, it is >>>>>>> IMO a problem in the spec. >>>>>>>=20 >>>>>>> An alternative implementation of actions would be to use = instance >>>>>>> identifiers instead of an explicit data hierarchy, and in this = case it >>>>>>> would be possible to use indices for identifying entries. But = the hierarchy >>>>>>> provides no such option. >>>>>>>=20 >>>>>>> It's not a big issue, but there is already a couple of rules = regarding >>>>>>> where actions can and cannot be defined, so this would be = another one >>>>>>> intended to avoid potential ambiguity. >>>>>>>=20 >>>>>>>=20 >>>>>> I agree actions were not considered when keyless lists were = allowed in YANG. >>>>>> There was an assumption that this data is always read-only that = is no >>>>>> longer true in YANG 1.1. >>>>>>=20 >>>>>> I certainly prefer adding a restriction than redoing the way = actions work. >>>>>> Using /foo[5] does not work because entry "5" might move or get = deleted, >>>>>> so the numbering is not stable. >>>>>=20 >>>>> How about: >>>>>=20 >>>>> An action MUST NOT have any ancestor node that is a list node = without >>>>> a "key" statement. >>>>=20 >>>>=20 >>>> Or rather: >>>>=20 >>>> An action MUST NOT be defined for a node that is a list without a >>>> "key" statement, or has a list node without a "key" statement as = its >>>> ancestor. >>>=20 >>> I don't see the difference. Even in: >>>=20 >>> list foo { >>> action bar { ... } >>> } >>>=20 >>> "foo" is an ancestor to "bar". >>=20 >> Provided "action" is a schema node which it doesn't seem to be: >>=20 >> action: An operation defined for a node in the data tree. >=20 > IMO it is absolutely clear that it is a schema node - later in the > Terminology section: >=20 > o schema node: A node in the schema tree. One of action, = container, > leaf, leaf-list, list, choice, case, rpc, input, output, > notification, anydata, and anyxml. OK, you are right, I missed this one, sorry. Lada >=20 > And "7.15 The action Statement": >=20 > The "action" statement defines an action node in the schema tree. >=20 > I can see how the "action" entry in the Terminology section - which > apparently talks about the action "concept" rather than the statement = or > the node - can be confusing, though. And looking for symmetry with = "rpc" > it gets perhaps even more confusing - there is no literal "rpc" entry, > but: >=20 > o RPC: A Remote Procedure Call. >=20 > Yeah, but...:-) Anyway, given >=20 > 4.2.9. Operation Definitions >=20 > YANG allows the definition of operations. The operations' name, > input parameters, and output parameters are modeled using YANG data > definition statements. Operations on the top-level in a module are > defined with the "rpc" statement. Operations can also be tied to a > data node. Such operations are defined with the "action" statement. >=20 > [snip example] >=20 > The "rpc" statement is covered in Section 7.14, and the "action" > statement in Section 7.15. >=20 > - it seems to me that the full picture is clear enough. >=20 > --Per -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 5 19:28:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F112D172; Tue, 5 Apr 2016 19:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfuyxLO8kafP; Tue, 5 Apr 2016 19:28:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A750B12D0BF; Tue, 5 Apr 2016 19:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5299; q=dns/txt; s=iport; t=1459909702; x=1461119302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QD+V+v94BEKqxMYQ155vG5/ykJxAURFDWb29czlx7Aw=; b=AT+6wHM7MRwHos/g1CCVP7qQxLsdJt3wiXakR4sQ6/oV3FplbwkGnG93 AaNmuHrPFkykGCDe2xRa4fJR1jVKy3Tf1/i8zOInepYxR7ZA4dSSu8D4+ fz7BOJ6ZrXomKMvIwuQZkqgUf7I9wzRCcPLprfN2JS/PqAaDUwp/KMQPH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgACdARX/4gNJK1ZA4M3U322SoJjg?= =?us-ascii?q?g8BDYFyHYVwAoFGOBQBAQEBAQEBZSeEQgEBBHkOAgIBCA4CJQYEBxsXFBECBA4?= =?us-ascii?q?FiCfAQwEBAQEBAQEBAQEBAQEBAQEBAQEBARUEhhyBdQiCToRgHQmCZIIrBZMFh?= =?us-ascii?q?HwBjgqBZ4RNhCCEOo8bAR4BAUKCMoE1bIg3AQEB?= X-IronPort-AV: E=Sophos; i="5.24,446,1454976000"; d="scan'208,217"; a="88676911" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 02:28:03 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u362S3Bv018292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 02:28:03 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 21:28:03 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 21:28:03 -0500 From: "Rajiv Asati (rajiva)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ91JyyAgAUq7ACAAFAoAIABnqmd Date: Wed, 6 Apr 2016 02:28:03 +0000 Message-ID: <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> , <20160404204356.GA57133@elstar.local> In-Reply-To: <20160404204356.GA57133@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_473C6D05BC3540698931665F0122A32Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 02:28:24 -0000 --_000_473C6D05BC3540698931665F0122A32Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Juergen, Thanks for the clarity. I somewhat agree. Different lifetime shouldn't real= ly cause any impact. One nit, When I pull out a configured interface, the operational state of this interface is gone but not the config - if I put the interface back, it should come up configured as before. Depends. If LC itself is removed, then all the related interfaces would be = removed from the running-config. And reinserting the LC may not bring their= individual conf back (ignoring the notifications). Obviously, I can also have operational state of an interface that has not been configured yet. Yes. Cheers, Rajiv Asati Distinguished Engineer, Cisco Services On Apr 4, 2016, at 5:44 PM, Juergen Schoenwaelder > wrote: On Mon, Apr 04, 2016 at 07:57:05PM +0000, Rajiv Asati (rajiva) wrote: Hi Juergen, Operational state often has a different lifetime than config. Hence, Hmm..Could you please clarify the above a bit more? The classic example: When I pull out a configured interface, the operational state of this interface is gone but not the config - if I put the interface back, it should come up configured as before. Obviously, I can also have operational state of an interface that has not been configured yet. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --_000_473C6D05BC3540698931665F0122A32Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Juer= gen,

Thanks for the clarity. I somewhat agree. Different lifetime shouldn't real= ly cause any impact. 

One nit, 

When I pull out a configured interface, th= e operational state of this
interface is gone but not the config - if I put the interface back, it
should come up configured as before. 

Depends. If LC itself is removed, then all the related interfaces woul= d be removed from the running-config. And reinserting the LC may not bring = their individual conf back (ignoring the notifications). 

Obviously, I can also have
operational state of an interface that has not been configured yet.<= /font>

Yes. 

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On Apr 4, 2016, at 5:44 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:

On Mon, Apr 04, 2016 at 07:57:05PM +0000, Rajiv Asati (rajiv= a) wrote:
Hi Juergen,

Operational state often has a different lif= etime than config. Hence,


Hmm..Could you please clarify the above a b= it more?


The classic example:

When I pull out a configured interface, the operational state of this=
interface is gone but not the config - if I put the interface back, i= t
should come up configured as before. Obviously, I can also have
operational state of an interface that has not been configured yet.

/js

--
Juergen Schoenwaelder         = ;  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587        = ; Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103      &= nbsp;  <http://ww= w.jacobs-university.de/>
--_000_473C6D05BC3540698931665F0122A32Aciscocom_-- From nobody Tue Apr 5 23:29:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867412D63D; Tue, 5 Apr 2016 23:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrL-YLlSqCph; Tue, 5 Apr 2016 23:29: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 DD12A12D72E; Tue, 5 Apr 2016 23:29:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 15707F6E; Wed, 6 Apr 2016 08:29: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 BEVJv9YTTCfp; Wed, 6 Apr 2016 08:28:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Apr 2016 08:29:03 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CD6720045; Wed, 6 Apr 2016 08:29:03 +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 0fscBIUp6jNm; Wed, 6 Apr 2016 08:29:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26F4020043; Wed, 6 Apr 2016 08:29:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E7A03A72C5A; Wed, 6 Apr 2016 08:28:59 +0200 (CEST) Date: Wed, 6 Apr 2016 08:28:59 +0200 From: Juergen Schoenwaelder To: "Rajiv Asati (rajiva)" Message-ID: <20160406062858.GA60806@elstar.local> Mail-Followup-To: "Rajiv Asati (rajiva)" , "netmod@ietf.org" , "mpls@ietf.org" References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 06:29:11 -0000 On Wed, Apr 06, 2016 at 02:28:03AM +0000, Rajiv Asati (rajiva) wrote: > Hi Juergen, > > Thanks for the clarity. I somewhat agree. Different lifetime shouldn't really cause any impact. > > One nit, > > When I pull out a configured interface, the operational state of this > interface is gone but not the config - if I put the interface back, it > should come up configured as before. > > Depends. If LC itself is removed, then all the related interfaces would be removed from the running-config. And reinserting the LC may not bring their individual conf back (ignoring the notifications). Assuming LC means line card if not discard the following (and explain what LC means). I believe the answer here is that systems treat this differently and there is no universal answer. Some systems seem to store line card config on the line card itself, other systems associate config with the physical location of a port or interface, yet others associate config with a name of an interface (which may not indicate the physical location of an interface). Since implementations really differ here, we support multiple implementation options in the interfaces data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 5 23:36:20 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565D012D7BF; Tue, 5 Apr 2016 23:36:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406063619.31042.86535.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 23:36:19 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:36:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Schema Mount Authors : Martin Bjorklund Ladislav Lhotka Filename : draft-ietf-netmod-schema-mount-01.txt Pages : 20 Date : 2016-04-05 Abstract: This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 5 23:39:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6DE12D81E for ; Tue, 5 Apr 2016 23:39: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y27bF30QlSqt for ; Tue, 5 Apr 2016 23:39: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 2277012D80A for ; Tue, 5 Apr 2016 23:39:31 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id D44741AE0141 for ; Wed, 6 Apr 2016 08:39:29 +0200 (CEST) Date: Wed, 06 Apr 2016 08:39:39 +0200 (CEST) Message-Id: <20160406.083939.519388094494155668.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20160406063619.31042.86535.idtracker@ietfa.amsl.com> References: <20160406063619.31042.86535.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:39:33 -0000 Hi, While -00 of this draft was a pure rename from the individual draft-bjorklund-netmod-structural-mount, this version (-01) changes not only the filename of the draft, but also the title of the document and the YANG module. /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language of the IETF. > > Title : YANG Schema Mount > Authors : Martin Bjorklund > Ladislav Lhotka > Filename : draft-ietf-netmod-schema-mount-01.txt > Pages : 20 > Date : 2016-04-05 > > Abstract: > This document defines a mechanism to combine YANG modules into the > schema defined in other YANG modules. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Apr 6 00:18:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF512D57F for ; Wed, 6 Apr 2016 00:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2Qn0YdtU9sp for ; Wed, 6 Apr 2016 00:18:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D7CF112D0B6 for ; Wed, 6 Apr 2016 00:18:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 868E21AE0141; Wed, 6 Apr 2016 09:18:42 +0200 (CEST) Date: Wed, 06 Apr 2016 09:18:52 +0200 (CEST) Message-Id: <20160406.091852.487853511276571798.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: <8eab257636824a178c19ebaf83d80dca@XCH-RTP-001.cisco.com> References: <20160405.113822.1614298419822308565.mbj@tail-f.com> <16B50CA8-0076-413D-87D1-FFBE6A54175C@nic.cz> <8eab257636824a178c19ebaf83d80dca@XCH-RTP-001.cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 07:18:47 -0000 Hi, "Alexander Clemm (alex)" wrote: > Hi, Martin, Lada, > = > unfortunately I wasn't able to attend the discussion, but I have one > comment regarding the "definition" vs "implementation" distinction. I probably failed to communicate my point clearly. I did not want to make the distinction in this way. > Clearly, peer-mount and alias-mount have a definition component to > it. Yes, absolutely. I don't think I implied that they didn't. > This is why the YANG extensions were defined to define mountpoints. > This definition component can be aligned with structural mount, and > the goal needs to be to reuse the same. So far, so good. Yes, this was my point. In Eric's presentation he had "schema mount", "peer-mount", and "alias-mount" on the same level; all three different variations of the generic concept "YANG Mount". I think that is incorrect; we should have a generic "schema mount", with "peer-mount" and "alias-mount" being specializations of this concept. > The aspect that I don't think I agree with is that peer-mount and > alias-mount should be treated merely as an "implementation". Again, this is not what I wrote. I wrote that: the client doesn't *necessarily* have to know if the the interfaces = data is implemented w/ "peer mount" or some other mechanism. [note "necessarily"] I agree that *some* clients need to be able to manage mount targets etc, but not all. > I think > I understand where you are coming from - to the user of mounted data,= > they don't care if there are other "instances" of the same data and > how the data they see is populated. That said, I don't think this > viewpoint is entirely correct, because there are certain semantics > associated with it, and also because there are different implications= > with regards to mountpoint management which need to be reflected in > the model. (For example, for peer-mount, there needs to be > information on the remote system.) > = > For the semantics, I think the fact should be captured when mounted > data depends on target data. We capture conditions and constraints > for semantically accurate models; the fact that the "aliased" data > reflects another instance in another subtree is something that sure > needs to be captured and understood. If the client is fully aware of the alias mount concept, why bother with it? As I have said previously, we (tail-f) have had alias mount implemented for many years (we call it "symlink"), and we have bad experiences with all scenarios but the very simplest ones (simple leaf to leaf alias). And even in this case users get pretty confused by errors caused by validation that depends on the target leaf. > For example, without reflecting > this relationship, an application might try to set an authoritative > subtree/datanode to one value, the mounted version of it to a > different value. So, whether or not there is an alias, or a peer, to= > an instance of data is something that should be reflected in the > model. In other words, I don't think you can see the mountpoint and > data mounted below it in entire isolation from the rest of the system= .= > Another question concerns what you are actually mounting. In > alias-mount, the mounted subtree may actually have been augmented and= > have other data nodes underneath it. Does the mounting apply to also= > augmenting data? For structural mount, the answer is clearly "no", > but for peer-mount it doesn't have to be. I don't understand what you mean. Maybe you can show an example? /martin > = > --- Alex > = > = > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > Lhotka > Sent: Tuesday, April 05, 2016 4:57 AM > To: Martin Bj=F6rklund > Cc: netmod@ietf.org > Subject: Re: [netmod] kw comments on > draft-voit-netmod-yang-mount-requirements > = > = > > On 05 Apr 2016, at 06:38, Martin Bjorklund wrote: > > = > > Hi, > > = > > Kent Watsen wrote: > >> [As a contributor] > >> = > >> Note: this is a -00 document, but only because the draft's name = > >> changed. In reality this is like a = > >> draft-voit-netmod-peer-mount-requirements-04. Looking at the diff= s, = > >> there aren't many changes, mostly cleanup and adding the "schema = > >> mount" concept. That is, the new "yang mount" term is use to cove= r = > >> all of "schema mount", "alias mount", and "peer mount". > >> = > >> My comment is mostly high-level. I'm wondering about the need for= = > >> this draft to include schema mount at all. That is, a schema moun= t = > >> solution draft is now an adopted WG item, and I'm unsure if the = > >> authors of that draft are looking to this one to define requiremen= ts. > >> Perhaps the goal is to define the umbrella term "yang mount", but = to = > >> be honest, I don't really see a need to have a term that spans bot= h = > >> schema and data mounts. I'm not sure how others feel about this, = but = > >> my thoughts are that we should define terms like: > >> = > >> - scheme-mount > >> - data-mount > >> - remote data mount (a.k.a. peer mount) > >> - local data mount (a.k.a. alias mount) > >> = > >> More so than: > >> = > >> yang-mount > >> - scheme-mount > >> - alias-mount > >> - peer-mount > > = > > Listening to Eric's presentation yesterday, I realized that I have = a = > > slightly different view on these terms. > > = > > I prefer to separate the *schema* (data model) from how things are = > > implemented. The various proposals for specific implementations (p= eer > = > Yes, I expressed this opinion already in Yokohama. Moreover, Eliot's > presentation indicated that there are use cases in which YANG is used= > for modelling data outside the context of a management protocol. So > IMO it is legitimate to require that even with schema mount it is > possible to write a compact specification of the complete schema. Suc= h > a schema is static as before, the only change is that we have more > flexibility in composing the modules, whereas currently they can be > only put side by side. Also, there needn't be any mechanism like peer= > mount, all data may be local. > = > Perhaps this use case is really different from the more dynamic > situation where the server needs to fetch the subschemas at runtime > and the data are contributed by an external entity. > = > Lada > = > > mount and alias mount etc) all need a "schema mount" to take of > > defining a proper data model. (This was the whole point of defini= ng > > structural-mount...) > > = > > For example, suppose we have: > > = > > container logical-devices { > > list logical-device { > > key name; > > ... > > yangmnt:mount-point logical-device; > > } > > } > > = > > With the associated yang-library, a client might learn that = > > ietf-interfaces is mounted under the "logical-device" mount mount. > > = > > Now, the client knows that there are paths: > > = > > /logical-devices/logical-device/if:interfaces/if:interface > > = > > but the client doesn't necessarily have to know if the the interfac= es = > > data is implemented w/ "peer mount" or some other mechanism. > > = > > = > > So, in my view, we have: > > = > > schema mount > > | > > +---- peer mount > > +---- alias mount > > +---- other cool mount > > = > > = > > = > > As a concrete example, peer mount might be used like this (example = > > taken from draft-clemm-netmod-mount-03): > > = > > import ietf-schema-mount { > > prefix yangmnt; > > } > > import ietf-peer-mount { > > prefix pmnt; > > } > > = > > ... > > = > > list network-element { > > key "element-id"; > > leaf element-id { > > type element-ID; > > } > > container element-address { > > ... // choice definition that allows to specify > > // host name, > > // IP addresses, URIs, etc > > } > > yangmnt:mount-point "interfaces" { > > pmnt:target "./element-address"; > > pmnt:subtree "/if:interfaces"; > > } > > ... > > } > > = > > = > > A client that knows about the generic, abstract schema mount can wo= rk = > > with this, without knowing anything of the specific implementation = of = > > peer mount. > > = > > [Actually, since peer mount is just one implementation technique, I= 'd = > > prefer to decouple the definition of this implementation detail fro= m = > > the data model, but that's a different topic.] > > = > > = > > /martin > > = > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > = > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > = > = > = > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Wed Apr 6 05:30:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7479812D0A2 for ; Wed, 6 Apr 2016 05:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8t0hI9KSlne for ; Wed, 6 Apr 2016 05:30:05 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A64F712D8C9 for ; Wed, 6 Apr 2016 05:30:04 -0700 (PDT) Received: from localhost (dhcp-b234.meeting.ietf.org [31.133.178.52]) by trail.lhotka.name (Postfix) with ESMTPSA id 844C01CC01E2; Wed, 6 Apr 2016 14:30:07 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , alex@cisco.com In-Reply-To: <20160406.091852.487853511276571798.mbj@tail-f.com> References: <20160405.113822.1614298419822308565.mbj@tail-f.com> <16B50CA8-0076-413D-87D1-FFBE6A54175C@nic.cz> <8eab257636824a178c19ebaf83d80dca@XCH-RTP-001.cisco.com> <20160406.091852.487853511276571798.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 06 Apr 2016 09:29:55 -0300 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] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:30:08 -0000 Martin Bjorklund writes: > Hi, > > "Alexander Clemm (alex)" wrote: >> Hi, Martin, Lada, >>=20 >> unfortunately I wasn't able to attend the discussion, but I have one >> comment regarding the "definition" vs "implementation" distinction. > > I probably failed to communicate my point clearly. I did not want to > make the distinction in this way. > >> Clearly, peer-mount and alias-mount have a definition component to >> it. > > Yes, absolutely. I don't think I implied that they didn't. > >> This is why the YANG extensions were defined to define mountpoints. >> This definition component can be aligned with structural mount, and >> the goal needs to be to reuse the same. So far, so good. > > Yes, this was my point. In Eric's presentation he had "schema mount", > "peer-mount", and "alias-mount" on the same level; all three different > variations of the generic concept "YANG Mount". I think that is > incorrect; we should have a generic "schema mount", with "peer-mount" > and "alias-mount" being specializations of this concept. I would go even further: schema mount and peer mount are independent and orthogonal (not sure about alias mount - this is probably still something else). That is, I can build a data model with schema mount, and use it for validating a good old local datastore. Conversely, it is IMO possible to apply peer mount and validate the data against a data model that's constructed according to the existing rules. So, even though it may be sometimes beneficial to combine schema mount and peer mount, I believe they can and should be implemented as two independent concepts. A pure schema mount should have no security implications, whereas accessing remote data certainly has some. And accepting a (sub)schema from an external source requires IMO even higher level of trust. Lada > > >> The aspect that I don't think I agree with is that peer-mount and >> alias-mount should be treated merely as an "implementation". > > Again, this is not what I wrote. I wrote that: > > the client doesn't *necessarily* have to know if the the interfaces=20 > data is implemented w/ "peer mount" or some other mechanism. > > [note "necessarily"] > > I agree that *some* clients need to be able to manage mount targets > etc, but not all. > >> I think >> I understand where you are coming from - to the user of mounted data, >> they don't care if there are other "instances" of the same data and >> how the data they see is populated. That said, I don't think this >> viewpoint is entirely correct, because there are certain semantics >> associated with it, and also because there are different implications >> with regards to mountpoint management which need to be reflected in >> the model. (For example, for peer-mount, there needs to be >> information on the remote system.) >>=20 >> For the semantics, I think the fact should be captured when mounted >> data depends on target data. We capture conditions and constraints >> for semantically accurate models; the fact that the "aliased" data >> reflects another instance in another subtree is something that sure >> needs to be captured and understood. > > If the client is fully aware of the alias mount concept, why bother > with it? > > As I have said previously, we (tail-f) have had alias mount > implemented for many years (we call it "symlink"), and we have bad > experiences with all scenarios but the very simplest ones (simple leaf > to leaf alias). And even in this case users get pretty confused by > errors caused by validation that depends on the target leaf. > >> For example, without reflecting >> this relationship, an application might try to set an authoritative >> subtree/datanode to one value, the mounted version of it to a >> different value. So, whether or not there is an alias, or a peer, to >> an instance of data is something that should be reflected in the >> model. In other words, I don't think you can see the mountpoint and >> data mounted below it in entire isolation from the rest of the system. >> Another question concerns what you are actually mounting. In >> alias-mount, the mounted subtree may actually have been augmented and >> have other data nodes underneath it. Does the mounting apply to also >> augmenting data? For structural mount, the answer is clearly "no", >> but for peer-mount it doesn't have to be. > > I don't understand what you mean. Maybe you can show an example? > > > /martin > > >>=20 >> --- Alex >>=20 >>=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka >> Sent: Tuesday, April 05, 2016 4:57 AM >> To: Martin Bj=C3=B6rklund >> Cc: netmod@ietf.org >> Subject: Re: [netmod] kw comments on >> draft-voit-netmod-yang-mount-requirements >>=20 >>=20 >> > On 05 Apr 2016, at 06:38, Martin Bjorklund wrote: >> >=20 >> > Hi, >> >=20 >> > Kent Watsen wrote: >> >> [As a contributor] >> >>=20 >> >> Note: this is a -00 document, but only because the draft's name=20 >> >> changed. In reality this is like a=20 >> >> draft-voit-netmod-peer-mount-requirements-04. Looking at the diffs,= =20 >> >> there aren't many changes, mostly cleanup and adding the "schema=20 >> >> mount" concept. That is, the new "yang mount" term is use to cover=20 >> >> all of "schema mount", "alias mount", and "peer mount". >> >>=20 >> >> My comment is mostly high-level. I'm wondering about the need for=20 >> >> this draft to include schema mount at all. That is, a schema mount=20 >> >> solution draft is now an adopted WG item, and I'm unsure if the=20 >> >> authors of that draft are looking to this one to define requirements. >> >> Perhaps the goal is to define the umbrella term "yang mount", but to= =20 >> >> be honest, I don't really see a need to have a term that spans both=20 >> >> schema and data mounts. I'm not sure how others feel about this, but= =20 >> >> my thoughts are that we should define terms like: >> >>=20 >> >> - scheme-mount >> >> - data-mount >> >> - remote data mount (a.k.a. peer mount) >> >> - local data mount (a.k.a. alias mount) >> >>=20 >> >> More so than: >> >>=20 >> >> yang-mount >> >> - scheme-mount >> >> - alias-mount >> >> - peer-mount >> >=20 >> > Listening to Eric's presentation yesterday, I realized that I have a=20 >> > slightly different view on these terms. >> >=20 >> > I prefer to separate the *schema* (data model) from how things are=20 >> > implemented. The various proposals for specific implementations (peer >>=20 >> Yes, I expressed this opinion already in Yokohama. Moreover, Eliot's >> presentation indicated that there are use cases in which YANG is used >> for modelling data outside the context of a management protocol. So >> IMO it is legitimate to require that even with schema mount it is >> possible to write a compact specification of the complete schema. Such >> a schema is static as before, the only change is that we have more >> flexibility in composing the modules, whereas currently they can be >> only put side by side. Also, there needn't be any mechanism like peer >> mount, all data may be local. >>=20 >> Perhaps this use case is really different from the more dynamic >> situation where the server needs to fetch the subschemas at runtime >> and the data are contributed by an external entity. >>=20 >> Lada >>=20 >> > mount and alias mount etc) all need a "schema mount" to take of >> > defining a proper data model. (This was the whole point of defining >> > structural-mount...) >> >=20 >> > For example, suppose we have: >> >=20 >> > container logical-devices { >> > list logical-device { >> > key name; >> > ... >> > yangmnt:mount-point logical-device; >> > } >> > } >> >=20 >> > With the associated yang-library, a client might learn that=20 >> > ietf-interfaces is mounted under the "logical-device" mount mount. >> >=20 >> > Now, the client knows that there are paths: >> >=20 >> > /logical-devices/logical-device/if:interfaces/if:interface >> >=20 >> > but the client doesn't necessarily have to know if the the interfaces= =20 >> > data is implemented w/ "peer mount" or some other mechanism. >> >=20 >> >=20 >> > So, in my view, we have: >> >=20 >> > schema mount >> > | >> > +---- peer mount >> > +---- alias mount >> > +---- other cool mount >> >=20 >> >=20 >> >=20 >> > As a concrete example, peer mount might be used like this (example=20 >> > taken from draft-clemm-netmod-mount-03): >> >=20 >> > import ietf-schema-mount { >> > prefix yangmnt; >> > } >> > import ietf-peer-mount { >> > prefix pmnt; >> > } >> >=20 >> > ... >> >=20 >> > list network-element { >> > key "element-id"; >> > leaf element-id { >> > type element-ID; >> > } >> > container element-address { >> > ... // choice definition that allows to specify >> > // host name, >> > // IP addresses, URIs, etc >> > } >> > yangmnt:mount-point "interfaces" { >> > pmnt:target "./element-address"; >> > pmnt:subtree "/if:interfaces"; >> > } >> > ... >> > } >> >=20 >> >=20 >> > A client that knows about the generic, abstract schema mount can work= =20 >> > with this, without knowing anything of the specific implementation of= =20 >> > peer mount. >> >=20 >> > [Actually, since peer mount is just one implementation technique, I'd= =20 >> > prefer to decouple the definition of this implementation detail from=20 >> > the data model, but that's a different topic.] >> >=20 >> >=20 >> > /martin >> >=20 >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 6 06:54:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD5312D5B9 for ; Wed, 6 Apr 2016 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n6n3EzQcHnp for ; Wed, 6 Apr 2016 06:54:30 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2DF812D525 for ; Wed, 6 Apr 2016 06:54:29 -0700 (PDT) Received: from localhost (dhcp-b234.meeting.ietf.org [31.133.178.52]) by trail.lhotka.name (Postfix) with ESMTPSA id 6B3551CC0249 for ; Wed, 6 Apr 2016 15:54:35 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 06 Apr 2016 10:54:23 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] identifying the mount point X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:54:32 -0000 Hi, for identifying and referring to mount points, two options are proposed: 1. Use a YANG extension, such as yangmnt:mount-point, for giving a name to a schema location. The specification of subschemas (mounted data models) then uses these named mount points. 2. The specification of subschemas uses schema node identifiers for addressing mount points. The rules can be same/similar to those for a target node of augment. My opinion is that #2 is a better choice because - schema node identifier is a known koncept, and it can refer to any schema location (of course, restrictions may be imposed, as they are for augment's target node); - an extension is not appropriate for such a fundamental data modelling mechanism; - schema node identifiers can be directly used even if the mount point is inside a grouping, the mount-point extension requires some CLRs. It is questionable whether specifying mount point in a parent model is good or bad. Its author must be able to know all potential mount points in advance, which may not always be possible. On the other hand, explicit mount points do not guarantee that new stuff can only appear there - it may be added to any location through an augment. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 6 06:58:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B930F12D5D4 for ; Wed, 6 Apr 2016 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGlCbxLfIPA9 for ; Wed, 6 Apr 2016 06:57:57 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA4C12D5B1 for ; Wed, 6 Apr 2016 06:57:57 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-21-570515be53ac Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 3D.06.22441.EB515075; Wed, 6 Apr 2016 15:57:18 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Wed, 6 Apr 2016 09:57:56 -0400 From: Eric Gray To: "netmod@ietf.org" Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft Thread-Index: AdGQDFCGfeqiXdK4SpWO63WB0/5TWA== Date: Wed, 6 Apr 2016 13:57:54 +0000 Message-ID: <3ED0CE30-93F9-4DBF-9129-DBA57C812493@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-03A6E4C9-EA4E-4E65-9C01-743D42B45B53"; protocol="application/pkcs7-signature" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyuXRPiO4+UdZwg+N3bSzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxroV51gKjqVXXH/7hL2B8UBKFyMHh4SAicS1WT5djJxAppjE hXvr2boYuTiEBI4ySqx8f44dwlnGKLGkawEbSBWbgIbEsTtrGUFsEQF1iZk7QTo4OIQFMiRO nJODCGdK/J69mBnC1pPYeeAYK4jNIqAi8eLUayYQm1fAXuL30k8sIDYj0OLvp9aAxZkFxCVu PZnPBHGQiMTDi6fZIGxRiZeP/7GC3MMsMJlRYsH1GYwQgwQlTs58wjKBUXAWkv5ZyOpmIamD KIqX+L3mIhuELS+x/e0cZghbU2J/93KoGkWJKd0P2SFsDYnObxNZMcWtJWb8Ogg1x1Ti9dGP jMhqFjDyrGLkKC0uyMlNNzLcxAiMrWMSbI47GPf2eh5iFOBgVOLhXZDLEi7EmlhWXJl7iFEF qPXRhtUXGKVY8vLzUpVEeFM4WMOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ83pH/gsTEkhPLEnN Tk0tSC2CyTJxcEo1MC591rKVNazlu0pt55eZMa+7AxfP2vZzn8Cho7nz0zg/MS3nk7ipbr7j 0bQqZwbX/JxstSDf76Yhx1ZeWvL7gRHjI967TK6Gx5NnTY/l+uRQxMp/6p2t4c+XQQm8bV6v /pgJlxoZ3tSesdRJnvvIojvdqlKRZ9Nfxi7nmV4ln68TJ7FSRj7sjBJLcUaioRZzUXEiAKIB 6fC1AgAA Archived-At: Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:58:01 -0000 --Apple-Mail-03A6E4C9-EA4E-4E65-9C01-743D42B45B53 Content-Type: multipart/alternative; boundary=Apple-Mail-C52D34DB-BDA8-4D52-A3DC-2810DA8B54D8 Content-Transfer-Encoding: 7bit --Apple-Mail-C52D34DB-BDA8-4D52-A3DC-2810DA8B54D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QXBvbG9naWVzIGZvciByZXNwb25kaW5nIHNvIGxhdGUgdG8gdGhpcyBtZXNzYWdlLg0KDQpJIG9u bHkgcmVjZW50bHkgd2FzIGFwcHJpc2VkIG9mIHRoaXMgZHJhZnQgYW5kIEkgd2FudGVkIHRvIGtu b3cgaWYgdGhlIGF1dGhvcnMgY2FuIGV4cGxhaW4gd2hhdCB0aGUgZHJhZnQgb2ZmZXJzIHRoYXQg aXMgbm90IGFscmVhZHkgZWFzaWx5IHN1cHBvcnRlZCB1c2luZyBSRkMgNzIyMz8NCg0KSWYgaXQg aXMgcG9zc2libGUgdG8gc3VwcG9ydCB0aGUgY2FwYWJpbGl0aWVzIGV4cGxpY2l0bHkgdGFyZ2V0 ZWQgaW4gdGhpcyBkcmFmdCwgdXNpbmcgdGhlIGV4aXN0aW5nIG1vZGVsLCBkb2VzIGl0IG1ha2Ug c2Vuc2UgdG8gaW50cm9kdWNlIGEgbmV3IHNldCBvZiBlbmhhbmNlbWVudHMgdGhhdCBtYWtlIGl0 IHBvc3NpYmxlIHRvIHJlcHJlc2VudCB0aGUgc2FtZSBjb25jZXB0cyBpbiB0d28gd2F5cz8NCg0K LS0NCkVyaWMNCg0KLS0tLS0tLS0tLS0tLS0tLS0NClJlOiBbbmV0bW9kXSBjYWxsIGZvciBjb25z ZW5zdXMgdG8gYWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIE5FVE1P RCBXRyBkcmFmdA0KS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IE1vbiwgMjkgRmVi cnVhcnkgMjAxNiAyMzowNyBVVENTaG93IGhlYWRlcg0KVGhlIGNoYWlycyB3ZXJlIGp1c3QgcmV2 aWV3aW5nIG5vdGVzIGFuZCByZWFsaXplZCB0aGF0IHRoaXMgdGhyZWFkIG5ldmVyIGNsb3NlZCBw cm9wZXJseS4gSnVlcmdlbiBoYXMgc29tZSBjb25jZXJucyByZWdhcmRpbmcgcmVhbGlzdGljIG1p bGVzdG9uZXMsIHRoYXQgd2VyZSBuZXZlciBhZGRyZXNzZWQuIFJvYmVydCwgY2FuIHlvdSBwbGVh c2UgdHJ5IHRvIGFkZHJlc3MgSnVlcmdlbuKAmXMgY29uY2VybnMgbm93PyBBbHNvLCB0aGVyZSB3 ZXJlIG9ubHkgYSB0d28gcmVzcG9uc2VzIGJlZm9yZSBpbmRpY2F0aW5nIHdpbGxpbmduZXNzIHRv IHJldmlldyB0aGUgZHJhZnQgYXMgaXQgcHJvZ3Jlc3NlcyAodGhhbmtzIERhbiBhbmQgTWFydGlu KS4gQ2FuIG90aGVycyB0aGF0IHN1cHBvcnQgdGhpcyBkcmFmdCBhbmQgd2lsbGluZyB0byByZXZp ZXcgdGhpcyBkcmFmdCBzYXkgc28/IFRoYW5rcywgTmV0bW9kIENoYWlycyBGcm9tOiBuZXRtb2Qg PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dh dHNlbkBqdW5pcGVyLm5ldD4+IERhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDE1LCAyMDE1IGF0IDEx OjQ4IEFNIFRvOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+PiBTdWJqZWN0OiBbbmV0bW9kXSBj YWxsIGZvciBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15 YW5nIGFzIE5FVE1PRCBXRyBkcmFmdCBUaGUgbWludXRlcyBmb3IgSUVURiA5NCBzaG93IHRoYXQg dGhlcmUgd2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRvcHRpbmcgZHJhZnQtd2lsdG9uLW5ldG1v ZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuIFRoZSBtaW51dGVzIGFsc28gc2hvdyB0aGF0 IHRoaXMgZGVjaXNpb24gd291bGQgYmUgY29uZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHdo aWNoIEkgYW0gZG9pbmcgbm93LiBTaG91bGQgd2UgbW92ZSB0byBhZG9wdCBkcmFmdC13aWx0b24t bmV0bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBpdGVtIGFuZCBjb3JyZXNwb25kaW5nbHkgYWRk IHRoaXMgdG8gdGhlIFdHIGNoYXJ0ZXIgYXMgYSBtaWxlc3RvbmU/IFBsZWFzZSBjb21tZW50IGJ5 IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IGF0IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUg V0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRv IG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1bWVudC4gVGhhbmtzLCBLZW50IA0KU2VudCBmcm9t IG15IGlQYWQ= --Apple-Mail-C52D34DB-BDA8-4D52-A3DC-2810DA8B54D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+QXBvbG9n aWVzIGZvciByZXNwb25kaW5nIHNvIGxhdGUgdG8gdGhpcyBtZXNzYWdlLjwvZGl2PjxkaXYgaWQ9 IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVy ZSI+SSBvbmx5IHJlY2VudGx5IHdhcyBhcHByaXNlZCBvZiB0aGlzIGRyYWZ0IGFuZCBJIHdhbnRl ZCB0byBrbm93IGlmIHRoZSBhdXRob3JzIGNhbiBleHBsYWluIHdoYXQgdGhlIGRyYWZ0IG9mZmVy cyB0aGF0IGlzIG5vdCBhbHJlYWR5IGVhc2lseSBzdXBwb3J0ZWQgdXNpbmcgUkZDIDcyMjM/PC9k aXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj5JZiBpdCBpcyBwb3NzaWJsZSB0byBzdXBwb3J0IHRoZSBjYXBhYmlsaXRp ZXMgZXhwbGljaXRseSB0YXJnZXRlZCBpbiB0aGlzIGRyYWZ0LCB1c2luZyB0aGUgZXhpc3Rpbmcg bW9kZWwsIGRvZXMgaXQgbWFrZSBzZW5zZSB0byBpbnRyb2R1Y2UgYSBuZXcgc2V0IG9mIGVuaGFu Y2VtZW50cyB0aGF0IG1ha2UgaXQgcG9zc2libGUgdG8gcmVwcmVzZW50IHRoZSBzYW1lIGNvbmNl cHRzIGluIHR3byB3YXlzPzwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwv ZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+LS08L2Rpdj48ZGl2IGlkPSJBcHBsZU1h aWxTaWduYXR1cmUiPkVyaWM8L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj48 L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPi0tLS0tLS0tLS0tLS0tLS0tPGJyPjxo MSBzdHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtd2Vp Z2h0OiBpbmhlcml0OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2Vs aW5lOyI+PGZvbnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo MjU1LCAyNTUsIDI1NSwgMCk7Ij5SZTogW25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFk b3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQ8 L3NwYW4+PC9mb250PjwvaDE+PHAgaWQ9Im1zZy1pbmZvIiBjbGFzcz0iZGFya2dyYXkiIHN0eWxl PSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgbGluZS1oZWlnaHQ6IGlu aGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PHNwYW4gaWQ9Im1zZy1mcm9tIiBjbGFz cz0icGlwZSIgc3R5bGU9Im1hcmdpbjogMHB4IDAuNWVtIDBweCAwcHg7IHBhZGRpbmc6IDBweCAw LjhlbSAwcHggMHB4OyBib3JkZXItd2lkdGg6IDBweCAxcHggMHB4IDBweDsgYm9yZGVyLXJpZ2h0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjIxLCAyMjEsIDIyMSk7IGZv bnQtc3R5bGU6IGluaGVyaXQ7IGZvbnQtdmFyaWFudC1jYXBzOiBpbmhlcml0OyBsaW5lLWhlaWdo dDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyI+S2VudCBXYXRzZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9h PiZndDs8L3NwYW4+Jm5ic3A7PHNwYW4gaWQ9Im1zZy1kYXRlIiBjbGFzcz0icGlwZSIgc3R5bGU9 Im1hcmdpbjogMHB4IDAuNWVtIDBweCAwcHg7IHBhZGRpbmc6IDBweCAwLjhlbSAwcHggMHB4OyBi b3JkZXItd2lkdGg6IDBweCAxcHggMHB4IDBweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsg Ym9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjIxLCAyMjEsIDIyMSk7IGZvbnQtc3R5bGU6IGluaGVy aXQ7IGZvbnQtdmFyaWFudC1jYXBzOiBpbmhlcml0OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVy dGljYWwtYWxpZ246IGJhc2VsaW5lOyI+TW9uLCAyOSBGZWJydWFyeSAyMDE2IDIzOjA3IFVUQzwv c3Bhbj48YSBpZD0idG9nZ2xlIiBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvc2VhcmNoLz9lbWFpbF9saXN0PW5ldG1vZCZhbXA7cT1XaWx0b24jIiBzdHlsZT0ibWFyZ2lu OiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtc3R5bGU6IGluaGVyaXQ7IGZv bnQtdmFyaWFudC1jYXBzOiBpbmhlcml0OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwt YWxpZ246IGJhc2VsaW5lOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij5TaG93IGhlYWRlcjwvYT48 L3NwYW4+PC9wPjxkaXYgaWQ9Im1zZy1wYXlsb2FkIiBzdHlsZT0ibWFyZ2luOiAxLjVlbSAwcHgg MHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVy dGljYWwtYWxpZ246IGJhc2VsaW5lOyI+PHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBw eDsgZm9udC1zdHlsZTogaW5oZXJpdDsgZm9udC12YXJpYW50LWNhcHM6IGluaGVyaXQ7IGxpbmUt aGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdvcmQtd3JhcDogYnJl YWstd29yZDsiPjxmb250IGZhY2U9IlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHkiPjxzcGFuIHN0 eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1 LCAyNTUsIDApOyI+VGhlIGNoYWlycyB3ZXJlIGp1c3QgcmV2aWV3aW5nIG5vdGVzIGFuZCByZWFs aXplZCB0aGF0IHRoaXMgdGhyZWFkIG5ldmVyIGNsb3NlZCBwcm9wZXJseS4NCg0KSnVlcmdlbiBo YXMgc29tZSBjb25jZXJucyByZWdhcmRpbmcgcmVhbGlzdGljIG1pbGVzdG9uZXMsIHRoYXQgd2Vy ZSBuZXZlciBhZGRyZXNzZWQuICBSb2JlcnQsIGNhbiB5b3UgcGxlYXNlIHRyeSB0byBhZGRyZXNz IEp1ZXJnZW7igJlzIGNvbmNlcm5zIG5vdz8NCg0KQWxzbywgdGhlcmUgd2VyZSBvbmx5IGEgdHdv IHJlc3BvbnNlcyBiZWZvcmUgaW5kaWNhdGluZyB3aWxsaW5nbmVzcyB0byByZXZpZXcgdGhlIGRy YWZ0IGFzIGl0IHByb2dyZXNzZXMgKHRoYW5rcyBEYW4gYW5kIE1hcnRpbikuICBDYW4gb3RoZXJz IHRoYXQgc3VwcG9ydCB0aGlzIGRyYWZ0IGFuZCB3aWxsaW5nIHRvIHJldmlldyB0aGlzIGRyYWZ0 IHNheSBzbz8NCg0KVGhhbmtzLA0KTmV0bW9kIENoYWlycw0KDQoNCkZyb206IG5ldG1vZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgb24gYmVoYWxmIG9mIEtl bnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNl bkBqdW5pcGVyLm5ldDwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQi Pm1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsmZ3Q7DQpEYXRlOiBUdWVzZGF5LCBE ZWNlbWJlciAxNSwgMjAxNSBhdCAxMTo0OCBBTQ0KVG86ICI8YSBocmVmPSJtYWlsdG86bmV0bW9k QGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RA aWV0Zi5vcmciPm1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OyIgJmx0OzxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mbHQ7PGEgaHJlZj0ibWFp bHRvOm5ldG1vZEBpZXRmLm9yZyI+bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ow0K U3ViamVjdDogW25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRv bi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQNCg0KDQpUaGUgbWludXRl cyBmb3IgSUVURiA5NCBzaG93IHRoYXQgdGhlcmUgd2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRv cHRpbmcgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICAg VGhlIG1pbnV0ZXMgYWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJt ZWQgb24gdGhlIG1haWxpbmcgbGlzdCwgd2hpY2ggSSBhbSBkb2luZyBub3cuDQoNClNob3VsZCB3 ZSBtb3ZlIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBhIFdH IGl0ZW0gYW5kIGNvcnJlc3BvbmRpbmdseSBhZGQgdGhpcyB0byB0aGUgV0cgY2hhcnRlciBhcyBh IG1pbGVzdG9uZT8gIFBsZWFzZSBjb21tZW50IGJ5IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1 IGF0IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUgV0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhl ciBvciBub3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1 bWVudC4NCg0KVGhhbmtzLA0KS2VudA0KPC9zcGFuPjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiBpbmhl cml0OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij4NCjwvc3Bhbj48L3ByZT48L2Rp dj5TZW50IGZyb20gbXkgaVBhZDwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-C52D34DB-BDA8-4D52-A3DC-2810DA8B54D8-- --Apple-Mail-03A6E4C9-EA4E-4E65-9C01-743D42B45B53 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5zCCBeMw ggPLoAMCAQICEQCYS4jmwxNQqniBrBdU7S3YMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIzMTE5 MjAyNloXDTE3MTIzMTE5MjAyNVowYDERMA8GA1UECgwIRXJpY3Nzb24xEjAQBgNVBAMMCUVyaWMg R3JheTElMCMGCSqGSIb3DQEJARYWZXJpYy5ncmF5QGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHRUVS SUdSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIlMl/jl+AkgaIjIzEpXGCYxvFXz 17v9ZSd3zfUuH1OafZMyy0aZpBog39btvM7ZVrihvhjDL1h0oKHLFbEFIOuhIsDdXVU5NFAwVcNn VYT1NstvHkQQ19tNoL6oxlh6/fdhQ18VQNIvKMjfykuILypr2Uf1FSa5/ApNS7yvh9qXXflmsS76 PTa7GAb5uqW3IX8b/H/OvzUtR9lvSgd8E5j/SmcARHReBJn9VKmg2roZUKtiW4Qp989K8/zUI3F5 hVT+Cf08H5vBjc4+2axzQ4ae2JH5Fe9OZP/yCiB3yreKqop4UMdNl+aJuolFnCm4PTO8AgmQHT+i Vn/coKeWQLsCAwEAAaOCAbwwggG4MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3Qu dGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAo BggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0 cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2Vy MCEGA1UdEQQaMBiBFmVyaWMuZ3JheUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIP AgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQ9QnvpKIwR U4CeORX8hs167SV3YTAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8E BAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAEKhCmOeiE9igJ2BRf2YSEA551K3eJ+L308zxUrg8ETH 4FiplFJ6n8J2Qpw8wsT/ZIBbjIsGyXL8J0Wfloo00157bAijqK8x/9DMJBzonMAZk+MdtbWSzvK7 iHMDGHiz11e8MHoVL0bsbgmeiqaRp0F5bO9FOmSC1ZHDVFP8BeYqxObPizR2CA0cwxKclQTrrDvo 9jES0vbIRgE0oE2Omtl9nYtmEk68jo+92ofY/lRM4u8bLcP923rN8kWNcM4krzw4ionp62OhqY1u OY91+F2d3+6SzoF81quKTJyP6HHnZ0+nXfR0qApb1EVL1b4fluhJ8fXwjTZszOdnqbX1Ei7tzno8 d/DpAOrXHB9iUXOGJxFbfCAPUxoG0ipVu93s2AnIDM4CRrodUrkrFd2Gwd84pUDBajxdisQxx1aM HU20ldi/s/hETTvOJrdy3JeGcWwndKtlsh9np5sX32+W9ucUtgWVsouQO4OmJXiOrsQKFd0fyhx2 OecgIvpASRMSU2S+/Aa2o65u82PlwC0tKu5+JWig084SP6461K0vXHUgOFOGINdHv3NUNY+RrbaB +rf86h1FyjwhBPgQYgLK4RfKCeg8X3imQSTaSn2MMbBOcOB498v6FOcR7O6dSWskXliiFXP+HqeR rHHVHMCUWVGKABPNv/aCNqe3MizGf9OTMYICmTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAJhLiObDE1CqeIGsF1Tt LdgwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTYwNDA2MTM1NzUyWjAjBgkqhkiG9w0BCQQxFgQUWsCTPzgDpEPPAiP8tjY4X6vD7YYwXgYJ KwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIRAJhLiObDE1CqeIGsF1TtLdgwYAYLKoZIhvcNAQkQAgsxUaBPMDox ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy AhEAmEuI5sMTUKp4gawXVO0t2DANBgkqhkiG9w0BAQEFAASCAQA+p3tL9+McX38MPT0Ypeaaln1I 30ZEyya+hUNvSvvc8rAPOSz5TQNfsn7qjFGErhKqGDHo9gaMotSNnLauc84JfNvJYfqtSx3LDo6v iPA/jJcsqaM4crR5XIif3UnO2IAF+czt+1guMVgnLi7Qm/x1AawOeVaDFvTMhY9jUGeHwEoTktA/ AHgCOacINqV3aGWumxJx8JK9aKqMbCjp+msvLg2/C5XQpBfEcD53sAXCEmN18/CJdItccDL6WLx2 ZacKJJftdk57B9mXBE483c5YQ/6fP/YLFj6Cw+a+fbLNcKI+GMnM1GYsuIgWbqHPCmQSr+FhAshS 94iYL6nJvOdWAAAAAAAA --Apple-Mail-03A6E4C9-EA4E-4E65-9C01-743D42B45B53-- From nobody Wed Apr 6 07:08:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261D12D5D7 for ; Wed, 6 Apr 2016 07:08:06 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BytOXZ_APe3E for ; Wed, 6 Apr 2016 07:08:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D386F12D1B4 for ; Wed, 6 Apr 2016 07:08:03 -0700 (PDT) Received: from localhost (dhcp-b234.meeting.ietf.org [31.133.178.52]) by trail.lhotka.name (Postfix) with ESMTPSA id B93721CC0249 for ; Wed, 6 Apr 2016 16:08:09 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 06 Apr 2016 11:07:59 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] compact versus iterative representation of the overall schema X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:08:07 -0000 Hi, with a schema mount mechanism in place, there are two different options for constructing the overall schema (their combinations are possible, too): 1. Define schema mount as an extension of YANG library so that it defines YANG modules, revisions, features and deviations as before but also the way how they are combined into a hierarchical structure of schemas. 2. Apart from YANG Library data, the server just specifies the mount points. A client of an NM protocol is expected to fetch a new instance of YANG library and/or subordinate mount points as state data from a well-known location under each mount point. I think that #1 should be available (alone or along with #2) because there are cases when YANG is used as a data modelling language outside the context of a NM protocol =E2=80=93 Eliot Lear's MUD presentation is one example. Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 6 07:08:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9A12D5EA; Wed, 6 Apr 2016 07:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5NrXcHBMJ2n; Wed, 6 Apr 2016 07:08:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4270B12D65D; Wed, 6 Apr 2016 07:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eWfKRYoT+KNPzKmX7/z9dLoOcfmGR8JLE2ANKXZQH4E=; b=Bi14qzIRPUJDzoyd3eBjEKE5MJg8WAR3LOqtkC51pOmNuoAus3Hr14IrKVydzzqlCzGSin/Zuehy75zyHFQa3lwulQxu7kAxbZbr3N14KYAlZ8NU43IIZv7gcxoxAyEA6XA1vcpKP5XABOh7kATWz0v/f0nzx5QuQsKpPqe+twc= Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1606.namprd05.prod.outlook.com (10.160.203.155) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 14:08:17 +0000 Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 14:08:17 +0000 From: Gert Grammel To: Juergen Schoenwaelder , "Rajiv Asati (rajiva)" Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ9001qAgAVt/oCAAA0XAIAB8nqAgABDUICAAE4FgA== Date: Wed, 6 Apr 2016 14:08:17 +0000 Message-ID: References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> <20160406062858.GA60806@elstar.local> In-Reply-To: <20160406062858.GA60806@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-ms-office365-filtering-correlation-id: 4b106438-2c23-46a5-b2fd-08d35e24e6f8 x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1606; 5:kRtRjuPN4ycbI37rDI30wJrCp5uxYzXZpQE9V89RVCtQvjUBw9p7FTs78Qp9uBUGmo5Fr28xnIA/VG46rY6ANluL/1CuKCS6ulnsdY9zyOGrNqyk2KCo350ShSepYMLdh8+XIiOF4DiWxQf6z2qX3g==; 24:ZSAXNPc1T+YCRLTJKH0ij8h9HBelwb3OjDevHieFb1I1wO6LTJcFWMzgUj3byo4kEZVsZfSFR0gB6GJkoJUUozlbCFoYL6RrEeJWgD9Iczs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1606; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY1PR0501MB1606; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1606; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(15975445007)(77096005)(99286002)(93886004)(2950100001)(2900100001)(83506001)(11100500001)(106116001)(19580405001)(122556002)(86362001)(5002640100001)(50986999)(87936001)(81166005)(54356999)(19580395003)(6116002)(1220700001)(66066001)(3660700001)(5001770100001)(4001350100001)(586003)(76176999)(3846002)(189998001)(1096002)(102836003)(5004730100002)(2906002)(3280700002)(5008740100001)(36756003)(10400500002)(4326007)(92566002)(225543005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1606; H:BY1PR0501MB1605.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 14:08:17.4857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1606 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:08:33 -0000 This case is another reason why the intended config should not be touched by the server. Juergen is right that there are lots of different implementations. It is the implementer=B9s choice where to put configuratio= n state. Typically if a server supports rollback, the state is stored in a database, otherwise it is often stored directly on HW. Both versions survive a reboot. If you remove the LC (=3DLine Card?) the result is either a) intended =3D config !=3D active in case of a central config repository o= r b) intended !=3D config =3D active in case of config stored on LC a) is a case that is often tolerated or even desired, as it allows to pre-configure HW before it becomes physically available. B) is an error condition. Gert On 2016-06-04 03:28, "netmod on behalf of Juergen Schoenwaelder" wrote: >On Wed, Apr 06, 2016 at 02:28:03AM +0000, Rajiv Asati (rajiva) wrote: >> Hi Juergen, >>=20 >> Thanks for the clarity. I somewhat agree. Different lifetime shouldn't >>really cause any impact. >>=20 >> One nit, >>=20 >> When I pull out a configured interface, the operational state of this >> interface is gone but not the config - if I put the interface back, it >> should come up configured as before. >>=20 >> Depends. If LC itself is removed, then all the related interfaces would >>be removed from the running-config. And reinserting the LC may not bring >>their individual conf back (ignoring the notifications). > >Assuming LC means line card if not discard the following (and explain >what LC means). I believe the answer here is that systems treat this >differently and there is no universal answer. Some systems seem to >store line card config on the line card itself, other systems >associate config with the physical location of a port or interface, >yet others associate config with a name of an interface (which may not >indicate the physical location of an interface). Since implementations >really differ here, we support multiple implementation options in the >interfaces data model. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 07:23:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1075F12D66E for ; Wed, 6 Apr 2016 07:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wuh8pwX88Wmh for ; Wed, 6 Apr 2016 07:23:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CEF5E12D66A for ; Wed, 6 Apr 2016 07:23:14 -0700 (PDT) Received: from localhost (dhcp-b234.meeting.ietf.org [31.133.178.52]) by trail.lhotka.name (Postfix) with ESMTPSA id 8E6221CC0249 for ; Wed, 6 Apr 2016 16:23:20 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 06 Apr 2016 11:23:10 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] permitted mount points X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:23:24 -0000 Hi, we have to specify a subset of schema node types that are permitted as candidates for mount points. The proposals were seen so far: 1. container and list 2. container, list, case, anydata 3. anydata only I prefer #2 because it is closest to the restrictions on augment's target node. I think that anydata should be allowed in any case, but only the other hand I don't support #3 because - anydata (as defined in 6020bis) makes the schema weaker: permitted child nodes aren't limited to those specified in mounted subschemas; - according to the existing rules, old clients have to be prepared to face unknown data pretty much anywhere: for example, if a client only supports module A, and the server advertises A + B where B augments A, then the client may see data from B. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 6 11:09:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7112D0E1 for ; Wed, 6 Apr 2016 11:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37AzaSMougip for ; Wed, 6 Apr 2016 11:09:45 -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 08EC612D0DD for ; Wed, 6 Apr 2016 11:09:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 3C773D8CBAE3A for ; Wed, 6 Apr 2016 18:09:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u36I9Ye1032554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Apr 2016 18:09:34 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u36I9XL5015768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Apr 2016 20:09:34 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 20:09:34 +0200 From: "Scharf, Michael (Nokia - DE)" To: "netmod@ietf.org" Thread-Topic: YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQ== Date: Wed, 6 Apr 2016 18:09:33 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:09:56 -0000 draft-ietf-netmod-yang-model-classification suggests that a YANG model is e= ither a "Network Element YANG Model" or a "Network Service YANG Model". How would draft-ietf-teas-yang-te-topo be classified according to that? Tho= ughts? Thanks Michael From nobody Wed Apr 6 12:14:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06C912D13D for ; Wed, 6 Apr 2016 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 627H-O0WlJEB for ; Wed, 6 Apr 2016 12:14:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B79012D52F for ; Wed, 6 Apr 2016 12:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=745; q=dns/txt; s=iport; t=1459970079; x=1461179679; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ylikE1YXPooBaQNBQ7KBuwjV755BgIDYoPJ/BYroksA=; b=ZVtfHngk0s5GOkwOxc+2AIF63fDqoX+BwVlkJKImok67JN12MxzzoIiG Np5CjstQA7RtFrChyV6b4rYy5SIkHeVznWnH7161oLhsZyr6Ef69LyDc9 YXszB7QkEUBLxjuJJUUEIZmNBlLGkXgU8B5Jt7WC+9Xl1guXFxPoIr/5Z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgAZXwVX/4wNJK1dgzdTfQa6RgENg?= =?us-ascii?q?XMXCoUiSgKBTzgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwULAgEIGB4QJwslAQE?= =?us-ascii?q?EDgWIHwgOwRkBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhgXWCVoQ9gy2CKwWYA?= =?us-ascii?q?QGOCo8OjyABHgEBQoNnbId1fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,448,1454976000"; d="scan'208";a="258145772" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 19:14:38 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u36JEcex016522 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 19:14:38 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 14:14:37 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 14:14:37 -0500 From: "Carl Moberg (camoberg)" To: "Scharf, Michael (Nokia - DE)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA Date: Wed, 6 Apr 2016 19:14:37 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.253.74] Content-Type: text/plain; charset="us-ascii" Content-ID: <5BE3AFBB9C79F64F91422BB3B85191B8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:14:42 -0000 Is the YANG model in draft-ietf-teas-yang-te-topo expected to be implement= ed in a network element, on a management system or perhaps either? -- Carl Moberg Technology Director, CVG camoberg@cisco.com > On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) wrote: >=20 > draft-ietf-netmod-yang-model-classification suggests that a YANG model is= either a "Network Element YANG Model" or a "Network Service YANG Model". >=20 > How would draft-ietf-teas-yang-te-topo be classified according to that? T= houghts? >=20 > Thanks >=20 > Michael >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 12:31:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3D12D791 for ; Wed, 6 Apr 2016 12:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9kC3tTK-YPe for ; Wed, 6 Apr 2016 12:31:13 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id BEA2A12D0A8 for ; Wed, 6 Apr 2016 12:31:13 -0700 (PDT) Received: (qmail 20270 invoked by uid 0); 6 Apr 2016 19:31:13 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 6 Apr 2016 19:31:13 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id f7X61s00H2SSUrH017X9R0; Wed, 06 Apr 2016 13:31:12 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=SGZlxK3pxFIA:10 a=kziv93cY1bsA:10 a=AUd_NHdVAAAA:8 a=9qxNCY_qAAAA:8 a=48vgC7mUAAAA:8 a=BEi7Px3vIW876W1OkyUA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From; bh=JsWbWeyeqZCMvM6sfv1FIRJ3MJaqW26u/Gl9hrYnjRc=; b=VGhXEj59yl/5NMbmr/5Fy0YiKp P6Gm4eOkmuI1CfaZD+Ox85wvsK7ZNQSy5hJtm57etwfrRtfTRY0pmHTkXSuybzrqURIM4/hCAVzdy dKL4r2rm5g0NuKpfer1m0JVrC; Received: from [31.133.177.116] (port=35149) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_2) (envelope-from ) id 1antAR-0001rm-4c; Wed, 06 Apr 2016 13:31:07 -0600 From: Lou Berger To: "Carl Moberg (camoberg)" , "Scharf, Michael (Nokia - DE)" Date: Wed, 06 Apr 2016 16:31:00 -0300 Message-ID: <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: AquaMail/1.6.1.5 (build: 26000005) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 31.133.177.116 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:31:21 -0000 My personal view is either. .. On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" wrote: > > Is the YANG model in draft-ietf-teas-yang-te-topo expected to be > implemented in a network element, on a management system or perhaps either? > > -- > Carl Moberg > Technology Director, CVG > camoberg@cisco.com > >> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) >> wrote: >> >> draft-ietf-netmod-yang-model-classification suggests that a YANG model is >> either a "Network Element YANG Model" or a "Network Service YANG Model". >> >> How would draft-ietf-teas-yang-te-topo be classified according to that? >> Thoughts? >> >> Thanks >> >> Michael >> >> _______________________________________________ >> 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 Apr 6 13:33:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F209812D174 for ; Wed, 6 Apr 2016 13:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coriant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC9-wMwSiZfp for ; Wed, 6 Apr 2016 13:33:40 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0607.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::607]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE7C12D1BC for ; Wed, 6 Apr 2016 13:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coriant.onmicrosoft.com; s=selector1-coriant-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7oqjHwDVeGPVFGJFW5sVZdTfkP9kQ0DkdlgV8AfT6lw=; b=VZLXwL9FSVpMkeIHhRmpTxJx4zIgJhWlGl/PJ5DzrCHOJHak4RJiFdsSKB2JIp3OMZQn4vBxSHeVN6QKQS6MOHq5X4tSbunv9ejeLG9A25oCvnXoYjfzsqs6z3Iy8RSFJvXZ5mWDrt7MPdHw/7pbQhWbNwHlEtPPb7So0Uwkcpk= Received: from HE1PR04MB0985.eurprd04.prod.outlook.com (10.162.21.22) by HE1PR04MB0987.eurprd04.prod.outlook.com (10.162.21.26) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 20:33:22 +0000 Received: from HE1PR04MB0985.eurprd04.prod.outlook.com ([10.162.21.22]) by HE1PR04MB0985.eurprd04.prod.outlook.com ([10.162.21.22]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 20:33:22 +0000 From: "Doolan, Paul (Coriant - US/Irving)" To: Lou Berger Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA//+wwwCAABFrgA== Date: Wed, 6 Apr 2016 20:33:22 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=coriant.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [98.229.158.74] x-ms-office365-filtering-correlation-id: 12d94ea9-ebf6-4c89-fb3b-08d35e5ab2c7 x-microsoft-exchange-diagnostics: 1; HE1PR04MB0987; 5:wMgsNROtSFyOn6PFxjGCgFm1v+LvFlkH1IYz8uHchoSYf/HXwoXIjT0pG4nxCzoaEFYnge8BzCdQqp/DeNVpzIrIIUHg6uVT+MGq4T03+hOL2GsUSgSrcJQeLWRbb20qRUeakIkBncYhjDo8nT4XqQ==; 24:2XHIUVeyt5rW52oPrSfqX66yehje2YODVrkMoxsEsjOGcdQY5AA503rgMktR8H34k4FDyIPjMHq9mRsGAQeEj4NwZK4qB18RnaZVJUDSeWA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB0987; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR04MB0987; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB0987; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(50226001)(92566002)(2900100001)(5002640100001)(2950100001)(15975445007)(81166005)(5004730100002)(189998001)(110136002)(77096005)(87936001)(33656002)(36756003)(19580405001)(122556002)(1096002)(6116002)(10400500002)(4326007)(5008740100001)(1220700001)(50986999)(102836003)(2906002)(82746002)(11100500001)(76176999)(586003)(83716003)(57306001)(19580395003)(3846002)(86362001)(3660700001)(66066001)(3280700002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB0987; H:HE1PR04MB0985.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 20:33:22.7014 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 76595477-907e-4695-988b-a6b39087332d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB0987 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:33:43 -0000 Not sure either captures the case where, in the same network, there are ins= tances of the model on NEs and on the management systems. Does "both" cover that case ? pd There has already been discussion of the concept of a switch matrix (inside= an NE) which can On Apr 6, 2016, at 3:31 PM, Lou Berger wrote: > My personal view is either. .. >=20 >=20 > On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" = wrote: >=20 >>=20 >> Is the YANG model in draft-ietf-teas-yang-te-topo expected to be implem= ented in a network element, on a management system or perhaps either? >>=20 >> -- >> Carl Moberg >> Technology Director, CVG >> camoberg@cisco.com >>=20 >>> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) wrote: >>>=20 >>> draft-ietf-netmod-yang-model-classification suggests that a YANG model = is either a "Network Element YANG Model" or a "Network Service YANG Model". >>>=20 >>> How would draft-ietf-teas-yang-te-topo be classified according to that?= Thoughts? >>>=20 >>> Thanks >>>=20 >>> Michael >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 14:34:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D812D15D for ; Wed, 6 Apr 2016 14:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Liz0huA8Gm-Q for ; Wed, 6 Apr 2016 14:33:57 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E9F12D160 for ; Wed, 6 Apr 2016 14:33:57 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id B22257E930B72; Wed, 6 Apr 2016 21:33:53 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u36LXul4027487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 21:33:56 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u36LXtce004762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2016 21:33:55 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.144]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 17:33:55 -0400 From: "Sterne, Jason (Nokia - CA)" To: "EXT Doolan, Paul (Coriant - US/Irving)" , "Lou Berger" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA///z0QCAABFtAIAAMpcg Date: Wed, 6 Apr 2016 21:33:55 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.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: [135.5.27.16] 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] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:34:00 -0000 Exposing a model of a *network* seems like something more appropriate on a = controller that sits above individual NEs and aggregates network wide infor= mation no ? =20 Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Doolan, Paul= (Coriant - US/Irving) Sent: Wednesday, April 06, 2016 17:33 To: Lou Berger Cc: netmod@ietf.org Subject: Re: [netmod] YANG model classification? Not sure either captures the case where, in the same network, there are ins= tances of the model on NEs and on the management systems. Does "both" cover that case ? pd There has already been discussion of the concept of a switch matrix (inside= an NE) which can On Apr 6, 2016, at 3:31 PM, Lou Berger = wrote: > My personal view is either. .. >=20 >=20 > On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" = wrote: >=20 >>=20 >> Is the YANG model in draft-ietf-teas-yang-te-topo expected to be implem= ented in a network element, on a management system or perhaps either? >>=20 >> -- >> Carl Moberg >> Technology Director, CVG >> camoberg@cisco.com >>=20 >>> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) wrote: >>>=20 >>> draft-ietf-netmod-yang-model-classification suggests that a YANG model = is either a "Network Element YANG Model" or a "Network Service YANG Model". >>>=20 >>> How would draft-ietf-teas-yang-te-topo be classified according to that?= Thoughts? >>>=20 >>> Thanks >>>=20 >>> Michael >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 14:48:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77812D160 for ; Wed, 6 Apr 2016 14:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94F2VUGX0crZ for ; Wed, 6 Apr 2016 14:48:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FED12D6C8 for ; Wed, 6 Apr 2016 14:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2776; q=dns/txt; s=iport; t=1459978886; x=1461188486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IjBETauknoFy8U1hjgnc+Nd2KEQ7P+N9+VMtdaSpYDY=; b=df6E4ZiydpWPwMAfkOMtHkxzO9qXU/dMhSrF9jxVtHrVMxboweBcspPF xQaUm/84Zwf8Y/uE1FL5Tv6Z/nSyeMUdkKxrX58iATEm6hjfP49RzLKrI Ky5TwQawaH+bHhd30gFqMiVxdnrpN8gBP11iwbD1eyT269OW9Cpf492Xr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgA/ggVX/4kNJK1dgzdTfQa6RwENg?= =?us-ascii?q?XMXCoUiSgKBUDgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwUHBAIBCBEEAQEBHgk?= =?us-ascii?q?HJwsUCQgBAQQOBYgfCA7BRwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdYJWh?= =?us-ascii?q?D2DLYIrBZgBAY4Kjw6PIAEeAQFCg2dsh3V+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,448,1454976000"; d="scan'208";a="89028831" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 21:41:04 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u36Lf4pj032465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 21:41:04 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 16:41:03 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 16:41:03 -0500 From: "Carl Moberg (camoberg)" To: "Sterne, Jason (Nokia - CA)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoA= Date: Wed, 6 Apr 2016 21:41:03 +0000 Message-ID: <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.253.74] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F171260B893FB46808662CF8655B0B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:48:22 -0000 There is a case that can be made for topology models capable of exposing t= opologies both from the view of a participant node as well as an all-seeing= orchestrator/controller. -- Carl Moberg Technology Director, CVG camoberg@cisco.com > On Apr 6, 2016, at 11:33 PM, Sterne, Jason (Nokia - CA) wrote: >=20 > Exposing a model of a *network* seems like something more appropriate on = a controller that sits above individual NEs and aggregates network wide inf= ormation no ? =20 > Jason >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Doolan, Pa= ul (Coriant - US/Irving) > Sent: Wednesday, April 06, 2016 17:33 > To: Lou Berger > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG model classification? >=20 > Not sure either captures the case where, in the same network, there are i= nstances of the model on NEs and on the management systems. >=20 > Does "both" cover that case ? >=20 > pd >=20 > There has already been discussion of the concept of a switch matrix (insi= de an NE) which can On Apr 6, 2016, at 3:31 PM, Lou Berger wrote: >=20 >> My personal view is either. .. >>=20 >>=20 >> On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" wrote: >>=20 >>>=20 >>> Is the YANG model in draft-ietf-teas-yang-te-topo expected to be imple= mented in a network element, on a management system or perhaps either? >>>=20 >>> -- >>> Carl Moberg >>> Technology Director, CVG >>> camoberg@cisco.com >>>=20 >>>> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) wrote: >>>>=20 >>>> draft-ietf-netmod-yang-model-classification suggests that a YANG model= is either a "Network Element YANG Model" or a "Network Service YANG Model"= . >>>>=20 >>>> How would draft-ietf-teas-yang-te-topo be classified according to that= ? Thoughts? >>>>=20 >>>> Thanks >>>>=20 >>>> Michael >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 17:09:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D47D12D1BA for ; Wed, 6 Apr 2016 17:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coriant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN6X7Z1GQLas for ; Wed, 6 Apr 2016 17:09:14 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0665.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::665]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F7E12D180 for ; Wed, 6 Apr 2016 17:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coriant.onmicrosoft.com; s=selector1-coriant-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5WAx/N2JnVYeombwKZE3tzQ62pYXA2C7t0iUZQPiZuw=; b=Bl7BdWi15/x5zhGkbfFaAOX9Uq6VpFZhRRqTKpD+OuM0phKBwyNpe78LtKAB+rebVMylGnIA0yRgzoDN8a/mgjUPaY6/lLvsp4ucoCwjWp55cPXdi39vbf8UWmfXnCibh9toPfnRVIiwDrsjkjlqhVU9bd2YpCIZz3hS6PGl+L4= Received: from DB5PR04MB0981.eurprd04.prod.outlook.com (10.161.196.25) by DB5PR04MB0982.eurprd04.prod.outlook.com (10.161.196.26) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 00:08:55 +0000 Received: from DB5PR04MB0981.eurprd04.prod.outlook.com ([10.161.196.25]) by DB5PR04MB0981.eurprd04.prod.outlook.com ([10.161.196.25]) with mapi id 15.01.0453.027; Thu, 7 Apr 2016 00:08:55 +0000 From: "Doolan, Paul (Coriant - US/Irving)" To: "Sterne, Jason (Nokia - CA)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA//+wwwCAABFrgIAAEO2AgAArTQA= Date: Thu, 7 Apr 2016 00:08:54 +0000 Message-ID: <11742C0E-DAF6-46ED-8BA6-9EB14EA35B94@coriant.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=coriant.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [98.229.158.74] x-ms-office365-filtering-correlation-id: a9c686f0-7560-4dc5-ff68-08d35e78cf22 x-microsoft-exchange-diagnostics: 1; DB5PR04MB0982; 5:EtdqxcGtsniWXhjoZ8n3VkcLgR1yhYbiak6kYM4eLVp1uojTqX+xDK3jlOy2q8YvYVHJto/4cX+Advk6THhvh7bkuHxNoElNOkDghR3GxAtQ1UjQOcrjJi0TBXQVhprIdZ2a3OYvH5DINeSYkAGNzw==; 24:iJmQKALd805bSyVocEjb+XGVKBVCX82edbtTz2xOGvPPgTV957fpUbfwTPRvXfNxGekFJrEqSCqFuFDmPtKL4im8Ozk15ropuunXnEloW4E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB0982; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB5PR04MB0982; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB0982; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(24454002)(92566002)(189998001)(33656002)(15975445007)(5008740100001)(1096002)(81166005)(82746002)(2900100001)(2950100001)(110136002)(66066001)(86362001)(36756003)(2906002)(93886004)(87936001)(76176999)(50226001)(122556002)(10400500002)(83716003)(77096005)(1220700001)(11100500001)(586003)(5002640100001)(19580395003)(3660700001)(19580405001)(4326007)(6116002)(102836003)(50986999)(3846002)(3280700002)(5004730100002)(57306001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB0982; H:DB5PR04MB0981.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <2BECECB3A5BF4448A6186E807D631344@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 00:08:54.7854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 76595477-907e-4695-988b-a6b39087332d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB0982 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:09:17 -0000 There's a fractal element to this. Depending on the scale at which you look= at these things - be they networks, NEs or even the switching fabrics with= in those - they are all similar to the extent that you can describe their i= nternal connectivity with a graph.=20 I guess another way to look at this is that big networks are out of little = networks built ;-) pd =20 On Apr 6, 2016, at 5:33 PM, "Sterne, Jason (Nokia - CA)" wrote: > Exposing a model of a *network* seems like something more appropriate on = a controller that sits above individual NEs and aggregates network wide inf= ormation no ? =20 > Jason >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Doolan, Pa= ul (Coriant - US/Irving) > Sent: Wednesday, April 06, 2016 17:33 > To: Lou Berger > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG model classification? >=20 > Not sure either captures the case where, in the same network, there are i= nstances of the model on NEs and on the management systems. >=20 > Does "both" cover that case ? >=20 > pd >=20 > There has already been discussion of the concept of a switch matrix (insi= de an NE) which can On Apr 6, 2016, at 3:31 PM, Lou Berger wrote: >=20 >> My personal view is either. .. >>=20 >>=20 >> On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" wrote: >>=20 >>>=20 >>> Is the YANG model in draft-ietf-teas-yang-te-topo expected to be imple= mented in a network element, on a management system or perhaps either? >>>=20 >>> -- >>> Carl Moberg >>> Technology Director, CVG >>> camoberg@cisco.com >>>=20 >>>> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) wrote: >>>>=20 >>>> draft-ietf-netmod-yang-model-classification suggests that a YANG model= is either a "Network Element YANG Model" or a "Network Service YANG Model"= . >>>>=20 >>>> How would draft-ietf-teas-yang-te-topo be classified according to that= ? Thoughts? >>>>=20 >>>> Thanks >>>>=20 >>>> Michael >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 17:40:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB0112D806 for ; Wed, 6 Apr 2016 17:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coriant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7jeLkkFJ1wS for ; Wed, 6 Apr 2016 17:40:48 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0691.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::691]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5140D12D7F1 for ; Wed, 6 Apr 2016 17:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coriant.onmicrosoft.com; s=selector1-coriant-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UKsItTpzTY+GTdrptt+cNjQnUo9tj/c2wyj6UgjZWX4=; b=s307rrKnbeKlW3jm83MLk2uk082nhCPD/OkTQRqtTp5tSNsLKlTFhC8f88ag8gXuLfhIsB2H6rFc974vv+M3VJAxjjuMerbUpIzUWa2fghs+fbxcnDRVEyIl50c3qBhDyCjqQnU34Moe9J5Ibh3xujFFh27Jtu/TPZPkMfJjo+4= Received: from DB5PR04MB0981.eurprd04.prod.outlook.com (10.161.196.25) by DB5PR04MB0981.eurprd04.prod.outlook.com (10.161.196.25) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 00:40:26 +0000 Received: from DB5PR04MB0981.eurprd04.prod.outlook.com ([10.161.196.25]) by DB5PR04MB0981.eurprd04.prod.outlook.com ([10.161.196.25]) with mapi id 15.01.0453.027; Thu, 7 Apr 2016 00:40:26 +0000 From: "Doolan, Paul (Coriant - US/Irving)" To: "Carl Moberg (camoberg)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA//+wwwCAABFrgIAAEO2AgAAB/oCAADIdgA== Date: Thu, 7 Apr 2016 00:40:26 +0000 Message-ID: <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> In-Reply-To: <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=coriant.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:183:4201:71f3:4d0a:523b:a2b:b759] x-ms-office365-filtering-correlation-id: b0905497-7bae-4d56-5652-08d35e7d366d x-microsoft-exchange-diagnostics: 1; DB5PR04MB0981; 5:yJSKjq+B2OyanSd9MGPtI0zAqLkBn/yq/WdzbUzBni4ChLxdB6HEG0oj6nt9NSvCV35vL2pLAIaq0gobkoAIg6mRnYZq9ALgBGvh+KdddSAU7KoCFOVhxGFg4FntybcRlkbu72mIXRdS97oaCLxg2Q==; 24:D2ElxKVQhz0owmQIPPudA+pET9CrdLShZRnmEOosFcnj/AOvFM99uIUjFS6eToURhXY+iFnkyBq421yAjI2ay9mjIVrewaZoQk8kE9UYoaA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB0981; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR04MB0981; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB0981; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(24454002)(4326007)(5004730100002)(110136002)(50226001)(50986999)(5002640100001)(76176999)(33656002)(189998001)(5008740100001)(83716003)(36756003)(57306001)(92566002)(87936001)(19580395003)(3660700001)(1096002)(2900100001)(2950100001)(3280700002)(6116002)(102836003)(1220700001)(586003)(86362001)(11100500001)(122556002)(93886004)(2906002)(82746002)(77096005)(15975445007)(19580405001)(10400500002)(81166005)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB0981; H:DB5PR04MB0981.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <10D2BCF849ABA84D9AA0A5F72888DBAB@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 00:40:26.5023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 76595477-907e-4695-988b-a6b39087332d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB0981 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:40:51 -0000 Hello Carl,=20 Interesting comment.=20 Would you agree with me that in principle a topology is a topology is a top= ology and, therefore, that we should strive for a model that can be employ= ed recursively at any level in such a (implied) hierarchy ? When I look at topology, i.e fundamentally at a graph, I wish to manipulat= e or exploit aspects of the properties represented by it. In principle it d= oesn't matter to me what it represents. I have the same primitives at my di= sposal to manipulate it regardless of what it represents . Obviously in pra= ctice I might want to check some identifier in/of the topology to ensure th= at it's not a national backbone I'm messing with when I intended to change = an access link in my metro ;-) Do you think that's a reasonable perspective from which to continue this di= scussion ? pd=20 On Apr 6, 2016, at 5:41 PM, "Carl Moberg (camoberg)" wrote: >=20 > There is a case that can be made for topology models capable of exposing = topologies both from the view of a participant node as well as an all-seein= g orchestrator/controller. >=20 > -- > Carl Moberg > Technology Director, CVG > camoberg@cisco.com >=20 >> On Apr 6, 2016, at 11:33 PM, Sterne, Jason (Nokia - CA) wrote: >>=20 >> Exposing a model of a *network* seems like something more appropriate on= a controller that sits above individual NEs and aggregates network wide in= formation no ? =20 >> Jason >>=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Doolan, P= aul (Coriant - US/Irving) >> Sent: Wednesday, April 06, 2016 17:33 >> To: Lou Berger >> Cc: netmod@ietf.org >> Subject: Re: [netmod] YANG model classification? >>=20 >> Not sure either captures the case where, in the same network, there are = instances of the model on NEs and on the management systems. >>=20 >> Does "both" cover that case ? >>=20 >> pd >>=20 >> There has already been discussion of the concept of a switch matrix (ins= ide an NE) which can On Apr 6, 2016, at 3:31 PM, Lou Berger wrote: >>=20 >>> My personal view is either. .. >>>=20 >>>=20 >>> On April 6, 2016 4:15:08 PM "Carl Moberg (camoberg)" wrote: >>>=20 >>>>=20 >>>> Is the YANG model in draft-ietf-teas-yang-te-topo expected to be impl= emented in a network element, on a management system or perhaps either? >>>>=20 >>>> -- >>>> Carl Moberg >>>> Technology Director, CVG >>>> camoberg@cisco.com >>>>=20 >>>>> On Apr 6, 2016, at 8:09 PM, Scharf, Michael (Nokia - DE) wrote: >>>>>=20 >>>>> draft-ietf-netmod-yang-model-classification suggests that a YANG mode= l is either a "Network Element YANG Model" or a "Network Service YANG Model= ". >>>>>=20 >>>>> How would draft-ietf-teas-yang-te-topo be classified according to tha= t? Thoughts? >>>>>=20 >>>>> Thanks >>>>>=20 >>>>> Michael >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Thu Apr 7 01:08:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46612D136 for ; Thu, 7 Apr 2016 01:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOw7mNcZPVel for ; Thu, 7 Apr 2016 01:08:19 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5652112D11E for ; Thu, 7 Apr 2016 01:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6302; q=dns/txt; s=iport; t=1460016499; x=1461226099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=saiTVob/YHFsS/ld5Zx4jWSkKwPqjB1zvY/kdencMUw=; b=R8tm2X4LCmddnsH6+l3aSfb9If5KE+DaTNvW2ZMP5VDvk4jMP60tyM36 Ne3wymhVcYkXzT/P37HOSNwdu9pz3TUEpigOKeoySqGF/93t5vfhYHxfm lRGjgdUikyoZSWvWEMBxdhN9CuxdZmPqw4PLNLgIjY4Xw8gtXl6f7QMA/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgDBFAZX/5xdJa1cgzdTfQa6SQENg?= =?us-ascii?q?XMXCoUiSgIcgSc4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQcEAgEIEQQBAQE?= =?us-ascii?q?CAiMDAgICJQsUAQgIAgQOBYgfCA6vMJFsAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR8hSWBdQiCToQ9GIJqK4IrBYlajioBjguPDo8jAR4BAUKDZ2yHdX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,448,1454976000"; d="scan'208";a="88836169" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 08:08:18 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3788IrW010761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 08:08:18 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 03:08:17 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 03:08:17 -0500 From: "Carl Moberg (camoberg)" To: "Doolan, Paul (Coriant - US/Irving)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoAABkQdAAAPpD0A Date: Thu, 7 Apr 2016 08:08:17 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> In-Reply-To: <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.70] Content-Type: text/plain; charset="utf-8" Content-ID: <637345A08D710841AF0B7C9313C94E4F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 08:08:21 -0000 DQotLQ0KQ2FybCBNb2JlcmcNClRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KY2Ftb2JlcmdAY2lz Y28uY29tDQoNCj4gT24gQXByIDcsIDIwMTYsIGF0IDI6NDAgQU0sIERvb2xhbiwgUGF1bCAoQ29y aWFudCAtIFVTL0lydmluZykgPHBhdWwuZG9vbGFuQGNvcmlhbnQuY29tPiB3cm90ZToNCj4gDQo+ IEhlbGxvIENhcmwsIA0KPiANCj4gSW50ZXJlc3RpbmcgY29tbWVudC4gDQo+IA0KPiBXb3VsZCB5 b3UgYWdyZWUgd2l0aCBtZSB0aGF0IGluIHByaW5jaXBsZSBhIHRvcG9sb2d5IGlzIGEgdG9wb2xv Z3kgaXMgYSB0b3BvbG9neSBhbmQsIHRoZXJlZm9yZSwgIHRoYXQgd2Ugc2hvdWxkIHN0cml2ZSBm b3IgYSBtb2RlbCB0aGF0IGNhbiBiZSBlbXBsb3llZCByZWN1cnNpdmVseSBhdCBhbnkgbGV2ZWwg aW4gc3VjaCBhIChpbXBsaWVkKSBoaWVyYXJjaHkgPw0KDQogSSBkb27igJl0IGtub3cgOi0pIE9u IGEgbW9yZSBzZXJpb3VzIG5vdGUsIEkgd291bGQgc3VnZ2VzdCBpdCBpcyBsaWtlbHkgdG8gZGVw ZW5kIG9uIHRoZSBpbnRlbnQgb2YgdGhlIG1vZGVsIGFuZCBhbGwgdGhlIGNvbW1vbiB0cmFkZW9m ZnMgYmV0d2VlbiB0cnlpbmcgdG8gYmUgZ2VuZXJhbCB5ZXQgdXNlZnVsLg0KDQo+IFdoZW4gSSAg bG9vayBhdCB0b3BvbG9neSwgaS5lIGZ1bmRhbWVudGFsbHkgYXQgYSBncmFwaCwgSSB3aXNoIHRv IG1hbmlwdWxhdGUgb3IgZXhwbG9pdCBhc3BlY3RzIG9mIHRoZSBwcm9wZXJ0aWVzIHJlcHJlc2Vu dGVkIGJ5IGl0LiBJbiBwcmluY2lwbGUgaXQgZG9lc24ndCBtYXR0ZXIgdG8gbWUgd2hhdCBpdCBy ZXByZXNlbnRzLiBJIGhhdmUgdGhlIHNhbWUgcHJpbWl0aXZlcyBhdCBteSBkaXNwb3NhbCB0byBt YW5pcHVsYXRlIGl0IHJlZ2FyZGxlc3Mgb2Ygd2hhdCBpdCByZXByZXNlbnRzIC4gT2J2aW91c2x5 IGluIHByYWN0aWNlIEkgbWlnaHQgd2FudCB0byBjaGVjayBzb21lIGlkZW50aWZpZXIgaW4vb2Yg dGhlIHRvcG9sb2d5IHRvIGVuc3VyZSB0aGF0IGl0J3Mgbm90IGEgbmF0aW9uYWwgYmFja2JvbmUg SSdtIG1lc3Npbmcgd2l0aCB3aGVuIEkgaW50ZW5kZWQgdG8gY2hhbmdlIGFuIGFjY2VzcyBsaW5r IGluIG15IG1ldHJvIDstKQ0KPiANCj4gRG8geW91IHRoaW5rIHRoYXQncyBhIHJlYXNvbmFibGUg cGVyc3BlY3RpdmUgZnJvbSB3aGljaCB0byBjb250aW51ZSB0aGlzIGRpc2N1c3Npb24gPw0KDQog SSBjb21lIGF0IHRoaXMgZnJvbSB0aGUgY2xhc3NpZmljYXRpb24gYW5nbGUsIHNvIG15IGludGVy ZXN0IGlzIGlmIHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBZQU5HIG1vZGVsIGNhbiBvbmx5IGJlIGNs YXNzaWZpZWQgYXMgYSBuZXR3b3JrIHNlcnZpY2UgbW9kZWwgWE9SIGEgbmV0d29yayBkZXZpY2Ug bW9kZWwgYWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0aW9ucyBpbiBkcmFmdC1pZXRmLW5ldG1vZC15 YW5nLW1vZGVsLWNsYXNzaWZpY2F0aW9uIChzZWN0aW9ucyAyLjEgYW5kIDIuMikuIEJhc2VkIG9u IHRoaXMgZGlzY3Vzc2lvbiBJIHRha2UgaXQgdGhhdCBzb21lIG1vZGVscyBhcmUgaW50ZW5kZWQg dG8gYmUgYWJsZSB0byBzZXJ2ZSBpbiBib3RoIHJvbGVzLiBBbmQgd2Ugc2hvdWxkIG1ha2Ugc3Vy ZSB0aGF0IGl04oCZcyBzdXBwb3J0ZWQgaW4gb3VyIGNhdGFsb2cgc3RydWN0dXJlLg0KDQo+IHBk IA0KPiANCj4gT24gQXByIDYsIDIwMTYsIGF0IDU6NDEgUE0sICJDYXJsIE1vYmVyZyAoY2Ftb2Jl cmcpIiA8Y2Ftb2JlcmdAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gDQo+PiANCj4+IFRoZXJlIGlz IGEgY2FzZSB0aGF0IGNhbiBiZSBtYWRlIGZvciB0b3BvbG9neSBtb2RlbHMgY2FwYWJsZSBvZiBl eHBvc2luZyB0b3BvbG9naWVzIGJvdGggZnJvbSB0aGUgdmlldyBvZiBhIHBhcnRpY2lwYW50IG5v ZGUgYXMgd2VsbCBhcyBhbiBhbGwtc2VlaW5nIG9yY2hlc3RyYXRvci9jb250cm9sbGVyLg0KPj4g DQo+PiAtLQ0KPj4gQ2FybCBNb2JlcmcNCj4+IFRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KPj4g Y2Ftb2JlcmdAY2lzY28uY29tDQo+PiANCj4+PiBPbiBBcHIgNiwgMjAxNiwgYXQgMTE6MzMgUE0s IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPiB3cm90 ZToNCj4+PiANCj4+PiBFeHBvc2luZyBhIG1vZGVsIG9mIGEgKm5ldHdvcmsqIHNlZW1zIGxpa2Ug c29tZXRoaW5nIG1vcmUgYXBwcm9wcmlhdGUgb24gYSBjb250cm9sbGVyIHRoYXQgc2l0cyBhYm92 ZSBpbmRpdmlkdWFsIE5FcyBhbmQgYWdncmVnYXRlcyBuZXR3b3JrIHdpZGUgaW5mb3JtYXRpb24g bm8gPyAgDQo+Pj4gSmFzb24NCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgRVhUIERvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZykNCj4+PiBTZW50OiBX ZWRuZXNkYXksIEFwcmlsIDA2LCAyMDE2IDE3OjMzDQo+Pj4gVG86IExvdSBCZXJnZXINCj4+PiBD YzogbmV0bW9kQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwg Y2xhc3NpZmljYXRpb24/DQo+Pj4gDQo+Pj4gTm90IHN1cmUgZWl0aGVyIGNhcHR1cmVzIHRoZSBj YXNlIHdoZXJlLCBpbiB0aGUgc2FtZSBuZXR3b3JrLCB0aGVyZSBhcmUgaW5zdGFuY2VzIG9mIHRo ZSBtb2RlbCBvbiBORXMgYW5kIG9uIHRoZSBtYW5hZ2VtZW50IHN5c3RlbXMuDQo+Pj4gDQo+Pj4g RG9lcyAgImJvdGgiIGNvdmVyIHRoYXQgY2FzZSA/DQo+Pj4gDQo+Pj4gcGQNCj4+PiANCj4+PiBU aGVyZSBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3Npb24gb2YgdGhlIGNvbmNlcHQgb2YgYSBzd2l0 Y2ggbWF0cml4IChpbnNpZGUgYW4gTkUpIHdoaWNoIGNhbiBPbiBBcHIgNiwgMjAxNiwgYXQgMzoz MSBQTSwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+Pj4gDQo+Pj4+IE15 IHBlcnNvbmFsIHZpZXcgaXMgZWl0aGVyLiAuLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIEFwcmls IDYsIDIwMTYgNDoxNTowOCBQTSAiQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSIgPGNhbW9iZXJnQGNp c2NvLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBJcyB0aGUgWUFORyBtb2RlbCBp biBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvIGV4cGVjdGVkIHRvIGJlICBpbXBsZW1lbnRl ZCBpbiBhIG5ldHdvcmsgZWxlbWVudCwgb24gYSBtYW5hZ2VtZW50IHN5c3RlbSBvciBwZXJoYXBz IGVpdGhlcj8NCj4+Pj4+IA0KPj4+Pj4gLS0NCj4+Pj4+IENhcmwgTW9iZXJnDQo+Pj4+PiBUZWNo bm9sb2d5IERpcmVjdG9yLCBDVkcNCj4+Pj4+IGNhbW9iZXJnQGNpc2NvLmNvbQ0KPj4+Pj4gDQo+ Pj4+Pj4gT24gQXByIDYsIDIwMTYsIGF0IDg6MDkgUE0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEg LSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4g ZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiBzdWdnZXN0cyB0aGF0 IGEgWUFORyBtb2RlbCBpcyBlaXRoZXIgYSAiTmV0d29yayBFbGVtZW50IFlBTkcgTW9kZWwiIG9y IGEgIk5ldHdvcmsgU2VydmljZSBZQU5HIE1vZGVsIi4NCj4+Pj4+PiANCj4+Pj4+PiBIb3cgd291 bGQgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wbyBiZSBjbGFzc2lmaWVkIGFjY29yZGluZyB0 byB0aGF0PyBUaG91Z2h0cz8NCj4+Pj4+PiANCj4+Pj4+PiBUaGFua3MNCj4+Pj4+PiANCj4+Pj4+ PiBNaWNoYWVsDQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbmV0 bW9kQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pj4+IG5ldG1vZEBp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCj4+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pj4gbmV0 bW9kQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+PiANCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gDQo+IA0KDQo= From nobody Thu Apr 7 01:55:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A0112D549 for ; Thu, 7 Apr 2016 01:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vXhvDXgAvb6 for ; Thu, 7 Apr 2016 01:55:27 -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 4D29912D10E for ; Thu, 7 Apr 2016 01:55:27 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7B915A939F35; Thu, 7 Apr 2016 08:55:23 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u378tOon004604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 08:55:25 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u378tDXm015265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 10:55:24 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 10:55:19 +0200 From: "Scharf, Michael (Nokia - DE)" To: "EXT Carl Moberg (camoberg)" , "Doolan, Paul (Coriant - US/Irving)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA//+PPACAABFtAIAAEOqAgAAB/4CAADIeAIAAfSGA///UJlA= Date: Thu, 7 Apr 2016 08:55:19 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 08:55:29 -0000 PiBJIGNvbWUgYXQgdGhpcyBmcm9tIHRoZSBjbGFzc2lmaWNhdGlvbiBhbmdsZSwgc28gbXkgaW50 ZXJlc3QgaXMgaWYgdGhlIGFzc3VtcHRpb24gdGhhdA0KPiBhIFlBTkcgbW9kZWwgY2FuIG9ubHkg YmUgY2xhc3NpZmllZCBhcyBhIG5ldHdvcmsgc2VydmljZSBtb2RlbCBYT1IgYSBuZXR3b3JrIGRl dmljZSBtb2RlbA0KPiBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb25zIGluIGRyYWZ0LWlldGYt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24gKHNlY3Rpb25zIDIuMQ0KPiBhbmQgMi4y KS4gQmFzZWQgb24gdGhpcyBkaXNjdXNzaW9uIEkgdGFrZSBpdCB0aGF0IHNvbWUgbW9kZWxzIGFy ZSBpbnRlbmRlZCB0byBiZSBhYmxlIHRvDQo+IHNlcnZlIGluIGJvdGggcm9sZXMuIEFuZCB3ZSBz aG91bGQgbWFrZSBzdXJlIHRoYXQgaXTigJlzIHN1cHBvcnRlZCBpbiBvdXIgY2F0YWxvZyBzdHJ1 Y3R1cmUuDQoNClJlZ2FyZGluZyB0aGUgWE9SIGFzc3VtcHRpb24gZm9yIGNsYXNzaWZpY2F0aW9u Og0KDQpZb3UgbWF5IGFsc28gd2FudCB0byB0aGluayBhYm91dCBZQU5HIG1vZGVscyB0aGF0IGFy ZSBORUlUSEVSIGRldmljZSBOT1Igc2VydmljZSBtb2RlbHMuIEZvciBpbnN0YW5jZSwgd2hhdCBh Ym91dCBSRkMgNjk5MT8gQW5kIEkgdGhpbmsgb3RoZXIsIG1vcmUgdGVjaG5pY2FsIG1vZGVscyBw cmVzZW50ZWQgdGhpcyB3ZWVrIG1heSBmYWxsIGludG8gYSBzaW1pbGFyIGNhdGVnb3J5ICgiZ2Vu ZXJpYyI/KS4NCg0KTWljaGFlbA0KDQo= From nobody Thu Apr 7 01:57:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CE612D606 for ; Thu, 7 Apr 2016 01:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY7bzrs0QP_6 for ; Thu, 7 Apr 2016 01:57:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D4A12D10E for ; Thu, 7 Apr 2016 01:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1388; q=dns/txt; s=iport; t=1460019439; x=1461229039; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jC6ZaaZ+87UUaaM99M++aHQZJXBavRY0qxMwuW2QtKM=; b=UUCW2CKDEtNHbTAlUztpyABQZ0raDZM0Uo/uiTjWyqHSflJhs94AxR8N uPcY1cTrcGUPTL7lUaGH5iUbCHKhjiOGvyyzLzoKnqprIZgLQa3O8pWrz lmcnJA8FR2quTvWVGoi+bsNwjTZ1KZMJrcBsgnr2TOf6taGNS4dlEewh1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAgCrIAZX/51dJa1cgzeBUAa4OoIPA?= =?us-ascii?q?Q2Bc4YNAhyBJTgUAQEBAQEBAWUnhEEBAQEDASMRRQULAgEIGAICJgICAjAVEAI?= =?us-ascii?q?EDgWIHwivO5FqAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXyFJYF1CIJOhD2DAiuCK?= =?us-ascii?q?wEEiVqOKgGOC48OjyMBHgEBQoNnbId1fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,448,1454976000"; d="scan'208";a="258368460" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 08:57:18 +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 u378vISJ017266 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 08:57:18 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 03:57:17 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 03:57:17 -0500 From: "Carl Moberg (camoberg)" To: "Scharf, Michael (Nokia - DE)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoAABkQdAAAPpD0AAAGkXYAAABFJgA== Date: Thu, 7 Apr 2016 08:57:17 +0000 Message-ID: <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.70] Content-Type: text/plain; charset="utf-8" Content-ID: <8542E6FDEED69A45BC2E6A931302820D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 08:57:22 -0000 DQoNCi0tDQpDYXJsIE1vYmVyZw0KVGVjaG5vbG9neSBEaXJlY3RvciwgQ1ZHDQpjYW1vYmVyZ0Bj aXNjby5jb20NCg0KPiBPbiBBcHIgNywgMjAxNiwgYXQgMTA6NTUgQU0sIFNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQo+IA0KPj4g SSBjb21lIGF0IHRoaXMgZnJvbSB0aGUgY2xhc3NpZmljYXRpb24gYW5nbGUsIHNvIG15IGludGVy ZXN0IGlzIGlmIHRoZSBhc3N1bXB0aW9uIHRoYXQNCj4+IGEgWUFORyBtb2RlbCBjYW4gb25seSBi ZSBjbGFzc2lmaWVkIGFzIGEgbmV0d29yayBzZXJ2aWNlIG1vZGVsIFhPUiBhIG5ldHdvcmsgZGV2 aWNlIG1vZGVsDQo+PiBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb25zIGluIGRyYWZ0LWlldGYt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24gKHNlY3Rpb25zIDIuMQ0KPj4gYW5kIDIu MikuIEJhc2VkIG9uIHRoaXMgZGlzY3Vzc2lvbiBJIHRha2UgaXQgdGhhdCBzb21lIG1vZGVscyBh cmUgaW50ZW5kZWQgdG8gYmUgYWJsZSB0bw0KPj4gc2VydmUgaW4gYm90aCByb2xlcy4gQW5kIHdl IHNob3VsZCBtYWtlIHN1cmUgdGhhdCBpdOKAmXMgc3VwcG9ydGVkIGluIG91ciBjYXRhbG9nIHN0 cnVjdHVyZS4NCj4gDQo+IFJlZ2FyZGluZyB0aGUgWE9SIGFzc3VtcHRpb24gZm9yIGNsYXNzaWZp Y2F0aW9uOg0KPiANCj4gWW91IG1heSBhbHNvIHdhbnQgdG8gdGhpbmsgYWJvdXQgWUFORyBtb2Rl bHMgdGhhdCBhcmUgTkVJVEhFUiBkZXZpY2UgTk9SIHNlcnZpY2UgbW9kZWxzLiBGb3IgaW5zdGFu Y2UsIHdoYXQgYWJvdXQgUkZDIDY5OTE/IEFuZCBJIHRoaW5rIG90aGVyLCBtb3JlIHRlY2huaWNh bCBtb2RlbHMgcHJlc2VudGVkIHRoaXMgd2VlayBtYXkgZmFsbCBpbnRvIGEgc2ltaWxhciBjYXRl Z29yeSAoImdlbmVyaWMiPykuDQoNCiBWZXJ5IGdvb2QgcG9pbnQsIHRoYW5rcyEgVGhhdCB3aWxs IG5lZWQgc29tZSBhZGRpdGlvbmFsIHRoaW5raW5nIGFuZCB3cml0aW5nLg== From nobody Thu Apr 7 03:45:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61912D09C for ; Thu, 7 Apr 2016 03:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnmoGRminmaz for ; Thu, 7 Apr 2016 03:45: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 6E4BD12D1E3 for ; Thu, 7 Apr 2016 03:45: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 B8FD8A53; Thu, 7 Apr 2016 12:45:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sLrK9Suew3HN; Thu, 7 Apr 2016 12:45: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; Thu, 7 Apr 2016 12:45:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E916C20045; Thu, 7 Apr 2016 12:45:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h0cuUm4q7Oq3; Thu, 7 Apr 2016 12:45: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 81BCB20043; Thu, 7 Apr 2016 12:45:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 58F9B3A74225; Thu, 7 Apr 2016 12:45:29 +0200 (CEST) Date: Thu, 7 Apr 2016 12:45:29 +0200 From: Juergen Schoenwaelder To: "Scharf, Michael (Nokia - DE)" Message-ID: <20160407104529.GC64000@elstar.local> Mail-Followup-To: "Scharf, Michael (Nokia - DE)" , "EXT Carl Moberg (camoberg)" , "Doolan, Paul (Coriant - US/Irving)" , "netmod@ietf.org" References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.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: <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 10:45:56 -0000 On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia - DE) wrote: > > I come at this from the classification angle, so my interest is if the assumption that > > a YANG model can only be classified as a network service model XOR a network device model > > according to the definitions in draft-ietf-netmod-yang-model-classification (sections 2.1 > > and 2.2). Based on this discussion I take it that some models are intended to be able to > > serve in both roles. And we should make sure that it’s supported in our catalog structure. > > Regarding the XOR assumption for classification: > > You may also want to think about YANG models that are NEITHER device NOR service models. For instance, what about RFC 6991? And I think other, more technical models presented this week may fall into a similar category ("generic"?). > RFC 6991 is not really defining a data model, while ietf-yang-types and ietf-inet-types are both YANG modules they do not define any data nodes that can be implemented. Lets look at RFC 6020bis: o data model: A data model describes how data is represented and accessed. Anyway, the point is that RFC 6991 do not define any data nodes and hence nothing that can be accessed. Perhaps it helps to import terminology into the model classification document and to be explicit that not all YANG modules define YANG data models. /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 Apr 7 04:56:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62CA12D6F3 for ; Thu, 7 Apr 2016 04:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPpIIlCWwTpw for ; Thu, 7 Apr 2016 04:56:00 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC01912D1A1 for ; Thu, 7 Apr 2016 04:55:59 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id j35so60528330qge.0 for ; Thu, 07 Apr 2016 04:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D8SewcW1eEI7k3dd5Uf2tKwKv9BLZ7cKIog8AC6teTk=; b=qmD2S9r4num18VmxC6DZtaAJcWZUV8EM4jMiSD5cPfbRit7JtEFPzXTt8IPi32z1Un cqxEgref7FhIRAjJXWzn5s7/UedHmlW2fBBquhFoVW3x6YpEMKgmCoJwpamhZyLcvn4w RS18AkLW8Md1EYOAWdPNM2xy42EBAWzwCjADTtcN0JIHmRScJOnrjbFfL6jyuUg+OCxK LghY+wPMAVqA3fkUGSpyirLga3JjR3UCZo4arMKwQzRWzs+CeqA3QgQ9T5O/PFaM0tvm 0PphGFCIy4DBJ9uQcLC+Z8lCpsRpiP0elJ3zWWZBSJZ4BXKJ6fitvCiE0t6ezlb8jM+b T2NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D8SewcW1eEI7k3dd5Uf2tKwKv9BLZ7cKIog8AC6teTk=; b=Kzpxm4R/DsrTPP/lSKwwBsE13l45OyCfAqJz8uqi4EcC/BUzg2iIc/v0yI9heFg9Cz eKnzKbCOlTbGjYxgVVF9+v3riuQZPT3qv7TYrHbXHD46beWdfGc6x/e5eUssj2fw9FRF 4Jx2eSluqJ8G9HuJw+pKqN7Ml+Qi7BxuDTikb9BBQ06kYZELrW+S7FkiaEzpszY4zwCl egA7p0XmzMDfVy9vGcMMG9NmCjq7GJqwp6p/d44e3j+g+JbMjgz76YfuItxVQM2Y1MXM ElhPb6IYLz9mBZdG/FKC/HFNKxHvG9l+DM1VdQi4QjlCJuF3+NNKAEwAy8BnNO6D5JI4 cSsA== X-Gm-Message-State: AD7BkJI08hn9RXuwd0aSs+4LHtZpNogsThSnfWunAXzlfCcaFOSLFBvAuuJmgJr1ubK1nQ== X-Received: by 10.140.132.68 with SMTP id 65mr3125120qhe.13.1460030158974; Thu, 07 Apr 2016 04:55:58 -0700 (PDT) Received: from [172.16.1.10] ([200.61.9.66]) by smtp.gmail.com with ESMTPSA id k25sm3249121qkl.29.2016.04.07.04.55.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 04:55:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <20160407104529.GC64000@elstar.local> Date: Thu, 7 Apr 2016 08:56:40 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7FCDA7AF-C42C-4E09-91A6-AC2DA5C98E09@gmail.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160407104529.GC64000@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 11:56:02 -0000 > On Apr 7, 2016, at 7:45 AM, Juergen Schoenwaelder = wrote: >=20 > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia - DE) = wrote: >>> I come at this from the classification angle, so my interest is if = the assumption that >>> a YANG model can only be classified as a network service model XOR a = network device model >>> according to the definitions in = draft-ietf-netmod-yang-model-classification (sections 2.1 >>> and 2.2). Based on this discussion I take it that some models are = intended to be able to >>> serve in both roles. And we should make sure that it=E2=80=99s = supported in our catalog structure. >>=20 >> Regarding the XOR assumption for classification: >>=20 >> You may also want to think about YANG models that are NEITHER device = NOR service models. For instance, what about RFC 6991? And I think = other, more technical models presented this week may fall into a similar = category ("generic"?). >>=20 >=20 > RFC 6991 is not really defining a data model, while ietf-yang-types > and ietf-inet-types are both YANG modules they do not define any data > nodes that can be implemented. Lets look at RFC 6020bis: >=20 > o data model: A data model describes how data is represented and > accessed. >=20 > Anyway, the point is that RFC 6991 do not define any data nodes and > hence nothing that can be accessed. Perhaps it helps to import > terminology into the model classification document and to be explicit > that not all YANG modules define YANG data models. This is a good definition to be added, as in the draft we are talking = about classifying data models and we have to go through the document and = make sure that we use data model instead of model consistently. Dean >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 7 04:56:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053712D1A1 for ; Thu, 7 Apr 2016 04:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyW-ZqnlVZtO for ; Thu, 7 Apr 2016 04:56:31 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A8012D7F1 for ; Thu, 7 Apr 2016 04:56:31 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id c126so55164394lfb.2 for ; Thu, 07 Apr 2016 04:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=WQhFR6/jvBaVKswfo43DlpKCelqotHkQ3+4pytSW0RQ=; b=ycSe46HSDfe/aPKmALHEp/GsPQL7WCNy1DMUZoZoiJtOOeE/8lzUKW6QtglUJRxJ5f lVYR13oB+89+2i4+OZyxiseHfJ4LjzQhi/FKdkeWE51vgv9rvBHPCdzI3abEuzACBNuL M9/HnxwG1V6lGQmSNP+Nq2CjYzZuBbxqFTeyJitzRhvkxFqs43HaOMcIaSeVeoGg63xJ CtgnKpt7+tefFvyWtqvA9ShqYnNZEy7Gc2PDucZNN5/jdfHXgzmQBMwWHY1ES9S3bYub 2TYyhM5ZCrWV/tOEaLODfmKDNPhG4+quHX5dU1GGqu5qPJbkvumiT0qCTZZ4Rjpns+cV T8DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=WQhFR6/jvBaVKswfo43DlpKCelqotHkQ3+4pytSW0RQ=; b=a9JE2i4QBz1AM3KDd6n3Sbc00gtAnXtClIqaREa0OFgBJwcNasHTZreVb+tNKUmuw0 gR4CT0nDZ3IrKwhjeTnnpDf1W05BCyaIccKCpLC09mwCjFjJPF5ap08e5JKHpSjuVgGB s7WQj6feV1imx2EKYce24UQhauUa3RFCU7G3GW0JUvyWCOXq351TTxwuJb0BtnPYdWXq l6awaL2wrm9JeWIR7Fkr1W/En0DVqYErsh2GrXBCs5DhjIOIyctisCj0EC6+XuWuh9j5 q5Jmcv9UDOslUxa6wWpdzX9EgE7V/n2xI3e+2V1d+CMbTfPPHjGo/vNmpSraLAyi+COK nQJQ== X-Gm-Message-State: AD7BkJJPMb8BnabSoGppOpDalhCGczVPXOXJlqJQK6t+G4r8FzDGjaM5eFMjCxTEz1gJ7qubVvad9iPxqQBm8g== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr1196579lfb.131.1460030189206; Thu, 07 Apr 2016 04:56:29 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 7 Apr 2016 04:56:29 -0700 (PDT) In-Reply-To: <20160407104529.GC64000@elstar.local> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160407104529.GC64000@elstar.local> Date: Thu, 7 Apr 2016 04:56:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Scharf, Michael (Nokia - DE)" , "EXT Carl Moberg (camoberg)" , "Doolan, Paul (Coriant - US/Irving)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11405936ca199a052fe3c45b Archived-At: Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 11:56:37 -0000 --001a11405936ca199a052fe3c45b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia - DE) > wrote: > > > I come at this from the classification angle, so my interest is if th= e > assumption that > > > a YANG model can only be classified as a network service model XOR a > network device model > > > according to the definitions in > draft-ietf-netmod-yang-model-classification (sections 2.1 > > > and 2.2). Based on this discussion I take it that some models are > intended to be able to > > > serve in both roles. And we should make sure that it=E2=80=99s suppor= ted in > our catalog structure. > > > > Regarding the XOR assumption for classification: > > > > You may also want to think about YANG models that are NEITHER device NO= R > service models. For instance, what about RFC 6991? And I think other, mor= e > technical models presented this week may fall into a similar category > ("generic"?). > > > > RFC 6991 is not really defining a data model, while ietf-yang-types > and ietf-inet-types are both YANG modules they do not define any data > nodes that can be implemented. Lets look at RFC 6020bis: > > o data model: A data model describes how data is represented and > accessed. > > Anyway, the point is that RFC 6991 do not define any data nodes and > hence nothing that can be accessed. Perhaps it helps to import > terminology into the model classification document and to be explicit > that not all YANG modules define YANG data models. > > I brought this issue up for YANG 1.1 but there was no interest or agreement that there is any problem or confusion. http://www.netconfcentral.org/modulereport/iana-crypt-hash Consider iana-crypt-hash that only contains 1 typedef and 3 features that relate to implementation of that typedef. According to YANG 1.1 and the YANG library, a server implement MUST NOT claim it implements iana-crypt-hash. Instead the server must say "I import this module, but implement the features". How can one implement something that is supposedly only imported? Very confusing. There is only ONE data model in a YANG implementation, which is composed of one or more modules. /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 > --001a11405936ca199a052fe3c45b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia - = DE) wrote:
> > I come at this from the classification angle, so my interest is i= f the assumption that
> > a YANG model can only be classified as a network service model XO= R a network device model
> > according to the definitions in draft-ietf-netmod-yang-model-clas= sification (sections 2.1
> > and 2.2). Based on this discussion I take it that some models are= intended to be able to
> > serve in both roles. And we should make sure that it=E2=80=99s su= pported in our catalog structure.
>
> Regarding the XOR assumption for classification:
>
> You may also want to think about YANG models that are NEITHER device N= OR service models. For instance, what about RFC 6991? And I think other, mo= re technical models presented this week may fall into a similar category (&= quot;generic"?).
>

RFC 6991 is not really defining a data model, while ietf-yang-types
and ietf-inet-types are both YANG modules they do not define any data
nodes that can be implemented. Lets look at RFC 6020bis:

=C2=A0 =C2=A0o=C2=A0 data model: A data model describes how data is represe= nted and
=C2=A0 =C2=A0 =C2=A0 accessed.

Anyway, the point is that RFC 6991 do not define any data nodes and
hence nothing that can be accessed. Perhaps it helps to import
terminology into the model classification document and to be explicit
that not all YANG modules define YANG data models.



I brought this issue up for YANG 1.1 but th= ere was no interest
or agreement that there is any problem or con= fusion.


Consider iana-crypt-hash that= only contains =C2=A01 typedef and 3 features
that relate to impl= ementation of that typedef.=C2=A0 According to YANG 1.1
and the Y= ANG library, a server implement MUST NOT claim it
implements iana= -crypt-hash.=C2=A0 Instead the server must say "I import
thi= s module, but implement the features".=C2=A0 How can one implement
something that is supposedly only imported?=C2=A0 Very confusing.

There is only ONE data model in a YANG implementatio= n,
which is composed of one or more modules.

=


/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

--001a11405936ca199a052fe3c45b-- From nobody Thu Apr 7 05:33:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5191512D89F for ; Thu, 7 Apr 2016 05:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM7FkcwgIdpg for ; Thu, 7 Apr 2016 05:33:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9649312D89D for ; Thu, 7 Apr 2016 05:33:17 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 728931AE028E; Thu, 7 Apr 2016 14:33:15 +0200 (CEST) Date: Thu, 07 Apr 2016 14:33:25 +0200 (CEST) Message-Id: <20160407.143325.949107323331061854.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160407104529.GC64000@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:33:19 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIEFwciA3 LCAyMDE2IGF0IDM6NDUgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8DQo+IGouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IA0KPiA+IE9uIFRodSwgQXByIDA3 LCAyMDE2IGF0IDA4OjU1OjE5QU0gKzAwMDAsIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkN Cj4gPiB3cm90ZToNCj4gPiA+ID4gSSBjb21lIGF0IHRoaXMgZnJvbSB0aGUgY2xhc3NpZmljYXRp b24gYW5nbGUsIHNvIG15IGludGVyZXN0IGlzIGlmIHRoZQ0KPiA+IGFzc3VtcHRpb24gdGhhdA0K PiA+ID4gPiBhIFlBTkcgbW9kZWwgY2FuIG9ubHkgYmUgY2xhc3NpZmllZCBhcyBhIG5ldHdvcmsg c2VydmljZSBtb2RlbCBYT1IgYQ0KPiA+IG5ldHdvcmsgZGV2aWNlIG1vZGVsDQo+ID4gPiA+IGFj Y29yZGluZyB0byB0aGUgZGVmaW5pdGlvbnMgaW4NCj4gPiBkcmFmdC1pZXRmLW5ldG1vZC15YW5n LW1vZGVsLWNsYXNzaWZpY2F0aW9uIChzZWN0aW9ucyAyLjENCj4gPiA+ID4gYW5kIDIuMikuIEJh c2VkIG9uIHRoaXMgZGlzY3Vzc2lvbiBJIHRha2UgaXQgdGhhdCBzb21lIG1vZGVscyBhcmUNCj4g PiBpbnRlbmRlZCB0byBiZSBhYmxlIHRvDQo+ID4gPiA+IHNlcnZlIGluIGJvdGggcm9sZXMuIEFu ZCB3ZSBzaG91bGQgbWFrZSBzdXJlIHRoYXQgaXTigJlzIHN1cHBvcnRlZCBpbg0KPiA+IG91ciBj YXRhbG9nIHN0cnVjdHVyZS4NCj4gPiA+DQo+ID4gPiBSZWdhcmRpbmcgdGhlIFhPUiBhc3N1bXB0 aW9uIGZvciBjbGFzc2lmaWNhdGlvbjoNCj4gPiA+DQo+ID4gPiBZb3UgbWF5IGFsc28gd2FudCB0 byB0aGluayBhYm91dCBZQU5HIG1vZGVscyB0aGF0IGFyZSBORUlUSEVSIGRldmljZSBOT1INCj4g PiBzZXJ2aWNlIG1vZGVscy4gRm9yIGluc3RhbmNlLCB3aGF0IGFib3V0IFJGQyA2OTkxPyBBbmQg SSB0aGluayBvdGhlciwgbW9yZQ0KPiA+IHRlY2huaWNhbCBtb2RlbHMgcHJlc2VudGVkIHRoaXMg d2VlayBtYXkgZmFsbCBpbnRvIGEgc2ltaWxhciBjYXRlZ29yeQ0KPiA+ICgiZ2VuZXJpYyI/KS4N Cj4gPiA+DQo+ID4NCj4gPiBSRkMgNjk5MSBpcyBub3QgcmVhbGx5IGRlZmluaW5nIGEgZGF0YSBt b2RlbCwgd2hpbGUgaWV0Zi15YW5nLXR5cGVzDQo+ID4gYW5kIGlldGYtaW5ldC10eXBlcyBhcmUg Ym90aCBZQU5HIG1vZHVsZXMgdGhleSBkbyBub3QgZGVmaW5lIGFueSBkYXRhDQo+ID4gbm9kZXMg dGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQuIExldHMgbG9vayBhdCBSRkMgNjAyMGJpczoNCj4gPg0K PiA+ICAgIG8gIGRhdGEgbW9kZWw6IEEgZGF0YSBtb2RlbCBkZXNjcmliZXMgaG93IGRhdGEgaXMg cmVwcmVzZW50ZWQgYW5kDQo+ID4gICAgICAgYWNjZXNzZWQuDQo+ID4NCj4gPiBBbnl3YXksIHRo ZSBwb2ludCBpcyB0aGF0IFJGQyA2OTkxIGRvIG5vdCBkZWZpbmUgYW55IGRhdGEgbm9kZXMgYW5k DQo+ID4gaGVuY2Ugbm90aGluZyB0aGF0IGNhbiBiZSBhY2Nlc3NlZC4gUGVyaGFwcyBpdCBoZWxw cyB0byBpbXBvcnQNCj4gPiB0ZXJtaW5vbG9neSBpbnRvIHRoZSBtb2RlbCBjbGFzc2lmaWNhdGlv biBkb2N1bWVudCBhbmQgdG8gYmUgZXhwbGljaXQNCj4gPiB0aGF0IG5vdCBhbGwgWUFORyBtb2R1 bGVzIGRlZmluZSBZQU5HIGRhdGEgbW9kZWxzLg0KPiA+DQo+ID4NCj4gDQo+IEkgYnJvdWdodCB0 aGlzIGlzc3VlIHVwIGZvciBZQU5HIDEuMSBidXQgdGhlcmUgd2FzIG5vIGludGVyZXN0DQo+IG9y IGFncmVlbWVudCB0aGF0IHRoZXJlIGlzIGFueSBwcm9ibGVtIG9yIGNvbmZ1c2lvbi4NCj4gDQo+ IGh0dHA6Ly93d3cubmV0Y29uZmNlbnRyYWwub3JnL21vZHVsZXJlcG9ydC9pYW5hLWNyeXB0LWhh c2gNCj4gDQo+IENvbnNpZGVyIGlhbmEtY3J5cHQtaGFzaCB0aGF0IG9ubHkgY29udGFpbnMgIDEg dHlwZWRlZiBhbmQgMyBmZWF0dXJlcw0KPiB0aGF0IHJlbGF0ZSB0byBpbXBsZW1lbnRhdGlvbiBv ZiB0aGF0IHR5cGVkZWYuICBBY2NvcmRpbmcgdG8gWUFORyAxLjENCj4gYW5kIHRoZSBZQU5HIGxp YnJhcnksIGEgc2VydmVyIGltcGxlbWVudCBNVVNUIE5PVCBjbGFpbSBpdA0KPiBpbXBsZW1lbnRz IGlhbmEtY3J5cHQtaGFzaC4gIEluc3RlYWQgdGhlIHNlcnZlciBtdXN0IHNheSAiSSBpbXBvcnQN Cj4gdGhpcyBtb2R1bGUsIGJ1dCBpbXBsZW1lbnQgdGhlIGZlYXR1cmVzIi4gIEhvdyBjYW4gb25l IGltcGxlbWVudA0KPiBzb21ldGhpbmcgdGhhdCBpcyBzdXBwb3NlZGx5IG9ubHkgaW1wb3J0ZWQ/ ICBWZXJ5IGNvbmZ1c2luZy4NCg0KaWV0Zi15YW5nLWxpYnJhcnkgYW5kIDYwMjBiaXMoKikgdXNl cyB0aGUgcGhyYXNlICJzdXBwb3J0ZWQNCmZlYXR1cmVzIi4gIFNvLCBhIHNlcnZlciBjYW4gYWR2 ZXJ0aXNlIGEgbW9kdWxlIGFzIGltcG9ydGVkLCBhbmQgbGlzdA0KdGhlIHN1cHBvcnRlZCBmZWF0 dXJlcy4NCg0KKCopIDYwMjBiaXMgYWN0dWFsbHkgdXNlcyB0aGUgcGhyYXNlICJpbXBsZW1lbnQg YSBmZWF0dXJlIiBpbiBvbmUNCnNlbnRlbmNlIChsYXN0IHNlbnRlbmNlIGluIDcuMjAuMSkuICBU aGlzIHNob3VsZCBwcm9iYWJseSBiZSBjaGFuZ2VkDQp0byAic3VwcG9ydCBhIGZlYXR1cmUiIGlu IG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KDQovbWFydGluDQo= From nobody Thu Apr 7 05:39:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1DB12D8B9 for ; Thu, 7 Apr 2016 05:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy7NnMmYE8QE for ; Thu, 7 Apr 2016 05:39:51 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DBB12D8BA for ; Thu, 7 Apr 2016 05:39:49 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id vo2so49003282lbb.1 for ; Thu, 07 Apr 2016 05:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PHieHamcRaobOOaa+bWJGKHXAN5P71gU9HAQAtKsXLM=; b=GX/T11j1qPmuSzuMpy5gH1Ll/Jhw+Kn4zY72p5UvizRmnd8MjnMhOE51VIYE4jEwCZ PjK+xjV6obHsOwnWs+w4Kuqe0u0ml53NvSyADKFuyLp5MW4HAMe83VabmTMLmwbsc/MR 2NZ1TRH5rQSEppN8iSFXVXRL5i/I10ub7LGp4i8t08l9Zo/QCn7PXLlTU9pBWCNDCWLO EmVTxVRYLvxErS5IXZ4PBe1tXBO/mKncarwn10zWie16G2rspRNQ/9YWsrT+7PAznQvP jRpfJPd3Z0nAsYYo/1cAV0v0R11/MgiN4ynnxOKNF53rDR6Z97ETVp0cVAIzh8kHVxzU 1X4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PHieHamcRaobOOaa+bWJGKHXAN5P71gU9HAQAtKsXLM=; b=cQqthiZ5iUF50uZYQYx2uJOfmFuJHODiNtJWtZo1KIC0qO5TdlBTVH/8iteSMKoFg1 k3QXx/qT44RdTvpejiKwGXjvxaoaRxRxcRd63d9eFX3htgxK7uus0k/Ya0XlWUhg00pl FMrkgJ2nOwsEbIeJ4eCVNHSkC7KaEyqLjdAE2N3bTSSJeGA+ktYFrPCwTao/HNmDG0P2 lcgqBESv5mZ5Vzd0cjetZbnGUP2vnmDvhzAkUlq1xtNzKos1im8FwNFmGCcLUgMpRVct V1+vuEv08Q8S8WBgeDLyW+h7B2d3tyM8gjnwBHXzfoLwyO9Up/TpQZA82/IaNo8EuFor p0RQ== X-Gm-Message-State: AD7BkJKHvmSuTMC1uzQglLOUG2VARpTXLkWtgrPnWqJwKmhD48L8gmCUY7hNkaMa+JSRbB7hg9nd7cgAli4Q4Q== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr1078566lbb.119.1460032787524; Thu, 07 Apr 2016 05:39:47 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 7 Apr 2016 05:39:47 -0700 (PDT) In-Reply-To: <20160407.143325.949107323331061854.mbj@tail-f.com> References: <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20160407104529.GC64000@elstar.local> <20160407.143325.949107323331061854.mbj@tail-f.com> Date: Thu, 7 Apr 2016 05:39:47 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b3a8bd2a9432f052fe45f3b Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:39:55 -0000 --047d7b3a8bd2a9432f052fe45f3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia - DE= ) > > > wrote: > > > > > I come at this from the classification angle, so my interest is i= f > the > > > assumption that > > > > > a YANG model can only be classified as a network service model XO= R > a > > > network device model > > > > > according to the definitions in > > > draft-ietf-netmod-yang-model-classification (sections 2.1 > > > > > and 2.2). Based on this discussion I take it that some models are > > > intended to be able to > > > > > serve in both roles. And we should make sure that it=E2=80=99s su= pported in > > > our catalog structure. > > > > > > > > Regarding the XOR assumption for classification: > > > > > > > > You may also want to think about YANG models that are NEITHER devic= e > NOR > > > service models. For instance, what about RFC 6991? And I think other, > more > > > technical models presented this week may fall into a similar category > > > ("generic"?). > > > > > > > > > > RFC 6991 is not really defining a data model, while ietf-yang-types > > > and ietf-inet-types are both YANG modules they do not define any data > > > nodes that can be implemented. Lets look at RFC 6020bis: > > > > > > o data model: A data model describes how data is represented and > > > accessed. > > > > > > Anyway, the point is that RFC 6991 do not define any data nodes and > > > hence nothing that can be accessed. Perhaps it helps to import > > > terminology into the model classification document and to be explicit > > > that not all YANG modules define YANG data models. > > > > > > > > > > I brought this issue up for YANG 1.1 but there was no interest > > or agreement that there is any problem or confusion. > > > > http://www.netconfcentral.org/modulereport/iana-crypt-hash > > > > Consider iana-crypt-hash that only contains 1 typedef and 3 features > > that relate to implementation of that typedef. According to YANG 1.1 > > and the YANG library, a server implement MUST NOT claim it > > implements iana-crypt-hash. Instead the server must say "I import > > this module, but implement the features". How can one implement > > something that is supposedly only imported? Very confusing. > > ietf-yang-library and 6020bis(*) uses the phrase "supported > features". So, a server can advertise a module as imported, and list > the supported features. > > (*) 6020bis actually uses the phrase "implement a feature" in one > sentence (last sentence in 7.20.1). This should probably be changed > to "support a feature" in order to avoid confusion. > > > How does one support a feature without implementing it? This terminology is inconsistent and confusing. > /martin > Andy --047d7b3a8bd2a9432f052fe45f3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia = - DE)
> > wrote:
> > > > I come at this from the classification angle, so my int= erest is if the
> > assumption that
> > > > a YANG model can only be classified as a network servic= e model XOR a
> > network device model
> > > > according to the definitions in
> > draft-ietf-netmod-yang-model-classification (sections 2.1
> > > > and 2.2). Based on this discussion I take it that some = models are
> > intended to be able to
> > > > serve in both roles. And we should make sure that it=E2= =80=99s supported in
> > our catalog structure.
> > >
> > > Regarding the XOR assumption for classification:
> > >
> > > You may also want to think about YANG models that are NEITHE= R device NOR
> > service models. For instance, what about RFC 6991? And I think ot= her, more
> > technical models presented this week may fall into a similar cate= gory
> > ("generic"?).
> > >
> >
> > RFC 6991 is not really defining a data model, while ietf-yang-typ= es
> > and ietf-inet-types are both YANG modules they do not define any = data
> > nodes that can be implemented. Lets look at RFC 6020bis:
> >
> >=C2=A0 =C2=A0 o=C2=A0 data model: A data model describes how data = is represented and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0accessed.
> >
> > Anyway, the point is that RFC 6991 do not define any data nodes a= nd
> > hence nothing that can be accessed. Perhaps it helps to import > > terminology into the model classification document and to be expl= icit
> > that not all YANG modules define YANG data models.
> >
> >
>
> I brought this issue up for YANG 1.1 but there was no interest
> or agreement that there is any problem or confusion.
>
> http://www.netconfcentral.org/moduler= eport/iana-crypt-hash
>
> Consider iana-crypt-hash that only contains=C2=A0 1 typedef and 3 feat= ures
> that relate to implementation of that typedef.=C2=A0 According to YANG= 1.1
> and the YANG library, a server implement MUST NOT claim it
> implements iana-crypt-hash.=C2=A0 Instead the server must say "I = import
> this module, but implement the features".=C2=A0 How can one imple= ment
> something that is supposedly only imported?=C2=A0 Very confusing.

ietf-yang-library and 6020bis(*) uses the phrase "supported
features".=C2=A0 So, a server can advertise a module as imported, and = list
the supported features.

(*) 6020bis actually uses the phrase "implement a feature" in one=
sentence (last sentence in 7.20.1).=C2=A0 This should probably be changed to "support a feature" in order to avoid confusion.



How does one support a f= eature without implementing it?
This terminology is inconsistent = and confusing.

=C2=A0
/martin

Andy<= /div>

--047d7b3a8bd2a9432f052fe45f3b-- From nobody Thu Apr 7 05:55:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629A512D911 for ; Thu, 7 Apr 2016 05:55:24 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkniGtHCgyVH for ; Thu, 7 Apr 2016 05:55: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 048CD12D902 for ; Thu, 7 Apr 2016 05:55:19 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id E92571AE028E; Thu, 7 Apr 2016 14:55:17 +0200 (CEST) Date: Thu, 07 Apr 2016 14:55:27 +0200 (CEST) Message-Id: <20160407.145527.383210146970907510.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20160407.143325.949107323331061854.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] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:55:24 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIEFwciA3 LCAyMDE2IGF0IDU6MzMgQU0sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90 ZToNCj4gDQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+ ID4gT24gVGh1LCBBcHIgNywgMjAxNiBhdCAzOjQ1IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg PA0KPiA+ID4gai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4g PiA+DQo+ID4gPiA+IE9uIFRodSwgQXByIDA3LCAyMDE2IGF0IDA4OjU1OjE5QU0gKzAwMDAsIFNj aGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCj4gPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPiBJ IGNvbWUgYXQgdGhpcyBmcm9tIHRoZSBjbGFzc2lmaWNhdGlvbiBhbmdsZSwgc28gbXkgaW50ZXJl c3QgaXMgaWYNCj4gPiB0aGUNCj4gPiA+ID4gYXNzdW1wdGlvbiB0aGF0DQo+ID4gPiA+ID4gPiBh IFlBTkcgbW9kZWwgY2FuIG9ubHkgYmUgY2xhc3NpZmllZCBhcyBhIG5ldHdvcmsgc2VydmljZSBt b2RlbCBYT1INCj4gPiBhDQo+ID4gPiA+IG5ldHdvcmsgZGV2aWNlIG1vZGVsDQo+ID4gPiA+ID4g PiBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb25zIGluDQo+ID4gPiA+IGRyYWZ0LWlldGYtbmV0 bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24gKHNlY3Rpb25zIDIuMQ0KPiA+ID4gPiA+ID4g YW5kIDIuMikuIEJhc2VkIG9uIHRoaXMgZGlzY3Vzc2lvbiBJIHRha2UgaXQgdGhhdCBzb21lIG1v ZGVscyBhcmUNCj4gPiA+ID4gaW50ZW5kZWQgdG8gYmUgYWJsZSB0bw0KPiA+ID4gPiA+ID4gc2Vy dmUgaW4gYm90aCByb2xlcy4gQW5kIHdlIHNob3VsZCBtYWtlIHN1cmUgdGhhdCBpdOKAmXMgc3Vw cG9ydGVkIGluDQo+ID4gPiA+IG91ciBjYXRhbG9nIHN0cnVjdHVyZS4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IFJlZ2FyZGluZyB0aGUgWE9SIGFzc3VtcHRpb24gZm9yIGNsYXNzaWZpY2F0aW9uOg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gWW91IG1heSBhbHNvIHdhbnQgdG8gdGhpbmsgYWJvdXQgWUFO RyBtb2RlbHMgdGhhdCBhcmUgTkVJVEhFUiBkZXZpY2UNCj4gPiBOT1INCj4gPiA+ID4gc2Vydmlj ZSBtb2RlbHMuIEZvciBpbnN0YW5jZSwgd2hhdCBhYm91dCBSRkMgNjk5MT8gQW5kIEkgdGhpbmsg b3RoZXIsDQo+ID4gbW9yZQ0KPiA+ID4gPiB0ZWNobmljYWwgbW9kZWxzIHByZXNlbnRlZCB0aGlz IHdlZWsgbWF5IGZhbGwgaW50byBhIHNpbWlsYXIgY2F0ZWdvcnkNCj4gPiA+ID4gKCJnZW5lcmlj Ij8pLg0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFJGQyA2OTkxIGlzIG5vdCByZWFsbHkg ZGVmaW5pbmcgYSBkYXRhIG1vZGVsLCB3aGlsZSBpZXRmLXlhbmctdHlwZXMNCj4gPiA+ID4gYW5k IGlldGYtaW5ldC10eXBlcyBhcmUgYm90aCBZQU5HIG1vZHVsZXMgdGhleSBkbyBub3QgZGVmaW5l IGFueSBkYXRhDQo+ID4gPiA+IG5vZGVzIHRoYXQgY2FuIGJlIGltcGxlbWVudGVkLiBMZXRzIGxv b2sgYXQgUkZDIDYwMjBiaXM6DQo+ID4gPiA+DQo+ID4gPiA+ICAgIG8gIGRhdGEgbW9kZWw6IEEg ZGF0YSBtb2RlbCBkZXNjcmliZXMgaG93IGRhdGEgaXMgcmVwcmVzZW50ZWQgYW5kDQo+ID4gPiA+ ICAgICAgIGFjY2Vzc2VkLg0KPiA+ID4gPg0KPiA+ID4gPiBBbnl3YXksIHRoZSBwb2ludCBpcyB0 aGF0IFJGQyA2OTkxIGRvIG5vdCBkZWZpbmUgYW55IGRhdGEgbm9kZXMgYW5kDQo+ID4gPiA+IGhl bmNlIG5vdGhpbmcgdGhhdCBjYW4gYmUgYWNjZXNzZWQuIFBlcmhhcHMgaXQgaGVscHMgdG8gaW1w b3J0DQo+ID4gPiA+IHRlcm1pbm9sb2d5IGludG8gdGhlIG1vZGVsIGNsYXNzaWZpY2F0aW9uIGRv Y3VtZW50IGFuZCB0byBiZSBleHBsaWNpdA0KPiA+ID4gPiB0aGF0IG5vdCBhbGwgWUFORyBtb2R1 bGVzIGRlZmluZSBZQU5HIGRhdGEgbW9kZWxzLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4NCj4g PiA+IEkgYnJvdWdodCB0aGlzIGlzc3VlIHVwIGZvciBZQU5HIDEuMSBidXQgdGhlcmUgd2FzIG5v IGludGVyZXN0DQo+ID4gPiBvciBhZ3JlZW1lbnQgdGhhdCB0aGVyZSBpcyBhbnkgcHJvYmxlbSBv ciBjb25mdXNpb24uDQo+ID4gPg0KPiA+ID4gaHR0cDovL3d3dy5uZXRjb25mY2VudHJhbC5vcmcv bW9kdWxlcmVwb3J0L2lhbmEtY3J5cHQtaGFzaA0KPiA+ID4NCj4gPiA+IENvbnNpZGVyIGlhbmEt Y3J5cHQtaGFzaCB0aGF0IG9ubHkgY29udGFpbnMgIDEgdHlwZWRlZiBhbmQgMyBmZWF0dXJlcw0K PiA+ID4gdGhhdCByZWxhdGUgdG8gaW1wbGVtZW50YXRpb24gb2YgdGhhdCB0eXBlZGVmLiAgQWNj b3JkaW5nIHRvIFlBTkcgMS4xDQo+ID4gPiBhbmQgdGhlIFlBTkcgbGlicmFyeSwgYSBzZXJ2ZXIg aW1wbGVtZW50IE1VU1QgTk9UIGNsYWltIGl0DQo+ID4gPiBpbXBsZW1lbnRzIGlhbmEtY3J5cHQt aGFzaC4gIEluc3RlYWQgdGhlIHNlcnZlciBtdXN0IHNheSAiSSBpbXBvcnQNCj4gPiA+IHRoaXMg bW9kdWxlLCBidXQgaW1wbGVtZW50IHRoZSBmZWF0dXJlcyIuICBIb3cgY2FuIG9uZSBpbXBsZW1l bnQNCj4gPiA+IHNvbWV0aGluZyB0aGF0IGlzIHN1cHBvc2VkbHkgb25seSBpbXBvcnRlZD8gIFZl cnkgY29uZnVzaW5nLg0KPiA+DQo+ID4gaWV0Zi15YW5nLWxpYnJhcnkgYW5kIDYwMjBiaXMoKikg dXNlcyB0aGUgcGhyYXNlICJzdXBwb3J0ZWQNCj4gPiBmZWF0dXJlcyIuICBTbywgYSBzZXJ2ZXIg Y2FuIGFkdmVydGlzZSBhIG1vZHVsZSBhcyBpbXBvcnRlZCwgYW5kIGxpc3QNCj4gPiB0aGUgc3Vw cG9ydGVkIGZlYXR1cmVzLg0KPiA+DQo+ID4gKCopIDYwMjBiaXMgYWN0dWFsbHkgdXNlcyB0aGUg cGhyYXNlICJpbXBsZW1lbnQgYSBmZWF0dXJlIiBpbiBvbmUNCj4gPiBzZW50ZW5jZSAobGFzdCBz ZW50ZW5jZSBpbiA3LjIwLjEpLiAgVGhpcyBzaG91bGQgcHJvYmFibHkgYmUgY2hhbmdlZA0KPiA+ IHRvICJzdXBwb3J0IGEgZmVhdHVyZSIgaW4gb3JkZXIgdG8gYXZvaWQgY29uZnVzaW9uLg0KPiA+ DQo+ID4NCj4gPg0KPiBIb3cgZG9lcyBvbmUgc3VwcG9ydCBhIGZlYXR1cmUgd2l0aG91dCBpbXBs ZW1lbnRpbmcgaXQ/DQo+IFRoaXMgdGVybWlub2xvZ3kgaXMgaW5jb25zaXN0ZW50IGFuZCBjb25m dXNpbmcuDQoNClRoZSBmZWF0dXJlIGl0c2VsZiBpc24ndCB2ZXJ5IGludGVyZXN0aW5nLiAgSWYg YSBzZXJ2ZXIgc3VwcG9ydHMNCmZlYXR1cmUgQSwgaXQgaW1wbGVtZW50cyBub2RlcyB0aGF0IGhh dmUgaWYtZmVhdHVyZSAiQSIgc3RhdGVtZW50cy4NCg0KDQovbWFydGluDQo= From nobody Thu Apr 7 06:30:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782C912D1CB for ; Wed, 6 Apr 2016 15:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_SPAM=0.585, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.from=noreply@github.com header.sender=noreply@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJlC4uN7aAdW for ; Wed, 6 Apr 2016 15:47:12 -0700 (PDT) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (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 25FFD12D0A3 for ; Wed, 6 Apr 2016 15:47:12 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1459982831; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=bx4o9M98xefpDlKFCcxKLatgdLXlOBJkhB78IXVPyKc=; b=EFxuhNqCd36j6IL/3wvFulZ/skSmoNAqGQOTyeQq8LXzolVKCb1euN9AYV9Rk77Hro3co3CD IB1loSh3PRT2ND1DQ17jwjBhrmAV9nTJWyoJKVvyq9ua84IZ8n08e9pm1baQbHBYPZZn5pKv lUcqZoMngrhDuVPoUxLxfbFbuX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=XXq0fF2TQZ1ZVRQzROap6/v6oAdGoqbD1bCrTqT67PCFMjr178kRrl79f6BaYV9T4pDuTn vPbfy2Xa1E67B4qYyZjL6EXrKLi9Voj6UN6qFCqxuspMCkFUIDA0DOvu414rfnnK7kjmRVB8 TI1rMv4uXA1iX2jhDEewN4hDLmiv4= Sender: noreply@github.com X-Mailgun-Sid: WyIxZDdlMiIsICJuZXRtb2RAaWV0Zi5vcmciLCAiNDBmIl0= Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 57058f7f.7fb014ae1480-in6; Wed, 06 Apr 2016 22:36:47 -0000 (UTC) Date: Wed, 06 Apr 2016 15:36:46 -0700 From: GitHub To: netmod@ietf.org Message-ID: <57058f7ea6d6a_1faa3fd8e3f8d29c1771db@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57058f7ea67ae_1faa3fd8e3f8d29c1770f8"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 07 Apr 2016 06:30:15 -0700 Subject: [netmod] [netmod-wg/yang-next] 41b635: Update README.md X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: GitHub List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:47:13 -0000 ----==_mimepart_57058f7ea67ae_1faa3fd8e3f8d29c1770f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/netmod-wg/yang-next Commit: 41b635fbab56827d81d6efd79a35e15bfdc2d6fa https://github.com/netmod-wg/yang-next/commit/41b635fbab56827d81d6efd79a35e15bfdc2d6fa Author: Kent Watsen Date: 2016-03-10 (Thu, 10 Mar 2016) Changed paths: M README.md Log Message: ----------- Update README.md ----==_mimepart_57058f7ea67ae_1faa3fd8e3f8d29c1770f8-- From nobody Thu Apr 7 06:30:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17DA12D7C1 for ; Thu, 7 Apr 2016 04:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_SPAM=0.585, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.from=noreply@github.com header.sender=noreply@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF8p6XzwAQzx for ; Thu, 7 Apr 2016 04:19:31 -0700 (PDT) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (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 9557512D685 for ; Thu, 7 Apr 2016 04:19:31 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1460027970; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=TLZGqzaayTuYU5JP5fvV2eRnIfChzWNXHgsx8UmtHsE=; b=lVb1vJEpMaBvc9eFDTVenrlqw5cRscP72NwFvGrYo8wNrMZydTsuoERUBrJJO6BNlFTd3QTP aQiN9aBgpZ/wMBKikLSMJ5zXt4G31nJOmV4ubgw6tc3gd3CCPiBtvnucrLmsoDaVqLCI6shd vP65D+pp1OQPZa3k/VLMSW0EZNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=Y1PM6t/0COq5xznq/WQxjw01YafpBqpemWJmkEkJOK4DEA6aqcgZEQglxTly0WHipCivzH MiWd0i5V2l7AHN9de0jAT5QfE1LzZUkrNPTZZd84VqWqTgagcKmP1oneNAb02sdMDSZkoMxa iI/OwCz6y++Fi0jNh41ma4K32uri8= Sender: noreply@github.com X-Mailgun-Sid: WyIxZDdlMiIsICJuZXRtb2RAaWV0Zi5vcmciLCAiNDBmIl0= Received: from github.com (Unknown [192.30.252.46]) by mxa.mailgun.org with ESMTP id 5706423f.7f0c1c27a0f0-in1; Thu, 07 Apr 2016 11:19:27 -0000 (UTC) Date: Thu, 07 Apr 2016 04:19:27 -0700 From: GitHub To: netmod@ietf.org Message-ID: <5706423f5b7b7_799b3f8453cbd2b8134652@hookshot-fe4-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5706423f5b3c8_799b3f8453cbd2b8134560"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 07 Apr 2016 06:30:15 -0700 Subject: [netmod] [netmod-wg/yang-next] 41b635: Update README.md X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: GitHub List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 11:19:33 -0000 ----==_mimepart_5706423f5b3c8_799b3f8453cbd2b8134560 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/netmod-wg/yang-next Commit: 41b635fbab56827d81d6efd79a35e15bfdc2d6fa https://github.com/netmod-wg/yang-next/commit/41b635fbab56827d81d6efd79a35e15bfdc2d6fa Author: Kent Watsen Date: 2016-03-10 (Thu, 10 Mar 2016) Changed paths: M README.md Log Message: ----------- Update README.md ----==_mimepart_5706423f5b3c8_799b3f8453cbd2b8134560-- From nobody Thu Apr 7 06:30:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9A912D6F2 for ; Thu, 7 Apr 2016 04:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_SPAM=0.585, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.from=noreply@github.com header.sender=noreply@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfxuUEXatEEX for ; Thu, 7 Apr 2016 04:38:07 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.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 E3E5312D692 for ; Thu, 7 Apr 2016 04:38:06 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1460029086; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=f6ZgmzKfZVAdm1SGsHNkVFQ+jvt+qwHl01QreLneGoI=; b=vyzhsYXEQMjsSUef4+7d49A7gqwXOwinoVgVWYcvJcm8hIhBQhTWzn/ESIrtKrLlxZ2wBIRd vSoUB+BsYr6KGBAGHRIFpS5/DR3L1Ssccd4i31YMsfwcTkGF+vrS+anZKLqZJOlVBbKpSHOp axqoo4nN4DDOVuR62ggccjzh05c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=USzv89ixUsRgOyRSZqCdoaZTGtQed4ddWax8W2UoGoV72DrCmHdzPtMNbvfLM+MeOkudOn EWwgVsZ5KQa3SLhfnIxxOPpFtARj8hWegCbjr3+xQvInOle5tIqcHsBZ6Eyu/6QFxQ5HQ4qT gyCUpeiNrF3uFbKXlgxV6RVeysrD4= Sender: noreply@github.com X-Mailgun-Sid: WyIxZDdlMiIsICJuZXRtb2RAaWV0Zi5vcmciLCAiNDBmIl0= Received: from github.com (Unknown [192.30.252.42]) by mxa.mailgun.org with ESMTP id 5706469b.694dbd0-in6; Thu, 07 Apr 2016 11:38:03 -0000 (UTC) Date: Thu, 07 Apr 2016 04:38:03 -0700 From: GitHub To: netmod@ietf.org Message-ID: <5706469b64513_1c7c3fb051b612a080422@hookshot-fe1-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5706469b6417c_1c7c3fb051b612a0803d6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 07 Apr 2016 06:30:15 -0700 Subject: [netmod] [netmod-wg/yang-next] 41b635: Update README.md X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: GitHub List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 11:38:08 -0000 ----==_mimepart_5706469b6417c_1c7c3fb051b612a0803d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/netmod-wg/yang-next Commit: 41b635fbab56827d81d6efd79a35e15bfdc2d6fa https://github.com/netmod-wg/yang-next/commit/41b635fbab56827d81d6efd79a35e15bfdc2d6fa Author: Kent Watsen Date: 2016-03-10 (Thu, 10 Mar 2016) Changed paths: M README.md Log Message: ----------- Update README.md ----==_mimepart_5706469b6417c_1c7c3fb051b612a0803d6-- From nobody Thu Apr 7 07:06:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3110E12D116 for ; Thu, 7 Apr 2016 07:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IeLtq7Qxq0Z for ; Thu, 7 Apr 2016 07:06:19 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE7A12D50F for ; Thu, 7 Apr 2016 07:06:17 -0700 (PDT) Received: by mail-lb0-x231.google.com with SMTP id vo2so50658792lbb.1 for ; Thu, 07 Apr 2016 07:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zyoFx8tFz/ViMELJsw+jde57rQQruIjI70GUVYwoULs=; b=aVhwdy+/Vu5r21ZDrt4z+yXhBoLDkxn6eXv90D4XDoboQ++k4YZxrtSi1I/yr3zxdT AFNJVD4LxUSV0gWLShouSrFpb6jbdo7HtyBFasWQjrLpObYXmEqGqee1dld+M8HR49gy uhsXctI8V4za/caruIgqK+YokcxaWmWL3h7NO3TkxQoHuph/Pj20kYv7rdtXW4kFa3yM UvA54HLoSHmGCefTMIubUcJH/8Ii7Ei+cW5+gGS5F50J9IE4gac1NiurMoOSwTfb5+OM Jb/xDxawN5M4R0xia2sPjksLFqQOtMqDf3HQ7Tq8sNyTjVidr85yS3MivY6PxKYyN6FY 1XXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=zyoFx8tFz/ViMELJsw+jde57rQQruIjI70GUVYwoULs=; b=HereyvH6rlmykAvdeoCsNXGd0zY6doJWBVZBssFbQuZWGb0RNVh0dr8j1zQYjRlhug xlKtZRnTzri7QSfvCORokx70sxNrZjPtFkhhK4dn6TShFrsvUw88hoMIcwmCMrt7gFTY zxtUHJmIRu9rZGZovOePUOlo1wNv5BruF4Lvfx7LmQc/8YMm8606ROF8tzr63VucNe0q JEQZy9ogvxQWfjYPz0AInyBZRTNbE2ioZTrFwJ5bLxfCJpsAO6LcmiDW2wwYZzGmGPl4 nRCMBWNFfibUZ4AQ6SVxlzmoqF5YCCzseWuOYJOGIja0uK6KXz0bkjnJoTWfoXSiZgV/ 8/iQ== X-Gm-Message-State: AD7BkJJRFQVuiwutOEsoItYhRcEcmTPWllAowW6wUUScB1OtRvaxP5FYbBepA3nlbD5l7iZz43Xg4b7ijFi9Yw== MIME-Version: 1.0 X-Received: by 10.112.56.43 with SMTP id x11mr1469170lbp.145.1460037975565; Thu, 07 Apr 2016 07:06:15 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 7 Apr 2016 07:06:15 -0700 (PDT) In-Reply-To: <20160407.145527.383210146970907510.mbj@tail-f.com> References: <20160407.143325.949107323331061854.mbj@tail-f.com> <20160407.145527.383210146970907510.mbj@tail-f.com> Date: Thu, 7 Apr 2016 07:06:15 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1133a9eae47bcb052fe594e8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:06:23 -0000 --001a1133a9eae47bcb052fe594e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund wrote= : > > > > > Andy Bierman wrote: > > > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael (Nokia = - > DE) > > > > > wrote: > > > > > > > I come at this from the classification angle, so my interest > is if > > > the > > > > > assumption that > > > > > > > a YANG model can only be classified as a network service mode= l > XOR > > > a > > > > > network device model > > > > > > > according to the definitions in > > > > > draft-ietf-netmod-yang-model-classification (sections 2.1 > > > > > > > and 2.2). Based on this discussion I take it that some models > are > > > > > intended to be able to > > > > > > > serve in both roles. And we should make sure that it=E2=80=99= s > supported in > > > > > our catalog structure. > > > > > > > > > > > > Regarding the XOR assumption for classification: > > > > > > > > > > > > You may also want to think about YANG models that are NEITHER > device > > > NOR > > > > > service models. For instance, what about RFC 6991? And I think > other, > > > more > > > > > technical models presented this week may fall into a similar > category > > > > > ("generic"?). > > > > > > > > > > > > > > > > RFC 6991 is not really defining a data model, while ietf-yang-typ= es > > > > > and ietf-inet-types are both YANG modules they do not define any > data > > > > > nodes that can be implemented. Lets look at RFC 6020bis: > > > > > > > > > > o data model: A data model describes how data is represented > and > > > > > accessed. > > > > > > > > > > Anyway, the point is that RFC 6991 do not define any data nodes a= nd > > > > > hence nothing that can be accessed. Perhaps it helps to import > > > > > terminology into the model classification document and to be > explicit > > > > > that not all YANG modules define YANG data models. > > > > > > > > > > > > > > > > > > I brought this issue up for YANG 1.1 but there was no interest > > > > or agreement that there is any problem or confusion. > > > > > > > > http://www.netconfcentral.org/modulereport/iana-crypt-hash > > > > > > > > Consider iana-crypt-hash that only contains 1 typedef and 3 featur= es > > > > that relate to implementation of that typedef. According to YANG 1= .1 > > > > and the YANG library, a server implement MUST NOT claim it > > > > implements iana-crypt-hash. Instead the server must say "I import > > > > this module, but implement the features". How can one implement > > > > something that is supposedly only imported? Very confusing. > > > > > > ietf-yang-library and 6020bis(*) uses the phrase "supported > > > features". So, a server can advertise a module as imported, and list > > > the supported features. > > > > > > (*) 6020bis actually uses the phrase "implement a feature" in one > > > sentence (last sentence in 7.20.1). This should probably be changed > > > to "support a feature" in order to avoid confusion. > > > > > > > > > > > How does one support a feature without implementing it? > > This terminology is inconsistent and confusing. > > The feature itself isn't very interesting. If a server supports > feature A, it implements nodes that have if-feature "A" statements. > > > Except this is not at all how features are used in iana-crypt-hash.yang. The features are clearly related to implementation of any leaf or leaf-list that uses this typedef. Perhaps this is an exception and we should have never defined those features in the first place. > /martin > Andy --001a1133a9eae47bcb052fe594e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder < > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Micha= el (Nokia - DE)
> > > > wrote:
> > > > > > I come at this from the classification angle,= so my interest is if
> > the
> > > > assumption that
> > > > > > a YANG model can only be classified as a netw= ork service model XOR
> > a
> > > > network device model
> > > > > > according to the definitions in
> > > > draft-ietf-netmod-yang-model-classification (sections 2= .1
> > > > > > and 2.2). Based on this discussion I take it = that some models are
> > > > intended to be able to
> > > > > > serve in both roles. And we should make sure = that it=E2=80=99s supported in
> > > > our catalog structure.
> > > > >
> > > > > Regarding the XOR assumption for classification: > > > > >
> > > > > You may also want to think about YANG models that = are NEITHER device
> > NOR
> > > > service models. For instance, what about RFC 6991? And = I think other,
> > more
> > > > technical models presented this week may fall into a si= milar category
> > > > ("generic"?).
> > > > >
> > > >
> > > > RFC 6991 is not really defining a data model, while iet= f-yang-types
> > > > and ietf-inet-types are both YANG modules they do not d= efine any data
> > > > nodes that can be implemented. Lets look at RFC 6020bis= :
> > > >
> > > >=C2=A0 =C2=A0 o=C2=A0 data model: A data model describes= how data is represented and
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0accessed.
> > > >
> > > > Anyway, the point is that RFC 6991 do not define any da= ta nodes and
> > > > hence nothing that can be accessed. Perhaps it helps to= import
> > > > terminology into the model classification document and = to be explicit
> > > > that not all YANG modules define YANG data models.
> > > >
> > > >
> > >
> > > I brought this issue up for YANG 1.1 but there was no intere= st
> > > or agreement that there is any problem or confusion.
> > >
> > > http://www.netconfcentral.o= rg/modulereport/iana-crypt-hash
> > >
> > > Consider iana-crypt-hash that only contains=C2=A0 1 typedef = and 3 features
> > > that relate to implementation of that typedef.=C2=A0 Accordi= ng to YANG 1.1
> > > and the YANG library, a server implement MUST NOT claim it > > > implements iana-crypt-hash.=C2=A0 Instead the server must sa= y "I import
> > > this module, but implement the features".=C2=A0 How can= one implement
> > > something that is supposedly only imported?=C2=A0 Very confu= sing.
> >
> > ietf-yang-library and 6020bis(*) uses the phrase "supported<= br> > > features".=C2=A0 So, a server can advertise a module as impo= rted, and list
> > the supported features.
> >
> > (*) 6020bis actually uses the phrase "implement a feature&qu= ot; in one
> > sentence (last sentence in 7.20.1).=C2=A0 This should probably be= changed
> > to "support a feature" in order to avoid confusion.
> >
> >
> >
> How does one support a feature without implementing it?
> This terminology is inconsistent and confusing.

The feature itself isn't very interesting.=C2=A0 If a server supports feature A, it implements nodes that have if-feature "A" statement= s.



Except this is not at al= l how features are used in iana-crypt-hash.yang.
The features are= clearly related to implementation of any leaf or leaf-list
that = uses this typedef.=C2=A0 Perhaps this is an exception and we should have
never defined those features in the first place. =C2=A0
<= br>
=C2=A0
/martin

Andy<= /div>

--001a1133a9eae47bcb052fe594e8-- From nobody Thu Apr 7 07:10:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4512012D0FB for ; Thu, 7 Apr 2016 07:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zarAt2HfNC5e for ; Thu, 7 Apr 2016 07:10:10 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF1512D0E3 for ; Thu, 7 Apr 2016 07:10:09 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id f105so40092192qge.2 for ; Thu, 07 Apr 2016 07:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=sWvH49pwUsrEsEOEYKOJGWD2y07BkT/g9Rd5QuBoiwY=; b=oibq5EPJhAqhE1BNWDV7pVSMblNRmZqoyzdpdAvg+aVTX4/KPXJVvqPLilGRpqfu81 SmSer9yOtNMOpgJFL8hRPcXK5YrEjQ2L8M33nw6zboOg/9CRTyQKhY4gUCbSeMS5jkBf gnPLH3SkG4ukenONV0WEtWHlU+/96Ahe3H5F2bs0qNT8qwKU1Ub5XASZIxw3XA7/K5ov XdKGp4f9G2ugkFhqHaXwe0qSsy0r8V3u/Bp7sfcrpG2AnW9ue7YuhJaIob4v8hozv5FR BcZrj+Mi8gD4r+x2jHFUHHypQMUT7dTdqayz32TGSa4RdZhcty1Fm4Uc7TI+MixCfdWL KzaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=sWvH49pwUsrEsEOEYKOJGWD2y07BkT/g9Rd5QuBoiwY=; b=iB5Bk5n3N0y8NIvmuzkl0AzysivjZjUIixT45ScRMTKe+gpx9UVwopUP7ojFpNC9pW UEaajOEYIwLI3BxeyFKxeYvTy/U1V6lLcHwvfPsRLigfANUMpiUijMcxYm8QrTTFvI9m bN46LkinSgsfeP8nO9ReL9PLDQ0VwH1mEOw+drV7r9KS1nI+cz2alM1bSbADas3YRJq4 K2fysyqQ8CPjGnZbmsYjfMAs20uklqBdoz4KnOwLco1RTg3ckcIeFmHt8Nv8XTrzcI9r el0j1qXjPyWKq2gW3usjzO4kdfFlzwQCV6RrEzVqj7b4G9pptDRhLCJq+e4mFmIVuFyC d6zQ== X-Gm-Message-State: AD7BkJKqBdiuDXdnqXulB9e80d02VQugwlH+AJmbCXVw0pm5pLOVH0WlOj3Cv7JUUfIK1Q== X-Received: by 10.141.23.211 with SMTP id z202mr4157592qhd.52.1460038208518; Thu, 07 Apr 2016 07:10:08 -0700 (PDT) Received: from dhcp-b0f4.meeting.ietf.org (dhcp-b0f4.meeting.ietf.org. [31.133.176.244]) by smtp.gmail.com with ESMTPSA id l67sm3452644qgl.47.2016.04.07.07.10.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 07:10:07 -0700 (PDT) From: Dean Bogdanovic Content-Type: multipart/alternative; boundary="Apple-Mail=_6E18933E-4FB7-4BA9-AED1-1C2D9A2A94F6" Message-Id: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> Date: Thu, 7 Apr 2016 11:11:31 -0300 To: netmod WG Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [netmod] input Interface match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:10:15 -0000 --Apple-Mail=_6E18933E-4FB7-4BA9-AED1-1C2D9A2A94F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As the action item from the netmod WG and, hopefully, last open item in = the ACL draft is the leaf input interface in the metadata grouping=20 grouping metadata { description "Fields associated with a packet which are not in the header."; leaf input-interface { type if:interface-ref { require-instance false; } description "Packet was received on this interface."; } } } Here are two questions: One Do want to have a metadata grouping in the basic ACL model? If yes, we = have to put in some leafs in there. There are implementations which use = metadata as match condition If we agree that metadata grouping is not needed in the basic model, = then the authors would remove the grouping from the model and I believe = that no more discussion is needed on this point Dean --Apple-Mail=_6E18933E-4FB7-4BA9-AED1-1C2D9A2A94F6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii As the action item from the netmod WG and, hopefully, last open item in the ACL draft is the leaf input interface in the metadata grouping 

grouping metadata {
    description
      "Fields associated with a packet which are not in
      the header.";
    leaf input-interface {
      type if:interface-ref {
        require-instance false;
      }
      description
        "Packet was received on this interface.";
    }
  }
}


Here are two questions:
One
Do want to have a metadata grouping in the basic ACL model? If yes, we have to put in some leafs in there. There are implementations which use metadata as match condition

If we agree that metadata grouping is not needed in the basic model, then the authors would remove the grouping from the model and I believe that no more discussion is needed on this point

Dean

--Apple-Mail=_6E18933E-4FB7-4BA9-AED1-1C2D9A2A94F6-- From nobody Thu Apr 7 07:37:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97A512D85F for ; Thu, 7 Apr 2016 07:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG7K4N3NDznj for ; Thu, 7 Apr 2016 07:37:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7D9E12D972 for ; Thu, 7 Apr 2016 07:21:39 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 63BC71AE028E; Thu, 7 Apr 2016 16:21:38 +0200 (CEST) Date: Thu, 07 Apr 2016 16:21:48 +0200 (CEST) Message-Id: <20160407.162148.2159529187166196531.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20160407.145527.383210146970907510.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] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:37:13 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIEFwciA3 LCAyMDE2IGF0IDU6NTUgQU0sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90 ZToNCj4gDQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+ ID4gT24gVGh1LCBBcHIgNywgMjAxNiBhdCA1OjMzIEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpA dGFpbC1mLmNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt YXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gT24gVGh1LCBBcHIgNywgMjAxNiBhdCAzOjQ1 IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPA0KPiA+ID4gPiA+IGouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9uIFRo dSwgQXByIDA3LCAyMDE2IGF0IDA4OjU1OjE5QU0gKzAwMDAsIFNjaGFyZiwgTWljaGFlbCAoTm9r aWEgLQ0KPiA+IERFKQ0KPiA+ID4gPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+ID4gSSBjb21l IGF0IHRoaXMgZnJvbSB0aGUgY2xhc3NpZmljYXRpb24gYW5nbGUsIHNvIG15IGludGVyZXN0DQo+ ID4gaXMgaWYNCj4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiBhc3N1bXB0aW9uIHRoYXQNCj4gPiA+ ID4gPiA+ID4gPiBhIFlBTkcgbW9kZWwgY2FuIG9ubHkgYmUgY2xhc3NpZmllZCBhcyBhIG5ldHdv cmsgc2VydmljZSBtb2RlbA0KPiA+IFhPUg0KPiA+ID4gPiBhDQo+ID4gPiA+ID4gPiBuZXR3b3Jr IGRldmljZSBtb2RlbA0KPiA+ID4gPiA+ID4gPiA+IGFjY29yZGluZyB0byB0aGUgZGVmaW5pdGlv bnMgaW4NCj4gPiA+ID4gPiA+IGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmlj YXRpb24gKHNlY3Rpb25zIDIuMQ0KPiA+ID4gPiA+ID4gPiA+IGFuZCAyLjIpLiBCYXNlZCBvbiB0 aGlzIGRpc2N1c3Npb24gSSB0YWtlIGl0IHRoYXQgc29tZSBtb2RlbHMNCj4gPiBhcmUNCj4gPiA+ ID4gPiA+IGludGVuZGVkIHRvIGJlIGFibGUgdG8NCj4gPiA+ID4gPiA+ID4gPiBzZXJ2ZSBpbiBi b3RoIHJvbGVzLiBBbmQgd2Ugc2hvdWxkIG1ha2Ugc3VyZSB0aGF0IGl04oCZcw0KPiA+IHN1cHBv cnRlZCBpbg0KPiA+ID4gPiA+ID4gb3VyIGNhdGFsb2cgc3RydWN0dXJlLg0KPiA+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gPiBSZWdhcmRpbmcgdGhlIFhPUiBhc3N1bXB0aW9uIGZvciBjbGFzc2lm aWNhdGlvbjoNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gWW91IG1heSBhbHNvIHdhbnQg dG8gdGhpbmsgYWJvdXQgWUFORyBtb2RlbHMgdGhhdCBhcmUgTkVJVEhFUg0KPiA+IGRldmljZQ0K PiA+ID4gPiBOT1INCj4gPiA+ID4gPiA+IHNlcnZpY2UgbW9kZWxzLiBGb3IgaW5zdGFuY2UsIHdo YXQgYWJvdXQgUkZDIDY5OTE/IEFuZCBJIHRoaW5rDQo+ID4gb3RoZXIsDQo+ID4gPiA+IG1vcmUN Cj4gPiA+ID4gPiA+IHRlY2huaWNhbCBtb2RlbHMgcHJlc2VudGVkIHRoaXMgd2VlayBtYXkgZmFs bCBpbnRvIGEgc2ltaWxhcg0KPiA+IGNhdGVnb3J5DQo+ID4gPiA+ID4gPiAoImdlbmVyaWMiPyku DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gUkZDIDY5OTEgaXMgbm90 IHJlYWxseSBkZWZpbmluZyBhIGRhdGEgbW9kZWwsIHdoaWxlIGlldGYteWFuZy10eXBlcw0KPiA+ ID4gPiA+ID4gYW5kIGlldGYtaW5ldC10eXBlcyBhcmUgYm90aCBZQU5HIG1vZHVsZXMgdGhleSBk byBub3QgZGVmaW5lIGFueQ0KPiA+IGRhdGENCj4gPiA+ID4gPiA+IG5vZGVzIHRoYXQgY2FuIGJl IGltcGxlbWVudGVkLiBMZXRzIGxvb2sgYXQgUkZDIDYwMjBiaXM6DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gICAgbyAgZGF0YSBtb2RlbDogQSBkYXRhIG1vZGVsIGRlc2NyaWJlcyBob3cgZGF0 YSBpcyByZXByZXNlbnRlZA0KPiA+IGFuZA0KPiA+ID4gPiA+ID4gICAgICAgYWNjZXNzZWQuDQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQW55d2F5LCB0aGUgcG9pbnQgaXMgdGhhdCBSRkMgNjk5 MSBkbyBub3QgZGVmaW5lIGFueSBkYXRhIG5vZGVzIGFuZA0KPiA+ID4gPiA+ID4gaGVuY2Ugbm90 aGluZyB0aGF0IGNhbiBiZSBhY2Nlc3NlZC4gUGVyaGFwcyBpdCBoZWxwcyB0byBpbXBvcnQNCj4g PiA+ID4gPiA+IHRlcm1pbm9sb2d5IGludG8gdGhlIG1vZGVsIGNsYXNzaWZpY2F0aW9uIGRvY3Vt ZW50IGFuZCB0byBiZQ0KPiA+IGV4cGxpY2l0DQo+ID4gPiA+ID4gPiB0aGF0IG5vdCBhbGwgWUFO RyBtb2R1bGVzIGRlZmluZSBZQU5HIGRhdGEgbW9kZWxzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGJyb3VnaHQgdGhpcyBpc3N1ZSB1cCBmb3IgWUFO RyAxLjEgYnV0IHRoZXJlIHdhcyBubyBpbnRlcmVzdA0KPiA+ID4gPiA+IG9yIGFncmVlbWVudCB0 aGF0IHRoZXJlIGlzIGFueSBwcm9ibGVtIG9yIGNvbmZ1c2lvbi4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IGh0dHA6Ly93d3cubmV0Y29uZmNlbnRyYWwub3JnL21vZHVsZXJlcG9ydC9pYW5hLWNyeXB0 LWhhc2gNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENvbnNpZGVyIGlhbmEtY3J5cHQtaGFzaCB0aGF0 IG9ubHkgY29udGFpbnMgIDEgdHlwZWRlZiBhbmQgMyBmZWF0dXJlcw0KPiA+ID4gPiA+IHRoYXQg cmVsYXRlIHRvIGltcGxlbWVudGF0aW9uIG9mIHRoYXQgdHlwZWRlZi4gIEFjY29yZGluZyB0byBZ QU5HIDEuMQ0KPiA+ID4gPiA+IGFuZCB0aGUgWUFORyBsaWJyYXJ5LCBhIHNlcnZlciBpbXBsZW1l bnQgTVVTVCBOT1QgY2xhaW0gaXQNCj4gPiA+ID4gPiBpbXBsZW1lbnRzIGlhbmEtY3J5cHQtaGFz aC4gIEluc3RlYWQgdGhlIHNlcnZlciBtdXN0IHNheSAiSSBpbXBvcnQNCj4gPiA+ID4gPiB0aGlz IG1vZHVsZSwgYnV0IGltcGxlbWVudCB0aGUgZmVhdHVyZXMiLiAgSG93IGNhbiBvbmUgaW1wbGVt ZW50DQo+ID4gPiA+ID4gc29tZXRoaW5nIHRoYXQgaXMgc3VwcG9zZWRseSBvbmx5IGltcG9ydGVk PyAgVmVyeSBjb25mdXNpbmcuDQo+ID4gPiA+DQo+ID4gPiA+IGlldGYteWFuZy1saWJyYXJ5IGFu ZCA2MDIwYmlzKCopIHVzZXMgdGhlIHBocmFzZSAic3VwcG9ydGVkDQo+ID4gPiA+IGZlYXR1cmVz Ii4gIFNvLCBhIHNlcnZlciBjYW4gYWR2ZXJ0aXNlIGEgbW9kdWxlIGFzIGltcG9ydGVkLCBhbmQg bGlzdA0KPiA+ID4gPiB0aGUgc3VwcG9ydGVkIGZlYXR1cmVzLg0KPiA+ID4gPg0KPiA+ID4gPiAo KikgNjAyMGJpcyBhY3R1YWxseSB1c2VzIHRoZSBwaHJhc2UgImltcGxlbWVudCBhIGZlYXR1cmUi IGluIG9uZQ0KPiA+ID4gPiBzZW50ZW5jZSAobGFzdCBzZW50ZW5jZSBpbiA3LjIwLjEpLiAgVGhp cyBzaG91bGQgcHJvYmFibHkgYmUgY2hhbmdlZA0KPiA+ID4gPiB0byAic3VwcG9ydCBhIGZlYXR1 cmUiIGluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+IEhvdyBkb2VzIG9uZSBzdXBwb3J0IGEgZmVhdHVyZSB3aXRob3V0IGltcGxlbWVu dGluZyBpdD8NCj4gPiA+IFRoaXMgdGVybWlub2xvZ3kgaXMgaW5jb25zaXN0ZW50IGFuZCBjb25m dXNpbmcuDQo+ID4NCj4gPiBUaGUgZmVhdHVyZSBpdHNlbGYgaXNuJ3QgdmVyeSBpbnRlcmVzdGlu Zy4gIElmIGEgc2VydmVyIHN1cHBvcnRzDQo+ID4gZmVhdHVyZSBBLCBpdCBpbXBsZW1lbnRzIG5v ZGVzIHRoYXQgaGF2ZSBpZi1mZWF0dXJlICJBIiBzdGF0ZW1lbnRzLg0KPiA+DQo+ID4NCj4gPg0K PiBFeGNlcHQgdGhpcyBpcyBub3QgYXQgYWxsIGhvdyBmZWF0dXJlcyBhcmUgdXNlZCBpbiBpYW5h LWNyeXB0LWhhc2gueWFuZy4NCj4gVGhlIGZlYXR1cmVzIGFyZSBjbGVhcmx5IHJlbGF0ZWQgdG8g aW1wbGVtZW50YXRpb24gb2YgYW55IGxlYWYgb3IgbGVhZi1saXN0DQo+IHRoYXQgdXNlcyB0aGlz IHR5cGVkZWYuIA0KDQpTdXJlLiAgQnV0IHRoZSBjb25mdXNpb24gY29tZXMgZnJvbSB0aGUgdGVy bSAiaW1wbGVtZW50IiB3aGljaCBpbg0KaWV0Zi15YW5nLWxpYnJhcnkgbWVhbnMgImltcGxlbWVu dCBkYXRhIG5vZGVzIi4gIFdoZW4gc29tZW9uZSBhbHNvIHNheQ0KImltcGxlbWVudCBhIGZlYXR1 cmUiLCBpdCBtaWdodCBiZSBjb25mdXNpbmcuICBTbyBJIHNpbXBseSBwcm9wb3NlDQp0aGF0IHdl IHN0aWNrIHRvIHRoZSBwaHJhc2UgInN1cHBvcnQgYSBmZWF0dXJlIiwgdG8gYXZvaWQgdGhlDQpj b25mdXNpb24uICBEbyB5b3UgaGF2ZSBzb21lIG90aGVyIGlkZWE/DQoNCg0KL21hcnRpbg0K From nobody Thu Apr 7 07:49:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0012D813 for ; Thu, 7 Apr 2016 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IROnVj5KYQca for ; Thu, 7 Apr 2016 07:49:37 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBFF12D81D for ; Thu, 7 Apr 2016 07:36:45 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id os9so7003527lbb.2 for ; Thu, 07 Apr 2016 07:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=H88slP4707rP5OgaGHhzMUDCX4w0eNGP9VzYK3u5YwU=; b=g6z9kgT9MELdwLW5vWrDnen7lEnhm5BAzEvIMpAnVjVJeSZziqLDkYAIdPFcKY39PO tJPvuwULmX8oJcji6U644xSk8RIb2o3Y+eFRjMGDQw4R65Z+m49mFpmG7uTk9aL/9nsC mbLbwKUA8IMlIahqJbk+L5EInbr7WNMVlrnWmOFcImJ2O9ksB1t1hA5IqBKVQBPJrzSy ZBHqwoCktfF7tQRbDGYAB72iuNfIxjL45wfR8/98fo3+2cALW2N40xTRCsMvYxIX93uc zxd7vQVKV4t6Y/RSmwXfD04yLDtJBkEOOYCwFZpfDJk6hi8SieT5Hti9gT0J2rUyHFpS xCQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=H88slP4707rP5OgaGHhzMUDCX4w0eNGP9VzYK3u5YwU=; b=Yw9gP1T94mzq6rEf2RDdrbjeU5f2x+pP9yKg9wMnPqSLhMvP87rT3x0828F8Ab1uGK m95VVCg08pLEY5HDd4JXHNRnpFl+Ndl1oDpxZHlxj894nJiiqopUstOdsiZFkNP0UOLu 1DTAF9uSB52Npy9UwMYVPqXUPX1IEyLvYuDlD479Cc2sls7Tt/2rpqsj8EVXgqZD06lQ 9tPQGpdw2b8QfEqCK8YZnQ4Mwla0q90DnAexzMa/Nh00lz0NlzMtPmAvAiC7OQZj+3uO xJ7UJGzh8+kejSGfGhBmMNJwYlPUE2np02xhGXz3CLzVTnZUHkcDwXZqK3ORIsrZF1q+ hAXg== X-Gm-Message-State: AD7BkJKZxiht7tyF+Q3rSdtPdFPYQ7O8tN/yQvky7Ut9ZdgrQ8QEpNBd6hCFn5MvDqkKMw3V2sgs9WcsofNEhw== MIME-Version: 1.0 X-Received: by 10.112.49.50 with SMTP id r18mr1548490lbn.65.1460039804084; Thu, 07 Apr 2016 07:36:44 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 7 Apr 2016 07:36:43 -0700 (PDT) In-Reply-To: <20160407.162148.2159529187166196531.mbj@tail-f.com> References: <20160407.145527.383210146970907510.mbj@tail-f.com> <20160407.162148.2159529187166196531.mbj@tail-f.com> Date: Thu, 7 Apr 2016 07:36:43 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113605a4e179aa052fe601f4 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:49:39 -0000 --001a113605a4e179aa052fe601f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2016 at 7:21 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund wrote= : > > > > > Andy Bierman wrote: > > > > On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund > wrote: > > > > > > > > > Andy Bierman wrote: > > > > > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwaelder < > > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Scharf, Michael > (Nokia - > > > DE) > > > > > > > wrote: > > > > > > > > > I come at this from the classification angle, so my > interest > > > is if > > > > > the > > > > > > > assumption that > > > > > > > > > a YANG model can only be classified as a network service > model > > > XOR > > > > > a > > > > > > > network device model > > > > > > > > > according to the definitions in > > > > > > > draft-ietf-netmod-yang-model-classification (sections 2.1 > > > > > > > > > and 2.2). Based on this discussion I take it that some > models > > > are > > > > > > > intended to be able to > > > > > > > > > serve in both roles. And we should make sure that it=E2= =80=99s > > > supported in > > > > > > > our catalog structure. > > > > > > > > > > > > > > > > Regarding the XOR assumption for classification: > > > > > > > > > > > > > > > > You may also want to think about YANG models that are NEITH= ER > > > device > > > > > NOR > > > > > > > service models. For instance, what about RFC 6991? And I thin= k > > > other, > > > > > more > > > > > > > technical models presented this week may fall into a similar > > > category > > > > > > > ("generic"?). > > > > > > > > > > > > > > > > > > > > > > RFC 6991 is not really defining a data model, while > ietf-yang-types > > > > > > > and ietf-inet-types are both YANG modules they do not define > any > > > data > > > > > > > nodes that can be implemented. Lets look at RFC 6020bis: > > > > > > > > > > > > > > o data model: A data model describes how data is > represented > > > and > > > > > > > accessed. > > > > > > > > > > > > > > Anyway, the point is that RFC 6991 do not define any data > nodes and > > > > > > > hence nothing that can be accessed. Perhaps it helps to impor= t > > > > > > > terminology into the model classification document and to be > > > explicit > > > > > > > that not all YANG modules define YANG data models. > > > > > > > > > > > > > > > > > > > > > > > > > > I brought this issue up for YANG 1.1 but there was no interest > > > > > > or agreement that there is any problem or confusion. > > > > > > > > > > > > http://www.netconfcentral.org/modulereport/iana-crypt-hash > > > > > > > > > > > > Consider iana-crypt-hash that only contains 1 typedef and 3 > features > > > > > > that relate to implementation of that typedef. According to > YANG 1.1 > > > > > > and the YANG library, a server implement MUST NOT claim it > > > > > > implements iana-crypt-hash. Instead the server must say "I > import > > > > > > this module, but implement the features". How can one implemen= t > > > > > > something that is supposedly only imported? Very confusing. > > > > > > > > > > ietf-yang-library and 6020bis(*) uses the phrase "supported > > > > > features". So, a server can advertise a module as imported, and > list > > > > > the supported features. > > > > > > > > > > (*) 6020bis actually uses the phrase "implement a feature" in one > > > > > sentence (last sentence in 7.20.1). This should probably be > changed > > > > > to "support a feature" in order to avoid confusion. > > > > > > > > > > > > > > > > > > > How does one support a feature without implementing it? > > > > This terminology is inconsistent and confusing. > > > > > > The feature itself isn't very interesting. If a server supports > > > feature A, it implements nodes that have if-feature "A" statements. > > > > > > > > > > > Except this is not at all how features are used in iana-crypt-hash.yang= . > > The features are clearly related to implementation of any leaf or > leaf-list > > that uses this typedef. > > Sure. But the confusion comes from the term "implement" which in > ietf-yang-library means "implement data nodes". When someone also say > "implement a feature", it might be confusing. So I simply propose > that we stick to the phrase "support a feature", to avoid the > confusion. Do you have some other idea? > > not really. We already spent a lot of time on the 'conformance-type' leaf and could not come up with consensus on something else. Supported feature will have to be good enough. It also applies to if-feature on an identity-stmt, which is only indirectly implemented. > > /martin > Andy --001a113605a4e179aa052fe601f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 7:21 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Apr 7, 2016 at 5:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Thu, Apr 7, 2016 at 5:33 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > > Andy Bierman <= andy@yumaworks.com> wrote:
> > > > > On Thu, Apr 7, 2016 at 3:45 AM, Juergen Schoenwael= der <
> > > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > > >
> > > > > > On Thu, Apr 07, 2016 at 08:55:19AM +0000, Sch= arf, Michael (Nokia -
> > DE)
> > > > > > wrote:
> > > > > > > > I come at this from the classificat= ion angle, so my interest
> > is if
> > > > the
> > > > > > assumption that
> > > > > > > > a YANG model can only be classified= as a network service model
> > XOR
> > > > a
> > > > > > network device model
> > > > > > > > according to the definitions in
> > > > > > draft-ietf-netmod-yang-model-classification (= sections 2.1
> > > > > > > > and 2.2). Based on this discussion = I take it that some models
> > are
> > > > > > intended to be able to
> > > > > > > > serve in both roles. And we should = make sure that it=E2=80=99s
> > supported in
> > > > > > our catalog structure.
> > > > > > >
> > > > > > > Regarding the XOR assumption for classif= ication:
> > > > > > >
> > > > > > > You may also want to think about YANG mo= dels that are NEITHER
> > device
> > > > NOR
> > > > > > service models. For instance, what about RFC = 6991? And I think
> > other,
> > > > more
> > > > > > technical models presented this week may fall= into a similar
> > category
> > > > > > ("generic"?).
> > > > > > >
> > > > > >
> > > > > > RFC 6991 is not really defining a data model,= while ietf-yang-types
> > > > > > and ietf-inet-types are both YANG modules the= y do not define any
> > data
> > > > > > nodes that can be implemented. Lets look at R= FC 6020bis:
> > > > > >
> > > > > >=C2=A0 =C2=A0 o=C2=A0 data model: A data model= describes how data is represented
> > and
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0accessed.
> > > > > >
> > > > > > Anyway, the point is that RFC 6991 do not def= ine any data nodes and
> > > > > > hence nothing that can be accessed. Perhaps i= t helps to import
> > > > > > terminology into the model classification doc= ument and to be
> > explicit
> > > > > > that not all YANG modules define YANG data mo= dels.
> > > > > >
> > > > > >
> > > > >
> > > > > I brought this issue up for YANG 1.1 but there was= no interest
> > > > > or agreement that there is any problem or confusio= n.
> > > > >
> > > > > http://www.netcon= fcentral.org/modulereport/iana-crypt-hash
> > > > >
> > > > > Consider iana-crypt-hash that only contains=C2=A0 = 1 typedef and 3 features
> > > > > that relate to implementation of that typedef.=C2= =A0 According to YANG 1.1
> > > > > and the YANG library, a server implement MUST NOT = claim it
> > > > > implements iana-crypt-hash.=C2=A0 Instead the serv= er must say "I import
> > > > > this module, but implement the features".=C2= =A0 How can one implement
> > > > > something that is supposedly only imported?=C2=A0 = Very confusing.
> > > >
> > > > ietf-yang-library and 6020bis(*) uses the phrase "= supported
> > > > features".=C2=A0 So, a server can advertise a modu= le as imported, and list
> > > > the supported features.
> > > >
> > > > (*) 6020bis actually uses the phrase "implement a = feature" in one
> > > > sentence (last sentence in 7.20.1).=C2=A0 This should p= robably be changed
> > > > to "support a feature" in order to avoid conf= usion.
> > > >
> > > >
> > > >
> > > How does one support a feature without implementing it?
> > > This terminology is inconsistent and confusing.
> >
> > The feature itself isn't very interesting.=C2=A0 If a server = supports
> > feature A, it implements nodes that have if-feature "A"= statements.
> >
> >
> >
> Except this is not at all how features are used in iana-crypt-hash.yan= g.
> The features are clearly related to implementation of any leaf or leaf= -list
> that uses this typedef.

Sure.=C2=A0 But the confusion comes from the term "implement" whi= ch in
ietf-yang-library means "implement data nodes".=C2=A0 When someon= e also say
"implement a feature", it might be confusing.=C2=A0 So I simply p= ropose
that we stick to the phrase "support a feature", to avoid the
confusion.=C2=A0 Do you have some other idea?


not really.=C2=A0 We already spent a lot of time on = the 'conformance-type' leaf
and could not come up with co= nsensus on something else.
Supported feature will have to be good= enough.=C2=A0 It also applies to if-feature
on an identity-stmt,= which is only indirectly implemented.

=C2=A0

/martin

Andy<= /div>

--001a113605a4e179aa052fe601f4-- From nobody Thu Apr 7 08:14:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2D712D948 for ; Thu, 7 Apr 2016 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OKw_5ubgzme for ; Thu, 7 Apr 2016 08:14:17 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 23CF112D101 for ; Thu, 7 Apr 2016 08:00:55 -0700 (PDT) Received: (qmail 5897 invoked by uid 0); 7 Apr 2016 15:00:53 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 7 Apr 2016 15:00:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id fT0l1s0072SSUrH01T0ouo; Thu, 07 Apr 2016 09:00:51 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=fl9PL8ng212584Lf09YA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=rJgIKTArpa6p349orHNJRP0ofLOWGMrs+vCAMQWBdDs=; b=TUJ8MCVCD+UgcBEfa9vFSwzOx/ 85THOhsex5RGcg8m1F2QvIsBB/sQpsDMqhZhBVcdcBwn5UPkEIpuUyF+0nIE2MgJ1SdtzNZkL5GqH Vz+FNpm3GKQhPPmocXW15tyoG; Received: from box313.bluehost.com ([69.89.31.113]:54411 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aoBQM-00012M-TQ; Thu, 07 Apr 2016 09:00:47 -0600 To: Andy Bierman , Ladislav Lhotka References: <7BE1AC8F-CBCE-4593-B997-628F39CD04EA@nic.cz> <57043738.9000500@labn.net> From: Lou Berger Message-ID: <57067618.30105@labn.net> Date: Thu, 7 Apr 2016 11:00:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <57043738.9000500@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: NETMOD WG Subject: Re: [netmod] schema mount issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:14:20 -0000 All, The repo has been setup to send notification of changes to netmod. We'll have to see how this works, and if it doesn't work well will have figure out what to try next... Lou On 4/5/2016 6:07 PM, Lou Berger wrote: > > On 4/5/2016 1:40 PM, Andy Bierman wrote: >> >> On Tue, Apr 5, 2016 at 10:18 AM, Ladislav Lhotka > > wrote: >> >> Hi, >> >> during the NETMOD session yesterday, we didn't have much time to >> discuss open issues related to schema mount. So I created three >> new issues in the GitHub project: >> >> https://github.com/netmod-wg/schema-mount/issues >> >> Please express your opinion there. >> >> >> As a procedural issue I think WG business needs to be conducted >> on the WG mailing list, not on github. >> > +1 > > capturing issues somewhere is important, and github is a fine place -- > but discussion need to be on list. > > -- it would be great if you could gateway issues to the WG list. > > Thanks, > Lou > (as one of three chairs, ;-) >> >> >> >> Thanks, Lada >> >> >> Andy >> >> >> -- >> 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Apr 7 09:43:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A5012D11D for ; Thu, 7 Apr 2016 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egCOxkNWEuWX for ; Thu, 7 Apr 2016 09:43:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B66512D0B9 for ; Thu, 7 Apr 2016 09:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3532; q=dns/txt; s=iport; t=1460047433; x=1461257033; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mCM0lsUMJCbH8qPeqEa1/d2NGDrxwNK8BWDHJ4brizY=; b=g4ASPGW+1G3OquLvE3XxxiLHn/mGTtfs767HVuL+qbGw64V7XJ33vpee U6PatGpxSvFDb3h79bluNf+NXxLKWss6PABRnemmSNCM6oXMx/zAsl3MM /L0ZPEuhe4Sz7FmYzmZx0Kx8ggPrMmYT6iWNazItSHNXgy+sG+UzRVrq1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQDXjQZX/5hdJa1dgzdTfQa6UwENg?= =?us-ascii?q?XMXCoUiSgIcgSc4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQcEAgEIEQQBAQE?= =?us-ascii?q?CAiMDAgICJQsUAQgIAgQOBQiIFwgOr06RewEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?REEfIlwhz+CVgWJWo4qAY4EjxWPIwEeAQFCg2dsh3UBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="257870388" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 16:43:52 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u37Ghqbn028181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 16:43:52 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 12:43:51 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 12:43:51 -0400 From: "Alexander Clemm (alex)" To: "Carl Moberg (camoberg)" , "Scharf, Michael (Nokia - DE)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA///z0QCAABFtAIAAMpcg///gUoCAADIeAIAAfSGAgAANJICAAACNgP//zgBg Date: Thu, 7 Apr 2016 16:43:51 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> In-Reply-To: <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:43:55 -0000 SSBhbSB3b25kZXJpbmcgd2hhdCBwdXJwb3NlIHRoZSBjbGFzc2lmaWNhdGlvbiByZWFsbHkgc2Vy dmVzLiAgQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIGFyZSB0 cnlpbmcgdG8gZXhwcmVzcyBhIG1vZGVsIGhpZXJhcmNoeSwgYW5kIGFydGljdWxhdGUgd2hhdCB0 aGUgbGF5ZXJzIGluIHRoZSBoaWVyYXJjaHkgYXJlLiAgQSBkZXZpY2UgbW9kZWwgaXMgdGh1cyBh dCBhIGxvd2VyIGxheWVyIHRoYW4gYSBzZXJ2aWNlIG1vZGVsLiAgQW4gaW1wbGVtZW50YXRpb24g b2YgdGhlIHNlcnZpY2UgbW9kZWwgbWF5IGluIHR1cm4gaGF2ZSBkZXBlbmRlbmNpZXMgb24gdGhl IGRldmljZSBtb2RlbCwgYnV0IG5vdCB0aGUgb3RoZXIgd2F5IHJvdW5kLiAgDQoNCldoZXJlIHRo ZSBtb2RlbHMgYXJlIGluc3RhbnRpYXRlZCAtIG9uIGEgY29udHJvbGxlciwgb24gYSAiZGV2aWNl IiwgZXRjIC0gc2VlbXMgdG8gYmUgc2Vjb25kYXJ5IGFuZCBpbmNpZGVudGFsLiAgVGhlIGJvdW5k YXJpZXMgYXJlIGJsdXJyeSwgYW55d2F5cy4gIEEgY29udHJvbGxlciBpcyBhIGRldmljZSB0b287 IHNvbWUgZGV2aWNlcyBtYXkgY29udGFpbiB2aXJ0dWFsaXplZCBjb250cm9sbGVycywgYW5kIHNv IG9uLiAgDQoNCk9uZSBtb2RlbCB0aGF0IGlzIHJlbGV2YW50IGluIHRoaXMgZGlzY3Vzc2lvbiBz ZWVtcyB0byBiZSB0aGUgVE1OIG1vZGVsLCBhcyBkZWZpbmVkIGluIElUVS1UIFJlY29tbWVuZGF0 aW9uIE0uMzAxMC4gIFRoaXMgbW9kZWwgZGVmaW5lcyBhIHNldCBvZiBtYW5hZ2VtZW50IGxheWVy cyAtIG5ldHdvcmsgZWxlbWVudCAoZGV2aWNlKSwgbmV0d29yaywgc2VydmljZSwgYnVzaW5lc3Mg LSB3aXRoIHdlbGwgZGVmaW5lZCBmdW5jaW9uYWwgc2NvcGUgb2YgZWFjaCBsYXllci4gIFRoZSBs YXllcnMgLyBmdW5jdGlvbiBoaWVyYXJjaHkgYWxzbyBpbXBseSBhbiBpbmZvcm1hdGlvbiAgYW5k IGRhdGEgbW9kZWwgaGllcmFyY2h5LiAgDQoNCldvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gc2VlIGlm IHRoZSBsYXllcmluZyBpbiBNLjMwMTAgY291bGQgaGVscCBndWlkZSBZQU5HIG1vZGVsIGNsYXNz aWZpY2F0aW9uLCBhbmQgcmVmZXJlbmNlIHRob3NlIGRlZmluaXRpb25zPyAgDQoNCi0tLSBBbGV4 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRt b2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcmwgTW9iZXJnIChjYW1vYmVyZykN ClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiAxOjU3IEFNDQpUbzogU2NoYXJmLCBNaWNo YWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPg0KQ2M6IG5ldG1vZEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY2xhc3NpZmljYXRpb24/ DQoNCg0KDQotLQ0KQ2FybCBNb2JlcmcNClRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KY2Ftb2Jl cmdAY2lzY28uY29tDQoNCj4gT24gQXByIDcsIDIwMTYsIGF0IDEwOjU1IEFNLCBTY2hhcmYsIE1p Y2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+IHdyb3RlOg0KPiAN Cj4+IEkgY29tZSBhdCB0aGlzIGZyb20gdGhlIGNsYXNzaWZpY2F0aW9uIGFuZ2xlLCBzbyBteSBp bnRlcmVzdCBpcyBpZiANCj4+IHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBZQU5HIG1vZGVsIGNhbiBv bmx5IGJlIGNsYXNzaWZpZWQgYXMgYSBuZXR3b3JrIA0KPj4gc2VydmljZSBtb2RlbCBYT1IgYSBu ZXR3b3JrIGRldmljZSBtb2RlbCBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb25zIA0KPj4gaW4g ZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiAoc2VjdGlvbnMgMi4x IGFuZCANCj4+IDIuMikuIEJhc2VkIG9uIHRoaXMgZGlzY3Vzc2lvbiBJIHRha2UgaXQgdGhhdCBz b21lIG1vZGVscyBhcmUgaW50ZW5kZWQgdG8gYmUgYWJsZSB0byBzZXJ2ZSBpbiBib3RoIHJvbGVz LiBBbmQgd2Ugc2hvdWxkIG1ha2Ugc3VyZSB0aGF0IGl04oCZcyBzdXBwb3J0ZWQgaW4gb3VyIGNh dGFsb2cgc3RydWN0dXJlLg0KPiANCj4gUmVnYXJkaW5nIHRoZSBYT1IgYXNzdW1wdGlvbiBmb3Ig Y2xhc3NpZmljYXRpb246DQo+IA0KPiBZb3UgbWF5IGFsc28gd2FudCB0byB0aGluayBhYm91dCBZ QU5HIG1vZGVscyB0aGF0IGFyZSBORUlUSEVSIGRldmljZSBOT1Igc2VydmljZSBtb2RlbHMuIEZv ciBpbnN0YW5jZSwgd2hhdCBhYm91dCBSRkMgNjk5MT8gQW5kIEkgdGhpbmsgb3RoZXIsIG1vcmUg dGVjaG5pY2FsIG1vZGVscyBwcmVzZW50ZWQgdGhpcyB3ZWVrIG1heSBmYWxsIGludG8gYSBzaW1p bGFyIGNhdGVnb3J5ICgiZ2VuZXJpYyI/KS4NCg0KIFZlcnkgZ29vZCBwb2ludCwgdGhhbmtzISBU aGF0IHdpbGwgbmVlZCBzb21lIGFkZGl0aW9uYWwgdGhpbmtpbmcgYW5kIHdyaXRpbmcuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0K From nobody Thu Apr 7 09:44:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3312D13B for ; Thu, 7 Apr 2016 09:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcBvmUf9wtRY for ; Thu, 7 Apr 2016 09:44:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4AF412D128 for ; Thu, 7 Apr 2016 09:44:51 -0700 (PDT) Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F2F01AE028E for ; Thu, 7 Apr 2016 18:44:50 +0200 (CEST) To: netmod@ietf.org From: Per Hedeland Message-ID: <57068E81.9080902@tail-f.com> Date: Thu, 7 Apr 2016 18:44:49 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Description of the "prefix" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:44:53 -0000 Hi, I "happened" to read "7.1.4. The prefix Statement" in RFC 6020, and found this strange statement: When used inside the "module" statement, the "prefix" statement defines the prefix to be used when this module is imported. This is obviously not correct (it would effectively require prefixes to be unique across all modules) - the prefix used when the module is imported is completely up to the author of the importing module. I guess it hasn't caused any great harm, but I think it would be a good idea to remove this statement from 6020bis (it is the same there), if it isn't too late. --Per Hedeland From nobody Thu Apr 7 19:20:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727D112D1DA for ; Thu, 7 Apr 2016 19:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T84_l2CODY4n for ; Thu, 7 Apr 2016 19:20:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460D612D50D for ; Thu, 7 Apr 2016 19:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4727; q=dns/txt; s=iport; t=1460082021; x=1461291621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DiAgmQxbFl2LvpRSes4wmM2woViGqluDPFI0CL63iTo=; b=EISZdeJ8p+5xbS9WkMCLjko9uNlYNQLOKT3ClA8cJqznJOcHxRZBbckq XOcLT1R0oyLm9vemh4MMgVAmp+0gWzbbyFMnouzx1bsYxcGronNG+9jbh KzUY/h35W8IQw3fL9NqRtdgywzaIb3Xy7IW77+h8gIdQA76+9RGg9cSaK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCnFAdX/5BdJa1dgzdTfQa6QAENg?= =?us-ascii?q?XMXCoUiSgKBPjgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwULAgEIDgoeECcLJQI?= =?us-ascii?q?EAQ0FCBOIBAgOwh4BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuKFQWNToo2A?= =?us-ascii?q?Y4EgW6HdYUxjyMBHgEBQoNnbIg7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="94156977" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 02:20:20 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u382KJbg008502 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 02:20:20 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 22:20:19 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 22:20:19 -0400 From: "Eric Voit (evoit)" To: Martin Bjorklund , "kwatsen@juniper.net" , "Alexander Clemm (alex)" Thread-Topic: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements Thread-Index: AQHRjx7t1dIqVaLFu0y/L6aVF65SwZ9/Ukig Date: Fri, 8 Apr 2016 02:20:19 +0000 Message-ID: References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> In-Reply-To: <20160405.113822.1614298419822308565.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.227.207] 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] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 02:20:24 -0000 > Martin Bjorklund, April 05, 2016 5:38 AM >=20 > Hi, >=20 > Kent Watsen wrote: > > [As a contributor] > > > > Note: this is a -00 document, but only because the draft's name > > changed. In reality this is like a > > draft-voit-netmod-peer-mount-requirements-04. Looking at the diffs, > > there aren't many changes, mostly cleanup and adding the "schema > > mount" concept. That is, the new "yang mount" term is use to cover > > all of "schema mount", "alias mount", and "peer mount". > > > > My comment is mostly high-level. I'm wondering about the need for > > this draft to include schema mount at all. That is, a schema mount > > solution draft is now an adopted WG item, and I'm unsure if the > > authors of that draft are looking to this one to define requirements. > > Perhaps the goal is to define the umbrella term "yang mount", but to > > be honest, I don't really see a need to have a term that spans both > > schema and data mounts. I'm not sure how others feel about this, but > > my thoughts are that we should define terms like: > > > > - scheme-mount > > - data-mount > > - remote data mount (a.k.a. peer mount) > > - local data mount (a.k.a. alias mount) > > > > More so than: > > > > yang-mount > > - scheme-mount > > - alias-mount > > - peer-mount >=20 > Listening to Eric's presentation yesterday, I realized that I have a slig= htly > different view on these terms. >=20 > I prefer to separate the *schema* (data model) from how things are > implemented. The various proposals for specific implementations (peer mo= unt > and alias mount etc) all need a "schema mount" to take of > defining a proper data model. (This was the whole point of defining > structural-mount...) Applications will have to know the full path to an object, but might not ha= ve to know the full schema of mounted objects. (i.e., with a path, a data= mount access a specific node without mounting the full schema.) This shou= ldn't pose any issues as Peer Mount implementation so far have been read-on= ly, and internal constraints within a namespace need not be checked. > For example, suppose we have: >=20 > container logical-devices { > list logical-device { > key name; > ... > yangmnt:mount-point logical-device; > } > } >=20 > With the associated yang-library, a client might learn that ietf-interfac= es is > mounted under the "logical-device" mount mount. >=20 > Now, the client knows that there are paths: >=20 > /logical-devices/logical-device/if:interfaces/if:interface >=20 > but the client doesn't necessarily have to know if the the interfaces dat= a is > implemented w/ "peer mount" or some other mechanism. >=20 >=20 > So, in my view, we have: >=20 > schema mount > | > +---- peer mount > +---- alias mount > +---- other cool mount My thinking matches more closely to what Kent lays out above: schema-mount data-mount remote data mount (a.k.a. peer mount) local data mount (a.k.a. alias mount) The value in the term "yang mount" is that it provides a conceptual umbrell= a to ensure a cohesive syntax across the four valid permutations of the abo= ve. The term itself was never intended to be implementable. Adding Alex for his thoughts as he has thought through configuration exampl= es more deeply than I have. Eric >=20 > As a concrete example, peer mount might be used like this (example taken = from > draft-clemm-netmod-mount-03): >=20 > import ietf-schema-mount { > prefix yangmnt; > } > import ietf-peer-mount { > prefix pmnt; > } >=20 > ... >=20 > list network-element { > key "element-id"; > leaf element-id { > type element-ID; > } > container element-address { > ... // choice definition that allows to specify > // host name, > // IP addresses, URIs, etc > } > yangmnt:mount-point "interfaces" { > pmnt:target "./element-address"; > pmnt:subtree "/if:interfaces"; > } > ... > } >=20 >=20 > A client that knows about the generic, abstract schema mount can work wit= h > this, without knowing anything of the specific implementation of peer mou= nt. >=20 > [Actually, since peer mount is just one implementation technique, I'd pre= fer to > decouple the definition of this implementation detail from the data model= , but > that's a different topic.] >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 7 19:52:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C050B12D62B for ; Thu, 7 Apr 2016 19:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Fz7FvJ2OSIm for ; Thu, 7 Apr 2016 19:52:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7763612D153 for ; Thu, 7 Apr 2016 19:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15814; q=dns/txt; s=iport; t=1460083954; x=1461293554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p7uYf/MM7EE4pswmDvVNoEb9rGno3mZ1ksFCQc125LA=; b=kmNQFPYYuSML/Stro/o2JlSFvpXTWtEp15sx9G94f69DINDx3x4Q6xuq MKUF1SBWiWBY+l7MNCRR5pROLyMIQnspNDe6bIEgodR0F96g/WF9bjpj0 JOt3F9ciSUmWu0NbNrEAcHUjcWPuju5e8iGno5NZrginc4pIgwRFMaTU3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgDyGwdX/5FdJa1dgzdTfQa6QAENg?= =?us-ascii?q?XMXCoUiSgIcgSI4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToEBwUHBAIBCBEEAQE?= =?us-ascii?q?BAgIjAwICAiULFAEICAIEAQ0FCBOIBAgOsBKSEgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEfIUlhEuEBSKDGIJWBYdthWGBMokEAY4EgW6HdYUxjyMBHgEBQoIEGYF?= =?us-ascii?q?KbId+BxcHGH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="258059842" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 02:52:32 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u382qWnI018560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 02:52:32 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 22:52:31 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 22:52:31 -0400 From: "Eric Voit (evoit)" To: Ladislav Lhotka , Martin Bjorklund , "Alexander Clemm (alex)" , "kwatsen@juniper.net" Thread-Topic: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements Thread-Index: AQHRkAAY1dIqVaLFu0y/L6aVF65SwZ9/XLCg Date: Fri, 8 Apr 2016 02:52:31 +0000 Message-ID: References: <20160405.113822.1614298419822308565.mbj@tail-f.com> <16B50CA8-0076-413D-87D1-FFBE6A54175C@nic.cz> <8eab257636824a178c19ebaf83d80dca@XCH-RTP-001.cisco.com> <20160406.091852.487853511276571798.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.227.207] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 02:52:37 -0000 PiBMYWRpc2xhdiBMaG90a2EsIFdlZG5lc2RheSwgQXByaWwgMDYsIDIwMTYgODozMCBBTQ0KPiAN Cj4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4gDQo+ID4gSGks DQo+ID4NCj4gPiAiQWxleGFuZGVyIENsZW1tIChhbGV4KSIgPGFsZXhAY2lzY28uY29tPiB3cm90 ZToNCj4gPj4gSGksIE1hcnRpbiwgTGFkYSwNCj4gPj4NCj4gPj4gdW5mb3J0dW5hdGVseSBJIHdh c24ndCBhYmxlIHRvIGF0dGVuZCB0aGUgZGlzY3Vzc2lvbiwgYnV0IEkgaGF2ZSBvbmUNCj4gPj4g Y29tbWVudCByZWdhcmRpbmcgdGhlICJkZWZpbml0aW9uIiB2cyAiaW1wbGVtZW50YXRpb24iIGRp c3RpbmN0aW9uLg0KPiA+DQo+ID4gSSBwcm9iYWJseSBmYWlsZWQgdG8gY29tbXVuaWNhdGUgbXkg cG9pbnQgY2xlYXJseS4gIEkgZGlkIG5vdCB3YW50IHRvDQo+ID4gbWFrZSB0aGUgZGlzdGluY3Rp b24gaW4gdGhpcyB3YXkuDQo+ID4NCj4gPj4gQ2xlYXJseSwgcGVlci1tb3VudCBhbmQgYWxpYXMt bW91bnQgaGF2ZSBhIGRlZmluaXRpb24gY29tcG9uZW50IHRvDQo+ID4+IGl0Lg0KPiA+DQo+ID4g WWVzLCBhYnNvbHV0ZWx5LiAgSSBkb24ndCB0aGluayBJIGltcGxpZWQgdGhhdCB0aGV5IGRpZG4n dC4NCj4gPg0KPiA+PiBUaGlzIGlzIHdoeSB0aGUgWUFORyBleHRlbnNpb25zIHdlcmUgZGVmaW5l ZCB0byBkZWZpbmUgbW91bnRwb2ludHMuDQo+ID4+IFRoaXMgZGVmaW5pdGlvbiBjb21wb25lbnQg Y2FuIGJlIGFsaWduZWQgd2l0aCBzdHJ1Y3R1cmFsIG1vdW50LCBhbmQNCj4gPj4gdGhlIGdvYWwg bmVlZHMgdG8gYmUgdG8gcmV1c2UgdGhlIHNhbWUuICBTbyBmYXIsIHNvIGdvb2QuDQo+ID4NCj4g PiBZZXMsIHRoaXMgd2FzIG15IHBvaW50LiAgSW4gRXJpYydzIHByZXNlbnRhdGlvbiBoZSBoYWQg InNjaGVtYSBtb3VudCIsDQo+ID4gInBlZXItbW91bnQiLCBhbmQgImFsaWFzLW1vdW50IiBvbiB0 aGUgc2FtZSBsZXZlbDsgYWxsIHRocmVlIGRpZmZlcmVudA0KPiA+IHZhcmlhdGlvbnMgb2YgdGhl IGdlbmVyaWMgY29uY2VwdCAiWUFORyBNb3VudCIuICBJIHRoaW5rIHRoYXQgaXMNCj4gPiBpbmNv cnJlY3Q7IHdlIHNob3VsZCBoYXZlIGEgZ2VuZXJpYyAic2NoZW1hIG1vdW50Iiwgd2l0aCAicGVl ci1tb3VudCINCj4gPiBhbmQgImFsaWFzLW1vdW50IiBiZWluZyBzcGVjaWFsaXphdGlvbnMgb2Yg dGhpcyBjb25jZXB0Lg0KPiANCj4gSSB3b3VsZCBnbyBldmVuIGZ1cnRoZXI6IHNjaGVtYSBtb3Vu dCBhbmQgcGVlciBtb3VudCBhcmUgaW5kZXBlbmRlbnQgYW5kDQo+IG9ydGhvZ29uYWwgKG5vdCBz dXJlIGFib3V0IGFsaWFzIG1vdW50IC0gdGhpcyBpcyBwcm9iYWJseSBzdGlsbCBzb21ldGhpbmcg ZWxzZSkuDQo+IFRoYXQgaXMsIEkgY2FuIGJ1aWxkIGEgZGF0YSBtb2RlbCB3aXRoIHNjaGVtYSBt b3VudCwgYW5kIHVzZSBpdCBmb3IgdmFsaWRhdGluZyBhDQo+IGdvb2Qgb2xkIGxvY2FsIGRhdGFz dG9yZS4gQ29udmVyc2VseSwgaXQgaXMgSU1PIHBvc3NpYmxlIHRvIGFwcGx5IHBlZXIgbW91bnQg YW5kDQo+IHZhbGlkYXRlIHRoZSBkYXRhIGFnYWluc3QgYSBkYXRhIG1vZGVsIHRoYXQncyBjb25z dHJ1Y3RlZCBhY2NvcmRpbmcgdG8gdGhlDQo+IGV4aXN0aW5nIHJ1bGVzLg0KDQpQZWVyIE1vdW50 IGltcGxlbWVudGF0aW9ucyBoYXZlIGJlZW4gcmVhZC1vbmx5IChzbyBmYXIpLiAgSXQgd291bGQg YmUgZ29vZCB0byBhdm9pZCByZXF1aXJpbmcgdGhlIHRyYW5zYWN0aW9uYWwgcmVxdWlyZW1lbnRz IGZvciB3cml0ZSBhbmQgdGhlcmVmb3JlIHRoZSBuZWVkcyB0byBicmluZyBpbiBhbmQgdmFsaWRh dGUgd2l0aCB0aGUgc2NoZW1hLiAgIFN1Y2ggYSByZXF1aXJlbWVudCB3b3VsZCBiZSB2ZXJ5IGhl YXZ5LXdlaWdodCBmb3IgdXNlIHdpdGggcmVtb3RlIHN5c3RlbXMuICBJdCBtaWdodCBub3QgZXZl biBiZSBwb3NzaWJsZSBpZiB0aG9zZSByZW1vdGUgc3lzdGVtcyBoYXZlIGFjY2VzcyBjb250cm9s IHBlcm1pc3Npb25zIHdoaWNoIGRvbid0IHBlcm1pdCB2aXNpYmlsaXR5IGFnYWluc3Qgb2JqZWN0 cyB1c2VkIGZvciBzdWNoIHZhbGlkYXRpb25zLiANCiANCj4gU28sIGV2ZW4gdGhvdWdoIGl0IG1h eSBiZSBzb21ldGltZXMgYmVuZWZpY2lhbCB0byBjb21iaW5lIHNjaGVtYSBtb3VudCBhbmQNCj4g cGVlciBtb3VudCwgSSBiZWxpZXZlIHRoZXkgY2FuIGFuZCBzaG91bGQgYmUgaW1wbGVtZW50ZWQg YXMgdHdvIGluZGVwZW5kZW50DQo+IGNvbmNlcHRzLiAgQSBwdXJlIHNjaGVtYSBtb3VudCBzaG91 bGQgaGF2ZSBubyBzZWN1cml0eSBpbXBsaWNhdGlvbnMsIHdoZXJlYXMNCj4gYWNjZXNzaW5nIHJl bW90ZSBkYXRhIGNlcnRhaW5seSBoYXMgc29tZS4gQW5kIGFjY2VwdGluZyBhIChzdWIpc2NoZW1h IGZyb20gYW4NCj4gZXh0ZXJuYWwgc291cmNlIHJlcXVpcmVzIElNTyBldmVuIGhpZ2hlciBsZXZl bCBvZiB0cnVzdC4NCg0KUmVhZC1vbmx5IGFjY2VzcyBjb250cm9sIG9iamVjdHMgc2hvdWxkIGJl IGVhc2llciBmb3IgYSBzdWItc2NoZW1hIHJhdGhlciBhIGZ1bGwgc2NoZW1hLiAgRm9yIHJlbW90 ZSBzeXN0ZW0gYWNjZXNzIHdlIGFscmVhZHkgbmVlZCB0aGVzZSBzZWN1cml0eSBlbGVtZW50cyBm b3IgYSBnZXQsIGhvcGVmdWxseSB3ZSBhcmUgbm90IHJlcXVpcmluZyBhbnl0aGluZyBuZXcgd2hl biB3ZSBpbnNlcnQgdGhlIHBlZXIgbW91bnQgYWJzdHJhY3Rpb24uDQoNCkVyaWMNCiANCj4gTGFk YQ0KPiANCj4gPg0KPiA+DQo+ID4+IFRoZSBhc3BlY3QgdGhhdCBJIGRvbid0IHRoaW5rIEkgYWdy ZWUgd2l0aCBpcyB0aGF0IHBlZXItbW91bnQgYW5kDQo+ID4+IGFsaWFzLW1vdW50IHNob3VsZCBi ZSB0cmVhdGVkIG1lcmVseSBhcyBhbiAiaW1wbGVtZW50YXRpb24iLg0KPiA+DQo+ID4gQWdhaW4s IHRoaXMgaXMgbm90IHdoYXQgSSB3cm90ZS4gIEkgd3JvdGUgdGhhdDoNCj4gPg0KPiA+ICAgIHRo ZSBjbGllbnQgZG9lc24ndCAqbmVjZXNzYXJpbHkqIGhhdmUgdG8ga25vdyBpZiB0aGUgdGhlIGlu dGVyZmFjZXMNCj4gPiAgICBkYXRhIGlzIGltcGxlbWVudGVkIHcvICJwZWVyIG1vdW50IiBvciBz b21lIG90aGVyIG1lY2hhbmlzbS4NCj4gPg0KPiA+IFtub3RlICJuZWNlc3NhcmlseSJdDQo+ID4N Cj4gPiBJIGFncmVlIHRoYXQgKnNvbWUqIGNsaWVudHMgbmVlZCB0byBiZSBhYmxlIHRvIG1hbmFn ZSBtb3VudCB0YXJnZXRzDQo+ID4gZXRjLCBidXQgbm90IGFsbC4NCj4gPg0KPiA+PiBJIHRoaW5r DQo+ID4+IEkgdW5kZXJzdGFuZCB3aGVyZSB5b3UgYXJlIGNvbWluZyBmcm9tIC0gdG8gdGhlIHVz ZXIgb2YgbW91bnRlZCBkYXRhLA0KPiA+PiB0aGV5IGRvbid0IGNhcmUgaWYgdGhlcmUgYXJlIG90 aGVyICJpbnN0YW5jZXMiIG9mIHRoZSBzYW1lIGRhdGEgYW5kDQo+ID4+IGhvdyB0aGUgZGF0YSB0 aGV5IHNlZSBpcyBwb3B1bGF0ZWQuICBUaGF0IHNhaWQsIEkgZG9uJ3QgdGhpbmsgdGhpcw0KPiA+ PiB2aWV3cG9pbnQgaXMgZW50aXJlbHkgY29ycmVjdCwgYmVjYXVzZSB0aGVyZSBhcmUgY2VydGFp biBzZW1hbnRpY3MNCj4gPj4gYXNzb2NpYXRlZCB3aXRoIGl0LCBhbmQgYWxzbyBiZWNhdXNlIHRo ZXJlIGFyZSBkaWZmZXJlbnQgaW1wbGljYXRpb25zDQo+ID4+IHdpdGggcmVnYXJkcyB0byBtb3Vu dHBvaW50IG1hbmFnZW1lbnQgd2hpY2ggbmVlZCB0byBiZSByZWZsZWN0ZWQgaW4NCj4gPj4gdGhl IG1vZGVsLiAgKEZvciBleGFtcGxlLCBmb3IgcGVlci1tb3VudCwgdGhlcmUgbmVlZHMgdG8gYmUN Cj4gPj4gaW5mb3JtYXRpb24gb24gdGhlIHJlbW90ZSBzeXN0ZW0uKQ0KPiA+Pg0KPiA+PiBGb3Ig dGhlIHNlbWFudGljcywgSSB0aGluayB0aGUgZmFjdCBzaG91bGQgYmUgY2FwdHVyZWQgd2hlbiBt b3VudGVkDQo+ID4+IGRhdGEgZGVwZW5kcyBvbiB0YXJnZXQgZGF0YS4gIFdlIGNhcHR1cmUgY29u ZGl0aW9ucyBhbmQgY29uc3RyYWludHMNCj4gPj4gZm9yIHNlbWFudGljYWxseSBhY2N1cmF0ZSBt b2RlbHM7IHRoZSBmYWN0IHRoYXQgdGhlICJhbGlhc2VkIiBkYXRhDQo+ID4+IHJlZmxlY3RzIGFu b3RoZXIgaW5zdGFuY2UgaW4gYW5vdGhlciBzdWJ0cmVlIGlzIHNvbWV0aGluZyB0aGF0IHN1cmUN Cj4gPj4gbmVlZHMgdG8gYmUgY2FwdHVyZWQgYW5kIHVuZGVyc3Rvb2QuDQo+ID4NCj4gPiBJZiB0 aGUgY2xpZW50IGlzIGZ1bGx5IGF3YXJlIG9mIHRoZSBhbGlhcyBtb3VudCBjb25jZXB0LCB3aHkg Ym90aGVyDQo+ID4gd2l0aCBpdD8NCj4gPg0KPiA+IEFzIEkgaGF2ZSBzYWlkIHByZXZpb3VzbHks IHdlICh0YWlsLWYpIGhhdmUgaGFkIGFsaWFzIG1vdW50DQo+ID4gaW1wbGVtZW50ZWQgZm9yIG1h bnkgeWVhcnMgKHdlIGNhbGwgaXQgInN5bWxpbmsiKSwgYW5kIHdlIGhhdmUgYmFkDQo+ID4gZXhw ZXJpZW5jZXMgd2l0aCBhbGwgc2NlbmFyaW9zIGJ1dCB0aGUgdmVyeSBzaW1wbGVzdCBvbmVzIChz aW1wbGUgbGVhZg0KPiA+IHRvIGxlYWYgYWxpYXMpLiAgQW5kIGV2ZW4gaW4gdGhpcyBjYXNlIHVz ZXJzIGdldCBwcmV0dHkgY29uZnVzZWQgYnkNCj4gPiBlcnJvcnMgY2F1c2VkIGJ5IHZhbGlkYXRp b24gdGhhdCBkZXBlbmRzIG9uIHRoZSB0YXJnZXQgbGVhZi4NCj4gPg0KPiA+PiBGb3IgZXhhbXBs ZSwgd2l0aG91dCByZWZsZWN0aW5nDQo+ID4+IHRoaXMgcmVsYXRpb25zaGlwLCBhbiBhcHBsaWNh dGlvbiBtaWdodCB0cnkgdG8gc2V0IGFuIGF1dGhvcml0YXRpdmUNCj4gPj4gc3VidHJlZS9kYXRh bm9kZSB0byBvbmUgdmFsdWUsIHRoZSBtb3VudGVkIHZlcnNpb24gb2YgaXQgdG8gYQ0KPiA+PiBk aWZmZXJlbnQgdmFsdWUuICBTbywgd2hldGhlciBvciBub3QgdGhlcmUgaXMgYW4gYWxpYXMsIG9y IGEgcGVlciwgdG8NCj4gPj4gYW4gaW5zdGFuY2Ugb2YgZGF0YSBpcyBzb21ldGhpbmcgdGhhdCBz aG91bGQgYmUgcmVmbGVjdGVkIGluIHRoZQ0KPiA+PiBtb2RlbC4gIEluIG90aGVyIHdvcmRzLCBJ IGRvbid0IHRoaW5rIHlvdSBjYW4gc2VlIHRoZSBtb3VudHBvaW50IGFuZA0KPiA+PiBkYXRhIG1v dW50ZWQgYmVsb3cgaXQgaW4gZW50aXJlIGlzb2xhdGlvbiBmcm9tIHRoZSByZXN0IG9mIHRoZSBz eXN0ZW0uDQo+ID4+IEFub3RoZXIgcXVlc3Rpb24gY29uY2VybnMgd2hhdCB5b3UgYXJlIGFjdHVh bGx5IG1vdW50aW5nLiAgSW4NCj4gPj4gYWxpYXMtbW91bnQsIHRoZSBtb3VudGVkIHN1YnRyZWUg bWF5IGFjdHVhbGx5IGhhdmUgYmVlbiBhdWdtZW50ZWQgYW5kDQo+ID4+IGhhdmUgb3RoZXIgZGF0 YSBub2RlcyB1bmRlcm5lYXRoIGl0LiAgRG9lcyB0aGUgbW91bnRpbmcgYXBwbHkgdG8gYWxzbw0K PiA+PiBhdWdtZW50aW5nIGRhdGE/ICBGb3Igc3RydWN0dXJhbCBtb3VudCwgdGhlIGFuc3dlciBp cyBjbGVhcmx5ICJubyIsDQo+ID4+IGJ1dCBmb3IgcGVlci1tb3VudCBpdCBkb2Vzbid0IGhhdmUg dG8gYmUuDQo+ID4NCj4gPiBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbi4gIE1heWJl IHlvdSBjYW4gc2hvdyBhbiBleGFtcGxlPw0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ID4NCj4g Pg0KPiA+Pg0KPiA+PiAtLS0gQWxleA0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIExhZGlzbGF2DQo+ID4+IExob3RrYQ0KPiA+PiBTZW50OiBUdWVz ZGF5LCBBcHJpbCAwNSwgMjAxNiA0OjU3IEFNDQo+ID4+IFRvOiBNYXJ0aW4gQmrDtnJrbHVuZCA8 bWJqQHRhaWwtZi5jb20+DQo+ID4+IENjOiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDog UmU6IFtuZXRtb2RdIGt3IGNvbW1lbnRzIG9uDQo+ID4+IGRyYWZ0LXZvaXQtbmV0bW9kLXlhbmct bW91bnQtcmVxdWlyZW1lbnRzDQo+ID4+DQo+ID4+DQo+ID4+ID4gT24gMDUgQXByIDIwMTYsIGF0 IDA2OjM4LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+ID4+ID4N Cj4gPj4gPiBIaSwNCj4gPj4gPg0KPiA+PiA+IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIu bmV0PiB3cm90ZToNCj4gPj4gPj4gW0FzIGEgY29udHJpYnV0b3JdDQo+ID4+ID4+DQo+ID4+ID4+ IE5vdGU6IHRoaXMgaXMgYSAtMDAgZG9jdW1lbnQsIGJ1dCBvbmx5IGJlY2F1c2UgdGhlIGRyYWZ0 J3MgbmFtZQ0KPiA+PiA+PiBjaGFuZ2VkLiAgSW4gcmVhbGl0eSB0aGlzIGlzIGxpa2UgYQ0KPiA+ PiA+PiBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wNC4gIExvb2tp bmcgYXQgdGhlDQo+ID4+ID4+IGRpZmZzLCB0aGVyZSBhcmVuJ3QgbWFueSBjaGFuZ2VzLCBtb3N0 bHkgY2xlYW51cCBhbmQgYWRkaW5nIHRoZQ0KPiA+PiA+PiAic2NoZW1hIG1vdW50IiBjb25jZXB0 LiAgVGhhdCBpcywgdGhlIG5ldyAieWFuZyBtb3VudCIgdGVybSBpcyB1c2UNCj4gPj4gPj4gdG8g Y292ZXIgYWxsIG9mICJzY2hlbWEgbW91bnQiLCAiYWxpYXMgbW91bnQiLCBhbmQgInBlZXIgbW91 bnQiLg0KPiA+PiA+Pg0KPiA+PiA+PiBNeSBjb21tZW50IGlzIG1vc3RseSBoaWdoLWxldmVsLiAg SSdtIHdvbmRlcmluZyBhYm91dCB0aGUgbmVlZCBmb3INCj4gPj4gPj4gdGhpcyBkcmFmdCB0byBp bmNsdWRlIHNjaGVtYSBtb3VudCBhdCBhbGwuICBUaGF0IGlzLCBhIHNjaGVtYQ0KPiA+PiA+PiBt b3VudCBzb2x1dGlvbiBkcmFmdCBpcyBub3cgYW4gYWRvcHRlZCBXRyBpdGVtLCBhbmQgSSdtIHVu c3VyZSBpZg0KPiA+PiA+PiB0aGUgYXV0aG9ycyBvZiB0aGF0IGRyYWZ0IGFyZSBsb29raW5nIHRv IHRoaXMgb25lIHRvIGRlZmluZSByZXF1aXJlbWVudHMuDQo+ID4+ID4+IFBlcmhhcHMgdGhlIGdv YWwgaXMgdG8gZGVmaW5lIHRoZSB1bWJyZWxsYSB0ZXJtICJ5YW5nIG1vdW50IiwgYnV0DQo+ID4+ ID4+IHRvIGJlIGhvbmVzdCwgSSBkb24ndCByZWFsbHkgc2VlIGEgbmVlZCB0byBoYXZlIGEgdGVy bSB0aGF0IHNwYW5zDQo+ID4+ID4+IGJvdGggc2NoZW1hIGFuZCBkYXRhIG1vdW50cy4gIEknbSBu b3Qgc3VyZSBob3cgb3RoZXJzIGZlZWwgYWJvdXQNCj4gPj4gPj4gdGhpcywgYnV0IG15IHRob3Vn aHRzIGFyZSB0aGF0IHdlIHNob3VsZCBkZWZpbmUgdGVybXMgbGlrZToNCj4gPj4gPj4NCj4gPj4g Pj4gLSBzY2hlbWUtbW91bnQNCj4gPj4gPj4gLSBkYXRhLW1vdW50DQo+ID4+ID4+IC0gcmVtb3Rl IGRhdGEgbW91bnQgICAoYS5rLmEuIHBlZXIgbW91bnQpDQo+ID4+ID4+IC0gbG9jYWwgZGF0YSBt b3VudCAgICAgICAgKGEuay5hLiBhbGlhcyBtb3VudCkNCj4gPj4gPj4NCj4gPj4gPj4gTW9yZSBz byB0aGFuOg0KPiA+PiA+Pg0KPiA+PiA+PiB5YW5nLW1vdW50DQo+ID4+ID4+IC0gc2NoZW1lLW1v dW50DQo+ID4+ID4+IC0gYWxpYXMtbW91bnQNCj4gPj4gPj4gLSBwZWVyLW1vdW50DQo+ID4+ID4N Cj4gPj4gPiBMaXN0ZW5pbmcgdG8gRXJpYydzIHByZXNlbnRhdGlvbiB5ZXN0ZXJkYXksIEkgcmVh bGl6ZWQgdGhhdCBJIGhhdmUNCj4gPj4gPiBhIHNsaWdodGx5IGRpZmZlcmVudCB2aWV3IG9uIHRo ZXNlIHRlcm1zLg0KPiA+PiA+DQo+ID4+ID4gSSBwcmVmZXIgdG8gc2VwYXJhdGUgdGhlICpzY2hl bWEqIChkYXRhIG1vZGVsKSBmcm9tIGhvdyB0aGluZ3MgYXJlDQo+ID4+ID4gaW1wbGVtZW50ZWQu ICBUaGUgdmFyaW91cyBwcm9wb3NhbHMgZm9yIHNwZWNpZmljIGltcGxlbWVudGF0aW9ucw0KPiA+ PiA+IChwZWVyDQo+ID4+DQo+ID4+IFllcywgSSBleHByZXNzZWQgdGhpcyBvcGluaW9uIGFscmVh ZHkgaW4gWW9rb2hhbWEuIE1vcmVvdmVyLCBFbGlvdCdzDQo+ID4+IHByZXNlbnRhdGlvbiBpbmRp Y2F0ZWQgdGhhdCB0aGVyZSBhcmUgdXNlIGNhc2VzIGluIHdoaWNoIFlBTkcgaXMgdXNlZA0KPiA+ PiBmb3IgbW9kZWxsaW5nIGRhdGEgb3V0c2lkZSB0aGUgY29udGV4dCBvZiBhIG1hbmFnZW1lbnQg cHJvdG9jb2wuIFNvDQo+ID4+IElNTyBpdCBpcyBsZWdpdGltYXRlIHRvIHJlcXVpcmUgdGhhdCBl dmVuIHdpdGggc2NoZW1hIG1vdW50IGl0IGlzDQo+ID4+IHBvc3NpYmxlIHRvIHdyaXRlIGEgY29t cGFjdCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBjb21wbGV0ZSBzY2hlbWEuDQo+ID4+IFN1Y2ggYSBz Y2hlbWEgaXMgc3RhdGljIGFzIGJlZm9yZSwgdGhlIG9ubHkgY2hhbmdlIGlzIHRoYXQgd2UgaGF2 ZQ0KPiA+PiBtb3JlIGZsZXhpYmlsaXR5IGluIGNvbXBvc2luZyB0aGUgbW9kdWxlcywgd2hlcmVh cyBjdXJyZW50bHkgdGhleSBjYW4NCj4gPj4gYmUgb25seSBwdXQgc2lkZSBieSBzaWRlLiBBbHNv LCB0aGVyZSBuZWVkbid0IGJlIGFueSBtZWNoYW5pc20gbGlrZQ0KPiA+PiBwZWVyIG1vdW50LCBh bGwgZGF0YSBtYXkgYmUgbG9jYWwuDQo+ID4+DQo+ID4+IFBlcmhhcHMgdGhpcyB1c2UgY2FzZSBp cyByZWFsbHkgZGlmZmVyZW50IGZyb20gdGhlIG1vcmUgZHluYW1pYw0KPiA+PiBzaXR1YXRpb24g d2hlcmUgdGhlIHNlcnZlciBuZWVkcyB0byBmZXRjaCB0aGUgc3Vic2NoZW1hcyBhdCBydW50aW1l DQo+ID4+IGFuZCB0aGUgZGF0YSBhcmUgY29udHJpYnV0ZWQgYnkgYW4gZXh0ZXJuYWwgZW50aXR5 Lg0KPiA+Pg0KPiA+PiBMYWRhDQo+ID4+DQo+ID4+ID4gbW91bnQgYW5kIGFsaWFzIG1vdW50IGV0 YykgYWxsIG5lZWQgYSAic2NoZW1hIG1vdW50IiB0byB0YWtlIG9mDQo+ID4+ID4gZGVmaW5pbmcg YSBwcm9wZXIgZGF0YSBtb2RlbC4gICAoVGhpcyB3YXMgdGhlIHdob2xlIHBvaW50IG9mIGRlZmlu aW5nDQo+ID4+ID4gc3RydWN0dXJhbC1tb3VudC4uLikNCj4gPj4gPg0KPiA+PiA+IEZvciBleGFt cGxlLCBzdXBwb3NlIHdlIGhhdmU6DQo+ID4+ID4NCj4gPj4gPiAgY29udGFpbmVyIGxvZ2ljYWwt ZGV2aWNlcyB7DQo+ID4+ID4gICAgbGlzdCBsb2dpY2FsLWRldmljZSB7DQo+ID4+ID4gICAgICBr ZXkgbmFtZTsNCj4gPj4gPiAgICAgIC4uLg0KPiA+PiA+ICAgICAgeWFuZ21udDptb3VudC1wb2lu dCBsb2dpY2FsLWRldmljZTsNCj4gPj4gPiAgICB9DQo+ID4+ID4gIH0NCj4gPj4gPg0KPiA+PiA+ IFdpdGggdGhlIGFzc29jaWF0ZWQgeWFuZy1saWJyYXJ5LCBhIGNsaWVudCBtaWdodCBsZWFybiB0 aGF0DQo+ID4+ID4gaWV0Zi1pbnRlcmZhY2VzIGlzIG1vdW50ZWQgdW5kZXIgdGhlICJsb2dpY2Fs LWRldmljZSIgbW91bnQgbW91bnQuDQo+ID4+ID4NCj4gPj4gPiBOb3csIHRoZSBjbGllbnQga25v d3MgdGhhdCB0aGVyZSBhcmUgcGF0aHM6DQo+ID4+ID4NCj4gPj4gPiAgL2xvZ2ljYWwtZGV2aWNl cy9sb2dpY2FsLWRldmljZS9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZQ0KPiA+PiA+DQo+ID4+ ID4gYnV0IHRoZSBjbGllbnQgZG9lc24ndCBuZWNlc3NhcmlseSBoYXZlIHRvIGtub3cgaWYgdGhl IHRoZQ0KPiA+PiA+IGludGVyZmFjZXMgZGF0YSBpcyBpbXBsZW1lbnRlZCB3LyAicGVlciBtb3Vu dCIgb3Igc29tZSBvdGhlciBtZWNoYW5pc20uDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IFNvLCBp biBteSB2aWV3LCB3ZSBoYXZlOg0KPiA+PiA+DQo+ID4+ID4gIHNjaGVtYSBtb3VudA0KPiA+PiA+ ICAgICAgfA0KPiA+PiA+ICAgICAgKy0tLS0gcGVlciBtb3VudA0KPiA+PiA+ICAgICAgKy0tLS0g YWxpYXMgbW91bnQNCj4gPj4gPiAgICAgICstLS0tIG90aGVyIGNvb2wgbW91bnQNCj4gPj4gPg0K PiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBBcyBhIGNvbmNyZXRlIGV4YW1wbGUsIHBlZXIgbW91bnQg bWlnaHQgYmUgdXNlZCBsaWtlIHRoaXMgKGV4YW1wbGUNCj4gPj4gPiB0YWtlbiBmcm9tIGRyYWZ0 LWNsZW1tLW5ldG1vZC1tb3VudC0wMyk6DQo+ID4+ID4NCj4gPj4gPiAgIGltcG9ydCBpZXRmLXNj aGVtYS1tb3VudCB7DQo+ID4+ID4gICAgIHByZWZpeCB5YW5nbW50Ow0KPiA+PiA+ICAgfQ0KPiA+ PiA+ICAgaW1wb3J0IGlldGYtcGVlci1tb3VudCB7DQo+ID4+ID4gICAgIHByZWZpeCBwbW50Ow0K PiA+PiA+ICAgfQ0KPiA+PiA+DQo+ID4+ID4gICAuLi4NCj4gPj4gPg0KPiA+PiA+ICAgbGlzdCBu ZXR3b3JrLWVsZW1lbnQgew0KPiA+PiA+ICAgICBrZXkgImVsZW1lbnQtaWQiOw0KPiA+PiA+ICAg ICBsZWFmIGVsZW1lbnQtaWQgew0KPiA+PiA+ICAgICAgIHR5cGUgZWxlbWVudC1JRDsNCj4gPj4g PiAgICAgfQ0KPiA+PiA+ICAgICBjb250YWluZXIgZWxlbWVudC1hZGRyZXNzIHsNCj4gPj4gPiAg ICAgICAuLi4gLy8gY2hvaWNlIGRlZmluaXRpb24gdGhhdCBhbGxvd3MgdG8gc3BlY2lmeQ0KPiA+ PiA+ICAgICAgICAgICAvLyBob3N0IG5hbWUsDQo+ID4+ID4gICAgICAgICAgIC8vIElQIGFkZHJl c3NlcywgVVJJcywgZXRjDQo+ID4+ID4gICAgIH0NCj4gPj4gPiAgICAgeWFuZ21udDptb3VudC1w b2ludCAiaW50ZXJmYWNlcyIgew0KPiA+PiA+ICAgICAgIHBtbnQ6dGFyZ2V0ICIuL2VsZW1lbnQt YWRkcmVzcyI7DQo+ID4+ID4gICAgICAgcG1udDpzdWJ0cmVlICIvaWY6aW50ZXJmYWNlcyI7DQo+ ID4+ID4gICAgIH0NCj4gPj4gPiAgICAgLi4uDQo+ID4+ID4gICB9DQo+ID4+ID4NCj4gPj4gPg0K PiA+PiA+IEEgY2xpZW50IHRoYXQga25vd3MgYWJvdXQgdGhlIGdlbmVyaWMsIGFic3RyYWN0IHNj aGVtYSBtb3VudCBjYW4NCj4gPj4gPiB3b3JrIHdpdGggdGhpcywgd2l0aG91dCBrbm93aW5nIGFu eXRoaW5nIG9mIHRoZSBzcGVjaWZpYw0KPiA+PiA+IGltcGxlbWVudGF0aW9uIG9mIHBlZXIgbW91 bnQuDQo+ID4+ID4NCj4gPj4gPiBbQWN0dWFsbHksIHNpbmNlIHBlZXIgbW91bnQgaXMganVzdCBv bmUgaW1wbGVtZW50YXRpb24gdGVjaG5pcXVlLA0KPiA+PiA+IEknZCBwcmVmZXIgdG8gZGVjb3Vw bGUgdGhlIGRlZmluaXRpb24gb2YgdGhpcyBpbXBsZW1lbnRhdGlvbiBkZXRhaWwNCj4gPj4gPiBm cm9tIHRoZSBkYXRhIG1vZGVsLCBidXQgdGhhdCdzIGEgZGlmZmVyZW50IHRvcGljLl0NCj4gPj4g Pg0KPiA+PiA+DQo+ID4+ID4gL21hcnRpbg0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPiBuZXRtb2QgbWFpbGluZyBs aXN0DQo+ID4+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPj4NCj4gPj4gLS0NCj4gPj4gTGFkaXNsYXYgTGhv dGthLCBDWi5OSUMgTGFicw0KPiA+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+IG5ldG1vZEBpZXRmLm9yZw0K PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+Pg0K PiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElEOiBF NzRFOEMwQw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Thu Apr 7 23:57:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D420B12D1BA for ; Thu, 7 Apr 2016 23:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jwlm44WUoph for ; Thu, 7 Apr 2016 23:57: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 97B5C12D10A for ; Thu, 7 Apr 2016 23:57: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 E9AC6222A; Fri, 8 Apr 2016 08:57: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 oUuoO6smA-la; Fri, 8 Apr 2016 08:57: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; Fri, 8 Apr 2016 08:57:51 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5815220045; Fri, 8 Apr 2016 08:57:51 +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 Lt5dnO2RScdf; Fri, 8 Apr 2016 08:57: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 355C220043; Fri, 8 Apr 2016 08:57:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 19F833A752F8; Fri, 8 Apr 2016 08:57:48 +0200 (CEST) Date: Fri, 8 Apr 2016 08:57:48 +0200 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20160408065748.GA66159@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , Martin Bjorklund , "kwatsen@juniper.net" , "Alexander Clemm (alex)" , "netmod@ietf.org" References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 06:57:56 -0000 On Fri, Apr 08, 2016 at 02:20:19AM +0000, Eric Voit (evoit) wrote: > My thinking matches more closely to what Kent lays out above: > > schema-mount > data-mount > remote data mount (a.k.a. peer mount) > local data mount (a.k.a. alias mount) > > The value in the term "yang mount" is that it provides a conceptual umbrella to ensure a cohesive syntax across the four valid permutations of the above. The term itself was never intended to be implementable. > So why do we need 'local data mount' (aka 'alias mount')? Which problem does it solve that 'peer mounting' localhost does not solve? /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 Apr 8 00:07:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D50C12D1EA for ; Fri, 8 Apr 2016 00:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drzs2UTYBsqf for ; Fri, 8 Apr 2016 00:07:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197E412D0B7 for ; Fri, 8 Apr 2016 00:07:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D547E222A; Fri, 8 Apr 2016 09:07:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id P8IpZKky0RAG; Fri, 8 Apr 2016 09:07:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Apr 2016 09:07:40 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D160E20045; Fri, 8 Apr 2016 09:07:40 +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 x46NMwMNY-0S; Fri, 8 Apr 2016 09:07:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9A2F20043; Fri, 8 Apr 2016 09:07:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BF7183A7535A; Fri, 8 Apr 2016 09:07:37 +0200 (CEST) Date: Fri, 8 Apr 2016 09:07:37 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20160408070737.GB66159@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , "Carl Moberg (camoberg)" , "Scharf, Michael (Nokia - DE)" , "netmod@ietf.org" References: <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 07:07:45 -0000 Yes, the boundaries are blurry and it does not matter which layering model you use. M.3010 does not change the fact that boundaries are blurry. I think it is not a problem. My understanding was that the I-D primarily aims at establish a common vocabulary and it should IMHO explicitely state that boundaries are blurry and that the main purpose is to simplify 'human communication'. The classification is not for 'implementation'. /js On Thu, Apr 07, 2016 at 04:43:51PM +0000, Alexander Clemm (alex) wrote: > I am wondering what purpose the classification really serves. At the end of the day, it seems to me that we are trying to express a model hierarchy, and articulate what the layers in the hierarchy are. A device model is thus at a lower layer than a service model. An implementation of the service model may in turn have dependencies on the device model, but not the other way round. > > Where the models are instantiated - on a controller, on a "device", etc - seems to be secondary and incidental. The boundaries are blurry, anyways. A controller is a device too; some devices may contain virtualized controllers, and so on. > > One model that is relevant in this discussion seems to be the TMN model, as defined in ITU-T Recommendation M.3010. This model defines a set of management layers - network element (device), network, service, business - with well defined funcional scope of each layer. The layers / function hierarchy also imply an information and data model hierarchy. > > Would it make sense to see if the layering in M.3010 could help guide YANG model classification, and reference those definitions? > > --- Alex > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Carl Moberg (camoberg) > Sent: Thursday, April 07, 2016 1:57 AM > To: Scharf, Michael (Nokia - DE) > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG model classification? > > > > -- > Carl Moberg > Technology Director, CVG > camoberg@cisco.com > > > On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) wrote: > > > >> I come at this from the classification angle, so my interest is if > >> the assumption that a YANG model can only be classified as a network > >> service model XOR a network device model according to the definitions > >> in draft-ietf-netmod-yang-model-classification (sections 2.1 and > >> 2.2). Based on this discussion I take it that some models are intended to be able to serve in both roles. And we should make sure that it’s supported in our catalog structure. > > > > Regarding the XOR assumption for classification: > > > > You may also want to think about YANG models that are NEITHER device NOR service models. For instance, what about RFC 6991? And I think other, more technical models presented this week may fall into a similar category ("generic"?). > > Very good point, thanks! That will need some additional thinking and writing. > _______________________________________________ > 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 Fri Apr 8 03:53:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAD412D0A5 for ; Fri, 8 Apr 2016 03:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-gK51jiTKHh for ; Fri, 8 Apr 2016 03:53:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC1012D6BD for ; Fri, 8 Apr 2016 03:53:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F553E7C; Fri, 8 Apr 2016 12:53:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QFo8jMdmcKhz; Fri, 8 Apr 2016 12:52:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Apr 2016 12:53:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DB682004A; Fri, 8 Apr 2016 12:53:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O_wqKbmN0GuF; Fri, 8 Apr 2016 12:53: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 D6C332004E; Fri, 8 Apr 2016 12:53:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A77EB3A756ED; Fri, 8 Apr 2016 12:53:14 +0200 (CEST) Date: Fri, 8 Apr 2016 12:53:14 +0200 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20160408105312.GA66692@elstar.local> Mail-Followup-To: Per Hedeland , netmod@ietf.org References: <57068E81.9080902@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57068E81.9080902@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Description of the "prefix" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 10:53:24 -0000 On Thu, Apr 07, 2016 at 06:44:49PM +0200, Per Hedeland wrote: > Hi, > > I "happened" to read "7.1.4. The prefix Statement" in RFC 6020, and > found this strange statement: > > When used inside the "module" statement, the "prefix" statement > defines the prefix to be used when this module is imported. > > This is obviously not correct (it would effectively require prefixes to > be unique across all modules) - the prefix used when the module is > imported is completely up to the author of the importing module. I guess > it hasn't caused any great harm, but I think it would be a good idea to > remove this statement from 6020bis (it is the same there), if it isn't > too late. > As far as I recall, The original intention was this: s/to be used/suggested to be used/ The main idea is to improve human readability by using common prefixes unless there are reasons to deviate from using the suggested prefix. /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 Apr 8 04:04:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9390C12D0B6 for ; Fri, 8 Apr 2016 04:04: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm9p7DwrDzRX for ; Fri, 8 Apr 2016 04:04: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 E19A912D8BD for ; Fri, 8 Apr 2016 04:03:02 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 225FD1AE0442; Fri, 8 Apr 2016 13:03:01 +0200 (CEST) Date: Fri, 08 Apr 2016 13:03:00 +0200 (CEST) Message-Id: <20160408.130300.191730724620478182.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160408105312.GA66692@elstar.local> References: <57068E81.9080902@tail-f.com> <20160408105312.GA66692@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Description of the "prefix" statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 11:04:32 -0000 Juergen Schoenwaelder wrote: > On Thu, Apr 07, 2016 at 06:44:49PM +0200, Per Hedeland wrote: > > Hi, > > > > I "happened" to read "7.1.4. The prefix Statement" in RFC 6020, and > > found this strange statement: > > > > When used inside the "module" statement, the "prefix" statement > > defines the prefix to be used when this module is imported. > > > > This is obviously not correct (it would effectively require prefixes to > > be unique across all modules) - the prefix used when the module is > > imported is completely up to the author of the importing module. I guess > > it hasn't caused any great harm, but I think it would be a good idea to > > remove this statement from 6020bis (it is the same there), if it isn't > > too late. > > > > As far as I recall, The original intention was this: > > s/to be used/suggested to be used/ I agree this was the intention. > The main idea is to improve human readability by using common prefixes > unless there are reasons to deviate from using the suggested prefix. /martin From nobody Fri Apr 8 05:20:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C6812D790 for ; Fri, 8 Apr 2016 05:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or3e-kxcmpep for ; Fri, 8 Apr 2016 05:20:45 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6D312D6F2 for ; Fri, 8 Apr 2016 05:20:43 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 5F26841D1C335; Fri, 8 Apr 2016 12:20:39 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u38CKfSp014511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 12:20:42 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u38CKfW2023099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 12:20:41 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.144]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 8 Apr 2016 08:20:41 -0400 From: "Sterne, Jason (Nokia - CA)" To: EXT Dean Bogdanovic , netmod WG Thread-Topic: [netmod] input Interface match Thread-Index: AQHRkNdAKWgKnh2rd02iJeaRF4Zhtp9//bKA Date: Fri, 8 Apr 2016 12:20:40 +0000 Message-ID: References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> In-Reply-To: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CC2B0C1US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] input Interface match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:20:48 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CC2B0C1US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dean, Just to clarify -> the main question posed in the WG meeting was about the = input-interface match criteria. From the meeting minutes: Chairs: call for if interface should be in base: 6 prefer NOT having it in the doc at all 5 prefer having it in, but as a feature 2 prefer having it in the doc as required Maybe we should get agreement on what to do about input-interface (on the l= ist) first and then we can figure out what to do about the metadata groupin= g. Matching on basic IPv4/IPv4/MAC header fields is common functionality. But= having that input-interface match on metadata in the core model is out of = place. It should be left to further extension drafts or vendor specific au= gmentations (along with whatever other metadata might be useful or vendor-s= pecific). Many major implementations do not support matching on input-inter= face (Cisco IOS-XR, Nokia SR OS, Brocade, others). The typical way to asso= ciate ACLs and Interfaces is by assigning an ACL to an interface as shown i= n section A.3. of the ACL draft. There is some discussion of this on the = NETMOD thread "Remove input-interface (metadata) from netmod-acl-model-07 ?= ". Regards, Jason From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Dean Bogdano= vic Sent: Thursday, April 07, 2016 11:12 To: netmod WG Subject: [netmod] input Interface match As the action item from the netmod WG and, hopefully, last open item in the= ACL draft is the leaf input interface in the metadata grouping grouping metadata { description "Fields associated with a packet which are not in the header."; leaf input-interface { type if:interface-ref { require-instance false; } description "Packet was received on this interface."; } } } Here are two questions: One Do want to have a metadata grouping in the basic ACL model? If yes, we have= to put in some leafs in there. There are implementations which use metadat= a as match condition If we agree that metadata grouping is not needed in the basic model, then t= he authors would remove the grouping from the model and I believe that no m= ore discussion is needed on this point Dean --_000_A125E53CE190A749957C19483DC79F9F5CC2B0C1US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dean,

 <= /p>

Just to clarify -> the= main question posed in the WG meeting was about the input-interface match = criteria.  From the meeting minutes:

 <= /p>

Chairs: call for if inter= face should be in base:

    6 pref= er NOT having it in the doc at all

    5 pref= er having it in, but as a feature

    2 pref= er having it in the doc as required

 <= /p>

Maybe we should get agree= ment on what to do about input-interface (on the list) first and then we ca= n figure out what to do about the metadata grouping.

 <= /p>

Matching on basic IPv4/IP= v4/MAC header fields is common functionality.  But having that input-i= nterface match on metadata in the core model is out of place.  It should be left to further extension drafts or vendor specific augmentat= ions (along with whatever other metadata might be useful or vendor-specific= ). Many major implementations do not support matching on input-interface (C= isco IOS-XR, Nokia SR OS, Brocade, others).  The typical way to associate ACLs and Interfaces is by assi= gning an ACL to an interface as shown in section A.3. of the ACL draft.&nbs= p;  There is some discussion of this on the NETMOD thread “Remov= e input-interface (metadata) from netmod-acl-model-07 ?”.

 <= /p>

Regards,

Jason

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of EXT Dean Bogdanovic
Sent: Thursday, April 07, 2016 11:12
To: netmod WG
Subject: [netmod] input Interface match

 

As the action item from the netmod WG and, hopefully= , last open item in the ACL draft is the leaf input interface in the metada= ta grouping 

 

grouping metadata {

    description=



      &quo=
t;Fields associated with a packet which are not in


      the =
header.";


    leaf input-inter=
face {


      type=
 if:interface-ref {


      =
;  require-instance false;


      }


      desc=
ription


      =
;  "Packet was received on this interface.";

    }

  }


}




 

 

Here are two questions:

One

Do want to have a metadata grouping in the basic ACL= model? If yes, we have to put in some leafs in there. There are implementa= tions which use metadata as match condition

 

If we agree that metadata grouping is not needed in = the basic model, then the authors would remove the grouping from the model = and I believe that no more discussion is needed on this point

 

Dean

 

--_000_A125E53CE190A749957C19483DC79F9F5CC2B0C1US70TWXCHMBA11z_-- From nobody Fri Apr 8 05:23:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A1F12D7F0 for ; Fri, 8 Apr 2016 05:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k32uOxZicVy2 for ; Fri, 8 Apr 2016 05:23:51 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78D712D7E9 for ; Fri, 8 Apr 2016 05:23:51 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f105so64753874qge.2 for ; Fri, 08 Apr 2016 05:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=sKDKedGXgKoYdcXY10bksyTbnCiBywIAR0MGWjWPmt8=; b=SaxSxsCW6X+mOTCV1LPxR5Yb68+L5eRnB6iIsKBGVxCl+8EJXG/NzPOXJWdQJw5U1Z HqC45nnTr7W0sX/RXdbR5EEptRra8oIma0RWYjzjR//rjuS1Au4e1Joeoi9y6P7MJRui f4WGvEgMliabhjZaf91F/SzAZrQmBO89DVt/KkcDzLaY2lacrGY6Hx/oWdOsqTMEgSpA PlFBvTlDAGmU1NdbUTMdItnrGFcTRfXRFU0z/bA3vs3JFSIvr6SDH9J9jGlsEg+s7ujz Rx8vAvW2YLYtZwTzWxtce/S5kpocyb2WySkckuVV4cYzDAzBTcYluADZ6e2R3oyL7fhR BhFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=sKDKedGXgKoYdcXY10bksyTbnCiBywIAR0MGWjWPmt8=; b=lCkkyAeVoW1cD6dgRe5XLPRgNrcOP+Qla7W50B6oN9FEvqZOuHsAAeHjo0WhwtrjT4 pXhymXmmMHuBkFlE9BCv+IiFxgjmbSMe28dCT0NnOfhdp5EYhF0xFzR+SCwkbvSnnwn0 EZM9sFbBvlHARjWkldjxIUolgL64FRYmj8EM2r2iXLPGeiCmVI1UDSvNDcc6Ygf0QSXF Ge0nchxmbOGN0nz9h/b2kBI+lavPJ2s6gRcAM8fKI3ymyvp3kfYMw/4/ylJMiVYteXzQ bK+hIfrhZbO80RcVpPprXEpINMi2N9XwEozmV7CMwMMIV1kbQS8/r8Tr2stIbfHlkdk4 hWiA== X-Gm-Message-State: AD7BkJKeWkmXyE/EFQrjA47g9LYPOqxj7QfOhdZNBVz++SGvwfAwaM2te0PRrayZGsE1Rg== X-Received: by 10.140.218.134 with SMTP id o128mr11215151qhb.33.1460118230778; Fri, 08 Apr 2016 05:23:50 -0700 (PDT) Received: from [172.16.1.10] ([200.61.9.66]) by smtp.gmail.com with ESMTPSA id o83sm5331991qho.47.2016.04.08.05.23.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 05:23:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BAE936FA-672E-456E-8E45-5B5A74748647" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: Date: Fri, 8 Apr 2016 09:25:17 -0300 Message-Id: <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com> References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> To: "Sterne, Jason (Nokia - CA)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: netmod WG Subject: Re: [netmod] input Interface match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:23:53 -0000 --Apple-Mail=_BAE936FA-672E-456E-8E45-5B5A74748647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jason, After looking at the document and the model, it is also about having = metadata grouping in the model. If you want to have metadata grouping in = the model, then you have to have something inside and then = input-interface questions comes up. If you don=E2=80=99t have to have = metadata grouping in the base model, everything is easy. I believe this is the right question Dean > On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) = wrote: >=20 > Hi Dean, > =20 > Just to clarify -> the main question posed in the WG meeting was about = the input-interface match criteria. =46rom the meeting minutes: > =20 > Chairs: call for if interface should be in base: > 6 prefer NOT having it in the doc at all > 5 prefer having it in, but as a feature > 2 prefer having it in the doc as required > =20 > Maybe we should get agreement on what to do about input-interface (on = the list) first and then we can figure out what to do about the metadata = grouping. > =20 > Matching on basic IPv4/IPv4/MAC header fields is common functionality. = But having that input-interface match on metadata in the core model is = out of place. It should be left to further extension drafts or vendor = specific augmentations (along with whatever other metadata might be = useful or vendor-specific). Many major implementations do not support = matching on input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, = others). The typical way to associate ACLs and Interfaces is by = assigning an ACL to an interface as shown in section A.3. of the ACL = draft. There is some discussion of this on the NETMOD thread =E2=80=9CRe= move input-interface (metadata) from netmod-acl-model-07 ?=E2=80=9D. > =20 > Regards, > Jason > =20 > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of EXT Dean = Bogdanovic > Sent: Thursday, April 07, 2016 11:12 > To: netmod WG > Subject: [netmod] input Interface match > =20 > As the action item from the netmod WG and, hopefully, last open item = in the ACL draft is the leaf input interface in the metadata grouping=20 > =20 > grouping metadata { > description > "Fields associated with a packet which are not in > the header."; > leaf input-interface { > type if:interface-ref { > require-instance false; > } > description > "Packet was received on this interface."; > } > } > } > =20 > =20 > Here are two questions: > One > Do want to have a metadata grouping in the basic ACL model? If yes, we = have to put in some leafs in there. There are implementations which use = metadata as match condition > =20 > If we agree that metadata grouping is not needed in the basic model, = then the authors would remove the grouping from the model and I believe = that no more discussion is needed on this point > =20 > Dean --Apple-Mail=_BAE936FA-672E-456E-8E45-5B5A74748647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jason,

After looking at the document and the model, it is also about = having metadata grouping in the model. If you want to have metadata = grouping in the model, then you have to have something inside and then = input-interface questions comes up. If you don=E2=80=99t have to have = metadata grouping in the base model, everything is easy.

I believe this is the = right question

Dean

On Apr 8, 2016, at 9:20 AM, = Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:

Hi = Dean,
 
Just to clarify -> = the main question posed in the WG meeting was about the input-interface = match criteria.  =46rom the meeting minutes:
 
Chairs: call for if = interface should be in base:
    6 prefer NOT having it in the doc at = all
    5 = prefer having it in, but as a feature
    2 prefer having it in = the doc as required
 
Maybe we should get = agreement on what to do about input-interface (on the list) first and = then we can figure out what to do about the metadata grouping.
 
Matching on basic = IPv4/IPv4/MAC header fields is common functionality.  But having = that input-interface match on metadata in the core model is out of = place.  It should be left to further extension drafts or vendor = specific augmentations (along with whatever other metadata might be = useful or vendor-specific). Many major implementations do not support = matching on input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, = others).  The typical way to associate ACLs and Interfaces is by = assigning an ACL to an interface as shown in section A.3. of the ACL = draft.   There is some discussion of this on the NETMOD thread = =E2=80=9CRemove input-interface (metadata) from netmod-acl-model-07 = ?=E2=80=9D.
 
Regards,
Jason
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf = Of EXT Dean = Bogdanovic
Sent: Thursday, April 07, 2016 = 11:12
To: netmod WG
Subject: [netmod] input Interface = match
 
As the action item from the netmod WG and, hopefully, = last open item in the ACL draft is the leaf input interface in the = metadata grouping 
 
grouping metadata {
    description
      "Fields associated with a =
packet which are not in
      =
the header.";
    leaf =
input-interface {
      =
type if:interface-ref {
        require-instance =
false;
      =
}
      description
        "Packet was =
received on this interface.";
    =
}
  }
}
 
 
Here are two questions:
One
Do want to have a metadata grouping in = the basic ACL model? If yes, we have to put in some leafs in there. = There are implementations which use metadata as match condition
 
If we agree that metadata grouping is not = needed in the basic model, then the authors would remove the grouping = from the model and I believe that no more discussion is needed on this = point
 
Dean

= --Apple-Mail=_BAE936FA-672E-456E-8E45-5B5A74748647-- From nobody Fri Apr 8 05:26:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567C412D70C for ; Fri, 8 Apr 2016 05:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltXn3M2nhajP for ; Fri, 8 Apr 2016 05:25:59 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9657912D837 for ; Fri, 8 Apr 2016 05:25:59 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 0306E566C5F7F; Fri, 8 Apr 2016 12:25:57 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u38CPwmT028276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 12:25:58 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u38CPwcP003052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 12:25:58 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.144]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 8 Apr 2016 08:25:58 -0400 From: "Sterne, Jason (Nokia - CA)" To: EXT Dean Bogdanovic Thread-Topic: [netmod] input Interface match Thread-Index: AQHRkNdAKWgKnh2rd02iJeaRF4Zhtp9//bKAgABHGID//7zI4A== Date: Fri, 8 Apr 2016 12:25:57 +0000 Message-ID: References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com> In-Reply-To: <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CC2B0EEUS70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] input Interface match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:26:01 -0000 --_000_A125E53CE190A749957C19483DC79F9F5CC2B0EEUS70TWXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVhbiwNCg0KV2Ugc2hvdWxkIHJlbW92ZSB0aGUgbWV0YWRhdGEgZ3JvdXBpbmcgZnJvbSB0 aGUgYmFzZSBtb2RlbC4gIEl0IGlzIG91dCBvZiBwbGFjZSB3aXRoIHRoZSByZXN0IG9mIHRoZSBt b2RlbCBhbmQgYSBmYWlybHkgY2xlYW4gbGluZSB0byBkcmF3IGFzIGEgYm91bmRhcnkgZm9yIGZ1 dHVyZSBleHRlbnNpb24vYXVnbWVudGF0aW9uLg0KDQpSZWdhcmRzLA0KSmFzb24NCg0KRnJvbTog RVhUIERlYW4gQm9nZGFub3ZpYyBbbWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbV0NClNlbnQ6IEZy aWRheSwgQXByaWwgMDgsIDIwMTYgOToyNQ0KVG86IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0Ep DQpDYzogbmV0bW9kIFdHDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gaW5wdXQgSW50ZXJmYWNlIG1h dGNoDQoNCkphc29uLA0KDQpBZnRlciBsb29raW5nIGF0IHRoZSBkb2N1bWVudCBhbmQgdGhlIG1v ZGVsLCBpdCBpcyBhbHNvIGFib3V0IGhhdmluZyBtZXRhZGF0YSBncm91cGluZyBpbiB0aGUgbW9k ZWwuIElmIHlvdSB3YW50IHRvIGhhdmUgbWV0YWRhdGEgZ3JvdXBpbmcgaW4gdGhlIG1vZGVsLCB0 aGVuIHlvdSBoYXZlIHRvIGhhdmUgc29tZXRoaW5nIGluc2lkZSBhbmQgdGhlbiBpbnB1dC1pbnRl cmZhY2UgcXVlc3Rpb25zIGNvbWVzIHVwLiBJZiB5b3UgZG9u4oCZdCBoYXZlIHRvIGhhdmUgbWV0 YWRhdGEgZ3JvdXBpbmcgaW4gdGhlIGJhc2UgbW9kZWwsIGV2ZXJ5dGhpbmcgaXMgZWFzeS4NCg0K SSBiZWxpZXZlIHRoaXMgaXMgdGhlIHJpZ2h0IHF1ZXN0aW9uDQoNCkRlYW4NCg0KT24gQXByIDgs IDIwMTYsIGF0IDk6MjAgQU0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EpIDxqYXNvbi5zdGVy bmVAbm9raWEuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tPj4gd3JvdGU6DQoNCkhp IERlYW4sDQoNCkp1c3QgdG8gY2xhcmlmeSAtPiB0aGUgbWFpbiBxdWVzdGlvbiBwb3NlZCBpbiB0 aGUgV0cgbWVldGluZyB3YXMgYWJvdXQgdGhlIGlucHV0LWludGVyZmFjZSBtYXRjaCBjcml0ZXJp YS4gIEZyb20gdGhlIG1lZXRpbmcgbWludXRlczoNCg0KQ2hhaXJzOiBjYWxsIGZvciBpZiBpbnRl cmZhY2Ugc2hvdWxkIGJlIGluIGJhc2U6DQogICAgNiBwcmVmZXIgTk9UIGhhdmluZyBpdCBpbiB0 aGUgZG9jIGF0IGFsbA0KICAgIDUgcHJlZmVyIGhhdmluZyBpdCBpbiwgYnV0IGFzIGEgZmVhdHVy ZQ0KICAgIDIgcHJlZmVyIGhhdmluZyBpdCBpbiB0aGUgZG9jIGFzIHJlcXVpcmVkDQoNCk1heWJl IHdlIHNob3VsZCBnZXQgYWdyZWVtZW50IG9uIHdoYXQgdG8gZG8gYWJvdXQgaW5wdXQtaW50ZXJm YWNlIChvbiB0aGUgbGlzdCkgZmlyc3QgYW5kIHRoZW4gd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCB0 byBkbyBhYm91dCB0aGUgbWV0YWRhdGEgZ3JvdXBpbmcuDQoNCk1hdGNoaW5nIG9uIGJhc2ljIElQ djQvSVB2NC9NQUMgaGVhZGVyIGZpZWxkcyBpcyBjb21tb24gZnVuY3Rpb25hbGl0eS4gIEJ1dCBo YXZpbmcgdGhhdCBpbnB1dC1pbnRlcmZhY2UgbWF0Y2ggb24gbWV0YWRhdGEgaW4gdGhlIGNvcmUg bW9kZWwgaXMgb3V0IG9mIHBsYWNlLiAgSXQgc2hvdWxkIGJlIGxlZnQgdG8gZnVydGhlciBleHRl bnNpb24gZHJhZnRzIG9yIHZlbmRvciBzcGVjaWZpYyBhdWdtZW50YXRpb25zIChhbG9uZyB3aXRo IHdoYXRldmVyIG90aGVyIG1ldGFkYXRhIG1pZ2h0IGJlIHVzZWZ1bCBvciB2ZW5kb3Itc3BlY2lm aWMpLiBNYW55IG1ham9yIGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3VwcG9ydCBtYXRjaGluZyBv biBpbnB1dC1pbnRlcmZhY2UgKENpc2NvIElPUy1YUiwgTm9raWEgU1IgT1MsIEJyb2NhZGUsIG90 aGVycykuICBUaGUgdHlwaWNhbCB3YXkgdG8gYXNzb2NpYXRlIEFDTHMgYW5kIEludGVyZmFjZXMg aXMgYnkgYXNzaWduaW5nIGFuIEFDTCB0byBhbiBpbnRlcmZhY2UgYXMgc2hvd24gaW4gc2VjdGlv biBBLjMuIG9mIHRoZSBBQ0wgZHJhZnQuICAgVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIG9mIHRo aXMgb24gdGhlIE5FVE1PRCB0aHJlYWQg4oCcUmVtb3ZlIGlucHV0LWludGVyZmFjZSAobWV0YWRh dGEpIGZyb20gbmV0bW9kLWFjbC1tb2RlbC0wNyA/4oCdLg0KDQpSZWdhcmRzLA0KSmFzb24NCg0K RnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBFWFQgRGVhbiBCb2dkYW5vdmljDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgMTE6 MTINClRvOiBuZXRtb2QgV0cNClN1YmplY3Q6IFtuZXRtb2RdIGlucHV0IEludGVyZmFjZSBtYXRj aA0KDQpBcyB0aGUgYWN0aW9uIGl0ZW0gZnJvbSB0aGUgbmV0bW9kIFdHIGFuZCwgaG9wZWZ1bGx5 LCBsYXN0IG9wZW4gaXRlbSBpbiB0aGUgQUNMIGRyYWZ0IGlzIHRoZSBsZWFmIGlucHV0IGludGVy ZmFjZSBpbiB0aGUgbWV0YWRhdGEgZ3JvdXBpbmcNCg0KDQpncm91cGluZyBtZXRhZGF0YSB7DQoN CiAgICBkZXNjcmlwdGlvbg0KDQogICAgICAiRmllbGRzIGFzc29jaWF0ZWQgd2l0aCBhIHBhY2tl dCB3aGljaCBhcmUgbm90IGluDQoNCiAgICAgIHRoZSBoZWFkZXIuIjsNCg0KICAgIGxlYWYgaW5w dXQtaW50ZXJmYWNlIHsNCg0KICAgICAgdHlwZSBpZjppbnRlcmZhY2UtcmVmIHsNCg0KICAgICAg ICByZXF1aXJlLWluc3RhbmNlIGZhbHNlOw0KDQogICAgICB9DQoNCiAgICAgIGRlc2NyaXB0aW9u DQoNCiAgICAgICAgIlBhY2tldCB3YXMgcmVjZWl2ZWQgb24gdGhpcyBpbnRlcmZhY2UuIjsNCg0K ICAgIH0NCg0KICB9DQoNCn0NCg0KDQpIZXJlIGFyZSB0d28gcXVlc3Rpb25zOg0KT25lDQpEbyB3 YW50IHRvIGhhdmUgYSBtZXRhZGF0YSBncm91cGluZyBpbiB0aGUgYmFzaWMgQUNMIG1vZGVsPyBJ ZiB5ZXMsIHdlIGhhdmUgdG8gcHV0IGluIHNvbWUgbGVhZnMgaW4gdGhlcmUuIFRoZXJlIGFyZSBp bXBsZW1lbnRhdGlvbnMgd2hpY2ggdXNlIG1ldGFkYXRhIGFzIG1hdGNoIGNvbmRpdGlvbg0KDQpJ ZiB3ZSBhZ3JlZSB0aGF0IG1ldGFkYXRhIGdyb3VwaW5nIGlzIG5vdCBuZWVkZWQgaW4gdGhlIGJh c2ljIG1vZGVsLCB0aGVuIHRoZSBhdXRob3JzIHdvdWxkIHJlbW92ZSB0aGUgZ3JvdXBpbmcgZnJv bSB0aGUgbW9kZWwgYW5kIEkgYmVsaWV2ZSB0aGF0IG5vIG1vcmUgZGlzY3Vzc2lvbiBpcyBuZWVk ZWQgb24gdGhpcyBwb2ludA0KDQpEZWFuDQoNCg== --_000_A125E53CE190A749957C19483DC79F9F5CC2B0EEUS70TWXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIERlYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaG91bGQgcmVtb3ZlIHRoZSBtZXRh ZGF0YSBncm91cGluZyBmcm9tIHRoZSBiYXNlIG1vZGVsLiZuYnNwOyBJdCBpcyBvdXQgb2YgcGxh Y2Ugd2l0aCB0aGUgcmVzdCBvZiB0aGUgbW9kZWwgYW5kIGEgZmFpcmx5IGNsZWFuIGxpbmUgdG8g ZHJhdyBhcyBhIGJvdW5kYXJ5IGZvcg0KIGZ1dHVyZSBleHRlbnNpb24vYXVnbWVudGF0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFzb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBFWFQgRGVhbiBCb2dkYW5vdmljIFttYWlsdG86aXZhbmRlYW5AZ21h aWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMDgsIDIwMTYgOToyNTxi cj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQSk8YnI+DQo8Yj5DYzo8L2I+ IG5ldG1vZCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gaW5wdXQgSW50ZXJm YWNlIG1hdGNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SmFzb24sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRl ciBsb29raW5nIGF0IHRoZSBkb2N1bWVudCBhbmQgdGhlIG1vZGVsLCBpdCBpcyBhbHNvIGFib3V0 IGhhdmluZyBtZXRhZGF0YSBncm91cGluZyBpbiB0aGUgbW9kZWwuIElmIHlvdSB3YW50IHRvIGhh dmUgbWV0YWRhdGEgZ3JvdXBpbmcgaW4gdGhlIG1vZGVsLCB0aGVuIHlvdSBoYXZlIHRvIGhhdmUg c29tZXRoaW5nIGluc2lkZSBhbmQgdGhlbiBpbnB1dC1pbnRlcmZhY2UgcXVlc3Rpb25zIGNvbWVz IHVwLg0KIElmIHlvdSBkb27igJl0IGhhdmUgdG8gaGF2ZSBtZXRhZGF0YSBncm91cGluZyBpbiB0 aGUgYmFzZSBtb2RlbCwgZXZlcnl0aGluZyBpcyBlYXN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhpcyBpcyB0aGUgcmln aHQgcXVlc3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RGVhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gQXByIDgsIDIwMTYsIGF0IDk6MjAgQU0sIFN0ZXJuZSwgSmFzb24gKE5v a2lhIC0gQ0EpICZsdDs8YSBocmVmPSJtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbSI+amFz b24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhpIERlYW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5KdXN0IHRvIGNsYXJpZnkgLSZndDsgdGhlIG1haW4gcXVlc3Rpb24gcG9zZWQgaW4gdGhlIFdH IG1lZXRpbmcgd2FzIGFib3V0IHRoZSBpbnB1dC1pbnRlcmZhY2UgbWF0Y2ggY3JpdGVyaWEuJm5i c3A7IEZyb20gdGhlIG1lZXRpbmcgbWludXRlczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNoYWlyczogY2FsbCBmb3IgaWYgaW50ZXJmYWNlIHNob3VsZCBiZSBpbiBi YXNlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsmbmJzcDsgNiBwcmVmZXIgTk9UIGhhdmluZyBpdCBpbiB0aGUgZG9jIGF0IGFsbDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsgNSBwcmVmZXIgaGF2aW5nIGl0IGluLCBidXQgYXMgYSBmZWF0dXJlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyAyIHByZWZl ciBoYXZpbmcgaXQgaW4gdGhlIGRvYyBhcyByZXF1aXJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgd2Ugc2hvdWxkIGdldCBhZ3JlZW1lbnQgb24gd2hhdCB0 byBkbyBhYm91dCBpbnB1dC1pbnRlcmZhY2UgKG9uIHRoZSBsaXN0KSBmaXJzdCBhbmQgdGhlbiB3 ZSBjYW4gZmlndXJlIG91dCB3aGF0IHRvIGRvIGFib3V0IHRoZSBtZXRhZGF0YSBncm91cGluZy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hdGNoaW5nIG9uIGJhc2lj IElQdjQvSVB2NC9NQUMgaGVhZGVyIGZpZWxkcyBpcyBjb21tb24gZnVuY3Rpb25hbGl0eS4mbmJz cDsgQnV0IGhhdmluZyB0aGF0IGlucHV0LWludGVyZmFjZSBtYXRjaCBvbiBtZXRhZGF0YSBpbiB0 aGUgY29yZSBtb2RlbCBpcyBvdXQgb2YgcGxhY2UuJm5ic3A7DQogSXQgc2hvdWxkIGJlIGxlZnQg dG8gZnVydGhlciBleHRlbnNpb24gZHJhZnRzIG9yIHZlbmRvciBzcGVjaWZpYyBhdWdtZW50YXRp b25zIChhbG9uZyB3aXRoIHdoYXRldmVyIG90aGVyIG1ldGFkYXRhIG1pZ2h0IGJlIHVzZWZ1bCBv ciB2ZW5kb3Itc3BlY2lmaWMpLiBNYW55IG1ham9yIGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3Vw cG9ydCBtYXRjaGluZyBvbiBpbnB1dC1pbnRlcmZhY2UgKENpc2NvIElPUy1YUiwgTm9raWEgU1Ig T1MsIEJyb2NhZGUsDQogb3RoZXJzKS4mbmJzcDsgVGhlIHR5cGljYWwgd2F5IHRvIGFzc29jaWF0 ZSBBQ0xzIGFuZCBJbnRlcmZhY2VzIGlzIGJ5IGFzc2lnbmluZyBhbiBBQ0wgdG8gYW4gaW50ZXJm YWNlIGFzIHNob3duIGluIHNlY3Rpb24gQS4zLiBvZiB0aGUgQUNMIGRyYWZ0LiZuYnNwOyZuYnNw OyBUaGVyZSBpcyBzb21lIGRpc2N1c3Npb24gb2YgdGhpcyBvbiB0aGUgTkVUTU9EIHRocmVhZCDi gJxSZW1vdmUgaW5wdXQtaW50ZXJmYWNlIChtZXRhZGF0YSkgZnJvbSBuZXRtb2QtYWNsLW1vZGVs LTA3DQogP+KAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphc29uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5uZXRtb2QNCiBbPGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkVYVCBEZWFu IEJvZ2Rhbm92aWM8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDExOjEyPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5uZXRtb2QgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W25ldG1vZF0gaW5wdXQgSW50ZXJmYWNlIG1hdGNoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXMgdGhlIGFjdGlvbiBpdGVtIGZyb20gdGhlIG5ldG1vZCBXRyBh bmQsIGhvcGVmdWxseSwgbGFzdCBvcGVuIGl0ZW0gaW4gdGhlIEFDTCBkcmFmdCBpcyB0aGUgbGVh ZiBpbnB1dCBpbnRlcmZhY2UgaW4gdGhlIG1ldGFkYXRhIGdyb3VwaW5nJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+Z3JvdXBpbmcgbWV0YWRhdGEgezxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyZuYnNw OyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtGaWVsZHMg YXNzb2NpYXRlZCB3aXRoIGEgcGFja2V0IHdoaWNoIGFyZSBub3QgaW48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIGhlYWRlci4mcXVvdDs7PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYg aW5wdXQtaW50ZXJmYWNlIHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBpZjpp bnRlcmZhY2UtcmVmIHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg cmVxdWlyZS1pbnN0YW5jZSBmYWxzZTs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtQYWNrZXQgd2FzIHJlY2VpdmVkIG9uIHRo aXMgaW50ZXJmYWNlLiZxdW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyB9PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+fTxvOnA+PC9v OnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgYXJlIHR3byBxdWVzdGlvbnM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHdhbnQgdG8gaGF2ZSBhIG1ldGFkYXRhIGdyb3VwaW5n IGluIHRoZSBiYXNpYyBBQ0wgbW9kZWw/IElmIHllcywgd2UgaGF2ZSB0byBwdXQgaW4gc29tZSBs ZWFmcyBpbiB0aGVyZS4gVGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB3aGljaCB1c2UgbWV0YWRh dGEgYXMgbWF0Y2ggY29uZGl0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIGFn cmVlIHRoYXQgbWV0YWRhdGEgZ3JvdXBpbmcgaXMgbm90IG5lZWRlZCBpbiB0aGUgYmFzaWMgbW9k ZWwsIHRoZW4gdGhlIGF1dGhvcnMgd291bGQgcmVtb3ZlIHRoZSBncm91cGluZyBmcm9tIHRoZSBt b2RlbCBhbmQgSSBiZWxpZXZlIHRoYXQgbm8gbW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZCBvbiB0 aGlzIHBvaW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A125E53CE190A749957C19483DC79F9F5CC2B0EEUS70TWXCHMBA11z_-- From nobody Fri Apr 8 05:41:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAEC12D7F8 for ; Fri, 8 Apr 2016 05:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EviwdcvDwE3M for ; Fri, 8 Apr 2016 05:41:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1498D12D804 for ; Fri, 8 Apr 2016 05:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5124; q=dns/txt; s=iport; t=1460119260; x=1461328860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=K/gajGlrQqoiuAYQMXkbqTrjKTytE7ejEKLmgDW/oss=; b=P1k/wbL7a/oQg8y8FY0IWmTeNi4pgxRePhkdxb2Hfm93te/FuaVq64Ak +02KexcN5NkEuU5exYwoYyVgdF8d7vg5SPRTL78Q3bYlykrJcs+HJBEaV mNmJ2A78b6EeUdQ4SpE3687MOcrTYUhPYzVTedSOE6H5b66mGtXQV6Fcg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgD5pQdX/51dJa1cgzdTbg8Guj8BD?= =?us-ascii?q?YFzFwqFIkoCHIEYOBQBAQEBAQEBZSeEQQEBAQMBAQEBIBE6CwUHBAIBBgIRBAE?= =?us-ascii?q?BAQICIwMCAgIlCxQBCAgCBA4FiB8IDpEZnReSAgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEfIUlgXWCVoc/K4IrBYlaiT+EawGOC48NjyQBHgEBQoNnbIg7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="91431529" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 12:41:00 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u38Cf0O3009874 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 12:41:00 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 07:40:59 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 07:40:59 -0500 From: "Carl Moberg (camoberg)" To: "Alexander Clemm (alex)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoAABkQdAAAPpD0AAAGkXYAAABFJgAAQS7qAACnPDwA= Date: Fri, 8 Apr 2016 12:40:59 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.70] 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] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:41:08 -0000 DQo+IE9uIEFwciA3LCAyMDE2LCBhdCA2OjQzIFBNLCBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIDxh bGV4QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBJIGFtIHdvbmRlcmluZyB3aGF0IHB1cnBvc2Ug dGhlIGNsYXNzaWZpY2F0aW9uIHJlYWxseSBzZXJ2ZXMuICBBdCB0aGUgZW5kIG9mIHRoZSBkYXks IGl0IHNlZW1zIHRvIG1lIHRoYXQgd2UgYXJlIHRyeWluZyB0byBleHByZXNzIGEgbW9kZWwgaGll cmFyY2h5LCBhbmQgYXJ0aWN1bGF0ZSB3aGF0IHRoZSBsYXllcnMgaW4gdGhlIGhpZXJhcmNoeSBh cmUuICBBIGRldmljZSBtb2RlbCBpcyB0aHVzIGF0IGEgbG93ZXIgbGF5ZXIgdGhhbiBhIHNlcnZp Y2UgbW9kZWwuICBBbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VydmljZSBtb2RlbCBtYXkgaW4g dHVybiBoYXZlIGRlcGVuZGVuY2llcyBvbiB0aGUgZGV2aWNlIG1vZGVsLCBidXQgbm90IHRoZSBv dGhlciB3YXkgcm91bmQuICANCg0KIFRoZSBhYnN0cmFjdCB0cmllcyB0byBleHByZXNzIHRoZSBw dXJwb3NlOg0KDQrigJzigJ3igJ0NCkEgY29uc2lzdGVudCB0ZXJtaW5vbG9neSB3b3VsZCBoZWxw IHdpdGggdGhlIGNhdGVnb3JpemF0aW9uIG9mDQptb2RlbHMsIGFzc2lzdCBpbiB0aGUgYW5hbHlz aXMgdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBlZmZvcnRzIGluIHRoZQ0KSUVURiBhbmQgb3RoZXIg b3JnYW5pemF0aW9ucywgYW5kIGJyaW5nIGNsYXJpdHkgdG8gdGhlIFlBTkctcmVsYXRlZA0KZGlz Y3Vzc2lvbnMgYmV0d2VlbiB0aGUgZGlmZmVyZW50IGdyb3Vwcy4NCuKAnOKAnSINCg0KIEFuZCBJ 4oCZdmUgdGhlbiB0cmllZCB0byBleHBhbmQgYSBsaXR0bGUgZnVydGhlciBpbiBzZWN0aW9uIDEu DQoNCiBIYXBweSB0byB0YWtlIGZlZWRiYWNrIG9uIGl0IQ0KDQo+IFdoZXJlIHRoZSBtb2RlbHMg YXJlIGluc3RhbnRpYXRlZCAtIG9uIGEgY29udHJvbGxlciwgb24gYSAiZGV2aWNlIiwgZXRjIC0g c2VlbXMgdG8gYmUgc2Vjb25kYXJ5IGFuZCBpbmNpZGVudGFsLiAgVGhlIGJvdW5kYXJpZXMgYXJl IGJsdXJyeSwgYW55d2F5cy4gIEEgY29udHJvbGxlciBpcyBhIGRldmljZSB0b287IHNvbWUgZGV2 aWNlcyBtYXkgY29udGFpbiB2aXJ0dWFsaXplZCBjb250cm9sbGVycywgYW5kIHNvIG9uLiAgDQoN CiBUaGUgYXNzdW1wdGlvbiBoZXJlIGlzIHRoYXQgdGhlIGxvY2F0aW9uIGlzIGluZGVlZCB1c2Vm dWwgYW5kIHN1Z2dlc3RzIHRoZSBjbGFzc2lmaWNhdGlvbiBvZiBkYXRhIG1vZGVscyBpbnRvIHR3 byBkaXN0aW5jdCBhYnN0cmFjdGlvbiBsYXllcnMuIFRvcG9sb2d5IGlzIHRoZSBhcmVhIHdoZXJl IEkgaGFkIGEgc2Vuc2UgdGhhdCB0aGUgZGV2aWNlIGFuZCBzZXJ2aWNlIGNsYXNzaWZpY2F0aW9u IG1heSBib3RoIGFwcGx5IHRvIGEgc2luZ2xlIG1vZHVsZS4NCg0KPiBPbmUgbW9kZWwgdGhhdCBp cyByZWxldmFudCBpbiB0aGlzIGRpc2N1c3Npb24gc2VlbXMgdG8gYmUgdGhlIFRNTiBtb2RlbCwg YXMgZGVmaW5lZCBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiBNLjMwMTAuICBUaGlzIG1vZGVsIGRl ZmluZXMgYSBzZXQgb2YgbWFuYWdlbWVudCBsYXllcnMgLSBuZXR3b3JrIGVsZW1lbnQgKGRldmlj ZSksIG5ldHdvcmssIHNlcnZpY2UsIGJ1c2luZXNzIC0gd2l0aCB3ZWxsIGRlZmluZWQgZnVuY2lv bmFsIHNjb3BlIG9mIGVhY2ggbGF5ZXIuICBUaGUgbGF5ZXJzIC8gZnVuY3Rpb24gaGllcmFyY2h5 IGFsc28gaW1wbHkgYW4gaW5mb3JtYXRpb24gIGFuZCBkYXRhIG1vZGVsIGhpZXJhcmNoeS4gIA0K DQogVGhlIGNsYXNzaWZpY2F0aW9uIGlzIGZhaXJseSB3ZWxsIGFsaWduZWQgd2l0aCB0aGUgY29u Y2VwdHMgaW4gTS4zMDEwLCBjb3ZlcmluZyB0aGUgIk5ldHdvcmsgbWFuYWdlbWVudOKAnSBhbmQg 4oCcRWxlbWVudCBtYW5hZ2VtZW504oCdIGxheWVycy4gQXQgbGVhc3QgdGhhdOKAmXMgdGhlIGlu dGVudCA6LSkNCg0KPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHNlZSBpZiB0aGUgbGF5ZXJpbmcg aW4gTS4zMDEwIGNvdWxkIGhlbHAgZ3VpZGUgWUFORyBtb2RlbCBjbGFzc2lmaWNhdGlvbiwgYW5k IHJlZmVyZW5jZSB0aG9zZSBkZWZpbml0aW9ucz8gIA0KDQogV291bGQgYmUgdmVyeSBoYXBweSB0 byBoZWFyIGlmIHlvdSBmaW5kIHdlIGRldmlhdGUgKG9yIGxhY2spIGNvbmNlcHRzIG9yIHVzZWZ1 bCBmZWF0dXJlcyBmcm9tIE0uMzAxMCB0aGF0IHdvdWxkIG1ha2UgdGhlIGNsYXNzaWZpY2F0aW9u IG1vcmUgdXNlZnVsLg0KDQo+IC0tLSBBbGV4DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIENhcmwgTW9iZXJnIChjYW1vYmVyZykNCj4gU2VudDogVGh1cnNkYXksIEFwcmls IDA3LCAyMDE2IDE6NTcgQU0NCj4gVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1p Y2hhZWwuc2NoYXJmQG5va2lhLmNvbT4NCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW25ldG1vZF0gWUFORyBtb2RlbCBjbGFzc2lmaWNhdGlvbj8NCj4gDQo+IA0KPiANCj4g LS0NCj4gQ2FybCBNb2JlcmcNCj4gVGVjaG5vbG9neSBEaXJlY3RvciwgQ1ZHDQo+IGNhbW9iZXJn QGNpc2NvLmNvbQ0KPiANCj4+IE9uIEFwciA3LCAyMDE2LCBhdCAxMDo1NSBBTSwgU2NoYXJmLCBN aWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPiB3cm90ZToNCj4+ IA0KPj4+IEkgY29tZSBhdCB0aGlzIGZyb20gdGhlIGNsYXNzaWZpY2F0aW9uIGFuZ2xlLCBzbyBt eSBpbnRlcmVzdCBpcyBpZiANCj4+PiB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgWUFORyBtb2RlbCBj YW4gb25seSBiZSBjbGFzc2lmaWVkIGFzIGEgbmV0d29yayANCj4+PiBzZXJ2aWNlIG1vZGVsIFhP UiBhIG5ldHdvcmsgZGV2aWNlIG1vZGVsIGFjY29yZGluZyB0byB0aGUgZGVmaW5pdGlvbnMgDQo+ Pj4gaW4gZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiAoc2VjdGlv bnMgMi4xIGFuZCANCj4+PiAyLjIpLiBCYXNlZCBvbiB0aGlzIGRpc2N1c3Npb24gSSB0YWtlIGl0 IHRoYXQgc29tZSBtb2RlbHMgYXJlIGludGVuZGVkIHRvIGJlIGFibGUgdG8gc2VydmUgaW4gYm90 aCByb2xlcy4gQW5kIHdlIHNob3VsZCBtYWtlIHN1cmUgdGhhdCBpdOKAmXMgc3VwcG9ydGVkIGlu IG91ciBjYXRhbG9nIHN0cnVjdHVyZS4NCj4+IA0KPj4gUmVnYXJkaW5nIHRoZSBYT1IgYXNzdW1w dGlvbiBmb3IgY2xhc3NpZmljYXRpb246DQo+PiANCj4+IFlvdSBtYXkgYWxzbyB3YW50IHRvIHRo aW5rIGFib3V0IFlBTkcgbW9kZWxzIHRoYXQgYXJlIE5FSVRIRVIgZGV2aWNlIE5PUiBzZXJ2aWNl IG1vZGVscy4gRm9yIGluc3RhbmNlLCB3aGF0IGFib3V0IFJGQyA2OTkxPyBBbmQgSSB0aGluayBv dGhlciwgbW9yZSB0ZWNobmljYWwgbW9kZWxzIHByZXNlbnRlZCB0aGlzIHdlZWsgbWF5IGZhbGwg aW50byBhIHNpbWlsYXIgY2F0ZWdvcnkgKCJnZW5lcmljIj8pLg0KPiANCj4gVmVyeSBnb29kIHBv aW50LCB0aGFua3MhIFRoYXQgd2lsbCBuZWVkIHNvbWUgYWRkaXRpb25hbCB0aGlua2luZyBhbmQg d3JpdGluZy4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Fri Apr 8 06:10:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F0412D6B9 for ; Fri, 8 Apr 2016 06:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbEWhiCX2m45 for ; Fri, 8 Apr 2016 06:10:03 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA3812D694 for ; Fri, 8 Apr 2016 06:10:03 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id vo2so69061537lbb.1 for ; Fri, 08 Apr 2016 06:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ofoSED84xKivag/kd84dwBJERw7ASTMS22Paw2gOQmM=; b=I/pW7ZVEvmbDU6ij+pljxH/H4A3g9mD0a1gGAOR0kV+90YHoJh6hGJf6Ig3KP3I5mD h+tJLw0C3J8JRabvgTjmPkSah9vjn3bOJZh7wb5UYZFBEC1EDK0LYOnmshCVjX0dPZ0/ 2zSCuirGJCOYTfrNIj2d6BLtvRoyADHJv7r6badw7A8QN3x5WaKiKaE5VBt5sO716gqb qj9l5PaadmR5q2jvZoEkoHV0rCeKR5jTXVPzBLRcfvYPpygWD8uXMAqhmxPINxMfiv2M 40NhRbO7oZrr3BzYfEdNPVMDpySAnuRL/APgwIQgM0VSaoa2sAETjNiJpwxaYBxfybgP hZYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ofoSED84xKivag/kd84dwBJERw7ASTMS22Paw2gOQmM=; b=gUv6Y4FSrvLYfT0hVAWKWKmEqUs4vw4IPFsvLbRUGoKj55rjqWdr0kM5PzXvJChjdl fFWrwicC9rlUaAZF1xXwDRm5hOM48GP0fCJnhJiF7+8tC11KUjRxUEHfJAJ1YJEwqWyC BzU6a+uKTlb4yrOdhAtFbDRylTuH/nDLn9sMzhmpsPhYXA7Z/n3AnDRnkQ1lpAA9i5pT N94/x8aEFwI2h1UrQwS72N2G0GqYsJDwhnBzSo48NOjhH2Lbmn5g0t6XfQ/vESLqesbc 8CqqZtnZzxl+wk4FzcMHfWNsCvfPlIH6DB5IsJQFiRv/r7sAzCdQqPJJLt6yUypTd/1G 0U7Q== X-Gm-Message-State: AD7BkJLEtZLSnZ1M+QY8iLzaCwcs15EVt/zBbR9Xy1Mg7Eu2LVq9RAFE71fF9ke4M6vFyh2z3GwicOyxXxGE8w== MIME-Version: 1.0 X-Received: by 10.112.56.43 with SMTP id x11mr3582232lbp.145.1460121001172; Fri, 08 Apr 2016 06:10:01 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Fri, 8 Apr 2016 06:10:01 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> Date: Fri, 8 Apr 2016 06:10:01 -0700 Message-ID: From: Andy Bierman To: "Carl Moberg (camoberg)" Content-Type: multipart/alternative; boundary=001a1133a9ea9ab5cb052ff8e979 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:10:10 -0000 --001a1133a9ea9ab5cb052ff8e979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, It is not that clear how the different types of modules or layers impact the task of designing a YANG module. It seems like vendor vs. standard or device vs. service are somewhat arbitrary, especially if virtualization is considered. The terminology would be more relevant if the differences in content of each type of module were clear. Andy On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) wrote: > > > On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) > wrote: > > > > I am wondering what purpose the classification really serves. At the > end of the day, it seems to me that we are trying to express a model > hierarchy, and articulate what the layers in the hierarchy are. A device > model is thus at a lower layer than a service model. An implementation o= f > the service model may in turn have dependencies on the device model, but > not the other way round. > > The abstract tries to express the purpose: > > =E2=80=9C=E2=80=9D=E2=80=9D > A consistent terminology would help with the categorization of > models, assist in the analysis the YANG data modeling efforts in the > IETF and other organizations, and bring clarity to the YANG-related > discussions between the different groups. > =E2=80=9C=E2=80=9D" > > And I=E2=80=99ve then tried to expand a little further in section 1. > > Happy to take feedback on it! > > > Where the models are instantiated - on a controller, on a "device", etc > - seems to be secondary and incidental. The boundaries are blurry, > anyways. A controller is a device too; some devices may contain > virtualized controllers, and so on. > > The assumption here is that the location is indeed useful and suggests > the classification of data models into two distinct abstraction layers. > Topology is the area where I had a sense that the device and service > classification may both apply to a single module. > > > One model that is relevant in this discussion seems to be the TMN model= , > as defined in ITU-T Recommendation M.3010. This model defines a set of > management layers - network element (device), network, service, business = - > with well defined funcional scope of each layer. The layers / function > hierarchy also imply an information and data model hierarchy. > > The classification is fairly well aligned with the concepts in M.3010, > covering the "Network management=E2=80=9D and =E2=80=9CElement management= =E2=80=9D layers. At least > that=E2=80=99s the intent :-) > > > Would it make sense to see if the layering in M.3010 could help guide > YANG model classification, and reference those definitions? > > Would be very happy to hear if you find we deviate (or lack) concepts or > useful features from M.3010 that would make the classification more usefu= l. > > > --- Alex > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Carl Moberg > (camoberg) > > Sent: Thursday, April 07, 2016 1:57 AM > > To: Scharf, Michael (Nokia - DE) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] YANG model classification? > > > > > > > > -- > > Carl Moberg > > Technology Director, CVG > > camoberg@cisco.com > > > >> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > >> > >>> I come at this from the classification angle, so my interest is if > >>> the assumption that a YANG model can only be classified as a network > >>> service model XOR a network device model according to the definitions > >>> in draft-ietf-netmod-yang-model-classification (sections 2.1 and > >>> 2.2). Based on this discussion I take it that some models are intende= d > to be able to serve in both roles. And we should make sure that it=E2=80= =99s > supported in our catalog structure. > >> > >> Regarding the XOR assumption for classification: > >> > >> You may also want to think about YANG models that are NEITHER device > NOR service models. For instance, what about RFC 6991? And I think other, > more technical models presented this week may fall into a similar categor= y > ("generic"?). > > > > Very good point, thanks! That will need some additional thinking and > writing. > > _______________________________________________ > > 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 > --001a1133a9ea9ab5cb052ff8e979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


It is not that clear= how the different types of modules or layers
impact the task of = designing a YANG module.=C2=A0 It seems like
vendor vs. standard = or device vs. service are somewhat arbitrary,
especially if virtu= alization is considered.

The terminology would be = more relevant if the differences in
content of each type of modul= e were clear.

Andy


On Fri, Apr 8, 2016 at = 5:40 AM, Carl Moberg (camoberg) <camoberg@cisco.com> wrote:=

> On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:
>
> I am wondering what purpose the classification really serves.=C2=A0 At= the end of the day, it seems to me that we are trying to express a model h= ierarchy, and articulate what the layers in the hierarchy are.=C2=A0 A devi= ce model is thus at a lower layer than a service model.=C2=A0 An implementa= tion of the service model may in turn have dependencies on the device model= , but not the other way round.

=C2=A0The abstract tries to express the purpose:

=E2=80=9C=E2=80=9D=E2=80=9D
A consistent terminology would help with the categorization of
models, assist in the analysis the YANG data modeling efforts in the
IETF and other organizations, and bring clarity to the YANG-related
discussions between the different groups.
=E2=80=9C=E2=80=9D"

=C2=A0And I=E2=80=99ve then tried to expand a little further in section 1.<= br>
=C2=A0Happy to take feedback on it!

> Where the models are instantiated - on a controller, on a "device= ", etc - seems to be secondary and incidental.=C2=A0 The boundaries ar= e blurry, anyways.=C2=A0 A controller is a device too; some devices may con= tain virtualized controllers, and so on.

=C2=A0The assumption here is that the location is indeed useful and suggest= s the classification of data models into two distinct abstraction layers. T= opology is the area where I had a sense that the device and service classif= ication may both apply to a single module.

> One model that is relevant in this discussion seems to be the TMN mode= l, as defined in ITU-T Recommendation M.3010.=C2=A0 This model defines a se= t of management layers - network element (device), network, service, busine= ss - with well defined funcional scope of each layer.=C2=A0 The layers / fu= nction hierarchy also imply an information=C2=A0 and data model hierarchy.<= br>
=C2=A0The classification is fairly well aligned with the concepts in M.3010= , covering the "Network management=E2=80=9D and =E2=80=9CElement manag= ement=E2=80=9D layers. At least that=E2=80=99s the intent :-)

> Would it make sense to see if the layering in M.3010 could help guide = YANG model classification, and reference those definitions?

=C2=A0Would be very happy to hear if you find we deviate (or lack) concepts= or useful features from M.3010 that would make the classification more use= ful.

> --- Alex
>
> -----Original Message-----
> From: netmod [mailto:netmod= -bounces@ietf.org] On Behalf Of Carl Moberg (camoberg)
> Sent: Thursday, April 07, 2016 1:57 AM
> To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG model classification?
>
>
>
> --
> Carl Moberg
> Technology Director, CVG
> camoberg@cisco.com
>
>> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> wr= ote:
>>
>>> I come at this from the classification angle, so my interest i= s if
>>> the assumption that a YANG model can only be classified as a n= etwork
>>> service model XOR a network device model according to the defi= nitions
>>> in draft-ietf-netmod-yang-model-classification (sections 2.1 a= nd
>>> 2.2). Based on this discussion I take it that some models are = intended to be able to serve in both roles. And we should make sure that it= =E2=80=99s supported in our catalog structure.
>>
>> Regarding the XOR assumption for classification:
>>
>> You may also want to think about YANG models that are NEITHER devi= ce NOR service models. For instance, what about RFC 6991? And I think other= , more technical models presented this week may fall into a similar categor= y ("generic"?).
>
> Very good point, thanks! That will need some additional thinking and w= riting.
> _______________________________________________
> 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

--001a1133a9ea9ab5cb052ff8e979-- From nobody Fri Apr 8 06:18:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AFE12D79B for ; Fri, 8 Apr 2016 06:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV-mL-LEdf-D for ; Fri, 8 Apr 2016 06:18:34 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66E612D6DA for ; Fri, 8 Apr 2016 06:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6804; q=dns/txt; s=iport; t=1460121513; x=1461331113; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ym7zMB1IFwS47G5J/oCeKO/amzoF9TZ+4BRVL1mbc88=; b=dosrRhe/wQF/Qsht7iVOK5bWMerqiFXkLHonJrseTmzWX2AbYLcTDYBd JStYzmVZpkNgP+CSYrXCE7YdItiJhUuqduvKZTx1DiF/2gJzKeiexMoi3 GVAk0FZw12KU5z87m4eFmf0yfEi5lLgR2vnOcFL877bSzU0UZrYU9WY2I 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgCurgdX/5NdJa1cgzdTfQa6PwENg?= =?us-ascii?q?XMXCoUiSgIcgRg4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQcEAgEGAhEEAQE?= =?us-ascii?q?BAgIjAwICAiULFAEICAIEDgWIHwgOkSGdF5IBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQR8hSWBdYJWhD2DAiuCKwWJWo4qAY4Ljw2PJAEeAQFCg2dsiDt+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="257212419" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 13:18:32 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u38DIWdU017566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 13:18:32 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 08:18:31 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 08:18:31 -0500 From: "Carl Moberg (camoberg)" To: Andy Bierman Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoAABkQdAAAPpD0AAAGkXYAAABFJgAAQS7qAACnPDwAAAQO6gAAAS9kA Date: Fri, 8 Apr 2016 13:18:31 +0000 Message-ID: <6E7F5A13-FB4A-4CCB-AA43-39F7718D38EF@cisco.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.70] Content-Type: text/plain; charset="utf-8" Content-ID: <0C0044EB698C9B47B17E23186BCD3AE8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:18:35 -0000 DQo+IE9uIEFwciA4LCAyMDE2LCBhdCAzOjEwIFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IA0KPiBJdCBpcyBub3QgdGhhdCBjbGVh ciBob3cgdGhlIGRpZmZlcmVudCB0eXBlcyBvZiBtb2R1bGVzIG9yIGxheWVycw0KPiBpbXBhY3Qg dGhlIHRhc2sgb2YgZGVzaWduaW5nIGEgWUFORyBtb2R1bGUuICBJdCBzZWVtcyBsaWtlDQo+IHZl bmRvciB2cy4gc3RhbmRhcmQgb3IgZGV2aWNlIHZzLiBzZXJ2aWNlIGFyZSBzb21ld2hhdCBhcmJp dHJhcnksDQo+IGVzcGVjaWFsbHkgaWYgdmlydHVhbGl6YXRpb24gaXMgY29uc2lkZXJlZC4NCg0K DQogVGhlIGludGVudCBvZiB0aGUgY2xhc3NpZmljYXRpb24gaXMgKGltaG8pIG5vdCBpbnRlbmRl ZCB0byBoYXZlIG11Y2ggaW1wYWN0IG9uIGhvdyB0byBkZXNpZ24gYSBtb2R1bGUuIFJhdGhlciB0 byBwcm92aWRlIGEgdGF4b25vbXkgdG8gY2xhc3NpZnkgbW9kZWxzIHdoZW4gdGhleSBhcmUgZG9u ZSAob3IgYmVpbmcgZGV2ZWxvcGVkKS4NCg0KIEkgZG9u4oCZdCBzZWUgaG93IHZpcnR1YWxpemF0 aW9uIHdvdWxkIGhhdmUgYW4gaW1wYWN0LCBhbnkgc3VnZ2VzdGlvbnM/DQoNCj4gVGhlIHRlcm1p bm9sb2d5IHdvdWxkIGJlIG1vcmUgcmVsZXZhbnQgaWYgdGhlIGRpZmZlcmVuY2VzIGluDQo+IGNv bnRlbnQgb2YgZWFjaCB0eXBlIG9mIG1vZHVsZSB3ZXJlIGNsZWFyLg0KDQogVGhlIGZpcnN0IHBh cmFncmFwaHMgb2YgdGhlIG1haW4gc2VjdGlvbnMgKDIuMSwgMi4yLCAzLjEtMy4zKSBhcmUgbWVh bnQoISkgdG8gZXhwbGFpbiB0aGlzLiBDb3VsZCB5b3UgZXhwYW5kIG9uIHdoYXQgeW91IHRoaW5r IGlzIG1pc3Npbmc/DQoNCj4gQW5keQ0KPiANCj4gDQo+IE9uIEZyaSwgQXByIDgsIDIwMTYgYXQg NTo0MCBBTSwgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSA8Y2Ftb2JlcmdAY2lzY28uY29tPiB3cm90 ZToNCj4gDQo+ID4gT24gQXByIDcsIDIwMTYsIGF0IDY6NDMgUE0sIEFsZXhhbmRlciBDbGVtbSAo YWxleCkgPGFsZXhAY2lzY28uY29tPiB3cm90ZToNCj4gPg0KPiA+IEkgYW0gd29uZGVyaW5nIHdo YXQgcHVycG9zZSB0aGUgY2xhc3NpZmljYXRpb24gcmVhbGx5IHNlcnZlcy4gIEF0IHRoZSBlbmQg b2YgdGhlIGRheSwgaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGV4cHJlc3Mg YSBtb2RlbCBoaWVyYXJjaHksIGFuZCBhcnRpY3VsYXRlIHdoYXQgdGhlIGxheWVycyBpbiB0aGUg aGllcmFyY2h5IGFyZS4gIEEgZGV2aWNlIG1vZGVsIGlzIHRodXMgYXQgYSBsb3dlciBsYXllciB0 aGFuIGEgc2VydmljZSBtb2RlbC4gIEFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzZXJ2aWNlIG1v ZGVsIG1heSBpbiB0dXJuIGhhdmUgZGVwZW5kZW5jaWVzIG9uIHRoZSBkZXZpY2UgbW9kZWwsIGJ1 dCBub3QgdGhlIG90aGVyIHdheSByb3VuZC4NCj4gDQo+ICBUaGUgYWJzdHJhY3QgdHJpZXMgdG8g ZXhwcmVzcyB0aGUgcHVycG9zZToNCj4gDQo+IOKAnOKAneKAnQ0KPiBBIGNvbnNpc3RlbnQgdGVy bWlub2xvZ3kgd291bGQgaGVscCB3aXRoIHRoZSBjYXRlZ29yaXphdGlvbiBvZg0KPiBtb2RlbHMs IGFzc2lzdCBpbiB0aGUgYW5hbHlzaXMgdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBlZmZvcnRzIGlu IHRoZQ0KPiBJRVRGIGFuZCBvdGhlciBvcmdhbml6YXRpb25zLCBhbmQgYnJpbmcgY2xhcml0eSB0 byB0aGUgWUFORy1yZWxhdGVkDQo+IGRpc2N1c3Npb25zIGJldHdlZW4gdGhlIGRpZmZlcmVudCBn cm91cHMuDQo+IOKAnOKAnSINCj4gDQo+ICBBbmQgSeKAmXZlIHRoZW4gdHJpZWQgdG8gZXhwYW5k IGEgbGl0dGxlIGZ1cnRoZXIgaW4gc2VjdGlvbiAxLg0KPiANCj4gIEhhcHB5IHRvIHRha2UgZmVl ZGJhY2sgb24gaXQhDQo+IA0KPiA+IFdoZXJlIHRoZSBtb2RlbHMgYXJlIGluc3RhbnRpYXRlZCAt IG9uIGEgY29udHJvbGxlciwgb24gYSAiZGV2aWNlIiwgZXRjIC0gc2VlbXMgdG8gYmUgc2Vjb25k YXJ5IGFuZCBpbmNpZGVudGFsLiAgVGhlIGJvdW5kYXJpZXMgYXJlIGJsdXJyeSwgYW55d2F5cy4g IEEgY29udHJvbGxlciBpcyBhIGRldmljZSB0b287IHNvbWUgZGV2aWNlcyBtYXkgY29udGFpbiB2 aXJ0dWFsaXplZCBjb250cm9sbGVycywgYW5kIHNvIG9uLg0KPiANCj4gIFRoZSBhc3N1bXB0aW9u IGhlcmUgaXMgdGhhdCB0aGUgbG9jYXRpb24gaXMgaW5kZWVkIHVzZWZ1bCBhbmQgc3VnZ2VzdHMg dGhlIGNsYXNzaWZpY2F0aW9uIG9mIGRhdGEgbW9kZWxzIGludG8gdHdvIGRpc3RpbmN0IGFic3Ry YWN0aW9uIGxheWVycy4gVG9wb2xvZ3kgaXMgdGhlIGFyZWEgd2hlcmUgSSBoYWQgYSBzZW5zZSB0 aGF0IHRoZSBkZXZpY2UgYW5kIHNlcnZpY2UgY2xhc3NpZmljYXRpb24gbWF5IGJvdGggYXBwbHkg dG8gYSBzaW5nbGUgbW9kdWxlLg0KPiANCj4gPiBPbmUgbW9kZWwgdGhhdCBpcyByZWxldmFudCBp biB0aGlzIGRpc2N1c3Npb24gc2VlbXMgdG8gYmUgdGhlIFRNTiBtb2RlbCwgYXMgZGVmaW5lZCBp biBJVFUtVCBSZWNvbW1lbmRhdGlvbiBNLjMwMTAuICBUaGlzIG1vZGVsIGRlZmluZXMgYSBzZXQg b2YgbWFuYWdlbWVudCBsYXllcnMgLSBuZXR3b3JrIGVsZW1lbnQgKGRldmljZSksIG5ldHdvcmss IHNlcnZpY2UsIGJ1c2luZXNzIC0gd2l0aCB3ZWxsIGRlZmluZWQgZnVuY2lvbmFsIHNjb3BlIG9m IGVhY2ggbGF5ZXIuICBUaGUgbGF5ZXJzIC8gZnVuY3Rpb24gaGllcmFyY2h5IGFsc28gaW1wbHkg YW4gaW5mb3JtYXRpb24gIGFuZCBkYXRhIG1vZGVsIGhpZXJhcmNoeS4NCj4gDQo+ICBUaGUgY2xh c3NpZmljYXRpb24gaXMgZmFpcmx5IHdlbGwgYWxpZ25lZCB3aXRoIHRoZSBjb25jZXB0cyBpbiBN LjMwMTAsIGNvdmVyaW5nIHRoZSAiTmV0d29yayBtYW5hZ2VtZW504oCdIGFuZCDigJxFbGVtZW50 IG1hbmFnZW1lbnTigJ0gbGF5ZXJzLiBBdCBsZWFzdCB0aGF04oCZcyB0aGUgaW50ZW50IDotKQ0K PiANCj4gPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHNlZSBpZiB0aGUgbGF5ZXJpbmcgaW4gTS4z MDEwIGNvdWxkIGhlbHAgZ3VpZGUgWUFORyBtb2RlbCBjbGFzc2lmaWNhdGlvbiwgYW5kIHJlZmVy ZW5jZSB0aG9zZSBkZWZpbml0aW9ucz8NCj4gDQo+ICBXb3VsZCBiZSB2ZXJ5IGhhcHB5IHRvIGhl YXIgaWYgeW91IGZpbmQgd2UgZGV2aWF0ZSAob3IgbGFjaykgY29uY2VwdHMgb3IgdXNlZnVsIGZl YXR1cmVzIGZyb20gTS4zMDEwIHRoYXQgd291bGQgbWFrZSB0aGUgY2xhc3NpZmljYXRpb24gbW9y ZSB1c2VmdWwuDQo+IA0KPiA+IC0tLSBBbGV4DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKQ0KPiA+IFNlbnQ6IFRodXJzZGF5 LCBBcHJpbCAwNywgMjAxNiAxOjU3IEFNDQo+ID4gVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEg LSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4NCj4gPiBDYzogbmV0bW9kQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY2xhc3NpZmljYXRpb24/DQo+ ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBDYXJsIE1vYmVyZw0KPiA+IFRlY2hub2xvZ3kgRGly ZWN0b3IsIENWRw0KPiA+IGNhbW9iZXJnQGNpc2NvLmNvbQ0KPiA+DQo+ID4+IE9uIEFwciA3LCAy MDE2LCBhdCAxMDo1NSBBTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5z Y2hhcmZAbm9raWEuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4+IEkgY29tZSBhdCB0aGlzIGZyb20g dGhlIGNsYXNzaWZpY2F0aW9uIGFuZ2xlLCBzbyBteSBpbnRlcmVzdCBpcyBpZg0KPiA+Pj4gdGhl IGFzc3VtcHRpb24gdGhhdCBhIFlBTkcgbW9kZWwgY2FuIG9ubHkgYmUgY2xhc3NpZmllZCBhcyBh IG5ldHdvcmsNCj4gPj4+IHNlcnZpY2UgbW9kZWwgWE9SIGEgbmV0d29yayBkZXZpY2UgbW9kZWwg YWNjb3JkaW5nIHRvIHRoZSBkZWZpbml0aW9ucw0KPiA+Pj4gaW4gZHJhZnQtaWV0Zi1uZXRtb2Qt eWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiAoc2VjdGlvbnMgMi4xIGFuZA0KPiA+Pj4gMi4yKS4g QmFzZWQgb24gdGhpcyBkaXNjdXNzaW9uIEkgdGFrZSBpdCB0aGF0IHNvbWUgbW9kZWxzIGFyZSBp bnRlbmRlZCB0byBiZSBhYmxlIHRvIHNlcnZlIGluIGJvdGggcm9sZXMuIEFuZCB3ZSBzaG91bGQg bWFrZSBzdXJlIHRoYXQgaXTigJlzIHN1cHBvcnRlZCBpbiBvdXIgY2F0YWxvZyBzdHJ1Y3R1cmUu DQo+ID4+DQo+ID4+IFJlZ2FyZGluZyB0aGUgWE9SIGFzc3VtcHRpb24gZm9yIGNsYXNzaWZpY2F0 aW9uOg0KPiA+Pg0KPiA+PiBZb3UgbWF5IGFsc28gd2FudCB0byB0aGluayBhYm91dCBZQU5HIG1v ZGVscyB0aGF0IGFyZSBORUlUSEVSIGRldmljZSBOT1Igc2VydmljZSBtb2RlbHMuIEZvciBpbnN0 YW5jZSwgd2hhdCBhYm91dCBSRkMgNjk5MT8gQW5kIEkgdGhpbmsgb3RoZXIsIG1vcmUgdGVjaG5p Y2FsIG1vZGVscyBwcmVzZW50ZWQgdGhpcyB3ZWVrIG1heSBmYWxsIGludG8gYSBzaW1pbGFyIGNh dGVnb3J5ICgiZ2VuZXJpYyI/KS4NCj4gPg0KPiA+IFZlcnkgZ29vZCBwb2ludCwgdGhhbmtzISBU aGF0IHdpbGwgbmVlZCBzb21lIGFkZGl0aW9uYWwgdGhpbmtpbmcgYW5kIHdyaXRpbmcuDQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRt b2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0 bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kDQo+IA0KDQo= From nobody Fri Apr 8 06:32:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2759712D8BE for ; Fri, 8 Apr 2016 06:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbA_PXxrI822 for ; Fri, 8 Apr 2016 06:32:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7588412D8AB for ; Fri, 8 Apr 2016 06:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1175; q=dns/txt; s=iport; t=1460122358; x=1461331958; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OzPjInnm+uApJVOSrq/wtceqe8WFC4EZWntB85LSkDc=; b=mPliHDjfwmYC0Fjr4mrJiaJDnHyb8xiE+JywRiIbWsVr9H6ju1fZ4wnE 7T731jVwRBCr4nnIFDqs4LHLAfiSYcm1XqoCSM5ugHbjgwPdXhFvwgKHX FE5Euz4w/gkf93rOX25tLbbbaZfPG/ndZ8x2OA7xXMMzhCJICb7YMzwsd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQDzsQdX/4wNJK1ZA4M3U4EDuj8BD?= =?us-ascii?q?YFzHYVwAoE0OBQBAQEBAQEBZSeEQQEBAQMBOj8FCQICAQgOAgUDHhAbFyUCBA4?= =?us-ascii?q?NiBcIwFQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIYdhEuEYCaFDwWYBAGOBI8Uj?= =?us-ascii?q?yQBHgEBQoNniSd+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="89666925" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 13:32:37 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38DWas5026443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 13:32:36 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 09:32:35 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 09:32:35 -0400 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements Thread-Index: AQHRjx7t1dIqVaLFu0y/L6aVF65SwZ9/UkiggACacwCAACUOQA== Date: Fri, 8 Apr 2016 13:32:35 +0000 Message-ID: References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> <20160408065748.GA66159@elstar.local> In-Reply-To: <20160408065748.GA66159@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.76.129] 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] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:32:40 -0000 > From: Juergen Schoenwaelder, April 08, 2016 2:58 AM >=20 > On Fri, Apr 08, 2016 at 02:20:19AM +0000, Eric Voit (evoit) wrote: > > My thinking matches more closely to what Kent lays out above: > > > > schema-mount > > data-mount > > remote data mount (a.k.a. peer mount) > > local data mount (a.k.a. alias mount) > > > > The value in the term "yang mount" is that it provides a conceptual umb= rella to > ensure a cohesive syntax across the four valid permutations of the above.= The > term itself was never intended to be implementable. > > >=20 > So why do we need 'local data mount' (aka 'alias mount')? Which problem d= oes > it solve that 'peer mounting' localhost does not solve? To me it comes down to ease of use for the developer. If the system only al= lows mounting localhost, why require that parameter in the syntax? That p= arameter shouldn't even be available/visible for entry.=20 Eric > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 8 06:36:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E5812D12D for ; Fri, 8 Apr 2016 06:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcWDXI0sjjMl for ; Fri, 8 Apr 2016 06:36:48 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B073612D0FF for ; Fri, 8 Apr 2016 06:36:47 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id c126so79371248lfb.2 for ; Fri, 08 Apr 2016 06:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=pAXYC60SGKOOs64Mhlj96TZqR4ihzyZJYF0Ksf72PTk=; b=wE780Dk7CFTdH28/CFXrZxLsdOr4vf2xiC77g4A7NB+XAqADFc6sn/ClU0xnvgJ9nH bnEYugy2Yy4lhFLixs3E9efIWQhbowqTnDWwQfGPG1T6z53d5o5t5P5PL1sx+xydCcz7 vgO2QBqlqbD88m6NC/f/eDo2t3hjAREzPt6ua/bCmb3Rimdm5ejhGdLfaOZbdxKE+oj5 XkkdUl7Hc1KlkINkrt7zh6XsWxNOA2yXdNxehuyw7RaKx4AOz/lNStk32HA5K4teKZV5 E02aHxdTp+EJeRIfPzHzmI4BosTVG3JK07VH8XGaw1ErY0XlRwZ99CUuLMybyaelU7br OHgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=pAXYC60SGKOOs64Mhlj96TZqR4ihzyZJYF0Ksf72PTk=; b=lpTGDC8aFNXVHwpR4auGl8IGhq/aQWZp9TE7/27OCNIPkMDQ5YrIPNv6eYtnmzI9fc o5T+RmeULkhaYp3YCMVxivA8rrTStUs870uVJ8bYg78h/NKsCWHmizHBxs+MnTVReo24 kKCjGt3L4+MtvoCufUMtBq1L4OkfKUnCGunnqZBK5ZwcXlm7OEFrRNQNNMBa3zsh75wr panLx/cvYh9hIsnNXmeQcT8gy8bdNmWwsZBObgbSQsP8JVnKSSzDppTRzWAHu38kzyBb MBFLEZ2YjEiZt9MjDkbukKUIihMFuX1Tp1GPho69WJpMZq3Lm8xhgVBVHnEnkvEqoAlX BbkA== X-Gm-Message-State: AD7BkJK0gmgc++S1znDdhkyU5xiSY0BlUDyiQ+c+yAAYPLSK00uRg+VoG9cTJBMgYr75+xKOYmrnYN9xTTneTg== MIME-Version: 1.0 X-Received: by 10.25.27.200 with SMTP id b191mr3875705lfb.8.1460122605902; Fri, 08 Apr 2016 06:36:45 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Fri, 8 Apr 2016 06:36:45 -0700 (PDT) In-Reply-To: <6E7F5A13-FB4A-4CCB-AA43-39F7718D38EF@cisco.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <6E7F5A13-FB4A-4CCB-AA43-39F7718D38EF@cisco.com> Date: Fri, 8 Apr 2016 06:36:45 -0700 Message-ID: From: Andy Bierman To: "Carl Moberg (camoberg)" Content-Type: multipart/alternative; boundary=001a11402c4840f3aa052ff949f9 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:36:51 -0000 --001a11402c4840f3aa052ff949f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 8, 2016 at 6:18 AM, Carl Moberg (camoberg) wrote: > > > On Apr 8, 2016, at 3:10 PM, Andy Bierman wrote: > > > > Hi, > > > > > > It is not that clear how the different types of modules or layers > > impact the task of designing a YANG module. It seems like > > vendor vs. standard or device vs. service are somewhat arbitrary, > > especially if virtualization is considered. > > > The intent of the classification is (imho) not intended to have much > impact on how to design a module. Rather to provide a taxonomy to classif= y > models when they are done (or being developed). > > I don=E2=80=99t see how virtualization would have an impact, any suggest= ions? > No suggestions other than the hierarchy of controller to device is not always static. Am I allowed to build a service layer on top of another service layer? (e.g, NMS --> EMS --> NE). Am I allowed to treat an entire data center as a device in a high level application? > > > The terminology would be more relevant if the differences in > > content of each type of module were clear. > > The first paragraphs of the main sections (2.1, 2.2, 3.1-3.3) are > meant(!) to explain this. Could you expand on what you think is missing? > No -- this is an Informational draft. The content does not have to be actionable. It only has to be informative. For decades SNMP completely ignored anything above the NE as out of scope. We are making some progress just by considering the possibility of standard functionality at the controller layer. > > Andy > > > > > > > On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) < > camoberg@cisco.com> wrote: > > > > > On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) > wrote: > > > > > > I am wondering what purpose the classification really serves. At the > end of the day, it seems to me that we are trying to express a model > hierarchy, and articulate what the layers in the hierarchy are. A device > model is thus at a lower layer than a service model. An implementation o= f > the service model may in turn have dependencies on the device model, but > not the other way round. > > > > The abstract tries to express the purpose: > > > > =E2=80=9C=E2=80=9D=E2=80=9D > > A consistent terminology would help with the categorization of > > models, assist in the analysis the YANG data modeling efforts in the > > IETF and other organizations, and bring clarity to the YANG-related > > discussions between the different groups. > > =E2=80=9C=E2=80=9D" > > > > And I=E2=80=99ve then tried to expand a little further in section 1. > > > > Happy to take feedback on it! > > > > > Where the models are instantiated - on a controller, on a "device", > etc - seems to be secondary and incidental. The boundaries are blurry, > anyways. A controller is a device too; some devices may contain > virtualized controllers, and so on. > > > > The assumption here is that the location is indeed useful and suggests > the classification of data models into two distinct abstraction layers. > Topology is the area where I had a sense that the device and service > classification may both apply to a single module. > > > > > One model that is relevant in this discussion seems to be the TMN > model, as defined in ITU-T Recommendation M.3010. This model defines a s= et > of management layers - network element (device), network, service, busine= ss > - with well defined funcional scope of each layer. The layers / function > hierarchy also imply an information and data model hierarchy. > > > > The classification is fairly well aligned with the concepts in M.3010, > covering the "Network management=E2=80=9D and =E2=80=9CElement management= =E2=80=9D layers. At least > that=E2=80=99s the intent :-) > > > > > Would it make sense to see if the layering in M.3010 could help guide > YANG model classification, and reference those definitions? > > > > Would be very happy to hear if you find we deviate (or lack) concepts > or useful features from M.3010 that would make the classification more > useful. > > > > > --- Alex > > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Carl > Moberg (camoberg) > > > Sent: Thursday, April 07, 2016 1:57 AM > > > To: Scharf, Michael (Nokia - DE) > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] YANG model classification? > > > > > > > > > > > > -- > > > Carl Moberg > > > Technology Director, CVG > > > camoberg@cisco.com > > > > > >> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > >> > > >>> I come at this from the classification angle, so my interest is if > > >>> the assumption that a YANG model can only be classified as a networ= k > > >>> service model XOR a network device model according to the definitio= ns > > >>> in draft-ietf-netmod-yang-model-classification (sections 2.1 and > > >>> 2.2). Based on this discussion I take it that some models are > intended to be able to serve in both roles. And we should make sure that > it=E2=80=99s supported in our catalog structure. > > >> > > >> Regarding the XOR assumption for classification: > > >> > > >> You may also want to think about YANG models that are NEITHER device > NOR service models. For instance, what about RFC 6991? And I think other, > more technical models presented this week may fall into a similar categor= y > ("generic"?). > > > > > > Very good point, thanks! That will need some additional thinking and > writing. > > > _______________________________________________ > > > 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 > > > > --001a11402c4840f3aa052ff949f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 8, 2016 at 6:18 AM, Carl Moberg (camoberg) <camoberg@cisc= o.com> wrote:

> On Apr 8, 2016, at 3:10 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> It is not that clear how the different types of modules or layers
> impact the task of designing a YANG module.=C2=A0 It seems like
> vendor vs. standard or device vs. service are somewhat arbitrary,
> especially if virtualization is considered.


=C2=A0The intent of the classification is (imho) not intended to have much = impact on how to design a module. Rather to provide a taxonomy to classify = models when they are done (or being developed).

=C2=A0I don=E2=80=99t see how virtualization would have an impact, any sugg= estions?

No suggestions other than the = hierarchy of controller to device is not always static.
Am I allo= wed to build a service layer on top of another service layer?
(e.= g, =C2=A0NMS --> EMS --> NE).=C2=A0 Am I allowed to treat an entire d= ata center
as a device in a high level application?
=C2= =A0

> The terminology would be more relevant if the differences in
> content of each type of module were clear.

=C2=A0The first paragraphs of the main sections (2.1, 2.2, 3.1-3.3) are mea= nt(!) to explain this. Could you expand on what you think is missing?

No -- this is an Informational draft.
<= div>The content does not have to be actionable.=C2=A0 It only
has= to be informative.

For decades SNMP completely ig= nored anything above the NE as out of scope.
We are making some p= rogress just by considering the possibility of standard
functiona= lity at the controller layer.


> Andy
=C2=A0
>
>
> On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) <camoberg@cisco.com> wrote:
>
> > On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:
> >
> > I am wondering what purpose the classification really serves.=C2= =A0 At the end of the day, it seems to me that we are trying to express a m= odel hierarchy, and articulate what the layers in the hierarchy are.=C2=A0 = A device model is thus at a lower layer than a service model.=C2=A0 An impl= ementation of the service model may in turn have dependencies on the device= model, but not the other way round.
>
>=C2=A0 The abstract tries to express the purpose:
>
> =E2=80=9C=E2=80=9D=E2=80=9D
> A consistent terminology would help with the categorization of
> models, assist in the analysis the YANG data modeling efforts in the > IETF and other organizations, and bring clarity to the YANG-related > discussions between the different groups.
> =E2=80=9C=E2=80=9D"
>
>=C2=A0 And I=E2=80=99ve then tried to expand a little further in sectio= n 1.
>
>=C2=A0 Happy to take feedback on it!
>
> > Where the models are instantiated - on a controller, on a "d= evice", etc - seems to be secondary and incidental.=C2=A0 The boundari= es are blurry, anyways.=C2=A0 A controller is a device too; some devices ma= y contain virtualized controllers, and so on.
>
>=C2=A0 The assumption here is that the location is indeed useful and su= ggests the classification of data models into two distinct abstraction laye= rs. Topology is the area where I had a sense that the device and service cl= assification may both apply to a single module.
>
> > One model that is relevant in this discussion seems to be the TMN= model, as defined in ITU-T Recommendation M.3010.=C2=A0 This model defines= a set of management layers - network element (device), network, service, b= usiness - with well defined funcional scope of each layer.=C2=A0 The layers= / function hierarchy also imply an information=C2=A0 and data model hierar= chy.
>
>=C2=A0 The classification is fairly well aligned with the concepts in M= .3010, covering the "Network management=E2=80=9D and =E2=80=9CElement = management=E2=80=9D layers. At least that=E2=80=99s the intent :-)
>
> > Would it make sense to see if the layering in M.3010 could help g= uide YANG model classification, and reference those definitions?
>
>=C2=A0 Would be very happy to hear if you find we deviate (or lack) con= cepts or useful features from M.3010 that would make the classification mor= e useful.
>
> > --- Alex
> >
> > -----Original Message-----
> > From: netmod [mailto:n= etmod-bounces@ietf.org] On Behalf Of Carl Moberg (camoberg)
> > Sent: Thursday, April 07, 2016 1:57 AM
> > To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] YANG model classification?
> >
> >
> >
> > --
> > Carl Moberg
> > Technology Director, CVG
> > camoberg@cisco.com
> >
> >> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) <= ;michael.scharf@nokia.com&g= t; wrote:
> >>
> >>> I come at this from the classification angle, so my inter= est is if
> >>> the assumption that a YANG model can only be classified a= s a network
> >>> service model XOR a network device model according to the= definitions
> >>> in draft-ietf-netmod-yang-model-classification (sections = 2.1 and
> >>> 2.2). Based on this discussion I take it that some models= are intended to be able to serve in both roles. And we should make sure th= at it=E2=80=99s supported in our catalog structure.
> >>
> >> Regarding the XOR assumption for classification:
> >>
> >> You may also want to think about YANG models that are NEITHER= device NOR service models. For instance, what about RFC 6991? And I think = other, more technical models presented this week may fall into a similar ca= tegory ("generic"?).
> >
> > Very good point, thanks! That will need some additional thinking = and writing.
> > _______________________________________________
> > 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 >


--001a11402c4840f3aa052ff949f9-- From nobody Fri Apr 8 09:52:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B42F12D5CE for ; Fri, 8 Apr 2016 09:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn3LKNouv-xt for ; Fri, 8 Apr 2016 09:52:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E8D12D1D7 for ; Fri, 8 Apr 2016 09:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9656; q=dns/txt; s=iport; t=1460134357; x=1461343957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5X1F1qsizZJABZ4VuYjUWCOQ7A06M12TQ2obHmyHvc0=; b=OzrMEcl+aUF8YTurGuuqOPn25UUqndMHGsBuJNu3PQ0tqiiOniKdRSMz vlFpa7uNuPDoMis7dcuhc5pZ8Xz/pq3f1RFw6lZwTscLMd4b5BjcMc92M WSqVLz0zEqPy8/O7Qz/VVP252JFCVRs/S1Q/vpElAKSo1aVSNsbGiCwIB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgBd4AdX/4MNJK1cgzdTfQa6PwENg?= =?us-ascii?q?XMXCoUiSgIcgRc4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgBA06CwUHBAIBBgIRBAE?= =?us-ascii?q?BAQICIwMCAgIlCxQBCAgCBA4FiB8IDpFQnReRfwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEfIUlgXUIgk6HPyuCKwEEiVqOKgGOC48NjyQBHgEBQoNnbIg7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="259069501" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 16:52:35 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u38GqZZw015721 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 16:52:35 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 11:52:34 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 11:52:34 -0500 From: "Carl Moberg (camoberg)" To: Andy Bierman Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoAABkQdAAAPpD0AAAGkXYAAABFJgAAQS7qAACnPDwAAAQO6gAAAS9kAAACjK4AABtZwAA== Date: Fri, 8 Apr 2016 16:52:34 +0000 Message-ID: <6210B927-9173-415C-A476-ADAF1051F145@cisco.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <6E7F5A13-FB4A-4CCB-AA43-39F7718D38EF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.155] Content-Type: text/plain; charset="utf-8" Content-ID: <65C53ACC33AB8C448F118E809F6FEA1F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:52:39 -0000 DQo+IE9uIEFwciA4LCAyMDE2LCBhdCAzOjM2IFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gDQo+IE9uIEZyaSwgQXByIDgsIDIwMTYgYXQgNjox OCBBTSwgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSA8Y2Ftb2JlcmdAY2lzY28uY29tPiB3cm90ZToN Cj4gDQo+ID4gT24gQXByIDgsIDIwMTYsIGF0IDM6MTAgUE0sIEFuZHkgQmllcm1hbiA8YW5keUB5 dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4NCj4gPiBJdCBpcyBu b3QgdGhhdCBjbGVhciBob3cgdGhlIGRpZmZlcmVudCB0eXBlcyBvZiBtb2R1bGVzIG9yIGxheWVy cw0KPiA+IGltcGFjdCB0aGUgdGFzayBvZiBkZXNpZ25pbmcgYSBZQU5HIG1vZHVsZS4gIEl0IHNl ZW1zIGxpa2UNCj4gPiB2ZW5kb3IgdnMuIHN0YW5kYXJkIG9yIGRldmljZSB2cy4gc2VydmljZSBh cmUgc29tZXdoYXQgYXJiaXRyYXJ5LA0KPiA+IGVzcGVjaWFsbHkgaWYgdmlydHVhbGl6YXRpb24g aXMgY29uc2lkZXJlZC4NCj4gDQo+IA0KPiAgVGhlIGludGVudCBvZiB0aGUgY2xhc3NpZmljYXRp b24gaXMgKGltaG8pIG5vdCBpbnRlbmRlZCB0byBoYXZlIG11Y2ggaW1wYWN0IG9uIGhvdyB0byBk ZXNpZ24gYSBtb2R1bGUuIFJhdGhlciB0byBwcm92aWRlIGEgdGF4b25vbXkgdG8gY2xhc3NpZnkg bW9kZWxzIHdoZW4gdGhleSBhcmUgZG9uZSAob3IgYmVpbmcgZGV2ZWxvcGVkKS4NCj4gDQo+ICBJ IGRvbuKAmXQgc2VlIGhvdyB2aXJ0dWFsaXphdGlvbiB3b3VsZCBoYXZlIGFuIGltcGFjdCwgYW55 IHN1Z2dlc3Rpb25zPw0KPiANCj4gTm8gc3VnZ2VzdGlvbnMgb3RoZXIgdGhhbiB0aGUgaGllcmFy Y2h5IG9mIGNvbnRyb2xsZXIgdG8gZGV2aWNlIGlzIG5vdCBhbHdheXMgc3RhdGljLg0KPiBBbSBJ IGFsbG93ZWQgdG8gYnVpbGQgYSBzZXJ2aWNlIGxheWVyIG9uIHRvcCBvZiBhbm90aGVyIHNlcnZp Y2UgbGF5ZXI/DQo+IChlLmcsICBOTVMgLS0+IEVNUyAtLT4gTkUpLiAgQW0gSSBhbGxvd2VkIHRv IHRyZWF0IGFuIGVudGlyZSBkYXRhIGNlbnRlcg0KPiBhcyBhIGRldmljZSBpbiBhIGhpZ2ggbGV2 ZWwgYXBwbGljYXRpb24/DQo+IA0KDQogVGhlIGRyYWZ0IGlzIGRlZmluaXRlbHkgbm90IHN1cHBv c2VkIHRvIHRlbGwgeW91IHdoYXQgeW91IGFyZSBhbGxvd2VkIHRvIGRvLCBidXQgaXQgZG9lcyBh c3BpcmUgdG8gYSB1c2VmdWwgY2xhc3NpZmljYXRpb24gb2Ygd2hhdCBwZW9wbGUgYXJlIGRvaW5n IDotKQ0KDQogU28sIHRvIHlvdXIgcXVlc3Rpb25zOg0KDQogMS4g4oCcLi4uYSBzZXJ2aWNlIGxh eWVyIG9uIHRvcCBvZiBhbm90aGVyIHNlcnZpY2UgbGF5ZXI/Ig0KDQogRnJvbSBzZWN0aW9uIDIu MToNCg0K4oCc4oCd4oCd4oCdDQpUaGUgY29tcG9uZW50LWJhc2VkIGFwcHJvYWNoIGNhcHR1cmVz IGRldmljZS1jZW50cmljIGZlYXR1cmVzIChlLmcuDQp0aGUgZGVmaW5pdGlvbiBvZiBhIFZSRiwg cm91dGluZyBwcm90b2NvbHMsIG9yIHBhY2tldCBmaWx0ZXJpbmcpIGluIGENCnZlbmRvci1pbmRl cGVuZGVudCBtYW5uZXIuICBUaGUgY29tcG9uZW50cyBhcmUgZGVzaWduZWQgZm9yIHJldXNlDQph Y3Jvc3MgbWFueSBzZXJ2aWNlcy4gIFRoZSBzZXQgb2YgY29tcG9uZW50cyByZXF1aXJlZCBmb3Ig YSBzcGVjaWZpYw0Kc2VydmljZSBpcyB0aGVuIGNvbXBvc2VkIGludG8gdGhlIGhpZ2hlci1sZXZl bCBzZXJ2aWNlLiAgVGhlDQpjb21wb25lbnQtYmFzZWQgYXBwcm9hY2ggaGFzIHRoZSBhZHZhbnRh Z2VzIG9mIG1vZHVsYXIgZGV2ZWxvcG1lbnQNCmluY2x1ZGluZyBhIGhpZ2hlciBkZWdyZWUgb2Yg cmV1c2FiaWxpdHkgYXQgdGhlIGV4cGVuc2Ugb2YgaW5pdGlhbA0Kc3BlZWQuDQrigJzigJ3igJ0N Cg0KDQogMi4g4oCcLi4udG8gdHJlYXQgYW4gZW50aXJlIGRhdGEgY2VudGVyIGFzIGEgZGV2aWNl IGluIGEgaGlnaCBsZXZlbCBhcHBsaWNhdGlvbj8iDQoNCuKAnOKAneKAnQ0KTmV0d29yayBFbGVt ZW50IFlBTkcgRGF0YSBNb2RlbHMgZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24sIHN0YXRlDQpk YXRhIGFuZCBvcGVyYXRpb25zIG9mIGEgbmV0d29yayBkZXZpY2UgYXMgZGVmaW5lZCBieSB0aGUg dmVuZG9yIG9mDQp0aGF0IGRldmljZS4gIFRoZSBtb2RlbHMgYXJlIGNvbW1vbmx5IHN0cnVjdHVy ZWQgYXJvdW5kIGZlYXR1cmVzIG9mDQp0aGUgZGV2aWNlLi4uDQrigJzigJ0iDQoNCj4gPiBUaGUg dGVybWlub2xvZ3kgd291bGQgYmUgbW9yZSByZWxldmFudCBpZiB0aGUgZGlmZmVyZW5jZXMgaW4N Cj4gPiBjb250ZW50IG9mIGVhY2ggdHlwZSBvZiBtb2R1bGUgd2VyZSBjbGVhci4NCj4gDQo+ICBU aGUgZmlyc3QgcGFyYWdyYXBocyBvZiB0aGUgbWFpbiBzZWN0aW9ucyAoMi4xLCAyLjIsIDMuMS0z LjMpIGFyZSBtZWFudCghKSB0byBleHBsYWluIHRoaXMuIENvdWxkIHlvdSBleHBhbmQgb24gd2hh dCB5b3UgdGhpbmsgaXMgbWlzc2luZz8NCj4gDQo+IE5vIC0tIHRoaXMgaXMgYW4gSW5mb3JtYXRp b25hbCBkcmFmdC4NCj4gVGhlIGNvbnRlbnQgZG9lcyBub3QgaGF2ZSB0byBiZSBhY3Rpb25hYmxl LiAgSXQgb25seQ0KPiBoYXMgdG8gYmUgaW5mb3JtYXRpdmUuDQo+IA0KPiBGb3IgZGVjYWRlcyBT Tk1QIGNvbXBsZXRlbHkgaWdub3JlZCBhbnl0aGluZyBhYm92ZSB0aGUgTkUgYXMgb3V0IG9mIHNj b3BlLg0KPiBXZSBhcmUgbWFraW5nIHNvbWUgcHJvZ3Jlc3MganVzdCBieSBjb25zaWRlcmluZyB0 aGUgcG9zc2liaWxpdHkgb2Ygc3RhbmRhcmQNCj4gZnVuY3Rpb25hbGl0eSBhdCB0aGUgY29udHJv bGxlciBsYXllci4NCj4gDQo+IA0KPiA+IEFuZHkNCj4gIA0KPiA+DQo+ID4NCj4gPiBPbiBGcmks IEFwciA4LCAyMDE2IGF0IDU6NDAgQU0sIENhcmwgTW9iZXJnIChjYW1vYmVyZykgPGNhbW9iZXJn QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiA+IE9uIEFwciA3LCAyMDE2LCBhdCA2OjQzIFBN LCBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIDxhbGV4QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPg0K PiA+ID4gSSBhbSB3b25kZXJpbmcgd2hhdCBwdXJwb3NlIHRoZSBjbGFzc2lmaWNhdGlvbiByZWFs bHkgc2VydmVzLiAgQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBpdCBzZWVtcyB0byBtZSB0aGF0IHdl IGFyZSB0cnlpbmcgdG8gZXhwcmVzcyBhIG1vZGVsIGhpZXJhcmNoeSwgYW5kIGFydGljdWxhdGUg d2hhdCB0aGUgbGF5ZXJzIGluIHRoZSBoaWVyYXJjaHkgYXJlLiAgQSBkZXZpY2UgbW9kZWwgaXMg dGh1cyBhdCBhIGxvd2VyIGxheWVyIHRoYW4gYSBzZXJ2aWNlIG1vZGVsLiAgQW4gaW1wbGVtZW50 YXRpb24gb2YgdGhlIHNlcnZpY2UgbW9kZWwgbWF5IGluIHR1cm4gaGF2ZSBkZXBlbmRlbmNpZXMg b24gdGhlIGRldmljZSBtb2RlbCwgYnV0IG5vdCB0aGUgb3RoZXIgd2F5IHJvdW5kLg0KPiA+DQo+ ID4gIFRoZSBhYnN0cmFjdCB0cmllcyB0byBleHByZXNzIHRoZSBwdXJwb3NlOg0KPiA+DQo+ID4g 4oCc4oCd4oCdDQo+ID4gQSBjb25zaXN0ZW50IHRlcm1pbm9sb2d5IHdvdWxkIGhlbHAgd2l0aCB0 aGUgY2F0ZWdvcml6YXRpb24gb2YNCj4gPiBtb2RlbHMsIGFzc2lzdCBpbiB0aGUgYW5hbHlzaXMg dGhlIFlBTkcgZGF0YSBtb2RlbGluZyBlZmZvcnRzIGluIHRoZQ0KPiA+IElFVEYgYW5kIG90aGVy IG9yZ2FuaXphdGlvbnMsIGFuZCBicmluZyBjbGFyaXR5IHRvIHRoZSBZQU5HLXJlbGF0ZWQNCj4g PiBkaXNjdXNzaW9ucyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgZ3JvdXBzLg0KPiA+IOKAnOKAnSIN Cj4gPg0KPiA+ICBBbmQgSeKAmXZlIHRoZW4gdHJpZWQgdG8gZXhwYW5kIGEgbGl0dGxlIGZ1cnRo ZXIgaW4gc2VjdGlvbiAxLg0KPiA+DQo+ID4gIEhhcHB5IHRvIHRha2UgZmVlZGJhY2sgb24gaXQh DQo+ID4NCj4gPiA+IFdoZXJlIHRoZSBtb2RlbHMgYXJlIGluc3RhbnRpYXRlZCAtIG9uIGEgY29u dHJvbGxlciwgb24gYSAiZGV2aWNlIiwgZXRjIC0gc2VlbXMgdG8gYmUgc2Vjb25kYXJ5IGFuZCBp bmNpZGVudGFsLiAgVGhlIGJvdW5kYXJpZXMgYXJlIGJsdXJyeSwgYW55d2F5cy4gIEEgY29udHJv bGxlciBpcyBhIGRldmljZSB0b287IHNvbWUgZGV2aWNlcyBtYXkgY29udGFpbiB2aXJ0dWFsaXpl ZCBjb250cm9sbGVycywgYW5kIHNvIG9uLg0KPiA+DQo+ID4gIFRoZSBhc3N1bXB0aW9uIGhlcmUg aXMgdGhhdCB0aGUgbG9jYXRpb24gaXMgaW5kZWVkIHVzZWZ1bCBhbmQgc3VnZ2VzdHMgdGhlIGNs YXNzaWZpY2F0aW9uIG9mIGRhdGEgbW9kZWxzIGludG8gdHdvIGRpc3RpbmN0IGFic3RyYWN0aW9u IGxheWVycy4gVG9wb2xvZ3kgaXMgdGhlIGFyZWEgd2hlcmUgSSBoYWQgYSBzZW5zZSB0aGF0IHRo ZSBkZXZpY2UgYW5kIHNlcnZpY2UgY2xhc3NpZmljYXRpb24gbWF5IGJvdGggYXBwbHkgdG8gYSBz aW5nbGUgbW9kdWxlLg0KPiA+DQo+ID4gPiBPbmUgbW9kZWwgdGhhdCBpcyByZWxldmFudCBpbiB0 aGlzIGRpc2N1c3Npb24gc2VlbXMgdG8gYmUgdGhlIFRNTiBtb2RlbCwgYXMgZGVmaW5lZCBpbiBJ VFUtVCBSZWNvbW1lbmRhdGlvbiBNLjMwMTAuICBUaGlzIG1vZGVsIGRlZmluZXMgYSBzZXQgb2Yg bWFuYWdlbWVudCBsYXllcnMgLSBuZXR3b3JrIGVsZW1lbnQgKGRldmljZSksIG5ldHdvcmssIHNl cnZpY2UsIGJ1c2luZXNzIC0gd2l0aCB3ZWxsIGRlZmluZWQgZnVuY2lvbmFsIHNjb3BlIG9mIGVh Y2ggbGF5ZXIuICBUaGUgbGF5ZXJzIC8gZnVuY3Rpb24gaGllcmFyY2h5IGFsc28gaW1wbHkgYW4g aW5mb3JtYXRpb24gIGFuZCBkYXRhIG1vZGVsIGhpZXJhcmNoeS4NCj4gPg0KPiA+ICBUaGUgY2xh c3NpZmljYXRpb24gaXMgZmFpcmx5IHdlbGwgYWxpZ25lZCB3aXRoIHRoZSBjb25jZXB0cyBpbiBN LjMwMTAsIGNvdmVyaW5nIHRoZSAiTmV0d29yayBtYW5hZ2VtZW504oCdIGFuZCDigJxFbGVtZW50 IG1hbmFnZW1lbnTigJ0gbGF5ZXJzLiBBdCBsZWFzdCB0aGF04oCZcyB0aGUgaW50ZW50IDotKQ0K PiA+DQo+ID4gPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHNlZSBpZiB0aGUgbGF5ZXJpbmcgaW4g TS4zMDEwIGNvdWxkIGhlbHAgZ3VpZGUgWUFORyBtb2RlbCBjbGFzc2lmaWNhdGlvbiwgYW5kIHJl ZmVyZW5jZSB0aG9zZSBkZWZpbml0aW9ucz8NCj4gPg0KPiA+ICBXb3VsZCBiZSB2ZXJ5IGhhcHB5 IHRvIGhlYXIgaWYgeW91IGZpbmQgd2UgZGV2aWF0ZSAob3IgbGFjaykgY29uY2VwdHMgb3IgdXNl ZnVsIGZlYXR1cmVzIGZyb20gTS4zMDEwIHRoYXQgd291bGQgbWFrZSB0aGUgY2xhc3NpZmljYXRp b24gbW9yZSB1c2VmdWwuDQo+ID4NCj4gPiA+IC0tLSBBbGV4DQo+ID4gPg0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKQ0KPiA+ ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDE6NTcgQU0NCj4gPiA+IFRvOiBTY2hh cmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+DQo+ID4g PiBDYzogbmV0bW9kQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBt b2RlbCBjbGFzc2lmaWNhdGlvbj8NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tDQo+ID4g PiBDYXJsIE1vYmVyZw0KPiA+ID4gVGVjaG5vbG9neSBEaXJlY3RvciwgQ1ZHDQo+ID4gPiBjYW1v YmVyZ0BjaXNjby5jb20NCj4gPiA+DQo+ID4gPj4gT24gQXByIDcsIDIwMTYsIGF0IDEwOjU1IEFN LCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+ IHdyb3RlOg0KPiA+ID4+DQo+ID4gPj4+IEkgY29tZSBhdCB0aGlzIGZyb20gdGhlIGNsYXNzaWZp Y2F0aW9uIGFuZ2xlLCBzbyBteSBpbnRlcmVzdCBpcyBpZg0KPiA+ID4+PiB0aGUgYXNzdW1wdGlv biB0aGF0IGEgWUFORyBtb2RlbCBjYW4gb25seSBiZSBjbGFzc2lmaWVkIGFzIGEgbmV0d29yaw0K PiA+ID4+PiBzZXJ2aWNlIG1vZGVsIFhPUiBhIG5ldHdvcmsgZGV2aWNlIG1vZGVsIGFjY29yZGlu ZyB0byB0aGUgZGVmaW5pdGlvbnMNCj4gPiA+Pj4gaW4gZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1t b2RlbC1jbGFzc2lmaWNhdGlvbiAoc2VjdGlvbnMgMi4xIGFuZA0KPiA+ID4+PiAyLjIpLiBCYXNl ZCBvbiB0aGlzIGRpc2N1c3Npb24gSSB0YWtlIGl0IHRoYXQgc29tZSBtb2RlbHMgYXJlIGludGVu ZGVkIHRvIGJlIGFibGUgdG8gc2VydmUgaW4gYm90aCByb2xlcy4gQW5kIHdlIHNob3VsZCBtYWtl IHN1cmUgdGhhdCBpdOKAmXMgc3VwcG9ydGVkIGluIG91ciBjYXRhbG9nIHN0cnVjdHVyZS4NCj4g PiA+Pg0KPiA+ID4+IFJlZ2FyZGluZyB0aGUgWE9SIGFzc3VtcHRpb24gZm9yIGNsYXNzaWZpY2F0 aW9uOg0KPiA+ID4+DQo+ID4gPj4gWW91IG1heSBhbHNvIHdhbnQgdG8gdGhpbmsgYWJvdXQgWUFO RyBtb2RlbHMgdGhhdCBhcmUgTkVJVEhFUiBkZXZpY2UgTk9SIHNlcnZpY2UgbW9kZWxzLiBGb3Ig aW5zdGFuY2UsIHdoYXQgYWJvdXQgUkZDIDY5OTE/IEFuZCBJIHRoaW5rIG90aGVyLCBtb3JlIHRl Y2huaWNhbCBtb2RlbHMgcHJlc2VudGVkIHRoaXMgd2VlayBtYXkgZmFsbCBpbnRvIGEgc2ltaWxh ciBjYXRlZ29yeSAoImdlbmVyaWMiPykuDQo+ID4gPg0KPiA+ID4gVmVyeSBnb29kIHBvaW50LCB0 aGFua3MhIFRoYXQgd2lsbCBuZWVkIHNvbWUgYWRkaXRpb25hbCB0aGlua2luZyBhbmQgd3JpdGlu Zy4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+DQo+IA0KPiANCg0K From nobody Fri Apr 8 11:23:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B612D13E for ; Fri, 8 Apr 2016 11:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnzsm7tI2fb8 for ; Fri, 8 Apr 2016 11:23:01 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF98812D166 for ; Fri, 8 Apr 2016 11:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14410; q=dns/txt; s=iport; t=1460139781; x=1461349381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BYFufjkL6IlfTALk3wNnlyw+idlZl0gaHNOEkMhsL84=; b=jP9cDphB5AB8cZu+vxTW97tsHhWWYmfexMdtJUMy0XihfZhpz05bC6gQ wT2+dYMDtWpoxi4Bsfv68AnOn8rOO9TFPmsfjGr+RyvVA0tiA2dljdTBa An2V4n9v2affQJe4s4x6i+VF1Z9bh6fNlKOIHskDmeusvl+6r2QO8YcBq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAQAp9gdX/xbLJq1chAp9Bro/AQ2Bc?= =?us-ascii?q?xcKhSJKAhyBTxQBAQEBAQEBZSeEQQEBAQMBAQEBIAQNOgsFBwQCAQYCEQQBAQE?= =?us-ascii?q?CAiMDAgICJQsUAQgIAgQBDQUIiBcIDpFanReRcAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEfIlwhz+CVgEEiVqOKgGOBI8UjyQBHgEBQoNnbIg7AX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="676645736" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 18:22:58 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u38IMvSL003273 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 18:22:58 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 14:22:56 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 14:22:56 -0400 From: "Alexander Clemm (alex)" To: "Carl Moberg (camoberg)" , Andy Bierman Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA///z0QCAABFtAIAAMpcg///gUoCAADIeAIAAfSGAgAANJICAAACNgP//zgBggAIC1YCAAAgdgIAAAmCAgAAFGICAADa2AIAAMrcA Date: Fri, 8 Apr 2016 18:22:56 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <6E7F5A13-FB4A-4CCB-AA43-39F7718D38EF@cisco.com> <6210B927-9173-415C-A476-ADAF1051F145@cisco.com> In-Reply-To: <6210B927-9173-415C-A476-ADAF1051F145@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:23:04 -0000 SGkgQ2FybCwNCg0KdG8gZm9sbG93IHVwIG9uIHRoZSBlYXJsaWVyIHBvaW50cyBpbiB0aGUgZGlz Y3Vzc2lvbjoNCi0gSG93IGNhbiB3ZSBwcm92aWRlIG1vcmUgY2xhcmlmaWNhdGlvbg0KLSBIb3cg Y291bGQgTS4zMDEwIHByb3ZpZGUgc29tZXRoaW5nIHVzZWZ1bA0KDQpGV0lXLCBhIGxpbmUgb2Yg YXJndW1lbnQgdG8gcmVmbGVjdCBpbiB0aGUgZHJhZnQgbWlnaHQgZ28gYXMgZm9sbG93czogDQoN CkdpdmVuIHRoYXQgdGhlIGhpc3RvcnkgaW4gSUVURiBoYXMgYmVlbiB0byBub3QgbG9vayBhdCB0 aGluZ3MgYmV5b25kIHRoZSBkZXZpY2UgYm91bmRhcnksIHBlcmhhcHMgaXQgd291bGQgYmUgdXNl ZnVsIHRvIHN0YXRlIHNvbWV3aGVyZSB0aGF0IHRoaXMgcmVzdHJpY3Rpb24gbm8gbG9uZ2VyIGhv bGRzIGFuZCBuZWVkcyB0byBiZSByZWxheGVkIC0gZ2l2ZW4gdGhhdCBkZXZpY2VzIGNhbiBiZSB2 aXJ0dWFsaXplZCwgY29udHJvbGxlcnMgbWF5IHJlc2lkZSBvbiBkZXZpY2VzLCB0aGF0IGFwcGxp Y2F0aW9ucyBtYXkgYmVjb21lIG1vcmUgbmV0d29yay1hd2FyZSBhbmQgbmV0d29ya3MgbW9yZSBz ZXJ2aWNlIC8gYXBwbGljYXRpb24gYXdhcmUsIGV0Yy4gIFNvLCB0aGUgYm91bmRhcmllcyBhcmUg Z2V0dGluZyBtb3JlIGJsdXJyeS4gIA0KDQpBdCB0aGUgc2FtZSB0aW1lLCBhIGZvdW5kYXRpb25h bCBjb25jZXB0IGlzIHN0aWxsIHRoZSBuZWVkIGZvciBmdW5jdGlvbiBoaWVyYXJjaGllcyAocmVn YXJkbGVzcyBvZiBkZXRhaWxzIG9mIHdoZXJlIGFuZCBob3cgdGhvc2UgZnVuY3Rpb25zIGFyZSBp bnN0YW50aWF0ZWQpOiBlbGVtZW50YXJ5IGZ1bmN0aW9ucyAvIGJ1aWxkaW5nIGJsb2NrcyAoZm9y bWVybHkgZXF1aXZhbGVudCB0byBkZXZpY2VzKSwgZnVuY3Rpb25zIHRoYXQgZGVhbCB3aXRoIHRo ZSBjb25uZWN0aW9uIG9mIHRob3NlIGZ1bmN0aW9ucyAvIGJ1aWxkaW5nIGJsb2NrcyAoZm9ybWVy bHkgZXF1aXZhbGVudCB0byAibmV0d29yayBtYW5hZ2VtZW50IiBpbiB0aGUgbmFycm93ZXIgc2Vu c2UpLCB0aGVuIGZ1bmN0aW9ucyB0aGF0IGJ1aWxkIGhpZ2hlci1sZXZlbCBzZXJ2aWNlcyBvbiB0 b3Agb2YgY29ubmVjdGl2aXR5IGFscmVhZHkgYmVpbmcgcHJvdmlkZWQuICBGdW5jdGlvbiBoaWVy YXJjaGllcyBpbXBseSBpbmZvcm1hdGlvbiAvIGRhdGEgaGllcmFjaGllcy4gIFRoZXJlIGlzIG5v IHJlYXNvbiB3aHkgWUFORyBjb3VsZCBub3QgYmUgdXNlZCB0byBkZWZpbmUgbW9kZWxzIGF0IGRp ZmZlcmVudCBsZXZlbHMgb2YgdGhhdCBoaWVyYXJjaHksIHdoaWNoIHByb3ZpZGVzIHZhcmlvdXMg YWR2YW50YWdlcyBzdWNoIGFzIGNvbnNpc3RlbmN5IGFjcm9zcyB0aGUgIm1vZGVsIHN0YWNrIiBh cyB3ZWxsIGFzIHRoZSBhYmlsaXR5IHRvIG1ha2UgYXNwZWN0cyBvZiBtb2RlbHMgYXQgZGlmZmVy ZW50IGxldmVscyBvZiBhYnN0cmFjdGlvbiBhY2Nlc3NpYmxlIHRvIG90aGVyIG1vZGVscyBhbmQg YmUgdXNlZCB0b2dldGhlciB3aGVyZSBsYXllcmluZyBpcyBub3QgInN0cmljdCIgKGluIHRoZSBz ZW5zZSB0aGF0IHVwcGVyIGxheWVycyBtYXkgYnVpbGQgb24gdG9wIG9mIG1vZGVscyBmcm9tIG11 bHRpcGxlIGxvd2VyIGxheWVycywgbm90IGp1c3QgdGhlIGxheWVyIGltbWVkaWF0ZWx5IGJlbG93 IGl0LCBzbyB0aGF0IGxvd2VyIGxheWVycyBhcmUgbm90IGNvbXBsZXRlbHkgaGlkZGVuKS4gIFNv LCBZQU5HIG1vZGVscyBhcHBseSB0byBkaWZmZXJlbnQgbGF5ZXJzLCBhbmQgdGhlcmUgYXJlIGFk dmFudGFnZXMgaW4gZG9pbmcgc28uIA0KDQpUaGUgY29uY2VwdCBvZiBtb2RlbCBoaWVyYXJjaGll cyBpcyBub3QgbmV3LiAgT25lIGV4YW1wbGUgb2YgYSBoaWVyYXJjaGljYWwgY2xhc3NpZmljYXRp b24gdGhhdCBoYXMgcHJvdmVkIHZlcnkgdXNlZnVsIG92ZXIgdGhlIHllYXJzIGlzIHRoZSBoaWVy YXJjaHkgc3BlbGxlZCBvdXQgaW4gTS4zMDEwLiAgU28sIHdlIGFyZSBub3QgcHJvcG9zaW5nIGFu eXRoaW5nICJyYWRpY2FsIiBoZXJlOyB0aGVyZSBpcyBwcmVjZWRlbmNlLiAgQXMgTS4zMDEwIGxh eWVyaW5nIGNvbmNlcHRzIGFyZSBpbiBlc3NlbmNlIGFwcGxpY2FibGUgYWxzbyBoZXJlLCB5ZXQg dGhlIG5lZWQgZm9yIGRhdGEgbW9kZWwgaGllcmFyY2hpZXMgaGFzIG5vdCBiZWVuIHNwZWxsZWQg b3V0IGJlZm9yZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgWUFORy9OZXRjb25mIGZyYW1ld29yaywg dGhpcyBpcyBhbiBhdHRlbXB0IHRvIGZpbGwgdGhhdCBnYXAuICAgDQoNCk9uZSByZWFzb24gd2h5 IGNsYXNzaWZpY2F0aW9uIGlzIHVzZWZ1bCBpbiB0aGF0IHNlbnNlIGlzIHRvIGtub3cgd2hpY2gg dHlwZXMgb2YgbW9kZWxzIG1pZ2h0IGhhdmUgZGVwZW5kZW5jaWVzIG9uIGVhY2ggb3RoZXIsIGFu ZCB3aGF0IG90aGVyIG1vZGVscyBhIG1vZGVsIG1pZ2h0IGJ1aWxkIG9uIHdoZW4gaW5zdGFudGlh dGVkLiAgVXBwZXItbGF5ZXIgbW9kZWxzIG1heSBoYXZlIGRlcGVuZGVuY2llcyBvbiBsb3dlci1s YXllciBtb2RlbHMsIGFuZCBpbiBtYW55IGNhc2VzIGFnZ3JlZ2F0ZS9hYnN0cmFjdCBtdWx0aXBs ZSBjb21wb25lbnRzIGZyb20gdGhvc2UgbG93ZXIgbGF5ZXIgbW9kZWxzLCBidXQgbm90IHRoZSBv dGhlciB3YXkgYXJvdW5kLiAgVGhpcyBtZWFucyB0aGF0LCB1cHBlci1sYXllciBtb2RlbHMgbWF5 IGJlIGluc3RhbnRpYXRlZCBpbiBkaWZmZXJlbnQgd2F5cyB0aGFuIGxvd2VyLWxheWVyIG1vZGVs cyBpbiBhcyBmYXIgYXMgdGhleSBidWlsZCBvbiB0b3Agb2Ygb3RoZXIgZnVuY3Rpb25zL21vZGVs cyBvZiB0aGUgc2FtZSBmcmFtZXdvcmsgKGluc3RlYWQgb2YgZnVuY3Rpb25zIG91dHNpZGUgdGhh dCBmcmFtZXdvcmspLiAgVGhpcyBkaXN0aW5jdGlvbiBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5 IGhhdmluZyBhIGNsZWFyIGNsYXNzaWZpY2F0aW9uIGlzIHNvbWV0aGluZyB0aGF0IG1heSBiZSB1 c2VmdWwuICANCg0KQW55d2F5LCBJTUhPLCB3aGF0IGlzIGN1cnJlbnRseSBub3Qgc3VmZmljaWVu dGx5IGNsZWFyIGZyb20gdGhlIGRyYWZ0IGlzIHRoYXQgY2xhc3NpZmljYXRpb24gZG9lcyBub3Qg b2NjdXIganVzdCBmb3IgY2xhc3NpZmljYXRpb24ncyBzYWtlLCBhbmQgdGhpcyBpcyBhbiBhdHRl bXB0IGF0IGFydGljdWxhdGluZyBhIGNhc2UgZm9yIGl0LiAgDQoNCkNoZWVycw0KLS0tIEFsZXgg DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcmwgTW9iZXJnIChjYW1v YmVyZykgDQpTZW50OiBGcmlkYXksIEFwcmlsIDA4LCAyMDE2IDk6NTMgQU0NClRvOiBBbmR5IEJp ZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NCkNjOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIDxh bGV4QGNpc2NvLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFlB TkcgbW9kZWwgY2xhc3NpZmljYXRpb24/DQoNCg0KPiBPbiBBcHIgOCwgMjAxNiwgYXQgMzozNiBQ TSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiANCj4gDQo+IA0K PiBPbiBGcmksIEFwciA4LCAyMDE2IGF0IDY6MTggQU0sIENhcmwgTW9iZXJnIChjYW1vYmVyZykg PGNhbW9iZXJnQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiA+IE9uIEFwciA4LCAyMDE2LCBhdCAz OjEwIFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4NCj4g PiBIaSwNCj4gPg0KPiA+DQo+ID4gSXQgaXMgbm90IHRoYXQgY2xlYXIgaG93IHRoZSBkaWZmZXJl bnQgdHlwZXMgb2YgbW9kdWxlcyBvciBsYXllcnMgDQo+ID4gaW1wYWN0IHRoZSB0YXNrIG9mIGRl c2lnbmluZyBhIFlBTkcgbW9kdWxlLiAgSXQgc2VlbXMgbGlrZSB2ZW5kb3IgDQo+ID4gdnMuIHN0 YW5kYXJkIG9yIGRldmljZSB2cy4gc2VydmljZSBhcmUgc29tZXdoYXQgYXJiaXRyYXJ5LCANCj4g PiBlc3BlY2lhbGx5IGlmIHZpcnR1YWxpemF0aW9uIGlzIGNvbnNpZGVyZWQuDQo+IA0KPiANCj4g IFRoZSBpbnRlbnQgb2YgdGhlIGNsYXNzaWZpY2F0aW9uIGlzIChpbWhvKSBub3QgaW50ZW5kZWQg dG8gaGF2ZSBtdWNoIGltcGFjdCBvbiBob3cgdG8gZGVzaWduIGEgbW9kdWxlLiBSYXRoZXIgdG8g cHJvdmlkZSBhIHRheG9ub215IHRvIGNsYXNzaWZ5IG1vZGVscyB3aGVuIHRoZXkgYXJlIGRvbmUg KG9yIGJlaW5nIGRldmVsb3BlZCkuDQo+IA0KPiAgSSBkb27igJl0IHNlZSBob3cgdmlydHVhbGl6 YXRpb24gd291bGQgaGF2ZSBhbiBpbXBhY3QsIGFueSBzdWdnZXN0aW9ucz8NCj4gDQo+IE5vIHN1 Z2dlc3Rpb25zIG90aGVyIHRoYW4gdGhlIGhpZXJhcmNoeSBvZiBjb250cm9sbGVyIHRvIGRldmlj ZSBpcyBub3QgYWx3YXlzIHN0YXRpYy4NCj4gQW0gSSBhbGxvd2VkIHRvIGJ1aWxkIGEgc2Vydmlj ZSBsYXllciBvbiB0b3Agb2YgYW5vdGhlciBzZXJ2aWNlIGxheWVyPw0KPiAoZS5nLCAgTk1TIC0t PiBFTVMgLS0+IE5FKS4gIEFtIEkgYWxsb3dlZCB0byB0cmVhdCBhbiBlbnRpcmUgZGF0YSANCj4g Y2VudGVyIGFzIGEgZGV2aWNlIGluIGEgaGlnaCBsZXZlbCBhcHBsaWNhdGlvbj8NCj4gDQoNCiBU aGUgZHJhZnQgaXMgZGVmaW5pdGVseSBub3Qgc3VwcG9zZWQgdG8gdGVsbCB5b3Ugd2hhdCB5b3Ug YXJlIGFsbG93ZWQgdG8gZG8sIGJ1dCBpdCBkb2VzIGFzcGlyZSB0byBhIHVzZWZ1bCBjbGFzc2lm aWNhdGlvbiBvZiB3aGF0IHBlb3BsZSBhcmUgZG9pbmcgOi0pDQoNCiBTbywgdG8geW91ciBxdWVz dGlvbnM6DQoNCiAxLiDigJwuLi5hIHNlcnZpY2UgbGF5ZXIgb24gdG9wIG9mIGFub3RoZXIgc2Vy dmljZSBsYXllcj8iDQoNCiBGcm9tIHNlY3Rpb24gMi4xOg0KDQrigJzigJ3igJ3igJ0NClRoZSBj b21wb25lbnQtYmFzZWQgYXBwcm9hY2ggY2FwdHVyZXMgZGV2aWNlLWNlbnRyaWMgZmVhdHVyZXMg KGUuZy4NCnRoZSBkZWZpbml0aW9uIG9mIGEgVlJGLCByb3V0aW5nIHByb3RvY29scywgb3IgcGFj a2V0IGZpbHRlcmluZykgaW4gYSB2ZW5kb3ItaW5kZXBlbmRlbnQgbWFubmVyLiAgVGhlIGNvbXBv bmVudHMgYXJlIGRlc2lnbmVkIGZvciByZXVzZSBhY3Jvc3MgbWFueSBzZXJ2aWNlcy4gIFRoZSBz ZXQgb2YgY29tcG9uZW50cyByZXF1aXJlZCBmb3IgYSBzcGVjaWZpYyBzZXJ2aWNlIGlzIHRoZW4g Y29tcG9zZWQgaW50byB0aGUgaGlnaGVyLWxldmVsIHNlcnZpY2UuICBUaGUgY29tcG9uZW50LWJh c2VkIGFwcHJvYWNoIGhhcyB0aGUgYWR2YW50YWdlcyBvZiBtb2R1bGFyIGRldmVsb3BtZW50IGlu Y2x1ZGluZyBhIGhpZ2hlciBkZWdyZWUgb2YgcmV1c2FiaWxpdHkgYXQgdGhlIGV4cGVuc2Ugb2Yg aW5pdGlhbCBzcGVlZC4NCuKAnOKAneKAnQ0KDQoNCiAyLiDigJwuLi50byB0cmVhdCBhbiBlbnRp cmUgZGF0YSBjZW50ZXIgYXMgYSBkZXZpY2UgaW4gYSBoaWdoIGxldmVsIGFwcGxpY2F0aW9uPyIN Cg0K4oCc4oCd4oCdDQpOZXR3b3JrIEVsZW1lbnQgWUFORyBEYXRhIE1vZGVscyBkZXNjcmliZSB0 aGUgY29uZmlndXJhdGlvbiwgc3RhdGUgZGF0YSBhbmQgb3BlcmF0aW9ucyBvZiBhIG5ldHdvcmsg ZGV2aWNlIGFzIGRlZmluZWQgYnkgdGhlIHZlbmRvciBvZiB0aGF0IGRldmljZS4gIFRoZSBtb2Rl bHMgYXJlIGNvbW1vbmx5IHN0cnVjdHVyZWQgYXJvdW5kIGZlYXR1cmVzIG9mIHRoZSBkZXZpY2Uu Li4NCuKAnOKAnSINCg0KPiA+IFRoZSB0ZXJtaW5vbG9neSB3b3VsZCBiZSBtb3JlIHJlbGV2YW50 IGlmIHRoZSBkaWZmZXJlbmNlcyBpbiBjb250ZW50IA0KPiA+IG9mIGVhY2ggdHlwZSBvZiBtb2R1 bGUgd2VyZSBjbGVhci4NCj4gDQo+ICBUaGUgZmlyc3QgcGFyYWdyYXBocyBvZiB0aGUgbWFpbiBz ZWN0aW9ucyAoMi4xLCAyLjIsIDMuMS0zLjMpIGFyZSBtZWFudCghKSB0byBleHBsYWluIHRoaXMu IENvdWxkIHlvdSBleHBhbmQgb24gd2hhdCB5b3UgdGhpbmsgaXMgbWlzc2luZz8NCj4gDQo+IE5v IC0tIHRoaXMgaXMgYW4gSW5mb3JtYXRpb25hbCBkcmFmdC4NCj4gVGhlIGNvbnRlbnQgZG9lcyBu b3QgaGF2ZSB0byBiZSBhY3Rpb25hYmxlLiAgSXQgb25seSBoYXMgdG8gYmUgDQo+IGluZm9ybWF0 aXZlLg0KPiANCj4gRm9yIGRlY2FkZXMgU05NUCBjb21wbGV0ZWx5IGlnbm9yZWQgYW55dGhpbmcg YWJvdmUgdGhlIE5FIGFzIG91dCBvZiBzY29wZS4NCj4gV2UgYXJlIG1ha2luZyBzb21lIHByb2dy ZXNzIGp1c3QgYnkgY29uc2lkZXJpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIA0KPiBzdGFuZGFyZCBm dW5jdGlvbmFsaXR5IGF0IHRoZSBjb250cm9sbGVyIGxheWVyLg0KPiANCj4gDQo+ID4gQW5keQ0K PiAgDQo+ID4NCj4gPg0KPiA+IE9uIEZyaSwgQXByIDgsIDIwMTYgYXQgNTo0MCBBTSwgQ2FybCBN b2JlcmcgKGNhbW9iZXJnKSA8Y2Ftb2JlcmdAY2lzY28uY29tPiB3cm90ZToNCj4gPg0KPiA+ID4g T24gQXByIDcsIDIwMTYsIGF0IDY6NDMgUE0sIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgPGFsZXhA Y2lzY28uY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBJIGFtIHdvbmRlcmluZyB3aGF0IHB1cnBv c2UgdGhlIGNsYXNzaWZpY2F0aW9uIHJlYWxseSBzZXJ2ZXMuICBBdCB0aGUgZW5kIG9mIHRoZSBk YXksIGl0IHNlZW1zIHRvIG1lIHRoYXQgd2UgYXJlIHRyeWluZyB0byBleHByZXNzIGEgbW9kZWwg aGllcmFyY2h5LCBhbmQgYXJ0aWN1bGF0ZSB3aGF0IHRoZSBsYXllcnMgaW4gdGhlIGhpZXJhcmNo eSBhcmUuICBBIGRldmljZSBtb2RlbCBpcyB0aHVzIGF0IGEgbG93ZXIgbGF5ZXIgdGhhbiBhIHNl cnZpY2UgbW9kZWwuICBBbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VydmljZSBtb2RlbCBtYXkg aW4gdHVybiBoYXZlIGRlcGVuZGVuY2llcyBvbiB0aGUgZGV2aWNlIG1vZGVsLCBidXQgbm90IHRo ZSBvdGhlciB3YXkgcm91bmQuDQo+ID4NCj4gPiAgVGhlIGFic3RyYWN0IHRyaWVzIHRvIGV4cHJl c3MgdGhlIHB1cnBvc2U6DQo+ID4NCj4gPiDigJzigJ3igJ0NCj4gPiBBIGNvbnNpc3RlbnQgdGVy bWlub2xvZ3kgd291bGQgaGVscCB3aXRoIHRoZSBjYXRlZ29yaXphdGlvbiBvZiANCj4gPiBtb2Rl bHMsIGFzc2lzdCBpbiB0aGUgYW5hbHlzaXMgdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBlZmZvcnRz IGluIHRoZSANCj4gPiBJRVRGIGFuZCBvdGhlciBvcmdhbml6YXRpb25zLCBhbmQgYnJpbmcgY2xh cml0eSB0byB0aGUgWUFORy1yZWxhdGVkIA0KPiA+IGRpc2N1c3Npb25zIGJldHdlZW4gdGhlIGRp ZmZlcmVudCBncm91cHMuDQo+ID4g4oCc4oCdIg0KPiA+DQo+ID4gIEFuZCBJ4oCZdmUgdGhlbiB0 cmllZCB0byBleHBhbmQgYSBsaXR0bGUgZnVydGhlciBpbiBzZWN0aW9uIDEuDQo+ID4NCj4gPiAg SGFwcHkgdG8gdGFrZSBmZWVkYmFjayBvbiBpdCENCj4gPg0KPiA+ID4gV2hlcmUgdGhlIG1vZGVs cyBhcmUgaW5zdGFudGlhdGVkIC0gb24gYSBjb250cm9sbGVyLCBvbiBhICJkZXZpY2UiLCBldGMg LSBzZWVtcyB0byBiZSBzZWNvbmRhcnkgYW5kIGluY2lkZW50YWwuICBUaGUgYm91bmRhcmllcyBh cmUgYmx1cnJ5LCBhbnl3YXlzLiAgQSBjb250cm9sbGVyIGlzIGEgZGV2aWNlIHRvbzsgc29tZSBk ZXZpY2VzIG1heSBjb250YWluIHZpcnR1YWxpemVkIGNvbnRyb2xsZXJzLCBhbmQgc28gb24uDQo+ ID4NCj4gPiAgVGhlIGFzc3VtcHRpb24gaGVyZSBpcyB0aGF0IHRoZSBsb2NhdGlvbiBpcyBpbmRl ZWQgdXNlZnVsIGFuZCBzdWdnZXN0cyB0aGUgY2xhc3NpZmljYXRpb24gb2YgZGF0YSBtb2RlbHMg aW50byB0d28gZGlzdGluY3QgYWJzdHJhY3Rpb24gbGF5ZXJzLiBUb3BvbG9neSBpcyB0aGUgYXJl YSB3aGVyZSBJIGhhZCBhIHNlbnNlIHRoYXQgdGhlIGRldmljZSBhbmQgc2VydmljZSBjbGFzc2lm aWNhdGlvbiBtYXkgYm90aCBhcHBseSB0byBhIHNpbmdsZSBtb2R1bGUuDQo+ID4NCj4gPiA+IE9u ZSBtb2RlbCB0aGF0IGlzIHJlbGV2YW50IGluIHRoaXMgZGlzY3Vzc2lvbiBzZWVtcyB0byBiZSB0 aGUgVE1OIG1vZGVsLCBhcyBkZWZpbmVkIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIE0uMzAxMC4g IFRoaXMgbW9kZWwgZGVmaW5lcyBhIHNldCBvZiBtYW5hZ2VtZW50IGxheWVycyAtIG5ldHdvcmsg ZWxlbWVudCAoZGV2aWNlKSwgbmV0d29yaywgc2VydmljZSwgYnVzaW5lc3MgLSB3aXRoIHdlbGwg ZGVmaW5lZCBmdW5jaW9uYWwgc2NvcGUgb2YgZWFjaCBsYXllci4gIFRoZSBsYXllcnMgLyBmdW5j dGlvbiBoaWVyYXJjaHkgYWxzbyBpbXBseSBhbiBpbmZvcm1hdGlvbiAgYW5kIGRhdGEgbW9kZWwg aGllcmFyY2h5Lg0KPiA+DQo+ID4gIFRoZSBjbGFzc2lmaWNhdGlvbiBpcyBmYWlybHkgd2VsbCBh bGlnbmVkIHdpdGggdGhlIGNvbmNlcHRzIGluIA0KPiA+IE0uMzAxMCwgY292ZXJpbmcgdGhlICJO ZXR3b3JrIG1hbmFnZW1lbnTigJ0gYW5kIOKAnEVsZW1lbnQgbWFuYWdlbWVudOKAnSANCj4gPiBs YXllcnMuIEF0IGxlYXN0IHRoYXTigJlzIHRoZSBpbnRlbnQgOi0pDQo+ID4NCj4gPiA+IFdvdWxk IGl0IG1ha2Ugc2Vuc2UgdG8gc2VlIGlmIHRoZSBsYXllcmluZyBpbiBNLjMwMTAgY291bGQgaGVs cCBndWlkZSBZQU5HIG1vZGVsIGNsYXNzaWZpY2F0aW9uLCBhbmQgcmVmZXJlbmNlIHRob3NlIGRl ZmluaXRpb25zPw0KPiA+DQo+ID4gIFdvdWxkIGJlIHZlcnkgaGFwcHkgdG8gaGVhciBpZiB5b3Ug ZmluZCB3ZSBkZXZpYXRlIChvciBsYWNrKSBjb25jZXB0cyBvciB1c2VmdWwgZmVhdHVyZXMgZnJv bSBNLjMwMTAgdGhhdCB3b3VsZCBtYWtlIHRoZSBjbGFzc2lmaWNhdGlvbiBtb3JlIHVzZWZ1bC4N Cj4gPg0KPiA+ID4gLS0tIEFsZXgNCj4gPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDYXJsIA0KPiA+ID4gTW9iZXJnIChjYW1vYmVyZykNCj4gPiA+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiAxOjU3IEFNDQo+ID4gPiBUbzogU2NoYXJmLCBNaWNo YWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPg0KPiA+ID4gQ2M6IG5l dG1vZEBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY2xh c3NpZmljYXRpb24/DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLQ0KPiA+ID4gQ2FybCBN b2JlcmcNCj4gPiA+IFRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KPiA+ID4gY2Ftb2JlcmdAY2lz Y28uY29tDQo+ID4gPg0KPiA+ID4+IE9uIEFwciA3LCAyMDE2LCBhdCAxMDo1NSBBTSwgU2NoYXJm LCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPiB3cm90ZToN Cj4gPiA+Pg0KPiA+ID4+PiBJIGNvbWUgYXQgdGhpcyBmcm9tIHRoZSBjbGFzc2lmaWNhdGlvbiBh bmdsZSwgc28gbXkgaW50ZXJlc3QgaXMgDQo+ID4gPj4+IGlmIHRoZSBhc3N1bXB0aW9uIHRoYXQg YSBZQU5HIG1vZGVsIGNhbiBvbmx5IGJlIGNsYXNzaWZpZWQgYXMgYSANCj4gPiA+Pj4gbmV0d29y ayBzZXJ2aWNlIG1vZGVsIFhPUiBhIG5ldHdvcmsgZGV2aWNlIG1vZGVsIGFjY29yZGluZyB0byAN Cj4gPiA+Pj4gdGhlIGRlZmluaXRpb25zIGluIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwt Y2xhc3NpZmljYXRpb24gDQo+ID4gPj4+IChzZWN0aW9ucyAyLjEgYW5kIDIuMikuIEJhc2VkIG9u IHRoaXMgZGlzY3Vzc2lvbiBJIHRha2UgaXQgdGhhdCBzb21lIG1vZGVscyBhcmUgaW50ZW5kZWQg dG8gYmUgYWJsZSB0byBzZXJ2ZSBpbiBib3RoIHJvbGVzLiBBbmQgd2Ugc2hvdWxkIG1ha2Ugc3Vy ZSB0aGF0IGl04oCZcyBzdXBwb3J0ZWQgaW4gb3VyIGNhdGFsb2cgc3RydWN0dXJlLg0KPiA+ID4+ DQo+ID4gPj4gUmVnYXJkaW5nIHRoZSBYT1IgYXNzdW1wdGlvbiBmb3IgY2xhc3NpZmljYXRpb246 DQo+ID4gPj4NCj4gPiA+PiBZb3UgbWF5IGFsc28gd2FudCB0byB0aGluayBhYm91dCBZQU5HIG1v ZGVscyB0aGF0IGFyZSBORUlUSEVSIGRldmljZSBOT1Igc2VydmljZSBtb2RlbHMuIEZvciBpbnN0 YW5jZSwgd2hhdCBhYm91dCBSRkMgNjk5MT8gQW5kIEkgdGhpbmsgb3RoZXIsIG1vcmUgdGVjaG5p Y2FsIG1vZGVscyBwcmVzZW50ZWQgdGhpcyB3ZWVrIG1heSBmYWxsIGludG8gYSBzaW1pbGFyIGNh dGVnb3J5ICgiZ2VuZXJpYyI/KS4NCj4gPiA+DQo+ID4gPiBWZXJ5IGdvb2QgcG9pbnQsIHRoYW5r cyEgVGhhdCB3aWxsIG5lZWQgc29tZSBhZGRpdGlvbmFsIHRoaW5raW5nIGFuZCB3cml0aW5nLg0K PiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gDQo+IA0KDQo= From nobody Fri Apr 8 11:45:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED7612D191 for ; Fri, 8 Apr 2016 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUHFJmMdVw9t for ; Fri, 8 Apr 2016 11:45:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0822712D12B for ; Fri, 8 Apr 2016 11:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5822; q=dns/txt; s=iport; t=1460141107; x=1461350707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QxAIqLmNrMBgwQjnONxbD2GIhJE/uMDBHBD/zQTNUGg=; b=LLt4dj+KFizZ823zZ/yzPhb4aWUXOfdy66SGm/CiwVtB8rsak6SET/nt 5445zieMtqzbtY8Okv3FZ3SJg6x3Q7P/eG9DYtjFRoip4nFcPH/n/sZDS /ItmdZzEdFq7hfnDf6x81ZdEl63vzQ0UU0OFmlDIrtPNYUMCiqoTag8rJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgAO+wdX/5FdJa1ZA4M3U30Guj8BD?= =?us-ascii?q?YFzFwqFIkoCHIEXOBQBAQEBAQEBZSeEQQEBAQQBAQEgEToLDAICAgEIDgIBBAE?= =?us-ascii?q?BAQICIwMCAgIZDAsUAQgIAgQOBQiIHw6ucZFrAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFQR4iXCEVQsmgjmCVgWJWo4qAY4EjxSPJAEeAQFCg2dsiDsBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="259278954" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 18:45:05 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u38Ij22i009215 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 18:45:02 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 14:45:01 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 14:45:01 -0400 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA///z0QCAABFtAIAAMpcg///gUoCAADIeAIAAfSGAgAANJICAAACNgP//zgBggAGlsYD//4GcYA== Date: Fri, 8 Apr 2016 18:45:01 +0000 Message-ID: <00726c40293d44dea9bd4ebb35d7ff3f@XCH-RTP-001.cisco.com> References: <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <20160408070737.GB66159@elstar.local> In-Reply-To: <20160408070737.GB66159@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:45:09 -0000 SGkgSnVlcmdlbiwgdGhlIHF1ZXN0aW9uIGlzIHN0aWxsIF9ob3dfIGl0IHNpbXBsaWZpZXMgaHVt YW4gY29tbXVuaWNhdGlvbi4gIFRvIHVzZSBkaWZmZXJlbnQgdGVybXMsIGl0IHNob3VsZCBiZSBj bGVhciB3aGF0IGRpZmZlcmVudCBwdXJwb3NlcyB0aGV5IGNvbnZleSwgYW5kIHdoeSB0aGVpciBk aXN0aW5jdGlvbiBpcyByZWxldmFudCBhbmQgbWF0dGVycy4gIElNSE8gdGhpcyBuZWVkcyB0byBi ZSBhcnRpY3VsYXRlZCBtb3JlIGNsZWFybHkuIElmIGl0IGlzIG5vdCBjbGVhciB3aHkgdGhlIGRp c3RpbmN0aW9uIG1hdHRlcnMsIGl0IGRvZXMgbm90IHNpbXBsaWZ5IGNvbW11bmljYXRpb24uICAN Ci0tLSBBbGV4DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVd IA0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiAxMjowOCBBTQ0KVG86IEFsZXhhbmRlciBD bGVtbSAoYWxleCkgPGFsZXhAY2lzY28uY29tPg0KQ2M6IENhcmwgTW9iZXJnIChjYW1vYmVyZykg PGNhbW9iZXJnQGNpc2NvLmNvbT47IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRt b2RdIFlBTkcgbW9kZWwgY2xhc3NpZmljYXRpb24/DQoNClllcywgdGhlIGJvdW5kYXJpZXMgYXJl IGJsdXJyeSBhbmQgaXQgZG9lcyBub3QgbWF0dGVyIHdoaWNoIGxheWVyaW5nIG1vZGVsIHlvdSB1 c2UuIE0uMzAxMCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGZhY3QgdGhhdCBib3VuZGFyaWVzIGFyZSBi bHVycnkuDQoNCkkgdGhpbmsgaXQgaXMgbm90IGEgcHJvYmxlbS4gTXkgdW5kZXJzdGFuZGluZyB3 YXMgdGhhdCB0aGUgSS1EIHByaW1hcmlseSBhaW1zIGF0IGVzdGFibGlzaCBhIGNvbW1vbiB2b2Nh YnVsYXJ5IGFuZCBpdCBzaG91bGQgSU1ITyBleHBsaWNpdGVseSBzdGF0ZSB0aGF0IGJvdW5kYXJp ZXMgYXJlIGJsdXJyeSBhbmQgdGhhdCB0aGUgbWFpbiBwdXJwb3NlIGlzIHRvIHNpbXBsaWZ5ICdo dW1hbiBjb21tdW5pY2F0aW9uJy4gVGhlIGNsYXNzaWZpY2F0aW9uIGlzIG5vdCBmb3IgJ2ltcGxl bWVudGF0aW9uJy4NCg0KL2pzDQoNCk9uIFRodSwgQXByIDA3LCAyMDE2IGF0IDA0OjQzOjUxUE0g KzAwMDAsIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgd3JvdGU6DQo+IEkgYW0gd29uZGVyaW5nIHdo YXQgcHVycG9zZSB0aGUgY2xhc3NpZmljYXRpb24gcmVhbGx5IHNlcnZlcy4gIEF0IHRoZSBlbmQg b2YgdGhlIGRheSwgaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGV4cHJlc3Mg YSBtb2RlbCBoaWVyYXJjaHksIGFuZCBhcnRpY3VsYXRlIHdoYXQgdGhlIGxheWVycyBpbiB0aGUg aGllcmFyY2h5IGFyZS4gIEEgZGV2aWNlIG1vZGVsIGlzIHRodXMgYXQgYSBsb3dlciBsYXllciB0 aGFuIGEgc2VydmljZSBtb2RlbC4gIEFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzZXJ2aWNlIG1v ZGVsIG1heSBpbiB0dXJuIGhhdmUgZGVwZW5kZW5jaWVzIG9uIHRoZSBkZXZpY2UgbW9kZWwsIGJ1 dCBub3QgdGhlIG90aGVyIHdheSByb3VuZC4gIA0KPiANCj4gV2hlcmUgdGhlIG1vZGVscyBhcmUg aW5zdGFudGlhdGVkIC0gb24gYSBjb250cm9sbGVyLCBvbiBhICJkZXZpY2UiLCBldGMgLSBzZWVt cyB0byBiZSBzZWNvbmRhcnkgYW5kIGluY2lkZW50YWwuICBUaGUgYm91bmRhcmllcyBhcmUgYmx1 cnJ5LCBhbnl3YXlzLiAgQSBjb250cm9sbGVyIGlzIGEgZGV2aWNlIHRvbzsgc29tZSBkZXZpY2Vz IG1heSBjb250YWluIHZpcnR1YWxpemVkIGNvbnRyb2xsZXJzLCBhbmQgc28gb24uICANCj4gDQo+ IE9uZSBtb2RlbCB0aGF0IGlzIHJlbGV2YW50IGluIHRoaXMgZGlzY3Vzc2lvbiBzZWVtcyB0byBi ZSB0aGUgVE1OIG1vZGVsLCBhcyBkZWZpbmVkIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIE0uMzAx MC4gIFRoaXMgbW9kZWwgZGVmaW5lcyBhIHNldCBvZiBtYW5hZ2VtZW50IGxheWVycyAtIG5ldHdv cmsgZWxlbWVudCAoZGV2aWNlKSwgbmV0d29yaywgc2VydmljZSwgYnVzaW5lc3MgLSB3aXRoIHdl bGwgZGVmaW5lZCBmdW5jaW9uYWwgc2NvcGUgb2YgZWFjaCBsYXllci4gIFRoZSBsYXllcnMgLyBm dW5jdGlvbiBoaWVyYXJjaHkgYWxzbyBpbXBseSBhbiBpbmZvcm1hdGlvbiAgYW5kIGRhdGEgbW9k ZWwgaGllcmFyY2h5LiAgDQo+IA0KPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHNlZSBpZiB0aGUg bGF5ZXJpbmcgaW4gTS4zMDEwIGNvdWxkIGhlbHAgZ3VpZGUgWUFORyBtb2RlbCBjbGFzc2lmaWNh dGlvbiwgYW5kIHJlZmVyZW5jZSB0aG9zZSBkZWZpbml0aW9ucz8gIA0KPiANCj4gLS0tIEFsZXgN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5ldG1vZCBbbWFpbHRv Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybCBNb2JlcmcgDQo+IChj YW1vYmVyZykNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDE6NTcgQU0NCj4gVG86 IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4N Cj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2Rl bCBjbGFzc2lmaWNhdGlvbj8NCj4gDQo+IA0KPiANCj4gLS0NCj4gQ2FybCBNb2JlcmcNCj4gVGVj aG5vbG9neSBEaXJlY3RvciwgQ1ZHDQo+IGNhbW9iZXJnQGNpc2NvLmNvbQ0KPiANCj4gPiBPbiBB cHIgNywgMjAxNiwgYXQgMTA6NTUgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1p Y2hhZWwuc2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4+IEkgY29tZSBhdCB0aGlz IGZyb20gdGhlIGNsYXNzaWZpY2F0aW9uIGFuZ2xlLCBzbyBteSBpbnRlcmVzdCBpcyBpZiANCj4g Pj4gdGhlIGFzc3VtcHRpb24gdGhhdCBhIFlBTkcgbW9kZWwgY2FuIG9ubHkgYmUgY2xhc3NpZmll ZCBhcyBhIA0KPiA+PiBuZXR3b3JrIHNlcnZpY2UgbW9kZWwgWE9SIGEgbmV0d29yayBkZXZpY2Ug bW9kZWwgYWNjb3JkaW5nIHRvIHRoZSANCj4gPj4gZGVmaW5pdGlvbnMgaW4gZHJhZnQtaWV0Zi1u ZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiANCj4gPj4gKHNlY3Rpb25zIDIuMSBhbmQg Mi4yKS4gQmFzZWQgb24gdGhpcyBkaXNjdXNzaW9uIEkgdGFrZSBpdCB0aGF0IHNvbWUgbW9kZWxz IGFyZSBpbnRlbmRlZCB0byBiZSBhYmxlIHRvIHNlcnZlIGluIGJvdGggcm9sZXMuIEFuZCB3ZSBz aG91bGQgbWFrZSBzdXJlIHRoYXQgaXTigJlzIHN1cHBvcnRlZCBpbiBvdXIgY2F0YWxvZyBzdHJ1 Y3R1cmUuDQo+ID4gDQo+ID4gUmVnYXJkaW5nIHRoZSBYT1IgYXNzdW1wdGlvbiBmb3IgY2xhc3Np ZmljYXRpb246DQo+ID4gDQo+ID4gWW91IG1heSBhbHNvIHdhbnQgdG8gdGhpbmsgYWJvdXQgWUFO RyBtb2RlbHMgdGhhdCBhcmUgTkVJVEhFUiBkZXZpY2UgTk9SIHNlcnZpY2UgbW9kZWxzLiBGb3Ig aW5zdGFuY2UsIHdoYXQgYWJvdXQgUkZDIDY5OTE/IEFuZCBJIHRoaW5rIG90aGVyLCBtb3JlIHRl Y2huaWNhbCBtb2RlbHMgcHJlc2VudGVkIHRoaXMgd2VlayBtYXkgZmFsbCBpbnRvIGEgc2ltaWxh ciBjYXRlZ29yeSAoImdlbmVyaWMiPykuDQo+IA0KPiAgVmVyeSBnb29kIHBvaW50LCB0aGFua3Mh IFRoYXQgd2lsbCBuZWVkIHNvbWUgYWRkaXRpb25hbCB0aGlua2luZyBhbmQgd3JpdGluZy4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0g DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l biBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwg Mjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8 aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Fri Apr 8 12:02:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAFE12D0E0 for ; Fri, 8 Apr 2016 12:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA93Pd2Tz7aO for ; Fri, 8 Apr 2016 12:02:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5A512D0F3 for ; Fri, 8 Apr 2016 12:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3106; q=dns/txt; s=iport; t=1460142143; x=1461351743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vRmDSE0pvG2+v8MCsxj3rXpXQTcnwM3wymtb92CwU+E=; b=WAE/T69xdE8f0IetCx79TeTESzTsUD345xikNZRqZEexEsFj433kUkWe dBr2tTQKMSg3vbEhPtwDwEW87O0BLvZlLVUqN7s3PCrHmtK2ojTlsphmw ONAOdIoBU8qLlUS+xOm0EKct+o36d0g3sYKaTW4/fxrq/Rmzo52YL5Psd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAG/wdX/40NJK1SBwODN1N9Bro/A?= =?us-ascii?q?Q2Bcx2FcAKBMzgUAQEBAQEBAWUnhEEBAQEDATo/BQcCAgIBCBABBAEBAR4QGxc?= =?us-ascii?q?dCAIEAQ0FCIgXCMBdAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQSKaIQVSyaFDwWYB?= =?us-ascii?q?AGOBIFuh3WFMY8kAR4BAUKDZ2yIOwF9AQEB?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="89436316" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 19:02:22 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u38J2Mxd018998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 19:02:22 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 15:02:21 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 15:02:21 -0400 From: "Alexander Clemm (alex)" To: "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements Thread-Index: AQHRjx7tOw12H05yWU25RG3JKFE7/J9/nzSAgABNhwCAAG5NgIAAFYTA Date: Fri, 8 Apr 2016 19:02:20 +0000 Message-ID: References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> <20160408065748.GA66159@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.91] 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] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:02:32 -0000 Hello Juergen to your question:=20 "> So why do we need 'local data mount' (aka 'alias mount')? Which=20 > problem does it solve that 'peer mounting' localhost does not solve?" Yes, you could apply peer mounting to a local host as a special case. Cert= ainly there is nothing that should prevent that. However, the distinction = is still relevant. For one, in the peer mounting case, the remote host is = considered the authoritative owner, the mounting host is _not_ the authorit= ative owner. In alias mount, since it is the same owner, it has authority.= =20 The fact that in peer mount the local host has no authority means that the = use cases primarily targeted involve cases that require visibility of data = and support for a data retrieval, read-only view. One of the concerns that= had been raised earlier were the ramifications that transactional behavior= and locking etc would have in a distributed scenario. Given that alias-mo= unt is local, things are simplified and use cases that go beyond pure provi= ding visibility easier to support. So, alias mounting may be an important = special case of peer mounting, but also a simple case. This is a fact that= we would like to leverage. =20 In practical terms, alias mount and peer mount can look very similar. Peer= mount involves an additional parameter (to identify the target system), wi= th corresponding additional mountpoint management ramifications. So, peer = mount can in that sense build on top of, or extend, alias mount. =20 --- Alex -----Original Message----- From: Eric Voit (evoit)=20 Sent: Friday, April 08, 2016 6:33 AM To: Juergen Schoenwaelder Cc: Martin Bjorklund ; kwatsen@juniper.net; Alexander Clemm= (alex) ; netmod@ietf.org Subject: RE: [netmod] kw comments on draft-voit-netmod-yang-mount-requireme= nts > From: Juergen Schoenwaelder, April 08, 2016 2:58 AM >=20 > On Fri, Apr 08, 2016 at 02:20:19AM +0000, Eric Voit (evoit) wrote: > > My thinking matches more closely to what Kent lays out above: > > > > schema-mount > > data-mount > > remote data mount (a.k.a. peer mount) > > local data mount (a.k.a. alias mount) > > > > The value in the term "yang mount" is that it provides a conceptual=20 > > umbrella to > ensure a cohesive syntax across the four valid permutations of the=20 > above. The term itself was never intended to be implementable. > > >=20 > So why do we need 'local data mount' (aka 'alias mount')? Which=20 > problem does it solve that 'peer mounting' localhost does not solve? To me it comes down to ease of use for the developer. If the system only al= lows mounting localhost, why require that parameter in the syntax? That p= arameter shouldn't even be available/visible for entry.=20 Eric > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 8 13:05:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1483312D625 for ; Fri, 8 Apr 2016 13:05:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X4CJL_9mnYS for ; Fri, 8 Apr 2016 13:05:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED0712D568 for ; Fri, 8 Apr 2016 13:05:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D30D620183; Fri, 8 Apr 2016 16:08:40 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DEDB463755; Fri, 8 Apr 2016 16:05:00 -0400 (EDT) From: Michael Richardson To: Eliot Lear , netmod@ietf.org In-Reply-To: <5707BB90.3020700@cisco.com> References: <29371.1460055085@obiwan.sandelman.ca> <5706B779.5050602@cisco.com> <28476.1460063381@obiwan.sandelman.ca> <5707BB90.3020700@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] mud documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 20:05:07 -0000 --=-=-= Content-Type: text/plain Eliot and I have been conversing about policies. I proposed that I want a policy like: He asked me three questions: 0 what happens when the policy enforcement point (PEP) that actually operationalizes the policy does not understand the policy in its entirety? Does it implement what it can, or does it discard? 1 Where does connections per unit of time fit in the above? 2 Where does logging/notification fit into the above? I proposed that we wanted policies like this: >---< I am a printer. I accept connections on the IPP port. Please be suspicious when the connections are non-local. Eliot asked: > There is no concept today of . Let me ask what network > behavior you would associate with that? I answered: mcr> Consider blocking them if they occur too frequently, or the mcr> connections have a small number of RTTs. I also think that the "be-suspicious" part might be significantly modified by local policy. It could be that this results in no connections, it could be that it must be approved by an admin, that it's subject to some kind of site-wide ACL (such connections from the VPN, intranet and partners okay, not the wild internet...) We discussed whether we could clearly articulate other policies like connections/minute or connections/day that would be not-suspicious. I also suggested that this could extend beyond "THINGS" to *APPS* as well: consider that the MUD could well be packaged with PC/Android/iPhone *apps* as part of their security profile. SELinux pretends to do this, but in practice configuring it is still close to impossible. The MUD specification would help a lot I think. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwgO6oCLcPvd0N1lAQKAXAf/XRlSxdoAcs/ujjV2zjEvrNOiq7o7/bKb aigh80on6RRJ5DUuk3GN+7pCvtkfA/ixU5J5Y/YGCbom2fE2w0ijZKJ6ZzvVNQSZ e+w+weZgzGel6piwRrrho3iRF/1g6znePxMLa17D4IjZ1onsfHAIpCgkQ2BEBPpj 9YmjIXIzpwr5y0Y0nHkMe4+cNIlJiz4E133JJiOdMvZZNg1IAaXKp4BoXDghwT5b a465n3RJC8s9EQCAVKku2sR3F8CLey1nwNJoTv8tNeL+YYOyrzEcvFu7X998ZFgt Lm7y2Vp7iU7ARE16BVLpZLd/mR33bvh2NahR9uC6i347lTBQbOW90A== =Dcnt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 8 17:23:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8E112D54C for ; Fri, 8 Apr 2016 17:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf7NQFQk0SAE for ; Fri, 8 Apr 2016 17:23:42 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7D12D623 for ; Fri, 8 Apr 2016 17:23:41 -0700 (PDT) Received: from tops.chopps.org (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A84A66115B; Sat, 9 Apr 2016 00:23:40 +0000 (UTC) References: <1458566013189.55874@pantheon.tech> User-agent: mu4e 0.9.16; emacs 24.5.1 From: To: Ladislav Lhotka In-reply-to: Date: Fri, 08 Apr 2016 20:23:39 -0400 Message-ID: <87lh4n4ol0.fsf@tops.chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 00:23:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ladislav Lhotka writes: > Hi Anton, > > Anton Tk=C3=A1=C4=8Dik writes: > >> Hi, >> >> if I understand correctly netmod-structural-mount inlines "mounted" data= directly to container / list which is used, >> >> which brings up following issues: >> >> >> 1. It is possible to have identifier conflict between data from model >> defining mount and mounted data (if mounted schema > > I think we need to eliminate all kinds of recursive mount, so this > should not happen. While I think I need more help understanding the original problem (maybe more explicit example of where the conflict is?), I wanted to point out that when we (the RTG yang DT) originally came up with our desire for a schema-mount, the ability to mount things recursively was seen as a feature, and not something to be restricted or disallowed. For example consider a physical network device that creates a logical network element, which could then creates its own logical network element (i.e., a guest of the guest of the host in VM terms) Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXCEuLAAoJEC4dgw7XuDAlld4P/jWAMHL7q0oAFC1692sWrZlJ O1yaSwiR1S1zQvXlgtOYeNphtXJGDCO6ZDkz4ECbsWwjUUU1xoaAoTetEBY2Y5U3 FnuOz8jUGss0hHLNjVm7gJOTjB0AnH+VzzIG2A2ZDMc3s8g4wY5RkXLNk09cRm2M 85G+kxcVYkormCIbMLZaC5QpaHefe5XA1G8r/9W4WYHL0WPhYPjtRlW4hyjDvq8k XI0CWMQVRjqEiHh5n60Y9BucWOdeOcqZGeRn0CpJTJUOGHlPPd1B7lCvG0/xuw5H eb09Kirl4os95LJvGSgAPZ7iP6LXuv9t2RY8YgcSf6woSdAdhYpXqXbpx2OHxgEm MfQxTh34KS5nf3ld2g1FVlpIAlFobC1En99LQQVZK7x8ajb3Ef6lnEGRRPiOn9ng OkZ9SOj67l0LCthCec/twvBeS/la22QEELkYatXmRN16ZVGOKnbn9FAoRme1rrq1 q5JILZKjwM+MyrMX58Y5OgGAj+NAyPy3pJfYikt8YAmCYk0qKRiXN5qazwm9STKi D2hU2Dw1BtDUlIGeMKR+xZn3gqlyc3Yqs/0y+Tqk7YmQs8gpsRbVQWLQzNURco86 f1HnlADVJC7GUJ1juArsRXYvuvPCh1ZWh7Xsnf7m/t5i5+G9Shsa1fmkw7WKqzkj 1Bf6mWBGdXkcFpU6us9w =eUF8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 9 00:32:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9051C12D15C for ; Sat, 9 Apr 2016 00:32: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aPoAftXRDxV for ; Sat, 9 Apr 2016 00:32:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DFC7312D14B for ; Sat, 9 Apr 2016 00:32:37 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 0FF271AE0386; Sat, 9 Apr 2016 09:32:35 +0200 (CEST) Date: Sat, 09 Apr 2016 09:32:34 +0200 (CEST) Message-Id: <20160409.093234.138748394999396297.mbj@tail-f.com> To: chopps@chopps.org From: Martin Bjorklund In-Reply-To: <87lh4n4ol0.fsf@tops.chopps.org> References: <1458566013189.55874@pantheon.tech> <87lh4n4ol0.fsf@tops.chopps.org> 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] draft-bjorklund-netmod-structural-mount: Namespace issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 07:32:39 -0000 PGNob3Bwc0BjaG9wcHMub3JnPiB3cm90ZToNCj4gDQo+IExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej4gd3JpdGVzOg0KPiANCj4gPiBIaSBBbnRvbiwNCj4gPg0KPiA+IEFudG9uIFRrw6HE jWlrIDxhbnRvbi50a2FjaWtAcGFudGhlb24udGVjaD4gd3JpdGVzOg0KPiA+DQo+ID4+IEhpLA0K PiA+Pg0KPiA+PiBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IG5ldG1vZC1zdHJ1Y3R1cmFsLW1v dW50IGlubGluZXMgIm1vdW50ZWQiIGRhdGEgZGlyZWN0bHkgdG8gY29udGFpbmVyIC8gbGlzdCB3 aGljaCBpcyB1c2VkLA0KPiA+Pg0KPiA+PiB3aGljaCBicmluZ3MgdXAgZm9sbG93aW5nIGlzc3Vl czoNCj4gPj4NCj4gPj4NCj4gPj4gMS4gSXQgaXMgcG9zc2libGUgdG8gaGF2ZSBpZGVudGlmaWVy IGNvbmZsaWN0IGJldHdlZW4gZGF0YSBmcm9tIG1vZGVsDQo+ID4+IGRlZmluaW5nIG1vdW50IGFu ZCBtb3VudGVkIGRhdGEgKGlmIG1vdW50ZWQgc2NoZW1hDQo+ID4NCj4gPiBJIHRoaW5rIHdlIG5l ZWQgdG8gZWxpbWluYXRlIGFsbCBraW5kcyBvZiByZWN1cnNpdmUgbW91bnQsIHNvIHRoaXMNCj4g PiBzaG91bGQgbm90IGhhcHBlbi4NCj4gDQo+IFdoaWxlIEkgdGhpbmsgSSBuZWVkIG1vcmUgaGVs cCB1bmRlcnN0YW5kaW5nIHRoZSBvcmlnaW5hbCBwcm9ibGVtIChtYXliZQ0KPiBtb3JlIGV4cGxp Y2l0IGV4YW1wbGUgb2Ygd2hlcmUgdGhlIGNvbmZsaWN0IGlzPyksIEkgd2FudGVkIHRvIHBvaW50 IG91dA0KPiB0aGF0IHdoZW4gd2UgKHRoZSBSVEcgeWFuZyBEVCkgb3JpZ2luYWxseSBjYW1lIHVw IHdpdGggb3VyIGRlc2lyZSBmb3IgYQ0KPiBzY2hlbWEtbW91bnQsIHRoZSBhYmlsaXR5IHRvIG1v dW50IHRoaW5ncyByZWN1cnNpdmVseSB3YXMgc2VlbiBhcyBhDQo+IGZlYXR1cmUsIGFuZCBub3Qg c29tZXRoaW5nIHRvIGJlIHJlc3RyaWN0ZWQgb3IgZGlzYWxsb3dlZC4gRm9yIGV4YW1wbGUNCj4g Y29uc2lkZXIgYSBwaHlzaWNhbCBuZXR3b3JrIGRldmljZSB0aGF0IGNyZWF0ZXMgYSBsb2dpY2Fs IG5ldHdvcmsNCj4gZWxlbWVudCwgd2hpY2ggY291bGQgdGhlbiBjcmVhdGVzIGl0cyBvd24gbG9n aWNhbCBuZXR3b3JrIGVsZW1lbnQgKGkuZS4sDQo+IGEgZ3Vlc3Qgb2YgdGhlIGd1ZXN0IG9mIHRo ZSBob3N0IGluIFZNIHRlcm1zKQ0KDQpUaGUgY3VycmVudCBzY2hlbWEtbW91bnQgc3VwcG9ydHMg cmVjdXJzaXZlIG1vdW50cyBpbiB0aGUgc2NoZW1hDQooZS5nLiwgaWYgaWV0Zi1sb2dpY2FsLWRl dmljZXMgaGFzIGEgbW91bnRwb2ludCwgaXQgbWlnaHQgYmUgdGhhdA0KaWV0Zi1sb2dpY2FsLWRl dmljZXMgaXMgbW91bnRlZCB0aGVyZSkuICBNYXliZSAnbmVzdGVkIG1vdW50cycgaXMgYQ0KYmV0 dGVyIHRlcm0uICBCdXQgd2l0aCBhIHNvbHV0aW9uIGxpa2UgcGVlciBtb3VudCwgeW91IHByb2Jh Ymx5IHdhbnQNCnRvIHN0YXkgb3V0IG9mIHJlY3Vyc2l2ZSBtb3VudHMgKEEgbW91bnRzIEIgd2hp Y2ggbW91bnRzIEEpLg0KDQpJIGFsc28gZG8gbm90IHVuZGVyc3RhbmQgdGhlIG9yaWdpbmFsIHF1 ZXN0aW9uIHJlZ2FyZGluZyBpZGVudGlmaWVyDQpjb25mbGljdHMuDQoNCg0KL21hcnRpbg0K From nobody Sat Apr 9 01:29:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F353612D10D for ; Sat, 9 Apr 2016 01:29: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, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TygDLbuZqOLz for ; Sat, 9 Apr 2016 01:29: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 B349312D0EC for ; Sat, 9 Apr 2016 01:29:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2B322226; Sat, 9 Apr 2016 10:29:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QjhNo8bghbWg; Sat, 9 Apr 2016 10:29: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; Sat, 9 Apr 2016 10:29:48 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1D2420046; Sat, 9 Apr 2016 10:29:48 +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 wE0WiUBdK5vv; Sat, 9 Apr 2016 10:29:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D2FE20043; Sat, 9 Apr 2016 10:29:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8FDDB3A76447; Sat, 9 Apr 2016 10:29:45 +0200 (CEST) Date: Sat, 9 Apr 2016 10:29:45 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20160409082944.GA68503@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , "Eric Voit (evoit)" , Martin Bjorklund , "kwatsen@juniper.net" , "netmod@ietf.org" References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> <20160408065748.GA66159@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] kw comments on draft-voit-netmod-yang-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 09 Apr 2016 08:29:55 -0000 Is the essence of your long text that the difference of alias mount and local peer mount is: alias mount = read-write peer mount = read-only Is it documented somewhere how writing (including locking) works with alias mount, how NACM works with alias mount, ...? /js On Fri, Apr 08, 2016 at 07:02:20PM +0000, Alexander Clemm (alex) wrote: > Hello Juergen > > to your question: > "> So why do we need 'local data mount' (aka 'alias mount')? Which > > problem does it solve that 'peer mounting' localhost does not solve?" > > Yes, you could apply peer mounting to a local host as a special case. Certainly there is nothing that should prevent that. However, the distinction is still relevant. For one, in the peer mounting case, the remote host is considered the authoritative owner, the mounting host is _not_ the authoritative owner. In alias mount, since it is the same owner, it has authority. > > The fact that in peer mount the local host has no authority means that the use cases primarily targeted involve cases that require visibility of data and support for a data retrieval, read-only view. One of the concerns that had been raised earlier were the ramifications that transactional behavior and locking etc would have in a distributed scenario. Given that alias-mount is local, things are simplified and use cases that go beyond pure providing visibility easier to support. So, alias mounting may be an important special case of peer mounting, but also a simple case. This is a fact that we would like to leverage. > > In practical terms, alias mount and peer mount can look very similar. Peer mount involves an additional parameter (to identify the target system), with corresponding additional mountpoint management ramifications. So, peer mount can in that sense build on top of, or extend, alias mount. > > --- Alex > > -----Original Message----- > From: Eric Voit (evoit) > Sent: Friday, April 08, 2016 6:33 AM > To: Juergen Schoenwaelder > Cc: Martin Bjorklund ; kwatsen@juniper.net; Alexander Clemm (alex) ; netmod@ietf.org > Subject: RE: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements > > > From: Juergen Schoenwaelder, April 08, 2016 2:58 AM > > > > On Fri, Apr 08, 2016 at 02:20:19AM +0000, Eric Voit (evoit) wrote: > > > My thinking matches more closely to what Kent lays out above: > > > > > > schema-mount > > > data-mount > > > remote data mount (a.k.a. peer mount) > > > local data mount (a.k.a. alias mount) > > > > > > The value in the term "yang mount" is that it provides a conceptual > > > umbrella to > > ensure a cohesive syntax across the four valid permutations of the > > above. The term itself was never intended to be implementable. > > > > > > > So why do we need 'local data mount' (aka 'alias mount')? Which > > problem does it solve that 'peer mounting' localhost does not solve? > > To me it comes down to ease of use for the developer. If the system only allows mounting localhost, why require that parameter in the syntax? That parameter shouldn't even be available/visible for entry. > > Eric > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Apr 10 05:37:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3EB12D555 for ; Sun, 10 Apr 2016 05:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX7zTLapIYc7 for ; Sun, 10 Apr 2016 05:37:33 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E3212B007 for ; Sun, 10 Apr 2016 05:37:33 -0700 (PDT) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E6C02A80D3; Sun, 10 Apr 2016 14:37:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id N9Gx9vERwzDL; Sun, 10 Apr 2016 14:37:29 +0200 (CEST) X-Originating-IP: 134.102.218.240 Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8D167A80C0; Sun, 10 Apr 2016 14:37:29 +0200 (CEST) Message-ID: <570A4907.7020606@tzi.org> Date: Sun, 10 Apr 2016 14:37:27 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: netmod@ietf.org References: <570A4583.2030100@tzi.org> In-Reply-To: <570A4583.2030100@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [netmod] =?utf-8?b?RndkOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBk?= =?utf-8?q?raft-veillette-core-yang-cbor-mapping-00?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 12:37:35 -0000 In the most recent rechartering of the CoRE working group, which works on application protocols for the Internet of Things, the work on management in constrained node networks (COMI) has been assigned to CoRE. We have promised to involve the relevant management working groups in our proceedings, and this message is part of that. COMI is a RESTCONF variant. Instead of XML or JSON representation of yang modeled data, the plan is to use the more compact (and easier to implement on constrained devices) format CBOR. draft-veillette-core-yang-cbor-mapping-00 is for CBOR what draft-ietf-netmod-yang-json-10 is for JSON. You are welcome to take part in CoRE and submit comments (and/or support for or objections to adoption) there. Of course, any discussion that ensues here on the netmod mailing list will be considered by the CoRE WG chairs as well. (We just want to avoid massive cross-posting; hence this separate message.) Grüße, Carsten -------- Original Message -------- Subject: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00 Date: Sun, 10 Apr 2016 14:22:27 +0200 From: Carsten Bormann To: core@ietf.org WG In Buenos Aires, we discussed the adoption of draft-veillette-core-yang-cbor-mapping-00 but not enough people had read the document to go for an in-room consensus call. This is a two-week call for adoption of draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. Specifically, if you (1) support or (2) have an objection to this decision, please speak up on the mailing list by 2016-04-24. Note that this work is explicitly covered by our charter, so discussions of which WG should work on this are off-topic. As always, adoption of a document as a WG document is not a vote on whether we already have reached last-call state; the intention is to work on the WG document after adoption for a while to get it ready for last call. If you want to combine your support/objection with technical comments, this is certainly welcome so we can accelerate that process. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sun Apr 10 08:31:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5035112D5EC for ; Sun, 10 Apr 2016 08:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQfSvzQzFgwC for ; Sun, 10 Apr 2016 08:31:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEEE12D0A2 for ; Sun, 10 Apr 2016 08:31: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 2680E1676; Sun, 10 Apr 2016 17:31: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 PdeKXRTYwOEE; Sun, 10 Apr 2016 17:30:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 10 Apr 2016 17:31:13 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1202D20045; Sun, 10 Apr 2016 17:31:13 +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 uU0xRwOS3FKg; Sun, 10 Apr 2016 17:31:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56A2F20043; Sun, 10 Apr 2016 17:31:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5133B3A9A6BB; Sun, 10 Apr 2016 17:31:09 +0200 (CEST) Date: Sun, 10 Apr 2016 17:31:09 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20160410153109.GA83581@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , "Carl Moberg (camoberg)" , "Scharf, Michael (Nokia - DE)" , "netmod@ietf.org" References: <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <20160408070737.GB66159@elstar.local> <00726c40293d44dea9bd4ebb35d7ff3f@XCH-RTP-001.cisco.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: <00726c40293d44dea9bd4ebb35d7ff3f@XCH-RTP-001.cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 10 Apr 2016 15:31:21 -0000 This is too abstract for me. There are definitions in draft-ietf-netmod-yang-model-classification-01.txt - it helps us if you can tell us which ones are not precise enough or which ones are missing or which ones you think do not serve a useful purpose. All I wanted to say is that boundaries will not be tight and I this is good as long as we have terms that should ease human communication. /js On Fri, Apr 08, 2016 at 06:45:01PM +0000, Alexander Clemm (alex) wrote: > Hi Juergen, the question is still _how_ it simplifies human communication. To use different terms, it should be clear what different purposes they convey, and why their distinction is relevant and matters. IMHO this needs to be articulated more clearly. If it is not clear why the distinction matters, it does not simplify communication. > --- Alex > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, April 08, 2016 12:08 AM > To: Alexander Clemm (alex) > Cc: Carl Moberg (camoberg) ; Scharf, Michael (Nokia - DE) ; netmod@ietf.org > Subject: Re: [netmod] YANG model classification? > > Yes, the boundaries are blurry and it does not matter which layering model you use. M.3010 does not change the fact that boundaries are blurry. > > I think it is not a problem. My understanding was that the I-D primarily aims at establish a common vocabulary and it should IMHO explicitely state that boundaries are blurry and that the main purpose is to simplify 'human communication'. The classification is not for 'implementation'. > > /js > > On Thu, Apr 07, 2016 at 04:43:51PM +0000, Alexander Clemm (alex) wrote: > > I am wondering what purpose the classification really serves. At the end of the day, it seems to me that we are trying to express a model hierarchy, and articulate what the layers in the hierarchy are. A device model is thus at a lower layer than a service model. An implementation of the service model may in turn have dependencies on the device model, but not the other way round. > > > > Where the models are instantiated - on a controller, on a "device", etc - seems to be secondary and incidental. The boundaries are blurry, anyways. A controller is a device too; some devices may contain virtualized controllers, and so on. > > > > One model that is relevant in this discussion seems to be the TMN model, as defined in ITU-T Recommendation M.3010. This model defines a set of management layers - network element (device), network, service, business - with well defined funcional scope of each layer. The layers / function hierarchy also imply an information and data model hierarchy. > > > > Would it make sense to see if the layering in M.3010 could help guide YANG model classification, and reference those definitions? > > > > --- Alex > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Carl Moberg > > (camoberg) > > Sent: Thursday, April 07, 2016 1:57 AM > > To: Scharf, Michael (Nokia - DE) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] YANG model classification? > > > > > > > > -- > > Carl Moberg > > Technology Director, CVG > > camoberg@cisco.com > > > > > On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) wrote: > > > > > >> I come at this from the classification angle, so my interest is if > > >> the assumption that a YANG model can only be classified as a > > >> network service model XOR a network device model according to the > > >> definitions in draft-ietf-netmod-yang-model-classification > > >> (sections 2.1 and 2.2). Based on this discussion I take it that some models are intended to be able to serve in both roles. And we should make sure that it’s supported in our catalog structure. > > > > > > Regarding the XOR assumption for classification: > > > > > > You may also want to think about YANG models that are NEITHER device NOR service models. For instance, what about RFC 6991? And I think other, more technical models presented this week may fall into a similar category ("generic"?). > > > > Very good point, thanks! That will need some additional thinking and writing. > > _______________________________________________ > > 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 -- 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 Apr 10 08:50:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B7812D5F5 for ; Sun, 10 Apr 2016 08:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvAWvZczCHtA for ; Sun, 10 Apr 2016 08:50:04 -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 3AFDD12D5F7 for ; Sun, 10 Apr 2016 08:50:02 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4A5725BD62FB1; Sun, 10 Apr 2016 15:49:57 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3AFnxb0025590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Apr 2016 15:50:00 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u3AFnxVj007941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Apr 2016 17:49:59 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.46]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 10 Apr 2016 17:49:59 +0200 From: "Scharf, Michael (Nokia - DE)" To: Juergen Schoenwaelder , "Alexander Clemm (alex)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oA//+PPACAABFtAIAAEOqAgAAB/4CAADIeAIAAfSGA///UJlCAADmLgIAAgluAgADxVoCAAMLZgIAC7oCA///aXIA= Date: Sun, 10 Apr 2016 15:49:57 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48787537@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <20160408070737.GB66159@elstar.local> <00726c40293d44dea9bd4ebb35d7ff3f@XCH-RTP-001.cisco.com> <20160410153109.GA83581@elstar.local> In-Reply-To: <20160410153109.GA83581@elstar.local> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 15:50:07 -0000 SGF2aW5nIHRpZ2h0IGJvdW5kYXJpZXMgbWF5IGFsc28gYmUgbm9uLXRyaXZpYWwgd2l0aG91dCBt YWtpbmcgZnVydGhlciBhc3N1bXB0aW9ucyBhYm91dCB0aGUgYWN0dWFsIHN5c3RlbSB0aGF0IHVz ZXMgWUFORyAoZGF0YSkgbW9kZWxzLg0KDQpQZXJzb25hbGx5LCBJJ2QgYmUgZmluZSB3aXRoIGEg d29yZGluZyB0aGF0IHNpbXBseSBhY2tub3dsZWRnZXMgdGhhdCB0aGVyZSBhcmUgZ3JleSBhcmVh cy4NCg0KTWljaGFlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog RVhUIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt DQo+IHVuaXZlcnNpdHkuZGVdDQo+IFNlbnQ6IFN1bmRheSwgQXByaWwgMTAsIDIwMTYgNTozMSBQ TQ0KPiBUbzogQWxleGFuZGVyIENsZW1tIChhbGV4KQ0KPiBDYzogQ2FybCBNb2JlcmcgKGNhbW9i ZXJnKTsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsNCj4gbmV0bW9kQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5HIG1vZGVsIGNsYXNzaWZpY2F0aW9uPw0KPiANCj4g VGhpcyBpcyB0b28gYWJzdHJhY3QgZm9yIG1lLiBUaGVyZSBhcmUgZGVmaW5pdGlvbnMgaW4NCj4g ZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbi0wMS50eHQgLSBpdCBo ZWxwcyB1cyBpZg0KPiB5b3UgY2FuIHRlbGwgdXMgd2hpY2ggb25lcyBhcmUgbm90IHByZWNpc2Ug ZW5vdWdoIG9yIHdoaWNoIG9uZXMgYXJlDQo+IG1pc3Npbmcgb3Igd2hpY2ggb25lcyB5b3UgdGhp bmsgZG8gbm90IHNlcnZlIGEgdXNlZnVsIHB1cnBvc2UuDQo+IA0KPiBBbGwgSSB3YW50ZWQgdG8g c2F5IGlzIHRoYXQgYm91bmRhcmllcyB3aWxsIG5vdCBiZSB0aWdodCBhbmQgSSB0aGlzIGlzDQo+ IGdvb2QgYXMgbG9uZyBhcyB3ZSBoYXZlIHRlcm1zIHRoYXQgc2hvdWxkIGVhc2UgaHVtYW4gY29t bXVuaWNhdGlvbi4NCj4gDQo+IC9qcw0KPiANCj4gT24gRnJpLCBBcHIgMDgsIDIwMTYgYXQgMDY6 NDU6MDFQTSArMDAwMCwgQWxleGFuZGVyIENsZW1tIChhbGV4KSB3cm90ZToNCj4gPiBIaSBKdWVy Z2VuLCB0aGUgcXVlc3Rpb24gaXMgc3RpbGwgX2hvd18gaXQgc2ltcGxpZmllcyBodW1hbg0KPiBj b21tdW5pY2F0aW9uLiAgVG8gdXNlIGRpZmZlcmVudCB0ZXJtcywgaXQgc2hvdWxkIGJlIGNsZWFy IHdoYXQNCj4gZGlmZmVyZW50IHB1cnBvc2VzIHRoZXkgY29udmV5LCBhbmQgd2h5IHRoZWlyIGRp c3RpbmN0aW9uIGlzIHJlbGV2YW50DQo+IGFuZCBtYXR0ZXJzLiAgSU1ITyB0aGlzIG5lZWRzIHRv IGJlIGFydGljdWxhdGVkIG1vcmUgY2xlYXJseS4gSWYgaXQgaXMNCj4gbm90IGNsZWFyIHdoeSB0 aGUgZGlzdGluY3Rpb24gbWF0dGVycywgaXQgZG9lcyBub3Qgc2ltcGxpZnkNCj4gY29tbXVuaWNh dGlvbi4NCj4gPiAtLS0gQWxleA0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJA amFjb2JzLQ0KPiB1bml2ZXJzaXR5LmRlXQ0KPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMDgsIDIw MTYgMTI6MDggQU0NCj4gPiBUbzogQWxleGFuZGVyIENsZW1tIChhbGV4KSA8YWxleEBjaXNjby5j b20+DQo+ID4gQ2M6IENhcmwgTW9iZXJnIChjYW1vYmVyZykgPGNhbW9iZXJnQGNpc2NvLmNvbT47 IFNjaGFyZiwgTWljaGFlbA0KPiAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNv bT47IG5ldG1vZEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5HIG1vZGVs IGNsYXNzaWZpY2F0aW9uPw0KPiA+DQo+ID4gWWVzLCB0aGUgYm91bmRhcmllcyBhcmUgYmx1cnJ5 IGFuZCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hpY2ggbGF5ZXJpbmcNCj4gbW9kZWwgeW91IHVzZS4g TS4zMDEwIGRvZXMgbm90IGNoYW5nZSB0aGUgZmFjdCB0aGF0IGJvdW5kYXJpZXMgYXJlDQo+IGJs dXJyeS4NCj4gPg0KPiA+IEkgdGhpbmsgaXQgaXMgbm90IGEgcHJvYmxlbS4gTXkgdW5kZXJzdGFu ZGluZyB3YXMgdGhhdCB0aGUgSS1EDQo+IHByaW1hcmlseSBhaW1zIGF0IGVzdGFibGlzaCBhIGNv bW1vbiB2b2NhYnVsYXJ5IGFuZCBpdCBzaG91bGQgSU1ITw0KPiBleHBsaWNpdGVseSBzdGF0ZSB0 aGF0IGJvdW5kYXJpZXMgYXJlIGJsdXJyeSBhbmQgdGhhdCB0aGUgbWFpbiBwdXJwb3NlDQo+IGlz IHRvIHNpbXBsaWZ5ICdodW1hbiBjb21tdW5pY2F0aW9uJy4gVGhlIGNsYXNzaWZpY2F0aW9uIGlz IG5vdCBmb3INCj4gJ2ltcGxlbWVudGF0aW9uJy4NCj4gPg0KPiA+IC9qcw0KPiA+DQo+ID4gT24g VGh1LCBBcHIgMDcsIDIwMTYgYXQgMDQ6NDM6NTFQTSArMDAwMCwgQWxleGFuZGVyIENsZW1tIChh bGV4KQ0KPiB3cm90ZToNCj4gPiA+IEkgYW0gd29uZGVyaW5nIHdoYXQgcHVycG9zZSB0aGUgY2xh c3NpZmljYXRpb24gcmVhbGx5IHNlcnZlcy4gIEF0DQo+IHRoZSBlbmQgb2YgdGhlIGRheSwgaXQg c2VlbXMgdG8gbWUgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGV4cHJlc3MgYQ0KPiBtb2RlbCBoaWVy YXJjaHksIGFuZCBhcnRpY3VsYXRlIHdoYXQgdGhlIGxheWVycyBpbiB0aGUgaGllcmFyY2h5IGFy ZS4NCj4gQSBkZXZpY2UgbW9kZWwgaXMgdGh1cyBhdCBhIGxvd2VyIGxheWVyIHRoYW4gYSBzZXJ2 aWNlIG1vZGVsLiAgQW4NCj4gaW1wbGVtZW50YXRpb24gb2YgdGhlIHNlcnZpY2UgbW9kZWwgbWF5 IGluIHR1cm4gaGF2ZSBkZXBlbmRlbmNpZXMgb24NCj4gdGhlIGRldmljZSBtb2RlbCwgYnV0IG5v dCB0aGUgb3RoZXIgd2F5IHJvdW5kLg0KPiA+ID4NCj4gPiA+IFdoZXJlIHRoZSBtb2RlbHMgYXJl IGluc3RhbnRpYXRlZCAtIG9uIGEgY29udHJvbGxlciwgb24gYSAiZGV2aWNlIiwNCj4gZXRjIC0g c2VlbXMgdG8gYmUgc2Vjb25kYXJ5IGFuZCBpbmNpZGVudGFsLiAgVGhlIGJvdW5kYXJpZXMgYXJl IGJsdXJyeSwNCj4gYW55d2F5cy4gIEEgY29udHJvbGxlciBpcyBhIGRldmljZSB0b287IHNvbWUg ZGV2aWNlcyBtYXkgY29udGFpbg0KPiB2aXJ0dWFsaXplZCBjb250cm9sbGVycywgYW5kIHNvIG9u Lg0KPiA+ID4NCj4gPiA+IE9uZSBtb2RlbCB0aGF0IGlzIHJlbGV2YW50IGluIHRoaXMgZGlzY3Vz c2lvbiBzZWVtcyB0byBiZSB0aGUgVE1ODQo+IG1vZGVsLCBhcyBkZWZpbmVkIGluIElUVS1UIFJl Y29tbWVuZGF0aW9uIE0uMzAxMC4gIFRoaXMgbW9kZWwgZGVmaW5lcyBhDQo+IHNldCBvZiBtYW5h Z2VtZW50IGxheWVycyAtIG5ldHdvcmsgZWxlbWVudCAoZGV2aWNlKSwgbmV0d29yaywgc2Vydmlj ZSwNCj4gYnVzaW5lc3MgLSB3aXRoIHdlbGwgZGVmaW5lZCBmdW5jaW9uYWwgc2NvcGUgb2YgZWFj aCBsYXllci4gIFRoZSBsYXllcnMNCj4gLyBmdW5jdGlvbiBoaWVyYXJjaHkgYWxzbyBpbXBseSBh biBpbmZvcm1hdGlvbiAgYW5kIGRhdGEgbW9kZWwNCj4gaGllcmFyY2h5Lg0KPiA+ID4NCj4gPiA+ IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gc2VlIGlmIHRoZSBsYXllcmluZyBpbiBNLjMwMTAgY291 bGQgaGVscA0KPiBndWlkZSBZQU5HIG1vZGVsIGNsYXNzaWZpY2F0aW9uLCBhbmQgcmVmZXJlbmNl IHRob3NlIGRlZmluaXRpb25zPw0KPiA+ID4NCj4gPiA+IC0tLSBBbGV4DQo+ID4gPg0KPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybA0KPiBNb2JlcmcNCj4gPiA+ IChjYW1vYmVyZykNCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiAxOjU3IEFN DQo+ID4gPiBUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZA bm9raWEuY29tPg0KPiA+ID4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6 IFtuZXRtb2RdIFlBTkcgbW9kZWwgY2xhc3NpZmljYXRpb24/DQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiAtLQ0KPiA+ID4gQ2FybCBNb2JlcmcNCj4gPiA+IFRlY2hub2xvZ3kgRGlyZWN0b3Is IENWRw0KPiA+ID4gY2Ftb2JlcmdAY2lzY28uY29tDQo+ID4gPg0KPiA+ID4gPiBPbiBBcHIgNywg MjAxNiwgYXQgMTA6NTUgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkNCj4gPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+PiBJIGNvbWUgYXQg dGhpcyBmcm9tIHRoZSBjbGFzc2lmaWNhdGlvbiBhbmdsZSwgc28gbXkgaW50ZXJlc3QgaXMNCj4g aWYNCj4gPiA+ID4+IHRoZSBhc3N1bXB0aW9uIHRoYXQgYSBZQU5HIG1vZGVsIGNhbiBvbmx5IGJl IGNsYXNzaWZpZWQgYXMgYQ0KPiA+ID4gPj4gbmV0d29yayBzZXJ2aWNlIG1vZGVsIFhPUiBhIG5l dHdvcmsgZGV2aWNlIG1vZGVsIGFjY29yZGluZyB0bw0KPiB0aGUNCj4gPiA+ID4+IGRlZmluaXRp b25zIGluIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24NCj4gPiA+ ID4+IChzZWN0aW9ucyAyLjEgYW5kIDIuMikuIEJhc2VkIG9uIHRoaXMgZGlzY3Vzc2lvbiBJIHRh a2UgaXQgdGhhdA0KPiBzb21lIG1vZGVscyBhcmUgaW50ZW5kZWQgdG8gYmUgYWJsZSB0byBzZXJ2 ZSBpbiBib3RoIHJvbGVzLiBBbmQgd2UNCj4gc2hvdWxkIG1ha2Ugc3VyZSB0aGF0IGl04oCZcyBz dXBwb3J0ZWQgaW4gb3VyIGNhdGFsb2cgc3RydWN0dXJlLg0KPiA+ID4gPg0KPiA+ID4gPiBSZWdh cmRpbmcgdGhlIFhPUiBhc3N1bXB0aW9uIGZvciBjbGFzc2lmaWNhdGlvbjoNCj4gPiA+ID4NCj4g PiA+ID4gWW91IG1heSBhbHNvIHdhbnQgdG8gdGhpbmsgYWJvdXQgWUFORyBtb2RlbHMgdGhhdCBh cmUgTkVJVEhFUg0KPiBkZXZpY2UgTk9SIHNlcnZpY2UgbW9kZWxzLiBGb3IgaW5zdGFuY2UsIHdo YXQgYWJvdXQgUkZDIDY5OTE/IEFuZCBJDQo+IHRoaW5rIG90aGVyLCBtb3JlIHRlY2huaWNhbCBt b2RlbHMgcHJlc2VudGVkIHRoaXMgd2VlayBtYXkgZmFsbCBpbnRvIGENCj4gc2ltaWxhciBjYXRl Z29yeSAoImdlbmVyaWMiPykuDQo+ID4gPg0KPiA+ID4gIFZlcnkgZ29vZCBwb2ludCwgdGhhbmtz ISBUaGF0IHdpbGwgbmVlZCBzb21lIGFkZGl0aW9uYWwgdGhpbmtpbmcNCj4gYW5kIHdyaXRpbmcu DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+IC0tDQo+ID4gSnVlcmdlbiBT Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4g PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC cmVtZW4gfA0KPiBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8 aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiAtLQ0KPiBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Sun Apr 10 22:34:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31B512E4DA; Sun, 10 Apr 2016 22:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj5ESv9a3maR; Sun, 10 Apr 2016 22:34:55 -0700 (PDT) Received: from BLU004-OMC3S15.hotmail.com (blu004-omc3s15.hotmail.com [65.55.116.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24A612E4D9; Sun, 10 Apr 2016 22:34:54 -0700 (PDT) Received: from BLU436-SMTP166 ([65.55.116.73]) by BLU004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 10 Apr 2016 22:34:53 -0700 X-TMN: [K2fESQIo+3l/k1qjJ3FkasF9V4GxTxjn] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Sun, 10 Apr 2016 22:34:42 -0700 From: Ashesh Mishra To: , Thread-Topic: IETF-95 netmod meeting minutes posted MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3543172491_9639583" X-OriginalArrivalTime: 11 Apr 2016 05:34:51.0928 (UTC) FILETIME=[DEF1E980:01D193B3] Archived-At: Subject: [netmod] IETF-95 netmod meeting minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 05:34:57 -0000 --B_3543172491_9639583 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, The NETMOD meeting minutes for IETF-95 have been posted at https://www.ietf.org/proceedings/95/minutes/minutes-95-netmod Thanks to everyone who participated. Cheers! Ashesh --B_3543172491_9639583 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
All,

The NETMOD meeting minutes for IETF-95 have been posted at https://www.iet= f.org/proceedings/95/minutes/minutes-95-netmod

= Thanks to everyone who participated. 

Cheers!<= /div>
Ashesh
--B_3543172491_9639583-- From nobody Mon Apr 11 03:46:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AB512DF6C for ; Mon, 11 Apr 2016 03:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hdA_rn-oZyo for ; Mon, 11 Apr 2016 03:46:38 -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 319E012DCA0 for ; Mon, 11 Apr 2016 03:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12117; q=dns/txt; s=iport; t=1460371598; x=1461581198; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=GuX212A4u0nDem/d3z7EkQJy4lS2mrSZ3Y0b4slVSZc=; b=afIIV00IIg0w0NDf25FFfinNPLo/eIIEBlndgerKvGbiDD9g/SvFTcQD sA8Tlg2FqLy5uYINnidzbpzZCc3ftxRZQSmMRmKQbiK3JDca0EdmVQ6hN t6D5recGcU159gnePm0EHBdGgzEKcOQ1JIa6C/dl1ekbeJ5b1ndw/833i 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLEQD2fwtX/xbLJq1dhAp9qACNZ4ZzF?= =?us-ascii?q?wEJhSJKAoF1AQEBAQEBZieEQQEBAQQBAQEaSgcKEQsRAwECAQkWCAcJAwIBAgE?= =?us-ascii?q?VHwkIBgEMBgIBAYgjDr1PAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYRLhF+FN?= =?us-ascii?q?gWHcJAUhXeIFYFnhE2DBYVUjyZigjKBNjswiisBAQE?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208,217";a="635125906" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2016 10:46:35 +0000 Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3BAkZmw023065; Mon, 11 Apr 2016 10:46:35 GMT To: Eric Gray , "netmod@ietf.org" References: <3ED0CE30-93F9-4DBF-9129-DBA57C812493@ericsson.com> From: Robert Wilton Message-ID: <570B8089.2060903@cisco.com> Date: Mon, 11 Apr 2016 11:46:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <3ED0CE30-93F9-4DBF-9129-DBA57C812493@ericsson.com> Content-Type: multipart/alternative; boundary="------------000908000905060406020002" Archived-At: Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 10:46:41 -0000 This is a multi-part message in MIME format. --------------000908000905060406020002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Eric, Sorry for the delay, just catching up after some PTO. In short, this draft is defining extensions to RFC 7223 for common interface based features that are mostly applicable to routers/switches. The idea is that there is a set of fairly common interface level features that several (perhaps most?) router vendors implement, and many customers make use of for configuring their networks. Examples include MTU configuration, or carrier delay (also sometimes called interface hold time). If you are familiar with the OpenConfig interface models (https://github.com/openconfig/public/tree/master/release) then you will see that they also define some of the same leaves that are not defined in RFC 7223. Of course, as you say, each vendor could define their own proprietary extensions to RFC 7223 to cover the specific features that they implement. Alas, this would then require the operators to use hard coded proprietary leaves/paths when trying to configure fairly standard network configurations. As such, I believe that for all the features covered by this draft there is no direct equivalent in RFC 7223. Thanks, Rob On 06/04/2016 14:57, Eric Gray wrote: > Apologies for responding so late to this message. > > I only recently was apprised of this draft and I wanted to know if the > authors can explain what the draft offers that is not already easily > supported using RFC 7223? > > If it is possible to support the capabilities explicitly targeted in > this draft, using the existing model, does it make sense to introduce > a new set of enhancements that make it possible to represent the same > concepts in two ways? > > -- > Eric > > ----------------- > > > Re: [netmod] call for consensus to adopt > draft-wilton-netmod-intf-ext-yang as NETMOD WG draft > > Kent Watsen > Mon, 29 > February 2016 23:07 UTCShow header > > > The chairs were just reviewing notes and realized that this thread > never closed properly. Juergen has some concerns regarding realistic > milestones, that were never addressed. Robert, can you please try to > address Juergen’s concerns now? Also, there were only a two responses > before indicating willingness to review the draft as it progresses > (thanks Dan and Martin). Can others that support this draft and > willing to review this draft say so? Thanks, Netmod Chairs From: > netmod > on > behalf of Kent Watsen > Date: > Tuesday, December 15, 2015 at 11:48 AM To: "netmod@ietf.org > " > Subject: [netmod] > call for consensus to adopt draft-wilton-netmod-intf-ext-yang as > NETMOD WG draft The minutes for IETF 94 show that there was in-room > support for adopting draft-wilton-netmod-intf-ext-yang as a WG draft. > The minutes also show that this decision would be confirmed on the > mailing list, which I am doing now. Should we move to adopt > draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add > this to the WG charter as a milestone? Please comment by Tuesday, > December 22, 2015 at 9AM EST at which time the WG Chairs will gauge > whether or not there is consensus to move forward with the document. > Thanks, Kent > Sent from my iPad > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000908000905060406020002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Eric,

Sorry for the delay, just catching up after some PTO.

In short, this draft is defining extensions to RFC 7223 for common interface based features that are mostly applicable to routers/switches.

The idea is that there is a set of fairly common interface level features that several (perhaps most?) router vendors implement, and many customers make use of for configuring their networks.  Examples include MTU configuration, or carrier delay (also sometimes called interface hold time).  If you are familiar with the OpenConfig interface models (https://github.com/openconfig/public/tree/master/release) then you will see that they also define some of the same leaves that are not defined in RFC 7223.

Of course, as you say, each vendor could define their own proprietary extensions to RFC 7223 to cover the specific features that they implement.  Alas, this would then require the operators to use hard coded proprietary leaves/paths when trying to configure fairly standard network configurations.

As such, I believe that for all the features covered by this draft there is no direct equivalent in RFC 7223.

Thanks,
Rob


On 06/04/2016 14:57, Eric Gray wrote:
Apologies for responding so late to this message.

I only recently was apprised of this draft and I wanted to know if the authors can explain what the draft offers that is not already easily supported using RFC 7223?

If it is possible to support the capabilities explicitly targeted in this draft, using the existing model, does it make sense to introduce a new set of enhancements that make it possible to represent the same concepts in two ways?

--
Eric

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

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

Kent Watsen <kwatsen@juniper.net> Mon, 29 February 2016 23:07 UTCShow header

The chairs were just reviewing notes and realized that this thread never closed properly.

Juergen has some concerns regarding realistic milestones, that were never addressed.  Robert, can you please try to address Juergen’s concerns now?

Also, there were only a two responses before indicating willingness to review the draft as it progresses (thanks Dan and Martin).  Can others that support this draft and willing to review this draft say so?

Thanks,
Netmod Chairs


From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> on behalf of Kent Watsen <kwatsen@juniper.net<mailto:kwatsen@juniper.net>>
Date: Tuesday, December 15, 2015 at 11:48 AM
To: "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft


The minutes for IETF 94 show that there was in-room support for adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that this decision would be confirmed on the mailing list, which I am doing now.

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add this to the WG charter as a milestone?  Please comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge whether or not there is consensus to move forward with the document.

Thanks,
Kent
Sent from my iPad


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

--------------000908000905060406020002-- From nobody Mon Apr 11 04:02:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B1212E11D for ; Mon, 11 Apr 2016 04:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylkLj9lgfXcD for ; Mon, 11 Apr 2016 04:02:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332EA12E90F for ; Mon, 11 Apr 2016 04:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16082; q=dns/txt; s=iport; t=1460372520; x=1461582120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3tEBculHjS5R1o8qkGsHVbbfIRLa16JKWCqROxwWIjk=; b=e5lL1za+lFRx/67tKk9qWnyFSSsrpgKNBjKqKUnVEqbhFvmY1ovq7mov fV+OE4agRtHclO2Mpiec36XTY99Vln+XRvQE3xoPFCLsY4bxw3s9q/J6R aDkvstv21CgMfn1SdctZH57GqFXieOCBdNfNhFK8RMvrRdT5nQRyLNe3a k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgA0gwtX/5FdJa1dgzdTbg8GulQBD?= =?us-ascii?q?YFyFwqFIkoCHIEMOBQBAQEBAQEBZSeEQQEBAQMBAQEBCxUEDTEJCwUHBAIBBgI?= =?us-ascii?q?RBAEBAQICIwMCAgIlCxQBCAgCBA4FiB8IDo5jnReRXQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAREEfIUlgXWCVoQ9gwIrgisBBIlaiT+EawGOC48NjyUBHgEBQoNnbIk?= =?us-ascii?q?tfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="92211980" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2016 11:01:58 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3BB1wDX027450 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 11:01:58 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 06:01:57 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 06:01:57 -0500 From: "Carl Moberg (camoberg)" To: "Alexander Clemm (alex)" Thread-Topic: [netmod] YANG model classification? Thread-Index: AdGQL3gKyy1tY+elQcGBPw1mF94+NQAMv+oAAACSoQAAAi2aAAACHVyAAAA/eoAABkQdAAAPpD0AAAGkXYAAABFJgAAQS7qAACnPDwAAAQO6gAAAS9kAAACjK4AABtZwAAADKD4AAId40IA= Date: Mon, 11 Apr 2016 11:01:57 +0000 Message-ID: <46EAF52E-B58B-498D-AE62-2A289A414A3B@cisco.com> References: <655C07320163294895BBADA28372AF5D4877E71B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <153ed0e7120.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <81AB04FD-E653-4C85-B8E3-67C60A6707EF@cisco.com> <78D2F3D9-B922-49E0-BB1E-1A4FD7E721FF@coriant.com> <655C07320163294895BBADA28372AF5D48780CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <8F04C08F-C006-4122-A70B-175CBF7E925E@cisco.com> <6E7F5A13-FB4A-4CCB-AA43-39F7718D38EF@cisco.com> <6210B927-9173-415C-A476-ADAF1051F145@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.74] 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] YANG model classification? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 11:02:03 -0000 DQo+IE9uIEFwciA4LCAyMDE2LCBhdCA4OjIyIFBNLCBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpIDxh bGV4QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiANCj4gdG8gZm9sbG93IHVw IG9uIHRoZSBlYXJsaWVyIHBvaW50cyBpbiB0aGUgZGlzY3Vzc2lvbjoNCj4gLSBIb3cgY2FuIHdl IHByb3ZpZGUgbW9yZSBjbGFyaWZpY2F0aW9uDQo+IC0gSG93IGNvdWxkIE0uMzAxMCBwcm92aWRl IHNvbWV0aGluZyB1c2VmdWwNCg0KIFdoYXQgSSB3YXMgZ29pbmcgYWZ0ZXIgd2FzIGlmIHlvdSBm aW5kIHdlIGRldmlhdGUgKG9yIGxhY2spIGNvbmNlcHRzIG9yIHVzZWZ1bCBmZWF0dXJlcyBmcm9t IE0uMzAxMCB0aGF0IHdvdWxkIG1ha2UgdGhlIGNsYXNzaWZpY2F0aW9uIG1vcmUgdXNlZnVsLiBI b3BpbmcgeW91IGNvdWxkIHJldmlldyB0aGUgZHJhZnQgd2l0aCBNLjMwMTAgZ29nZ2xlcyBvbiBh bmQgc2VlIGlmIHdl4oCZcmUgbWlzc2luZyBzb21ldGhpbmcgdXNlZnVsIQ0KDQo+IEZXSVcsIGEg bGluZSBvZiBhcmd1bWVudCB0byByZWZsZWN0IGluIHRoZSBkcmFmdCBtaWdodCBnbyBhcyBmb2xs b3dzOiANCj4gDQo+IEdpdmVuIHRoYXQgdGhlIGhpc3RvcnkgaW4gSUVURiBoYXMgYmVlbiB0byBu b3QgbG9vayBhdCB0aGluZ3MgYmV5b25kIHRoZSBkZXZpY2UgYm91bmRhcnksIHBlcmhhcHMgaXQg d291bGQgYmUgdXNlZnVsIHRvIHN0YXRlIHNvbWV3aGVyZSB0aGF0IHRoaXMgcmVzdHJpY3Rpb24g bm8gbG9uZ2VyIGhvbGRzIGFuZCBuZWVkcyB0byBiZSByZWxheGVkIC0gZ2l2ZW4gdGhhdCBkZXZp Y2VzIGNhbiBiZSB2aXJ0dWFsaXplZCwgY29udHJvbGxlcnMgbWF5IHJlc2lkZSBvbiBkZXZpY2Vz LCB0aGF0IGFwcGxpY2F0aW9ucyBtYXkgYmVjb21lIG1vcmUgbmV0d29yay1hd2FyZSBhbmQgbmV0 d29ya3MgbW9yZSBzZXJ2aWNlIC8gYXBwbGljYXRpb24gYXdhcmUsIGV0Yy4gIFNvLCB0aGUgYm91 bmRhcmllcyBhcmUgZ2V0dGluZyBtb3JlIGJsdXJyeS4gIA0KDQogVGhpcyB0byBtZSBzZWVtcyB0 byBiZSBhIGdlbmVyYWxseSB1c2VmdWwgcmVmbGVjdGlvbiwgYnV0IEkgYmVsaWV2ZSBpdCB0byBi ZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZHJhZnQuDQoNCj4gQXQgdGhlIHNhbWUgdGltZSwgYSBm b3VuZGF0aW9uYWwgY29uY2VwdCBpcyBzdGlsbCB0aGUgbmVlZCBmb3IgZnVuY3Rpb24gaGllcmFy Y2hpZXMgKHJlZ2FyZGxlc3Mgb2YgZGV0YWlscyBvZiB3aGVyZSBhbmQgaG93IHRob3NlIGZ1bmN0 aW9ucyBhcmUgaW5zdGFudGlhdGVkKTogZWxlbWVudGFyeSBmdW5jdGlvbnMgLyBidWlsZGluZyBi bG9ja3MgKGZvcm1lcmx5IGVxdWl2YWxlbnQgdG8gZGV2aWNlcyksIGZ1bmN0aW9ucyB0aGF0IGRl YWwgd2l0aCB0aGUgY29ubmVjdGlvbiBvZiB0aG9zZSBmdW5jdGlvbnMgLyBidWlsZGluZyBibG9j a3MgKGZvcm1lcmx5IGVxdWl2YWxlbnQgdG8gIm5ldHdvcmsgbWFuYWdlbWVudCIgaW4gdGhlIG5h cnJvd2VyIHNlbnNlKSwgdGhlbiBmdW5jdGlvbnMgdGhhdCBidWlsZCBoaWdoZXItbGV2ZWwgc2Vy dmljZXMgb24gdG9wIG9mIGNvbm5lY3Rpdml0eSBhbHJlYWR5IGJlaW5nIHByb3ZpZGVkLiAgRnVu Y3Rpb24gaGllcmFyY2hpZXMgaW1wbHkgaW5mb3JtYXRpb24gLyBkYXRhIGhpZXJhY2hpZXMuICBU aGVyZSBpcyBubyByZWFzb24gd2h5IFlBTkcgY291bGQgbm90IGJlIHVzZWQgdG8gZGVmaW5lIG1v ZGVscyBhdCBkaWZmZXJlbnQgbGV2ZWxzIG9mIHRoYXQgaGllcmFyY2h5LCB3aGljaCBwcm92aWRl cyB2YXJpb3VzIGFkdmFudGFnZXMgc3VjaCBhcyBjb25zaXN0ZW5jeSBhY3Jvc3MgdGhlICJtb2Rl bCBzdGFjayIgYXMgd2VsbCBhcyB0aGUgYWJpbGl0eSB0byBtYWtlIGFzcGVjdHMgb2YgbW9kZWxz IGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgYWJzdHJhY3Rpb24gYWNjZXNzaWJsZSB0byBvdGhlciBt b2RlbHMgYW5kIGJlIHVzZWQgdG9nZXRoZXIgd2hlcmUgbGF5ZXJpbmcgaXMgbm90ICJzdHJpY3Qi IChpbiB0aGUgc2Vuc2UgdGhhdCB1cHBlciBsYXllcnMgbWF5IGJ1aWxkIG9uIHRvcCBvZiBtb2Rl bHMgZnJvbSBtdWx0aXBsZSBsb3dlciBsYXllcnMsIG5vdCBqdXN0IHRoZSBsYXllciBpbW1lZGlh dGVseSBiZWxvdyBpdCwgc28gdGhhdCBsb3dlciBsYXllcnMgYXJlIG5vdCBjb21wbGV0ZWx5IGhp ZGRlbikuICBTbywgWUFORyBtb2RlbHMgYXBwbHkgdG8gZGlmZmVyZW50IGxheWVycywgYW5kIHRo ZXJlIGFyZSBhZHZhbnRhZ2VzIGluIGRvaW5nIHNvLiANCg0KIEnigJl2ZSB0cmllZCB0byBjb3Zl ciB0aGlzIHRvcGljIChvciBhdCBsZWFzdCBvbmUgaW5zdGFuY2Ugb2YgaXQpIGluIHNlY3Rpb24g Mi4gSeKAmWxsIHJlLXJldmlldyB3aXRoIHRoZSBhYm92ZSBpbiBtaW5kLg0KDQo+IFRoZSBjb25j ZXB0IG9mIG1vZGVsIGhpZXJhcmNoaWVzIGlzIG5vdCBuZXcuICBPbmUgZXhhbXBsZSBvZiBhIGhp ZXJhcmNoaWNhbCBjbGFzc2lmaWNhdGlvbiB0aGF0IGhhcyBwcm92ZWQgdmVyeSB1c2VmdWwgb3Zl ciB0aGUgeWVhcnMgaXMgdGhlIGhpZXJhcmNoeSBzcGVsbGVkIG91dCBpbiBNLjMwMTAuICBTbywg d2UgYXJlIG5vdCBwcm9wb3NpbmcgYW55dGhpbmcgInJhZGljYWwiIGhlcmU7IHRoZXJlIGlzIHBy ZWNlZGVuY2UuICBBcyBNLjMwMTAgbGF5ZXJpbmcgY29uY2VwdHMgYXJlIGluIGVzc2VuY2UgYXBw bGljYWJsZSBhbHNvIGhlcmUsIHlldCB0aGUgbmVlZCBmb3IgZGF0YSBtb2RlbCBoaWVyYXJjaGll cyBoYXMgbm90IGJlZW4gc3BlbGxlZCBvdXQgYmVmb3JlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBZ QU5HL05ldGNvbmYgZnJhbWV3b3JrLCB0aGlzIGlzIGFuIGF0dGVtcHQgdG8gZmlsbCB0aGF0IGdh cC4gICANCg0KIEV4YWN0bHkhDQoNCj4gT25lIHJlYXNvbiB3aHkgY2xhc3NpZmljYXRpb24gaXMg dXNlZnVsIGluIHRoYXQgc2Vuc2UgaXMgdG8ga25vdyB3aGljaCB0eXBlcyBvZiBtb2RlbHMgbWln aHQgaGF2ZSBkZXBlbmRlbmNpZXMgb24gZWFjaCBvdGhlciwgYW5kIHdoYXQgb3RoZXIgbW9kZWxz IGEgbW9kZWwgbWlnaHQgYnVpbGQgb24gd2hlbiBpbnN0YW50aWF0ZWQuICBVcHBlci1sYXllciBt b2RlbHMgbWF5IGhhdmUgZGVwZW5kZW5jaWVzIG9uIGxvd2VyLWxheWVyIG1vZGVscywgYW5kIGlu IG1hbnkgY2FzZXMgYWdncmVnYXRlL2Fic3RyYWN0IG11bHRpcGxlIGNvbXBvbmVudHMgZnJvbSB0 aG9zZSBsb3dlciBsYXllciBtb2RlbHMsIGJ1dCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuICBU aGlzIG1lYW5zIHRoYXQsIHVwcGVyLWxheWVyIG1vZGVscyBtYXkgYmUgaW5zdGFudGlhdGVkIGlu IGRpZmZlcmVudCB3YXlzIHRoYW4gbG93ZXItbGF5ZXIgbW9kZWxzIGluIGFzIGZhciBhcyB0aGV5 IGJ1aWxkIG9uIHRvcCBvZiBvdGhlciBmdW5jdGlvbnMvbW9kZWxzIG9mIHRoZSBzYW1lIGZyYW1l d29yayAoaW5zdGVhZCBvZiBmdW5jdGlvbnMgb3V0c2lkZSB0aGF0IGZyYW1ld29yaykuICBUaGlz IGRpc3RpbmN0aW9uIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB3aHkgaGF2aW5nIGEgY2xlYXIgY2xh c3NpZmljYXRpb24gaXMgc29tZXRoaW5nIHRoYXQgbWF5IGJlIHVzZWZ1bC4gIA0KPiANCj4gQW55 d2F5LCBJTUhPLCB3aGF0IGlzIGN1cnJlbnRseSBub3Qgc3VmZmljaWVudGx5IGNsZWFyIGZyb20g dGhlIGRyYWZ0IGlzIHRoYXQgY2xhc3NpZmljYXRpb24gZG9lcyBub3Qgb2NjdXIganVzdCBmb3Ig Y2xhc3NpZmljYXRpb24ncyBzYWtlLCBhbmQgdGhpcyBpcyBhbiBhdHRlbXB0IGF0IGFydGljdWxh dGluZyBhIGNhc2UgZm9yIGl0LiAgDQoNCiBJ4oCZbSB0cnlpbmcgdG8gc3RyaWtlIGEgYmFsYW5j ZSBiZXR3ZWVuIHByb3ZpZGluZyBhcmd1bWVudHMgZm9yIHdoeSBhYnN0cmFjdGlvbnMgYXJlIHVz ZWZ1bCAod2hpY2ggaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgZHJhZnQgaW1obykgYW5kIGhvdyB0 byBjbGFzc2lmeSBZQU5HIG1vZHVsZXMuIEFsbW9zdCB0byB0aGUgY29udHJhcnksIHRoZSBkcmFm dCBtZW50aW9ucyB0aGF0IHRoZXJlIGFyZSBjdXJyZW50bHkgbm8gc3BlY2lmaWMgcmVxdWlyZW1l bnRzIG9uLCBvciB3ZWxsLWRlZmluZWQgYmVzdCBwcmFjdGljZXMgYXJvdW5kIHRoZSBkZXZlbG9w bWVudCBvZiBtb2R1bGVzIGluc2lkZSB0aGUgYm91bmRhcmllcyBvZiB0aGlzIGNsYXNzaWZpY2F0 aW9uLiBBcyB0aGUgcGVvcGxlIGFuZCB0ZWNobm9sb2dpZXMgYXJvdW5kIFlBTkcgbWF0dXJlcywg SSBiZWxpZXZlIHdlIHdpbGwgc2VlIG1vcmUgZ3JhbnVsYXIgcGF0dGVybnMgb2YgdXNlIHRoYXQg d2UgbWF5IHdhbnQgdG8gY2FwdHVyZSBpbiBmdXR1cmUgZHJhZnRzLg0KDQo+IENoZWVycw0KPiAt LS0gQWxleCANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBD YXJsIE1vYmVyZyAoY2Ftb2JlcmcpIA0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDA4LCAyMDE2IDk6 NTMgQU0NCj4gVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KPiBDYzogQWxl eGFuZGVyIENsZW1tIChhbGV4KSA8YWxleEBjaXNjby5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY2xhc3NpZmljYXRpb24/DQo+IA0KPiAN Cj4+IE9uIEFwciA4LCAyMDE2LCBhdCAzOjM2IFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4gd3JvdGU6DQo+PiANCj4+IA0KPj4gDQo+PiBPbiBGcmksIEFwciA4LCAyMDE2IGF0 IDY6MTggQU0sIENhcmwgTW9iZXJnIChjYW1vYmVyZykgPGNhbW9iZXJnQGNpc2NvLmNvbT4gd3Jv dGU6DQo+PiANCj4+PiBPbiBBcHIgOCwgMjAxNiwgYXQgMzoxMCBQTSwgQW5keSBCaWVybWFuIDxh bmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+IA0KPj4+ IEl0IGlzIG5vdCB0aGF0IGNsZWFyIGhvdyB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIG1vZHVsZXMg b3IgbGF5ZXJzIA0KPj4+IGltcGFjdCB0aGUgdGFzayBvZiBkZXNpZ25pbmcgYSBZQU5HIG1vZHVs ZS4gIEl0IHNlZW1zIGxpa2UgdmVuZG9yIA0KPj4+IHZzLiBzdGFuZGFyZCBvciBkZXZpY2UgdnMu IHNlcnZpY2UgYXJlIHNvbWV3aGF0IGFyYml0cmFyeSwgDQo+Pj4gZXNwZWNpYWxseSBpZiB2aXJ0 dWFsaXphdGlvbiBpcyBjb25zaWRlcmVkLg0KPj4gDQo+PiANCj4+IFRoZSBpbnRlbnQgb2YgdGhl IGNsYXNzaWZpY2F0aW9uIGlzIChpbWhvKSBub3QgaW50ZW5kZWQgdG8gaGF2ZSBtdWNoIGltcGFj dCBvbiBob3cgdG8gZGVzaWduIGEgbW9kdWxlLiBSYXRoZXIgdG8gcHJvdmlkZSBhIHRheG9ub215 IHRvIGNsYXNzaWZ5IG1vZGVscyB3aGVuIHRoZXkgYXJlIGRvbmUgKG9yIGJlaW5nIGRldmVsb3Bl ZCkuDQo+PiANCj4+IEkgZG9u4oCZdCBzZWUgaG93IHZpcnR1YWxpemF0aW9uIHdvdWxkIGhhdmUg YW4gaW1wYWN0LCBhbnkgc3VnZ2VzdGlvbnM/DQo+PiANCj4+IE5vIHN1Z2dlc3Rpb25zIG90aGVy IHRoYW4gdGhlIGhpZXJhcmNoeSBvZiBjb250cm9sbGVyIHRvIGRldmljZSBpcyBub3QgYWx3YXlz IHN0YXRpYy4NCj4+IEFtIEkgYWxsb3dlZCB0byBidWlsZCBhIHNlcnZpY2UgbGF5ZXIgb24gdG9w IG9mIGFub3RoZXIgc2VydmljZSBsYXllcj8NCj4+IChlLmcsICBOTVMgLS0+IEVNUyAtLT4gTkUp LiAgQW0gSSBhbGxvd2VkIHRvIHRyZWF0IGFuIGVudGlyZSBkYXRhIA0KPj4gY2VudGVyIGFzIGEg ZGV2aWNlIGluIGEgaGlnaCBsZXZlbCBhcHBsaWNhdGlvbj8NCj4+IA0KPiANCj4gVGhlIGRyYWZ0 IGlzIGRlZmluaXRlbHkgbm90IHN1cHBvc2VkIHRvIHRlbGwgeW91IHdoYXQgeW91IGFyZSBhbGxv d2VkIHRvIGRvLCBidXQgaXQgZG9lcyBhc3BpcmUgdG8gYSB1c2VmdWwgY2xhc3NpZmljYXRpb24g b2Ygd2hhdCBwZW9wbGUgYXJlIGRvaW5nIDotKQ0KPiANCj4gU28sIHRvIHlvdXIgcXVlc3Rpb25z Og0KPiANCj4gMS4g4oCcLi4uYSBzZXJ2aWNlIGxheWVyIG9uIHRvcCBvZiBhbm90aGVyIHNlcnZp Y2UgbGF5ZXI/Ig0KPiANCj4gRnJvbSBzZWN0aW9uIDIuMToNCj4gDQo+IOKAnOKAneKAneKAnQ0K PiBUaGUgY29tcG9uZW50LWJhc2VkIGFwcHJvYWNoIGNhcHR1cmVzIGRldmljZS1jZW50cmljIGZl YXR1cmVzIChlLmcuDQo+IHRoZSBkZWZpbml0aW9uIG9mIGEgVlJGLCByb3V0aW5nIHByb3RvY29s cywgb3IgcGFja2V0IGZpbHRlcmluZykgaW4gYSB2ZW5kb3ItaW5kZXBlbmRlbnQgbWFubmVyLiAg VGhlIGNvbXBvbmVudHMgYXJlIGRlc2lnbmVkIGZvciByZXVzZSBhY3Jvc3MgbWFueSBzZXJ2aWNl cy4gIFRoZSBzZXQgb2YgY29tcG9uZW50cyByZXF1aXJlZCBmb3IgYSBzcGVjaWZpYyBzZXJ2aWNl IGlzIHRoZW4gY29tcG9zZWQgaW50byB0aGUgaGlnaGVyLWxldmVsIHNlcnZpY2UuICBUaGUgY29t cG9uZW50LWJhc2VkIGFwcHJvYWNoIGhhcyB0aGUgYWR2YW50YWdlcyBvZiBtb2R1bGFyIGRldmVs b3BtZW50IGluY2x1ZGluZyBhIGhpZ2hlciBkZWdyZWUgb2YgcmV1c2FiaWxpdHkgYXQgdGhlIGV4 cGVuc2Ugb2YgaW5pdGlhbCBzcGVlZC4NCj4g4oCc4oCd4oCdDQo+IA0KPiANCj4gMi4g4oCcLi4u dG8gdHJlYXQgYW4gZW50aXJlIGRhdGEgY2VudGVyIGFzIGEgZGV2aWNlIGluIGEgaGlnaCBsZXZl bCBhcHBsaWNhdGlvbj8iDQo+IA0KPiDigJzigJ3igJ0NCj4gTmV0d29yayBFbGVtZW50IFlBTkcg RGF0YSBNb2RlbHMgZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGEgYW5kIG9w ZXJhdGlvbnMgb2YgYSBuZXR3b3JrIGRldmljZSBhcyBkZWZpbmVkIGJ5IHRoZSB2ZW5kb3Igb2Yg dGhhdCBkZXZpY2UuICBUaGUgbW9kZWxzIGFyZSBjb21tb25seSBzdHJ1Y3R1cmVkIGFyb3VuZCBm ZWF0dXJlcyBvZiB0aGUgZGV2aWNlLi4uDQo+IOKAnOKAnSINCj4gDQo+Pj4gVGhlIHRlcm1pbm9s b2d5IHdvdWxkIGJlIG1vcmUgcmVsZXZhbnQgaWYgdGhlIGRpZmZlcmVuY2VzIGluIGNvbnRlbnQg DQo+Pj4gb2YgZWFjaCB0eXBlIG9mIG1vZHVsZSB3ZXJlIGNsZWFyLg0KPj4gDQo+PiBUaGUgZmly c3QgcGFyYWdyYXBocyBvZiB0aGUgbWFpbiBzZWN0aW9ucyAoMi4xLCAyLjIsIDMuMS0zLjMpIGFy ZSBtZWFudCghKSB0byBleHBsYWluIHRoaXMuIENvdWxkIHlvdSBleHBhbmQgb24gd2hhdCB5b3Ug dGhpbmsgaXMgbWlzc2luZz8NCj4+IA0KPj4gTm8gLS0gdGhpcyBpcyBhbiBJbmZvcm1hdGlvbmFs IGRyYWZ0Lg0KPj4gVGhlIGNvbnRlbnQgZG9lcyBub3QgaGF2ZSB0byBiZSBhY3Rpb25hYmxlLiAg SXQgb25seSBoYXMgdG8gYmUgDQo+PiBpbmZvcm1hdGl2ZS4NCj4+IA0KPj4gRm9yIGRlY2FkZXMg U05NUCBjb21wbGV0ZWx5IGlnbm9yZWQgYW55dGhpbmcgYWJvdmUgdGhlIE5FIGFzIG91dCBvZiBz Y29wZS4NCj4+IFdlIGFyZSBtYWtpbmcgc29tZSBwcm9ncmVzcyBqdXN0IGJ5IGNvbnNpZGVyaW5n IHRoZSBwb3NzaWJpbGl0eSBvZiANCj4+IHN0YW5kYXJkIGZ1bmN0aW9uYWxpdHkgYXQgdGhlIGNv bnRyb2xsZXIgbGF5ZXIuDQo+PiANCj4+IA0KPj4+IEFuZHkNCj4+IA0KPj4+IA0KPj4+IA0KPj4+ IE9uIEZyaSwgQXByIDgsIDIwMTYgYXQgNTo0MCBBTSwgQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSA8 Y2Ftb2JlcmdAY2lzY28uY29tPiB3cm90ZToNCj4+PiANCj4+Pj4gT24gQXByIDcsIDIwMTYsIGF0 IDY6NDMgUE0sIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgPGFsZXhAY2lzY28uY29tPiB3cm90ZToN Cj4+Pj4gDQo+Pj4+IEkgYW0gd29uZGVyaW5nIHdoYXQgcHVycG9zZSB0aGUgY2xhc3NpZmljYXRp b24gcmVhbGx5IHNlcnZlcy4gIEF0IHRoZSBlbmQgb2YgdGhlIGRheSwgaXQgc2VlbXMgdG8gbWUg dGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGV4cHJlc3MgYSBtb2RlbCBoaWVyYXJjaHksIGFuZCBhcnRp Y3VsYXRlIHdoYXQgdGhlIGxheWVycyBpbiB0aGUgaGllcmFyY2h5IGFyZS4gIEEgZGV2aWNlIG1v ZGVsIGlzIHRodXMgYXQgYSBsb3dlciBsYXllciB0aGFuIGEgc2VydmljZSBtb2RlbC4gIEFuIGlt cGxlbWVudGF0aW9uIG9mIHRoZSBzZXJ2aWNlIG1vZGVsIG1heSBpbiB0dXJuIGhhdmUgZGVwZW5k ZW5jaWVzIG9uIHRoZSBkZXZpY2UgbW9kZWwsIGJ1dCBub3QgdGhlIG90aGVyIHdheSByb3VuZC4N Cj4+PiANCj4+PiBUaGUgYWJzdHJhY3QgdHJpZXMgdG8gZXhwcmVzcyB0aGUgcHVycG9zZToNCj4+ PiANCj4+PiDigJzigJ3igJ0NCj4+PiBBIGNvbnNpc3RlbnQgdGVybWlub2xvZ3kgd291bGQgaGVs cCB3aXRoIHRoZSBjYXRlZ29yaXphdGlvbiBvZiANCj4+PiBtb2RlbHMsIGFzc2lzdCBpbiB0aGUg YW5hbHlzaXMgdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBlZmZvcnRzIGluIHRoZSANCj4+PiBJRVRG IGFuZCBvdGhlciBvcmdhbml6YXRpb25zLCBhbmQgYnJpbmcgY2xhcml0eSB0byB0aGUgWUFORy1y ZWxhdGVkIA0KPj4+IGRpc2N1c3Npb25zIGJldHdlZW4gdGhlIGRpZmZlcmVudCBncm91cHMuDQo+ Pj4g4oCc4oCdIg0KPj4+IA0KPj4+IEFuZCBJ4oCZdmUgdGhlbiB0cmllZCB0byBleHBhbmQgYSBs aXR0bGUgZnVydGhlciBpbiBzZWN0aW9uIDEuDQo+Pj4gDQo+Pj4gSGFwcHkgdG8gdGFrZSBmZWVk YmFjayBvbiBpdCENCj4+PiANCj4+Pj4gV2hlcmUgdGhlIG1vZGVscyBhcmUgaW5zdGFudGlhdGVk IC0gb24gYSBjb250cm9sbGVyLCBvbiBhICJkZXZpY2UiLCBldGMgLSBzZWVtcyB0byBiZSBzZWNv bmRhcnkgYW5kIGluY2lkZW50YWwuICBUaGUgYm91bmRhcmllcyBhcmUgYmx1cnJ5LCBhbnl3YXlz LiAgQSBjb250cm9sbGVyIGlzIGEgZGV2aWNlIHRvbzsgc29tZSBkZXZpY2VzIG1heSBjb250YWlu IHZpcnR1YWxpemVkIGNvbnRyb2xsZXJzLCBhbmQgc28gb24uDQo+Pj4gDQo+Pj4gVGhlIGFzc3Vt cHRpb24gaGVyZSBpcyB0aGF0IHRoZSBsb2NhdGlvbiBpcyBpbmRlZWQgdXNlZnVsIGFuZCBzdWdn ZXN0cyB0aGUgY2xhc3NpZmljYXRpb24gb2YgZGF0YSBtb2RlbHMgaW50byB0d28gZGlzdGluY3Qg YWJzdHJhY3Rpb24gbGF5ZXJzLiBUb3BvbG9neSBpcyB0aGUgYXJlYSB3aGVyZSBJIGhhZCBhIHNl bnNlIHRoYXQgdGhlIGRldmljZSBhbmQgc2VydmljZSBjbGFzc2lmaWNhdGlvbiBtYXkgYm90aCBh cHBseSB0byBhIHNpbmdsZSBtb2R1bGUuDQo+Pj4gDQo+Pj4+IE9uZSBtb2RlbCB0aGF0IGlzIHJl bGV2YW50IGluIHRoaXMgZGlzY3Vzc2lvbiBzZWVtcyB0byBiZSB0aGUgVE1OIG1vZGVsLCBhcyBk ZWZpbmVkIGluIElUVS1UIFJlY29tbWVuZGF0aW9uIE0uMzAxMC4gIFRoaXMgbW9kZWwgZGVmaW5l cyBhIHNldCBvZiBtYW5hZ2VtZW50IGxheWVycyAtIG5ldHdvcmsgZWxlbWVudCAoZGV2aWNlKSwg bmV0d29yaywgc2VydmljZSwgYnVzaW5lc3MgLSB3aXRoIHdlbGwgZGVmaW5lZCBmdW5jaW9uYWwg c2NvcGUgb2YgZWFjaCBsYXllci4gIFRoZSBsYXllcnMgLyBmdW5jdGlvbiBoaWVyYXJjaHkgYWxz byBpbXBseSBhbiBpbmZvcm1hdGlvbiAgYW5kIGRhdGEgbW9kZWwgaGllcmFyY2h5Lg0KPj4+IA0K Pj4+IFRoZSBjbGFzc2lmaWNhdGlvbiBpcyBmYWlybHkgd2VsbCBhbGlnbmVkIHdpdGggdGhlIGNv bmNlcHRzIGluIA0KPj4+IE0uMzAxMCwgY292ZXJpbmcgdGhlICJOZXR3b3JrIG1hbmFnZW1lbnTi gJ0gYW5kIOKAnEVsZW1lbnQgbWFuYWdlbWVudOKAnSANCj4+PiBsYXllcnMuIEF0IGxlYXN0IHRo YXTigJlzIHRoZSBpbnRlbnQgOi0pDQo+Pj4gDQo+Pj4+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8g c2VlIGlmIHRoZSBsYXllcmluZyBpbiBNLjMwMTAgY291bGQgaGVscCBndWlkZSBZQU5HIG1vZGVs IGNsYXNzaWZpY2F0aW9uLCBhbmQgcmVmZXJlbmNlIHRob3NlIGRlZmluaXRpb25zPw0KPj4+IA0K Pj4+IFdvdWxkIGJlIHZlcnkgaGFwcHkgdG8gaGVhciBpZiB5b3UgZmluZCB3ZSBkZXZpYXRlIChv ciBsYWNrKSBjb25jZXB0cyBvciB1c2VmdWwgZmVhdHVyZXMgZnJvbSBNLjMwMTAgdGhhdCB3b3Vs ZCBtYWtlIHRoZSBjbGFzc2lmaWNhdGlvbiBtb3JlIHVzZWZ1bC4NCj4+PiANCj4+Pj4gLS0tIEFs ZXgNCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IG5l dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybCAN Cj4+Pj4gTW9iZXJnIChjYW1vYmVyZykNCj4+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAy MDE2IDE6NTcgQU0NCj4+Pj4gVG86IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hh ZWwuc2NoYXJmQG5va2lhLmNvbT4NCj4+Pj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPj4+PiBTdWJq ZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2RlbCBjbGFzc2lmaWNhdGlvbj8NCj4+Pj4gDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gLS0NCj4+Pj4gQ2FybCBNb2JlcmcNCj4+Pj4gVGVjaG5vbG9neSBEaXJl Y3RvciwgQ1ZHDQo+Pj4+IGNhbW9iZXJnQGNpc2NvLmNvbQ0KPj4+PiANCj4+Pj4+IE9uIEFwciA3 LCAyMDE2LCBhdCAxMDo1NSBBTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFl bC5zY2hhcmZAbm9raWEuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IEkgY29tZSBhdCB0aGlz IGZyb20gdGhlIGNsYXNzaWZpY2F0aW9uIGFuZ2xlLCBzbyBteSBpbnRlcmVzdCBpcyANCj4+Pj4+ PiBpZiB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgWUFORyBtb2RlbCBjYW4gb25seSBiZSBjbGFzc2lm aWVkIGFzIGEgDQo+Pj4+Pj4gbmV0d29yayBzZXJ2aWNlIG1vZGVsIFhPUiBhIG5ldHdvcmsgZGV2 aWNlIG1vZGVsIGFjY29yZGluZyB0byANCj4+Pj4+PiB0aGUgZGVmaW5pdGlvbnMgaW4gZHJhZnQt aWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbiANCj4+Pj4+PiAoc2VjdGlvbnMg Mi4xIGFuZCAyLjIpLiBCYXNlZCBvbiB0aGlzIGRpc2N1c3Npb24gSSB0YWtlIGl0IHRoYXQgc29t ZSBtb2RlbHMgYXJlIGludGVuZGVkIHRvIGJlIGFibGUgdG8gc2VydmUgaW4gYm90aCByb2xlcy4g QW5kIHdlIHNob3VsZCBtYWtlIHN1cmUgdGhhdCBpdOKAmXMgc3VwcG9ydGVkIGluIG91ciBjYXRh bG9nIHN0cnVjdHVyZS4NCj4+Pj4+IA0KPj4+Pj4gUmVnYXJkaW5nIHRoZSBYT1IgYXNzdW1wdGlv biBmb3IgY2xhc3NpZmljYXRpb246DQo+Pj4+PiANCj4+Pj4+IFlvdSBtYXkgYWxzbyB3YW50IHRv IHRoaW5rIGFib3V0IFlBTkcgbW9kZWxzIHRoYXQgYXJlIE5FSVRIRVIgZGV2aWNlIE5PUiBzZXJ2 aWNlIG1vZGVscy4gRm9yIGluc3RhbmNlLCB3aGF0IGFib3V0IFJGQyA2OTkxPyBBbmQgSSB0aGlu ayBvdGhlciwgbW9yZSB0ZWNobmljYWwgbW9kZWxzIHByZXNlbnRlZCB0aGlzIHdlZWsgbWF5IGZh bGwgaW50byBhIHNpbWlsYXIgY2F0ZWdvcnkgKCJnZW5lcmljIj8pLg0KPj4+PiANCj4+Pj4gVmVy eSBnb29kIHBvaW50LCB0aGFua3MhIFRoYXQgd2lsbCBuZWVkIHNvbWUgYWRkaXRpb25hbCB0aGlu a2luZyBhbmQgd3JpdGluZy4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+PiBuZXRtb2RAaWV0 Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN Cj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+IA0KPj4gDQo+PiAN Cj4gDQoNCg== From nobody Mon Apr 11 08:37:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A1D12D5D0 for ; Mon, 11 Apr 2016 08:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMZ_3hNTAK0H for ; Mon, 11 Apr 2016 08:37:08 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id CA54512D5A0 for ; Mon, 11 Apr 2016 08:37:08 -0700 (PDT) Received: from tops.chopps.org (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5998661176; Mon, 11 Apr 2016 15:37:07 +0000 (UTC) References: <1458566013189.55874@pantheon.tech> <87lh4n4ol0.fsf@tops.chopps.org> <20160409.093234.138748394999396297.mbj@tail-f.com> User-agent: mu4e 0.9.16; emacs 24.5.1 From: To: Martin Bjorklund In-reply-to: <20160409.093234.138748394999396297.mbj@tail-f.com> Date: Mon, 11 Apr 2016 11:37:03 -0400 Message-ID: <87egacjgww.fsf@tops.chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:37:10 -0000 --=-=-= Content-Type: text/plain Martin Bjorklund writes: > wrote: >> Ladislav Lhotka writes: >> > I think we need to eliminate all kinds of recursive mount, so this >> > should not happen. >> >> While I think I need more help understanding the original problem (maybe >> more explicit example of where the conflict is?), I wanted to point out >> that when we (the RTG yang DT) originally came up with our desire for a >> schema-mount, the ability to mount things recursively was seen as a >> feature, and not something to be restricted or disallowed. For example >> consider a physical network device that creates a logical network >> element, which could then creates its own logical network element (i.e., >> a guest of the guest of the host in VM terms) > > The current schema-mount supports recursive mounts in the schema > (e.g., if ietf-logical-devices has a mountpoint, it might be that > ietf-logical-devices is mounted there). Maybe 'nested mounts' is a > better term. But with a solution like peer mount, you probably want > to stay out of recursive mounts (A mounts B which mounts A). Nested schema mounts seems like a good enough name. Before hearing of the peer/alias mounts I had thought a "symlink" would perhaps be useful, which I believe is basically what an alias mount is. To that end the way unix deals with infinite recursion (loops) is to return an error when it happens (either the loop is detected and an error is returned specific to that condition, or some maximum depth is violated I believe). Thanks, Chris. > I also do not understand the original question regarding identifier > conflicts. > > > /martin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXC8SfAAoJEC4dgw7XuDAlpvcP/2d5T9KnTeYuFYLj3d897pCW sz6fR6oehpgJoHCpKDZLGO86Jqbqzejgps2IiivWtkb4iwxSWnT0mCXVl7CDoaGH 1oXJ3p/mm4LoIPWZxtT1hIjFuR31MpUDTDqBW1ULZNonabaq2y9xa2r9/gpRuVUq pCXPkaZnGAfX2hOIztXCKyquvwfoC1a66AiacSjG9TPWMDa8+xSm791s70SrZD0w cJDtD323vn8zTpoWSiwfLbdXiOyb6olFSE30htEXWmiPjSiIBrQYaBYfniboVnDh ZjNzYo8TbYsobjvYKNJ7tFa05PXg4K0vXORB4+gcDaN7TUtBuGiqmO5f0w9H+pmV PaTmnjQGi40XCjnmQpEmF35ovFMVhguZMPxGw2NhdRaMX8dXL32t3IKmrBKzCZEz kNPDcCBKl/1+6Bgb4JOKiiuWggkvtNbmf6ngCK5jXc1oaVdnatqdIIBuWVDzKRub f2Ghj1FaFO5rBMaYN0pbV5IUmtugX8vpebUBOAVZ3rifsXDaAtjkZu2rkyYnfbch JdiDVok1nnTdG/WIKHXzxFHwC/6m6fwleCJX7XRfivmH221R4tx8T5EMnDFYi5sD sAn2XAudf6oX2Yb7lLay1yQSCjW/eOoG7OPWZr6neelV+DYK5IYTPaXkDFMd6Xiq B73FyWG3IkLqVQgkfl8x =dyJB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 11 17:22:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1AD12D734 for ; Mon, 11 Apr 2016 17:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCNP5H0d89OC for ; Mon, 11 Apr 2016 17:22:45 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3888A12D6E8 for ; Mon, 11 Apr 2016 17:22:45 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id e190so3115608lfe.0 for ; Mon, 11 Apr 2016 17:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=XjI5Q8GFAyYZroavulRVhREG8zfEOJ89qRl+k5p0cd8=; b=amjsqtESl1/7L+IXXdvU0ONus2uvLnmT2ZWOf9L3hElbXcWbZwy2Y+U4SGcHwfXzsW MFw3YdOLoaDsaR7svB5HvSdZRARD2bgqud1T29IxJLDvWHrUc4i5bDE/twyABW/V1Os2 HV5ilT4W/FjR5EtESjhpfi/tHycvcYSOgYOo9AcgPCxdim/DC5pat6QgqqxrgAyRP3cX XadyE+ROKT40nViv/fsmYGe5fWWikCm8V59BA14EkvnaPqn55jWZeaEbldKwcCkyzRKY iSCGGyKjudFEG62IEgK4gUZarXXUKEEwX5/IDcVS7KHuxgIyCAXHCj1UsyW3Se0R6HiZ zDnw== 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; bh=XjI5Q8GFAyYZroavulRVhREG8zfEOJ89qRl+k5p0cd8=; b=Hu4t//FbTxGZpUO9FjliS1Nlm18IWhWw6cl40IhJ+B8AutxccAhKCCb4bUUnJ6Hyqc vZ7DBDwXbyRVrYtrQh/0jvHD3nZW6KCTmUtcCAPY4FMEh38RBgiEZko7BnBryZhE/6of J2+H1wTdYn/yLkdqEdW1dIroQTrEwvLOjivuC3UiapCaY3Hnura29gRLe8wILNWAN2Jc NkUMKQOWW7TAdBGVJT/DOT3RnpCLvDp+Awha4j7yl6etZzcFGDscY8VCXdNd08H1Nxo0 kmY7OwA9RwOAx9fAu/KSV3sNkk+TD+p6POx18P0NkEXDBgNqMK2agzCWZGNVQffgUqsk 7+7g== X-Gm-Message-State: AOPr4FUacZL/wZ+OI1eirG2zxy3Al7owyhue2HJn2WFhPSwqleZ2sX8xcWg9LPxOVptzd4Lo8LOOkHrFL3j9Ew== MIME-Version: 1.0 X-Received: by 10.112.49.50 with SMTP id r18mr107109lbn.65.1460420563284; Mon, 11 Apr 2016 17:22:43 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Mon, 11 Apr 2016 17:22:43 -0700 (PDT) Date: Mon, 11 Apr 2016 17:22:43 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113605a4e5c0a405303ea877 Archived-At: Subject: [netmod] YANG 1.1 ABNF issue for decimal64 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 00:22:47 -0000 --001a113605a4e5c0a405303ea877 Content-Type: text/plain; charset=UTF-8 Hi, The following restriction is not reflected in the ABNF. Same issue in RFC 6020. 9.3.3 . Restrictions A decimal64 type can be restricted with the "range" statement (Section 9.2.4 ). Andy --001a113605a4e5c0a405303ea877 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The following restriction is not re= flected in the ABNF.
Same issue in RFC 6020.

= 
9.3.3.  Restrictions


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



Andy

--001a113605a4e5c0a405303ea877-- From nobody Tue Apr 12 00:09:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323BF12E675 for ; Tue, 12 Apr 2016 00:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9FKsBbDsn3D for ; Tue, 12 Apr 2016 00:09:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2EE12E674 for ; Tue, 12 Apr 2016 00:09:07 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 494A71AE0351; Tue, 12 Apr 2016 09:09:05 +0200 (CEST) Date: Tue, 12 Apr 2016 09:09:16 +0200 (CEST) Message-Id: <20160412.090916.830301801094848919.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] YANG 1.1 ABNF issue for decimal64 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 07:09:09 -0000 Andy Bierman wrote: > Hi, > > The following restriction is not reflected in the ABNF. > Same issue in RFC 6020. > > 9.3.3 . > Restrictions > > A decimal64 type can be restricted with the "range" statement > (Section 9.2.4 > ). In 6020: decimal64-specification = fraction-digits-stmt In 6020bis: decimal64-specification = ;; these stmts can appear in any order fraction-digits-stmt [range-stmt] So I think it is correct in 6020bis. /martin From nobody Wed Apr 13 10:30:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29212DBAF for ; Wed, 13 Apr 2016 10:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDauMXoimTQW for ; Wed, 13 Apr 2016 10:30:12 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 A49B412DB14 for ; Wed, 13 Apr 2016 10:30:11 -0700 (PDT) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3DHTcmC022567 for ; Wed, 13 Apr 2016 10:30:11 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 22714tkg0k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 13 Apr 2016 10:30:11 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 11:30:09 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 19:30:08 +0200 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Wed, 13 Apr 2016 19:30:08 +0200 From: William Ivory To: "netmod@ietf.org" Thread-Topic: Clarification request for NETCONF edit-config default-operation replace Thread-Index: AdGVqTFLv31RNMwqTpuKmbR4SdQ9UQ== Date: Wed, 13 Apr 2016 17:29:59 +0000 Deferred-Delivery: Wed, 13 Apr 2016 17:29:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.252.50.5] Content-Type: multipart/alternative; boundary="_000_d2e2984e4b5044ebace0c748ca6ad697EMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604130236 Archived-At: Subject: [netmod] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 17:30:13 -0000 --_000_d2e2984e4b5044ebace0c748ca6ad697EMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="us-ascii" Hi, I'd appreciate clarification of how the NETCONF edit-config command should work with default-operation set to 'replace'. For the most part, the edit-config section is clear that config will only be replaced if explicitly overwritten (ie if you provide replacement config for given nodes). However, the section on default-operation is less clear: The parameter is optional, but if provided, it has one of the following values: merge: The configuration data in the parameter is merged with the configuration at the corresponding level in the target datastore. This is the default behavior. replace: The configuration data in the parameter completely replaces the configuration in the target datastore. This is useful for loading previously saved configuration data. Specifically, while 'merge' states that merge happesn with 'configuration as the corresponding level', 'replace' states that is 'completely replaces' the configuration, suggesting that it will remove ALL existing configuration regardless of what is explicitly provided as the replacement. Is that correct, or is 'replace' meant to have equivalent semantics to 'merge' ie it will only replace configuration when an explicit replacement is provided. In other words, if the latter case is correct, all it does is remove the requirement to specify the operation in each element of new config. Thanks, William --_000_d2e2984e4b5044ebace0c748ca6ad697EMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I’d appreciate clarification of how the  NETCONF edit-confi= g command should work with default-operation set to ‘replace’.&= nbsp; For the most part, the edit-config section is clear that config will = only be replaced if explicitly overwritten (ie if you provide replacement config for given nodes).  However, the section on default-= operation is less clear:
 
         The <default-opera= tion> parameter is optional, but if provided,
         it has one of the fol= lowing values:
 
         merge:  The conf= iguration data in the <config> parameter is
            mer= ged with the configuration at the corresponding level in
            the= target datastore.  This is the default behavior.
 
         replace:  The co= nfiguration data in the <config> parameter
            com= pletely replaces the configuration in the target
            dat= astore.  This is useful for loading previously saved
            con= figuration data.
 
Specifically, while ‘merge’ states that merge happesn with= ‘configuration as the corresponding level’, ‘replaceR= 17; states that is ‘completely replaces’ the configuration, sug= gesting that it will remove ALL existing configuration regardless of what i= s explicitly provided as the replacement.  Is that correct, or is ‘replace= 217; meant to have equivalent semantics to ‘merge’ ie it will o= nly replace configuration when an explicit replacement is provided.  I= n other words, if the latter case is correct, all it does is remove the requirement to specify the operation in each element of new config.
 
Thanks,
 
William
 
 --_000_d2e2984e4b5044ebace0c748ca6ad697EMEAWPEXMB12corpbrocade_-- From nobody Wed Apr 13 14:31:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D48C12DB41 for ; Wed, 13 Apr 2016 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUvSxawUJfak for ; Wed, 13 Apr 2016 14:31:49 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E45412DAA1 for ; Wed, 13 Apr 2016 14:31:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 98B7E899; Wed, 13 Apr 2016 23:31:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6cvNsnARUaRO; Wed, 13 Apr 2016 23:31:32 +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, 13 Apr 2016 23:31:46 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFA4B20046; Wed, 13 Apr 2016 23:31:45 +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 CvIWW74-6rg4; Wed, 13 Apr 2016 23:31: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 9FB5C20047; Wed, 13 Apr 2016 23:31:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2ACFA3AA034B; Wed, 13 Apr 2016 23:31:36 +0200 (CEST) Date: Wed, 13 Apr 2016 23:31:36 +0200 From: Juergen Schoenwaelder To: William Ivory Message-ID: <20160413213136.GA91449@elstar.local> Mail-Followup-To: William Ivory , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 21:31:52 -0000 Try asking on the NETCONF WG mailing list. /js On Wed, Apr 13, 2016 at 05:29:59PM +0000, William Ivory wrote: > Hi, > > I'd appreciate clarification of how the NETCONF edit-config command should work with default-operation set to 'replace'. For the most part, the edit-config section is clear that config will only be replaced if explicitly overwritten (ie if you provide replacement config for given nodes). However, the section on default-operation is less clear: > > The parameter is optional, but if provided, > it has one of the following values: > > merge: The configuration data in the parameter is > merged with the configuration at the corresponding level in > the target datastore. This is the default behavior. > > replace: The configuration data in the parameter > completely replaces the configuration in the target > datastore. This is useful for loading previously saved > configuration data. > > Specifically, while 'merge' states that merge happesn with 'configuration as the corresponding level', 'replace' states that is 'completely replaces' the configuration, suggesting that it will remove ALL existing configuration regardless of what is explicitly provided as the replacement. Is that correct, or is 'replace' meant to have equivalent semantics to 'merge' ie it will only replace configuration when an explicit replacement is provided. In other words, if the latter case is correct, all it does is remove the requirement to specify the operation in each element of new config. > > Thanks, > > William > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 14 13:03:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D33D12E3CD for ; Thu, 14 Apr 2016 13:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeJbnJVLYzRa for ; Thu, 14 Apr 2016 13:03:24 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0661.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::661]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55F212E3CC for ; Thu, 14 Apr 2016 13:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pKuBFyv04tUKZXw6UQAK3ZQmOmQ8h6tUGjWoiugo69Y=; b=N2ipbJnNBwLHzqp1OPTX0wA+nQ329FhJYGm7Oag4FzfRPoaXzLO2jinPvhPgjnMEXq8EHj3FUgNis2fh8gtvDWw8uJFo7Gxl6joamGaTuyL1LWsxXV/CuoeJkWZe2tIx7Hv4v6rMYa0VcBP2wPPhQO9ZFBPNRl5128neXzz10Zg= Received: from DBXPR06MB623.eurprd06.prod.outlook.com (10.255.71.170) by DBXPR06MB624.eurprd06.prod.outlook.com (10.255.71.171) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 20:03:05 +0000 Received: from DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.211]) by DBXPR06MB623.eurprd06.prod.outlook.com ([169.254.1.211]) with mapi id 15.01.0453.030; Thu, 14 Apr 2016 20:03:05 +0000 From: Xufeng Liu To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] kw review of draft-liu-netmod-yang-schedule Thread-Index: AQJ0hqPMUcYXu2mLgmpGLwn3QPNMqZ5DxxCA Date: Thu, 14 Apr 2016 20:03:05 +0000 Message-ID: References: <8DC36161-54BC-435B-B8BA-AA72A153451F@juniper.net> In-Reply-To: <8DC36161-54BC-435B-B8BA-AA72A153451F@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; juniper.net; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 8ac596cb-3320-4b59-9281-08d3649fcacb x-microsoft-exchange-diagnostics: 1; DBXPR06MB624; 5:UsmX8VzndjX6LUNOJYPsSo6jfxocKgyVoWCpeFXGL3dknrK+WueM2I5iwnOkz0hBBCZsNMkP0GXjeytnLez7XSt8ZMBqxJo/Mpr0WhCbz2ADSXr6rNdAv/FUQ06clzzE9vCaDOkubaIHbCQ1LzqF7w==; 24:ZCIxY5Zjj8JBlc+WtLhC4NAnl0qTqO1e/Ubo3HVwxOwSxA3Csy/sia3NBZseycnkr/8b2gtUmB27tVde1txm3jS2dBepV2eTQU25NXA3QTg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR06MB624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040102)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041046)(6043046); SRVR:DBXPR06MB624; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB624; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(76104003)(51914003)(377454003)(50986999)(230783001)(76176999)(15975445007)(2906002)(164054004)(3660700001)(10400500002)(3280700002)(54356999)(19300405004)(76576001)(102836003)(3846002)(92566002)(106116001)(2900100001)(19580395003)(19580405001)(2950100001)(1220700001)(16236675004)(586003)(1096002)(790700001)(6116002)(74316001)(5002640100001)(19625215002)(9686002)(5004730100002)(19617315012)(5001770100001)(5008740100001)(2501003)(86362001)(189998001)(87936001)(107886002)(81166005)(122556002)(33656002)(66066001)(5003600100002)(11100500001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR06MB624; H:DBXPR06MB623.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR06MB623D1071080C7258FD22C1EB1970DBXPR06MB623eurprd_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 20:03:05.3508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB624 Archived-At: Subject: Re: [netmod] kw review of draft-liu-netmod-yang-schedule X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:03:27 -0000 --_000_DBXPR06MB623D1071080C7258FD22C1EB1970DBXPR06MB623eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KVGhhbmtzIGZvciB0aGUgdmFsdWFibGUgY29tbWVudHMuDQoNCkJlc3QsDQoN Ci0gWHVmZW5nDQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NClNlbnQ6IE1vbmRheSwgQXByaWwgNCwgMjAxNiAx MDo1NCBBTQ0KVG86IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogW25ldG1vZF0ga3cgcmV2aWV3 IG9mIGRyYWZ0LWxpdS1uZXRtb2QteWFuZy1zY2hlZHVsZQ0KDQoNCltBcyBhIGNvbnRyaWJ1dG9y XQ0KDQpXaGlsZSBpdCdzIGNsZWFyIHdoYXQgdGhpcyBkb2N1bWVudCBpcyB0cnlpbmcgdG8gYWNo aWV2ZSBhdCBhIGhpZ2ggbGV2ZWwsIGl0IGlzIHVuY2xlYXIgd2h5IHRoZSBzb2x1dGlvbiBpcyBu ZWVkZWQuICAgQSAibW90aXZhdGlvbiIgc2VjdGlvbiBleHBsYWluaW5nIHdoeSB0aGlzIHNob3Vs ZCBiZSBzdGFuZGFyZGl6ZWQgd291bGQgYmUgbmljZS4NCltYdWZlbmddIEFncmVlLg0KDQpXaGVu IHJlYWRpbmcgdGhpcyBkcmFmdCwgSSB3YXMgcmVtaW5kZWQgb2YgbXkgbG9uZyBleHBpcmVkIGRy YWZ0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rd2F0c2VuLWNvbmRpdGlvbmFs LWVuYWJsZW1lbnQtMDAuICBUaGF0IGRyYWZ0IHByb3ZpZGVkIGEgbW9yZSBnZW5lcmFsIHNvbHV0 aW9uLCBpbiB0aGF0IGl0IGVuYWJsZWQgc3ViLXRyZWVzIHRvIGJlIGVuYWJsZWQvZGlzYWJsZWQg Zm9yIGFueSByZWFzb24uICBJdCB3YXMgcHJpbWFyaWx5IGZvY3VzZWQgb24gc3VwcG9ydGluZyBj b21tZW50cywgYnV0IGl0IGRpZCBjYWxsIG91dCB0aGF0IGV4cHJlc3Npb25zIGNvdWxkIGluY2x1 ZGUgdGltZSwgdGhvdWdoIGl0IGRpZG4ndCBmbHVzaCBvdXQgdGhhdCB0aG91Z2h0IHRvIGFueSBl eHRlbnQuDQoNCk90aGVyIHRoYW4gZHJhZnQta3dhdHNlbi1jb25kaXRpb25hbC1lbmFibGVtZW50 IGJlaW5nIGEgbW9yZSBnZW5lcmljIHNvbHV0aW9uLCBhbm90aGVyIGRpZmZlcmVuY2UgaXMgdGhh dCB0aGlzIGRyYWZ0IGVuYWJsZXMgdGhlIG1vZHVsZS1kZXNpZ25lciB0byBzcGVjaWZ5IHdoZXJl IGluIHRoZSBkYXRhIG1vZGVsIHRoZSBncm91cGluZyBpcyB1c2VkLCB3aGVyZWFzIG15IG9sZCBk cmFmdCBsZXQgdGhlIGNsaWVudCBlbmFibGVkL2Rpc2FibGVkIG5vZGVzIGFueXdoZXJlIGluIHRo ZSBkYXRhIG1vZGVsLCBwb3RlbnRpYWxseSBwcm9kdWNpbmcgbm9uc2Vuc2ljYWwgcmVzdWx0cywg dGhvdWdoIHdlIGhhdmUgdG8gYXNzdW1lIHRoYXQgdGhlIHNlcnZlciB3b3VsZCBmYWlsIGFueSBp bnZhbGlkIHJlc3VsdHMuDQpbWHVmZW5nXSBBZ3JlZSB0aGF0IGl0IGlzIG1vcmUgZ2VuZXJpYyBz b2x1dGlvbiwgdGhvdWdoIHRoZSBpbnRlbnRpb24gYW5kIG1lY2hhbmlzbSBhcmUgYSBiaXQgZGlm ZmVyZW50LiBJIHRoaW5rIHRoYXQgdGhlIGRlc2NyaWJlZCB0ZWNobmlxdWUgaXMgc3RpbGwgdXNl ZnVsLCBhbmQgSeKAmWQgc3VwcG9ydCBpdCB0byBwcm9jZWVkLg0KDQpSZWdhcmRpbmcgdGhpcyBz b2x1dGlvbiwgSSBoYXZlIHNvbWUgc3BlY2lmaWMgcXVlc3Rpb25zOg0KDQoxKSB3aHkgaXMgdGhl ICJzY2hlZHVsZSIgbm9kZSBhIGxpc3Q/ICBIb3cgaXMgYSBsaXN0IHRvIGJlIHByb2Nlc3NlZD8g ICBBcmUgdGhlcmUgYW55IG92ZXJsYXBwaW5nIGlzc3Vlcz8NCltYdWZlbmddIFRoZSBsaXN0IGlz IHVzZWQgc28gdGhhdCBhIHNlcmllcyBvZiBzY2hlZHVsZXMgKHN1Y2ggYXMgZHVyYXRpb25zKSBj YW4gYmUgc3BlY2lmaWVkLiBJZiBzZXZlcmFsIGR1cmF0aW9ucyBhcmUgc3BlY2lmaWVkLCB0aGUg b2JqZWN0IGlzIGNvbmZpZ3VyZWQgaW4gYWxsIHRoZXNlIGR1cmF0aW9ucywgaW5jbHVzaXZlbHku IElmIHR3byBkdXJhdGlvbnMgYXJlIG92ZXJsYXBwZWQsIHRoZSB1bmlvbiBpcyB1c2VkLCBzbyB0 aGF0IHRoZSByZXN1bHQgaXMgb25lIGxvbmdlciBkdXJhdGlvbi4gRG8geW91IHNlZSBhbnkgcHJv YmxlbSBoZXJlPw0KDQoyKSBkb2VzIHRoZSAic2NoZWR1bGUtaWQiIGxlYWYgaGF2ZSBhbnkgdXNl ZnVsIHB1cnBvc2Ugb3RoZXIgdGhhbiBiZWluZyB0aGUgbGlzdCdzIGtleT8NCltYdWZlbmddIEl0 cyBvbmx5IHB1cnBvc2UgaXMgdG8gYmUgdGhlIGtleS4NCg0KMykgdGhlICJzY2hlZHVsZS1kdXJh dGlvbiIgbm9kZSdzIHBhdHRlcm4gbWF0Y2hlcyBYU0QncyAiZHVyYXRpb24iIHR5cGUsIGlzIGl0 IHRoZSBpbnRlbnQgdG8gcHJvY2VzcyBpdCBhcyBzdWNoPw0KW1h1ZmVuZ10gWWVzLg0KDQo0KSB0 aGUgZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbCBkcmFmdCBvcmlnaW5hbGx5IGhhZCBh IGR1cmF0aW9uLWxpa2UgdmFsdWUsIGJ1dCB0aGUgV0cgY29uc2Vuc3VzIHdhcyBhdCB0aGUgdGlt ZSB3YXMgdG8gaW5zdGVhZCB1c2UgYW4gdW5zaWduZWQgaW50ZWdlciB2YWx1ZSB3aXRoIGEgInVu aXRzIiB2YWx1ZSAoZS5nLiwgc2Vjb25kcywgbWludXRlcywgZXRjLikuICBUaGUgY2xhaW0gd2Fz IHRoYXQsIHdoZW4gbGFyZ2UgdmFsdWVzIHdoZXJlIG5lZWRlZCAoZS5nLiwgMzYwMC1zZWNvbmRz IGluc3RlYWQgb2YgMS1ob3VyKSwgdGhhdCB0aGUgY2xpZW50IGNvdWxkIGFsd2F5cyBkbyB0aGUg bWF0aC4gIEFueSB0aG91Z2h0cyBvbiB0aGF0Pw0KW1h1ZmVuZ10gVGhlIGludGVnZXIgdmFsdWUg aXMgc3VyZWx5IGFuIGFsdGVybmF0aXZlLCB0aG91Z2ggdGhlIGZpeGVkIOKAnHVuaXRz4oCdIG1p Z2h0IGJlIGxpbWl0aW5nLiBGb3IgZXhhbXBsZSwgd2h5IHNob3VsZCB3ZSBwaWNrIOKAnHNlY29u ZHPigJ0gaW5zdGVhZCBvZiDigJxtaW51dGVz4oCdPyBXaGF0IHNob3VsZCBiZSBwcm9wZXIgcmFu Z2Ugb2YgdGhlIGludGVnZXI/IEluIHRoaXMgY2FzZSwgSSB0aGluayBJU08gODYwMSBmb3JtYXQg aXMgbW9yZSBjb252ZW5pZW50IGFuZCBmbGV4aWJsZSB0aGFuIGFza2luZyB0aGUgY2xpZW50IHRv IGRvIHRoZSBtYXRoIGFsbCB0aGUgdGltZSAod2hpY2ggbWF5IG5vdCBiZSBhZGVxdWF0ZSkuIEFs c28sIHRoZSBkdXJhdGlvbiBpcyB1c2VkIGFsb25nIHdpdGggYSBkYXRhLXRpbWUgbGVhZiB3aGlj aCBpcyBhbHNvIGluIElTTyA4NjAxIGZvcm1hdCwgc28gdGhhdCB0aGUgc3R5bGUgYW5kIHByb2Nl c3NpbmcgYXJlIGNvbnNpc3RlbnQuDQoNCjUpIGFyZSB0aGVyZSBhbnkgaXNzdWVzIHdpdGggdGhl ICJyZXBlYXQtaW50ZXJ2YWwiIG5vZGU/ICBJJ20gc3BlY2lmaWNhbGx5IHRoaW5raW5nIGFib3V0 IHRoZSBpbnRlcnZhbCBiZWluZyBleHByZXNzZWQgaW4gdGVybXMgb2YgaG91cnMgYW5kIGRheXMg aW4gdGhlIGNvbnRleHQgb2YgZGF5bGlnaHQgc2F2aW5ncyBhbmQgbGVhcCB5ZWFyLi4uDQpbWHVm ZW5nXSBIZWFyZCBzb21lIGNyaXRpY2lzbXMgb24gdGhlIElPUyA4NjAxIGV4cHJlc3Npb25zLiBU aGVyZSBjb3VsZCBiZSBzb21lIGlzc3VlcywgYnV0IGFyZSB0aGV5IHNpZ25pZmljYW50IGVub3Vn aCB0byBzdG9wIHVzIGZyb20gdXNpbmcgaXQ/IFRoZSBiZWhhdmlvcnMgY291bGQgYmUgZGVmaW5l ZCBhbmQgY2xhcmlmaWVkLCBjb3VsZG7igJl0IHRoZXk/IFdoYXQgZG8geW91IHRoaW5rPw0KDQpO aXQ6IHNvbWUgZXhhbXBsZXMgaW4gdGhlIGRyYWZ0IHdvdWxkJ3ZlIGJlZW4gbmljZS4NCltYdWZl bmddIFN1cmUgd2Ugd2lsbCBkby4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0K --_000_DBXPR06MB623D1071080C7258FD22C1EB1970DBXPR06MB623eurprd_ 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 b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEtlbnQsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRo YW5rcyBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPi0gWHVmZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZW50IFdhdHNlbjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIEFwcmlsIDQsIDIwMTYgMTA6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+IG5ldG1vZEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbmV0bW9kXSBrdyByZXZpZXcgb2YgZHJhZnQtbGl1LW5l dG1vZC15YW5nLXNjaGVkdWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5bQXMgYSBjb250cmlidXRvcl08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ V2hpbGUgaXQncyBjbGVhciB3aGF0IHRoaXMgZG9jdW1lbnQgaXMgdHJ5aW5nIHRvIGFjaGlldmUg YXQgYSBoaWdoIGxldmVsLCBpdCBpcyB1bmNsZWFyIHdoeSB0aGUgc29sdXRpb24gaXMgbmVlZGVk LiAmbmJzcDsgQSAmcXVvdDttb3RpdmF0aW9uJnF1b3Q7IHNlY3Rpb24gZXhwbGFpbmluZyB3aHkg dGhpcw0KIHNob3VsZCBiZSBzdGFuZGFyZGl6ZWQgd291bGQgYmUgbmljZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltY dWZlbmddIEFncmVlLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PldoZW4gcmVhZGluZyB0aGlzIGRyYWZ0LCBJIHdhcyByZW1pbmRlZCBvZiBteSBsb25nIGV4cGly ZWQgZHJhZnQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rd2F0 c2VuLWNvbmRpdGlvbmFsLWVuYWJsZW1lbnQtMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1rd2F0c2VuLWNvbmRpdGlvbmFsLWVuYWJsZW1lbnQtMDA8L2E+LiAmbmJzcDtUaGF0 IGRyYWZ0IHByb3ZpZGVkIGEgbW9yZSBnZW5lcmFsIHNvbHV0aW9uLCBpbiB0aGF0IGl0IGVuYWJs ZWQgc3ViLXRyZWVzIHRvIGJlIGVuYWJsZWQvZGlzYWJsZWQgZm9yIGFueQ0KIHJlYXNvbi4gJm5i c3A7SXQgd2FzIHByaW1hcmlseSBmb2N1c2VkIG9uIHN1cHBvcnRpbmcgY29tbWVudHMsIGJ1dCBp dCBkaWQgY2FsbCBvdXQgdGhhdCBleHByZXNzaW9ucyBjb3VsZCBpbmNsdWRlIHRpbWUsIHRob3Vn aCBpdCBkaWRuJ3QgZmx1c2ggb3V0IHRoYXQgdGhvdWdodCB0byBhbnkgZXh0ZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PdGhlciB0aGFuIGRyYWZ0LWt3YXRz ZW4tY29uZGl0aW9uYWwtZW5hYmxlbWVudCBiZWluZyBhIG1vcmUgZ2VuZXJpYyBzb2x1dGlvbiwg YW5vdGhlciBkaWZmZXJlbmNlIGlzIHRoYXQgdGhpcyBkcmFmdCBlbmFibGVzIHRoZSBtb2R1bGUt ZGVzaWduZXIgdG8gc3BlY2lmeSB3aGVyZQ0KIGluIHRoZSBkYXRhIG1vZGVsIHRoZSBncm91cGlu ZyBpcyB1c2VkLCB3aGVyZWFzIG15IG9sZCBkcmFmdCBsZXQgdGhlIGNsaWVudCBlbmFibGVkL2Rp c2FibGVkIG5vZGVzIGFueXdoZXJlIGluIHRoZSBkYXRhIG1vZGVsLCBwb3RlbnRpYWxseSBwcm9k dWNpbmcgbm9uc2Vuc2ljYWwgcmVzdWx0cywgdGhvdWdoIHdlIGhhdmUgdG8gYXNzdW1lIHRoYXQg dGhlIHNlcnZlciB3b3VsZCBmYWlsIGFueSBpbnZhbGlkIHJlc3VsdHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5bWHVmZW5nXSBBZ3JlZSB0aGF0IGl0IGlzIG1vcmUgZ2VuZXJpYyBzb2x1dGlv biwgdGhvdWdoIHRoZSBpbnRlbnRpb24gYW5kIG1lY2hhbmlzbSBhcmUgYSBiaXQgZGlmZmVyZW50 LiBJIHRoaW5rIHRoYXQgdGhlIGRlc2NyaWJlZCB0ZWNobmlxdWUgaXMgc3RpbGwgdXNlZnVsLCBh bmQgSeKAmWQNCiBzdXBwb3J0IGl0IHRvIHByb2NlZWQuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+UmVnYXJkaW5nIHRoaXMgc29sdXRpb24sIEkgaGF2ZSBzb21lIHNwZWNpZmljIHF1ZXN0 aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+MSkgd2h5IGlzIHRoZSAmcXVvdDtzY2hlZHVsZSZxdW90OyBub2Rl IGEgbGlzdD8gJm5ic3A7SG93IGlzIGEgbGlzdCB0byBiZSBwcm9jZXNzZWQ/ICZuYnNwOyBBcmUg dGhlcmUgYW55IG92ZXJsYXBwaW5nIGlzc3Vlcz8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltYdWZlbmddIFRo ZSBsaXN0IGlzIHVzZWQgc28gdGhhdCBhIHNlcmllcyBvZiBzY2hlZHVsZXMgKHN1Y2ggYXMgZHVy YXRpb25zKSBjYW4gYmUgc3BlY2lmaWVkLiBJZiBzZXZlcmFsIGR1cmF0aW9ucyBhcmUgc3BlY2lm aWVkLCB0aGUgb2JqZWN0IGlzIGNvbmZpZ3VyZWQgaW4gYWxsIHRoZXNlDQogZHVyYXRpb25zLCBp bmNsdXNpdmVseS4gSWYgdHdvIGR1cmF0aW9ucyBhcmUgb3ZlcmxhcHBlZCwgdGhlIHVuaW9uIGlz IHVzZWQsIHNvIHRoYXQgdGhlIHJlc3VsdCBpcyBvbmUgbG9uZ2VyIGR1cmF0aW9uLiBEbyB5b3Ug c2VlIGFueSBwcm9ibGVtIGhlcmU/PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+MikgZG9lcyB0aGUgJnF1b3Q7c2NoZWR1bGUtaWQmcXVvdDsgbGVhZiBoYXZlIGFu eSB1c2VmdWwgcHVycG9zZSBvdGhlciB0aGFuIGJlaW5nIHRoZSBsaXN0J3Mga2V5PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+W1h1ZmVuZ10gSXRzIG9ubHkgcHVycG9zZSBpcyB0byBiZSB0aGUga2V5Ljwvc3Bhbj48L2k+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjMpIHRoZSAmcXVvdDtzY2hlZHVsZS1k dXJhdGlvbiZxdW90OyBub2RlJ3MgcGF0dGVybiBtYXRjaGVzIFhTRCdzICZxdW90O2R1cmF0aW9u JnF1b3Q7IHR5cGUsIGlzIGl0IHRoZSBpbnRlbnQgdG8gcHJvY2VzcyBpdCBhcyBzdWNoPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+W1h1ZmVuZ10gWWVzLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjQpIHRoZSBkcmFmdC1pZXRmLW5ldGNvbmYtc2VydmVyLW1vZGVsIGRyYWZ0IG9yaWdp bmFsbHkgaGFkIGEgZHVyYXRpb24tbGlrZSB2YWx1ZSwgYnV0IHRoZSBXRyBjb25zZW5zdXMgd2Fz IGF0IHRoZSB0aW1lIHdhcyB0byBpbnN0ZWFkIHVzZSBhbiB1bnNpZ25lZCBpbnRlZ2VyIHZhbHVl DQogd2l0aCBhICZxdW90O3VuaXRzJnF1b3Q7IHZhbHVlIChlLmcuLCBzZWNvbmRzLCBtaW51dGVz LCBldGMuKS4gJm5ic3A7VGhlIGNsYWltIHdhcyB0aGF0LCB3aGVuIGxhcmdlIHZhbHVlcyB3aGVy ZSBuZWVkZWQgKGUuZy4sIDM2MDAtc2Vjb25kcyBpbnN0ZWFkIG9mIDEtaG91ciksIHRoYXQgdGhl IGNsaWVudCBjb3VsZCBhbHdheXMgZG8gdGhlIG1hdGguICZuYnNwO0FueSB0aG91Z2h0cyBvbiB0 aGF0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+W1h1ZmVuZ10gVGhlIGludGVnZXIgdmFsdWUgaXMgc3VyZWx5IGFuIGFs dGVybmF0aXZlLCB0aG91Z2ggdGhlIGZpeGVkIOKAnHVuaXRz4oCdIG1pZ2h0IGJlIGxpbWl0aW5n LiBGb3IgZXhhbXBsZSwgd2h5IHNob3VsZCB3ZSBwaWNrIOKAnHNlY29uZHPigJ0gaW5zdGVhZCBv ZiDigJxtaW51dGVz4oCdPyBXaGF0DQogc2hvdWxkIGJlIHByb3BlciByYW5nZSBvZiB0aGUgaW50 ZWdlcj8gSW4gdGhpcyBjYXNlLCBJIHRoaW5rIElTTyA4NjAxIGZvcm1hdCBpcyBtb3JlIGNvbnZl bmllbnQgYW5kIGZsZXhpYmxlIHRoYW4gYXNraW5nIHRoZSBjbGllbnQgdG8gZG8gdGhlIG1hdGgg YWxsIHRoZSB0aW1lICh3aGljaCBtYXkgbm90IGJlIGFkZXF1YXRlKS4gQWxzbywgdGhlIGR1cmF0 aW9uIGlzIHVzZWQgYWxvbmcgd2l0aCBhIGRhdGEtdGltZSBsZWFmIHdoaWNoIGlzIGFsc28NCiBp biBJU08gODYwMSBmb3JtYXQsIHNvIHRoYXQgdGhlIHN0eWxlIGFuZCBwcm9jZXNzaW5nIGFyZSBj b25zaXN0ZW50Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjUp IGFyZSB0aGVyZSBhbnkgaXNzdWVzIHdpdGggdGhlICZxdW90O3JlcGVhdC1pbnRlcnZhbCZxdW90 OyBub2RlPyAmbmJzcDtJJ20gc3BlY2lmaWNhbGx5IHRoaW5raW5nIGFib3V0IHRoZSBpbnRlcnZh bCBiZWluZyBleHByZXNzZWQgaW4gdGVybXMgb2YgaG91cnMgYW5kIGRheXMgaW4gdGhlIGNvbnRl eHQNCiBvZiBkYXlsaWdodCBzYXZpbmdzIGFuZCBsZWFwIHllYXIuLi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltYdWZl bmddIEhlYXJkIHNvbWUgY3JpdGljaXNtcyBvbiB0aGUgSU9TIDg2MDEgZXhwcmVzc2lvbnMuIFRo ZXJlIGNvdWxkIGJlIHNvbWUgaXNzdWVzLCBidXQgYXJlIHRoZXkgc2lnbmlmaWNhbnQgZW5vdWdo IHRvIHN0b3AgdXMgZnJvbSB1c2luZyBpdD8gVGhlIGJlaGF2aW9ycyBjb3VsZA0KIGJlIGRlZmlu ZWQgYW5kIGNsYXJpZmllZCwgY291bGRu4oCZdCB0aGV5PyBXaGF0IGRvIHlvdSB0aGluaz88L3Nw YW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5OaXQ6IHNvbWUgZXhhbXBs ZXMgaW4gdGhlIGRyYWZ0IHdvdWxkJ3ZlIGJlZW4gbmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltYdWZlbmddIFN1 cmUgd2Ugd2lsbCBkby48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5LZW50PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBXPR06MB623D1071080C7258FD22C1EB1970DBXPR06MB623eurprd_-- From nobody Fri Apr 15 07:59:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BB412D62B for ; Fri, 15 Apr 2016 07:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrKXdAvbCJvh for ; Fri, 15 Apr 2016 07:59:33 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0061.outbound.protection.outlook.com [104.47.2.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6658E12D532 for ; Fri, 15 Apr 2016 07:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AbSvSCe0doMp2qmqZboNiGMUuP555Wf7N19b9jrro38=; b=KY/mOagkHCGH8F2z/mTguloWiq3RIBHBuV8tTzKI7qXI/tbSPPlYrRsv4pxxpu9f1MRkL1Ja1bxj8BOT1v/R0N1CAsybCRQntGqBQp35PHXE+4RZ/0tGG/zIMg5XhDRYHRhzSAEsoKSJTWKfbyn3SlY7INUfJeekrcBWdHk+i70= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0952.eurprd06.prod.outlook.com (10.162.158.142) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 15 Apr 2016 14:59:31 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0453.029; Fri, 15 Apr 2016 14:59:30 +0000 From: "Ing-Wher (Helen) Chen" To: "netmod@ietf.org" Thread-Topic: update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2A== Date: Fri, 15 Apr 2016 14:59:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 06aaae25-3a8b-4361-8c9e-08d3653e8c6d x-microsoft-exchange-diagnostics: 1; DB5PR06MB0952; 5:no7cFzafSZCMa+qXkNi/Ss1vZWyJ+3FjMZWTzF+wm3u4AOsVugiJT/8UXkL1cnV2leGeABMZBOolWbMzRFsgDO4jUptg998CcRQyGOusrstPxEMFVIzDUWUf4bprqenDoSk+iwmj1z3LJmHuj5yIrA==; 24:pO8hp5JtIdR9pOYpd3OOitCWvwqLKSz4PikwpVyuJrGTZBV5dCMZ8gJaGEtflx6TT7hhPTtuvZxb0Hsu0w7p2XtF1i5Xpk1fnPYmpLn5BWI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0952; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:DB5PR06MB0952; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0952; x-forefront-prvs: 0913EA1D60 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2906002)(9686002)(164054004)(2900100001)(15975445007)(3660700001)(5008740100001)(81166005)(3280700002)(1730700002)(1220700001)(5640700001)(122556002)(1096002)(6116002)(5004730100002)(54356999)(102836003)(66066001)(2501003)(77096005)(189998001)(450100001)(74316001)(19580395003)(87936001)(229853001)(2351001)(33656002)(107886002)(5003600100002)(19580405001)(15650500001)(110136002)(92566002)(3846002)(575784001)(5002640100001)(86362001)(10400500002)(586003)(50986999)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0952; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2016 14:59:30.4770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0952 Archived-At: Subject: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 14:59:36 -0000 Hello, At IETF94 in Yokohama, I presented an idea to allow enterprise YANG models to easily generate globally unique namespaces (https://datatracker.ietf.org/doc/draft-chen-netmod-enterprise-yang-namespa= ce/) . The topic was also discussed on the mailing list: https://mailarchive.ietf.org/arch/msg/netmod/JQmD8yrUeuAwuHpBnqZV_mcuveU https://mailarchive.ietf.org/arch/msg/netmod/GSz_1dp2R3FPlMmu2_HF3ZIwrsY https://mailarchive.ietf.org/arch/msg/netmod/tJDZPI9PV1-SjZm2c608OQu41ws https://mailarchive.ietf.org/arch/msg/netmod/RCYhzKvMd0BATTtxaE69nbvcj7g As promised, I started the process of registering the top-level "rdns" name= space. Following RFC 3406, I wrote https://datatracker.ietf.org/doc/draft-chen-rdn= s-urn/ and completed the review on urn-nid@ietf.org . For the review on urn-nid@i= etf.org , please see the following messages. The final message stating the review is complete is here: https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-eTA4ONNiwaJhUPmcs The review in its entirety is here: https://mailarchive.ietf.org/arch/msg/urn-nid/N3Md2evqFPE2o7figeGcyqT4BsY https://mailarchive.ietf.org/arch/msg/urn-nid/wEIRTDvf4vPJPW9ORw6lkK6St2A https://mailarchive.ietf.org/arch/msg/urn-nid/btXpEnmt7LHL4ZeCUvxYLQPUps4 https://mailarchive.ietf.org/arch/msg/urn-nid/52U72G2qzuqEwfSVIkD9YE-Pv3c https://mailarchive.ietf.org/arch/msg/urn-nid/_AHANMEp_uq9ZFI7bHzf7lVvpoM https://mailarchive.ietf.org/arch/msg/urn-nid/UgfKVlPS87x-1j2juHI8jLHdmAY https://mailarchive.ietf.org/arch/msg/urn-nid/fFjwJMup43-P4mGQ4GMnG5DsrdM https://mailarchive.ietf.org/arch/msg/urn-nid/sRpdhqpw-t4t0A15svbM_eywGj8 https://mailarchive.ietf.org/arch/msg/urn-nid/pibno5XNyXvAhuJ9bW6lKJjDA0w https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-eTA4ONNiwaJhUPmcs Thanks, Helen From nobody Fri Apr 15 08:09:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DB512D9A9 for ; Thu, 7 Apr 2016 08:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HEADER_SPAM=0.585, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=mbj4668=gmail.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weXL5P7YWHkg for ; Thu, 7 Apr 2016 08:11:52 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.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 07E5212D821 for ; Thu, 7 Apr 2016 07:58:30 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1460041110; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=N4BS1trSUCVIBv15rA6qfhxi5WbnVJWG/sKpf1jZ/kk=; b=cnonTZuVtkm8mEKAIkitwUDEjhnoH8Kt2KXvk9aAPO9KlDCyybQr1RjMArZ6yvveK1h8r6vu Vh1bwqxfw+RBxo/pyiVpMTdQ44DNaAU572T0JMApLsL/x6xmdKY7E4vYMZtypdKpjOj9kt+n DdeTCjHLv//l66QFHALPJLAzBqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=YYd75mUaQyA+ixyPjj7JJCo1kC+QCRlxkZF2+Wzq1zcBW/XJ/P/DqkNOhhMLkIGLfklJjL VSHoF4udWrZ91WN1ekqO6tKTEDOBAhWpkVtvHsshZr15EhGKhDWEd/kyRS1KixeXlyybMsW+ YWj82lKcev0dFNnjcd0FpQNuiNML0= Sender: mbj4668=gmail.com@github.com X-Mailgun-Sid: WyIxZDdlMiIsICJuZXRtb2RAaWV0Zi5vcmciLCAiNDBmIl0= Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 57067590.7ac9840-in06; Thu, 07 Apr 2016 14:58:24 -0000 (UTC) Date: Thu, 07 Apr 2016 07:58:24 -0700 From: Martin =?UTF-8?B?QmrDtnJrbHVuZA==?= To: netmod@ietf.org Message-ID: <57067590af2e4_23dd3fb82275b2b812681@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57067590aeb5d_23dd3fb82275b2b8126759"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 15 Apr 2016 08:09:00 -0700 Subject: [netmod] [netmod-wg/schema-mount] c0fc4d: use ipv6 instead of ipv4 in examples X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Martin =?UTF-8?B?QmrDtnJrbHVuZA==?= List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:12:01 -0000 ----==_mimepart_57067590aeb5d_23dd3fb82275b2b8126759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Branch: refs/heads/master Home: https://github.com/netmod-wg/schema-mount Commit: c0fc4d052e1e8d677a4f0d54d796a9c577ac27e7 https://github.com/netmod-wg/schema-mount/commit/c0fc4d052e1e8d677a= 4f0d54d796a9c577ac27e7 Author: Martin Bj=C3=B6rklund Date: 2016-04-06 (Wed, 06 Apr 2016) Changed paths: M ex4.xml Log Message: ----------- use ipv6 instead of ipv4 in examples ----==_mimepart_57067590aeb5d_23dd3fb82275b2b8126759-- From nobody Fri Apr 15 08:23:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F212DDDB for ; Fri, 15 Apr 2016 08:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GUtA0Y8MMWZ for ; Fri, 15 Apr 2016 08:23: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 96C7212DDE4 for ; Fri, 15 Apr 2016 08:23:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5D88C116B; Fri, 15 Apr 2016 17:23:20 +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 jU3LzOqCjfJo; Fri, 15 Apr 2016 17:22:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Apr 2016 17:23:19 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69F9A20046; Fri, 15 Apr 2016 17:23:19 +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 99nGHq1Z_90S; Fri, 15 Apr 2016 17:23:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF8852004A; Fri, 15 Apr 2016 17:23:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C41B33AA2BBC; Fri, 15 Apr 2016 17:23:17 +0200 (CEST) Date: Fri, 15 Apr 2016 17:23:17 +0200 From: Juergen Schoenwaelder To: "Ing-Wher (Helen) Chen" Message-ID: <20160415152317.GB95324@elstar.local> Mail-Followup-To: "Ing-Wher (Helen) Chen" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 15 Apr 2016 15:23:24 -0000 Hi Helen, can you explain why urn:rdns:de:jacobs-university:foo is from a technical perspective significantly better than http://jacobs-university.de/foo also considering that domain names are not stable identifiers but subject to changing ownerships or limited lifetimes (and hence a URN embedding domain names has the same stability properties)? /js On Fri, Apr 15, 2016 at 02:59:30PM +0000, Ing-Wher (Helen) Chen wrote: > Hello, > > At IETF94 in Yokohama, I presented an idea to allow enterprise YANG models > to easily generate globally unique namespaces > (https://datatracker.ietf.org/doc/draft-chen-netmod-enterprise-yang-namespace/) . > > The topic was also discussed on the mailing list: > https://mailarchive.ietf.org/arch/msg/netmod/JQmD8yrUeuAwuHpBnqZV_mcuveU > https://mailarchive.ietf.org/arch/msg/netmod/GSz_1dp2R3FPlMmu2_HF3ZIwrsY > https://mailarchive.ietf.org/arch/msg/netmod/tJDZPI9PV1-SjZm2c608OQu41ws > https://mailarchive.ietf.org/arch/msg/netmod/RCYhzKvMd0BATTtxaE69nbvcj7g > > As promised, I started the process of registering the top-level "rdns" namespace. > Following RFC 3406, I wrote https://datatracker.ietf.org/doc/draft-chen-rdns-urn/ > and completed the review on urn-nid@ietf.org . For the review on urn-nid@ietf.org , > please see the following messages. > > The final message stating the review is complete is here: > https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-eTA4ONNiwaJhUPmcs > > The review in its entirety is here: > https://mailarchive.ietf.org/arch/msg/urn-nid/N3Md2evqFPE2o7figeGcyqT4BsY > https://mailarchive.ietf.org/arch/msg/urn-nid/wEIRTDvf4vPJPW9ORw6lkK6St2A > https://mailarchive.ietf.org/arch/msg/urn-nid/btXpEnmt7LHL4ZeCUvxYLQPUps4 > https://mailarchive.ietf.org/arch/msg/urn-nid/52U72G2qzuqEwfSVIkD9YE-Pv3c > https://mailarchive.ietf.org/arch/msg/urn-nid/_AHANMEp_uq9ZFI7bHzf7lVvpoM > https://mailarchive.ietf.org/arch/msg/urn-nid/UgfKVlPS87x-1j2juHI8jLHdmAY > https://mailarchive.ietf.org/arch/msg/urn-nid/fFjwJMup43-P4mGQ4GMnG5DsrdM > https://mailarchive.ietf.org/arch/msg/urn-nid/sRpdhqpw-t4t0A15svbM_eywGj8 > https://mailarchive.ietf.org/arch/msg/urn-nid/pibno5XNyXvAhuJ9bW6lKJjDA0w > https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd-eTA4ONNiwaJhUPmcs > > Thanks, > Helen > > _______________________________________________ > 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 Apr 15 08:53:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC13812DFA2 for ; Fri, 15 Apr 2016 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kReofnIz0Mv1 for ; Fri, 15 Apr 2016 08:53:24 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0642.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E175E12DF3F for ; Fri, 15 Apr 2016 08:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TVbj9e7BF/429oZ6B2VHOsWqoQHpRoSD4Qsgx+lXwjI=; b=mpryoEVsf4oujVRD8d0HXeF3VpngrTo9i/QVpBjtsOURLtlegK6HI5YTsGKadwV3KDToi/LzB3WZl+0yOIQzjHtyiGIs0TQRPTIQaRDNwUg+b3l9oQR1pO5SaLwS7P82oqPwiqSQhcDOmFJM4RNWSXphp/g0StTxXlvI+Xo/7Go= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 15 Apr 2016 15:53:04 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0453.031; Fri, 15 Apr 2016 15:53:04 +0000 From: "Ing-Wher (Helen) Chen" To: Juergen Schoenwaelder Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyA= Date: Fri, 15 Apr 2016 15:53:04 +0000 Message-ID: References: <20160415152317.GB95324@elstar.local> In-Reply-To: <20160415152317.GB95324@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: a563fa42-84d1-417f-a486-08d3654607ef x-microsoft-exchange-diagnostics: 1; DB5PR06MB0950; 5:DTpysRbus79S4/6GKndqzTazF9Iiqxg5uF3+iJkw93ZXpjc0tpBzJr7MyNFjq+BclZoeb2s4bjGEeewWVkYfJ0Ebt1uQAOvOYOdcZq9achNjaDPRs0S56rBLpwLz5YxLIgHKJxz0VkOGZ/8lF+1aPg==; 24:ZYbSL6Apq9HRZnVGDj2iuE8CB4XGU4qwHkCRz3TDwYYynTAj5brZQ0EhUTmqrwxJUjcMr3zc9ABl7UdIz2T7wIGCDm73yZxxRy9GKD4T2KU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0950; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:DB5PR06MB0950; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0950; x-forefront-prvs: 0913EA1D60 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(13464003)(377454003)(4326007)(50986999)(2906002)(76176999)(54356999)(74316001)(3280700002)(3660700001)(5008740100001)(2420400007)(15650500001)(10400500002)(3846002)(102836003)(6116002)(66066001)(9686002)(164054004)(122556002)(189998001)(2900100001)(19580405001)(15975445007)(77096005)(7110500001)(5003600100002)(110136002)(33656002)(19580395003)(2950100001)(5002640100001)(86362001)(575784001)(1720100001)(87936001)(11100500001)(586003)(1220700001)(5004730100002)(92566002)(1096002)(76576001)(81166005)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0950; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2016 15:53:04.1821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0950 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 15:53:27 -0000 Section 4 of the draft =20 documents why a URN is better than URL as a namespace. While a URL is glo= bally unique, a URL is also a resource locator, providing access information. Fo= r an enterprise that does not wish to publish the access information of its YANG models, a = URN is a better choice. As required by RFC 3406, Section 3 of the draft, at the bottom of page 5 under "Identifi= er Persistence Considerations", addresses the question of identifier persistence. The mai= n concern for "identifier persistence" is in the case where an identifier is used for= global resolution. Because YANG model namespaces do not provide global resolutions (actually Y= ANG model namespaces are only used to uniquely identify a model within a device= ), the identifier persistence consideration is not as crucial. (Please see RF= C 3406 top of page 13 for the identi= fier persistence discussion.) Thanks, Helen > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, April 15, 2016 11:23 AM > To: Ing-Wher (Helen) Chen > Cc: netmod@ietf.org > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models >=20 > Hi Helen, >=20 > can you explain why >=20 > urn:rdns:de:jacobs-university:foo >=20 > is from a technical perspective significantly better than >=20 > http://jacobs-university.de/foo >=20 > also considering that domain names are not stable identifiers but subject= to > changing ownerships or limited lifetimes (and hence a URN embedding > domain names has the same stability properties)? >=20 > /js >=20 > On Fri, Apr 15, 2016 at 02:59:30PM +0000, Ing-Wher (Helen) Chen wrote: > > Hello, > > > > At IETF94 in Yokohama, I presented an idea to allow enterprise YANG > > models to easily generate globally unique namespaces > > (https://datatracker.ietf.org/doc/draft-chen-netmod-enterprise-yang- > namespace/) . > > > > The topic was also discussed on the mailing list: > > > https://mailarchive.ietf.org/arch/msg/netmod/JQmD8yrUeuAwuHpBnqZV_ > mcuv > > eU > > > https://mailarchive.ietf.org/arch/msg/netmod/GSz_1dp2R3FPlMmu2_HF3ZI > wr > > sY > > https://mailarchive.ietf.org/arch/msg/netmod/tJDZPI9PV1- > SjZm2c608OQu41 > > ws > > > https://mailarchive.ietf.org/arch/msg/netmod/RCYhzKvMd0BATTtxaE69nbv > cj > > 7g > > > > As promised, I started the process of registering the top-level "rdns" > namespace. > > Following RFC 3406, I wrote > > https://datatracker.ietf.org/doc/draft-chen-rdns-urn/ > > and completed the review on urn-nid@ietf.org . For the review on > > urn-nid@ietf.org , please see the following messages. > > > > The final message stating the review is complete is here: > > https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd- > eTA4ONNiwaJhUP > > mcs > > > > The review in its entirety is here: > > https://mailarchive.ietf.org/arch/msg/urn- > nid/N3Md2evqFPE2o7figeGcyqT4 > > BsY > > https://mailarchive.ietf.org/arch/msg/urn- > nid/wEIRTDvf4vPJPW9ORw6lkK6S > > t2A > > https://mailarchive.ietf.org/arch/msg/urn- > nid/btXpEnmt7LHL4ZeCUvxYLQPU > > ps4 > > https://mailarchive.ietf.org/arch/msg/urn-nid/52U72G2qzuqEwfSVIkD9YE- > P > > v3c > > https://mailarchive.ietf.org/arch/msg/urn- > nid/_AHANMEp_uq9ZFI7bHzf7lVv > > poM > > https://mailarchive.ietf.org/arch/msg/urn-nid/UgfKVlPS87x-1j2juHI8jLHd > > mAY > > https://mailarchive.ietf.org/arch/msg/urn-nid/fFjwJMup43- > P4mGQ4GMnG5Ds > > rdM > > https://mailarchive.ietf.org/arch/msg/urn-nid/sRpdhqpw- > t4t0A15svbM_eyw > > Gj8 > > https://mailarchive.ietf.org/arch/msg/urn-nid/pibno5XNyXvAhuJ9bW6lKJjD > > A0w > > https://mailarchive.ietf.org/arch/msg/urn-nid/-Dwx-2JBd- > eTA4ONNiwaJhUP > > mcs > > > > Thanks, > > Helen > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Apr 15 13:54:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCAB12D10F for ; Fri, 15 Apr 2016 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYlZUcxYKDMw for ; Fri, 15 Apr 2016 13:54:09 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0061.outbound.protection.outlook.com [104.47.2.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E5012D767 for ; Fri, 15 Apr 2016 13:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=66FCuxBI7gJr+vEbFOniVaouGJ1Mum0Pizt+r09wMZc=; b=MMoypJcC0twCG6Oairc4igecix9y9YEwGrCAwlC6yPuBniyTBHnT9m6+FCzfdgg4ppATuWLVPz0POxA2uKaacsbfpu5pOABQ3lZWYeV98ofGwvUyuPg6ZVGATXJwQQY+8fJmb2cIx5VCCEXdLzyPp/LOAOfBf1/eZrsBvPm1f8E= Received: from AM4PR06MB1474.eurprd06.prod.outlook.com (10.164.80.28) by AM4PR06MB1473.eurprd06.prod.outlook.com (10.164.80.27) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 15 Apr 2016 20:54:04 +0000 Received: from AM4PR06MB1474.eurprd06.prod.outlook.com ([10.164.80.28]) by AM4PR06MB1474.eurprd06.prod.outlook.com ([10.164.80.28]) with mapi id 15.01.0453.031; Fri, 15 Apr 2016 20:54:04 +0000 From: Athanasios Kyparlis To: NETMOD WG Thread-Topic: [netmod] schema mount issues - ifStacking Thread-Index: AdGXVLCu8nd/CPIBQymvR7aD8tgX+Q== Date: Fri, 15 Apr 2016 20:54:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 95435c44-10c7-4b0b-bf1f-08d365701450 x-microsoft-exchange-diagnostics: 1; AM4PR06MB1473; 5:gzqOFr+EMjhFxL6eBetbp6D8tUvLLdtUlE8c3rGX0MmZvoium5QtHPQu+FPCUEklET7faxnOLCIv11T1iChohgnHTE+WwyFPbDsO73ATJDuDdieY/tnBB5X6qpJrjemc6l4yZ7L97AYGI0wG8se+BQ==; 24:9dl98//uq0eFFl+bjMjs2YLhwhsK6W/6GKQA6ZCEj6nDAM0oX6d8RBNNB2/Zj+trQTXVYC1g0JnxOlaTROpz/St+sXINjpM39B1kU+41RHk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR06MB1473; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:AM4PR06MB1473; BCL:0; PCL:0; RULEID:; SRVR:AM4PR06MB1473; x-forefront-prvs: 0913EA1D60 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(13464003)(5002640100001)(1220700001)(86362001)(5008740100001)(54356999)(3660700001)(50986999)(87936001)(189998001)(110136002)(575784001)(1096002)(3280700002)(107886002)(5004730100002)(5003600100002)(11100500001)(2906002)(33656002)(19580405001)(19580395003)(66066001)(10400500002)(122556002)(92566002)(3846002)(450100001)(6116002)(102836003)(76576001)(74316001)(2900100001)(77096005)(9686002)(586003)(81166005)(15975445007)(164054004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR06MB1473; H:AM4PR06MB1474.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2016 20:54:03.9387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR06MB1473 Archived-At: Subject: Re: [netmod] schema mount issues - ifStacking X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 20:54:11 -0000 I was wondering how schema-mount would support the use case of ifStacking i= nterfaces across mount-points (e.g. across logical network devices). Currently, according to rfc7223, higher/lower-layer-if are of type interfac= e-state-ref typedef interface-state-ref { type leafref { path "/if:interfaces-state/if:interface/if:name"; } description "This type is used by data models that need to reference the operationally present interfaces."; } If I am reading the schema mount draft correctly (3.1), the above reference= would be confined to the same mount-point, so, in the specific case, inter= faces could only reference higher/lower-layer-ifs within the same logical d= evice/network instance. How could one reference interfaces across logical device/network instances? Thanks, Athanasios -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Thursday, April 7, 2016 11:01 AM To: Andy Bierman ; Ladislav Lhotka Cc: NETMOD WG Subject: Re: [netmod] schema mount issues All, The repo has been setup to send notification of changes to netmod.=20 We'll have to see how this works, and if it doesn't work well will have fig= ure out what to try next... Lou On 4/5/2016 6:07 PM, Lou Berger wrote: > > On 4/5/2016 1:40 PM, Andy Bierman wrote: >> >> On Tue, Apr 5, 2016 at 10:18 AM, Ladislav Lhotka > > wrote: >> >> Hi, >> >> during the NETMOD session yesterday, we didn't have much time to >> discuss open issues related to schema mount. So I created three >> new issues in the GitHub project: >> >> https://github.com/netmod-wg/schema-mount/issues >> >> Please express your opinion there. >> >> >> As a procedural issue I think WG business needs to be conducted on=20 >> the WG mailing list, not on github. >> > +1 > > capturing issues somewhere is important, and github is a fine place --=20 > but discussion need to be on list. > > -- it would be great if you could gateway issues to the WG list. > > Thanks, > Lou > (as one of three chairs, ;-) >> =20 >> >> >> Thanks, Lada >> >> >> Andy >> =20 >> >> -- >> 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 > > _______________________________________________ > 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 Fri Apr 15 16:42:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F070B12DC74 for ; Fri, 15 Apr 2016 16:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J516Ggn2jsC6 for ; Fri, 15 Apr 2016 16:42:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6268A12DBD7 for ; Fri, 15 Apr 2016 16:42:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B501D8DD; Sat, 16 Apr 2016 01:42:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id c74F87xWrKb5; Sat, 16 Apr 2016 01:42:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 16 Apr 2016 01:42:41 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8709120047; Sat, 16 Apr 2016 01:42:41 +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 o67VhYMnYJ0o; Sat, 16 Apr 2016 01:42:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D435420046; Sat, 16 Apr 2016 01:42:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F12A43AA32DE; Sat, 16 Apr 2016 01:42:38 +0200 (CEST) Date: Sat, 16 Apr 2016 01:42:38 +0200 From: Juergen Schoenwaelder To: "Ing-Wher (Helen) Chen" Message-ID: <20160415234236.GC95761@elstar.local> Mail-Followup-To: "Ing-Wher (Helen) Chen" , "netmod@ietf.org" References: <20160415152317.GB95324@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 15 Apr 2016 23:42:47 -0000 On Fri, Apr 15, 2016 at 03:53:04PM +0000, Ing-Wher (Helen) Chen wrote: > Section 4 of the draft > documents why a URN is better than URL as a namespace. While a URL is globally > unique, a URL is also a resource locator, providing access information. For an enterprise > that does not wish to publish the access information of its YANG models, a URN is a better > choice. Continuing as devil's advocate... The YANG specifications (both 1.0 and 1.1) has a normative reference to https://www.w3.org/TR/2009/REC-xml-names-20091208/ which states in section 3: [...] The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). Uniform Resource Names [RFC2141] is an example of a syntax that is designed with these goals in mind. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals. Do we have evidence that managing ordinary URLs in such a way as to achieve these same goals (of uniqueness and persistence) is a problem? If so, why does this only apply to YANG modules (only one of many uses of XML namespaces)? > As required by RFC 3406, Section 3 of the draft, at the bottom of page 5 > under "Identifier Persistence > Considerations", addresses the question of identifier persistence. The main concern > for "identifier persistence" is in the case where an identifier is used for global resolution. > Because YANG model namespaces do not provide global resolutions (actually YANG > model namespaces are only used to uniquely identify a model within a device), > the identifier persistence consideration is not as crucial. (Please see RFC 3406 > top of page 13 for the identifier > persistence discussion.) I am not sure I agree that the scope of a YANG namespace is limited to a device. There is nothing that prevents some random device to implement some random YANG model. If the org currently owning bar.foo publishes a module using urn:rdns:com:foo:bar as a namespace then other orgs can implement this module as well if they think this is a good idea. I read: In practice, an administrator consciously installs YANG modules in a device. Thus, in the unlikely event that there is a collision due to changing domain names, the administrator can detect the collision and rectify the situation by requesting that the offending organization republish its YANG modules with the correct "rdns" URNs. Who is the 'administrator' that consciously installs YANG modules in a device here? Administrator of what - the namespace or the device? In case you mean the administrator of the namespace then what happens in the case where this role changes because some other org took over the domain name? If a module uses urn:rdns:com:foo:bar and I later buy the domain bar.foo than do I get change control of the YANG module using this particular namespace as a side effect? [...break...] Taking a step back, we do have the tension between XML namespaces (that are identified by URIs and used in the XML encoding) and 'JSON namespaces' identified by module names (and used in the JSON encoding). The former is relying on the uniqueness of a URI while the later is relying on the uniqueness of the YANG module name. So from this perspective, assuming the YANG module name is already sufficiently unique, perhaps the right thing to do is to simply use urn:yang: for all XML namespaces and to essentially get rid of the namespace declaration in YANG (which then defaults to urn:yang:). Now I need a break to think about this... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Apr 18 18:50:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2978812DBC0 for ; Mon, 18 Apr 2016 18:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnRA0m_9Zk7G for ; Mon, 18 Apr 2016 18:50:29 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D11112D777 for ; Mon, 18 Apr 2016 18:50:29 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id e190so2319948lfe.0 for ; Mon, 18 Apr 2016 18:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=GJt7gQjKUs+klEcB4VwCUNXMT6cl4ruFpZbV7fyHIg4=; b=fKDoFH+3G4hseJ6zk9cUd9l0wGKt1HPcDdopSg+a/oWD/XLSKtlQsAZtmf7amp1E4L QOYHrbxwX9L0phXBFXTvU6IZidFtkUk8Pnq60/Jw9LOalm8Z8w08PRmtMbryWVPK8YgU bguWJ3poZaoQRTdJKuApAUh7AobABVUJT9khBDHmpu+WpRo4TkUIBwSPnPYOmmcNhBYk eWr6fk9PMlBeQO8HxwxilvEo6l9Nkqf+iK5qDhPU6HTdqXNQgQETbckF3yl3UNO5Pw6A VICujLc+kQzCAYOCg2BVR9+dOKZze9aY10Ipw77uhgTcdN2uUmpzYmeG0j12l93lgVhf MaKg== 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; bh=GJt7gQjKUs+klEcB4VwCUNXMT6cl4ruFpZbV7fyHIg4=; b=CqkjDxRDi7hEILjYwTB1ouF6gQ2OvDoz1f6TnOsEqqmuPBKcibfxnnSBNut37Kq0V5 wzF1eJ6rFeFR6nEVumNnhNbxHITrY48oLCJIBlONComIs/X++yltbfaPODKv/KEB2dAQ TO6J/ds5FylzmGCYm7gflF3z1HFAy9MMC2ID9GOPsEyAWnH33uItN/DaaZIMKaItRXLJ U++5sq4hCbG7ziQpWs+6Zzm4XfzverlfraYjoP9o/EsHf6dlR/RZJvk09Lv4khbBp0e1 1wCR5XRPTlE+/sYq2oX/gAeoO0B3/EJpjGsMM0xASIKPXrGCbD/8ynzNv51lsxRDapjS kgpg== X-Gm-Message-State: AOPr4FVMrS8clncceB4Qa8Jsi2UplWkhjFHtrEc9WhY0fOluZFxsEcHGpcQWdjspd/47vHDZGI9VCU3V4jf3Ew== MIME-Version: 1.0 X-Received: by 10.25.64.212 with SMTP id n203mr155907lfa.62.1461030627541; Mon, 18 Apr 2016 18:50:27 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Mon, 18 Apr 2016 18:50:27 -0700 (PDT) Date: Mon, 18 Apr 2016 18:50:27 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113fc26a8f9cb80530ccb325 Archived-At: Subject: [netmod] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 01:50:34 -0000 --001a113fc26a8f9cb80530ccb325 Content-Type: text/plain; charset=UTF-8 Hi, The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, delete) Is says [default-stmt] but it should be *default-stmt Is it intentional that the ABNF for deviate-delete-stmt leaves out config, mandatory, max-elements, and min-elements? I understand why "type" cannot be removed. IMO the rest of the statements should be removable. Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. This section should make it clear a leaf has only 1 default and the 0..n refers to leaf-list only. It should also be clear that the "deviate add default" for a leaf-list is YANG statement order-dependent. Not as obvious -- a config=false leaf-list can have duplicate default values. The deviate-stmt has no way to specify which 1 to delete or replace if there are duplicates. Andy --001a113fc26a8f9cb80530ccb325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The ABNF for "default" is= wrong in the deviate-*-stmt (add, replace, delete)
Is says [defa= ult-stmt] but it should be *default-stmt

Is it int= entional that the ABNF for deviate-delete-stmt leaves out
config,= mandatory, max-elements, and min-elements?
I understand why &quo= t;type" cannot be removed.

IMO the rest of th= e statements should be removable.
Sec. 7.20.3.2 does not mention = the restrictions indicated in the ABNF.
This section should make = it clear a leaf has only 1 default
and the 0..n refers to leaf-li= st only.

It should also be clear that the "de= viate add default" for a leaf-list
is YANG statement order-d= ependent.

Not as obvious -- a config=3Dfalse leaf-= list can have duplicate default values.
The deviate-stmt has no w= ay to specify which 1 to delete or replace
if there are duplicate= s.


Andy



--001a113fc26a8f9cb80530ccb325-- From nobody Tue Apr 19 00:30:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FFE12E1D3 for ; Tue, 19 Apr 2016 00:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AztOLdycBpNd for ; Tue, 19 Apr 2016 00:30:50 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 4BB6612DCC8 for ; Tue, 19 Apr 2016 00:30:50 -0700 (PDT) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3J7NB6p009033 for ; Tue, 19 Apr 2016 00:30:45 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 22bmp4x4r3-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 19 Apr 2016 00:30:45 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 01:30:41 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 09:30:35 +0200 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Tue, 19 Apr 2016 09:30:35 +0200 From: William Ivory To: "netmod@ietf.org" Thread-Topic: Question about updating YANG modules Thread-Index: AdGaDIsRoA8Ay+auSpqxOPLgxtuk4A== Date: Tue, 19 Apr 2016 07:30:14 +0000 Deferred-Delivery: Tue, 19 Apr 2016 07:29:33 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.252.48.6] Content-Type: multipart/alternative; boundary="_000_eead3a05c85f43c688ce29e84eeac6e5EMEAWPEXMB12corpbrocade_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604190123 Archived-At: Subject: [netmod] Question about updating YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:30:52 -0000 --_000_eead3a05c85f43c688ce29e84eeac6e5EMEAWPEXMB12corpbrocade_ Content-Type: text/plain; charset="us-ascii" Hi, Section 10 of the YANG RFC covers updating modules while maintaining backwards-compatibiility. I have a question about whether the following statement allows for a string type to be replaced with a union comprising solely of string types, so long as the overall set of strings accepted was no more restrictive? This would allow us to reuse some existing types. o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but an int8 type cannot be replaced by an int16, since the syntax would change. I can see that changing int8 to int16 changes the syntax, but does changing from string to a union of strings change the syntax according to this definition? Thanks, William --_000_eead3a05c85f43c688ce29e84eeac6e5EMEAWPEXMB12corpbrocade_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Section 10 of the YANG RFC covers updating modules while maintaining b= ackwards-compatibiility.  I have a question about whether the followin= g statement allows for a string type to be replaced with a union comprising= solely of string types, so long as the overall set of strings accepted was no more restrictive?  This would a= llow us to reuse some existing types.
 
   o  A "type" statement may be replaced with= another "type" statement
      that does not change the syntax or sema= ntics of the type.  For
      example, an inline type definition may = be replaced with a typedef,
      but an int8 type cannot be replaced by = an int16, since the syntax
      would change.
 
I can see that changing int8 to int16 changes the syntax, but does cha= nging from string to a union of strings change the syntax according to this= definition?
 
Thanks,
 
William
 
 --_000_eead3a05c85f43c688ce29e84eeac6e5EMEAWPEXMB12corpbrocade_-- From nobody Tue Apr 19 00:40:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A7112ECC4 for ; Tue, 19 Apr 2016 00:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTBxhXD7eXRZ for ; Tue, 19 Apr 2016 00:40:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B77412ECC1 for ; Tue, 19 Apr 2016 00:40: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 C68B46DC; Tue, 19 Apr 2016 09:40: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 XZD1mYY5N0Di; Tue, 19 Apr 2016 09:40:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 Apr 2016 09:40:44 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A09D2004A; Tue, 19 Apr 2016 09:40:44 +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 Z8RVb88w_UT6; Tue, 19 Apr 2016 09:40: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 F1C5B20046; Tue, 19 Apr 2016 09:40:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0AF603AA6E27; Tue, 19 Apr 2016 09:40:41 +0200 (CEST) Date: Tue, 19 Apr 2016 09:40:41 +0200 From: Juergen Schoenwaelder To: William Ivory Message-ID: <20160419074041.GA2342@elstar.local> Mail-Followup-To: William Ivory , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about updating YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 07:40:49 -0000 A type is essentially defining a set of allowed values. If this set of values does not change (and the semantics associated with the values do not change), then you can change the type used in the type statement. /js On Tue, Apr 19, 2016 at 07:30:14AM +0000, William Ivory wrote: > Hi, > > Section 10 of the YANG RFC covers updating modules while maintaining backwards-compatibiility. I have a question about whether the following statement allows for a string type to be replaced with a union comprising solely of string types, so long as the overall set of strings accepted was no more restrictive? This would allow us to reuse some existing types. > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but an int8 type cannot be replaced by an int16, since the syntax > would change. > > I can see that changing int8 to int16 changes the syntax, but does changing from string to a union of strings change the syntax according to this definition? > > Thanks, > > William > > _______________________________________________ > 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 Apr 19 01:02:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344A912DCEF for ; Tue, 19 Apr 2016 01:02:42 -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_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyKuL9d_hTiR for ; Tue, 19 Apr 2016 01:02:39 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 BAC2B12DCCA for ; Tue, 19 Apr 2016 01:02:39 -0700 (PDT) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3J7vj1p012567; Tue, 19 Apr 2016 01:02:39 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 22bmsxe9nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Apr 2016 01:02:39 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 02:02:37 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 10:02:36 +0200 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Tue, 19 Apr 2016 10:02:36 +0200 From: William Ivory To: Juergen Schoenwaelder Thread-Topic: [netmod] Question about updating YANG modules Thread-Index: AdGaDIsRoA8Ay+auSpqxOPLgxtuk4P//4u6A///ZOCA= Date: Tue, 19 Apr 2016 08:02:24 +0000 Deferred-Delivery: Tue, 19 Apr 2016 08:02:16 +0000 Message-ID: <0f43e4eb85a64205b3bdb11c9e009d01@EMEAWP-EXMB12.corp.brocade.com> References: <20160419074041.GA2342@elstar.local> In-Reply-To: <20160419074041.GA2342@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.252.48.6] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604190131 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about updating YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:02:42 -0000 OK - but changing from int8 to int16 still allows all previously allowed values, and simply adds some more, making it less restrictive. That isn't allowed though as noted in the bullet point from section 10 below. What about extending a union that previously included say just strings to include int8 as well - is that allowed under section 10 rules? Thanks, William -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: 19 April 2016 08:41 To: William Ivory Cc: netmod@ietf.org Subject: Re: [netmod] Question about updating YANG modules A type is essentially defining a set of allowed values. If this set of values does not change (and the semantics associated with the values do not change), then you can change the type used in the type statement. /js On Tue, Apr 19, 2016 at 07:30:14AM +0000, William Ivory wrote: > Hi, > > Section 10 of the YANG RFC covers updating modules while maintaining backwards-compatibiility. I have a question about whether the following statement allows for a string type to be replaced with a union comprising solely of string types, so long as the overall set of strings accepted was no more restrictive? This would allow us to reuse some existing types. > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but an int8 type cannot be replaced by an int16, since the syntax > would change. > > I can see that changing int8 to int16 changes the syntax, but does changing from string to a union of strings change the syntax according to this definition? > > Thanks, > > William > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > man_listinfo_netmod&d=CwIBAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_A > lgBo9uvdDrxizlOR7l_SnTXowyJU8&m=eNnaJYadAK0Fvw2MfBD-jQYKBdoeq28VUey6fK > A5B6s&s=lzSZQBGv2Xz2LtMHfvwQmV0K6i7olWuSvPFW9XEkA8M&e= -- 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 Apr 19 01:12:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5313612E0E2 for ; Tue, 19 Apr 2016 01:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjCZt_N6Wy56 for ; Tue, 19 Apr 2016 01:12:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CFF12E07E for ; Tue, 19 Apr 2016 01:12:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D3A008F9; Tue, 19 Apr 2016 10:12:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nDbOIvJqCJcx; Tue, 19 Apr 2016 10: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; Tue, 19 Apr 2016 10:12:06 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D73220047; Tue, 19 Apr 2016 10:12:06 +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 aQdHoExoLgKC; Tue, 19 Apr 2016 10:12: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 C336620046; Tue, 19 Apr 2016 10:12:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8D1653AA7008; Tue, 19 Apr 2016 10:12:04 +0200 (CEST) Date: Tue, 19 Apr 2016 10:12:04 +0200 From: Juergen Schoenwaelder To: William Ivory Message-ID: <20160419081204.GA2451@elstar.local> Mail-Followup-To: William Ivory , "netmod@ietf.org" References: <20160419074041.GA2342@elstar.local> <0f43e4eb85a64205b3bdb11c9e009d01@EMEAWP-EXMB12.corp.brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f43e4eb85a64205b3bdb11c9e009d01@EMEAWP-EXMB12.corp.brocade.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about updating YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 08:12:09 -0000 On Tue, Apr 19, 2016 at 08:02:24AM +0000, William Ivory wrote: > OK - but changing from int8 to int16 still allows all previously > allowed values, and simply adds some more, making it less > restrictive. That isn't allowed though as noted in the bullet point > from section 10 below. Obviously, the set of allowed values changes when you replace int8 with int16. > What about extending a union that previously included say just strings to include int8 as well - is that allowed under section 10 rules? This is an interesting question. Assuming you had leaf a { type string; } and you change it to leaf a { type union { type int8; type string; } } then for the XML encoding the set of values does not change however for the JSON encoding it does change. See the JSON document for subtleties associated with unions. To prevent damage for encodings that carry some type information, we might need a stricter interpretation of YANG compatibility rules... /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 Apr 19 01:21:15 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC8E12E95B for ; Tue, 19 Apr 2016 01:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yimv3diGx91J for ; Tue, 19 Apr 2016 01:21:11 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 03DEC12EB89 for ; Tue, 19 Apr 2016 01:21:09 -0700 (PDT) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3J8HpxC022699; Tue, 19 Apr 2016 01:21:09 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 22bm46ecgc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Apr 2016 01:21:09 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 02:21:07 -0600 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 10:21:06 +0200 Received: from EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a]) by EMEAWP-EXMB12.corp.brocade.com ([fe80::44d8:98be:88a6:417a%23]) with mapi id 15.00.1104.000; Tue, 19 Apr 2016 10:21:06 +0200 From: William Ivory To: Juergen Schoenwaelder Thread-Topic: [netmod] Question about updating YANG modules Thread-Index: AdGaDIsRoA8Ay+auSpqxOPLgxtuk4P//4u6A///ZOCCAAC+NAP//3WAQ Date: Tue, 19 Apr 2016 08:20:36 +0000 Deferred-Delivery: Tue, 19 Apr 2016 08:19:53 +0000 Message-ID: <099c393f7d31491fbb38fbbc0ccdfba9@EMEAWP-EXMB12.corp.brocade.com> References: <20160419074041.GA2342@elstar.local> <0f43e4eb85a64205b3bdb11c9e009d01@EMEAWP-EXMB12.corp.brocade.com> <20160419081204.GA2451@elstar.local> In-Reply-To: <20160419081204.GA2451@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.252.48.6] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604190141 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about updating YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:21:13 -0000 So would it be a fair summary to say that it is allowed to change from a specific type to a union consisting only of those types, but that adding different types on top of the existing type is not recommended. Which JSON document are you referring to? Thanks, William -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: 19 April 2016 09:12 To: William Ivory Cc: netmod@ietf.org Subject: Re: [netmod] Question about updating YANG modules On Tue, Apr 19, 2016 at 08:02:24AM +0000, William Ivory wrote: > OK - but changing from int8 to int16 still allows all previously > allowed values, and simply adds some more, making it less restrictive. > That isn't allowed though as noted in the bullet point from section 10 > below. Obviously, the set of allowed values changes when you replace int8 with int16. > What about extending a union that previously included say just strings to include int8 as well - is that allowed under section 10 rules? This is an interesting question. Assuming you had leaf a { type string; } and you change it to leaf a { type union { type int8; type string; } } then for the XML encoding the set of values does not change however for the JSON encoding it does change. See the JSON document for subtleties associated with unions. To prevent damage for encodings that carry some type information, we might need a stricter interpretation of YANG compatibility rules... /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 Apr 19 01:25:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7705912ED09 for ; Tue, 19 Apr 2016 01:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AR26rs7Zt1a for ; Tue, 19 Apr 2016 01:25:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174FF12ED0A for ; Tue, 19 Apr 2016 01:25: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 D2225A9B; Tue, 19 Apr 2016 10:25: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 WiUeltDmIP4Z; Tue, 19 Apr 2016 10:25: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; Tue, 19 Apr 2016 10:25:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 425C420047; Tue, 19 Apr 2016 10:25:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4ia3-nY1oNNk; Tue, 19 Apr 2016 10:25: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 DB10D20046; Tue, 19 Apr 2016 10:25:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CDF983AA708B; Tue, 19 Apr 2016 10:25:44 +0200 (CEST) Date: Tue, 19 Apr 2016 10:25:44 +0200 From: Juergen Schoenwaelder To: William Ivory Message-ID: <20160419082544.GA2524@elstar.local> Mail-Followup-To: William Ivory , "netmod@ietf.org" References: <20160419074041.GA2342@elstar.local> <0f43e4eb85a64205b3bdb11c9e009d01@EMEAWP-EXMB12.corp.brocade.com> <20160419081204.GA2451@elstar.local> <099c393f7d31491fbb38fbbc0ccdfba9@EMEAWP-EXMB12.corp.brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <099c393f7d31491fbb38fbbc0ccdfba9@EMEAWP-EXMB12.corp.brocade.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Question about updating YANG modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 08:25:49 -0000 On Tue, Apr 19, 2016 at 08:20:36AM +0000, William Ivory wrote: > So would it be a fair summary to say that it is allowed to change from a specific type to a union consisting only of those types, but that adding different types on top of the existing type is not recommended. > > Which JSON document are you referring to? > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10 /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 Apr 19 01:50:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF9512E0D8 for ; Tue, 19 Apr 2016 01:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0h3wpOWs5sp for ; Tue, 19 Apr 2016 01:50:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 20CDB12DF4F for ; Tue, 19 Apr 2016 01:50:12 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 80ED21AE0383; Tue, 19 Apr 2016 10:50:08 +0200 (CEST) Date: Tue, 19 Apr 2016 10:50:21 +0200 (CEST) Message-Id: <20160419.105021.2152837727269070493.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] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:50:15 -0000 Andy Bierman wrote: > Hi, > > The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, delete) > Is says [default-stmt] but it should be *default-stmt Thanks, fixed. But for deviate-replace, it is not clear what the correct answer is. This is pretty clear: leaf foo { type int32; default 42; } deviation /foo { deviate replace { default 10; } } But what about this: leaf-list bar { type int32; default 42; default 43; } deviation /bar { deviate replace { default 10; default 11; } } Are all defaults changed? Compare with must and unique - they can not be replaced currently. In order to resolve this we probably need more text as well :( OLD: The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node. NEW: The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node. If multiple properties exist in the target node, all of them are replaced with the new properties defined in the substatements to the deviate statement. + add an example to the section "Usage examples": NEW: In this example, the original definition of a leaf list has two default values "42" and "43: leaf-list bar { type int32; default 42; default 43; } A server can change this to the values "10" and "11" instead: deviation /base:bar { deviate replace { default 10; default 11; } } Also, change the grammar: OLD: deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [type-stmt] [units-stmt] [default-stmt] [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt] "}") stmtsep NEW: deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [type-stmt] [units-stmt] *must-stmt *unique-stmt *default-stmt [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt] "}") stmtsep > Is it intentional that the ABNF for deviate-delete-stmt leaves out > config, mandatory, max-elements, and min-elements? > I understand why "type" cannot be removed. I don't really remember, but I can see that if you want to "delete" min-elements you can replace it and set it to 0. > IMO the rest of the statements should be removable. > Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. > This section should make it clear a leaf has only 1 default > and the 0..n refers to leaf-list only. In general, the result after applying deviations must be valid - e.g., you cannot deviate "foo" as the default for an int32 leaf. > It should also be clear that the "deviate add default" for a leaf-list > is YANG statement order-dependent. > > Not as obvious -- a config=false leaf-list can have duplicate default > values. > The deviate-stmt has no way to specify which 1 to delete or replace > if there are duplicates. Unless replace will replace *all*, as suggested above. /martin From nobody Tue Apr 19 02:21:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92CC12E066 for ; Tue, 19 Apr 2016 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.996 X-Spam-Level: X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIVq9b9TUvpv for ; Tue, 19 Apr 2016 02:21:26 -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 0057912DD94 for ; Tue, 19 Apr 2016 02:21:25 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:3c34:4029:d88a:2446] (unknown [IPv6:2001:718:1a02:1:3c34:4029:d88a:2446]) by mail.nic.cz (Postfix) with ESMTPSA id 36D98180A24; Tue, 19 Apr 2016 11:21:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461057683; bh=VL4QbTCj8+OlGhmHN3vFtQdNz85zUgZ46Wym5R1lkCg=; h=From:Date:To; b=kCCd9aMjbLpS/xzX1ftMwnKvNsXACUQ1POWbSIZVwUEa6M37ve1x1BrKCvidX9wIz y26G4yinrTi4DyNwve3VM6oikJ0Q8c8WqBH962RPgbN+26XHFw1wyIF/Xh3N1Gzwpi GiMYrKO9YM7Z1AkAAvXa/EJil/P+1aEa07yfCct8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160419.105021.2152837727269070493.mbj@tail-f.com> Date: Tue, 19 Apr 2016 11:21:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47F854AA-B2D5-470E-A1A3-60C5B5B82E95@nic.cz> References: <20160419.105021.2152837727269070493.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 09:21:29 -0000 > On 19 Apr 2016, at 10:50, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: >> Hi, >>=20 >> The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, = delete) >> Is says [default-stmt] but it should be *default-stmt >=20 > Thanks, fixed. >=20 > But for deviate-replace, it is not clear what the correct answer is. >=20 > This is pretty clear: >=20 > leaf foo { > type int32; > default 42; > } >=20 > deviation /foo { > deviate replace { > default 10; > } > } >=20 > But what about this: >=20 > leaf-list bar { > type int32; > default 42; > default 43; > } >=20 > deviation /bar { > deviate replace { > default 10; > default 11; > } > } >=20 > Are all defaults changed? >=20 > Compare with must and unique - they can not be replaced currently. >=20 > In order to resolve this we probably need more text as well :( >=20 >=20 > OLD: >=20 > The argument "replace" replaces properties of the target node. The > properties to replace are identified by substatements to the > "deviate" statement. The properties to replace MUST exist in the > target node. >=20 >=20 > NEW: >=20 > The argument "replace" replaces properties of the target node. The > properties to replace are identified by substatements to the > "deviate" statement. The properties to replace MUST exist in the > target node. If multiple properties exist in the target node, all > of them are replaced with the new properties defined in the > substatements to the deviate statement. >=20 > + add an example to the section "Usage examples": >=20 > NEW: >=20 > In this example, the original definition of a leaf list has two > default values "42" and "43: >=20 > leaf-list bar { > type int32; > default 42; > default 43; > } >=20 > A server can change this to the values "10" and "11" instead: >=20 > deviation /base:bar { > deviate replace { > default 10; > default 11; > } > } Makes sense. However, Balazs asked previously about multiple deviations = with the same target node: https://www.ietf.org/mail-archive/web/netmod/current/msg14532.html It seems there has been no resolution. In this case, if default values = are replaced multiple times, which version will take effect? Lada >=20 >=20 > Also, change the grammar: >=20 > OLD: >=20 > deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str = optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [type-stmt] > [units-stmt] > [default-stmt] > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > "}") stmtsep >=20 > NEW: >=20 > deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str = optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [type-stmt] > [units-stmt] > *must-stmt > *unique-stmt > *default-stmt > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > "}") stmtsep >=20 >=20 >=20 >=20 >=20 >> Is it intentional that the ABNF for deviate-delete-stmt leaves out >> config, mandatory, max-elements, and min-elements? >> I understand why "type" cannot be removed. >=20 > I don't really remember, but I can see that if you want to "delete" > min-elements you can replace it and set it to 0. >=20 >> IMO the rest of the statements should be removable. >=20 >> Sec. 7.20.3.2 does not mention the restrictions indicated in the = ABNF. >> This section should make it clear a leaf has only 1 default >> and the 0..n refers to leaf-list only. >=20 > In general, the result after applying deviations must be valid - e.g., > you cannot deviate "foo" as the default for an int32 leaf. >=20 >> It should also be clear that the "deviate add default" for a = leaf-list >> is YANG statement order-dependent. >>=20 >> Not as obvious -- a config=3Dfalse leaf-list can have duplicate = default >> values. >> The deviate-stmt has no way to specify which 1 to delete or replace >> if there are duplicates. >=20 > Unless replace will replace *all*, as suggested above. >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 19 08:35:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B27D12E0A2 for ; Tue, 19 Apr 2016 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xrp-6P-I7G1 for ; Tue, 19 Apr 2016 08:35:43 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0417B12DFC1 for ; Tue, 19 Apr 2016 08:35:43 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id c126so22909921lfb.2 for ; Tue, 19 Apr 2016 08:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=t8IWo/lrl9Xt5aRViQ9yyQu73nuM68LUqwoSLESOsbM=; b=o4Usaoi/YhUIPEJ8lUnXW/JIgLML794uQDrI6/VG/iVcysiXxjbfrSn9k1AG79QSeu EhrW93Cb7COzqPPAQPpux2L72oBjP2KQ14okH4vOz0mDXW0WEtTGjZq600YjGEyFFLdM xyoZSvQ1IyiQmX/oB8N6v+hUTgiTBhy4vnYAcE0Wm4L5hSyuukKuMpgWoEJxKGBOshnw ste7mMnKzqk1yxlzl8sv7FjcxGoroL1jOLvwSYnRHNIW8Q7T0FQ8Oalh+im0DBcUS7Sr C/ZxM4gJ91Qp7S1RzQrLofsPrOCEkUpXf9tYIwO7nVD/tlEvS+cQM3HzlihcufsvqAz2 GBgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=t8IWo/lrl9Xt5aRViQ9yyQu73nuM68LUqwoSLESOsbM=; b=JF4oKQZyPAGwe4nZAKeaRJhnH25dSZqBkW9VNXvhUcBm/sY6IEbLZapd0Ytkg1vBdP 5Z2zu8/eiRm5gtGuGmQGXWcINjwxd4H2qlJhgmWrzGy1YGxSOqqLHfgdkV3Wj6h8RTwZ ZexjsfuuDEoSGvn2lm5E4fmRIoIi+HNWF9tbIE2Z/eGzOkApJ1ZdltojIHBgkyPEiQKh ZZNDTfZv3BXBEknh7dCMa4G1F8e4KH38ELcZpCFhyrXByzZS+n8NzKe1McF2STwFWcIg eRgSnPWh5qlRJDjUj39FXXCWd21fuCCSdoOWfbyD/746bTEnqBdNtKTtybRI1L0aRunI oNGg== X-Gm-Message-State: AOPr4FUXIn6iqG0HI/UjmcBD9dKaStNM8gAUoO/eReFgkSaZzzIITz6tR8EndHRPJXZWliDCccN/CDFmBoFp7g== MIME-Version: 1.0 X-Received: by 10.112.129.169 with SMTP id nx9mr1660773lbb.96.1461080141184; Tue, 19 Apr 2016 08:35:41 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Tue, 19 Apr 2016 08:35:41 -0700 (PDT) In-Reply-To: <47F854AA-B2D5-470E-A1A3-60C5B5B82E95@nic.cz> References: <20160419.105021.2152837727269070493.mbj@tail-f.com> <47F854AA-B2D5-470E-A1A3-60C5B5B82E95@nic.cz> Date: Tue, 19 Apr 2016 08:35:41 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b3441dacdd9070530d83a19 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:35:50 -0000 --047d7b3441dacdd9070530d83a19 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 19, 2016 at 2:21 AM, Ladislav Lhotka wrote: > > > On 19 Apr 2016, at 10:50, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > >> Hi, > >> > >> The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, > delete) > >> Is says [default-stmt] but it should be *default-stmt > > > > Thanks, fixed. > > > > But for deviate-replace, it is not clear what the correct answer is. > > > > This is pretty clear: > > > > leaf foo { > > type int32; > > default 42; > > } > > > > deviation /foo { > > deviate replace { > > default 10; > > } > > } > > > > But what about this: > > > > leaf-list bar { > > type int32; > > default 42; > > default 43; > > } > > > > deviation /bar { > > deviate replace { > > default 10; > > default 11; > > } > > } > > > > Are all defaults changed? > > > > Compare with must and unique - they can not be replaced currently. > > > > In order to resolve this we probably need more text as well :( > > > > > > OLD: > > > > The argument "replace" replaces properties of the target node. The > > properties to replace are identified by substatements to the > > "deviate" statement. The properties to replace MUST exist in the > > target node. > > > > > > NEW: > > > > The argument "replace" replaces properties of the target node. The > > properties to replace are identified by substatements to the > > "deviate" statement. The properties to replace MUST exist in the > > target node. If multiple properties exist in the target node, all > > of them are replaced with the new properties defined in the > > substatements to the deviate statement. > > > > + add an example to the section "Usage examples": > > > > NEW: > > > > In this example, the original definition of a leaf list has two > > default values "42" and "43: > > > > leaf-list bar { > > type int32; > > default 42; > > default 43; > > } > > > > A server can change this to the values "10" and "11" instead: > > > > deviation /base:bar { > > deviate replace { > > default 10; > > default 11; > > } > > } > > Makes sense. However, Balazs asked previously about multiple deviations > with the same target node: > ' > The replace and delete variants all need to work the same. They apply to all the default-stmts. leaf-list foo { type int32; default 10; default 20; } > https://www.ietf.org/mail-archive/web/netmod/current/msg14532.html > > It seems there has been no resolution. In this case, if default values are > replaced multiple times, which version will take effect? > > This will be implementation-specific. module dev1: deviation /foo { deviate replace { default 30; } } module dev2: deviation /foo { deviate replace { default 40; } } If first one wins or last one wins, then it depends on the order that the deviations are loaded and processed by the parser. Which version of /foo is really in use? leaf-list foo { type int32; default 30; } leaf-list foo { type int32; default 40; } This follows the requirement that the statement be valid at the end, but it is really broken wrt/ which deviation wins. This applies to many deviations, not just default. There needs to be a rule that a deviation duplicates are not allowed. Lada > > Andy > > > > > > Also, change the grammar: > > > > OLD: > > > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > [type-stmt] > > [units-stmt] > > [default-stmt] > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > "}") stmtsep > > > > NEW: > > > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > [type-stmt] > > [units-stmt] > > *must-stmt > > *unique-stmt > > *default-stmt > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > "}") stmtsep > > > > > > > > > > > >> Is it intentional that the ABNF for deviate-delete-stmt leaves out > >> config, mandatory, max-elements, and min-elements? > >> I understand why "type" cannot be removed. > > > > I don't really remember, but I can see that if you want to "delete" > > min-elements you can replace it and set it to 0. > > > >> IMO the rest of the statements should be removable. > > > >> Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. > >> This section should make it clear a leaf has only 1 default > >> and the 0..n refers to leaf-list only. > > > > In general, the result after applying deviations must be valid - e.g., > > you cannot deviate "foo" as the default for an int32 leaf. > > > >> It should also be clear that the "deviate add default" for a leaf-list > >> is YANG statement order-dependent. > >> > >> Not as obvious -- a config=false leaf-list can have duplicate default > >> values. > >> The deviate-stmt has no way to specify which 1 to delete or replace > >> if there are duplicates. > > > > Unless replace will replace *all*, as suggested above. > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b3441dacdd9070530d83a19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 19, 2016 at 2:21 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 19 Apr 2016, at 10:50, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Andy Bierman <andy@yumaworks.= com> wrote:
>> Hi,
>>
>> The ABNF for "default" is wrong in the deviate-*-stmt (a= dd, replace, delete)
>> Is says [default-stmt] but it should be *default-stmt
>
> Thanks, fixed.
>
> But for deviate-replace, it is not clear what the correct answer is. >
> This is pretty clear:
>
>=C2=A0 leaf foo {
>=C2=A0 =C2=A0 type int32;
>=C2=A0 =C2=A0 default 42;
>=C2=A0 }
>
>=C2=A0 deviation /foo {
>=C2=A0 =C2=A0 deviate replace {
>=C2=A0 =C2=A0 =C2=A0 default 10;
>=C2=A0 =C2=A0 }
>=C2=A0 }
>
> But what about this:
>
>=C2=A0 leaf-list bar {
>=C2=A0 =C2=A0 type int32;
>=C2=A0 =C2=A0 default 42;
>=C2=A0 =C2=A0 default 43;
>=C2=A0 }
>
>=C2=A0 deviation /bar {
>=C2=A0 =C2=A0 deviate replace {
>=C2=A0 =C2=A0 =C2=A0 default 10;
>=C2=A0 =C2=A0 =C2=A0 default 11;
>=C2=A0 =C2=A0 }
>=C2=A0 }
>
> Are all defaults changed?
>
> Compare with must and unique - they can not be replaced currently.
>
> In order to resolve this we probably need more text as well :(
>
>
> OLD:
>
>=C2=A0 The argument "replace" replaces properties of the targ= et node.=C2=A0 The
>=C2=A0 properties to replace are identified by substatements to the
>=C2=A0 "deviate" statement.=C2=A0 The properties to replace M= UST exist in the
>=C2=A0 target node.
>
>
> NEW:
>
>=C2=A0 The argument "replace" replaces properties of the targ= et node.=C2=A0 The
>=C2=A0 properties to replace are identified by substatements to the
>=C2=A0 "deviate" statement.=C2=A0 The properties to replace M= UST exist in the
>=C2=A0 target node.=C2=A0 If multiple properties exist in the target no= de, all
>=C2=A0 of them are replaced with the new properties defined in the
>=C2=A0 substatements to the deviate statement.
>
> + add an example to the section "Usage examples":
>
> NEW:
>
>=C2=A0 In this example, the original definition of a leaf list has two<= br> >=C2=A0 default values "42" and "43:
>
>=C2=A0 =C2=A0 leaf-list bar {
>=C2=A0 =C2=A0 =C2=A0 type int32;
>=C2=A0 =C2=A0 =C2=A0 default 42;
>=C2=A0 =C2=A0 =C2=A0 default 43;
>=C2=A0 =C2=A0 }
>
>=C2=A0 A server can change this to the values "10" and "= 11" instead:
>
>=C2=A0 =C2=A0 deviation /base:bar {
>=C2=A0 =C2=A0 =C2=A0 deviate replace {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default 10;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default 11;
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }

Makes sense. However, Balazs asked previously about multiple deviations wit= h the same target node:
'



The= replace and delete variants all need to work the same.
They appl= y to all the default-stmts.

=C2=A0 =C2=A0leaf-list= foo {=C2=A0
=C2=A0 =C2=A0 =C2=A0 type int32;
=C2=A0 = =C2=A0 =C2=A0 default 10;
=C2=A0 =C2=A0 =C2=A0 default 20;
<= div>=C2=A0 =C2=A0}


=C2=A0
=
https://www.ietf.org/mail-archive/= web/netmod/current/msg14532.html

It seems there has been no resolution. In this case, if default values are = replaced multiple times, which version will take effect?



This will be implementa= tion-specific.
=C2=A0


mod= ule =C2=A0dev1:

=C2=A0 =C2=A0deviation /foo {
=C2=A0 =C2=A0 =C2=A0 deviate replace {
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 default 30;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}



module =C2=A0dev2:

=C2=A0 =C2=A0deviation /foo {<= /div>
=C2=A0 =C2=A0 =C2=A0 deviate replace {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 default 40;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

If first one wins or l= ast one wins, then it depends on the order that
the deviations ar= e loaded and processed by the parser.

Which versio= n of /foo is really in use?

=C2=A0=C2=A0leaf-= list foo {=C2=A0
=C2=A0 =C2=A0 =C2=A0 type int32;
=C2= =A0 =C2=A0 =C2=A0 default 30;
=C2=A0 =C2=A0}

=
=C2=A0=C2=A0leaf-list foo {=C2=A0
=C2=A0 =C2=A0 = =C2=A0 type int32;
=C2=A0 =C2=A0 =C2=A0 default 40;
=C2= =A0 =C2=A0}


This follows the = requirement that the statement be valid at the end,
but it is rea= lly broken wrt/ which deviation wins.=C2=A0 This applies to
many = deviations, not just default.

There needs to be a = rule that a deviation duplicates are not allowed.

=
Lada


Andy
=C2=A0
>
>
> Also, change the grammar:
>
> OLD:
>
> deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str optse= p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (";" /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"{" stmtsep
>=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;; these stmts can appear in any order
>=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[type-stmt]
>=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[units-stmt]
>=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[default-stmt]
>=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[config-stmt]
>=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[mandatory-stmt]
>=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[min-elements-stmt]
>=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[max-elements-stmt]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"}") stmtsep
>
> NEW:
>
> deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str optse= p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (";" /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"{" stmtsep
>=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;; these stmts can appear in any order
>=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[type-stmt]
>=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[units-stmt]
>=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*must-stmt
>=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*unique-stmt
>=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*default-stmt
>=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[config-stmt]
>=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[mandatory-stmt]
>=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[min-elements-stmt]
>=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[max-elements-stmt]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"}") stmtsep
>
>
>
>
>
>> Is it intentional that the ABNF for deviate-delete-stmt leaves out=
>> config, mandatory, max-elements, and min-elements?
>> I understand why "type" cannot be removed.
>
> I don't really remember, but I can see that if you want to "d= elete"
> min-elements you can replace it and set it to 0.
>
>> IMO the rest of the statements should be removable.
>
>> Sec. 7.20.3.2 does not mention the restrictions indicated in the A= BNF.
>> This section should make it clear a leaf has only 1 default
>> and the 0..n refers to leaf-list only.
>
> In general, the result after applying deviations must be valid - e.g.,=
> you cannot deviate "foo" as the default for an int32 leaf. >
>> It should also be clear that the "deviate add default" f= or a leaf-list
>> is YANG statement order-dependent.
>>
>> Not as obvious -- a config=3Dfalse leaf-list can have duplicate de= fault
>> values.
>> The deviate-stmt has no way to specify which 1 to delete or replac= e
>> if there are duplicates.
>
> Unless replace will replace *all*, as suggested above.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--047d7b3441dacdd9070530d83a19-- From nobody Tue Apr 19 08:46:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE5612E11A for ; Tue, 19 Apr 2016 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QKtnnmvOFjy for ; Tue, 19 Apr 2016 08:46:28 -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 3C83912E0A2 for ; Tue, 19 Apr 2016 08:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27684; q=dns/txt; s=iport; t=1461080787; x=1462290387; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=ANeMIgeB7r9Db2xK3th3tZpeP0BsOD5ihum2iK8TY2s=; b=gdFFdcvOcaWmoorZopPK6jsdv7FHoiDX8vaDO7S4FLgYspsTDXfZnFZf uk/CaEAXmjBCNc7NeqmJcTk9Qnhzq2aYVlsm/pwY9ypnlPsDVw39n+fOW oAZzD8ISKko6YjkqpguJcr8R20Z868klH2PJoDEmfhs9bOCKf5+UtTRoL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvBQCHUhZX/xbLJq1VCYQLA3QGsiaJT?= =?us-ascii?q?x2CQYMwAoIOAQEBAQEBZieEQgEBBCNVESwWCwICCQMCAQIBRQYNCAEBBYggCQW?= =?us-ascii?q?reZF9AQEBAQEBAQEBAQEBAQEBAQEBAQEWhiGIYRGDGIJWBYd0XYUChUuEcIV7g?= =?us-ascii?q?nSFI4FmToQAgwYjhTOHYodJYoNqOjABAQEBh1JSawEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,506,1454976000"; d="scan'208,217";a="635255041" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2016 15:46:02 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3JFk1Ej009075 for ; Tue, 19 Apr 2016 15:46:01 GMT References: <56D5B319.90703@cisco.com> From: Benoit Claise To: NETMOD Working Group X-Forwarded-Message-Id: <56D5B319.90703@cisco.com> Message-ID: <571652B4.6000005@cisco.com> Date: Tue, 19 Apr 2016 17:45:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D5B319.90703@cisco.com> Content-Type: multipart/alternative; boundary="------------010405050304000907010605" Archived-At: Subject: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:46:30 -0000 This is a multi-part message in MIME format. --------------010405050304000907010605 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is part 1 of my AD review. I found this useful: http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt - Do we want to mention RESTCONF in the abstract? From the new charter: The NETMOD working group has defined the data modeling language YANG, which can be used to specify network management data models that are transported over such protocols as NETCONF and RESTCONF. OLD: YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols like the Network Configuration Protocol (NETCONF). NEW: YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols transported over such protocols as Network Configuration Protocol (NETCONF) and RESTCONF. This document specifies the YANG mappings to NETCONF. - Section 1.1 Can we want to stress the backwards incompatible changes from YANG version 1 in a specific paragraph? I see o Changed the rules for the interpretation of escaped characters in double quoted strings. This is an backwards incompatible change from YANG version 1. A module that uses a character sequence that is now illegal must change the string to match the new rules. See Section 6.1.3 for details. o An unquoted string cannot contain any single or double quote characters. This is an backwards incompatible change from YANG version 1. There is section 12, but this is not exactly that. Have we made an analysis of the 38 RFC-produced YANG modules? Any facing issues with 1.1 compilation? - Section 1.1 Since this document introduces the NETCONF mapping, the protocol change must be included in section 1.1 Example: no NETCONF capability exchange in YANG 1.1, we use exclusively the YANG library Any other ones? - Section 3 o anydata: A data node that can contain an unknown set of nodes that can be modelled by YANG. NEW o anydata: A data node that can contain an unknown set of nodes that can be modelled by YANG, except anyxml, but for which the data model is not known at module design time. - Terminology: The following terms are defined in [RFC6241 ]: ... o configuration datastore: a configuration datastore is an instantiated data tree with configuration data o datastore: an instantiated data tree RFC6241 has different definition for "configuration datastore" and "datastore". I would just provide the pointer to the RFC 6241 definitions. If you intend to provide an adapted definition for the YANG mappings, then you should say so. - Section 4.1 YANG models can describe constraints to be enforced on the data, restricting the appearance or value of nodes based on the presence or value of other nodes in the hierarchy. I was looking for an example of appearance. NEW? YANG models can describe constraints to be enforced on the data, restricting the appearance (for example, with the "when" statement) or value of nodes based on the presence or value of other nodes in the hierarchy. - section 4.2.2.3, Container Nodes A container is used to group related nodes in a subtree. A container has only child nodes and no value. A container may contain any number of child nodes of any type (leafs, lists, containers, leaf- lists, and actions). And notification, right? This should be added container-stmt = container-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [when-stmt] *if-feature-stmt *must-stmt [presence-stmt ] [config-stmt] [status-stmt] [description-stmt] [reference-stmt] *(typedef-stmt / grouping-stmt) *data-def-stmt *action-stmt *notification-stmt "}") stmtsep - Examples I guess that no examples are supposed to compile, right? Please add a sentence saying so. When Andy's proposal will be ready (TAG: EXAMPLE-BEGINS => the YANG example compiles, NO TAG: => no supposed to compile), this document will already be compliant. - Section 4.2.4 +---------------------+-------------------------------------+ | Name | Description | +---------------------+-------------------------------------+ | binary | Any binary data | | bits | A set of bits or flags | | boolean | "true" or "false" | | decimal64 | 64-bit signed decimal number | | empty | A leaf that does not have any value | | enumeration | Enumerated strings | | identityref | A reference to an abstract identity | | instance-identifier | References a data tree node | Editorial: What the difference between: A reference or references? Be consistent - Section4.2.7 . Choices To be consistent with When a node from one case is created in the data tree, all nodes from all other cases are implicitly deleted. This text in section 7.9 should be updated. OLD: Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If a request creates a node from a case, the server will delete any existing nodes that are defined in other cases inside the choice. NEW: Since only one of the choice's cases can be valid at any time_in the data tree_, the creation of a node from one case implicitly deletes all nodes from all other cases. If a request creates a node from a case, the server will delete any existing nodes that are defined in other cases inside the choice. - Section 4.2.9 example-fw-2.3 Editorial: Alignment - Editorial: is there a logic in the numbering? ], and it MUST set the leaf "conformance-type" to "import" for this module. You should say a few words about it in section 4. Alternatively, the content in 5.6.5 should come before 5.6.4 - Some statements in the ABNF section contains links. Intended? Talking with Martin, he submitted only the .txt version. So it seems that the issues resides in the ietf submission tool chain. To be solved during AUTH48, I guess. Example: container-stmt = container-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [when-stmt] *if-feature-stmt *must-stmt [presence-stmt ] ... refine-stmt = refine-keyword sep refine-arg-str optsep "{" stmtsep ;; these stmts can appear in any order *if-feature-stmt *must-stmt [presence-stmt] [default-stmt] [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt ] [description-stmt] [reference-stmt] "}" stmtsep Regards, Benoit --------------010405050304000907010605 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Here is part 1 of my AD review.

I found this useful: http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt
- Do we want to mention RESTCONF in the abstract? From the new charter:
The NETMOD working group has defined the data modeling language
YANG, which can be used to specify network management data models that are transported over such protocols as NETCONF and RESTCONF. 
OLD:

   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols like the Network Configuration Protocol
   (NETCONF).

NEW:

   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols transported over such protocols as Network 
   Configuration Protocol (NETCONF) and RESTCONF. This document specifies 
   the YANG mappings to NETCONF.


- Section 1.1
Can we want to stress the backwards incompatible changes from YANG version 1 in a specific paragraph?
I see 
   o  Changed the rules for the interpretation of escaped characters in
      double quoted strings.  This is an backwards incompatible change
      from YANG version 1.  A module that uses a character sequence that
      is now illegal must change the string to match the new rules.  See
      Section 6.1.3 for details.

   o  An unquoted string cannot contain any single or double quote
      characters.  This is an backwards incompatible change from YANG
      version 1.


There is section 12, but this is not exactly that.
Have we made an analysis of the 38 RFC-produced YANG modules? Any facing issues with 1.1 compilation?

- Section 1.1
Since this document introduces the NETCONF mapping, the protocol change must be included in section 1.1
Example: no NETCONF capability exchange in YANG 1.1, we use exclusively the YANG library
Any other ones?
 
- Section 3
   o  anydata: A data node that can contain an unknown set of nodes that
      can be modelled by YANG.

NEW

   o  anydata: A data node that can contain an unknown set of nodes that
      can be modelled by YANG, except anyxml, but for which the data
      model is not known at module design time.

- Terminology:
 The following terms are defined in [RFC6241]:

   ...

   o  configuration datastore: a configuration datastore is an
      instantiated data tree with configuration data

   o  datastore: an instantiated data tree

RFC6241 has different definition for "configuration datastore" and "datastore".
I would just provide the pointer to the RFC 6241 definitions.
If you intend to provide an adapted definition for the YANG mappings, then you should say so.


- Section 4.1 

   YANG models can describe constraints to be enforced on the data,
   restricting the appearance or value of nodes based on the presence or
   value of other nodes in the hierarchy.

I was looking for an example of appearance.
NEW?
   YANG models can describe constraints to be enforced on the data,
   restricting the appearance (for example, with the "when" statement)
   or value of nodes based on the presence or value of other nodes in 
   the hierarchy.

- section 4.2.2.3, Container Nodes

   A container is used to group related nodes in a subtree.  A container
   has only child nodes and no value.  A container may contain any
   number of child nodes of any type (leafs, lists, containers, leaf-
   lists, and actions).
 
And notification, right? This should be added
   container-stmt      = container-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt]
                              *if-feature-stmt
                              *must-stmt
                              [presence-stmt]
                              [config-stmt]
                              [status-stmt]
                              [description-stmt]
                              [reference-stmt]
                              *(typedef-stmt / grouping-stmt)
                              *data-def-stmt
                              *action-stmt
                              *notification-stmt
                          "}") stmtsep

- Examples
I guess that no examples are supposed to compile, right?
Please add a sentence saying so. 
When Andy's proposal will be ready (TAG: EXAMPLE-BEGINS => the YANG example compiles, NO TAG: => no supposed to compile), this document will already be compliant.

- Section 4.2.4

       +---------------------+-------------------------------------+
       | Name                | Description                         |
       +---------------------+-------------------------------------+
       | binary              | Any binary data                     |
       | bits                | A set of bits or flags              |
       | boolean             | "true" or "false"                   |
       | decimal64           | 64-bit signed decimal number        |
       | empty               | A leaf that does not have any value |
       | enumeration         | Enumerated strings                  |
       | identityref         | A reference to an abstract identity |
       | instance-identifier | References a data tree node         |

Editorial: What the difference between: A reference or references? Be consistent

- Section 4.2.7.  Choices

To be consistent with

   When a node from one case is created in the data tree, all nodes from
   all other cases are implicitly deleted. 


This text in section 7.9 should be updated.
OLD:
   Since only one of the choice's cases can be valid at any time, the
   creation of a node from one case implicitly deletes all nodes from
   all other cases.  If a request creates a node from a case, the server
   will delete any existing nodes that are defined in other cases inside
   the choice.

NEW:
   Since only one of the choice's cases can be valid at any time in the data tree, the
   creation of a node from one case implicitly deletes all nodes from
   all other cases.  If a request creates a node from a case, the server
   will delete any existing nodes that are defined in other cases inside
   the choice.


- Section 4.2.9 
     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <activate-software-image xmlns="http://example.com/system">
         <image-name>example-fw-2.3</image-name>
      </activate-software-image>
     </rpc>

Editorial: Alignment



- Editorial: is there a logic in the numbering?
<rpc message-id="101"
<rpc message-id="102"

- section 4.2.9

   Operations can also be tied to a
   data node.  Such operations are defined with the "action" statement.

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

And I see in section 7.15:
   The "action" statement is used to define an operation connected to a
   specific container or list data node. 


I believe it should be clarified in 4.2.9
NEW:
   Operations can also be tied to a
   container or list data node.  Such operations are defined with the "action" statement.


- Section 5.1
Editorial
OLD:
   o  A module or submodule belonging to that module can reference
      definitions in the module and all submodules included by the
      module.

NEW?
   o  A module, or submodule belonging to that module, can reference
      definitions in the module and all submodules included by that
      module.



- The following examples (as far as my quick check goes) are the only one that misses "yang-version 1.1"
module example-augment {
  namespace "urn:example:augment";
  prefix mymod;
  import ietf-interfaces {
    prefix if;
  }

    module example-a {
       namespace urn:example:a;
       prefix a;

- Section 5.6.4
   If a server implements a module A that imports a module B, and A uses
   any node from B in an "augment" or "path" statement that the server
   supports, then the server MUST implement a revision of module B that
   has these nodes defined.  This is regardless of if module B is
   imported by revision or not.

"imported by revision or not" I'm, confused because I read the document in sequence.
>From 5.1 and 5.1.1, it doesn't look like we have two options (import by revision or not)
And the example shows the two possibilities:
       import b {
         revision-date 2015-01-01;
       }
       import c;

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

You should write a sentence or two (imported by revision or not) about in section 5.1 or 5.1.1

- section 5.6.4
   A server MUST NOT implement more than one revision of a module.

You should add that the server may contain more than one version for import reasons. 
This would be in line with https://tools.ietf.org/html/draft-ietf-netconf-yang-library-05

   This mandatory list contains one entry for each YANG data model
   module supported by the server.  There MUST be an entry in this list
   for each revision of each YANG module that is used by the server.  It
   is possible for multiple revisions of the same module to be imported,
   in addition to an entry for the revision that is implemented by the
   server.

- section 5.6.4
ietf-yang-library comes out of the blue in section 5.6.4

   If a server implements a module A that imports a module C without
   specifying the revision date of module C, and the server does not
   implement C (e.g., if C only defines some typedefs), the server MUST
   list module C in the "/modules-state/module" list from
   "ietf-yang-library" [I-D.ietf-netconf-yang-library], and it MUST set
   the leaf "conformance-type" to "import" for this module.

You should say a few words about it in section 4. 
Alternatively, the content in 5.6.5 should come before 5.6.4

- Some statements in the ABNF section contains links. Intended? Talking with Martin, he submitted only the .txt version.
So it seems that the issues resides in the ietf submission tool chain. To be solved during AUTH48, I guess.   

Example:

   container-stmt      = container-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt]
                              *if-feature-stmt
                              *must-stmt
                              [presence-stmt]
                              ...


   refine-stmt         = refine-keyword sep refine-arg-str optsep
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *if-feature-stmt
                              *must-stmt
                              [presence-stmt]
                              [default-stmt]
                              [config-stmt]
                              [mandatory-stmt]
                              [min-elements-stmt]
                              [max-elements-stmt]
                              [description-stmt]
                              [reference-stmt]
                            "}" stmtsep
Regards, Benoit

--------------010405050304000907010605-- From nobody Tue Apr 19 09:24:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB21612DC75 for ; Tue, 19 Apr 2016 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwoXPhcZgiZE for ; Tue, 19 Apr 2016 09:24:14 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0688.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::688]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D2412DB22 for ; Tue, 19 Apr 2016 09:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FHxaanEfNNJjpl4Nqnf4IdrzJPOTecKrK6X8A8dqnMQ=; b=gckMM2qf9TEM3c5HHNzm/kSLuC2VlqEvj2XYJKJHEGQe55u9uJQnfcr8lomloE4UcMQsbDQzTrrAvMCogZGm0q1HtK8iJqZQrE34grm7rx2P7KRFyEtAoaeUSxYmIhzKPPhDfbXYri5B1fOYcJYZ7gwk7XzYYXgzQGF6oYdx39E= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) with Microsoft SMTP Server (TLS) id 15.1.466.19; Tue, 19 Apr 2016 16:23:52 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0466.022; Tue, 19 Apr 2016 16:23:52 +0000 From: "Ing-Wher (Helen) Chen" To: Juergen Schoenwaelder Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyAAEV4yAAC5VLVA Date: Tue, 19 Apr 2016 16:23:51 +0000 Message-ID: References: <20160415152317.GB95324@elstar.local> <20160415234236.GC95761@elstar.local> In-Reply-To: <20160415234236.GC95761@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: ab8194a9-b10a-48d1-35ea-08d3686efed0 x-microsoft-exchange-diagnostics: 1; DB5PR06MB0950; 5:nRj0neeI/0N/EUgDccK/b3IaeyD8nAZC7KVspCq7GG/ecbHbBMckdcbKTHQAfoLEvpQQF0w3y0r7MJ0ZSaFdv0Xn4q8ldsTr22ZEBxMoUpcCryXwnnlVcbPnK8BFOtEx4CoHyN/14UgmVA5y5O2wMsPw8JneWiNqP9JsLZlSmfhuQecNOehgHZ0wsIH68WFh; 24:IyPQIJF9U5gF/ip8OWeNl4NGtjwxsnZjMJMucXk+2WlpxhCR63fjvshd/ZNdVjF5Gf1b5OoVhm44YeglsEhgmLvKBfbub6GtMPj8RRMvCmg=; 7:ER0DfdM5EX8nSFC9wuO7vdeP/erIgCmzgeED/xhtx5gxGgUCHZGO585Hp90CEbE7LktxIKL9Gp7m7nCarNzjW/8ZddPSipmpdqrLyd4Rwlg83k1Zwm8pPDQXyXkYyHhY3+RK8lxKApnUm27oGbST0WQuVJ+ifKja45T/XXCPDZZsIS/4jj0jvBihSWYS2e5qPnZW/HIfr/ZGc1JegYZ+siXCtyTiDiQ3MFuVWCAGIro= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0950; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041046)(6043046); SRVR:DB5PR06MB0950; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0950; x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(13464003)(377454003)(3660700001)(81166005)(86362001)(5002640100001)(4326007)(2906002)(3280700002)(74316001)(10400500002)(9686002)(93886004)(2950100001)(10710500007)(7110500001)(189998001)(110136002)(2420400007)(6116002)(66066001)(586003)(5003600100002)(1096002)(33656002)(5004730100002)(15975445007)(122556002)(5008740100001)(92566002)(76176999)(15650500001)(2900100001)(19580395003)(102836003)(1220700001)(54356999)(50986999)(1720100001)(76576001)(11100500001)(77096005)(19580405001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0950; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2016 16:23:51.9027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0950 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 16:24:17 -0000 I'm not an expert on XML namespaces and I'm a little confused by some of the questions, so I apologize if my response below does not quite answer th= e questions. I'd like to point out that the request for "rdns" URN is not to= prevent the use of URLs. The request for "rdns" URN is to allow an enterprise to ea= sily create a URN namespace, if the enterprise happens to prefer to use URN as a YANG module namespace. I also think that the problems that arise when a YANG module uses a URN based on an enterprise's domain name are the same problems that arise when a YANG module uses a URL based on an enterprise's domain name. (Of course, this is not an excuse to fix the problems that sh= ould be fixed.) > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, April 15, 2016 7:43 PM > To: Ing-Wher (Helen) Chen > Cc: netmod@ietf.org > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models >=20 > On Fri, Apr 15, 2016 at 03:53:04PM +0000, Ing-Wher (Helen) Chen wrote: >=20 > > Section 4 of the draft > > > > documents why a URN is better than URL as a namespace. While a URL > > is globally unique, a URL is also a resource locator, providing access > > information. For an enterprise that does not wish to publish the > > access information of its YANG models, a URN is a better choice. >=20 > Continuing as devil's advocate... >=20 > The YANG specifications (both 1.0 and 1.1) has a normative reference to >=20 > https://www.w3.org/TR/2009/REC-xml-names-20091208/ >=20 > which states in section 3: >=20 > [...] The namespace name, to serve its intended purpose, SHOULD > have the characteristics of uniqueness and persistence. It is not a > goal that it be directly usable for retrieval of a schema (if any > exists). Uniform Resource Names [RFC2141] is an example of a syntax > that is designed with these goals in mind. However, it should be > noted that ordinary URLs can be managed in such a way as to achieve > these same goals. >=20 > Do we have evidence that managing ordinary URLs in such a way as to > achieve these same goals (of uniqueness and persistence) is a problem? > If so, why does this only apply to YANG modules (only one of many uses of > XML namespaces)? I found some XML namespaces that are URLs, e.g. http://www.w3.org/1999/XSL/Transform , that look like they're centrall= y managed and should have uniqueness and persistence characteristics. There are also examples of URLs that do not have a centralized authority to manag= e URLs and results in URLs not being persistence, e.g. confluence wiki pages = create URLs based on web page titles and so the wiki page URLs can change at rando= m, even though the page contents don't change. (However, confluence wiki page= s' URLs are not used as XML namespaces, and so the lack of persistence is not = an issue.) So, it seems that it's all about how URLs are managed---in particu= lar, centrally managed URLs can have uniqueness and persistence characteristics. I think that this type of centralized management might be problematic for enterprise YANG modules, which have no centralized authority. >=20 > > As required by RFC 3406, Section 3 of the draft, at the bottom of page > > 5 under > > "Identifier Persistence Considerations", addresses the question of > > identifier persistence. The main concern for "identifier persistence" = is in > the case where an identifier is used for global resolution. > > Because YANG model namespaces do not provide global resolutions > > (actually YANG model namespaces are only used to uniquely identify a > > model within a device), the identifier persistence consideration is > > not as crucial. (Please see RFC 3406 top of page 13 > > for the identifier > > persistence discussion.) >=20 > I am not sure I agree that the scope of a YANG namespace is limited to a > device. There is nothing that prevents some random device to implement > some random YANG model. If the org currently owning bar.foo publishes a > module using urn:rdns:com:foo:bar as a namespace then other orgs can > implement this module as well if they think this is a good idea. I'd like to flesh out this example to illustrate what I had in mind when I = wrote that YANG model namespaces are only used to uniquely identify a model withi= n a device. Assume that device "R" currently implements/installs YANG module "ospf" from company "A" which, at time T, owns domain "bar.foo", i.e. company "A's= " "ospf" YANG module's namespace is "urn:rdns:foo:bar:ospf". At time T+delta= , company "A" gives up "bar.foo" and company B buys "bar.foo". For whatever reason, company "B" creates some other module "ospf", i.e. company "B's" new "ospf" YANG module's namespace is also assigned "urn:rdns:foo:bar:ospf"= , though this module presumably has contents different from company "A's" "ospf" YANG modules. If device "R" decides to implement module "ospf" from company "A" and module "ospf" from company "B", then there is a collision o= n this device "R". When a NETCONF client attempts to manage device "R" and u= ses "urn:rdns:foo:bar:ospf" to identify an "ospf" module, there is a problem, b= ecause device "R" doesn't know which "urn:rdns:foo:bar:ospf" the client is referri= ng to. If some other device "Q" only implements one single "ospf" module (regardle= ss of whether the "ospf" module is from company "A" or from company "B"), then the namespace "urn:rdns:foo:bar:ospf" identifies the one "ospf" module inst= alled on device "Q", and there are no ambiguities in the event that a NETCONF cli= ent attempts to reference the module identified by "urn:rdns:foo:bar:ospf" on d= evice "Q". So, the problem of non-unique YANG module namespaces only manifests within a device. >=20 > I read: >=20 > In practice, an administrator consciously installs YANG modules in > a device. Thus, in the unlikely event that there is a collision > due to changing domain names, the administrator can detect the > collision and rectify the situation by requesting that the > offending organization republish its YANG modules with the correct > "rdns" URNs. >=20 > Who is the 'administrator' that consciously installs YANG modules in a de= vice > here? Administrator of what - the namespace or the device? In case you > mean the administrator of the namespace then what happens in the case > where this role changes because some other org took over the domain > name? >=20 > If a module uses urn:rdns:com:foo:bar and I later buy the domain bar.foo > than do I get change control of the YANG module using this particular > namespace as a side effect? By "administrator", I meant the administrator of the device. Using the example I fleshed out above, where company "A" initially owns domain "bar.foo" and creates module "ospf" with namespace "urn:rdns:foo:bar:ospf", but company "B" later purchases domain "bar.foo" and also creates its own module "ospf" and gives it namespace "urn:rdns:foo:bar:ospf".=20 While it's true that allows this situation to occur, this situation only results in a problem in= the case of device "R" above, after device "R" implements both company "A's" "o= spf" module with namespace "urn:rdns:foo:bar:ospf" and company "B's" "ospf" module also with namespace "urn:rdns:foo:bar:ospf". Getting device "R" to implement both modules is not trivial. It actually requires obtaining both modules, installing them on device "R", and perhaps even upgrading device "= R's" software to handle the second module. In other words, I think that the collision resulting from non-unique namespaces on device "R" is limited wit= hin a device, therefore the solution can also be limited to the administrator d= etecting and rectifying the collision. I also think that this example holds true in= the case where an enterprise chooses to use URLs based on domain names as YANG module namespaces. >=20 > [...break...] >=20 > Taking a step back, we do have the tension between XML namespaces (that > are identified by URIs and used in the XML encoding) and 'JSON namespaces= ' > identified by module names (and used in the JSON encoding). The former is > relying on the uniqueness of a URI while the later is relying on the uniq= ueness > of the YANG module name. So from this perspective, assuming the YANG > module name is already sufficiently unique, perhaps the right thing to do= is to > simply use >=20 > urn:yang: >=20 > for all XML namespaces and to essentially get rid of the namespace > declaration in YANG (which then defaults to urn:yang:). This approach would require registering "yang" URN and also would place constraints on . These constraints might result in the same questions that we're struggling with now, with URN/URL based on domain names that can come and go. Thanks, Helen From nobody Tue Apr 19 11:23:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887C512E38F for ; Tue, 19 Apr 2016 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IybwD6tYf9de for ; Tue, 19 Apr 2016 11:22:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF09A12DC9D for ; Tue, 19 Apr 2016 11:22: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 192F0119E; Tue, 19 Apr 2016 20:22: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 XokE3Qzwq1mm; Tue, 19 Apr 2016 20:22:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 Apr 2016 20:22:54 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED4E72004A; Tue, 19 Apr 2016 20:22:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id szulnxC_p2jt; Tue, 19 Apr 2016 20:22: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 BF74A20047; Tue, 19 Apr 2016 20:22:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 83C673AA8476; Tue, 19 Apr 2016 20:22:51 +0200 (CEST) Date: Tue, 19 Apr 2016 20:22:50 +0200 From: Juergen Schoenwaelder To: "Ing-Wher (Helen) Chen" Message-ID: <20160419182250.GA3771@elstar.local> Mail-Followup-To: "Ing-Wher (Helen) Chen" , "netmod@ietf.org" References: <20160415152317.GB95324@elstar.local> <20160415234236.GC95761@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 18:22:59 -0000 On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote: > I'm not an expert on XML namespaces and I'm a little confused by some of > the questions, so I apologize if my response below does not quite answer the > questions. I'd like to point out that the request for "rdns" URN is not to prevent > the use of URLs. The request for "rdns" URN is to allow an enterprise to easily > create a URN namespace, if the enterprise happens to prefer to use URN as a > YANG module namespace. I also think that the problems that arise when a > YANG module uses a URN based on an enterprise's domain name are the same > problems that arise when a YANG module uses a URL based on an enterprise's > domain name. (Of course, this is not an excuse to fix the problems that should > be fixed.) You write "happen to prefer to use URN" - why? > > I am not sure I agree that the scope of a YANG namespace is limited to a > > device. There is nothing that prevents some random device to implement > > some random YANG model. If the org currently owning bar.foo publishes a > > module using urn:rdns:com:foo:bar as a namespace then other orgs can > > implement this module as well if they think this is a good idea. > > I'd like to flesh out this example to illustrate what I had in mind when I wrote > that YANG model namespaces are only used to uniquely identify a model within > a device. [...] I think a management application likely has a problem is a URI value can mean different things on different devices unless it always fetches the model from the devices. Anyway, this problem exists for URNs that contain domain names in the same way as for URLs that contain domain names. In practice, I think this scenario is rare - it is likely more common that people rename modules and namespaces, e.g. when a company acquires a different company. This is strictly speaking not a problem since YANG treats such a renamed module as a new module. > > [...break...] > > > > Taking a step back, we do have the tension between XML namespaces (that > > are identified by URIs and used in the XML encoding) and 'JSON namespaces' > > identified by module names (and used in the JSON encoding). The former is > > relying on the uniqueness of a URI while the later is relying on the uniqueness > > of the YANG module name. So from this perspective, assuming the YANG > > module name is already sufficiently unique, perhaps the right thing to do is to > > simply use > > > > urn:yang: > > > > for all XML namespaces and to essentially get rid of the namespace > > declaration in YANG (which then defaults to urn:yang:). > > This approach would require registering "yang" URN and also would place > constraints on . These constraints might result in the same > questions that we're struggling with now, with URN/URL based on domain > names that can come and go. The namespace definition is used by the XML encoding, the JSON encoding uses the YANG module name to identify a 'namespace'. The module name generally is assumed to be unique since tools (e.g., YANG compilers) import via module names. A urn:yang: would have the advantage to integrate things. In fact, the namespace statement in YANG could become optional, if one does not define a namespace, then the default namespace is urn:yang: (and this would enable round-trip conversion of namespaces between XML and JSON encoding, something I always found a valuable property.) Anyway, it would be good to hear opinions of other people. /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 Apr 19 12:37:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB11712E821 for ; Tue, 19 Apr 2016 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ7NC21JWj-D for ; Tue, 19 Apr 2016 12:37: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 1BF0412E635 for ; Tue, 19 Apr 2016 12:37:06 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id D6A1E1AE0383; Tue, 19 Apr 2016 21:37:03 +0200 (CEST) Date: Tue, 19 Apr 2016 21:37:03 +0200 (CEST) Message-Id: <20160419.213703.1223710857303113407.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160419182250.GA3771@elstar.local> References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: ichen@kuatrotech.com, netmod@ietf.org Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 19:37:08 -0000 Juergen Schoenwaelder wrote: > On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote: > > I'm not an expert on XML namespaces and I'm a little confused by some of > > the questions, so I apologize if my response below does not quite answer the > > questions. I'd like to point out that the request for "rdns" URN is not to prevent > > the use of URLs. The request for "rdns" URN is to allow an enterprise to easily > > create a URN namespace, if the enterprise happens to prefer to use URN as a > > YANG module namespace. I also think that the problems that arise when a > > YANG module uses a URN based on an enterprise's domain name are the same > > problems that arise when a YANG module uses a URL based on an enterprise's > > domain name. (Of course, this is not an excuse to fix the problems that should > > be fixed.) > > You write "happen to prefer to use URN" - why? > > > > I am not sure I agree that the scope of a YANG namespace is limited to a > > > device. There is nothing that prevents some random device to implement > > > some random YANG model. If the org currently owning bar.foo publishes a > > > module using urn:rdns:com:foo:bar as a namespace then other orgs can > > > implement this module as well if they think this is a good idea. > > > > I'd like to flesh out this example to illustrate what I had in mind when I wrote > > that YANG model namespaces are only used to uniquely identify a model within > > a device. > > [...] > > I think a management application likely has a problem is a URI value > can mean different things on different devices unless it always > fetches the model from the devices. Anyway, this problem exists for > URNs that contain domain names in the same way as for URLs that > contain domain names. In practice, I think this scenario is rare - it > is likely more common that people rename modules and namespaces, e.g. > when a company acquires a different company. This is strictly speaking > not a problem since YANG treats such a renamed module as a new module. > > > > [...break...] > > > > > > Taking a step back, we do have the tension between XML namespaces (that > > > are identified by URIs and used in the XML encoding) and 'JSON namespaces' > > > identified by module names (and used in the JSON encoding). The former is > > > relying on the uniqueness of a URI while the later is relying on the uniqueness > > > of the YANG module name. So from this perspective, assuming the YANG > > > module name is already sufficiently unique, perhaps the right thing to do is to > > > simply use > > > > > > urn:yang: > > > > > > for all XML namespaces and to essentially get rid of the namespace > > > declaration in YANG (which then defaults to urn:yang:). > > > > This approach would require registering "yang" URN and also would place > > constraints on . These constraints might result in the same > > questions that we're struggling with now, with URN/URL based on domain > > names that can come and go. > > The namespace definition is used by the XML encoding, the JSON > encoding uses the YANG module name to identify a 'namespace'. The > module name generally is assumed to be unique since tools (e.g., YANG > compilers) import via module names. A urn:yang: would have > the advantage to integrate things. In fact, the namespace statement in > YANG could become optional, if one does not define a namespace, then > the default namespace is urn:yang: (and this would enable > round-trip conversion of namespaces between XML and JSON encoding, > something I always found a valuable property.) > > Anyway, it would be good to hear opinions of other people. I can see the value in a urn:rdns: URN. Using 'http://' for YANG module namespace is a bit weird. Why not 'https://'? Or 'gopher://'? But I like urn:yang: even more - and if we had this, we wouldn't have to use the "namespace" statement. Unfortunately that would require a new version of YANG... /martin From nobody Tue Apr 19 13:51:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6988D12E65D for ; Tue, 19 Apr 2016 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLqn4eLkLrV4 for ; Tue, 19 Apr 2016 13:51:34 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA3112E65C for ; Tue, 19 Apr 2016 13:51:34 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g184so28600045lfb.3 for ; Tue, 19 Apr 2016 13:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jJAJVsC39OK57eVGTsWZIoi6YlGOI1F3XtzdDBjaTn4=; b=X0IUAAwC9yJPu71GWozk96Pj0l6yZ8rt+f1Agb+OAQBEKqiEsZOkbDccOHN69nijc7 yzHLKzVNsNb6KMnHY2MdjIjq+/QWWGkJmVr+PYjyKpqHxWy3hEwju0A0/CxlZb9SO4bM i/oA3EpmoGT1JdOF8V4Jr/dFJEftHZIELKMf3CxKaHU3X148M/ksclGlhvEfLFGizvTM siclme6/qaRrFVTtUGm/phoS6gVOl8Ff94r7DiW3kYNPjO0wRzvg54DAiJClOf57CCbh aTqe9V5MqsIYUUX97oMgIJ8vYu37dJ95PubOkkZ+9qxlFnv1T9muRPGXxUJ+0kM8wMT3 s9Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jJAJVsC39OK57eVGTsWZIoi6YlGOI1F3XtzdDBjaTn4=; b=CxH1JfELtIBe7j9uRVtZ+pwy0hj3VhrUjlryQtZ8QV550jf5eQjTOWnddFoR2fBbis b+KYPc3UI8Si96Lt2hxvfVgykPJKnmUqbLmedwByvDAxJEup83zS4Mtd4uxOhtlQO05b F15k82i5JyIcjAQ1XW1TBjksG2EnuQllTOD5d+jSqb8NJC/SmwEjun6KAFSxznwYsrrV 5YIsM+Y99WEwLOkwFr8F254krGDPuZBhyXLO0pZHiI2MVe//cH2EDv39B9d84cM8I3Of a0TIIPws847dqniwiDFkOXvBKEZQAg4SzDu/634bC+u/abtFmparHN38SDPXR+hfrIPs djkg== X-Gm-Message-State: AOPr4FWUayRbCp0wqM1h4yC8i07jP4RBteO8RRdai92m/NYCdKSpo52BNW0vlXr8oa5CEk9Jils6+uLxLfR4Wg== MIME-Version: 1.0 X-Received: by 10.25.214.83 with SMTP id n80mr2225569lfg.54.1461099092134; Tue, 19 Apr 2016 13:51:32 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Tue, 19 Apr 2016 13:51:32 -0700 (PDT) In-Reply-To: <20160419.213703.1223710857303113407.mbj@tail-f.com> References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> <20160419.213703.1223710857303113407.mbj@tail-f.com> Date: Tue, 19 Apr 2016 13:51:32 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114125d65e5c250530dca49d Archived-At: Cc: ichen@kuatrotech.com, "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:51:37 -0000 --001a114125d65e5c250530dca49d Content-Type: text/plain; charset=UTF-8 On Tue, Apr 19, 2016 at 12:37 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote: > > > I'm not an expert on XML namespaces and I'm a little confused by some > of > > > the questions, so I apologize if my response below does not quite > answer the > > > questions. I'd like to point out that the request for "rdns" URN is > not to prevent > > > the use of URLs. The request for "rdns" URN is to allow an enterprise > to easily > > > create a URN namespace, if the enterprise happens to prefer to use URN > as a > > > YANG module namespace. I also think that the problems that arise when > a > > > YANG module uses a URN based on an enterprise's domain name are the > same > > > problems that arise when a YANG module uses a URL based on an > enterprise's > > > domain name. (Of course, this is not an excuse to fix the problems > that should > > > be fixed.) > > > > You write "happen to prefer to use URN" - why? > > > > > > I am not sure I agree that the scope of a YANG namespace is limited > to a > > > > device. There is nothing that prevents some random device to > implement > > > > some random YANG model. If the org currently owning bar.foo > publishes a > > > > module using urn:rdns:com:foo:bar as a namespace then other orgs can > > > > implement this module as well if they think this is a good idea. > > > > > > I'd like to flesh out this example to illustrate what I had in mind > when I wrote > > > that YANG model namespaces are only used to uniquely identify a model > within > > > a device. > > > > [...] > > > > I think a management application likely has a problem is a URI value > > can mean different things on different devices unless it always > > fetches the model from the devices. Anyway, this problem exists for > > URNs that contain domain names in the same way as for URLs that > > contain domain names. In practice, I think this scenario is rare - it > > is likely more common that people rename modules and namespaces, e.g. > > when a company acquires a different company. This is strictly speaking > > not a problem since YANG treats such a renamed module as a new module. > > > > > > [...break...] > > > > > > > > Taking a step back, we do have the tension between XML namespaces > (that > > > > are identified by URIs and used in the XML encoding) and 'JSON > namespaces' > > > > identified by module names (and used in the JSON encoding). The > former is > > > > relying on the uniqueness of a URI while the later is relying on the > uniqueness > > > > of the YANG module name. So from this perspective, assuming the YANG > > > > module name is already sufficiently unique, perhaps the right thing > to do is to > > > > simply use > > > > > > > > urn:yang: > > > > > > > > for all XML namespaces and to essentially get rid of the namespace > > > > declaration in YANG (which then defaults to urn:yang:). > > > > > > This approach would require registering "yang" URN and also would place > > > constraints on . These constraints might result in the > same > > > questions that we're struggling with now, with URN/URL based on domain > > > names that can come and go. > > > > The namespace definition is used by the XML encoding, the JSON > > encoding uses the YANG module name to identify a 'namespace'. The > > module name generally is assumed to be unique since tools (e.g., YANG > > compilers) import via module names. A urn:yang: would have > > the advantage to integrate things. In fact, the namespace statement in > > YANG could become optional, if one does not define a namespace, then > > the default namespace is urn:yang: (and this would enable > > round-trip conversion of namespaces between XML and JSON encoding, > > something I always found a valuable property.) > > > > Anyway, it would be good to hear opinions of other people. > > I can see the value in a urn:rdns: URN. Using 'http://' for YANG > module namespace is a bit weird. Why not 'https://'? Or 'gopher://'? > > But I like urn:yang: even more - and if we had this, we > wouldn't have to use the "namespace" statement. Unfortunately that > would require a new version of YANG... > > > I do not think the standard mechanisms are good enough to assume YANG module names will be globally unique. The RDNS format needs to include the naming authority somehow. The namespace URI gives the author more control to make naming collisions less likely. > /martin > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114125d65e5c250530dca49d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 19, 2016 at 12:37 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
> On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote:=
> > I'm not an expert on XML namespaces and I'm a little conf= used by some of
> > the questions, so I apologize if my response below does not quite= answer the
> > questions.=C2=A0 I'd like to point out that the request for &= quot;rdns" URN is not to prevent
> > the use of URLs. The request for "rdns" URN is to allow= an enterprise to easily
> > create a URN namespace, if the enterprise happens to prefer to us= e URN as a
> > YANG module namespace.=C2=A0 I also think that the problems that = arise when a
> > YANG module uses a URN based on an enterprise's domain name a= re the same
> > problems that arise when a YANG module uses a URL based on an ent= erprise's
> > domain name.=C2=A0 (Of course, this is not an excuse to fix the p= roblems that should
> > be fixed.)
>
> You write "happen to prefer to use URN" - why?
>
> > > I am not sure I agree that the scope of a YANG namespace is = limited to a
> > > device. There is nothing that prevents some random device to= implement
> > > some random YANG model. If the org currently owning bar.foo = publishes a
> > > module using urn:rdns:com:foo:bar as a namespace then other = orgs can
> > > implement this module as well if they think this is a good i= dea.
> >
> > I'd like to flesh out this example to illustrate what I had i= n mind when I wrote
> > that YANG model namespaces are only used to uniquely identify a m= odel within
> > a device.
>
> [...]
>
> I think a management application likely has a problem is a URI value > can mean different things on different devices unless it always
> fetches the model from the devices. Anyway, this problem exists for > URNs that contain domain names in the same way as for URLs that
> contain domain names. In practice, I think this scenario is rare - it<= br> > is likely more common that people rename modules and namespaces, e.g.<= br> > when a company acquires a different company. This is strictly speaking=
> not a problem since YANG treats such a renamed module as a new module.=
>
> > > [...break...]
> > >
> > > Taking a step back, we do have the tension between XML names= paces (that
> > > are identified by URIs and used in the XML encoding) and = 9;JSON namespaces'
> > > identified by module names (and used in the JSON encoding). = The former is
> > > relying on the uniqueness of a URI while the later is relyin= g on the uniqueness
> > > of the YANG module name. So from this perspective, assuming = the YANG
> > > module name is already sufficiently unique, perhaps the righ= t thing to do is to
> > > simply use
> > >
> > >=C2=A0 =C2=A0 urn:yang:<modulename>
> > >
> > > for all XML namespaces and to essentially get rid of the nam= espace
> > > declaration in YANG (which then defaults to urn:yang:<mod= ulename>).
> >
> > This approach would require registering "yang" URN and = also would place
> > constraints on <modulename>.=C2=A0 These constraints might = result in the same
> > questions that we're struggling with now, with URN/URL based = on domain
> > names that can come and go.
>
> The namespace definition is used by the XML encoding, the JSON
> encoding uses the YANG module name to identify a 'namespace'. = The
> module name generally is assumed to be unique since tools (e.g., YANG<= br> > compilers) import via module names. A urn:yang:<modulename> woul= d have
> the advantage to integrate things. In fact, the namespace statement in=
> YANG could become optional, if one does not define a namespace, then > the default namespace is urn:yang:<modulename> (and this would e= nable
> round-trip conversion of namespaces between XML and JSON encoding,
> something I always found a valuable property.)
>
> Anyway, it would be good to hear opinions of other people.

I can see the value in a urn:rdns: URN.=C2=A0 Using 'http://' for Y= ANG
module namespace is a bit weird.=C2=A0 Why not 'https://'?=C2=A0 Or= 'gopher://'?

But I like urn:yang:<module-name> even more - and if we had this, we<= br> wouldn't have to use the "namespace" statement.=C2=A0 Unfortu= nately that
would require a new version of YANG...



I do not think the standard mechanisms= are good enough to assume
YANG module names will be globally uni= que.=C2=A0 The RDNS format
needs to include the naming authority = somehow.=C2=A0 The namespace URI
gives the author more control to= make naming collisions less likely.


=C2=A0
/martin

Andy
=C2=A0

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

--001a114125d65e5c250530dca49d-- From nobody Tue Apr 19 23:27:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369212EBCE for ; Tue, 19 Apr 2016 23:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.996 X-Spam-Level: X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4pQHpB27HE8 for ; Tue, 19 Apr 2016 23:27: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 4899B12EBCC for ; Tue, 19 Apr 2016 23:27:02 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id 34981600D7; Wed, 20 Apr 2016 08:27:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461133621; bh=C2gFgRLzDC2W6wDnlIbJSx9AclkV5yB6W9AcJKKXqmg=; h=From:Date:To; b=JNqZwckPOElATTGqyVHo6svO9GCB6iYHVywbs56sdD+gYUTIazbg/4vJ+jEyYDJ9S wegqvbSzIWsBVPu7bZ9AV8vgfkUlWeGwFRl4/R3/uWFaJbY5dxYPVv0XmYW8gR9AP+ NnN3RdV11P0HzCF2JuVrZiLdeXKBJD6dOFhCeU0g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 20 Apr 2016 08:27:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <761E34AE-0E75-4166-92B1-60970024E587@nic.cz> References: <20160419.105021.2152837727269070493.mbj@tail-f.com> <47F854AA-B2D5-470E-A1A3-60C5B5B82E95@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 06:27:06 -0000 > On 19 Apr 2016, at 17:35, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Apr 19, 2016 at 2:21 AM, Ladislav Lhotka = wrote: >=20 > > On 19 Apr 2016, at 10:50, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > >> Hi, > >> > >> The ABNF for "default" is wrong in the deviate-*-stmt (add, = replace, delete) > >> Is says [default-stmt] but it should be *default-stmt > > > > Thanks, fixed. > > > > But for deviate-replace, it is not clear what the correct answer is. > > > > This is pretty clear: > > > > leaf foo { > > type int32; > > default 42; > > } > > > > deviation /foo { > > deviate replace { > > default 10; > > } > > } > > > > But what about this: > > > > leaf-list bar { > > type int32; > > default 42; > > default 43; > > } > > > > deviation /bar { > > deviate replace { > > default 10; > > default 11; > > } > > } > > > > Are all defaults changed? > > > > Compare with must and unique - they can not be replaced currently. > > > > In order to resolve this we probably need more text as well :( > > > > > > OLD: > > > > The argument "replace" replaces properties of the target node. The > > properties to replace are identified by substatements to the > > "deviate" statement. The properties to replace MUST exist in the > > target node. > > > > > > NEW: > > > > The argument "replace" replaces properties of the target node. The > > properties to replace are identified by substatements to the > > "deviate" statement. The properties to replace MUST exist in the > > target node. If multiple properties exist in the target node, all > > of them are replaced with the new properties defined in the > > substatements to the deviate statement. > > > > + add an example to the section "Usage examples": > > > > NEW: > > > > In this example, the original definition of a leaf list has two > > default values "42" and "43: > > > > leaf-list bar { > > type int32; > > default 42; > > default 43; > > } > > > > A server can change this to the values "10" and "11" instead: > > > > deviation /base:bar { > > deviate replace { > > default 10; > > default 11; > > } > > } >=20 > Makes sense. However, Balazs asked previously about multiple = deviations with the same target node: > ' >=20 >=20 >=20 > The replace and delete variants all need to work the same. > They apply to all the default-stmts. >=20 > leaf-list foo {=20 > type int32; > default 10; > default 20; > } >=20 >=20 > =20 > https://www.ietf.org/mail-archive/web/netmod/current/msg14532.html >=20 > It seems there has been no resolution. In this case, if default values = are replaced multiple times, which version will take effect? >=20 >=20 >=20 > This will be implementation-specific. > =20 >=20 >=20 > module dev1: >=20 > deviation /foo { > deviate replace { > default 30; > } > } >=20 >=20 >=20 > module dev2: >=20 > deviation /foo { > deviate replace { > default 40; > } > } >=20 > If first one wins or last one wins, then it depends on the order that > the deviations are loaded and processed by the parser. >=20 > Which version of /foo is really in use? >=20 > leaf-list foo {=20 > type int32; > default 30; > } >=20 > leaf-list foo {=20 > type int32; > default 40; > } >=20 >=20 > This follows the requirement that the statement be valid at the end, > but it is really broken wrt/ which deviation wins. This applies to > many deviations, not just default. >=20 > There needs to be a rule that a deviation duplicates are not allowed. I agree, although it is a bit awkward because it would be an = inter-module rule. Lada >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > > > Also, change the grammar: > > > > OLD: > > > > deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str = optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > [type-stmt] > > [units-stmt] > > [default-stmt] > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > "}") stmtsep > > > > NEW: > > > > deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str = optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > [type-stmt] > > [units-stmt] > > *must-stmt > > *unique-stmt > > *default-stmt > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > "}") stmtsep > > > > > > > > > > > >> Is it intentional that the ABNF for deviate-delete-stmt leaves out > >> config, mandatory, max-elements, and min-elements? > >> I understand why "type" cannot be removed. > > > > I don't really remember, but I can see that if you want to "delete" > > min-elements you can replace it and set it to 0. > > > >> IMO the rest of the statements should be removable. > > > >> Sec. 7.20.3.2 does not mention the restrictions indicated in the = ABNF. > >> This section should make it clear a leaf has only 1 default > >> and the 0..n refers to leaf-list only. > > > > In general, the result after applying deviations must be valid - = e.g., > > you cannot deviate "foo" as the default for an int32 leaf. > > > >> It should also be clear that the "deviate add default" for a = leaf-list > >> is YANG statement order-dependent. > >> > >> Not as obvious -- a config=3Dfalse leaf-list can have duplicate = default > >> values. > >> The deviate-stmt has no way to specify which 1 to delete or replace > >> if there are duplicates. > > > > Unless replace will replace *all*, as suggested above. > > > > > > /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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 20 04:34:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACF12D193 for ; Wed, 20 Apr 2016 04:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_zSdr5NXeyF for ; Wed, 20 Apr 2016 04:34: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 83D6112D12D for ; Wed, 20 Apr 2016 04:34:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51B191005; Wed, 20 Apr 2016 13:34: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 pNQ9l4JoueAs; Wed, 20 Apr 2016 13:33: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, 20 Apr 2016 13:34:06 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6000F20050; Wed, 20 Apr 2016 13:34:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L3x--wgCGs-X; Wed, 20 Apr 2016 13:34:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAFA72004E; Wed, 20 Apr 2016 13:34:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8318C3AA9DB5; Wed, 20 Apr 2016 13:34:02 +0200 (CEST) Date: Wed, 20 Apr 2016 13:34:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160420113402.GA5481@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , ichen@kuatrotech.com, "netmod@ietf.org" References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> <20160419.213703.1223710857303113407.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.6.0 (2016-04-01) Archived-At: Cc: ichen@kuatrotech.com, "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 11:34:11 -0000 On Tue, Apr 19, 2016 at 01:51:32PM -0700, Andy Bierman wrote: > > > Anyway, it would be good to hear opinions of other people. > > > > I can see the value in a urn:rdns: URN. Using 'http://' for YANG > > module namespace is a bit weird. Why not 'https://'? Or 'gopher://'? > > > > But I like urn:yang: even more - and if we had this, we > > wouldn't have to use the "namespace" statement. Unfortunately that > > would require a new version of YANG... > > > I do not think the standard mechanisms are good enough to assume > YANG module names will be globally unique. The RDNS format > needs to include the naming authority somehow. The namespace URI > gives the author more control to make naming collisions less likely. > Are you saying that (a) YANG imports are broken (since they assume unique module names) and that (b) JSON encoding is broken (since it uses module names to define 'namespaces'? I believe module authors will have to make sure module names are unique; if not they will learn it the hard way. Yes, I know the wording in 6020bis is Within a server, all module names MUST be unique. since this is obviously decidable and thus enforceable but RFC 6087 should clearly advice to create module names that have a larger scope of uniqueness. In fact, -06 still says: All published module names MUST be unique. [...] /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 Apr 20 04:48:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F1E12EB27 for ; Wed, 20 Apr 2016 04:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAsvtaWIykWl for ; Wed, 20 Apr 2016 04:47: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 3066912EB0B for ; Wed, 20 Apr 2016 04:47: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 E998E779; Wed, 20 Apr 2016 13:47:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jATZFHPVH_99; Wed, 20 Apr 2016 13:47:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 20 Apr 2016 13:47:56 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 019E120047; Wed, 20 Apr 2016 13:47:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GKB5pU8y4ZMD; Wed, 20 Apr 2016 13:47: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 F309720046; Wed, 20 Apr 2016 13:47:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E1CB13AA9E42; Wed, 20 Apr 2016 13:47:53 +0200 (CEST) Date: Wed, 20 Apr 2016 13:47:53 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160420114753.GB5481@elstar.local> Mail-Followup-To: Martin Bjorklund , ichen@kuatrotech.com, netmod@ietf.org References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> <20160419.213703.1223710857303113407.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160419.213703.1223710857303113407.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: ichen@kuatrotech.com, netmod@ietf.org Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 20 Apr 2016 11:48:00 -0000 On Tue, Apr 19, 2016 at 09:37:03PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > > The namespace definition is used by the XML encoding, the JSON > > encoding uses the YANG module name to identify a 'namespace'. The > > module name generally is assumed to be unique since tools (e.g., YANG > > compilers) import via module names. A urn:yang: would have > > the advantage to integrate things. In fact, the namespace statement in > > YANG could become optional, if one does not define a namespace, then > > the default namespace is urn:yang: (and this would enable > > round-trip conversion of namespaces between XML and JSON encoding, > > something I always found a valuable property.) > > > > Anyway, it would be good to hear opinions of other people. > > I can see the value in a urn:rdns: URN. Using 'http://' for YANG > module namespace is a bit weird. Why not 'https://'? Or 'gopher://'? The point is it does not matter. In some theory, the idea is that the URL resolves to something useful but in practice this does not matter. > But I like urn:yang: even more - and if we had this, we > wouldn't have to use the "namespace" statement. Unfortunately that > would require a new version of YANG... I think we should try to move into a direction that makes things simpler and more consistent in the longer term. It is too late to address this in YANG 1.1 but clearly if I would have had this idea earlier I would have filed an issue. The urn:yang: makes it clear that - we are talking about YANG URNs and - it forces people to think carefully about their module names. Even the IETF could in principle move to a scheme where we use module ietf-foo { version 1.1; namespace "urn:yang:ietf-foo"; // ... } and future versions of YANG may then even drop the namespace definition if it matches the module name, e.g., the example becomes just this: module ietf-foo { version 1.2; // ... } (The XML encoding specific namespace definition is removed.) /js PS: In hindsight, perhaps we should have used reverse DNS names for module name prefixes, i.e., org-ietf-foo instead of just ietf-foo and so we would have a reasonably reliable mechanism in place to create unique names for both SDOs and other organizations. -- 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 Apr 20 05:39:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C1612EB05 for ; Wed, 20 Apr 2016 05:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.996 X-Spam-Level: X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSHlhJJ8Fi4a for ; Wed, 20 Apr 2016 05:39:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E2512DD35 for ; Wed, 20 Apr 2016 05:39:40 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id B0A5960830; Wed, 20 Apr 2016 14:39:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461155978; bh=ew7Ix0Oy7DLPyzu0g5KgZsppnSWmBQH+gJxw9YYSDYE=; h=From:Date:To; b=A0Mqv18agCRn16hK9YxL/qWsSEWjKs0ENHKJXpr8AmGFDG3RNpiVg9ZH3tZ5yWYqv U0I2uIDyay5Z4nogUa/azMqnDe86IFDv2eeuUMXvI+sYVQlpSCcdSh5Hl7n/0gt7sb Lf/DxYLh3RHaXp+X7196mVTxPbOv8spIKnTbkQCA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160420113402.GA5481@elstar.local> Date: Wed, 20 Apr 2016 14:39:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> <20160419.213703.1223710857303113407.mbj@tail-f.com> <20160420113402.GA5481@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: ichen@kuatrotech.com, "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 12:39:42 -0000 > On 20 Apr 2016, at 13:34, Juergen Schoenwaelder = wrote: >=20 > On Tue, Apr 19, 2016 at 01:51:32PM -0700, Andy Bierman wrote: >>>> Anyway, it would be good to hear opinions of other people. >>>=20 >>> I can see the value in a urn:rdns: URN. Using 'http://' for YANG >>> module namespace is a bit weird. Why not 'https://'? Or = 'gopher://'? >>>=20 >>> But I like urn:yang: even more - and if we had this, we >>> wouldn't have to use the "namespace" statement. Unfortunately that >>> would require a new version of YANG... >>>=20 >> I do not think the standard mechanisms are good enough to assume >> YANG module names will be globally unique. The RDNS format >> needs to include the naming authority somehow. The namespace URI >> gives the author more control to make naming collisions less likely. >>=20 >=20 > Are you saying that (a) YANG imports are broken (since they assume > unique module names) and that (b) JSON encoding is broken (since it > uses module names to define 'namespaces'? >=20 > I believe module authors will have to make sure module names are > unique; if not they will learn it the hard way. Yes, I know the > wording in 6020bis is >=20 > Within a server, all module names MUST be unique. >=20 > since this is obviously decidable and thus enforceable but RFC 6087 > should clearly advice to create module names that have a larger scope > of uniqueness. In fact, -06 still says: >=20 > All published module names MUST be unique. [...] [I know we already had this discussion but =E2=80=A6] It is unclear what = "published" means - not so much in 6087bis whose scope is restricted to = Standard Track RFCs. However, 6020bis provides no definition but = nonetheless uses "published" in connection with 2119 keywords, e.g. For any published change, a new "revision" statement (Section 7.1.9) = MUST be included in front of the existing "revision" statements. I think this is quite problematic. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 20 06:32:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA6612D169 for ; Wed, 20 Apr 2016 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErwiDsBvFr6X for ; Wed, 20 Apr 2016 06:32:41 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC6212D5C5 for ; Wed, 20 Apr 2016 06:32:40 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id e190so41016998lfe.0 for ; Wed, 20 Apr 2016 06:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=dsq+iLG/z++eXNmnFAvkGmdtZcWy4lvpxhQsp2U1GoE=; b=q51re5S5Nux+yalMcxclaoMTFzwI/xnourApBYv9k3VvXdt+gddDc+MQT/6+IC6LGj VbI410+PnUCPsLq/SVE+1DPEtF4ASu4EKvSNBbyJ9QJxCRRDSCDTiFhUk1BAc+80EmIH XoNm0SQmG40/b2gJdoqg4Udb6vrm5o9wfyiHPXmCK20eesKhmynNIGpyw16HAEltL3+T /lM85jJ3dEeVH3GzBa64wZvq8Ue6NVzGGAwGi2kOBLm6j+LrvUQ5c51j79YGKKJpvjCd HXB3v0kT3lvwu08yMG6deDAVcgKXVsxJmk26/L7lJD5QBk4n4SxBOqdWBWkJpLWkVSJd oRqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=dsq+iLG/z++eXNmnFAvkGmdtZcWy4lvpxhQsp2U1GoE=; b=HxfLEfQfQ4Ys7Yw4VpCVHXptYks9L6d10T/co/qiXrngkMb4Z+ZKSXBOOaT4Yodu3W ykE63BzeajLYrK+oRm9eMftIvpX+FaT+mm3ZIFRXY1QwoIBofqW+OuMdBYZC2IYG4QMs 6r12zuyXTXpZ9Ju3cwVTH0CXQdXPV4XubiW209/sz+1mAMpHAyY9wNa2I4OBF0ZNYeun onRm6V6wg0dfK+G8fnGJso9JYvUe75GmfT/lmamw+wVXShklTZ7Htl9CRat/iQh8LuYf LxdLYM0IZ4x7WxAeDluagjZtHie5ad/RxTJ3blznZhAawpO3Wl++5LkQPf8NbnZ+NhKW I+1w== X-Gm-Message-State: AOPr4FVHcTBSo0ruOX2PbBRWBt4S57PsJJ76D7Ke+V/afbArxzQ74gzqayKTwi68kQUUrKaxTwWvj7B/TBk7Ig== MIME-Version: 1.0 X-Received: by 10.25.207.73 with SMTP id f70mr3639431lfg.131.1461159159078; Wed, 20 Apr 2016 06:32:39 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Wed, 20 Apr 2016 06:32:39 -0700 (PDT) In-Reply-To: <20160420113402.GA5481@elstar.local> References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> <20160419.213703.1223710857303113407.mbj@tail-f.com> <20160420113402.GA5481@elstar.local> Date: Wed, 20 Apr 2016 06:32:39 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , ichen@kuatrotech.com, "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1141fe4ca32f7c0530eaa07d Archived-At: Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:32:43 -0000 --001a1141fe4ca32f7c0530eaa07d Content-Type: text/plain; charset=UTF-8 On Wed, Apr 20, 2016 at 4:34 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Apr 19, 2016 at 01:51:32PM -0700, Andy Bierman wrote: > > > > Anyway, it would be good to hear opinions of other people. > > > > > > I can see the value in a urn:rdns: URN. Using 'http://' for YANG > > > module namespace is a bit weird. Why not 'https://'? Or 'gopher://'? > > > > > > But I like urn:yang: even more - and if we had this, we > > > wouldn't have to use the "namespace" statement. Unfortunately that > > > would require a new version of YANG... > > > > > I do not think the standard mechanisms are good enough to assume > > YANG module names will be globally unique. The RDNS format > > needs to include the naming authority somehow. The namespace URI > > gives the author more control to make naming collisions less likely. > > > > Are you saying that (a) YANG imports are broken (since they assume > unique module names) and that (b) JSON encoding is broken (since it > uses module names to define 'namespaces'? > > No, I didn't say that. > I believe module authors will have to make sure module names are > unique; if not they will learn it the hard way. Yes, I know the > wording in 6020bis is > > Within a server, all module names MUST be unique. > > This is obviously easy to accomplish since YANG imports cannot possibly work with 2 modules with the same name. since this is obviously decidable and thus enforceable but RFC 6087 > should clearly advice to create module names that have a larger scope > of uniqueness. In fact, -06 still says: > > All published module names MUST be unique. [...] > guidelines are not part of YANG. A compiler cannot rely on that. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1141fe4ca32f7c0530eaa07d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 20, 2016 at 4:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Apr 19, 2016 at 01:51:32PM -0700, Andy Bierm= an wrote:
> > > Anyway, it would be good to hear opinions of other people. > >
> > I can see the value in a urn:rdns: URN.=C2=A0 Using 'http://&= #39; for YANG
> > module namespace is a bit weird.=C2=A0 Why not 'https://'= ?=C2=A0 Or 'gopher://'?
> >
> > But I like urn:yang:<module-name> even more - and if we had= this, we
> > wouldn't have to use the "namespace" statement.=C2= =A0 Unfortunately that
> > would require a new version of YANG...
> >
> I do not think the standard mechanisms are good enough to assume
> YANG module names will be globally unique.=C2=A0 The RDNS format
> needs to include the naming authority somehow.=C2=A0 The namespace URI=
> gives the author more control to make naming collisions less likely. >

Are you saying that (a) YANG imports are broken (since they assume
unique module names) and that (b) JSON encoding is broken (since it
uses module names to define 'namespaces'?



No, I didn't say th= at.
=C2=A0
I believe module authors will have to make sure module names are
unique; if not they will learn it the hard way. Yes, I know the
wording in 6020bis is

=C2=A0 =C2=A0Within a server, all module names MUST be unique.


This is obviously easy to accomplish s= ince YANG imports cannot
possibly work with =C2=A02 modules with = the same name.


since this is obviously decidable and thus enforceable but RFC 6087
should clearly advice to create module names that have a larger scope
of uniqueness. In fact, -06 still says:

=C2=A0 =C2=A0All published module names MUST be unique. [...]

guidelines are not part of YANG.
A compile= r cannot rely on that.



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

--001a1141fe4ca32f7c0530eaa07d-- From nobody Wed Apr 20 07:41:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC59D12EF5F for ; Wed, 20 Apr 2016 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJJzaTFWeWWw for ; Wed, 20 Apr 2016 07:41:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0626.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::626]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56F712EEEE for ; Wed, 20 Apr 2016 07:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qd/NCVOSwC+Dbm3EgE3YUP4J+zXf7TlQLdIxFZqhJmY=; b=RJd0wKmvsexc8u+KpIMyk9f/RJ3BL4z0t5KUwlDso1IllDaScQlijH1JBOJyjg3YrWD8wLi1XY+Hchw8DA8l0wm/b/zPtCQVC0eSMhx6aGlDOOV3KheQxKyndkldJZLDsCregzZcWo3iqzkuFVbisG8xuALD/PFH67LaYOnJi80= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0949.eurprd06.prod.outlook.com (10.162.158.14) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 14:40:50 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 14:40:50 +0000 From: "Ing-Wher (Helen) Chen" To: Juergen Schoenwaelder Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyAAEV4yAAC5VLVAAASqeQAAKi2lIA== Date: Wed, 20 Apr 2016 14:40:50 +0000 Message-ID: References: <20160415152317.GB95324@elstar.local> <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> In-Reply-To: <20160419182250.GA3771@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 17502413-198b-45a4-804f-08d36929c4c2 x-microsoft-exchange-diagnostics: 1; DB5PR06MB0949; 5:USzFQKSk+Ak3DMTR2hA0ioratBHhCkPhCYdr9eXn5FFLSE9wRJ9O4ahly1bXQ9lH6z+afiRCGdESB7ZBaq1lRgN7VSr1u3u8CkVTKtqoFSAvwUYtkoew/Agp/Qr1zU7mXnd8Ur48QqyRjC/1HTbDgJeRgJKgv2TVqlpbigKE5r5P02QmNcbi0FbDPPlnIdeb; 24:nxtLKHkcqltEVpQXyap2Wy7PKPNH6AxcQE6kbP3nkc5sLm2jSAIQYXz99DS5hZdqxWNh8jsaDiv90qsIZCB6YalzEVppRCxZiDsXQIa7KuE=; 7:6tJ2OEkds8GTsyWTjcQboayTs+IWuK920yzwNo1I27NcU2mKK4lQiNkp1NWQalKvOe/zZ8JEoWaBm7jL3klNkV+D2J2cj2ZG7r1pQmpW7AtYVcvWI1Aniapi8exzkTJbHIPx/fU1h54mmNEMbtJdHwfr/SviIwW3sYL0aoHz+owVT6tCbDzGKZDvYtj/VMwHQELT7yVpwDbhB3xVbbg9qGdf6Y0qoamlpLteFugTntY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0949; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046); SRVR:DB5PR06MB0949; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0949; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(13464003)(24454002)(93886004)(10400500002)(50986999)(54356999)(76176999)(11100500001)(5004730100002)(122556002)(2906002)(2950100001)(74316001)(9686002)(87936001)(110136002)(4326007)(86362001)(81166005)(76576001)(5008740100001)(3846002)(33656002)(6116002)(102836003)(92566002)(1220700001)(1096002)(586003)(77096005)(5003600100002)(5002640100001)(19580405001)(15650500001)(66066001)(19580395003)(15975445007)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0949; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 14:40:50.4403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0949 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 14:41:15 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, April 19, 2016 2:23 PM > To: Ing-Wher (Helen) Chen > Cc: netmod@ietf.org > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models >=20 > On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote: > > I'm not an expert on XML namespaces and I'm a little confused by some > > of the questions, so I apologize if my response below does not quite > > answer the questions. I'd like to point out that the request for > > "rdns" URN is not to prevent the use of URLs. The request for "rdns" > > URN is to allow an enterprise to easily create a URN namespace, if the > > enterprise happens to prefer to use URN as a YANG module namespace. I > > also think that the problems that arise when a YANG module uses a URN > > based on an enterprise's domain name are the same problems that arise > > when a YANG module uses a URL based on an enterprise's domain name. > > (Of course, this is not an excuse to fix the problems that should be > > fixed.) >=20 > You write "happen to prefer to use URN" - why? draft-chen-rdns-urn Section 4 discusses why an enterprise might prefer to use URN over URL. URL provides resource access mechanism, which might mislead a customer to request that the YANG module be accessible at a specific location. It's true that the d= evice does not care that the YANG module is not at a particular URL, but I can st= ill imagine getting a bug requesting that the YANG module be accessible at the = URL. Thanks, Helen From nobody Wed Apr 20 07:47:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EE312DA43 for ; Wed, 20 Apr 2016 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vry60oOOdGSu for ; Wed, 20 Apr 2016 07:47:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08F12D92C for ; Wed, 20 Apr 2016 07:47:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id ED3E61AE0351; Wed, 20 Apr 2016 16:47:41 +0200 (CEST) Date: Wed, 20 Apr 2016 16:47:55 +0200 (CEST) Message-Id: <20160420.164755.1169712416411367784.mbj@tail-f.com> To: ichen@kuatrotech.com From: Martin Bjorklund In-Reply-To: References: <20160419182250.GA3771@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 14:47:44 -0000 Hi, One comment on this draft - why is it only for YANG module namespaces? It seems to me that it could be useful to use urn:rdns URNs for other purposes as well. If you really want to limit it to YANG module namespaces, maybe it should be called urn:yang-rdns: or something. /martin From nobody Wed Apr 20 08:36:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90412E376 for ; Wed, 20 Apr 2016 08:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kuatrotechnology.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEpqVZFEUExd for ; Wed, 20 Apr 2016 08:36:55 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::612]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECA912EFB2 for ; Wed, 20 Apr 2016 08:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fngJJuigKuiOUo9nqJfWc2vsvfxBWQVXp+XnVzHQ39o=; b=n/E8Tv5xXFqPNtKpoR4Ehz8VEE5HPINGMNeb0LiW4tJo1rmMtflPgNx0VC9B2miwFPq6FiZLricwQiRcLZfxrY8krO3be8TgKWPBQp3U4vp5xmLrGLaWAv7TtOniy6amN2P9ADof4/6MU1hkwXt6wsXhwCiVakDwod+6dgnqWFY= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 15:24:26 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 15:24:26 +0000 From: "Ing-Wher (Helen) Chen" To: Martin Bjorklund Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyAAEV4yAAC5VLVAAASqeQAAKi2lIAAAm3SAAAAbDzA= Date: Wed, 20 Apr 2016 15:24:25 +0000 Message-ID: References: <20160419182250.GA3771@elstar.local> <20160420.164755.1169712416411367784.mbj@tail-f.com> In-Reply-To: <20160420.164755.1169712416411367784.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 9d4c1374-8e10-49a8-3b17-08d3692fdbba x-microsoft-exchange-diagnostics: 1; DB5PR06MB0950; 5:73Mqq716zMEGYLQs9eRMzKxy4crj2poaXwijYTMY/wAmLoxW5vkcZ3rNv+SlblIZzhvNauLQYQrmTLknJdhrOzNd+E+UtoBHo992wzEuJxQhF/LP0ap+SDqSBi+k95APqGFLhSKwN5DA/3DHxTegVb1nWhEVlBbOva1mEU7xCkcGEgtLyVcstqZWCAkyFDbp; 24:fH8otP0JSBtwQoOfnRYHyodfw/w8jtokflG438Mwe8NwqQSwBrlC+p1TLUifOZ4jav7xT5Rrcbx04zEEeG++D91i0kYhz1NbL/0nPExEeqs=; 7:nOH7/9GNqrkBKNMjg+yhkDSVLpyxTcEoP8LxwvaPiClVNtm3l7Rwt/wL9qfQUOe+LWkFBTGv+GBuhn+C11+unKzHKbgN75/2omftSxEqZYQuY/rSTRp+xcktbfbDICAQ5fIkmya4pAWrBbMoPwxXxkXcpNcYCWy2R+NAtWu5/7vPOToY5CNLdHoWp9kV0mUoZ9NTMWVM8GSCHK7Ayb4a2+mcdt+sRf/gdK5I20X4peQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0950; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:DB5PR06MB0950; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0950; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377454003)(3660700001)(81166005)(86362001)(4326007)(5002640100001)(3280700002)(2906002)(66066001)(10400500002)(74316001)(9686002)(93886004)(2950100001)(110136002)(189998001)(586003)(5003600100002)(6116002)(3846002)(1096002)(33656002)(5004730100002)(122556002)(5008740100001)(76176999)(92566002)(87936001)(1220700001)(15650500001)(2900100001)(19580395003)(54356999)(102836003)(76576001)(50986999)(11100500001)(19580405001)(77096005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0950; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 15:24:25.9228 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0950 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:36:57 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, April 20, 2016 10:48 AM > To: Ing-Wher (Helen) Chen > Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models >=20 > Hi, >=20 > One comment on this draft - why is it only for YANG module namespaces? > It seems to me that it could be useful to use urn:rdns URNs for other > purposes as well. There are indeed many use cases for URNs based on registered domain names, and I believe there are registrations for top-level URN names where parts o= f the URN are based on domain names. The technical problem of generalizing is the difficulty in creating a URN b= ased on domain names that is also persistent. Limiting the scope of the "rdns"= URN namespace to only YANG modules means that there is a smaller persistency problem to solve and that it can be solved by taking advantage of propertie= s=09 specific to YANG modules. >=20 > If you really want to limit it to YANG module namespaces, maybe it should= be > called urn:yang-rdns: or something. Noted. Thanks, Helen From nobody Wed Apr 20 11:10:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2127F12DE07 for ; Wed, 20 Apr 2016 11:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74xvG0U11NdL for ; Wed, 20 Apr 2016 11:10:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr650134.outbound.protection.outlook.com [40.107.65.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7C712DCF6 for ; Wed, 20 Apr 2016 11:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ayZKBZQq/e9YTrGBuyi7gjz4ZB8YklIaJQAHDaPmZQ0=; b=erYr2r3WpYfRSwk2gk+ovPygSV2DlQo+1Y5KP2jUU0ay+R/MQ2XOXyjr3v5D+Wc2Iq3Emhi15VLpu6OCawzU5tLO+6Qdm4OFFyWLqLl2XvfFmDwEiUdabpkoX/Hc1acT5I9MSexiOm+besaPXvipUebfw4IYdPKRF9oFOS8qHIk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 20 Apr 2016 18:10:23 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0466.023; Wed, 20 Apr 2016 18:10:23 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyAAEV4yAAC5VLVAAASqeQAAApeMgAAh5+6AAAT55gA= Date: Wed, 20 Apr 2016 18:10:23 +0000 Message-ID: References: <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local> <20160419.213703.1223710857303113407.mbj@tail-f.com> <20160420114753.GB5481@elstar.local> In-Reply-To: <20160420114753.GB5481@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: e3d2890e-60e4-402f-8406-08d369470af1 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:1NT7AZeJpakh1SHNQAS/8zj1h7pYRqFq+fwuPUK9OZv+v7UYrwGTkxhTOS2j5Qbvl87amQuL3OKiVmnVKy0PrbnMpT0FCHCWmPaiZqnky3as/gNo+jOs/MEzWwGI8mHiEFBFootmXXlod0AmH5QGgQ==; 24:/MctEJKpkN87mcJ7UxjW8cJc8Kx6ZunWbpue1Qh3gXDitpuHpzRcymgw9tnywPTIeoSqgRVOXPHOuxjvgn5ggrOwRfPrtOVVx4BgNOA5/pM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(99286002)(83716003)(76176999)(50986999)(54356999)(66066001)(81166005)(11100500001)(36756003)(3280700002)(92566002)(3660700001)(4326007)(5002640100001)(2900100001)(2950100001)(86362001)(2906002)(93886004)(5008740100001)(19580405001)(4001350100001)(77096005)(189998001)(83506001)(82746002)(19580395003)(5001770100001)(6116002)(3846002)(5004730100002)(586003)(87936001)(102836003)(33656002)(122556002)(10400500002)(15975445007)(1096002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 18:10:23.5004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "ichen@kuatrotech.com" , "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:10:26 -0000 DQoNCg0KDQoNCk9uIDQvMjAvMTYsIDc6NDcgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEp1ZXJn ZW4gU2Nob2Vud2FlbGRlciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQo+T24gVHVlLCBB cHIgMTksIDIwMTYgYXQgMDk6Mzc6MDNQTSArMDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN Cj4+DQo+IA0KPj4gQnV0IEkgbGlrZSB1cm46eWFuZzo8bW9kdWxlLW5hbWU+IGV2ZW4gbW9yZSAt IGFuZCBpZiB3ZSBoYWQgdGhpcywgd2UNCj4+IHdvdWxkbid0IGhhdmUgdG8gdXNlIHRoZSAibmFt ZXNwYWNlIiBzdGF0ZW1lbnQuICBVbmZvcnR1bmF0ZWx5IHRoYXQNCj4+IHdvdWxkIHJlcXVpcmUg YSBuZXcgdmVyc2lvbiBvZiBZQU5HLi4uDQo+DQo+SSB0aGluayB3ZSBzaG91bGQgdHJ5IHRvIG1v dmUgaW50byBhIGRpcmVjdGlvbiB0aGF0IG1ha2VzIHRoaW5ncw0KPnNpbXBsZXIgYW5kIG1vcmUg Y29uc2lzdGVudCBpbiB0aGUgbG9uZ2VyIHRlcm0uIEl0IGlzIHRvbyBsYXRlIHRvDQo+YWRkcmVz cyB0aGlzIGluIFlBTkcgMS4xIGJ1dCBjbGVhcmx5IGlmIEkgd291bGQgaGF2ZSBoYWQgdGhpcyBp ZGVhDQo+ZWFybGllciBJIHdvdWxkIGhhdmUgZmlsZWQgYW4gaXNzdWUuIA0KDQoNCkp1c3QgZmls ZWQgb25lIGZvciBZQU5HLW5leHQ6IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1u ZXh0L2lzc3Vlcy81Lg0KDQpLZW50DQoNCg0KDQo= From nobody Wed Apr 20 20:56:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E2112E4CA for ; Wed, 20 Apr 2016 20:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoseGVLYxX_Q for ; Wed, 20 Apr 2016 20:56:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E06912E3B5 for ; Wed, 20 Apr 2016 20:56:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIA60626; Thu, 21 Apr 2016 03:56:28 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Apr 2016 04:56:27 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.184]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0235.001; Thu, 21 Apr 2016 11:56:22 +0800 From: "zhangyali (D)" To: "netmod@ietf.org" Thread-Topic: yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/w== Date: Thu, 21 Apr 2016 03:56:22 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.104.182] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F58135F161A3szxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57184F6C.00B7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9d5624d5952c331d1fcd735440f2e871 Archived-At: Subject: [netmod] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 03:56:33 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F58135F161A3szxeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I noticed that there is a draft intents to classify the various yang model,= it is really a meaningful work. Many points are consistent with my underst= anding, whereas, there are some questions unclear need to inquire. 1. What is Best Regards, Yali --_000_A747A0713F56294D8FBE33E5C6B8F58135F161A3szxeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I noticed that there is a draft= intents to classify the various yang model, it is really a meaningful work= . Many points are consistent with my understanding, whereas, there are some= questions unclear need to inquire.

 

1= .   &= nbsp;   What is

 

Best Regards,=

Yali

 

--_000_A747A0713F56294D8FBE33E5C6B8F58135F161A3szxeml513mbxchi_-- From nobody Wed Apr 20 21:12:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA82912E330 for ; Wed, 20 Apr 2016 21:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 434S5lEyElsX for ; Wed, 20 Apr 2016 21:12:29 -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 694C312D5E2 for ; Wed, 20 Apr 2016 21:03:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIA61330; Thu, 21 Apr 2016 04:03:26 +0000 (GMT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Apr 2016 05:03:26 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.184]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0235.001; Thu, 21 Apr 2016 12:03:13 +0800 From: "zhangyali (D)" To: "netmod@ietf.org" Thread-Topic: yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2A Date: Thu, 21 Apr 2016 04:03:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.104.182] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F58135F161BBszxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5718510F.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 058840567991d1e83ea2ab60ebb936e3 Archived-At: Subject: [netmod] =?gb2312?b?tPC4tDogeWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlvbg==?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 04:12:31 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F58135F161BBszxeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIG5vdGljZWQgdGhhdCB0aGVyZSBpcyBhIGRyYWZ0IGludGVudHMgdG8gY2xh c3NpZnkgdGhlIHZhcmlvdXMgeWFuZyBtb2RlbCwgaXQgaXMgcmVhbGx5IGEgbWVhbmluZ2Z1bCB3 b3JrLiBNYW55IHBvaW50cyBhcmUgY29uc2lzdGVudCB3aXRoIG15IHVuZGVyc3RhbmRpbmcsIHdo ZXJlYXMsIHRoZXJlIGFyZSBzb21lIHF1ZXN0aW9ucyB1bmNsZWFyIG5lZWQgdG8gaW5xdWlyZS4N Cg0KDQoxLiAgICAgICBXaHkgVlBMUyBhbmQgVlBXUyBhcmUgYWxsIHNlcnZpY2UgbW9kZWwsIHdo aWNoIGlzIGF0IHRoZSBzYW1lIGxldmVsIHdpdGggTDNWUE4/IEluIG15IHVuZGVyc3RhbmRpbmcs IEwzVlBOIGlzIGEgdHlwaWNhbCBzZXJ2aWNlIG1vZGVsIHdoaWNoIGhpZGVzIHRoZSB1bmRlcmxh eSBuZXR3b3JrLCBidXQgYm90aCBWUExTIGFuZCBWUFdTIGlzIHNwZWNpZmljIHRlY2hub2xvZ3kg c29sdXRpb25zLiBNYXliZSBhIHVuaWZvcm0gTDJWUE4gd2hpY2ggYWJzdHJhY3RzIHNlcnZpY2Ug aW5mb3JtYXRpb24gZnJvbSBhbGwgbGF5ZXIyIHRlY2hub2xvZ2llcyBtb3JlIGxpa2Ugc2Vydmlj ZSBtb2RlbC4NCg0KMi4gICAgICAgV2hhdCBpcyB0aGUgbGF5ZXIgb2YgdGVjaG5vbG9neSBzb2x1 dGlvbnMsIHN1Y2ggYXMsIFZ4TEFOLCBHUkUsIFZQTFMsIGV0Yz8NCg0KMy4gICAgICAgSW4gVE1O IE0uMzAxMCwgbmV0d29yayBtb2RlbCBhbHNvIGEgcGFydGljdWxhciBsYXllciwgc2hvdWxkIHNw ZWNpZmljIHlhbmcgbW9kZWwgY292ZXIgdGhpcyBsYXllcj8NCg0KQmVzdCBSZWdhcmRzLA0KWWFs aQ0KDQo= --_000_A747A0713F56294D8FBE33E5C6B8F58135F161BBszxeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I noticed that there is a draft= intents to classify the various yang model, it is really a meaningful work= . Many points are consistent with my understanding, whereas, there are some= questions unclear need to inquire.

 

1= .   &= nbsp;   Why VPLS and VPWS are all service model, which is at the same level = with L3VPN? In my understanding, L3VPN is a typical service model which hid= es the underlay network, but both VPLS and VPWS is specific technology solutions. Maybe a uniform L2VPN which abs= tracts service information from all layer2 technologies more like service m= odel.

2.       What is the layer of technology solutions, such as, VxLAN, GRE, VPLS, etc?=

3.       In TMN M.3010, network model also a particular layer, should specific yang= model cover this layer?

 

Best Regards,=

Yali

 

--_000_A747A0713F56294D8FBE33E5C6B8F58135F161BBszxeml513mbxchi_-- From nobody Thu Apr 21 00:46:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1013F12EA36 for ; Thu, 21 Apr 2016 00:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukbKT3YkPhlK for ; Thu, 21 Apr 2016 00:46:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F95912EA3B for ; Thu, 21 Apr 2016 00:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1461224802; x=1462434402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lrWo0i/5NzrDgBmgaTZYZJ901FuIECpuvfQnFJH/zzs=; b=k4V0DK8a4/ZPfIZShU7rfIHK+XB46+nlLUAAD+xgDiU0qMgxUJotGfF8 PpB3TIYPlwTk6NttA3eBAl+RJtse+xIZDSa5qSl853/PgjOHceMik65WT 3FaPxBDeAASg2qPeP7fQVamhAUiml/81SSnzmDve9A/IfeCjFa/f11+Lr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBFhBhX/5NdJa1egzhTfQa5agENg?= =?us-ascii?q?XIXC4UiSgIcgR84FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQgYAgImAgI?= =?us-ascii?q?CJQsVEAEBBA4FG4gHCA6tX5EWAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR8hSWBd?= =?us-ascii?q?QiCToQ9gwIrgisFmA8BjhOPEI8sAR4BAUKCCRWBSmyHSX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="94220300" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 07:46:41 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3L7kfDa017377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 07:46:41 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 02:46:40 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 02:46:40 -0500 From: "Carl Moberg (camoberg)" To: "zhangyali (D)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoA= Date: Thu, 21 Apr 2016 07:46:40 +0000 Message-ID: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.210] Content-Type: text/plain; charset="utf-8" Content-ID: <78D599FA78554C4789493A7DD2EF5630@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:46:44 -0000 WWFsaSwNCg0KPiBPbiBBcHIgMjEsIDIwMTYsIGF0IDY6MDMgQU0sIHpoYW5neWFsaSAoRCkgPHpo YW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4gIA0KPiBJIG5v dGljZWQgdGhhdCB0aGVyZSBpcyBhIGRyYWZ0IGludGVudHMgdG8gY2xhc3NpZnkgdGhlIHZhcmlv dXMgeWFuZyBtb2RlbCwgaXQgaXMgcmVhbGx5IGEgbWVhbmluZ2Z1bCB3b3JrLiBNYW55IHBvaW50 cyBhcmUgY29uc2lzdGVudCB3aXRoIG15IHVuZGVyc3RhbmRpbmcsIHdoZXJlYXMsIHRoZXJlIGFy ZSBzb21lIHF1ZXN0aW9ucyB1bmNsZWFyIG5lZWQgdG8gaW5xdWlyZS4NCj4gIA0KPiAxLiAgICAg ICBXaHkgVlBMUyBhbmQgVlBXUyBhcmUgYWxsIHNlcnZpY2UgbW9kZWwsIHdoaWNoIGlzIGF0IHRo ZSBzYW1lIGxldmVsIHdpdGggTDNWUE4/IEluIG15IHVuZGVyc3RhbmRpbmcsIEwzVlBOIGlzIGEg dHlwaWNhbCBzZXJ2aWNlIG1vZGVsIHdoaWNoIGhpZGVzIHRoZSB1bmRlcmxheSBuZXR3b3JrLCBi dXQgYm90aCBWUExTIGFuZCBWUFdTIGlzIHNwZWNpZmljIHRlY2hub2xvZ3kgc29sdXRpb25zLiBN YXliZSBhIHVuaWZvcm0gTDJWUE4gd2hpY2ggYWJzdHJhY3RzIHNlcnZpY2UgaW5mb3JtYXRpb24g ZnJvbSBhbGwgbGF5ZXIyIHRlY2hub2xvZ2llcyBtb3JlIGxpa2Ugc2VydmljZSBtb2RlbC4NCg0K IFNlY3Rpb24gMi4xIGdvZXMgdG8gc29tZSBsZW5ndGggdG8gZGVzY3JpYmUgdGhhdCB0aGVyZSBh cmUgdmFyaW91cyB0eXBlcyBvZiBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscyBhdCB2 YXJpb3VzIGxldmVscyBvZiBhYnN0cmFjdGlvbnMuIFRoaXMgbWVhbnMgdGhhdCBib3RoIGdlbmVy aWMgbW9kZWxzIChlLmcuIGEgdGVjaG5vbG9neSBhZ25vc3RpYyBMMyBWUE4gbW9kZWwpIGFuZCBt b3JlIGltcGxlbWVudGF0aW9uLW9yaWVudGVkIG1vZGVscyAoZS5nLiBWUExTKSB3b3VsZCBiZSBj bGFzc2lmaWVkIGFzIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9kZWxzIHdpdGhvdXQgYmVp bmcgYXQgdGhlIGV4YWN0IHNhbWUgbGV2ZWwgb2YgYWJzdHJhY3Rpb24uDQoNCj4gMi4gICAgICAg V2hhdCBpcyB0aGUgbGF5ZXIgb2YgdGVjaG5vbG9neSBzb2x1dGlvbnMsIHN1Y2ggYXMsIFZ4TEFO LCBHUkUsIFZQTFMsIGV0Yz8NCg0KIElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBWeExBTiwgR1JF LCBWUExTIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgcmVzaWRpbmcg b24gYSBkZXZpY2UsIHRoZW4gaXTigJlzIE5ldHdvcmsgRWxlbWVudCBZQU5HIERhdGEgbW9kZWxz LiBJZiB5b3XigJlyZSB0YWxraW5nIGFib3V0IFZ4TEFOLCBHUkUsIFZQTFMgY29uZmlndXJhdGlv biBhbmQgb3BlcmF0aW9uYWwgcGFyYW1ldGVycyBhcyBwYXJ0IG9mIGFuICJhYnN0cmFjdCBtb2Rl bCB0aGF0IGFsbG93cyBpbnN0YW5jZXMgbyB0aGUgc2VydmljZSB0byBiZSBkZWNvbXBvc2VkIGlu dG8gaW5zdGFuY2UgZGF0YSBhY2NvcmRpbmcgdG8gdGhlIE5ldHdvcmsgRWxlbWVudCBkYXRhIG1v ZGVscyBvZiB0aGUgcGFydGljaXBhdGluZyBuZXR3b3JrIGVsZW1lbnRz4oCdLCB0aGVuIGl0IHdv dWxkIGJlIGNsYXNzaWZpZWQgYXMgYSBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscy4g DQoNCj4gMy4gICAgICAgSW4gVE1OIE0uMzAxMCwgbmV0d29yayBtb2RlbCBhbHNvIGEgcGFydGlj dWxhciBsYXllciwgc2hvdWxkIHNwZWNpZmljIHlhbmcgbW9kZWwgY292ZXIgdGhpcyBsYXllcj8N Cg0KIEkgaGF2ZSBkb25lIHNvbWUgcmVhZGluZyBvbiBNLjMwMTAgYW5kIGJlbGlldmUgd2UgYXJl IHdlbGwgYWxpZ25lZCBpbiB0aGUgZHJhZnQuIFRoZSBuZXR3b3JrIG1vZGVsIHdvdWxkIGJlIGNs YXNzaWZpZWQgYWQgYXMgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbC4NCg0KPiBCZXN0 IFJlZ2FyZHMsDQo+IFlhbGkNCj4gIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Thu Apr 21 01:31:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E23A12EB12 for ; Thu, 21 Apr 2016 01:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqyx01h9a55R for ; Thu, 21 Apr 2016 01:31:27 -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 243F812EB1E for ; Thu, 21 Apr 2016 01:31:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMW00340; Thu, 21 Apr 2016 08:31:22 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Apr 2016 09:31:05 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.184]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0235.001; Thu, 21 Apr 2016 16:30:54 +0800 From: "zhangyali (D)" To: "Carl Moberg (camoberg)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8A== Date: Thu, 21 Apr 2016 08:30:53 +0000 Message-ID: References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> In-Reply-To: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.104.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57188FDC.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a1b7b2358bfa3e031db7d837882245e5 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] =?utf-8?b?562U5aSNOiAgeWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlv?= =?utf-8?q?n?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:31:31 -0000 SGkgQ2FybCwNCg0KVGhhbmtzIGZvciB5b3VyIGFuc3dlcnMgdmVyeSBtdWNoLiBGcm9tIHlvdXIg ZXhwbGFuYXRpb24sIHRoZSBtYWluIHZpZXcgaXMgdGhhdCBkbyBub3QgZGlzdGluZ3Vpc2ggdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiBuZXR3b3JrIGxldmVsIGFuZCBzZXJ2aWNlIGxldmVsIG1vZGVs LCB3aGljaCBhbGwgY2FsbGVkICJuZXR3b3JrIHNlcnZpY2UgbW9kZWwiLCByaWdodD8NCklmIHNv LCB0aGUgcXVlc3Rpb24gaXMgdGhhdCBob3cgdGhlc2UgInNhbWUgbGF5ZXIiIG1vZGVsIGNvdWxk IGJlIHVzZWQgaW4gdGhlIGxheWVyZWQgYXJjaGl0ZWN0dXJlLCBzdWNoIGFzLCB0aGVyZSBhcmUg b3JjaGVzdHJhdG9yIGxheWVyLCBjb250cm9sbGVyIGxheWVyIGFuZCBkZXZpY2UgbGF5ZXI/IElu IG15IHVuZGVyc3RhbmRpbmcsIHRoZSBOQkkgb2Ygb3JjaGVzdHJhdG9yIHNob3VsZCBub3QgaW5j bHVkZSBhbnkgdGVjaG5vbG9neSBkZXRhaWxzIHdoaWNoIHNob3VsZCBleGlzdCBpbiB0aGUgTkJJ IG9mIGNvbnRyb2xsZXIuIFRoZSBvcmNoZXN0cmF0b3Igd2lsbCBjb21wbGV0ZSB0aGUgbWFwcGlu ZyBmcm9tIE5CSSBvZiBvcmNoZXN0cmF0b3IgdG8gTkJJIG9mIGNvbnRyb2xsZXIuDQoNCkxldCdz IHRha2UgTDJWUE4gYXMgYSBleGFtcGxlLiBJbiB0aGUgTkJJIG9mIG9yY2hlc3RyYXRvciwgdGhl IHlhbmcgbW9kZWwganVzdCBuZWVkIGV4cHJlc3MgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIG9mIEwy VlBOLCBzdWNoIGFzLCBzaXRlcyBpbmZvcm1hdGlvbiBhbmQgdG9wb2xvZ3kgYmV0d2VlbiBzaXRl cy4gRm9yIHRoZSBOQkkgb2YgY29udHJvbGxlciwgdGhlIHlhbmcgbW9kZWwgbWF5IGJlIHNvbWUg dGVjaG5vbG9neSBzb2x1dGlvbnMsIHN1Y2ggYXMsIFZQTFMsIFZQV1MsIGV0Yy4gVGhlIG9yY2hl c3RyYXRvciB3aWxsIGNob29zZSBvbmUgb3Igc29tZSBzb2x1dGlvbnMgZGVwZW5kcyBvbiB1c2Vy cycgcmVxdWlyZW1lbnQuIFRoZW4gdGhlIGNvbnRyb2xsZXIgd2lsbCBjb21wbGV0ZSB0aGUgbmV0 d29yayBlbGVtZW50IGNvbmZpZ3VyYXRpb24gKHVzaW5nIG5ldHdvcmsgZWxlbWVudCB5YW5nIG1v ZGVsICkgYWNjb3JkaW5nIHRvIHRlY2hub2xvZ3kgc29sdXRpb25zIGNob3NlbiBieSBvcmNoZXN0 cmF0b3IuDQoNClRob3VnaCBJIGFtIG5vdCBzdXJlIGlmIHRoZSBwcm9jZXNzIGlzIHN1aXRhYmxl LCB0aGUgc2VydmljZSBtb2RlbCBhbmQgbmV0d29yayBtb2RlbCBhcmUgZGlmZmVyZW5jZSB3aGlj aCBhcmUgdXNlZCBpbiBkaWZmZXJlbnQgcGxhY2VzLiBBbnkgY29tbWVudHM/DQoNCg0KQmVzdCwN CllhbGkNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAo Y2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdAY2lzY28uY29tXSANCuWPkemAgeaXtumXtDogMjAx NuW5tDTmnIgyMeaXpSAxNTo0Nw0K5pS25Lu25Lq6OiB6aGFuZ3lhbGkgKEQpDQrmioTpgIE6IG5l dG1vZEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0geWFuZyBtb2RlbCBjbGFzc2lmaWNh dGlvbg0KDQpZYWxpLA0KDQo+IE9uIEFwciAyMSwgMjAxNiwgYXQgNjowMyBBTSwgemhhbmd5YWxp IChEKSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gSGkgYWxsLA0KPiAg DQo+IEkgbm90aWNlZCB0aGF0IHRoZXJlIGlzIGEgZHJhZnQgaW50ZW50cyB0byBjbGFzc2lmeSB0 aGUgdmFyaW91cyB5YW5nIG1vZGVsLCBpdCBpcyByZWFsbHkgYSBtZWFuaW5nZnVsIHdvcmsuIE1h bnkgcG9pbnRzIGFyZSBjb25zaXN0ZW50IHdpdGggbXkgdW5kZXJzdGFuZGluZywgd2hlcmVhcywg dGhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zIHVuY2xlYXIgbmVlZCB0byBpbnF1aXJlLg0KPiAgDQo+ IDEuICAgICAgIFdoeSBWUExTIGFuZCBWUFdTIGFyZSBhbGwgc2VydmljZSBtb2RlbCwgd2hpY2gg aXMgYXQgdGhlIHNhbWUgbGV2ZWwgd2l0aCBMM1ZQTj8gSW4gbXkgdW5kZXJzdGFuZGluZywgTDNW UE4gaXMgYSB0eXBpY2FsIHNlcnZpY2UgbW9kZWwgd2hpY2ggaGlkZXMgdGhlIHVuZGVybGF5IG5l dHdvcmssIGJ1dCBib3RoIFZQTFMgYW5kIFZQV1MgaXMgc3BlY2lmaWMgdGVjaG5vbG9neSBzb2x1 dGlvbnMuIE1heWJlIGEgdW5pZm9ybSBMMlZQTiB3aGljaCBhYnN0cmFjdHMgc2VydmljZSBpbmZv cm1hdGlvbiBmcm9tIGFsbCBsYXllcjIgdGVjaG5vbG9naWVzIG1vcmUgbGlrZSBzZXJ2aWNlIG1v ZGVsLg0KDQogU2VjdGlvbiAyLjEgZ29lcyB0byBzb21lIGxlbmd0aCB0byBkZXNjcmliZSB0aGF0 IHRoZXJlIGFyZSB2YXJpb3VzIHR5cGVzIG9mIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9k ZWxzIGF0IHZhcmlvdXMgbGV2ZWxzIG9mIGFic3RyYWN0aW9ucy4gVGhpcyBtZWFucyB0aGF0IGJv dGggZ2VuZXJpYyBtb2RlbHMgKGUuZy4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIEwzIFZQTiBtb2Rl bCkgYW5kIG1vcmUgaW1wbGVtZW50YXRpb24tb3JpZW50ZWQgbW9kZWxzIChlLmcuIFZQTFMpIHdv dWxkIGJlIGNsYXNzaWZpZWQgYXMgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMgd2l0 aG91dCBiZWluZyBhdCB0aGUgZXhhY3Qgc2FtZSBsZXZlbCBvZiBhYnN0cmFjdGlvbi4NCg0KPiAy LiAgICAgICBXaGF0IGlzIHRoZSBsYXllciBvZiB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBh cywgVnhMQU4sIEdSRSwgVlBMUywgZXRjPw0KDQogSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IFZ4 TEFOLCBHUkUsIFZQTFMgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgcGFyYW1ldGVycyBy ZXNpZGluZyBvbiBhIGRldmljZSwgdGhlbiBpdOKAmXMgTmV0d29yayBFbGVtZW50IFlBTkcgRGF0 YSBtb2RlbHMuIElmIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQgVnhMQU4sIEdSRSwgVlBMUyBjb25m aWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIGFzIHBhcnQgb2YgYW4gImFic3Ry YWN0IG1vZGVsIHRoYXQgYWxsb3dzIGluc3RhbmNlcyBvIHRoZSBzZXJ2aWNlIHRvIGJlIGRlY29t cG9zZWQgaW50byBpbnN0YW5jZSBkYXRhIGFjY29yZGluZyB0byB0aGUgTmV0d29yayBFbGVtZW50 IGRhdGEgbW9kZWxzIG9mIHRoZSBwYXJ0aWNpcGF0aW5nIG5ldHdvcmsgZWxlbWVudHPigJ0sIHRo ZW4gaXQgd291bGQgYmUgY2xhc3NpZmllZCBhcyBhIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEg TW9kZWxzLiANCg0KPiAzLiAgICAgICBJbiBUTU4gTS4zMDEwLCBuZXR3b3JrIG1vZGVsIGFsc28g YSBwYXJ0aWN1bGFyIGxheWVyLCBzaG91bGQgc3BlY2lmaWMgeWFuZyBtb2RlbCBjb3ZlciB0aGlz IGxheWVyPw0KDQogSSBoYXZlIGRvbmUgc29tZSByZWFkaW5nIG9uIE0uMzAxMCBhbmQgYmVsaWV2 ZSB3ZSBhcmUgd2VsbCBhbGlnbmVkIGluIHRoZSBkcmFmdC4gVGhlIG5ldHdvcmsgbW9kZWwgd291 bGQgYmUgY2xhc3NpZmllZCBhZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVsLg0K DQo+IEJlc3QgUmVnYXJkcywNCj4gWWFsaQ0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9k QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQoNCg== From nobody Thu Apr 21 01:41:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF5F12DF58 for ; Thu, 21 Apr 2016 01:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FptbbzTL72Ww for ; Thu, 21 Apr 2016 01:41:47 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B629812E1D5 for ; Thu, 21 Apr 2016 01:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5974; q=dns/txt; s=iport; t=1461228079; x=1462437679; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IjyrgPObMR380ub7pkI9plLjw1eX9Pv4wE6ivhrsjsw=; b=KmDeG1tBO0TZyAeM01i9S8xG39fwHLndL3Xa7NIwvTUkfgwz8XWAAmz9 12Z3qBu7kxc6RYXipQ/f8jpfiXow6rvE548fKVqRx9tGheuzbul33Vlbi eCAQDtQCX7I29YPeUj/mj93LNX2C62ZyBsCor2o1DNh7su5f+eqGqF0jX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBCkRhX/5hdJa1egzhTfQa5agENg?= =?us-ascii?q?XIXC4UiSgIcgQ04FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQYCEgYCAiM?= =?us-ascii?q?DAgICJQsUAQIOAQEEDgUbiAcIDpBsnReRGAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?REEfIUlgXWCVoc/K4IrBZMehHEBjhOPEI8sAR4BAUKCCRWBSmyHSX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="264135367" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 08:41:18 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3L8fIVb015355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 08:41:18 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 03:41:18 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 03:41:17 -0500 From: "Carl Moberg (camoberg)" To: "zhangyali (D)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A Date: Thu, 21 Apr 2016 08:41:17 +0000 Message-ID: <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.210] 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] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:41:48 -0000 PiBPbiBBcHIgMjEsIDIwMTYsIGF0IDEwOjMwIEFNLCB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkz NjlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiANCj4gVGhhbmtzIGZvciB5 b3VyIGFuc3dlcnMgdmVyeSBtdWNoLiBGcm9tIHlvdXIgZXhwbGFuYXRpb24sIHRoZSBtYWluIHZp ZXcgaXMgdGhhdCBkbyBub3QgZGlzdGluZ3Vpc2ggdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBuZXR3 b3JrIGxldmVsIGFuZCBzZXJ2aWNlIGxldmVsIG1vZGVsLCB3aGljaCBhbGwgY2FsbGVkICJuZXR3 b3JrIHNlcnZpY2UgbW9kZWwiLCByaWdodD8NCj4gSWYgc28sIHRoZSBxdWVzdGlvbiBpcyB0aGF0 IGhvdyB0aGVzZSAic2FtZSBsYXllciIgbW9kZWwgY291bGQgYmUgdXNlZCBpbiB0aGUgbGF5ZXJl ZCBhcmNoaXRlY3R1cmUsIHN1Y2ggYXMsIHRoZXJlIGFyZSBvcmNoZXN0cmF0b3IgbGF5ZXIsIGNv bnRyb2xsZXIgbGF5ZXIgYW5kIGRldmljZSBsYXllcj8gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhl IE5CSSBvZiBvcmNoZXN0cmF0b3Igc2hvdWxkIG5vdCBpbmNsdWRlIGFueSB0ZWNobm9sb2d5IGRl dGFpbHMgd2hpY2ggc2hvdWxkIGV4aXN0IGluIHRoZSBOQkkgb2YgY29udHJvbGxlci4gVGhlIG9y Y2hlc3RyYXRvciB3aWxsIGNvbXBsZXRlIHRoZSBtYXBwaW5nIGZyb20gTkJJIG9mIG9yY2hlc3Ry YXRvciB0byBOQkkgb2YgY29udHJvbGxlci4NCg0KIFRoZSB2aWV3IG9mIHRoaXMgdmFyaWVzIHdp bGRseSBhY3Jvc3Mgc3RhbmRhcmRzIGJvZGllcywgb3BlbiBzb3VyY2UgcHJvamVjdHMsIHZlbmRv cnMgYW5kIG1hbnkgb3RoZXIgZW50aXRpZXMgaW52b2x2ZWQuIEkuZS4gbW9zdCBvcmNoZXN0cmF0 b3JzIGRvIGxlYWsgdGVjaG5vbG9neSBkZXRhaWxzIGFuZCBOQklzIG9mIGNvbnRyb2xsZXJzIGNv bnRhaW4gYWJzdHJhY3Rpb25zIGFib3ZlIHRoZSBuZXR3b3JrIGxldmVsLg0KDQo+IExldCdzIHRh a2UgTDJWUE4gYXMgYSBleGFtcGxlLiBJbiB0aGUgTkJJIG9mIG9yY2hlc3RyYXRvciwgdGhlIHlh bmcgbW9kZWwganVzdCBuZWVkIGV4cHJlc3MgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIG9mIEwyVlBO LCBzdWNoIGFzLCBzaXRlcyBpbmZvcm1hdGlvbiBhbmQgdG9wb2xvZ3kgYmV0d2VlbiBzaXRlcy4g Rm9yIHRoZSBOQkkgb2YgY29udHJvbGxlciwgdGhlIHlhbmcgbW9kZWwgbWF5IGJlIHNvbWUgdGVj aG5vbG9neSBzb2x1dGlvbnMsIHN1Y2ggYXMsIFZQTFMsIFZQV1MsIGV0Yy4gVGhlIG9yY2hlc3Ry YXRvciB3aWxsIGNob29zZSBvbmUgb3Igc29tZSBzb2x1dGlvbnMgZGVwZW5kcyBvbiB1c2Vycycg cmVxdWlyZW1lbnQuIFRoZW4gdGhlIGNvbnRyb2xsZXIgd2lsbCBjb21wbGV0ZSB0aGUgbmV0d29y ayBlbGVtZW50IGNvbmZpZ3VyYXRpb24gKHVzaW5nIG5ldHdvcmsgZWxlbWVudCB5YW5nIG1vZGVs ICkgYWNjb3JkaW5nIHRvIHRlY2hub2xvZ3kgc29sdXRpb25zIGNob3NlbiBieSBvcmNoZXN0cmF0 b3IuDQoNCiBUaGF0IGlzIGFic29sdXRlbHkgb25lIHdheSBvZiBsb29raW5nIChhbmQgcGVyaGFw cyBldmVuIGltcGxlbWVudGluZykgaXQsIGFtb25nIHNldmVyYWwgb3RoZXJzLiBJbiB0aGlzIGNh c2UsIGFuZCB1bmRlciB0aGUgc3VnZ2VzdGVkIGNsYXNzaWZpY2F0aW9uIGluIHRoZSBkb2N1bWVu dCwgYm90aCB0aGUgY29udHJvbGxlciBhbmQgb3JjaGVzdHJhdG9yIG1vZGVscyB3b3VsZCBiZSBl eGFtcGxlcyBvZiBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscyB3aXRoIGRpZmZlcmVu dCBhYnN0cmFjdGlvbiBsZXZlbHMuDQoNCj4gVGhvdWdoIEkgYW0gbm90IHN1cmUgaWYgdGhlIHBy b2Nlc3MgaXMgc3VpdGFibGUsIHRoZSBzZXJ2aWNlIG1vZGVsIGFuZCBuZXR3b3JrIG1vZGVsIGFy ZSBkaWZmZXJlbmNlIHdoaWNoIGFyZSB1c2VkIGluIGRpZmZlcmVudCBwbGFjZXMuIEFueSBjb21t ZW50cz8NCg0KIEFib3ZlLg0KDQo+IA0KPiBCZXN0LA0KPiBZYWxpDQo+IA0KPiAtLS0tLemCruS7 tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSBbbWFpbHRv OmNhbW9iZXJnQGNpc2NvLmNvbV0gDQo+IOWPkemAgeaXtumXtDogMjAxNuW5tDTmnIgyMeaXpSAx NTo0Nw0KPiDmlLbku7bkuro6IHpoYW5neWFsaSAoRCkNCj4g5oqE6YCBOiBuZXRtb2RAaWV0Zi5v cmcNCj4g5Li76aKYOiBSZTogW25ldG1vZF0geWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlvbg0KPiAN Cj4gWWFsaSwNCj4gDQo+PiBPbiBBcHIgMjEsIDIwMTYsIGF0IDY6MDMgQU0sIHpoYW5neWFsaSAo RCkgPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgYWxsLA0KPj4g DQo+PiBJIG5vdGljZWQgdGhhdCB0aGVyZSBpcyBhIGRyYWZ0IGludGVudHMgdG8gY2xhc3NpZnkg dGhlIHZhcmlvdXMgeWFuZyBtb2RlbCwgaXQgaXMgcmVhbGx5IGEgbWVhbmluZ2Z1bCB3b3JrLiBN YW55IHBvaW50cyBhcmUgY29uc2lzdGVudCB3aXRoIG15IHVuZGVyc3RhbmRpbmcsIHdoZXJlYXMs IHRoZXJlIGFyZSBzb21lIHF1ZXN0aW9ucyB1bmNsZWFyIG5lZWQgdG8gaW5xdWlyZS4NCj4+IA0K Pj4gMS4gICAgICAgV2h5IFZQTFMgYW5kIFZQV1MgYXJlIGFsbCBzZXJ2aWNlIG1vZGVsLCB3aGlj aCBpcyBhdCB0aGUgc2FtZSBsZXZlbCB3aXRoIEwzVlBOPyBJbiBteSB1bmRlcnN0YW5kaW5nLCBM M1ZQTiBpcyBhIHR5cGljYWwgc2VydmljZSBtb2RlbCB3aGljaCBoaWRlcyB0aGUgdW5kZXJsYXkg bmV0d29yaywgYnV0IGJvdGggVlBMUyBhbmQgVlBXUyBpcyBzcGVjaWZpYyB0ZWNobm9sb2d5IHNv bHV0aW9ucy4gTWF5YmUgYSB1bmlmb3JtIEwyVlBOIHdoaWNoIGFic3RyYWN0cyBzZXJ2aWNlIGlu Zm9ybWF0aW9uIGZyb20gYWxsIGxheWVyMiB0ZWNobm9sb2dpZXMgbW9yZSBsaWtlIHNlcnZpY2Ug bW9kZWwuDQo+IA0KPiBTZWN0aW9uIDIuMSBnb2VzIHRvIHNvbWUgbGVuZ3RoIHRvIGRlc2NyaWJl IHRoYXQgdGhlcmUgYXJlIHZhcmlvdXMgdHlwZXMgb2YgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0 YSBNb2RlbHMgYXQgdmFyaW91cyBsZXZlbHMgb2YgYWJzdHJhY3Rpb25zLiBUaGlzIG1lYW5zIHRo YXQgYm90aCBnZW5lcmljIG1vZGVscyAoZS5nLiBhIHRlY2hub2xvZ3kgYWdub3N0aWMgTDMgVlBO IG1vZGVsKSBhbmQgbW9yZSBpbXBsZW1lbnRhdGlvbi1vcmllbnRlZCBtb2RlbHMgKGUuZy4gVlBM Uykgd291bGQgYmUgY2xhc3NpZmllZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVs cyB3aXRob3V0IGJlaW5nIGF0IHRoZSBleGFjdCBzYW1lIGxldmVsIG9mIGFic3RyYWN0aW9uLg0K PiANCj4+IDIuICAgICAgIFdoYXQgaXMgdGhlIGxheWVyIG9mIHRlY2hub2xvZ3kgc29sdXRpb25z LCBzdWNoIGFzLCBWeExBTiwgR1JFLCBWUExTLCBldGM/DQo+IA0KPiBJZiB5b3UgYXJlIHRhbGtp bmcgYWJvdXQgVnhMQU4sIEdSRSwgVlBMUyBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBw YXJhbWV0ZXJzIHJlc2lkaW5nIG9uIGEgZGV2aWNlLCB0aGVuIGl04oCZcyBOZXR3b3JrIEVsZW1l bnQgWUFORyBEYXRhIG1vZGVscy4gSWYgeW914oCZcmUgdGFsa2luZyBhYm91dCBWeExBTiwgR1JF LCBWUExTIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgYXMgcGFydCBv ZiBhbiAiYWJzdHJhY3QgbW9kZWwgdGhhdCBhbGxvd3MgaW5zdGFuY2VzIG8gdGhlIHNlcnZpY2Ug dG8gYmUgZGVjb21wb3NlZCBpbnRvIGluc3RhbmNlIGRhdGEgYWNjb3JkaW5nIHRvIHRoZSBOZXR3 b3JrIEVsZW1lbnQgZGF0YSBtb2RlbHMgb2YgdGhlIHBhcnRpY2lwYXRpbmcgbmV0d29yayBlbGVt ZW50c+KAnSwgdGhlbiBpdCB3b3VsZCBiZSBjbGFzc2lmaWVkIGFzIGEgTmV0d29yayBTZXJ2aWNl IFlBTkcgRGF0YSBNb2RlbHMuIA0KPiANCj4+IDMuICAgICAgIEluIFRNTiBNLjMwMTAsIG5ldHdv cmsgbW9kZWwgYWxzbyBhIHBhcnRpY3VsYXIgbGF5ZXIsIHNob3VsZCBzcGVjaWZpYyB5YW5nIG1v ZGVsIGNvdmVyIHRoaXMgbGF5ZXI/DQo+IA0KPiBJIGhhdmUgZG9uZSBzb21lIHJlYWRpbmcgb24g TS4zMDEwIGFuZCBiZWxpZXZlIHdlIGFyZSB3ZWxsIGFsaWduZWQgaW4gdGhlIGRyYWZ0LiBUaGUg bmV0d29yayBtb2RlbCB3b3VsZCBiZSBjbGFzc2lmaWVkIGFkIGFzIE5ldHdvcmsgU2VydmljZSBZ QU5HIERhdGEgTW9kZWwuDQo+IA0KPj4gQmVzdCBSZWdhcmRzLA0KPj4gWWFsaQ0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCg0K From nobody Thu Apr 21 01:45:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF2612D5F6 for ; Thu, 21 Apr 2016 01:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7qthbixA6sE for ; Thu, 21 Apr 2016 01:45:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 04B6612D5B0 for ; Thu, 21 Apr 2016 01:45:12 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 363471AE034F; Thu, 21 Apr 2016 10:45:10 +0200 (CEST) Date: Thu, 21 Apr 2016 10:45:23 +0200 (CEST) Message-Id: <20160421.104523.1036688066875225335.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: <20160419.105021.2152837727269070493.mbj@tail-f.com> References: <20160419.105021.2152837727269070493.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] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:45:14 -0000 Hi Andy, Are you ok with the proposed OLD/NEW changes? /martin Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, delete) > > Is says [default-stmt] but it should be *default-stmt > > Thanks, fixed. > > But for deviate-replace, it is not clear what the correct answer is. > > This is pretty clear: > > leaf foo { > type int32; > default 42; > } > > deviation /foo { > deviate replace { > default 10; > } > } > > But what about this: > > leaf-list bar { > type int32; > default 42; > default 43; > } > > deviation /bar { > deviate replace { > default 10; > default 11; > } > } > > Are all defaults changed? > > Compare with must and unique - they can not be replaced currently. > > In order to resolve this we probably need more text as well :( > > > OLD: > > The argument "replace" replaces properties of the target node. The > properties to replace are identified by substatements to the > "deviate" statement. The properties to replace MUST exist in the > target node. > > > NEW: > > The argument "replace" replaces properties of the target node. The > properties to replace are identified by substatements to the > "deviate" statement. The properties to replace MUST exist in the > target node. If multiple properties exist in the target node, all > of them are replaced with the new properties defined in the > substatements to the deviate statement. > > + add an example to the section "Usage examples": > > NEW: > > In this example, the original definition of a leaf list has two > default values "42" and "43: > > leaf-list bar { > type int32; > default 42; > default 43; > } > > A server can change this to the values "10" and "11" instead: > > deviation /base:bar { > deviate replace { > default 10; > default 11; > } > } > > > Also, change the grammar: > > OLD: > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [type-stmt] > [units-stmt] > [default-stmt] > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > "}") stmtsep > > NEW: > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [type-stmt] > [units-stmt] > *must-stmt > *unique-stmt > *default-stmt > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt] > "}") stmtsep > > > > > > > Is it intentional that the ABNF for deviate-delete-stmt leaves out > > config, mandatory, max-elements, and min-elements? > > I understand why "type" cannot be removed. > > I don't really remember, but I can see that if you want to "delete" > min-elements you can replace it and set it to 0. > > > IMO the rest of the statements should be removable. > > > Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. > > This section should make it clear a leaf has only 1 default > > and the 0..n refers to leaf-list only. > > In general, the result after applying deviations must be valid - e.g., > you cannot deviate "foo" as the default for an int32 leaf. > > > It should also be clear that the "deviate add default" for a leaf-list > > is YANG statement order-dependent. > > > > Not as obvious -- a config=false leaf-list can have duplicate default > > values. > > The deviate-stmt has no way to specify which 1 to delete or replace > > if there are duplicates. > > Unless replace will replace *all*, as suggested above. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Apr 21 03:24:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420D112D6A7 for ; Thu, 21 Apr 2016 03:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxx3ig7GkFZ0 for ; Thu, 21 Apr 2016 03: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 A33C712D0E6 for ; Thu, 21 Apr 2016 03:23:58 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 347BC1AE034F; Thu, 21 Apr 2016 12:23:56 +0200 (CEST) Date: Thu, 21 Apr 2016 12:24:09 +0200 (CEST) Message-Id: <20160421.122409.329112641806495413.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <571652B4.6000005@cisco.com> References: <56D5B319.90703@cisco.com> <571652B4.6000005@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 10:24:01 -0000 Hi Benoit, Benoit Claise wrote: > Dear all, > > Here is part 1 of my AD review. > > I found this useful: > http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt > > - Do we want to mention RESTCONF in the abstract? From the new charter: > > The NETMOD working group has defined the data modeling language > YANG, which can be used to specify network management data models > that are transported over such protocols as NETCONF and RESTCONF. > > OLD: > > YANG is a data modeling language used to model configuration data, > state data, remote procedure calls, and notifications for network > management protocols like the Network Configuration Protocol > (NETCONF). > > NEW: > > YANG is a data modeling language used to model configuration data, > state data, remote procedure calls, and notifications for network > management protocols transported over such protocols as Network > Configuration Protocol (NETCONF) and RESTCONF. This document specifies > the YANG mappings to NETCONF. The first paragraph in the introduction mentions other protocols; RESCTONF and CoMI. My personal opinion is that this is sufficient, but I'd like to hear what others think. > - Section 1.1 > Can we want to stress the backwards incompatible changes from YANG > version 1 in a specific paragraph? Ok, this is a good idea. I'll move them to a separate list. > I see > o Changed the rules for the interpretation of escaped characters in > double quoted strings. This is an backwards incompatible change > from YANG version 1. A module that uses a character sequence that > is now illegal must change the string to match the new rules. See > Section 6.1.3 > > for details. > > o An unquoted string cannot contain any single or double quote > characters. This is an backwards incompatible change from YANG > version 1. > > > There is section 12, but this is not exactly that. > > Have we made an analysis of the 38 RFC-produced YANG modules? Any > facing issues with 1.1 compilation? I have tested to put "yang-version 1.1;" into all RFC-published modules, and then ran pyang on them w/o any issues. > - Section 1.1 > Since this document introduces the NETCONF mapping, the protocol > change must be included in section 1.1 > Example: no NETCONF capability exchange in YANG 1.1, we use > exclusively the YANG library > Any other ones? > - Section 3 > o anydata: A data node that can contain an unknown set of nodes that > can be modelled by YANG. > > NEW > > o anydata: A data node that can contain an unknown set of nodes that > can be modelled by YANG, except anyxml, but for which the data > model is not known at module design time. Ok, but I'd say: NEW: o anydata: A data node that can contain an unknown set of nodes that can be modelled by YANG, except anyxml. This is just a summary; the details are to be found in later sections. > - Terminology: > The following terms are defined in [RFC6241 > ]: > > ... > > o configuration datastore: a configuration datastore is an > instantiated data tree with configuration data > > o datastore: an instantiated data tree > > RFC6241 has different definition for "configuration datastore" and > "datastore". > I would just provide the pointer to the RFC 6241 definitions. > If you intend to provide an adapted definition for the YANG mappings, > then you should say so. How about: OLD: o configuration datastore: a configuration datastore is an instantiated data tree with configuration data o datastore: an instantiated data tree NEW: o configuration datastore: When modelled with YANG, a configuration datastore is an instantiated data tree with configuration data o datastore: When modelled with YANG, an instantiated data tree > - Section 4.1 > > YANG models can describe constraints to be enforced on the data, > restricting the appearance or value of nodes based on the presence or > value of other nodes in the hierarchy. > > I was looking for an example of appearance. > NEW? > YANG models can describe constraints to be enforced on the data, > restricting the appearance (for example, with the "when" statement) > or value of nodes based on the presence or value of other nodes in > the hierarchy. This is very early in the document, and the text tries to give a very high level function overview. I am not sure that mentioning "when" at this time actually helps a first time reader. I would prefer to leave it as it is. > - section 4.2.2.3, Container Nodes > > A container is used to group related nodes in a subtree. A container > has only child nodes and no value. A container may contain any > number of child nodes of any type (leafs, lists, containers, leaf- > lists, and actions). > And notification, right? This should be added Ok. > container-stmt = container-keyword sep identifier-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [when-stmt] > *if-feature-stmt > *must-stmt > [presence-stmt > ] > [config-stmt] > [status-stmt] > [description-stmt] > [reference-stmt] > *(typedef-stmt / grouping-stmt) > *data-def-stmt > *action-stmt > *notification-stmt > "}") stmtsep > > - Examples > I guess that no examples are supposed to compile, right? > Please add a sentence saying so. I honestly does not think that this is an issue, but how about this: NEW: 3.1. A Note on Examples Throughout this document there are many examples of YANG statements. These examples are supposed to illustrate certain features, and are not supposed to be complete, valid YANG modules. > When Andy's proposal will be ready (TAG: EXAMPLE-BEGINS => the YANG > example compiles, NO TAG: => no supposed to compile), this document > will already be compliant. > > - Section 4.2.4 > > +---------------------+-------------------------------------+ > | Name | Description | > +---------------------+-------------------------------------+ > | binary | Any binary data | > | bits | A set of bits or flags | > | boolean | "true" or "false" | > | decimal64 | 64-bit signed decimal number | > | empty | A leaf that does not have any value | > | enumeration | Enumerated strings | > | identityref | A reference to an abstract identity | > | instance-identifier | References a data tree node | > > Editorial: What the difference between: A reference or references? Be > consistent No difference. I'll change to A reference. > - Section4.2.7 > - . > - Choices > > To be consistent with > > When a node from one case is created in the data tree, all nodes from > all other cases are implicitly deleted. > > > This text in section 7.9 should be updated. > OLD: > Since only one of the choice's cases can be valid at any time, the > creation of a node from one case implicitly deletes all nodes from > all other cases. If a request creates a node from a case, the server > will delete any existing nodes that are defined in other cases inside > the choice. > > NEW: > Since only one of the choice's cases can be valid at any time_in the > data tree_, the > creation of a node from one case implicitly deletes all nodes from > all other cases. If a request creates a node from a case, the server > will delete any existing nodes that are defined in other cases inside > the choice. Ok. > - Section 4.2.9 > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > example-fw-2.3 > > > > Editorial: Alignment Fixed. > - Editorial: is there a logic in the numbering? > - section 4.2.9 > > Operations can also be tied to a > data node. Such operations are defined with the "action" statement. > > From the definition: > o data node: A node in the schema tree that can be instantiated in a > data tree. One of container, leaf, leaf-list, list, anydata, and > anyxml. > > And I see in section 7.15: > The "action" statement is used to define an operation connected to a > specific container or list data node. > > > I believe it should be clarified in 4.2.9 > NEW: > Operations can also be tied to a > container or list data node. Such operations are defined with the > "action" statement. Ok. > - Section 5.1 > Editorial > OLD: > o A module or submodule belonging to that module can reference > definitions in the module and all submodules included by the > module. > > NEW? > o A module, or submodule belonging to that module, can reference > definitions in the module and all submodules included by that > module. Yes, fixed. > - The following examples (as far as my quick check goes) are the only > - one that misses "yang-version 1.1" > > module example-augment { > namespace "urn:example:augment"; > prefix mymod; > import ietf-interfaces { > prefix if; > } > > module example-a { > namespace urn:example:a; > prefix a; Fixed. > - Section 5.6.4 > If a server implements a module A that imports a module B, and A uses > any node from B in an "augment" or "path" statement that the server > supports, then the server MUST implement a revision of module B that > has these nodes defined. This is regardless of if module B is > imported by revision or not. > > "imported by revision or not" I'm, confused because I read the > document in sequence. > From 5.1 and 5.1.1, it doesn't look like we have two options (import > by revision or not) > And the example shows the two possibilities: > import b { > revision-date 2015-01-01; > } > import c; > > I found my answer in section 7.1.5: > When the optional "revision-date" substatement is present, any > typedef, grouping, extension, feature, and identity referenced by > definitions in the local module are taken from the specified revision > of the imported module. It is an error if the specified revision of > the imported module does not exist. If no "revision-date" > substatement is present, it is undefined from which revision of the > module they are taken. > > You should write a sentence or two (imported by revision or not) about > in section 5.1 or 5.1.1 OLD: Published modules evolve independently over time. In order to allow for this evolution, modules need to be imported using specific revisions. When a module is written, it uses the current revisions of other modules, based on what is available at the time. NEW: Published modules evolve independently over time. In order to allow for this evolution, modules can be imported using specific revisions. When a module is written, it can import the current revisions of other modules, based on what is available at the time. And then a new paragraph last in the same section (5.1.1): NEW: If a module is not imported with a specific revision, it is undefined which excat revision is used. > - section 5.6.4 > A server MUST NOT implement more than one revision of a module. > > You should add that the server may contain more than one version for > import reasons. > This would be in line with > https://tools.ietf.org/html/draft-ietf-netconf-yang-library-05 > > This mandatory list contains one entry for each YANG data model > module supported by the server. There MUST be an entry in this list > for each revision of each YANG module that is used by the server. It > is possible for multiple revisions of the same module to be imported, > in addition to an entry for the revision that is implemented by the > server. I started to write some text to address this issue, but it felt out of place. This section is about modules that are implemented. Other modules can be listed according to yang-library; but that is a yang-library issue, not YANG 1.1. So I prefer to leave this section as it is. > - section 5.6.4 > ietf-yang-library comes out of the blue in section 5.6.4 > > If a server implements a module A that imports a module C without > specifying the revision date of module C, and the server does not > implement C (e.g., if C only defines some typedefs), the server MUST > list module C in the "/modules-state/module" list from > "ietf-yang-library" [I-D.ietf-netconf-yang-library > ], > and it MUST set > the leaf "conformance-type" to "import" for this module. > > You should say a few words about it in section 4. > Alternatively, the content in 5.6.5 should come before 5.6.4 Agreed. I switched the order of 5.6.4 and 5.6.5, and added a forward reference: A NETCONF server announces the modules it implements (Section 5.6.5) > - Some statements in the ABNF section contains links. Intended? Talking > - with Martin, he submitted only the .txt version. > So it seems that the issues resides in the ietf submission tool > chain. To be solved during AUTH48, I guess. > > Example: > > container-stmt = container-keyword sep identifier-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [when-stmt] > *if-feature-stmt > *must-stmt > [presence-stmt > ] > ... > > > refine-stmt = refine-keyword sep refine-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > *must-stmt > [presence-stmt] > [default-stmt] > [config-stmt] > [mandatory-stmt] > [min-elements-stmt] > [max-elements-stmt > ] > [description-stmt] > [reference-stmt] > "}" stmtsep Ok. /martin From nobody Thu Apr 21 05:41:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6EF12EC1C for ; Thu, 21 Apr 2016 05:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVynvV9dGI52 for ; Thu, 21 Apr 2016 05:41:31 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9227912EC19 for ; Thu, 21 Apr 2016 05:41:30 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id v14so45889415qge.0 for ; Thu, 21 Apr 2016 05:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=6DLcpxomUXphR3ooWEUUtn3/i4+7VUsXshA6x5ui4xI=; b=hq0MhvcK4tTmdiSfhyWDFPgZh9/4RMUTjnZTlyXdaJeHXP4dsyG8U8k+SM9r4UmO47 lDeQglZ/Rj4CW57n9eSp51VghZPoTyTsihhupuyuYrswi4g3ZUIvkw9gRfNc5L52oWCn u8ApJuePeUeJU/+52j69dC6PLHoMW5YwG/nRUjGj03ELSedc9z0CCDtCyLn1PtFoAYMo RM9dKoLYWK2WGRy2ej7/i9/b4LFk8qRUJA0KpDTCTa2QFGCoHFyvfenEDy84m/BgcenP e9k09dVqXku60hIshc4CXqzmjFi9weH4IJRTpvA3rxGV2Qz/1ggPd79i+d6Ohy8yRhW3 zMjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6DLcpxomUXphR3ooWEUUtn3/i4+7VUsXshA6x5ui4xI=; b=W5Va3hvOPBDqXsCWc6XsZqDNg85j4g4EM2HGH3VEvUOXMGVOaNXzVdswNrgw+SOfcM vVb8509BEayP7+ybyOVvqGhogva2hR1OuOWmQ7vbDkoalclUM3N8PAgzZuLqZlKF5/40 /3PIQvSf1oFq1zy15f5/+1vLecq87UpbsyUzYjcNb2SvlrFXKRbopBVkkwdc1nbDuFoy GmPWxZleB7rw11AADfWfe9nV/h1RcXLEb0rnRuY4JXnB/Bp1tKjqxhETE9rUUMUDbynV NR8XfvFcTiEarPGBIqZXNOnTRQlwcptG9cHqd0MGEBFW+qumjqfhhjVsnyVM3jBnjC8/ NUPQ== X-Gm-Message-State: AOPr4FXCCYldV1qC0vut+RLaJcmpgwWwgIyQq4EpFaP9ewsCNQ7R/+LG92oIa6rtAGUiPw== X-Received: by 10.140.246.86 with SMTP id r83mr17425139qhc.65.1461242489712; Thu, 21 Apr 2016 05:41:29 -0700 (PDT) Received: from [10.0.1.3] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id e11sm356818qhe.2.2016.04.21.05.41.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 05:41:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5AB18B6A-54DD-4823-B4AC-5FDA5945D0A7" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: Date: Thu, 21 Apr 2016 08:41:28 -0400 Message-Id: <0EC4FCB5-1228-4D98-AC5C-12961765AA5D@gmail.com> References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com> To: "Sterne, Jason (Nokia - CA)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: netmod WG Subject: Re: [netmod] input Interface match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:41:32 -0000 --Apple-Mail=_5AB18B6A-54DD-4823-B4AC-5FDA5945D0A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Any other opinions on this issue? There were quite a few hands in the = air during the WG meeting Dean > On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) = wrote: >=20 > Hi Dean, > =20 > We should remove the metadata grouping from the base model. It is out = of place with the rest of the model and a fairly clean line to draw as a = boundary for future extension/augmentation. > =20 > Regards, > Jason > =20 > From: EXT Dean Bogdanovic [mailto:ivandean@gmail.com]=20 > Sent: Friday, April 08, 2016 9:25 > To: Sterne, Jason (Nokia - CA) > Cc: netmod WG > Subject: Re: [netmod] input Interface match > =20 > Jason, > =20 > After looking at the document and the model, it is also about having = metadata grouping in the model. If you want to have metadata grouping in = the model, then you have to have something inside and then = input-interface questions comes up. If you don=E2=80=99t have to have = metadata grouping in the base model, everything is easy. > =20 > I believe this is the right question > =20 > Dean > =20 > On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) = > wrote: > =20 > Hi Dean, > =20 > Just to clarify -> the main question posed in the WG meeting was about = the input-interface match criteria. =46rom the meeting minutes: > =20 > Chairs: call for if interface should be in base: > 6 prefer NOT having it in the doc at all > 5 prefer having it in, but as a feature > 2 prefer having it in the doc as required > =20 > Maybe we should get agreement on what to do about input-interface (on = the list) first and then we can figure out what to do about the metadata = grouping. > =20 > Matching on basic IPv4/IPv4/MAC header fields is common functionality. = But having that input-interface match on metadata in the core model is = out of place. It should be left to further extension drafts or vendor = specific augmentations (along with whatever other metadata might be = useful or vendor-specific). Many major implementations do not support = matching on input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, = others). The typical way to associate ACLs and Interfaces is by = assigning an ACL to an interface as shown in section A.3. of the ACL = draft. There is some discussion of this on the NETMOD thread =E2=80=9CRe= move input-interface (metadata) from netmod-acl-model-07 ?=E2=80=9D. > =20 > Regards, > Jason > =20 > From: netmod [mailto:netmod-bounces@ietf.org = ] On Behalf Of EXT Dean Bogdanovic > Sent: Thursday, April 07, 2016 11:12 > To: netmod WG > Subject: [netmod] input Interface match > =20 > As the action item from the netmod WG and, hopefully, last open item = in the ACL draft is the leaf input interface in the metadata grouping=20 > =20 > grouping metadata { > description > "Fields associated with a packet which are not in > the header."; > leaf input-interface { > type if:interface-ref { > require-instance false; > } > description > "Packet was received on this interface."; > } > } > } > =20 > =20 > Here are two questions: > One > Do want to have a metadata grouping in the basic ACL model? If yes, we = have to put in some leafs in there. There are implementations which use = metadata as match condition > =20 > If we agree that metadata grouping is not needed in the basic model, = then the authors would remove the grouping from the model and I believe = that no more discussion is needed on this point > =20 > Dean --Apple-Mail=_5AB18B6A-54DD-4823-B4AC-5FDA5945D0A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Any other opinions on this issue? There were quite a few = hands in the air during the WG meeting

Dean

On = Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> wrote:

Hi = Dean,
 
We should remove the = metadata grouping from the base model.  It is out of place with the = rest of the model and a fairly clean line to draw as a boundary for = future extension/augmentation.
 
Regards,
Jason
 
From: EXT Dean = Bogdanovic [mailto:ivandean@gmail.com] 
Sent: Friday, April 08, 2016 = 9:25
To: Sterne, Jason (Nokia - = CA)
Cc: netmod WG
Subject: Re: [netmod] input = Interface match
 
Jason,
 
After looking at the document and the model, it is = also about having metadata grouping in the model. If you want to have = metadata grouping in the model, then you have to have something inside = and then input-interface questions comes up. If you don=E2=80=99t have = to have metadata grouping in the base model, everything is easy.
 
I believe this is the right question
 
Dean
 
On Apr 8, 2016, at = 9:20 AM, Sterne, Jason (Nokia - CA) <jason.sterne@nokia.com> = wrote:
 
Hi Dean,
 
Just to clarify -> = the main question posed in the WG meeting was about the input-interface = match criteria.  =46rom the meeting minutes:
 
Chairs: call for if = interface should be in base:
    6 prefer NOT having it = in the doc at all
    5 prefer having it in, = but as a feature
    2 prefer having it in = the doc as required
 
Maybe we should get = agreement on what to do about input-interface (on the list) first and = then we can figure out what to do about the metadata = grouping.
 
Matching on basic IPv4/IPv4/MAC header = fields is common functionality.  But having that input-interface = match on metadata in the core model is out of place.  It should be = left to further extension drafts or vendor specific augmentations (along = with whatever other metadata might be useful or vendor-specific). Many = major implementations do not support matching on input-interface (Cisco = IOS-XR, Nokia SR OS, Brocade, others).  The typical way to = associate ACLs and Interfaces is by assigning an ACL to an interface as = shown in section A.3. of the ACL draft.   There is some = discussion of this on the NETMOD thread =E2=80=9CRemove input-interface = (metadata) from netmod-acl-model-07 ?=E2=80=9D.
 
Regards,
Jason
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf = Of EXT Dean = Bogdanovic
Sent: Thursday, April 07, 2016 = 11:12
To: netmod WG
Subject: [netmod] input Interface = match
 
As the action item from the netmod WG and, hopefully, last = open item in the ACL draft is the leaf input interface in the metadata = grouping 
 
grouping metadata {
    description
      "Fields associated with a =
packet which are not in
      =
the header.";
    leaf =
input-interface {
      =
type if:interface-ref {
        require-instance =
false;
      =
}
      description
        "Packet was =
received on this interface.";
    =
}
  }
}
 
 
Here = are two questions:
One
Do want to have a = metadata grouping in the basic ACL model? If yes, we have to put in some = leafs in there. There are implementations which use metadata as match = condition
 
If we agree that metadata grouping is not = needed in the basic model, then the authors would remove the grouping = from the model and I believe that no more discussion is needed on this = point
 
Dean

= --Apple-Mail=_5AB18B6A-54DD-4823-B4AC-5FDA5945D0A7-- From nobody Thu Apr 21 06:33:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9253D12DC62 for ; Thu, 21 Apr 2016 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InIQP5AgWqsS for ; Thu, 21 Apr 2016 06:33: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 490C812D8D3 for ; Thu, 21 Apr 2016 06:33:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9B75B116C; Thu, 21 Apr 2016 15:33: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 Y9iM7Elbpd9d; Thu, 21 Apr 2016 15:32:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Apr 2016 15:33:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E18320082; Thu, 21 Apr 2016 15:33: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 yyJtZ-ayXs3x; Thu, 21 Apr 2016 15:33: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 C57BD2007F; Thu, 21 Apr 2016 15:33:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 00E253AAC6EF; Thu, 21 Apr 2016 15:33:05 +0200 (CEST) Date: Thu, 21 Apr 2016 15:33:05 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160421133305.GA8123@elstar.local> Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, netmod@ietf.org References: <56D5B319.90703@cisco.com> <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160421.122409.329112641806495413.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 13:33:19 -0000 On Thu, Apr 21, 2016 at 12:24:09PM +0200, Martin Bjorklund wrote: > Hi Benoit, > > Benoit Claise wrote: > > Dear all, > > > > Here is part 1 of my AD review. > > > > I found this useful: > > http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt > > > > - Do we want to mention RESTCONF in the abstract? From the new charter: > > > > The NETMOD working group has defined the data modeling language > > YANG, which can be used to specify network management data models > > that are transported over such protocols as NETCONF and RESTCONF. > > > > OLD: > > > > YANG is a data modeling language used to model configuration data, > > state data, remote procedure calls, and notifications for network > > management protocols like the Network Configuration Protocol > > (NETCONF). > > > > NEW: > > > > YANG is a data modeling language used to model configuration data, > > state data, remote procedure calls, and notifications for network > > management protocols transported over such protocols as Network > > Configuration Protocol (NETCONF) and RESTCONF. This document specifies > > the YANG mappings to NETCONF. > > The first paragraph in the introduction mentions other protocols; > RESCTONF and CoMI. My personal opinion is that this is sufficient, > but I'd like to hear what others think. I agree with less is more since we do not know how many protocols will eventually transport YANG-defined data. What I like about Benoit's proposal is that it clearly says that this document provides the mappings to NETCONF. So how about this? YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). /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 Apr 21 06:34:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3B612D11C for ; Thu, 21 Apr 2016 06:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.518 X-Spam-Level: X-Spam-Status: No, score=-15.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rQ_1-n3I4gy for ; Thu, 21 Apr 2016 06:34:45 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B1812B059 for ; Thu, 21 Apr 2016 06:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9530; q=dns/txt; s=iport; t=1461245685; x=1462455285; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=n05fRozrH0hREcmGeCPNg9KWHC+tJzMY2+sSiV/mfaQ=; b=OKHNAoq90OB9QOAFYoNXLtassXK7TbWooLh2DMBrjNE+9LZYvJSn+qEn zvsZWz1+X3koycqVnAahBXeSLya5sooPj7dO3YOgISapj6YqfUMc3kL2Q a1+DC9Llv77NfeL7siuyZEP4RdhLFC7xO93Knq/z14XY6DqWZWTAm4yYc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQB91hhX/xbLJq1VCYQLfblvAQ2Bc?= =?us-ascii?q?x2FcQKBaRQBAQEBAQEBZSeEQgEBBDhAARALDgoJFg8JAwIBAgFFBg0GAgEBBYg?= =?us-ascii?q?hDr9IAQEBAQEBAQEBAQEBAQEBAQEBAReGIYNJgQKEFhGFbgEEmA+Fe4J1hSSBZ?= =?us-ascii?q?k6Df4MGI4U0jy0eAQFCg2o6MAEBAQGIcgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="676855338" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 13:34:41 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3LDYeoW007672; Thu, 21 Apr 2016 13:34:41 GMT To: Martin Bjorklund References: <56D5B319.90703@cisco.com> <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> From: Benoit Claise Message-ID: <5718D6F1.5040902@cisco.com> Date: Thu, 21 Apr 2016 15:34:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160421.122409.329112641806495413.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] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:34:47 -0000 Hi Martin, Thanks for engaging quickly. [I removed the resolved entries] > Hi Benoit, > > Benoit Claise wrote: >> Dear all, >> >> Here is part 1 of my AD review. >> >> I found this useful: >> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt >> >> - Do we want to mention RESTCONF in the abstract? From the new charter: >> >> The NETMOD working group has defined the data modeling language >> YANG, which can be used to specify network management data models >> that are transported over such protocols as NETCONF and RESTCONF. >> >> OLD: >> >> YANG is a data modeling language used to model configuration data, >> state data, remote procedure calls, and notifications for network >> management protocols like the Network Configuration Protocol >> (NETCONF). >> >> NEW: >> >> YANG is a data modeling language used to model configuration data, >> state data, remote procedure calls, and notifications for network >> management protocols transported over such protocols as Network >> Configuration Protocol (NETCONF) and RESTCONF. This document specifies >> the YANG mappings to NETCONF. > The first paragraph in the introduction mentions other protocols; > RESCTONF and CoMI. My personal opinion is that this is sufficient, > but I'd like to hear what others think. The current abstract doesn't even mention the mapping to NETCONF. > > >> >> Have we made an analysis of the 38 RFC-produced YANG modules? Any >> facing issues with 1.1 compilation? > I have tested to put "yang-version 1.1;" into all RFC-published > modules, and then ran pyang on them w/o any issues. Great. > >> - Section 1.1 >> Since this document introduces the NETCONF mapping, the protocol >> change must be included in section 1.1 >> Example: no NETCONF capability exchange in YANG 1.1, we use >> exclusively the YANG library >> Any other ones? And this one? >> - Section 3 >> o anydata: A data node that can contain an unknown set of nodes that >> can be modelled by YANG. >> >> NEW >> >> o anydata: A data node that can contain an unknown set of nodes that >> can be modelled by YANG, except anyxml, but for which the data >> model is not known at module design time. > Ok, but I'd say: > > NEW: > > o anydata: A data node that can contain an unknown set of nodes that > can be modelled by YANG, except anyxml. > > This is just a summary; the details are to be found in later sections. Sure. > > >> - Terminology: >> The following terms are defined in [RFC6241 >> ]: >> >> ... >> >> o configuration datastore: a configuration datastore is an >> instantiated data tree with configuration data >> >> o datastore: an instantiated data tree >> >> RFC6241 has different definition for "configuration datastore" and >> "datastore". >> I would just provide the pointer to the RFC 6241 definitions. >> If you intend to provide an adapted definition for the YANG mappings, >> then you should say so. > How about: > > OLD: > > o configuration datastore: a configuration datastore is an > instantiated data tree with configuration data > > o datastore: an instantiated data tree > > NEW: > > o configuration datastore: When modelled with YANG, a configuration > datastore is an instantiated data tree with configuration data > > o datastore: When modelled with YANG, an instantiated data tree > This issue is with "The following terms are defined in [RFC6241]", but you re-define those terms. So give a warning about the redefinition to the readers. > > >> - Section 4.1 >> >> YANG models can describe constraints to be enforced on the data, >> restricting the appearance or value of nodes based on the presence or >> value of other nodes in the hierarchy. >> >> I was looking for an example of appearance. >> NEW? >> YANG models can describe constraints to be enforced on the data, >> restricting the appearance (for example, with the "when" statement) >> or value of nodes based on the presence or value of other nodes in >> the hierarchy. > This is very early in the document, and the text tries to give a very > high level function overview. I am not sure that mentioning "when" at > this time actually helps a first time reader. The first time I read this, I was wondering how YANG data models can describe constraints on HOW data appear, while you wanted to express WHETHER a data appear. Maybe "when" is not the best way to help the first time user, but something is needed. > I would prefer to > leave it as it is. > > >> container-stmt = container-keyword sep identifier-arg-str optsep >> (";" / >> "{" stmtsep >> ;; these stmts can appear in any order >> [when-stmt] >> *if-feature-stmt >> *must-stmt >> [presence-stmt >> ] >> [config-stmt] >> [status-stmt] >> [description-stmt] >> [reference-stmt] >> *(typedef-stmt / grouping-stmt) >> *data-def-stmt >> *action-stmt >> *notification-stmt >> "}") stmtsep >> >> - Examples >> I guess that no examples are supposed to compile, right? >> Please add a sentence saying so. > > I honestly does not think that this is an issue, but how about this: > > NEW: > > 3.1. A Note on Examples > > Throughout this document there are many examples of YANG statements. > These examples are supposed to illustrate certain features, and are > not supposed to be complete, valid YANG modules. > Sure. > >> - Section 5.6.4 >> If a server implements a module A that imports a module B, and A uses >> any node from B in an "augment" or "path" statement that the server >> supports, then the server MUST implement a revision of module B that >> has these nodes defined. This is regardless of if module B is >> imported by revision or not. >> >> "imported by revision or not" I'm, confused because I read the >> document in sequence. >> From 5.1 and 5.1.1, it doesn't look like we have two options (import >> by revision or not) >> And the example shows the two possibilities: >> import b { >> revision-date 2015-01-01; >> } >> import c; >> >> I found my answer in section 7.1.5: >> When the optional "revision-date" substatement is present, any >> typedef, grouping, extension, feature, and identity referenced by >> definitions in the local module are taken from the specified revision >> of the imported module. It is an error if the specified revision of >> the imported module does not exist. If no "revision-date" >> substatement is present, it is undefined from which revision of the >> module they are taken. >> >> You should write a sentence or two (imported by revision or not) about >> in section 5.1 or 5.1.1 > OLD: > > Published modules evolve independently over time. In order to allow > for this evolution, modules need to be imported using specific > revisions. When a module is written, it uses the current revisions > of other modules, based on what is available at the time. > > NEW: > > Published modules evolve independently over time. In order to allow > for this evolution, modules can be imported using specific revisions. > When a module is written, it can import the current revisions of > other modules, based on what is available at the time. > > And then a new paragraph last in the same section (5.1.1): > > NEW: > > If a module is not imported with a specific revision, it is undefined > which excat revision is used. > Yes. >> - section 5.6.4 >> A server MUST NOT implement more than one revision of a module. >> >> You should add that the server may contain more than one version for >> import reasons. >> This would be in line with >> https://tools.ietf.org/html/draft-ietf-netconf-yang-library-05 >> >> This mandatory list contains one entry for each YANG data model >> module supported by the server. There MUST be an entry in this list >> for each revision of each YANG module that is used by the server. It >> is possible for multiple revisions of the same module to be imported, >> in addition to an entry for the revision that is implemented by the >> server. > I started to write some text to address this issue, but it felt out of > place. This section is about modules that are implemented. Other > modules can be listed according to yang-library; but that is a > yang-library issue, not YANG 1.1. Not YANG 1.1 but NETCONF/YANG 1.1 > So I prefer to leave this section > as it is. > > Regards, Benoit From nobody Thu Apr 21 06:44:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9C012D9EE for ; Thu, 21 Apr 2016 06:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81G2FWOMPDvd for ; Thu, 21 Apr 2016 06:43: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 7F7A712D122 for ; Thu, 21 Apr 2016 06:43:56 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C7BD1AE034F; Thu, 21 Apr 2016 15:43:52 +0200 (CEST) Date: Thu, 21 Apr 2016 15:44:05 +0200 (CEST) Message-Id: <20160421.154405.1631253100298639147.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160421133305.GA8123@elstar.local> References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <20160421133305.GA8123@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:43:59 -0000 Juergen Schoenwaelder wrote: > On Thu, Apr 21, 2016 at 12:24:09PM +0200, Martin Bjorklund wrote: > > Hi Benoit, > > > > Benoit Claise wrote: > > > Dear all, > > > > > > Here is part 1 of my AD review. > > > > > > I found this useful: > > > http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt > > > > > > - Do we want to mention RESTCONF in the abstract? From the new charter: > > > > > > The NETMOD working group has defined the data modeling language > > > YANG, which can be used to specify network management data models > > > that are transported over such protocols as NETCONF and RESTCONF. > > > > > > OLD: > > > > > > YANG is a data modeling language used to model configuration data, > > > state data, remote procedure calls, and notifications for network > > > management protocols like the Network Configuration Protocol > > > (NETCONF). > > > > > > NEW: > > > > > > YANG is a data modeling language used to model configuration data, > > > state data, remote procedure calls, and notifications for network > > > management protocols transported over such protocols as Network > > > Configuration Protocol (NETCONF) and RESTCONF. This document specifies > > > the YANG mappings to NETCONF. > > > > The first paragraph in the introduction mentions other protocols; > > RESCTONF and CoMI. My personal opinion is that this is sufficient, > > but I'd like to hear what others think. > > I agree with less is more since we do not know how many protocols will > eventually transport YANG-defined data. What I like about Benoit's > proposal is that it clearly says that this document provides the > mappings to NETCONF. So how about this? > > YANG is a data modeling language used to model configuration data, > state data, remote procedure calls, and notifications for network > management protocols. This document also specifies the YANG mappings > to the Network Configuration Protocol (NETCONF). Yes, this is better! /martin From nobody Thu Apr 21 06:50:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE98412E112 for ; Thu, 21 Apr 2016 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4--t5V28tNd for ; Thu, 21 Apr 2016 06:50:19 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6DB12DF40 for ; Thu, 21 Apr 2016 06:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2276; q=dns/txt; s=iport; t=1461246619; x=1462456219; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2g/cXL3Pq9sUmeaJFLgb6cNJ30tYRmycipOOjI8xb1s=; b=cLk+FgcPuDiv62PO7qdksUXMzlxJG0Ubbrpqqc7yQD9bBmmeEsqP+lcA StvEC8rAWN0RgtxNG1lXFPgMPkL08FBGLc1yZO1iIP+zScr42p0MrgQO+ QNGk3i9o7CNPZI0dcuLh9QpYgtW1aPmEu+0ZCxbjXEzWlrev0w8mAJLSR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQAc2hhX/xbLJq1ehAt9uW8BDYFzH?= =?us-ascii?q?YVxAoFpFAEBAQEBAQFlJ4RCAQEEOEABEAsOAggJFg8JAwIBAgFFBgEMBgIBAQW?= =?us-ascii?q?IIQ6/RwEBAQEBAQEBAQEBAQEBAQEBAQEBFoYhhEuKFQEEmA+Fe4gZgjSHBYVXj?= =?us-ascii?q?y0eAQFCg2o6MAEBAQGIcgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="634267714" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 13:50:17 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3LDoGGX023204; Thu, 21 Apr 2016 13:50:17 GMT To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <20160421133305.GA8123@elstar.local> <20160421.154405.1631253100298639147.mbj@tail-f.com> From: Benoit Claise Message-ID: <5718DA99.2030406@cisco.com> Date: Thu, 21 Apr 2016 15:50:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160421.154405.1631253100298639147.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] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:50:22 -0000 On 4/21/2016 3:44 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Thu, Apr 21, 2016 at 12:24:09PM +0200, Martin Bjorklund wrote: >>> Hi Benoit, >>> >>> Benoit Claise wrote: >>>> Dear all, >>>> >>>> Here is part 1 of my AD review. >>>> >>>> I found this useful: >>>> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt >>>> >>>> - Do we want to mention RESTCONF in the abstract? From the new charter: >>>> >>>> The NETMOD working group has defined the data modeling language >>>> YANG, which can be used to specify network management data models >>>> that are transported over such protocols as NETCONF and RESTCONF. >>>> >>>> OLD: >>>> >>>> YANG is a data modeling language used to model configuration data, >>>> state data, remote procedure calls, and notifications for network >>>> management protocols like the Network Configuration Protocol >>>> (NETCONF). >>>> >>>> NEW: >>>> >>>> YANG is a data modeling language used to model configuration data, >>>> state data, remote procedure calls, and notifications for network >>>> management protocols transported over such protocols as Network >>>> Configuration Protocol (NETCONF) and RESTCONF. This document specifies >>>> the YANG mappings to NETCONF. >>> The first paragraph in the introduction mentions other protocols; >>> RESCTONF and CoMI. My personal opinion is that this is sufficient, >>> but I'd like to hear what others think. >> I agree with less is more since we do not know how many protocols will >> eventually transport YANG-defined data. What I like about Benoit's >> proposal is that it clearly says that this document provides the >> mappings to NETCONF. So how about this? >> >> YANG is a data modeling language used to model configuration data, >> state data, remote procedure calls, and notifications for network >> management protocols. This document also specifies the YANG mappings >> to the Network Configuration Protocol (NETCONF). > Yes, this is better! Indeed. Regards, Benoit > > > /martin > > . > From nobody Thu Apr 21 06:59:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5933712B059 for ; Thu, 21 Apr 2016 06:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YLJ3KvulFja for ; Thu, 21 Apr 2016 06: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 1BC1E12DCB6 for ; Thu, 21 Apr 2016 06:58:45 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 45A7E1AE034F; Thu, 21 Apr 2016 15:58:44 +0200 (CEST) Date: Thu, 21 Apr 2016 15:58:57 +0200 (CEST) Message-Id: <20160421.155857.43464387853940362.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <5718D6F1.5040902@cisco.com> References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:58:58 -0000 Benoit Claise wrote: > Hi Martin, > > Thanks for engaging quickly. > [I removed the resolved entries] > > Hi Benoit, > > > > Benoit Claise wrote: > >> Dear all, > >> > >> Here is part 1 of my AD review. > >> > >> I found this useful: > >> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt > >> > >> - Do we want to mention RESTCONF in the abstract? From the new charter: > >> > >> The NETMOD working group has defined the data modeling language > >> YANG, which can be used to specify network management data models > >> that are transported over such protocols as NETCONF and RESTCONF. > >> > >> OLD: > >> > >> YANG is a data modeling language used to model configuration data, > >> state data, remote procedure calls, and notifications for network > >> management protocols like the Network Configuration Protocol > >> (NETCONF). > >> > >> NEW: > >> > >> YANG is a data modeling language used to model configuration data, > >> state data, remote procedure calls, and notifications for network > >> management protocols transported over such protocols as Network > >> Configuration Protocol (NETCONF) and RESTCONF. This document specifies > >> the YANG mappings to NETCONF. > > The first paragraph in the introduction mentions other protocols; > > RESCTONF and CoMI. My personal opinion is that this is sufficient, > > but I'd like to hear what others think. > The current abstract doesn't even mention the mapping to NETCONF. See Juergen's proposal, I think that one is better. > >> - Section 1.1 > >> Since this document introduces the NETCONF mapping, the protocol > >> change must be included in section 1.1 > >> Example: no NETCONF capability exchange in YANG 1.1, we use > >> exclusively the YANG library > >> Any other ones? > And this one? NEW: The following changes are done to the NETCONF mapping: o A server advertises support for YANG 1.1 modules by using ietf- yang-library [I-D.ietf-netconf-yang-library] instead of listing them as capabilities in the message. > >> - Terminology: > >> The following terms are defined in [RFC6241 > >> ]: > >> > >> ... > >> > >> o configuration datastore: a configuration datastore is an > >> instantiated data tree with configuration data > >> > >> o datastore: an instantiated data tree > >> > >> RFC6241 has different definition for "configuration datastore" and > >> "datastore". > >> I would just provide the pointer to the RFC 6241 definitions. > >> If you intend to provide an adapted definition for the YANG mappings, > >> then you should say so. > > How about: > > > > OLD: > > > > o configuration datastore: a configuration datastore is an > > instantiated data tree with configuration data > > > > o datastore: an instantiated data tree > > > > NEW: > > > > o configuration datastore: When modelled with YANG, a configuration > > datastore is an instantiated data tree with configuration data > > > > o datastore: When modelled with YANG, an instantiated data tree > > > This issue is with "The following terms are defined in [RFC6241]", but > you re-define those terms. > So give a warning about the redefinition to the readers. Yes, that's what my proposed text does. It says that "datastore" is defined in 6241, and when YANG is used, it means the instantiated data tree. > >> - Section 4.1 > >> > >> YANG models can describe constraints to be enforced on the data, > >> restricting the appearance or value of nodes based on the presence or > >> value of other nodes in the hierarchy. > >> > >> I was looking for an example of appearance. > >> NEW? > >> YANG models can describe constraints to be enforced on the data, > >> restricting the appearance (for example, with the "when" statement) > >> or value of nodes based on the presence or value of other nodes in > >> the hierarchy. > > This is very early in the document, and the text tries to give a very > > high level function overview. I am not sure that mentioning "when" at > > this time actually helps a first time reader. > The first time I read this, I was wondering how YANG data models can > describe constraints on HOW data appear, while you wanted to express > WHETHER a data appear. Maybe "when" is not the best way to help the > first time user, but something is needed. How about "restricting the presence or value of nodes"? /martin From nobody Thu Apr 21 08:18:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CD212EA1B for ; Thu, 21 Apr 2016 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xSwXVYFnWuL for ; Thu, 21 Apr 2016 08:18:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DE612E624 for ; Thu, 21 Apr 2016 08:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q3BEWVX6a4FZVh8vbRN8xpM7qnUT65TA3J6N6hq6MoA=; b=IQ3Dno3qHhUCAeuXru4lENNnqlCiu0MzyacxTHPp8QG4/E/oeNAUvIF9ZkYucZcvWeqfCSLuZgMexqi9gxVj1qOX4GaYkdutrpSlPpaROvtAJoysojDj8g2NmDEAvzVbEzTLYw5vF4As3AafuK2z/eWqt+WZOOfsZuj/NYfY/SQ= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 15:18:05 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 15:18:05 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft Thread-Index: AQHRc0XzOmgxKIY1jkmkuTyx7LV2V5+UmGeA Date: Thu, 21 Apr 2016 15:18:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: dd0444ea-3769-49c4-23a7-08d369f82368 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:ElySJ601LKj9FDtQmpYPwt9azKC8i/WHeHe4YbyM9mEOFzYB70lrKruGEKbrTHku3h0yqLQuJJh2BdglTxlGOgR7ExMeaoac0y4flcMkF2CLXsN+wmW3UDOSx23YBg/bM2hgdc3ntI5o/88wxv9+MuWRsGLHA8ewQls5uCLttKeYMr1/8dl2t3raEmQDLO9U; 24:RekPXbN0wCnlA+Z4//PUbLE11j1HMswQ53ivNot/0/zlFlVGzaU8H5fHwNLZo6SN74WFFmKih5eOhlecJGuiE34daS8ZkQl3xFs8TaZE3+w=; 7:chp0+r0LvcATljOWGzGGCZTP/kxAOvt7HIzeygRQ54R/Iegf25itz+Lpt9zOWsqaNAERZr8u9W+iR24l+C6GBxETMRfKTZ3QWzPa6dipRYinKYzqjNULYidjn6vvytMzq+YtanPenHyfxz6RaygafVBVN9JW6gNICYQ2xrSsFRtViJeMBG8BC3xWrHuLGihlKvIHL3wbqBMZXU886Ad6KAHHLwY1OFHfUpzQyvuGMZ8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(76176999)(5004730100002)(54356999)(1220700001)(1096002)(11100500001)(586003)(87936001)(86362001)(102836003)(2351001)(6116002)(5008740100001)(33656002)(189998001)(5002640100001)(3846002)(107886002)(110136002)(4001350100001)(450100001)(50986999)(77096005)(10400500002)(92566002)(122556002)(83506001)(81166005)(2900100001)(2950100001)(1730700002)(16236675004)(66066001)(19580405001)(5640700001)(230783001)(2906002)(3660700001)(19580395003)(3280700002)(36756003)(83716003)(106116001)(99286002)(82746002)(2501003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E81CA05BD3414CDF9F7E0CC40BFC041Cjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 15:18:05.5111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:18:08 -0000 --_000_E81CA05BD3414CDF9F7E0CC40BFC041Cjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpbSSB3YW50ZWQgdG8gZm9ybWFsbHkgY2xvc2UgdGhpcyB0aHJlYWQsIG1vZGVsZWQgYWZ0ZXIg TG91J3MgcmVjZW50IGNsb3N1cmUgb2YgYW5vdGhlciBkcmFmdF0NCg0KVGhpcyBwb2xsIGlzIGNv bXBsZXRlIGFuZCB0aGUgZG9jdW1lbnQgaXMgYWRvcHRlZCwNCg0KQXV0aG9ycywNCg0KUGxlYXNl IHJlc3VibWl0IHRoZSBkcmFmdCB3aXRoIHRoZSBvbmx5IGNoYW5nZSBiZWluZyB0byByZW5hbWUg dGhlIGRyYWZ0IHRvIGRyYWZ0LWlldGYtbmV0bW9kLWludGYtZXh0LXlhbmctMDANCg0KVGhhbmsg eW91IQ0KS2VudCAoYW5kIGNvLWNoYWlycykNCg0KDQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxm IG9mIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlw ZXIubmV0Pj4NCkRhdGU6IE1vbmRheSwgRmVicnVhcnkgMjksIDIwMTYgYXQgNjowNyBQTQ0KVG86 ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gY2FsbCBm b3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBh cyBORVRNT0QgV0cgZHJhZnQNCg0KDQpUaGUgY2hhaXJzIHdlcmUganVzdCByZXZpZXdpbmcgbm90 ZXMgYW5kIHJlYWxpemVkIHRoYXQgdGhpcyB0aHJlYWQgbmV2ZXIgY2xvc2VkIHByb3Blcmx5Lg0K DQpKdWVyZ2VuIGhhcyBzb21lIGNvbmNlcm5zIHJlZ2FyZGluZyByZWFsaXN0aWMgbWlsZXN0b25l cywgdGhhdCB3ZXJlIG5ldmVyIGFkZHJlc3NlZC4gIFJvYmVydCwgY2FuIHlvdSBwbGVhc2UgdHJ5 IHRvIGFkZHJlc3MgSnVlcmdlbuKAmXMgY29uY2VybnMgbm93Pw0KDQpBbHNvLCB0aGVyZSB3ZXJl IG9ubHkgYSB0d28gcmVzcG9uc2VzIGJlZm9yZSBpbmRpY2F0aW5nIHdpbGxpbmduZXNzIHRvIHJl dmlldyB0aGUgZHJhZnQgYXMgaXQgcHJvZ3Jlc3NlcyAodGhhbmtzIERhbiBhbmQgTWFydGluKS4g IENhbiBvdGhlcnMgdGhhdCBzdXBwb3J0IHRoaXMgZHJhZnQgYW5kIHdpbGxpbmcgdG8gcmV2aWV3 IHRoaXMgZHJhZnQgc2F5IHNvPw0KDQpUaGFua3MsDQpOZXRtb2QgQ2hhaXJzDQoNCg0KRnJvbTog bmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFp bHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+Pg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMTUsIDIw MTUgYXQgMTE6NDggQU0NClRvOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDog W25ldG1vZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2Qt aW50Zi1leHQteWFuZyBhcyBORVRNT0QgV0cgZHJhZnQNCg0KDQpUaGUgbWludXRlcyBmb3IgSUVU RiA5NCBzaG93IHRoYXQgdGhlcmUgd2FzIGluLXJvb20gc3VwcG9ydCBmb3IgYWRvcHRpbmcgZHJh ZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICAgVGhlIG1pbnV0 ZXMgYWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhl IG1haWxpbmcgbGlzdCwgd2hpY2ggSSBhbSBkb2luZyBub3cuDQoNClNob3VsZCB3ZSBtb3ZlIHRv IGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBhIFdHIGl0ZW0gYW5k IGNvcnJlc3BvbmRpbmdseSBhZGQgdGhpcyB0byB0aGUgV0cgY2hhcnRlciBhcyBhIG1pbGVzdG9u ZT8gIFBsZWFzZSBjb21tZW50IGJ5IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IGF0IDlBTSBF U1QgYXQgd2hpY2ggdGltZSB0aGUgV0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhlciBvciBub3Qg dGhlcmUgaXMgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkb2N1bWVudC4NCg0K VGhhbmtzLA0KS2VudA0KDQoNCg== --_000_E81CA05BD3414CDF9F7E0CC40BFC041Cjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <1DF75056A0137B4CAFF13902EC29DF3B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KW0kgd2FudGVkIHRvIGZvcm1hbGx5IGNsb3Nl IHRoaXMgdGhyZWFkLCBtb2RlbGVkIGFmdGVyIExvdSdzIHJlY2VudCBjbG9zdXJlIG9mIGFub3Ro ZXIgZHJhZnRdPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhpcyBwb2xs IGlzIGNvbXBsZXRlIGFuZCB0aGUgZG9jdW1lbnQgaXMgYWRvcHRlZCw8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPkF1dGhvcnMsPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5QbGVhc2UgcmVzdWJtaXQg dGhlIGRyYWZ0IHdpdGggdGhlIG9ubHkgY2hhbmdlIGJlaW5nIHRvIHJlbmFtZSB0aGUgZHJhZnQg dG8mbmJzcDs8L2ZvbnQ+ZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMDwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5U aGFuayB5b3UhPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPktlbnQgKGFuZCBjby1jaGFpcnMpPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0 LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9S REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPm5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5A anVuaXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBGZWJydWFyeSAyOSwgMjAx NiBhdCA2OjA3IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3Jn PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGll dGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj dDogPC9zcGFuPlJlOiBbbmV0bW9kXSBjYWxsIGZvciBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQt d2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIE5FVE1PRCBXRyBkcmFmdDxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7IGZvbnQt c2l6ZTogMTJweDsiPlRoZSBjaGFpcnMgd2VyZSBqdXN0IHJldmlld2luZyBub3RlcyBhbmQgcmVh bGl6ZWQgdGhhdCB0aGlzIHRocmVhZCBuZXZlciBjbG9zZWQgcHJvcGVybHkuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4 OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9z cGFjZTsgZm9udC1zaXplOiAxMnB4OyI+SnVlcmdlbiBoYXMgc29tZSBjb25jZXJucyByZWdhcmRp bmcgcmVhbGlzdGljIG1pbGVzdG9uZXMsIHRoYXQgd2VyZSBuZXZlciBhZGRyZXNzZWQuICZuYnNw O1JvYmVydCwgY2FuIHlvdSBwbGVhc2UgdHJ5IHRvIGFkZHJlc3MgSnVlcmdlbuKAmXMgY29uY2Vy bnMgbm93PzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3Bh Y2U7IGZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvbnNvbGFzLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPkFsc28sIHRoZXJlIHdl cmUgb25seSBhIHR3byByZXNwb25zZXMgYmVmb3JlIGluZGljYXRpbmcgd2lsbGluZ25lc3MgdG8g cmV2aWV3IHRoZSBkcmFmdCBhcyBpdCBwcm9ncmVzc2VzICh0aGFua3MgRGFuIGFuZCBNYXJ0aW4p LiAmbmJzcDtDYW4gb3RoZXJzIHRoYXQgc3VwcG9ydCB0aGlzIGRyYWZ0IGFuZCB3aWxsaW5nIHRv IHJldmlldyB0aGlzDQogZHJhZnQgc2F5IHNvPzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvbnNvbGFzLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTog MTJweDsiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywg bW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5OZXRtb2QgQ2hhaXJzPC9kaXY+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7 IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkct TEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNv bGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bmV0bW9kICZsdDs8YSBocmVm PSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dh dHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBEZWNlbWJlciAx NSwgMjAxNSBhdCAxMTo0OCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5l dG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6IDwvc3Bhbj5bbmV0bW9kXSBjYWxsIGZvciBjb25zZW5zdXMgdG8gYWRvcHQgZHJh ZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIE5FVE1PRCBXRyBkcmFmdDxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhlIG1pbnV0ZXMgZm9y IElFVEYgOTQgc2hvdyB0aGF0IHRoZXJlIHdhcyBpbi1yb29tIHN1cHBvcnQgZm9yIGFkb3B0aW5n Jm5ic3A7PC9mb250PmRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBhIFdHIGRy YWZ0LiAmbmJzcDsgVGhlIG1pbnV0ZXMgYWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3Vs ZCBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdCwgd2hpY2ggSQ0KIGFtIGRvaW5nIG5v dy4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TaG91bGQgd2UgbW92ZSB0 byBhZG9wdCBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBpdGVtIGFu ZCBjb3JyZXNwb25kaW5nbHkgYWRkIHRoaXMgdG8gdGhlIFdHIGNoYXJ0ZXIgYXMgYSBtaWxlc3Rv bmU/ICZuYnNwO1BsZWFzZSBjb21tZW50IGJ5IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IGF0 IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUgV0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hldGhlciBv ciBub3QgdGhlcmUgaXMNCiBjb25zZW5zdXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlIGRvY3Vt ZW50LjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5UaGFua3Ms PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPktlbnQ8 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRp diBpZD0iIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPC9zcGFuPjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E81CA05BD3414CDF9F7E0CC40BFC041Cjunipernet_-- From nobody Thu Apr 21 08:43:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D252412EC7F for ; Thu, 21 Apr 2016 08:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blXAO-itcx-F for ; Thu, 21 Apr 2016 08:43:22 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB3312E3FB for ; Thu, 21 Apr 2016 08:43:21 -0700 (PDT) Received: by mail-lb0-x232.google.com with SMTP id u8so29325798lbk.0 for ; Thu, 21 Apr 2016 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2nrmTR8pgBd1QGKXTO0iE+v60Xbgct5x5IqpaHiNJ64=; b=brekMe2p24ExMohI+8vIfeXELelK3qpR0WX9rKzX/qVBEl7OP/eYm83wFE0yzuEPKz vdYEebdWi15DOE7LSp6wTyLYYkZ8ZrP1ihbKm9gFYNvqmUannV4HFS0gUQmpB0SRcO9a 99MrZNra5S+YaiHPFHb2H04WKDvg3O1WRHVuC37yG3SIYIUcbFZMa7K9+7QgNAQe+0O7 I8DAsmSCn+FZ/p0zdk0aXy+/rfxfnI8thWi7Hoa/yVz6T8Lj/6PIjm/uBDVYKX0QZrgm fbBHZ8TqS/Tl7TdcSlD3nCfCGlPBVbykfO63N06haTFhgDCMcbB8cB+cVf87YEGVYQa3 frog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2nrmTR8pgBd1QGKXTO0iE+v60Xbgct5x5IqpaHiNJ64=; b=hEcsrh2XgeEH/t/xurD+b7CmhUeRV8ShEDXPyen5lMb9r1eTVJQIWn0srhs/RQeAB2 oy7gCt4rKFgXwWOxNAPE54uhDKuO7M4GXJrxuMwsFKkEvTQcrasXYrtpFQXv6/eoyT/e ji5GL9VuWcHYXnPeAGRV+cVqcaV9AUTmICpNCMsx+jEU2F1sVqN+8ZMlm4C1W9cuVjle U+Nl6sLhkk1n827LjT4xTIs+Cul3kKa4wa/f4IUMnZAqWMJ9pIMjbQ0Asft7sRnTuuGW liNx5OSaL+nFjTzlygLl2ND0ANQL71O1CLKlxJSqYHyLnoW7tfTp4r8M11LBbPXwXeFU fvOg== X-Gm-Message-State: AOPr4FUa7zyMAnpnBDFT0EAKREKLt8ZjkCEobGMi+BlcUm4s9SXkiI/YVPcXx/ttJR7zJbQxAA1uQpFZb71uHw== MIME-Version: 1.0 X-Received: by 10.112.129.169 with SMTP id nx9mr6731001lbb.96.1461253400179; Thu, 21 Apr 2016 08:43:20 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Thu, 21 Apr 2016 08:43:20 -0700 (PDT) In-Reply-To: <20160421.104523.1036688066875225335.mbj@tail-f.com> References: <20160419.105021.2152837727269070493.mbj@tail-f.com> <20160421.104523.1036688066875225335.mbj@tail-f.com> Date: Thu, 21 Apr 2016 08:43:20 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b3441dad84d8e05310091a6 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:43:25 -0000 --047d7b3441dad84d8e05310091a6 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 21, 2016 at 1:45 AM, Martin Bjorklund wrote: > Hi Andy, > > Are you ok with the proposed OLD/NEW changes? > > Yes, except the issue of multiple deviations (that could be in 1 module on N modules). The actual result depends on the order the deviations are applied. This "last one wins" is implementation-dependent. Some text should be added either to fix it or warn people. (Note that the and YANG library are not ordered so they cannot be used to inform the client which of the N is actually applied.) This also affects the order of "deviate add default" for leaf-list. > > /martin Andy > > > Martin Bjorklund wrote: > > Andy Bierman wrote: > > > Hi, > > > > > > The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, > delete) > > > Is says [default-stmt] but it should be *default-stmt > > > > Thanks, fixed. > > > > But for deviate-replace, it is not clear what the correct answer is. > > > > This is pretty clear: > > > > leaf foo { > > type int32; > > default 42; > > } > > > > deviation /foo { > > deviate replace { > > default 10; > > } > > } > > > > But what about this: > > > > leaf-list bar { > > type int32; > > default 42; > > default 43; > > } > > > > deviation /bar { > > deviate replace { > > default 10; > > default 11; > > } > > } > > > > Are all defaults changed? > > > > Compare with must and unique - they can not be replaced currently. > > > > In order to resolve this we probably need more text as well :( > > > > > > OLD: > > > > The argument "replace" replaces properties of the target node. The > > properties to replace are identified by substatements to the > > "deviate" statement. The properties to replace MUST exist in the > > target node. > > > > > > NEW: > > > > The argument "replace" replaces properties of the target node. The > > properties to replace are identified by substatements to the > > "deviate" statement. The properties to replace MUST exist in the > > target node. If multiple properties exist in the target node, all > > of them are replaced with the new properties defined in the > > substatements to the deviate statement. > > > > + add an example to the section "Usage examples": > > > > NEW: > > > > In this example, the original definition of a leaf list has two > > default values "42" and "43: > > > > leaf-list bar { > > type int32; > > default 42; > > default 43; > > } > > > > A server can change this to the values "10" and "11" instead: > > > > deviation /base:bar { > > deviate replace { > > default 10; > > default 11; > > } > > } > > > > > > Also, change the grammar: > > > > OLD: > > > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > [type-stmt] > > [units-stmt] > > [default-stmt] > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > "}") stmtsep > > > > NEW: > > > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > [type-stmt] > > [units-stmt] > > *must-stmt > > *unique-stmt > > *default-stmt > > [config-stmt] > > [mandatory-stmt] > > [min-elements-stmt] > > [max-elements-stmt] > > "}") stmtsep > > > > > > > > > > > > > Is it intentional that the ABNF for deviate-delete-stmt leaves out > > > config, mandatory, max-elements, and min-elements? > > > I understand why "type" cannot be removed. > > > > I don't really remember, but I can see that if you want to "delete" > > min-elements you can replace it and set it to 0. > > > > > IMO the rest of the statements should be removable. > > > > > Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. > > > This section should make it clear a leaf has only 1 default > > > and the 0..n refers to leaf-list only. > > > > In general, the result after applying deviations must be valid - e.g., > > you cannot deviate "foo" as the default for an int32 leaf. > > > > > It should also be clear that the "deviate add default" for a leaf-list > > > is YANG statement order-dependent. > > > > > > Not as obvious -- a config=false leaf-list can have duplicate default > > > values. > > > The deviate-stmt has no way to specify which 1 to delete or replace > > > if there are duplicates. > > > > Unless replace will replace *all*, as suggested above. > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > --047d7b3441dad84d8e05310091a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 21, 2016 at 1:45 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi Andy,

Are you ok with the proposed OLD/NEW changes?


Yes, except the issue of multiple devi= ations (that could be in 1 module on N modules).
The actual resul= t depends on the order the deviations are applied.
This "las= t one wins" is implementation-dependent. Some text should be added
either to fix it or warn people. =C2=A0(Note that the <hello> = and YANG library
are not ordered so they cannot be used to inform= the client which of
the N is actually applied.) =C2=A0This also = affects the order of "deviate add default"
for leaf-lis= t.

=C2=A0

/martin


Andy
=C2= =A0
=C2=A0


Martin Bjorklund <mbj@tail-f.com&g= t; wrote:
> Andy Bierman <andy@yumaworks.= com> wrote:
> > Hi,
> >
> > The ABNF for "default" is wrong in the deviate-*-stmt (= add, replace, delete)
> > Is says [default-stmt] but it should be *default-stmt
>
> Thanks, fixed.
>
> But for deviate-replace, it is not clear what the correct answer is. >
> This is pretty clear:
>
>=C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0type int32;
>=C2=A0 =C2=A0 =C2=A0default 42;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0deviation /foo {
>=C2=A0 =C2=A0 =C2=A0deviate replace {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 10;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> But what about this:
>
>=C2=A0 =C2=A0leaf-list bar {
>=C2=A0 =C2=A0 =C2=A0type int32;
>=C2=A0 =C2=A0 =C2=A0default 42;
>=C2=A0 =C2=A0 =C2=A0default 43;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0deviation /bar {
>=C2=A0 =C2=A0 =C2=A0deviate replace {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 10;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 11;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> Are all defaults changed?
>
> Compare with must and unique - they can not be replaced currently.
>
> In order to resolve this we probably need more text as well :(
>
>
> OLD:
>
>=C2=A0 =C2=A0The argument "replace" replaces properties of th= e target node.=C2=A0 The
>=C2=A0 =C2=A0properties to replace are identified by substatements to t= he
>=C2=A0 =C2=A0"deviate" statement.=C2=A0 The properties to rep= lace MUST exist in the
>=C2=A0 =C2=A0target node.
>
>
> NEW:
>
>=C2=A0 =C2=A0The argument "replace" replaces properties of th= e target node.=C2=A0 The
>=C2=A0 =C2=A0properties to replace are identified by substatements to t= he
>=C2=A0 =C2=A0"deviate" statement.=C2=A0 The properties to rep= lace MUST exist in the
>=C2=A0 =C2=A0target node.=C2=A0 If multiple properties exist in the tar= get node, all
>=C2=A0 =C2=A0of them are replaced with the new properties defined in th= e
>=C2=A0 =C2=A0substatements to the deviate statement.
>
> + add an example to the section "Usage examples":
>
> NEW:
>
>=C2=A0 =C2=A0In this example, the original definition of a leaf list ha= s two
>=C2=A0 =C2=A0default values "42" and "43:
>
>=C2=A0 =C2=A0 =C2=A0leaf-list bar {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type int32;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 42;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 43;
>=C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0A server can change this to the values "10" and = "11" instead:
>
>=C2=A0 =C2=A0 =C2=A0deviation /base:bar {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0deviate replace {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default 10;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default 11;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>
>
> Also, change the grammar:
>
> OLD:
>
> deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str optse= p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0(";" /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "{" stmtsep
>=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 ;; these stmts can appear in any order
>=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 [type-stmt]
>=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 [units-stmt]
>=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 [default-stmt]
>=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 [config-stmt]
>=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 [mandatory-stmt]
>=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 [min-elements-stmt]
>=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 [max-elements-stmt]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "}") stmtsep
>
> NEW:
>
> deviate-replace-stmt =3D deviate-keyword sep replace-keyword-str optse= p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0(";" /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "{" stmtsep
>=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 ;; these stmts can appear in any order
>=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 [type-stmt]
>=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 [units-stmt]
>=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 *must-stmt
>=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 *unique-stmt
>=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 *default-stmt
>=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 [config-stmt]
>=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 [mandatory-stmt]
>=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 [min-elements-stmt]
>=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 [max-elements-stmt]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "}") stmtsep
>
>
>
>
>
> > Is it intentional that the ABNF for deviate-delete-stmt leaves ou= t
> > config, mandatory, max-elements, and min-elements?
> > I understand why "type" cannot be removed.
>
> I don't really remember, but I can see that if you want to "d= elete"
> min-elements you can replace it and set it to 0.
>
> > IMO the rest of the statements should be removable.
>
> > Sec. 7.20.3.2 does not mention the restrictions indicated in the = ABNF.
> > This section should make it clear a leaf has only 1 default
> > and the 0..n refers to leaf-list only.
>
> In general, the result after applying deviations must be valid - e.g.,=
> you cannot deviate "foo" as the default for an int32 leaf. >
> > It should also be clear that the "deviate add default" = for a leaf-list
> > is YANG statement order-dependent.
> >
> > Not as obvious -- a config=3Dfalse leaf-list can have duplicate d= efault
> > values.
> > The deviate-stmt has no way to specify which 1 to delete or repla= ce
> > if there are duplicates.
>
> Unless replace will replace *all*, as suggested above.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod >

--047d7b3441dad84d8e05310091a6-- From nobody Thu Apr 21 08:47:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40C512EC7F for ; Thu, 21 Apr 2016 08:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwZ41HsQ4TUD for ; Thu, 21 Apr 2016 08:46: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 7FBB512EC85 for ; Thu, 21 Apr 2016 08:46:58 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 784891AE0397; Thu, 21 Apr 2016 17:46:57 +0200 (CEST) Date: Thu, 21 Apr 2016 17:46:57 +0200 (CEST) Message-Id: <20160421.174657.1185541435255989696.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20160419.105021.2152837727269070493.mbj@tail-f.com> <20160421.104523.1036688066875225335.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] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:47:00 -0000 Andy Bierman wrote: > On Thu, Apr 21, 2016 at 1:45 AM, Martin Bjorklund wrote: > > > Hi Andy, > > > > Are you ok with the proposed OLD/NEW changes? > > > > > Yes, except the issue of multiple deviations (that could be in 1 module on > N modules). > The actual result depends on the order the deviations are applied. > This "last one wins" is implementation-dependent. Some text should be added > either to fix it or warn people. (Note that the and YANG library > are not ordered so they cannot be used to inform the client which of > the N is actually applied.) This also affects the order of "deviate add > default" > for leaf-list. I prefer some warning text. In reality, I don't think is an issue. /martin > > > > > > > /martin > > > > Andy > > > > > > > > > > Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, > > delete) > > > > Is says [default-stmt] but it should be *default-stmt > > > > > > Thanks, fixed. > > > > > > But for deviate-replace, it is not clear what the correct answer is. > > > > > > This is pretty clear: > > > > > > leaf foo { > > > type int32; > > > default 42; > > > } > > > > > > deviation /foo { > > > deviate replace { > > > default 10; > > > } > > > } > > > > > > But what about this: > > > > > > leaf-list bar { > > > type int32; > > > default 42; > > > default 43; > > > } > > > > > > deviation /bar { > > > deviate replace { > > > default 10; > > > default 11; > > > } > > > } > > > > > > Are all defaults changed? > > > > > > Compare with must and unique - they can not be replaced currently. > > > > > > In order to resolve this we probably need more text as well :( > > > > > > > > > OLD: > > > > > > The argument "replace" replaces properties of the target node. The > > > properties to replace are identified by substatements to the > > > "deviate" statement. The properties to replace MUST exist in the > > > target node. > > > > > > > > > NEW: > > > > > > The argument "replace" replaces properties of the target node. The > > > properties to replace are identified by substatements to the > > > "deviate" statement. The properties to replace MUST exist in the > > > target node. If multiple properties exist in the target node, all > > > of them are replaced with the new properties defined in the > > > substatements to the deviate statement. > > > > > > + add an example to the section "Usage examples": > > > > > > NEW: > > > > > > In this example, the original definition of a leaf list has two > > > default values "42" and "43: > > > > > > leaf-list bar { > > > type int32; > > > default 42; > > > default 43; > > > } > > > > > > A server can change this to the values "10" and "11" instead: > > > > > > deviation /base:bar { > > > deviate replace { > > > default 10; > > > default 11; > > > } > > > } > > > > > > > > > Also, change the grammar: > > > > > > OLD: > > > > > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > > > (";" / > > > "{" stmtsep > > > ;; these stmts can appear in any order > > > [type-stmt] > > > [units-stmt] > > > [default-stmt] > > > [config-stmt] > > > [mandatory-stmt] > > > [min-elements-stmt] > > > [max-elements-stmt] > > > "}") stmtsep > > > > > > NEW: > > > > > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep > > > (";" / > > > "{" stmtsep > > > ;; these stmts can appear in any order > > > [type-stmt] > > > [units-stmt] > > > *must-stmt > > > *unique-stmt > > > *default-stmt > > > [config-stmt] > > > [mandatory-stmt] > > > [min-elements-stmt] > > > [max-elements-stmt] > > > "}") stmtsep > > > > > > > > > > > > > > > > > > > Is it intentional that the ABNF for deviate-delete-stmt leaves out > > > > config, mandatory, max-elements, and min-elements? > > > > I understand why "type" cannot be removed. > > > > > > I don't really remember, but I can see that if you want to "delete" > > > min-elements you can replace it and set it to 0. > > > > > > > IMO the rest of the statements should be removable. > > > > > > > Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. > > > > This section should make it clear a leaf has only 1 default > > > > and the 0..n refers to leaf-list only. > > > > > > In general, the result after applying deviations must be valid - e.g., > > > you cannot deviate "foo" as the default for an int32 leaf. > > > > > > > It should also be clear that the "deviate add default" for a leaf-list > > > > is YANG statement order-dependent. > > > > > > > > Not as obvious -- a config=false leaf-list can have duplicate default > > > > values. > > > > The deviate-stmt has no way to specify which 1 to delete or replace > > > > if there are duplicates. > > > > > > Unless replace will replace *all*, as suggested above. > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > From nobody Thu Apr 21 08:59:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9212DAFD; Thu, 21 Apr 2016 08:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C-6fitht77n; Thu, 21 Apr 2016 08:59:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED1012D8A7; Thu, 21 Apr 2016 08:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aIYhGIC6Wa1Szo4+8fKPXaUli70gr6175PmFL6Pa3mc=; b=jAcnJOLiouiRwiyn2/AYaE5z7jdEYZyZEt+FLkkyV/4aGmGHdOxUeEN+Kh37yPzMtOXCnr6C5XUJKREFVBeK4DpHlQmqiasUYZYZryzOASrCHwwBDOYA9H+eWtwIKYAltluPpJmI51wLpHVkHq4PTp/SDdw50ySYFKowM1xB6BY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 15:59:45 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 15:59:43 +0000 From: Kent Watsen To: "rwilton@cisco.com" , "daviball@cisco.com" , Selvakumar Sivaraj Thread-Topic: Regarding IPR on draft-wilton-netmod-intf-vlan-yang Thread-Index: AQHRf7UBKZSP0lcWWUeZHr8YytB+k5+UiykA Date: Thu, 21 Apr 2016 15:59:43 +0000 Message-ID: <3BB6B538-57F7-4EC7-AA8C-B058DCC59125@juniper.net> References: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> In-Reply-To: <1C382F23-CC30-42CC-BF4D-BB6D3BF0DE51@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: fed2634b-ae1c-4051-b309-08d369fdf480 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:bdh71eQu/b/2F5x9r9A7za9YpNiQoOgs1yGS+QXT2MdsbY2hdL52EN9SHimAo0FH35hmYuTxyp8iiUhLA8DOzKfQxpy3EgtoA73VAc37bQUgZSH8LmxGkxHO5yaAG3FkgxMwGQsh5lpVWhBvRm/Cc7YXxI+oK8UTR+DMFQxqYlEaOQYuLHIK7+me37mxI/VO; 24:bXkYiYMODqJS+mhJ02eMmig00xNTfCv+Lq6/9wrqFhMqdj6a/6wctprlQYgMwzPax4nMVDZLu/1Vkx/Lp6vsXMXSJxyhMQ6FfHa0CPO5Bok=; 7:qmv4iS9jAsoBzq5YCDRrX2y+CP7iA+N7de6/ybYjYOpVOZsw5tw6XZsPmLwhpYFqf+Rw6kSRZcIzyRhzpJrXR2JkFkBw7LBByKyytaFSxs7Ll5cAYEvllvVxnsaNJbccdBTUf2+Mu+bc6pP84rJP6blpB74d+eJrUICN1HT6p+NxL37SuHjyzSbU9OhAYqmc2wn0v2kbKxg0jrA3OlS7VtoNcHJjCmWM4pY146GzvV8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(69224002)(50986999)(5001770100001)(87936001)(189998001)(4001350100001)(19580395003)(83716003)(5004730100002)(19617315012)(83506001)(82746002)(5008740100001)(1096002)(1220700001)(19580405001)(86362001)(76176999)(54356999)(586003)(3846002)(102836003)(6116002)(77096005)(10400500002)(15975445007)(2900100001)(2950100001)(5002640100001)(66066001)(4001450100002)(99286002)(33656002)(36756003)(2501003)(4326007)(81166005)(230783001)(92566002)(2906002)(122556002)(16236675004)(3280700002)(106116001)(3660700001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3BB6B53857F74EC7AA8CB058DCC59125junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 15:59:43.7526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:59:49 -0000 --_000_3BB6B53857F74EC7AA8CB058DCC59125junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBbGwsDQoNClRoYW5rcyBmb3IgYWxsIHlvdXIgSVBSIHJlc3BvbnNlcy4gIEkgd2FzIGhvcGlu ZyB0byBsZWFkIHRoaXMgdG8gYSBjYWxsIGZvciBhZG9wdGlvbiwgYnV0IGFmdGVyIGp1c3Qgbm93 IGRpc2N1c3Npbmcgd2l0aCBSb2JlcnQsIGl0IHNlZW1zIHRoYXQgd2UgZmlyc3QgaGF2ZSB0byB3 YWl0IGZvciB0aGUgSUVFRSB0byB1bmJsb2NrIGl0LCB3aGljaCBob3BlZnVsbHkgd2lsbCBoYXBw ZW4gb24gYSBjYWxsIGluIE1heS4gIEEgY2FsbCBmb3IgYWRvcHRpb24gb24gdGhpcyBkcmFmdCB3 aWxsIG9jY3VyIHRoZW4sIGFzc3VtaW5nIGl0IGlzIHVuYmxvY2tlZC4NCg0KVGhhbmtzLA0KS2Vu dA0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNl bkBqdW5pcGVyLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIE1hcmNoIDE2LCAyMDE2IGF0IDI6NTIg UE0NClRvOiAicndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPiIgPHJ3 aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+LCAiZGF2aWJhbGxAY2lz Y28uY29tPG1haWx0bzpkYXZpYmFsbEBjaXNjby5jb20+IiA8ZGF2aWJhbGxAY2lzY28uY29tPG1h aWx0bzpkYXZpYmFsbEBjaXNjby5jb20+PiwgU2VsdmFrdW1hciBTaXZhcmFqIDxzc2l2YXJhakBq dW5pcGVyLm5ldDxtYWlsdG86c3NpdmFyYWpAanVuaXBlci5uZXQ+Pg0KQ2M6ICJuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4+LCAibmV0bW9kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNo YWlyc0BpZXRmLm9yZz4iIDxuZXRtb2QtY2hhaXJzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtY2hh aXJzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtd2lsdG9uLW5l dG1vZC1pbnRmLXZsYW4teWFuZw0KDQpbVGhpcyByZWdhcmRzIHRoZSBuZXcgcHJlLWFkb3B0aW9u IHByb2Nlc3MgZGVzY3JpYmVkIGJ5IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9uZXRtb2QvY3VycmVudC9tc2cxNTUyMC5odG1sXQ0KDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9y cywgV0csDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGwsIGFy ZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBh Ym92ZT8gIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgICAiTm8sIEknbSBub3QgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQogICAgIlllcywgSSdtIGF3 YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlz IElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyAgSWYg eWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAgICJZZXMsIHRoZSBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyIN Cm9yDQogICAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBh bnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5r DQphcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Ig b3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0 aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBh bnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l eHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0 aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0Yg WU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0XigJlTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9u IHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2Js aWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRv IG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4g SUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFu eSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQg SVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJv dmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0lu dGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpORVRNT0QgV0cgQ2hhaXJzDQoNClBT IFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdl IGluIHlvdXIgcmVzcG9uc2UuDQoNCg== --_000_3BB6B53857F74EC7AA8CB058DCC59125junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <70A66DD529D45148BCD941EC07A00ACF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5r cyBmb3IgYWxsIHlvdXIgSVBSIHJlc3BvbnNlcy4gJm5ic3A7SSB3YXMgaG9waW5nIHRvIGxlYWQg dGhpcyB0byBhIGNhbGwgZm9yIGFkb3B0aW9uLCBidXQgYWZ0ZXIganVzdCBub3cgZGlzY3Vzc2lu ZyB3aXRoIFJvYmVydCwgaXQgc2VlbXMgdGhhdCB3ZSBmaXJzdCBoYXZlIHRvIHdhaXQgZm9yIHRo ZSBJRUVFIHRvIHVuYmxvY2sgaXQsIHdoaWNoIGhvcGVmdWxseSB3aWxsIGhhcHBlbiBvbiBhIGNh bGwgaW4gTWF5LiAmbmJzcDtBIGNhbGwgZm9yIGFkb3B0aW9uDQogb24gdGhpcyBkcmFmdCB3aWxs IG9jY3VyIHRoZW4sIGFzc3VtaW5nIGl0IGlzIHVuYmxvY2tlZC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+S2VudDwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPktlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dh dHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE1hcmNoIDE2 LCAyMDE2IGF0IDI6NTIgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86 IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25A Y2lzY28uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29t Ij5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZGF2aWJh bGxAY2lzY28uY29tIj5kYXZpYmFsbEBjaXNjby5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWJhbGxAY2lzY28uY29tIj5kYXZpYmFsbEBjaXNjby5jb208L2E+Jmd0OywNCiBT ZWx2YWt1bWFyIFNpdmFyYWogJmx0OzxhIGhyZWY9Im1haWx0bzpzc2l2YXJhakBqdW5pcGVyLm5l dCI+c3NpdmFyYWpAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v cmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RA aWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnIj5uZXRtb2QtY2hhaXJz QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDogPC9zcGFuPlJlZ2FyZGluZyBJUFIgb24gZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLXZs YW4teWFuZzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5bVGhpcyByZWdh cmRzIHRoZSBuZXcgcHJlLWFkb3B0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGJ5Jm5ic3A7PGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21z ZzE1NTIwLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2Qv Y3VycmVudC9tc2cxNTUyMC5odG1sPC9hPl08L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmll cjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5BdXRo b3JzLCBDb250cmlidXRvcnMsIFdHLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENv dXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+ QXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbCwgYXJlIHlvdSBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPyAmbmJz cDtQbGVhc2Ugc3RhdGUgZWl0aGVyOjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENv dXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+ Jm5ic3A7ICZuYnNwOyAmcXVvdDtObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBw bGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q291cmllcjsiPm9yPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPiZu YnNwOyAmbmJzcDsgJnF1b3Q7WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0JnF1b3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsi Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5JZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlczwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij4oc2VlIFJGQ3Mg Mzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gJm5ic3A7SWYgeWVz IHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ291cmllcjsiPiZuYnNwOyAmbmJzcDsgJnF1b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRp c2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVvdDs8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+b3I8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb3VyaWVyOyI+Jm5ic3A7ICZuYnNwOyAmcXVvdDtObywgdGhlIElQUiBoYXMg bm90IGJlZW4gZGlzY2xvc2VkJnF1b3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog Q291cmllcjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7 Ij5JZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxz IHlvdSB0aGluazwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij5hcHBy b3ByaWF0ZS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPklmIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhl IGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3 aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsDQogYSByZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5P VEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0XigJlT IFRPIExJTkVTLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+SWYgeW91IGFyZSBv biB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlz dGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9i bGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0 byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFINCiBvZiBvdGhlcnMgb24g YW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGlu IGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9z ZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQg YWJvdmUgYW5kJm5ic3A7PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAv aWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkiPmh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5PC9hPi48L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiPlRoYW5rIHlvdSw8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyI+TkVUTU9EIFdHIENoYWlyczwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb3VyaWVyOyI+UFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUg aGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_3BB6B53857F74EC7AA8CB058DCC59125junipernet_-- From nobody Thu Apr 21 10:55:01 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E6C12E9ED; Thu, 21 Apr 2016 10:54:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421175453.19566.44924.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 10:54:53 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:54:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Common Interface Extension YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-intf-ext-yang-00.txt Pages : 25 Date : 2016-04-21 Abstract: This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 21 19:44:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1A12EBBC for ; Thu, 21 Apr 2016 19:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cU9SZjlhTU8 for ; Thu, 21 Apr 2016 19:44:01 -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 EC82112EA6B for ; Thu, 21 Apr 2016 19:44:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CID61557; Fri, 22 Apr 2016 02:43:58 +0000 (GMT) Received: from SZXEML424-HUB.china.huawei.com (10.82.67.153) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 22 Apr 2016 03:43:55 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.184]) by SZXEML424-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.03.0235.001; Fri, 22 Apr 2016 10:43:47 +0800 From: "zhangyali (D)" To: "Carl Moberg (camoberg)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A//8tEkA= Date: Fri, 22 Apr 2016 02:43:48 +0000 Message-ID: References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> In-Reply-To: <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.104.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57198FEF.0061, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fd72970ef93372eee588630b56be189d Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] =?utf-8?b?562U5aSNOiAgeWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlv?= =?utf-8?q?n?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 02:44:04 -0000 SGkgQ2FybCwNCg0KSW5kZWVkLCB0aGVyZSBpcyB1bmNsZWFyIGZ1bmN0aW9uYWwgcGFydGl0aW9u aW5nIGJldHdlZW4gb3JjaGVzdHJhdG9yIGFuZCBjb250cm9sbGVyLiBTbyBsZXQncyBnbyBiYWNr IHRvIHRoZSBkaXZpc2lvbiBvZiBuZXR3b3JrIGVsZW1lbnQgeWFuZyBtb2RlbCBhbmQgc2Vydmlj ZSB5YW5nIG1vZGVsLg0KDQpJbiBteSB2aWV3LCBlbGVtZW50IHlhbmcgbW9kZWwgc2hvdWxkIGJl IHRoZSBkZXRhaWxlZCBjb25maWd1cmF0aW9uIGZvciBvbmUgZGV2aWNlLCBzdWNoIGFzLCBtdHUs IGhvcC1saW1pdCxldGMuIEJ1dCBzZXJ2aWNlIG1vZGVsIHNob3VsZCBiZSBhIGxhcmdlc2NhbGUg ZGVzY3JpcHRpb24sIHN1Y2ggYXMsIHRoZSBlbmRwb2ludHMgaW4gdGhlIFZQTi4gQnV0IHNvbWV0 aW1lcywgbWFueSBjb25maWd1cmF0aW9ucyB5YW5nIG1vZGVsIGluY2x1ZGUgbWFueSBkZXZpY2Vz JyBjb25maWd1cmF0aW9uIG9yIGRvIG5vdCBkaXN0aW5ndWlzaCB3aGljaCBkZXZpY2VzIGFyZSBj b25maWd1cmVkLiBTbyBjb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIG1vcmUgc3BlY2lmaWMgbWV0aG9k IHRvIGNsYXNzaWZ5IHRoZW0/IE1heWJlIHRoZSBkcmFmdCBbZHJhZnQtdHJhbi1pcHNlY21lLXlh bmctMDFdIGlzIGEgZ29vZCBleGFtcGxlLg0KDQpCZXN0LA0KWWFsaQ0KDQotLS0tLemCruS7tuWO n+S7ti0tLS0tDQrlj5Hku7bkuro6IENhcmwgTW9iZXJnIChjYW1vYmVyZykgW21haWx0bzpjYW1v YmVyZ0BjaXNjby5jb21dIA0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIx5pelIDE2OjQxDQrm lLbku7bkuro6IHpoYW5neWFsaSAoRCkNCuaKhOmAgTogbmV0bW9kQGlldGYub3JnDQrkuLvpopg6 IFJlOiBbbmV0bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQoNCj4gT24gQXByIDIxLCAy MDE2LCBhdCAxMDozMCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+ IHdyb3RlOg0KPiANCj4gSGkgQ2FybCwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBhbnN3ZXJzIHZl cnkgbXVjaC4gRnJvbSB5b3VyIGV4cGxhbmF0aW9uLCB0aGUgbWFpbiB2aWV3IGlzIHRoYXQgZG8g bm90IGRpc3Rpbmd1aXNoIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gbmV0d29yayBsZXZlbCBhbmQg c2VydmljZSBsZXZlbCBtb2RlbCwgd2hpY2ggYWxsIGNhbGxlZCAibmV0d29yayBzZXJ2aWNlIG1v ZGVsIiwgcmlnaHQ/DQo+IElmIHNvLCB0aGUgcXVlc3Rpb24gaXMgdGhhdCBob3cgdGhlc2UgInNh bWUgbGF5ZXIiIG1vZGVsIGNvdWxkIGJlIHVzZWQgaW4gdGhlIGxheWVyZWQgYXJjaGl0ZWN0dXJl LCBzdWNoIGFzLCB0aGVyZSBhcmUgb3JjaGVzdHJhdG9yIGxheWVyLCBjb250cm9sbGVyIGxheWVy IGFuZCBkZXZpY2UgbGF5ZXI/IEluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBOQkkgb2Ygb3JjaGVz dHJhdG9yIHNob3VsZCBub3QgaW5jbHVkZSBhbnkgdGVjaG5vbG9neSBkZXRhaWxzIHdoaWNoIHNo b3VsZCBleGlzdCBpbiB0aGUgTkJJIG9mIGNvbnRyb2xsZXIuIFRoZSBvcmNoZXN0cmF0b3Igd2ls bCBjb21wbGV0ZSB0aGUgbWFwcGluZyBmcm9tIE5CSSBvZiBvcmNoZXN0cmF0b3IgdG8gTkJJIG9m IGNvbnRyb2xsZXIuDQoNCiBUaGUgdmlldyBvZiB0aGlzIHZhcmllcyB3aWxkbHkgYWNyb3NzIHN0 YW5kYXJkcyBib2RpZXMsIG9wZW4gc291cmNlIHByb2plY3RzLCB2ZW5kb3JzIGFuZCBtYW55IG90 aGVyIGVudGl0aWVzIGludm9sdmVkLiBJLmUuIG1vc3Qgb3JjaGVzdHJhdG9ycyBkbyBsZWFrIHRl Y2hub2xvZ3kgZGV0YWlscyBhbmQgTkJJcyBvZiBjb250cm9sbGVycyBjb250YWluIGFic3RyYWN0 aW9ucyBhYm92ZSB0aGUgbmV0d29yayBsZXZlbC4NCg0KPiBMZXQncyB0YWtlIEwyVlBOIGFzIGEg ZXhhbXBsZS4gSW4gdGhlIE5CSSBvZiBvcmNoZXN0cmF0b3IsIHRoZSB5YW5nIG1vZGVsIGp1c3Qg bmVlZCBleHByZXNzIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBvZiBMMlZQTiwgc3VjaCBhcywgc2l0 ZXMgaW5mb3JtYXRpb24gYW5kIHRvcG9sb2d5IGJldHdlZW4gc2l0ZXMuIEZvciB0aGUgTkJJIG9m IGNvbnRyb2xsZXIsIHRoZSB5YW5nIG1vZGVsIG1heSBiZSBzb21lIHRlY2hub2xvZ3kgc29sdXRp b25zLCBzdWNoIGFzLCBWUExTLCBWUFdTLCBldGMuIFRoZSBvcmNoZXN0cmF0b3Igd2lsbCBjaG9v c2Ugb25lIG9yIHNvbWUgc29sdXRpb25zIGRlcGVuZHMgb24gdXNlcnMnIHJlcXVpcmVtZW50LiBU aGVuIHRoZSBjb250cm9sbGVyIHdpbGwgY29tcGxldGUgdGhlIG5ldHdvcmsgZWxlbWVudCBjb25m aWd1cmF0aW9uICh1c2luZyBuZXR3b3JrIGVsZW1lbnQgeWFuZyBtb2RlbCApIGFjY29yZGluZyB0 byB0ZWNobm9sb2d5IHNvbHV0aW9ucyBjaG9zZW4gYnkgb3JjaGVzdHJhdG9yLg0KDQogVGhhdCBp cyBhYnNvbHV0ZWx5IG9uZSB3YXkgb2YgbG9va2luZyAoYW5kIHBlcmhhcHMgZXZlbiBpbXBsZW1l bnRpbmcpIGl0LCBhbW9uZyBzZXZlcmFsIG90aGVycy4gSW4gdGhpcyBjYXNlLCBhbmQgdW5kZXIg dGhlIHN1Z2dlc3RlZCBjbGFzc2lmaWNhdGlvbiBpbiB0aGUgZG9jdW1lbnQsIGJvdGggdGhlIGNv bnRyb2xsZXIgYW5kIG9yY2hlc3RyYXRvciBtb2RlbHMgd291bGQgYmUgZXhhbXBsZXMgb2YgTmV0 d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMgd2l0aCBkaWZmZXJlbnQgYWJzdHJhY3Rpb24g bGV2ZWxzLg0KDQo+IFRob3VnaCBJIGFtIG5vdCBzdXJlIGlmIHRoZSBwcm9jZXNzIGlzIHN1aXRh YmxlLCB0aGUgc2VydmljZSBtb2RlbCBhbmQgbmV0d29yayBtb2RlbCBhcmUgZGlmZmVyZW5jZSB3 aGljaCBhcmUgdXNlZCBpbiBkaWZmZXJlbnQgcGxhY2VzLiBBbnkgY29tbWVudHM/DQoNCiBBYm92 ZS4NCg0KPiANCj4gQmVzdCwNCj4gWWFsaQ0KPiANCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K PiDlj5Hku7bkuro6IENhcmwgTW9iZXJnIChjYW1vYmVyZykgW21haWx0bzpjYW1vYmVyZ0BjaXNj by5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIwMTblubQ05pyIMjHml6UgMTU6NDcNCj4g5pS25Lu2 5Lq6OiB6aGFuZ3lhbGkgKEQpDQo+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+IOS4u+mimDog UmU6IFtuZXRtb2RdIHlhbmcgbW9kZWwgY2xhc3NpZmljYXRpb24NCj4gDQo+IFlhbGksDQo+IA0K Pj4gT24gQXByIDIxLCAyMDE2LCBhdCA2OjAzIEFNLCB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkz NjlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIGFsbCwNCj4+IA0KPj4gSSBub3RpY2Vk IHRoYXQgdGhlcmUgaXMgYSBkcmFmdCBpbnRlbnRzIHRvIGNsYXNzaWZ5IHRoZSB2YXJpb3VzIHlh bmcgbW9kZWwsIGl0IGlzIHJlYWxseSBhIG1lYW5pbmdmdWwgd29yay4gTWFueSBwb2ludHMgYXJl IGNvbnNpc3RlbnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nLCB3aGVyZWFzLCB0aGVyZSBhcmUgc29t ZSBxdWVzdGlvbnMgdW5jbGVhciBuZWVkIHRvIGlucXVpcmUuDQo+PiANCj4+IDEuICAgICAgIFdo eSBWUExTIGFuZCBWUFdTIGFyZSBhbGwgc2VydmljZSBtb2RlbCwgd2hpY2ggaXMgYXQgdGhlIHNh bWUgbGV2ZWwgd2l0aCBMM1ZQTj8gSW4gbXkgdW5kZXJzdGFuZGluZywgTDNWUE4gaXMgYSB0eXBp Y2FsIHNlcnZpY2UgbW9kZWwgd2hpY2ggaGlkZXMgdGhlIHVuZGVybGF5IG5ldHdvcmssIGJ1dCBi b3RoIFZQTFMgYW5kIFZQV1MgaXMgc3BlY2lmaWMgdGVjaG5vbG9neSBzb2x1dGlvbnMuIE1heWJl IGEgdW5pZm9ybSBMMlZQTiB3aGljaCBhYnN0cmFjdHMgc2VydmljZSBpbmZvcm1hdGlvbiBmcm9t IGFsbCBsYXllcjIgdGVjaG5vbG9naWVzIG1vcmUgbGlrZSBzZXJ2aWNlIG1vZGVsLg0KPiANCj4g U2VjdGlvbiAyLjEgZ29lcyB0byBzb21lIGxlbmd0aCB0byBkZXNjcmliZSB0aGF0IHRoZXJlIGFy ZSB2YXJpb3VzIHR5cGVzIG9mIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9kZWxzIGF0IHZh cmlvdXMgbGV2ZWxzIG9mIGFic3RyYWN0aW9ucy4gVGhpcyBtZWFucyB0aGF0IGJvdGggZ2VuZXJp YyBtb2RlbHMgKGUuZy4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIEwzIFZQTiBtb2RlbCkgYW5kIG1v cmUgaW1wbGVtZW50YXRpb24tb3JpZW50ZWQgbW9kZWxzIChlLmcuIFZQTFMpIHdvdWxkIGJlIGNs YXNzaWZpZWQgYXMgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMgd2l0aG91dCBiZWlu ZyBhdCB0aGUgZXhhY3Qgc2FtZSBsZXZlbCBvZiBhYnN0cmFjdGlvbi4NCj4gDQo+PiAyLiAgICAg ICBXaGF0IGlzIHRoZSBsYXllciBvZiB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywgVnhM QU4sIEdSRSwgVlBMUywgZXRjPw0KPiANCj4gSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IFZ4TEFO LCBHUkUsIFZQTFMgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgcGFyYW1ldGVycyByZXNp ZGluZyBvbiBhIGRldmljZSwgdGhlbiBpdOKAmXMgTmV0d29yayBFbGVtZW50IFlBTkcgRGF0YSBt b2RlbHMuIElmIHlvdeKAmXJlIHRhbGtpbmcgYWJvdXQgVnhMQU4sIEdSRSwgVlBMUyBjb25maWd1 cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIGFzIHBhcnQgb2YgYW4gImFic3RyYWN0 IG1vZGVsIHRoYXQgYWxsb3dzIGluc3RhbmNlcyBvIHRoZSBzZXJ2aWNlIHRvIGJlIGRlY29tcG9z ZWQgaW50byBpbnN0YW5jZSBkYXRhIGFjY29yZGluZyB0byB0aGUgTmV0d29yayBFbGVtZW50IGRh dGEgbW9kZWxzIG9mIHRoZSBwYXJ0aWNpcGF0aW5nIG5ldHdvcmsgZWxlbWVudHPigJ0sIHRoZW4g aXQgd291bGQgYmUgY2xhc3NpZmllZCBhcyBhIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9k ZWxzLiANCj4gDQo+PiAzLiAgICAgICBJbiBUTU4gTS4zMDEwLCBuZXR3b3JrIG1vZGVsIGFsc28g YSBwYXJ0aWN1bGFyIGxheWVyLCBzaG91bGQgc3BlY2lmaWMgeWFuZyBtb2RlbCBjb3ZlciB0aGlz IGxheWVyPw0KPiANCj4gSSBoYXZlIGRvbmUgc29tZSByZWFkaW5nIG9uIE0uMzAxMCBhbmQgYmVs aWV2ZSB3ZSBhcmUgd2VsbCBhbGlnbmVkIGluIHRoZSBkcmFmdC4gVGhlIG5ldHdvcmsgbW9kZWwg d291bGQgYmUgY2xhc3NpZmllZCBhZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVs Lg0KPiANCj4+IEJlc3QgUmVnYXJkcywNCj4+IFlhbGkNCj4+IA0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCj4gDQoNCg== From nobody Fri Apr 22 01:03:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866BA12E68C for ; Fri, 22 Apr 2016 01:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLgsC3WW823l for ; Fri, 22 Apr 2016 01:03:51 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC2C12D8B3 for ; Fri, 22 Apr 2016 01:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9188; q=dns/txt; s=iport; t=1461312231; x=1462521831; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sO6fANjp2H7DeGG/20lPytl98qQ0MEKQp4EWn/ZxrVk=; b=RFdKwSN15tYl3loZvNRBvKxgLhpl+NKjb/EoP7fRk47cYcLkMw0sBbdb 8usMMCT5/6HTSvFfesKdN5NeXV7DeCK+HRP9qiJPhNsbd/n6zI2Cma+Tn dXxlQFQTgNFVRhyN2plg/uL7JiNMt7111rJ9Zes3mZKmxUyie/GRqYZcp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgB62hlX/4cNJK1egzhTfQa6AAENg?= =?us-ascii?q?XQXC4UiSgIcgQ84FAEBAQEBAQFlJ4RBAQEBAwEBAQEgETcDCwULAgEGAhIGAgI?= =?us-ascii?q?jAwICAiULFAECDgIEDgUbiAcIDpB3nReRIQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?REEfIUlgXWCVoQaI4MCK4IrBZgPAY4TjxCPLgEeAQFCggkWgUpshzo+fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,516,1454976000"; d="scan'208";a="264715792" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2016 08:03:50 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3M83mM5016529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 08:03:50 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 03:03:48 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 03:03:48 -0500 From: "Carl Moberg (camoberg)" To: "zhangyali (D)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A//8tEkCAAlrGAA== Date: Fri, 22 Apr 2016 08:03:48 +0000 Message-ID: <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.89] Content-Type: text/plain; charset="utf-8" Content-ID: <226274CE04A56A4BAB911C2A4790ED92@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:03:53 -0000 DQotLQ0KQ2FybCBNb2JlcmcNClRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KY2Ftb2JlcmdAY2lz Y28uY29tDQoNCj4gT24gQXByIDIyLCAyMDE2LCBhdCA0OjQzIEFNLCB6aGFuZ3lhbGkgKEQpIDx6 aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiANCj4gSW5k ZWVkLCB0aGVyZSBpcyB1bmNsZWFyIGZ1bmN0aW9uYWwgcGFydGl0aW9uaW5nIGJldHdlZW4gb3Jj aGVzdHJhdG9yIGFuZCBjb250cm9sbGVyLiBTbyBsZXQncyBnbyBiYWNrIHRvIHRoZSBkaXZpc2lv biBvZiBuZXR3b3JrIGVsZW1lbnQgeWFuZyBtb2RlbCBhbmQgc2VydmljZSB5YW5nIG1vZGVsLg0K PiANCj4gSW4gbXkgdmlldywgZWxlbWVudCB5YW5nIG1vZGVsIHNob3VsZCBiZSB0aGUgZGV0YWls ZWQgY29uZmlndXJhdGlvbiBmb3Igb25lIGRldmljZSwgc3VjaCBhcywgbXR1LCBob3AtbGltaXQs ZXRjLiBCdXQgc2VydmljZSBtb2RlbCBzaG91bGQgYmUgYSBsYXJnZXNjYWxlIGRlc2NyaXB0aW9u LCBzdWNoIGFzLCB0aGUgZW5kcG9pbnRzIGluIHRoZSBWUE4uIEJ1dCBzb21ldGltZXMsIG1hbnkg Y29uZmlndXJhdGlvbnMgeWFuZyBtb2RlbCBpbmNsdWRlIG1hbnkgZGV2aWNlcycgY29uZmlndXJh dGlvbiBvciBkbyBub3QgZGlzdGluZ3Vpc2ggd2hpY2ggZGV2aWNlcyBhcmUgY29uZmlndXJlZC4g U28gY291bGQgeW91IGdpdmUgbWUgc29tZSBtb3JlIHNwZWNpZmljIG1ldGhvZCB0byBjbGFzc2lm eSB0aGVtPyBNYXliZSB0aGUgZHJhZnQgW2RyYWZ0LXRyYW4taXBzZWNtZS15YW5nLTAxXSBpcyBh IGdvb2QgZXhhbXBsZS4NCg0KIFRoZSBtZXRob2QgdG8gY2xhc3NpZnkgbW9kZWxzIGFsb25nIHRo ZSBzdWdnZXN0ZWQgYWJzdHJhY3Rpb24gbGF5ZXJzIGFyZSBkZWZpbmVkIGluIHNlY3Rpb25zIDIu MSBhbmQgMi4yLiBUaGUgaW50ZW50IGhlcmUgaXMgb2YgY291cnNlIHRvIGJlIGNsZWFyIGVub3Vn aCBpbiB0aG9zZSBkZXNjcmlwdGlvbnMgZm9yIHBlb3BsZSB0byBiZSBhYmxlIHRvIHVzZSB0aGVt IChpLmUuIGNsYXNzaWZ5IG1vZGVscykuIElmIHlvdSB0aGluayB0aGUgY29udGVudCBvZiB0aG9z ZSBzZWN0aW9ucyBhcmUgbm90IGNsZWFyIGVub3VnaCBvciBwbGFpbiB3cm9uZywgSeKAmWQgYmUg bW9yZSB0aGFuIGhhcHB5IHRvIHRha2UgdGhhdCBmZWVkYmFjay4NCg0KIEkgYW0gbm90IGFuIGV4 cGVydCBpbiBJUFNlYywgYnV0IGdsYW5jaW5nIHRocm91Z2ggZHJhZnQtdHJhbi1pcHNlY21lLXlh bmctMDEgSSBzZWUgbWFueSByZWZlcmVuY2VzIHRvIOKAnHRoZSBzeXN0ZW3igJ0sIGFzIGluOg0K DQrigJzigJ3igJ0NClRoZSBJUFNFQyBHbG9iYWwgU3RhdGlzdGljcyBjb250YWluZXIgaXMgdXNl ZCB0byBtYWludGFpbg0KaW5mb3JtYXRpb24gcmVsYXRlZCB0byBhbGwgdGhlIElQU0VDIHR1bm5l bHMgZXN0YWJsaXNoZWQgaW4gdGhlDQpzeXN0ZW0uDQrigJzigJ0iDQoNCg0KIEZyb20gc2VjdGlv biAyLjIuIGluIHRoZSBjbGFzc2lmaWNhdGlvbiBtb2RlbDoNCg0K4oCc4oCd4oCdDQpOZXR3b3Jr IEVsZW1lbnQgWUFORyBEYXRhIE1vZGVscyBkZXNjcmliZSB0aGUgY29uZmlndXJhdGlvbiwgc3Rh dGUNCmRhdGEgYW5kIG9wZXJhdGlvbnMgb2YgYSBuZXR3b3JrIGRldmljZSBhcyBkZWZpbmVkIGJ5 IHRoZSB2ZW5kb3Igb2YNCnRoYXQgZGV2aWNlLiAgVGhlIG1vZGVscyBhcmUgY29tbW9ubHkgc3Ry dWN0dXJlZCBhcm91bmQgZmVhdHVyZXMgb2YNCnRoZSBkZXZpY2UsIGUuZy4gaW50ZXJmYWNlIGNv bmZpZ3VyYXRpb24gW1JGQzcyMjNdLCBPU1BGIGNvbmZpZ3VyYXRpb24NCltJLUQuaWV0Zi1vc3Bm LXlhbmddLCBhbmQgZmlyZXdhbGwgcnVsZXMgZGVmaW5pdGlvbnMNCltJLUQuaWV0Zi1uZXRtb2Qt YWNsLW1vZGVsXS4NCuKAnOKAneKAnQ0KDQogSSB3b3VsZCB0aGVuIHN1Z2dlc3QgdGhhdCB0aGUg bW9kdWxlcyBpbiBkcmFmdC10cmFuLWlwc2VjbWUteWFuZyByZXByZXNlbnQgTmV0d29yayBFbGVt ZW50IFlBTkcgRGF0YSBNb2RlbHMuDQoNCj4gQmVzdCwNCj4gWWFsaQ0KPiANCj4gLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IENhcmwgTW9iZXJnIChjYW1vYmVyZykgW21haWx0 bzpjYW1vYmVyZ0BjaXNjby5jb21dIA0KPiDlj5HpgIHml7bpl7Q6IDIwMTblubQ05pyIMjHml6Ug MTY6NDENCj4g5pS25Lu25Lq6OiB6aGFuZ3lhbGkgKEQpDQo+IOaKhOmAgTogbmV0bW9kQGlldGYu b3JnDQo+IOS4u+mimDogUmU6IFtuZXRtb2RdIHlhbmcgbW9kZWwgY2xhc3NpZmljYXRpb24NCj4g DQo+PiBPbiBBcHIgMjEsIDIwMTYsIGF0IDEwOjMwIEFNLCB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lh bGkzNjlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIENhcmwsDQo+PiANCj4+IFRoYW5r cyBmb3IgeW91ciBhbnN3ZXJzIHZlcnkgbXVjaC4gRnJvbSB5b3VyIGV4cGxhbmF0aW9uLCB0aGUg bWFpbiB2aWV3IGlzIHRoYXQgZG8gbm90IGRpc3Rpbmd1aXNoIHRoZSBkaWZmZXJlbmNlIGJldHdl ZW4gbmV0d29yayBsZXZlbCBhbmQgc2VydmljZSBsZXZlbCBtb2RlbCwgd2hpY2ggYWxsIGNhbGxl ZCAibmV0d29yayBzZXJ2aWNlIG1vZGVsIiwgcmlnaHQ/DQo+PiBJZiBzbywgdGhlIHF1ZXN0aW9u IGlzIHRoYXQgaG93IHRoZXNlICJzYW1lIGxheWVyIiBtb2RlbCBjb3VsZCBiZSB1c2VkIGluIHRo ZSBsYXllcmVkIGFyY2hpdGVjdHVyZSwgc3VjaCBhcywgdGhlcmUgYXJlIG9yY2hlc3RyYXRvciBs YXllciwgY29udHJvbGxlciBsYXllciBhbmQgZGV2aWNlIGxheWVyPyBJbiBteSB1bmRlcnN0YW5k aW5nLCB0aGUgTkJJIG9mIG9yY2hlc3RyYXRvciBzaG91bGQgbm90IGluY2x1ZGUgYW55IHRlY2hu b2xvZ3kgZGV0YWlscyB3aGljaCBzaG91bGQgZXhpc3QgaW4gdGhlIE5CSSBvZiBjb250cm9sbGVy LiBUaGUgb3JjaGVzdHJhdG9yIHdpbGwgY29tcGxldGUgdGhlIG1hcHBpbmcgZnJvbSBOQkkgb2Yg b3JjaGVzdHJhdG9yIHRvIE5CSSBvZiBjb250cm9sbGVyLg0KPiANCj4gVGhlIHZpZXcgb2YgdGhp cyB2YXJpZXMgd2lsZGx5IGFjcm9zcyBzdGFuZGFyZHMgYm9kaWVzLCBvcGVuIHNvdXJjZSBwcm9q ZWN0cywgdmVuZG9ycyBhbmQgbWFueSBvdGhlciBlbnRpdGllcyBpbnZvbHZlZC4gSS5lLiBtb3N0 IG9yY2hlc3RyYXRvcnMgZG8gbGVhayB0ZWNobm9sb2d5IGRldGFpbHMgYW5kIE5CSXMgb2YgY29u dHJvbGxlcnMgY29udGFpbiBhYnN0cmFjdGlvbnMgYWJvdmUgdGhlIG5ldHdvcmsgbGV2ZWwuDQo+ IA0KPj4gTGV0J3MgdGFrZSBMMlZQTiBhcyBhIGV4YW1wbGUuIEluIHRoZSBOQkkgb2Ygb3JjaGVz dHJhdG9yLCB0aGUgeWFuZyBtb2RlbCBqdXN0IG5lZWQgZXhwcmVzcyBuZWNlc3NhcnkgaW5mb3Jt YXRpb24gb2YgTDJWUE4sIHN1Y2ggYXMsIHNpdGVzIGluZm9ybWF0aW9uIGFuZCB0b3BvbG9neSBi ZXR3ZWVuIHNpdGVzLiBGb3IgdGhlIE5CSSBvZiBjb250cm9sbGVyLCB0aGUgeWFuZyBtb2RlbCBt YXkgYmUgc29tZSB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywgVlBMUywgVlBXUywgZXRj LiBUaGUgb3JjaGVzdHJhdG9yIHdpbGwgY2hvb3NlIG9uZSBvciBzb21lIHNvbHV0aW9ucyBkZXBl bmRzIG9uIHVzZXJzJyByZXF1aXJlbWVudC4gVGhlbiB0aGUgY29udHJvbGxlciB3aWxsIGNvbXBs ZXRlIHRoZSBuZXR3b3JrIGVsZW1lbnQgY29uZmlndXJhdGlvbiAodXNpbmcgbmV0d29yayBlbGVt ZW50IHlhbmcgbW9kZWwgKSBhY2NvcmRpbmcgdG8gdGVjaG5vbG9neSBzb2x1dGlvbnMgY2hvc2Vu IGJ5IG9yY2hlc3RyYXRvci4NCj4gDQo+IFRoYXQgaXMgYWJzb2x1dGVseSBvbmUgd2F5IG9mIGxv b2tpbmcgKGFuZCBwZXJoYXBzIGV2ZW4gaW1wbGVtZW50aW5nKSBpdCwgYW1vbmcgc2V2ZXJhbCBv dGhlcnMuIEluIHRoaXMgY2FzZSwgYW5kIHVuZGVyIHRoZSBzdWdnZXN0ZWQgY2xhc3NpZmljYXRp b24gaW4gdGhlIGRvY3VtZW50LCBib3RoIHRoZSBjb250cm9sbGVyIGFuZCBvcmNoZXN0cmF0b3Ig bW9kZWxzIHdvdWxkIGJlIGV4YW1wbGVzIG9mIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9k ZWxzIHdpdGggZGlmZmVyZW50IGFic3RyYWN0aW9uIGxldmVscy4NCj4gDQo+PiBUaG91Z2ggSSBh bSBub3Qgc3VyZSBpZiB0aGUgcHJvY2VzcyBpcyBzdWl0YWJsZSwgdGhlIHNlcnZpY2UgbW9kZWwg YW5kIG5ldHdvcmsgbW9kZWwgYXJlIGRpZmZlcmVuY2Ugd2hpY2ggYXJlIHVzZWQgaW4gZGlmZmVy ZW50IHBsYWNlcy4gQW55IGNvbW1lbnRzPw0KPiANCj4gQWJvdmUuDQo+IA0KPj4gDQo+PiBCZXN0 LA0KPj4gWWFsaQ0KPj4gDQo+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+PiDlj5Hku7bkuro6 IENhcmwgTW9iZXJnIChjYW1vYmVyZykgW21haWx0bzpjYW1vYmVyZ0BjaXNjby5jb21dIA0KPj4g 5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIx5pelIDE1OjQ3DQo+PiDmlLbku7bkuro6IHpoYW5n eWFsaSAoRCkNCj4+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+PiDkuLvpopg6IFJlOiBbbmV0 bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+PiANCj4+IFlhbGksDQo+PiANCj4+PiBP biBBcHIgMjEsIDIwMTYsIGF0IDY6MDMgQU0sIHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBo dWF3ZWkuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBhbGwsDQo+Pj4gDQo+Pj4gSSBub3RpY2Vk IHRoYXQgdGhlcmUgaXMgYSBkcmFmdCBpbnRlbnRzIHRvIGNsYXNzaWZ5IHRoZSB2YXJpb3VzIHlh bmcgbW9kZWwsIGl0IGlzIHJlYWxseSBhIG1lYW5pbmdmdWwgd29yay4gTWFueSBwb2ludHMgYXJl IGNvbnNpc3RlbnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nLCB3aGVyZWFzLCB0aGVyZSBhcmUgc29t ZSBxdWVzdGlvbnMgdW5jbGVhciBuZWVkIHRvIGlucXVpcmUuDQo+Pj4gDQo+Pj4gMS4gICAgICAg V2h5IFZQTFMgYW5kIFZQV1MgYXJlIGFsbCBzZXJ2aWNlIG1vZGVsLCB3aGljaCBpcyBhdCB0aGUg c2FtZSBsZXZlbCB3aXRoIEwzVlBOPyBJbiBteSB1bmRlcnN0YW5kaW5nLCBMM1ZQTiBpcyBhIHR5 cGljYWwgc2VydmljZSBtb2RlbCB3aGljaCBoaWRlcyB0aGUgdW5kZXJsYXkgbmV0d29yaywgYnV0 IGJvdGggVlBMUyBhbmQgVlBXUyBpcyBzcGVjaWZpYyB0ZWNobm9sb2d5IHNvbHV0aW9ucy4gTWF5 YmUgYSB1bmlmb3JtIEwyVlBOIHdoaWNoIGFic3RyYWN0cyBzZXJ2aWNlIGluZm9ybWF0aW9uIGZy b20gYWxsIGxheWVyMiB0ZWNobm9sb2dpZXMgbW9yZSBsaWtlIHNlcnZpY2UgbW9kZWwuDQo+PiAN Cj4+IFNlY3Rpb24gMi4xIGdvZXMgdG8gc29tZSBsZW5ndGggdG8gZGVzY3JpYmUgdGhhdCB0aGVy ZSBhcmUgdmFyaW91cyB0eXBlcyBvZiBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscyBh dCB2YXJpb3VzIGxldmVscyBvZiBhYnN0cmFjdGlvbnMuIFRoaXMgbWVhbnMgdGhhdCBib3RoIGdl bmVyaWMgbW9kZWxzIChlLmcuIGEgdGVjaG5vbG9neSBhZ25vc3RpYyBMMyBWUE4gbW9kZWwpIGFu ZCBtb3JlIGltcGxlbWVudGF0aW9uLW9yaWVudGVkIG1vZGVscyAoZS5nLiBWUExTKSB3b3VsZCBi ZSBjbGFzc2lmaWVkIGFzIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9kZWxzIHdpdGhvdXQg YmVpbmcgYXQgdGhlIGV4YWN0IHNhbWUgbGV2ZWwgb2YgYWJzdHJhY3Rpb24uDQo+PiANCj4+PiAy LiAgICAgICBXaGF0IGlzIHRoZSBsYXllciBvZiB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBh cywgVnhMQU4sIEdSRSwgVlBMUywgZXRjPw0KPj4gDQo+PiBJZiB5b3UgYXJlIHRhbGtpbmcgYWJv dXQgVnhMQU4sIEdSRSwgVlBMUyBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0 ZXJzIHJlc2lkaW5nIG9uIGEgZGV2aWNlLCB0aGVuIGl04oCZcyBOZXR3b3JrIEVsZW1lbnQgWUFO RyBEYXRhIG1vZGVscy4gSWYgeW914oCZcmUgdGFsa2luZyBhYm91dCBWeExBTiwgR1JFLCBWUExT IGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgYXMgcGFydCBvZiBhbiAi YWJzdHJhY3QgbW9kZWwgdGhhdCBhbGxvd3MgaW5zdGFuY2VzIG8gdGhlIHNlcnZpY2UgdG8gYmUg ZGVjb21wb3NlZCBpbnRvIGluc3RhbmNlIGRhdGEgYWNjb3JkaW5nIHRvIHRoZSBOZXR3b3JrIEVs ZW1lbnQgZGF0YSBtb2RlbHMgb2YgdGhlIHBhcnRpY2lwYXRpbmcgbmV0d29yayBlbGVtZW50c+KA nSwgdGhlbiBpdCB3b3VsZCBiZSBjbGFzc2lmaWVkIGFzIGEgTmV0d29yayBTZXJ2aWNlIFlBTkcg RGF0YSBNb2RlbHMuIA0KPj4gDQo+Pj4gMy4gICAgICAgSW4gVE1OIE0uMzAxMCwgbmV0d29yayBt b2RlbCBhbHNvIGEgcGFydGljdWxhciBsYXllciwgc2hvdWxkIHNwZWNpZmljIHlhbmcgbW9kZWwg Y292ZXIgdGhpcyBsYXllcj8NCj4+IA0KPj4gSSBoYXZlIGRvbmUgc29tZSByZWFkaW5nIG9uIE0u MzAxMCBhbmQgYmVsaWV2ZSB3ZSBhcmUgd2VsbCBhbGlnbmVkIGluIHRoZSBkcmFmdC4gVGhlIG5l dHdvcmsgbW9kZWwgd291bGQgYmUgY2xhc3NpZmllZCBhZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFO RyBEYXRhIE1vZGVsLg0KPj4gDQo+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+IFlhbGkNCj4+PiANCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gDQo+IA0KDQo= From nobody Fri Apr 22 05:14:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D712D78B for ; Fri, 22 Apr 2016 05:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1Mcz4oUy4J3 for ; Fri, 22 Apr 2016 05:14:40 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF3612DB1A for ; Fri, 22 Apr 2016 05:14:40 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C50AC1CC0291; Fri, 22 Apr 2016 14:14:40 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , bclaise@cisco.com In-Reply-To: <20160421.122409.329112641806495413.mbj@tail-f.com> References: <56D5B319.90703@cisco.com> <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 22 Apr 2016 14:14:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:14:44 -0000 Martin Bjorklund writes: > Hi Benoit, > > Benoit Claise wrote: >> Dear all, >> >> Here is part 1 of my AD review. >> >> I found this useful: >> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt >> >> - Do we want to mention RESTCONF in the abstract? From the new charter: >> >> The NETMOD working group has defined the data modeling language >> YANG, which can be used to specify network management data models >> that are transported over such protocols as NETCONF and RESTCONF. >> >> OLD: >> >> YANG is a data modeling language used to model configuration data, >> state data, remote procedure calls, and notifications for network >> management protocols like the Network Configuration Protocol >> (NETCONF). >> >> NEW: >> >> YANG is a data modeling language used to model configuration data, >> state data, remote procedure calls, and notifications for network >> management protocols transported over such protocols as Network >> Configuration Protocol (NETCONF) and RESTCONF. This document specifies >> the YANG mappings to NETCONF. > > The first paragraph in the introduction mentions other protocols; > RESCTONF and CoMI. My personal opinion is that this is sufficient, > but I'd like to hear what others think. > >> - Section 1.1 >> Can we want to stress the backwards incompatible changes from YANG >> version 1 in a specific paragraph? > > Ok, this is a good idea. I'll move them to a separate list. > > >> I see >> o Changed the rules for the interpretation of escaped characters in >> double quoted strings. This is an backwards incompatible change >> from YANG version 1. A module that uses a character sequence that >> is now illegal must change the string to match the new rules. See >> Section 6.1.3 >> >> for details. >> >> o An unquoted string cannot contain any single or double quote >> characters. This is an backwards incompatible change from YANG >> version 1. >> >> >> There is section 12, but this is not exactly that. >> >> Have we made an analysis of the 38 RFC-produced YANG modules? Any >> facing issues with 1.1 compilation? > > I have tested to put "yang-version 1.1;" into all RFC-published > modules, and then ran pyang on them w/o any issues. > >> - Section 1.1 >> Since this document introduces the NETCONF mapping, the protocol >> change must be included in section 1.1 >> Example: no NETCONF capability exchange in YANG 1.1, we use >> exclusively the YANG library >> Any other ones? >> - Section 3 >> o anydata: A data node that can contain an unknown set of nodes that >> can be modelled by YANG. >> >> NEW >> >> o anydata: A data node that can contain an unknown set of nodes that >> can be modelled by YANG, except anyxml, but for which the data >> model is not known at module design time. > > Ok, but I'd say: > > NEW: > > o anydata: A data node that can contain an unknown set of nodes that > can be modelled by YANG, except anyxml. > > This is just a summary; the details are to be found in later sections. > > >> - Terminology: >> The following terms are defined in [RFC6241 >> ]: >> >> ... >> >> o configuration datastore: a configuration datastore is an >> instantiated data tree with configuration data >> >> o datastore: an instantiated data tree >> >> RFC6241 has different definition for "configuration datastore" and >> "datastore". >> I would just provide the pointer to the RFC 6241 definitions. >> If you intend to provide an adapted definition for the YANG mappings, >> then you should say so. > > How about: > > OLD: > > o configuration datastore: a configuration datastore is an > instantiated data tree with configuration data > > o datastore: an instantiated data tree > > NEW: > > o configuration datastore: When modelled with YANG, a configuration > datastore is an instantiated data tree with configuration data > > o datastore: When modelled with YANG, an instantiated data tree > > > > >> - Section 4.1 >> >> YANG models can describe constraints to be enforced on the data, >> restricting the appearance or value of nodes based on the presence or >> value of other nodes in the hierarchy. >> >> I was looking for an example of appearance. >> NEW? >> YANG models can describe constraints to be enforced on the data, >> restricting the appearance (for example, with the "when" statement) >> or value of nodes based on the presence or value of other nodes in >> the hierarchy. > > This is very early in the document, and the text tries to give a very > high level function overview. I am not sure that mentioning "when" at > this time actually helps a first time reader. I would prefer to > leave it as it is. > > >> - section 4.2.2.3, Container Nodes >> >> A container is used to group related nodes in a subtree. A container >> has only child nodes and no value. A container may contain any >> number of child nodes of any type (leafs, lists, containers, leaf- >> lists, and actions). >> And notification, right? This should be added > > Ok. > >> container-stmt = container-keyword sep identifier-arg-str optsep >> (";" / >> "{" stmtsep >> ;; these stmts can appear in any order >> [when-stmt] >> *if-feature-stmt >> *must-stmt >> [presence-stmt >> ] >> [config-stmt] >> [status-stmt] >> [description-stmt] >> [reference-stmt] >> *(typedef-stmt / grouping-stmt) >> *data-def-stmt >> *action-stmt >> *notification-stmt >> "}") stmtsep >> >> - Examples >> I guess that no examples are supposed to compile, right? >> Please add a sentence saying so. > > > I honestly does not think that this is an issue, but how about this: > > NEW: > > 3.1. A Note on Examples > > Throughout this document there are many examples of YANG statements. > These examples are supposed to illustrate certain features, and are > not supposed to be complete, valid YANG modules. > > > >> When Andy's proposal will be ready (TAG: EXAMPLE-BEGINS => the YANG >> example compiles, NO TAG: => no supposed to compile), this document >> will already be compliant. >> >> - Section 4.2.4 >> >> +---------------------+-------------------------------------+ >> | Name | Description | >> +---------------------+-------------------------------------+ >> | binary | Any binary data | >> | bits | A set of bits or flags | >> | boolean | "true" or "false" | >> | decimal64 | 64-bit signed decimal number | >> | empty | A leaf that does not have any value | >> | enumeration | Enumerated strings | >> | identityref | A reference to an abstract identity | >> | instance-identifier | References a data tree node | >> >> Editorial: What the difference between: A reference or references? Be >> consistent > > No difference. I'll change to A reference. > >> - Section4.2.7 >> - . >> - Choices >> >> To be consistent with >> >> When a node from one case is created in the data tree, all nodes from >> all other cases are implicitly deleted. >> >> >> This text in section 7.9 should be updated. >> OLD: >> Since only one of the choice's cases can be valid at any time, the >> creation of a node from one case implicitly deletes all nodes from >> all other cases. If a request creates a node from a case, the server >> will delete any existing nodes that are defined in other cases inside >> the choice. >> >> NEW: >> Since only one of the choice's cases can be valid at any time_in the >> data tree_, the >> creation of a node from one case implicitly deletes all nodes from >> all other cases. If a request creates a node from a case, the server >> will delete any existing nodes that are defined in other cases inside >> the choice. > > Ok. > >> - Section 4.2.9 >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> example-fw-2.3 >> >> >> >> Editorial: Alignment > > Fixed. > >> - Editorial: is there a logic in the numbering? >> > > When there are two rpcs in the same example, I use 101, 102. > > I double checked, and fixed two occurences where 101 was used instead > of 102. > >> - section 4.2.9 >> >> Operations can also be tied to a >> data node. Such operations are defined with the "action" statement. >> >> From the definition: >> o data node: A node in the schema tree that can be instantiated in a >> data tree. One of container, leaf, leaf-list, list, anydata, and >> anyxml. >> >> And I see in section 7.15: >> The "action" statement is used to define an operation connected to a >> specific container or list data node. >> >> >> I believe it should be clarified in 4.2.9 >> NEW: >> Operations can also be tied to a >> container or list data node. Such operations are defined with the >> "action" statement. > > Ok. > >> - Section 5.1 >> Editorial >> OLD: >> o A module or submodule belonging to that module can reference >> definitions in the module and all submodules included by the >> module. >> >> NEW? >> o A module, or submodule belonging to that module, can reference >> definitions in the module and all submodules included by that >> module. > > Yes, fixed. > >> - The following examples (as far as my quick check goes) are the only >> - one that misses "yang-version 1.1" >> >> module example-augment { >> namespace "urn:example:augment"; >> prefix mymod; >> import ietf-interfaces { >> prefix if; >> } >> >> module example-a { >> namespace urn:example:a; >> prefix a; > > Fixed. > >> - Section 5.6.4 >> If a server implements a module A that imports a module B, and A uses >> any node from B in an "augment" or "path" statement that the server >> supports, then the server MUST implement a revision of module B that >> has these nodes defined. This is regardless of if module B is >> imported by revision or not. >> >> "imported by revision or not" I'm, confused because I read the >> document in sequence. >> From 5.1 and 5.1.1, it doesn't look like we have two options (import >> by revision or not) >> And the example shows the two possibilities: >> import b { >> revision-date 2015-01-01; >> } >> import c; >> >> I found my answer in section 7.1.5: >> When the optional "revision-date" substatement is present, any >> typedef, grouping, extension, feature, and identity referenced by >> definitions in the local module are taken from the specified revision >> of the imported module. It is an error if the specified revision of >> the imported module does not exist. If no "revision-date" >> substatement is present, it is undefined from which revision of the >> module they are taken. >> >> You should write a sentence or two (imported by revision or not) about >> in section 5.1 or 5.1.1 > > OLD: > > Published modules evolve independently over time. In order to allow > for this evolution, modules need to be imported using specific > revisions. When a module is written, it uses the current revisions > of other modules, based on what is available at the time. > > NEW: > > Published modules evolve independently over time. In order to allow > for this evolution, modules can be imported using specific revisions. > When a module is written, it can import the current revisions of > other modules, based on what is available at the time. IMO, "published" should be removed unless its meaning is explained. Lada > > And then a new paragraph last in the same section (5.1.1): > > NEW: > > If a module is not imported with a specific revision, it is undefined > which excat revision is used. > > >> - section 5.6.4 >> A server MUST NOT implement more than one revision of a module. >> >> You should add that the server may contain more than one version for >> import reasons. >> This would be in line with >> https://tools.ietf.org/html/draft-ietf-netconf-yang-library-05 >> >> This mandatory list contains one entry for each YANG data model >> module supported by the server. There MUST be an entry in this list >> for each revision of each YANG module that is used by the server. It >> is possible for multiple revisions of the same module to be imported, >> in addition to an entry for the revision that is implemented by the >> server. > > I started to write some text to address this issue, but it felt out of > place. This section is about modules that are implemented. Other > modules can be listed according to yang-library; but that is a > yang-library issue, not YANG 1.1. So I prefer to leave this section > as it is. > > >> - section 5.6.4 >> ietf-yang-library comes out of the blue in section 5.6.4 >> >> If a server implements a module A that imports a module C without >> specifying the revision date of module C, and the server does not >> implement C (e.g., if C only defines some typedefs), the server MUST >> list module C in the "/modules-state/module" list from >> "ietf-yang-library" [I-D.ietf-netconf-yang-library >> ], >> and it MUST set >> the leaf "conformance-type" to "import" for this module. >> >> You should say a few words about it in section 4. >> Alternatively, the content in 5.6.5 should come before 5.6.4 > > Agreed. I switched the order of 5.6.4 and 5.6.5, and added a forward > reference: > > A NETCONF server announces the modules it implements (Section 5.6.5) > > >> - Some statements in the ABNF section contains links. Intended? Talking >> - with Martin, he submitted only the .txt version. >> So it seems that the issues resides in the ietf submission tool >> chain. To be solved during AUTH48, I guess. >> >> Example: >> >> container-stmt = container-keyword sep identifier-arg-str optsep >> (";" / >> "{" stmtsep >> ;; these stmts can appear in any order >> [when-stmt] >> *if-feature-stmt >> *must-stmt >> [presence-stmt >> ] >> ... >> >> >> refine-stmt = refine-keyword sep refine-arg-str optsep >> "{" stmtsep >> ;; these stmts can appear in any order >> *if-feature-stmt >> *must-stmt >> [presence-stmt] >> [default-stmt] >> [config-stmt] >> [mandatory-stmt] >> [min-elements-stmt] >> [max-elements-stmt >> ] >> [description-stmt] >> [reference-stmt] >> "}" stmtsep > > Ok. > > > /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 Apr 22 05:24:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E837512E906 for ; Fri, 22 Apr 2016 05:24:39 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3tA36pdKla2 for ; Fri, 22 Apr 2016 05:24:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8A92812DD69 for ; Fri, 22 Apr 2016 05:24:37 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4B9301CC0291; Fri, 22 Apr 2016 14:24:40 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20160421.174657.1185541435255989696.mbj@tail-f.com> References: <20160419.105021.2152837727269070493.mbj@tail-f.com> <20160421.104523.1036688066875225335.mbj@tail-f.com> <20160421.174657.1185541435255989696.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 22 Apr 2016 14:24:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 ABNF for deviate-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:24:40 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Thu, Apr 21, 2016 at 1:45 AM, Martin Bjorklund wrote: >> >> > Hi Andy, >> > >> > Are you ok with the proposed OLD/NEW changes? >> > >> > >> Yes, except the issue of multiple deviations (that could be in 1 module on >> N modules). >> The actual result depends on the order the deviations are applied. >> This "last one wins" is implementation-dependent. Some text should be added >> either to fix it or warn people. (Note that the and YANG library >> are not ordered so they cannot be used to inform the client which of >> the N is actually applied.) This also affects the order of "deviate add >> default" >> for leaf-list. > > I prefer some warning text. In reality, I don't think is an issue. Hopefully. It could become a problem if, for example, deviations are bundled with other definitions. Lada > > > /martin > > > > > >> >> >> >> > >> > /martin >> >> >> >> Andy >> >> >> > >> >> >> > >> > Martin Bjorklund wrote: >> > > Andy Bierman wrote: >> > > > Hi, >> > > > >> > > > The ABNF for "default" is wrong in the deviate-*-stmt (add, replace, >> > delete) >> > > > Is says [default-stmt] but it should be *default-stmt >> > > >> > > Thanks, fixed. >> > > >> > > But for deviate-replace, it is not clear what the correct answer is. >> > > >> > > This is pretty clear: >> > > >> > > leaf foo { >> > > type int32; >> > > default 42; >> > > } >> > > >> > > deviation /foo { >> > > deviate replace { >> > > default 10; >> > > } >> > > } >> > > >> > > But what about this: >> > > >> > > leaf-list bar { >> > > type int32; >> > > default 42; >> > > default 43; >> > > } >> > > >> > > deviation /bar { >> > > deviate replace { >> > > default 10; >> > > default 11; >> > > } >> > > } >> > > >> > > Are all defaults changed? >> > > >> > > Compare with must and unique - they can not be replaced currently. >> > > >> > > In order to resolve this we probably need more text as well :( >> > > >> > > >> > > OLD: >> > > >> > > The argument "replace" replaces properties of the target node. The >> > > properties to replace are identified by substatements to the >> > > "deviate" statement. The properties to replace MUST exist in the >> > > target node. >> > > >> > > >> > > NEW: >> > > >> > > The argument "replace" replaces properties of the target node. The >> > > properties to replace are identified by substatements to the >> > > "deviate" statement. The properties to replace MUST exist in the >> > > target node. If multiple properties exist in the target node, all >> > > of them are replaced with the new properties defined in the >> > > substatements to the deviate statement. >> > > >> > > + add an example to the section "Usage examples": >> > > >> > > NEW: >> > > >> > > In this example, the original definition of a leaf list has two >> > > default values "42" and "43: >> > > >> > > leaf-list bar { >> > > type int32; >> > > default 42; >> > > default 43; >> > > } >> > > >> > > A server can change this to the values "10" and "11" instead: >> > > >> > > deviation /base:bar { >> > > deviate replace { >> > > default 10; >> > > default 11; >> > > } >> > > } >> > > >> > > >> > > Also, change the grammar: >> > > >> > > OLD: >> > > >> > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep >> > > (";" / >> > > "{" stmtsep >> > > ;; these stmts can appear in any order >> > > [type-stmt] >> > > [units-stmt] >> > > [default-stmt] >> > > [config-stmt] >> > > [mandatory-stmt] >> > > [min-elements-stmt] >> > > [max-elements-stmt] >> > > "}") stmtsep >> > > >> > > NEW: >> > > >> > > deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep >> > > (";" / >> > > "{" stmtsep >> > > ;; these stmts can appear in any order >> > > [type-stmt] >> > > [units-stmt] >> > > *must-stmt >> > > *unique-stmt >> > > *default-stmt >> > > [config-stmt] >> > > [mandatory-stmt] >> > > [min-elements-stmt] >> > > [max-elements-stmt] >> > > "}") stmtsep >> > > >> > > >> > > >> > > >> > > >> > > > Is it intentional that the ABNF for deviate-delete-stmt leaves out >> > > > config, mandatory, max-elements, and min-elements? >> > > > I understand why "type" cannot be removed. >> > > >> > > I don't really remember, but I can see that if you want to "delete" >> > > min-elements you can replace it and set it to 0. >> > > >> > > > IMO the rest of the statements should be removable. >> > > >> > > > Sec. 7.20.3.2 does not mention the restrictions indicated in the ABNF. >> > > > This section should make it clear a leaf has only 1 default >> > > > and the 0..n refers to leaf-list only. >> > > >> > > In general, the result after applying deviations must be valid - e.g., >> > > you cannot deviate "foo" as the default for an int32 leaf. >> > > >> > > > It should also be clear that the "deviate add default" for a leaf-list >> > > > is YANG statement order-dependent. >> > > > >> > > > Not as obvious -- a config=false leaf-list can have duplicate default >> > > > values. >> > > > The deviate-stmt has no way to specify which 1 to delete or replace >> > > > if there are duplicates. >> > > >> > > Unless replace will replace *all*, as suggested above. >> > > >> > > >> > > /martin >> > > >> > > _______________________________________________ >> > > netmod mailing list >> > > netmod@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netmod >> > > >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 22 05:26:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6586F12EBC1 for ; Fri, 22 Apr 2016 05:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.518 X-Spam-Level: X-Spam-Status: No, score=-15.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgW1RmvGVgYg for ; Fri, 22 Apr 2016 05:26:31 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F8812EBC0 for ; Fri, 22 Apr 2016 05:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2867; q=dns/txt; s=iport; t=1461327990; x=1462537590; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=W1AZ7yrOnstlvTk1/c8wOuhI/DyAs87LKjrJQzmyC1o=; b=SJbbJ8TGJC3Dah/q7Q/9MgnSyAOkbyffzxKaVEXI/R/pHDPlI2HXq1jn IjAQ0i/Cc43oA1C5nS+8U7I4Uz8RHMjnIhffYXtMZqzPNj6f03PQNHxAj VnEjcA/hw4KtL1pCqmuTxKNvkkZP0ZjqxYsRSBmpSfAVzTfythU7+FQai U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDTFxpX/xbLJq1ehAu7AwENgXMeh?= =?us-ascii?q?XACgVwUAQEBAQEBAWUnhEIBAQQ4QAEQCw4TFg8JAwIBAgFFBg0IAQGIJg6/NwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARQEhiGES4oVAQSYD4V7iBmBZodTI4U0jy8eAQFCg?= =?us-ascii?q?206iScBAQE?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="676871446" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2016 12:26:28 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3MCQSQv000790; Fri, 22 Apr 2016 12:26:28 GMT To: Martin Bjorklund References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> From: Benoit Claise Message-ID: <571A1874.6070306@cisco.com> Date: Fri, 22 Apr 2016 14:26:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160421.155857.43464387853940362.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] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:26:32 -0000 Hi Martin, Removed some extra ones on which we agree. See in line. > >>>> - Terminology: >>>> The following terms are defined in [RFC6241 >>>> ]: >>>> >>>> ... >>>> >>>> o configuration datastore: a configuration datastore is an >>>> instantiated data tree with configuration data >>>> >>>> o datastore: an instantiated data tree >>>> >>>> RFC6241 has different definition for "configuration datastore" and >>>> "datastore". >>>> I would just provide the pointer to the RFC 6241 definitions. >>>> If you intend to provide an adapted definition for the YANG mappings, >>>> then you should say so. >>> How about: >>> >>> OLD: >>> >>> o configuration datastore: a configuration datastore is an >>> instantiated data tree with configuration data >>> >>> o datastore: an instantiated data tree >>> >>> NEW: >>> >>> o configuration datastore: When modelled with YANG, a configuration >>> datastore is an instantiated data tree with configuration data >>> >>> o datastore: When modelled with YANG, an instantiated data tree >>> >> This issue is with "The following terms are defined in [RFC6241]", but >> you re-define those terms. >> So give a warning about the redefinition to the readers. > Yes, that's what my proposed text does. It says that "datastore" is > defined in 6241, and when YANG is used, it means the instantiated data > tree. OLD: The following terms are defined in [RFC6241 ]: NEW: The following terms are defined in [RFC6241 ], but re-defined in this document in YANG context: > >>>> - Section 4.1 >>>> >>>> YANG models can describe constraints to be enforced on the data, >>>> restricting the appearance or value of nodes based on the presence or >>>> value of other nodes in the hierarchy. >>>> >>>> I was looking for an example of appearance. >>>> NEW? >>>> YANG models can describe constraints to be enforced on the data, >>>> restricting the appearance (for example, with the "when" statement) >>>> or value of nodes based on the presence or value of other nodes in >>>> the hierarchy. >>> This is very early in the document, and the text tries to give a very >>> high level function overview. I am not sure that mentioning "when" at >>> this time actually helps a first time reader. >> The first time I read this, I was wondering how YANG data models can >> describe constraints on HOW data appear, while you wanted to express >> WHETHER a data appear. Maybe "when" is not the best way to help the >> first time user, but something is needed. > How about "restricting the presence or value of nodes"? Yes, thank you. Regards, Benoit From nobody Fri Apr 22 06:49:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F86112EAEC for ; Fri, 22 Apr 2016 06:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-jYhohtrY8S for ; Fri, 22 Apr 2016 06:49:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5A12DFFF for ; Fri, 22 Apr 2016 06:48:59 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 362361CC0291; Fri, 22 Apr 2016 15:49:02 +0200 (CEST) From: Ladislav Lhotka To: Dean Bogdanovic , "Sterne\, Jason \(Nokia - CA\)" In-Reply-To: <0EC4FCB5-1228-4D98-AC5C-12961765AA5D@gmail.com> References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com> <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com> <0EC4FCB5-1228-4D98-AC5C-12961765AA5D@gmail.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 22 Apr 2016 15:49:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod WG Subject: Re: [netmod] input Interface match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:49:03 -0000 Dean Bogdanovic writes: > Any other opinions on this issue? There were quite a few hands in the > air during the WG meeting Unlike packet header fields, metadata are very much implementation-specific, and may also depend on the context - e.g. whether packet filtering is ingress or egress. The draft cites nftables but in fact nftables includes several metadata items, not only input-interface: http://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainform= ation I would suggest to think about other aspects of ACL type, such as "ingress-acl" versus "egress-acl", and either define additional leafs for t= hese aspects or utilize multiple inheritance of identities that is possible in YANG 1.1. Then, I would extend the "metadata" grouping with other reasonably common metadata items (for example, output-interface or packet-length), and make each item conditional via "when" and/or "if-feature". Lada > > Dean > >> On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) wrote: >>=20 >> Hi Dean, >>=20=20 >> We should remove the metadata grouping from the base model. It is out o= f place with the rest of the model and a fairly clean line to draw as a bou= ndary for future extension/augmentation. >>=20=20 >> Regards, >> Jason >>=20=20 >> From: EXT Dean Bogdanovic [mailto:ivandean@gmail.com]=20 >> Sent: Friday, April 08, 2016 9:25 >> To: Sterne, Jason (Nokia - CA) >> Cc: netmod WG >> Subject: Re: [netmod] input Interface match >>=20=20 >> Jason, >>=20=20 >> After looking at the document and the model, it is also about having met= adata grouping in the model. If you want to have metadata grouping in the m= odel, then you have to have something inside and then input-interface quest= ions comes up. If you don=E2=80=99t have to have metadata grouping in the b= ase model, everything is easy. >>=20=20 >> I believe this is the right question >>=20=20 >> Dean >>=20=20 >> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) > wrote: >>=20=20 >> Hi Dean, >>=20=20 >> Just to clarify -> the main question posed in the WG meeting was about t= he input-interface match criteria. From the meeting minutes: >>=20=20 >> Chairs: call for if interface should be in base: >> 6 prefer NOT having it in the doc at all >> 5 prefer having it in, but as a feature >> 2 prefer having it in the doc as required >>=20=20 >> Maybe we should get agreement on what to do about input-interface (on th= e list) first and then we can figure out what to do about the metadata grou= ping. >>=20=20 >> Matching on basic IPv4/IPv4/MAC header fields is common functionality. = But having that input-interface match on metadata in the core model is out = of place. It should be left to further extension drafts or vendor specific= augmentations (along with whatever other metadata might be useful or vendo= r-specific). Many major implementations do not support matching on input-in= terface (Cisco IOS-XR, Nokia SR OS, Brocade, others). The typical way to a= ssociate ACLs and Interfaces is by assigning an ACL to an interface as show= n in section A.3. of the ACL draft. There is some discussion of this on t= he NETMOD thread =E2=80=9CRemove input-interface (metadata) from netmod-acl= -model-07 ?=E2=80=9D. >>=20=20 >> Regards, >> Jason >>=20=20 >> From: netmod [mailto:netmod-bounces@ietf.org ] On Behalf Of EXT Dean Bogdanovic >> Sent: Thursday, April 07, 2016 11:12 >> To: netmod WG >> Subject: [netmod] input Interface match >>=20=20 >> As the action item from the netmod WG and, hopefully, last open item in = the ACL draft is the leaf input interface in the metadata grouping=20 >>=20=20 >> grouping metadata { >> description >> "Fields associated with a packet which are not in >> the header."; >> leaf input-interface { >> type if:interface-ref { >> require-instance false; >> } >> description >> "Packet was received on this interface."; >> } >> } >> } >>=20=20 >>=20=20 >> Here are two questions: >> One >> Do want to have a metadata grouping in the basic ACL model? If yes, we h= ave to put in some leafs in there. There are implementations which use meta= data as match condition >>=20=20 >> If we agree that metadata grouping is not needed in the basic model, the= n the authors would remove the grouping from the model and I believe that n= o more discussion is needed on this point >>=20=20 >> Dean > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 22 19:12:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8854B12DF4A for ; Fri, 22 Apr 2016 19:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drkD9RdlBSJW for ; Fri, 22 Apr 2016 19:12: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 9343E12E2A8 for ; Fri, 22 Apr 2016 19:12:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMZ57465; Sat, 23 Apr 2016 02:12:27 +0000 (GMT) Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 23 Apr 2016 03:12:26 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.184]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0235.001; Sat, 23 Apr 2016 10:12:19 +0800 From: "zhangyali (D)" To: "Carl Moberg (camoberg)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A//8tEkCAAlrGAP//J36g Date: Sat, 23 Apr 2016 02:12:19 +0000 Message-ID: References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> In-Reply-To: <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.104.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.571ADA0B.0139, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.184, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a1b7b2358bfa3e031db7d837882245e5 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] =?utf-8?b?562U5aSNOiAgeWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlv?= =?utf-8?q?n?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 02:12:33 -0000 SGkgQ2FybCwNCg0KVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uKEkgYWxzbyB0aGluayB0aGUg SVBTZWMgeWFuZyBtb2RlbCBpcyBuZXR3b3JrIGVsZW1lbnQgbW9kZWwpLg0KSSB0aGluayB0aGUg bWFpbiBjcml0ZXJpYSB0byBkaXN0aW5ndWlzaCB0aGUgc2VydmljZSBtb2RlbCBhbmQgbmV0d29y ayBlbGVtZW50IG1vZGVsIGlzIHRoZSBwZXJzcGVjdGl2ZSB3aGVuIGRlZmluZSB0aGUgbW9kZWws IG5hbWVseSwgdGhlIG1vZGVsIHdpbGwgYmUgbmV0d29yayBzZXJ2aWNlIG1vZGVsIHdoZW4gaXQg ZGVzY3JpYmUgdGhlIHdob2xlIG5ldHdvcmsgc2VydmljZSBzdGFuZGluZyBvbiB0aGUgd2hvbGUg c2l0dWF0aW9uLCBvciBlbHNlLCBpdCB3aWxsIGJlIGEgbmV0d29yayBlbGVtZW50IG1vZGVsLiBB IHNpbXBsZSBleGFtcGxlLCB3aGVuIEkgZGVzY3JpYmUgYSBWUE4gc2VydmljZSwgaWYgdGhlIG1v ZGVsIGRlc2NyaWJlcyB3aGljaCB0d28gZW5kcG9pbnRzIG5lZWQgYmUgY29ubmVjdGVkIHRvZ2V0 aGVyLCBpdCBpcyBzZXJ2aWNlIG1vZGVsLiBBbmQgaWYgdGhlIG1vZGVsIGRlc2NyaWJlcyB0aGUg ZXh0ZXJuYWwgY29ubmVjdGl2aXR5IG9mIGVhY2ggZGV2aWNlLCBpdCB3aWxsIGJlIG5ldHdvcmsg ZWxlbWVudCBzZXJ2aWNlLiBEb2VzIHRoaXMgbWV0aG9kIG1ha2Ugc2Vuc2U/DQoNCkJlc3QsDQpZ YWxpDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogQ2FybCBNb2JlcmcgKGNh bW9iZXJnKSBbbWFpbHRvOmNhbW9iZXJnQGNpc2NvLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTbl ubQ05pyIMjLml6UgMTY6MDQNCuaUtuS7tuS6ujogemhhbmd5YWxpIChEKQ0K5oqE6YCBOiBuZXRt b2RAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRtb2RdIHlhbmcgbW9kZWwgY2xhc3NpZmljYXRp b24NCg0KDQotLQ0KQ2FybCBNb2JlcmcNClRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KY2Ftb2Jl cmdAY2lzY28uY29tDQoNCj4gT24gQXByIDIyLCAyMDE2LCBhdCA0OjQzIEFNLCB6aGFuZ3lhbGkg KEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiAN Cj4gSW5kZWVkLCB0aGVyZSBpcyB1bmNsZWFyIGZ1bmN0aW9uYWwgcGFydGl0aW9uaW5nIGJldHdl ZW4gb3JjaGVzdHJhdG9yIGFuZCBjb250cm9sbGVyLiBTbyBsZXQncyBnbyBiYWNrIHRvIHRoZSBk aXZpc2lvbiBvZiBuZXR3b3JrIGVsZW1lbnQgeWFuZyBtb2RlbCBhbmQgc2VydmljZSB5YW5nIG1v ZGVsLg0KPiANCj4gSW4gbXkgdmlldywgZWxlbWVudCB5YW5nIG1vZGVsIHNob3VsZCBiZSB0aGUg ZGV0YWlsZWQgY29uZmlndXJhdGlvbiBmb3Igb25lIGRldmljZSwgc3VjaCBhcywgbXR1LCBob3At bGltaXQsZXRjLiBCdXQgc2VydmljZSBtb2RlbCBzaG91bGQgYmUgYSBsYXJnZXNjYWxlIGRlc2Ny aXB0aW9uLCBzdWNoIGFzLCB0aGUgZW5kcG9pbnRzIGluIHRoZSBWUE4uIEJ1dCBzb21ldGltZXMs IG1hbnkgY29uZmlndXJhdGlvbnMgeWFuZyBtb2RlbCBpbmNsdWRlIG1hbnkgZGV2aWNlcycgY29u ZmlndXJhdGlvbiBvciBkbyBub3QgZGlzdGluZ3Vpc2ggd2hpY2ggZGV2aWNlcyBhcmUgY29uZmln dXJlZC4gU28gY291bGQgeW91IGdpdmUgbWUgc29tZSBtb3JlIHNwZWNpZmljIG1ldGhvZCB0byBj bGFzc2lmeSB0aGVtPyBNYXliZSB0aGUgZHJhZnQgW2RyYWZ0LXRyYW4taXBzZWNtZS15YW5nLTAx XSBpcyBhIGdvb2QgZXhhbXBsZS4NCg0KIFRoZSBtZXRob2QgdG8gY2xhc3NpZnkgbW9kZWxzIGFs b25nIHRoZSBzdWdnZXN0ZWQgYWJzdHJhY3Rpb24gbGF5ZXJzIGFyZSBkZWZpbmVkIGluIHNlY3Rp b25zIDIuMSBhbmQgMi4yLiBUaGUgaW50ZW50IGhlcmUgaXMgb2YgY291cnNlIHRvIGJlIGNsZWFy IGVub3VnaCBpbiB0aG9zZSBkZXNjcmlwdGlvbnMgZm9yIHBlb3BsZSB0byBiZSBhYmxlIHRvIHVz ZSB0aGVtIChpLmUuIGNsYXNzaWZ5IG1vZGVscykuIElmIHlvdSB0aGluayB0aGUgY29udGVudCBv ZiB0aG9zZSBzZWN0aW9ucyBhcmUgbm90IGNsZWFyIGVub3VnaCBvciBwbGFpbiB3cm9uZywgSeKA mWQgYmUgbW9yZSB0aGFuIGhhcHB5IHRvIHRha2UgdGhhdCBmZWVkYmFjay4NCg0KIEkgYW0gbm90 IGFuIGV4cGVydCBpbiBJUFNlYywgYnV0IGdsYW5jaW5nIHRocm91Z2ggZHJhZnQtdHJhbi1pcHNl Y21lLXlhbmctMDEgSSBzZWUgbWFueSByZWZlcmVuY2VzIHRvIOKAnHRoZSBzeXN0ZW3igJ0sIGFz IGluOg0KDQrigJzigJ3igJ0NClRoZSBJUFNFQyBHbG9iYWwgU3RhdGlzdGljcyBjb250YWluZXIg aXMgdXNlZCB0byBtYWludGFpbiBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIGFsbCB0aGUgSVBTRUMg dHVubmVscyBlc3RhYmxpc2hlZCBpbiB0aGUgc3lzdGVtLg0K4oCc4oCdIg0KDQoNCiBGcm9tIHNl Y3Rpb24gMi4yLiBpbiB0aGUgY2xhc3NpZmljYXRpb24gbW9kZWw6DQoNCuKAnOKAneKAnQ0KTmV0 d29yayBFbGVtZW50IFlBTkcgRGF0YSBNb2RlbHMgZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24s IHN0YXRlIGRhdGEgYW5kIG9wZXJhdGlvbnMgb2YgYSBuZXR3b3JrIGRldmljZSBhcyBkZWZpbmVk IGJ5IHRoZSB2ZW5kb3Igb2YgdGhhdCBkZXZpY2UuICBUaGUgbW9kZWxzIGFyZSBjb21tb25seSBz dHJ1Y3R1cmVkIGFyb3VuZCBmZWF0dXJlcyBvZiB0aGUgZGV2aWNlLCBlLmcuIGludGVyZmFjZSBj b25maWd1cmF0aW9uIFtSRkM3MjIzXSwgT1NQRiBjb25maWd1cmF0aW9uIFtJLUQuaWV0Zi1vc3Bm LXlhbmddLCBhbmQgZmlyZXdhbGwgcnVsZXMgZGVmaW5pdGlvbnMgW0ktRC5pZXRmLW5ldG1vZC1h Y2wtbW9kZWxdLg0K4oCc4oCd4oCdDQoNCiBJIHdvdWxkIHRoZW4gc3VnZ2VzdCB0aGF0IHRoZSBt b2R1bGVzIGluIGRyYWZ0LXRyYW4taXBzZWNtZS15YW5nIHJlcHJlc2VudCBOZXR3b3JrIEVsZW1l bnQgWUFORyBEYXRhIE1vZGVscy4NCg0KPiBCZXN0LA0KPiBZYWxpDQo+IA0KPiAtLS0tLemCruS7 tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSBbbWFpbHRv OmNhbW9iZXJnQGNpc2NvLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIx5pelIDE2 OjQxDQo+IOaUtuS7tuS6ujogemhhbmd5YWxpIChEKQ0KPiDmioTpgIE6IG5ldG1vZEBpZXRmLm9y Zw0KPiDkuLvpopg6IFJlOiBbbmV0bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+IA0K Pj4gT24gQXByIDIxLCAyMDE2LCBhdCAxMDozMCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxp MzY5QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBDYXJsLA0KPj4gDQo+PiBUaGFua3Mg Zm9yIHlvdXIgYW5zd2VycyB2ZXJ5IG11Y2guIEZyb20geW91ciBleHBsYW5hdGlvbiwgdGhlIG1h aW4gdmlldyBpcyB0aGF0IGRvIG5vdCBkaXN0aW5ndWlzaCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVu IG5ldHdvcmsgbGV2ZWwgYW5kIHNlcnZpY2UgbGV2ZWwgbW9kZWwsIHdoaWNoIGFsbCBjYWxsZWQg Im5ldHdvcmsgc2VydmljZSBtb2RlbCIsIHJpZ2h0Pw0KPj4gSWYgc28sIHRoZSBxdWVzdGlvbiBp cyB0aGF0IGhvdyB0aGVzZSAic2FtZSBsYXllciIgbW9kZWwgY291bGQgYmUgdXNlZCBpbiB0aGUg bGF5ZXJlZCBhcmNoaXRlY3R1cmUsIHN1Y2ggYXMsIHRoZXJlIGFyZSBvcmNoZXN0cmF0b3IgbGF5 ZXIsIGNvbnRyb2xsZXIgbGF5ZXIgYW5kIGRldmljZSBsYXllcj8gSW4gbXkgdW5kZXJzdGFuZGlu ZywgdGhlIE5CSSBvZiBvcmNoZXN0cmF0b3Igc2hvdWxkIG5vdCBpbmNsdWRlIGFueSB0ZWNobm9s b2d5IGRldGFpbHMgd2hpY2ggc2hvdWxkIGV4aXN0IGluIHRoZSBOQkkgb2YgY29udHJvbGxlci4g VGhlIG9yY2hlc3RyYXRvciB3aWxsIGNvbXBsZXRlIHRoZSBtYXBwaW5nIGZyb20gTkJJIG9mIG9y Y2hlc3RyYXRvciB0byBOQkkgb2YgY29udHJvbGxlci4NCj4gDQo+IFRoZSB2aWV3IG9mIHRoaXMg dmFyaWVzIHdpbGRseSBhY3Jvc3Mgc3RhbmRhcmRzIGJvZGllcywgb3BlbiBzb3VyY2UgcHJvamVj dHMsIHZlbmRvcnMgYW5kIG1hbnkgb3RoZXIgZW50aXRpZXMgaW52b2x2ZWQuIEkuZS4gbW9zdCBv cmNoZXN0cmF0b3JzIGRvIGxlYWsgdGVjaG5vbG9neSBkZXRhaWxzIGFuZCBOQklzIG9mIGNvbnRy b2xsZXJzIGNvbnRhaW4gYWJzdHJhY3Rpb25zIGFib3ZlIHRoZSBuZXR3b3JrIGxldmVsLg0KPiAN Cj4+IExldCdzIHRha2UgTDJWUE4gYXMgYSBleGFtcGxlLiBJbiB0aGUgTkJJIG9mIG9yY2hlc3Ry YXRvciwgdGhlIHlhbmcgbW9kZWwganVzdCBuZWVkIGV4cHJlc3MgbmVjZXNzYXJ5IGluZm9ybWF0 aW9uIG9mIEwyVlBOLCBzdWNoIGFzLCBzaXRlcyBpbmZvcm1hdGlvbiBhbmQgdG9wb2xvZ3kgYmV0 d2VlbiBzaXRlcy4gRm9yIHRoZSBOQkkgb2YgY29udHJvbGxlciwgdGhlIHlhbmcgbW9kZWwgbWF5 IGJlIHNvbWUgdGVjaG5vbG9neSBzb2x1dGlvbnMsIHN1Y2ggYXMsIFZQTFMsIFZQV1MsIGV0Yy4g VGhlIG9yY2hlc3RyYXRvciB3aWxsIGNob29zZSBvbmUgb3Igc29tZSBzb2x1dGlvbnMgZGVwZW5k cyBvbiB1c2VycycgcmVxdWlyZW1lbnQuIFRoZW4gdGhlIGNvbnRyb2xsZXIgd2lsbCBjb21wbGV0 ZSB0aGUgbmV0d29yayBlbGVtZW50IGNvbmZpZ3VyYXRpb24gKHVzaW5nIG5ldHdvcmsgZWxlbWVu dCB5YW5nIG1vZGVsICkgYWNjb3JkaW5nIHRvIHRlY2hub2xvZ3kgc29sdXRpb25zIGNob3NlbiBi eSBvcmNoZXN0cmF0b3IuDQo+IA0KPiBUaGF0IGlzIGFic29sdXRlbHkgb25lIHdheSBvZiBsb29r aW5nIChhbmQgcGVyaGFwcyBldmVuIGltcGxlbWVudGluZykgaXQsIGFtb25nIHNldmVyYWwgb3Ro ZXJzLiBJbiB0aGlzIGNhc2UsIGFuZCB1bmRlciB0aGUgc3VnZ2VzdGVkIGNsYXNzaWZpY2F0aW9u IGluIHRoZSBkb2N1bWVudCwgYm90aCB0aGUgY29udHJvbGxlciBhbmQgb3JjaGVzdHJhdG9yIG1v ZGVscyB3b3VsZCBiZSBleGFtcGxlcyBvZiBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVs cyB3aXRoIGRpZmZlcmVudCBhYnN0cmFjdGlvbiBsZXZlbHMuDQo+IA0KPj4gVGhvdWdoIEkgYW0g bm90IHN1cmUgaWYgdGhlIHByb2Nlc3MgaXMgc3VpdGFibGUsIHRoZSBzZXJ2aWNlIG1vZGVsIGFu ZCBuZXR3b3JrIG1vZGVsIGFyZSBkaWZmZXJlbmNlIHdoaWNoIGFyZSB1c2VkIGluIGRpZmZlcmVu dCBwbGFjZXMuIEFueSBjb21tZW50cz8NCj4gDQo+IEFib3ZlLg0KPiANCj4+IA0KPj4gQmVzdCwN Cj4+IFlhbGkNCj4+IA0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4g5Y+R5Lu25Lq6OiBD YXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdAY2lzY28uY29tXQ0KPj4g5Y+R 6YCB5pe26Ze0OiAyMDE25bm0NOaciDIx5pelIDE1OjQ3DQo+PiDmlLbku7bkuro6IHpoYW5neWFs aSAoRCkNCj4+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+PiDkuLvpopg6IFJlOiBbbmV0bW9k XSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+PiANCj4+IFlhbGksDQo+PiANCj4+PiBPbiBB cHIgMjEsIDIwMTYsIGF0IDY6MDMgQU0sIHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBodWF3 ZWkuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBhbGwsDQo+Pj4gDQo+Pj4gSSBub3RpY2VkIHRo YXQgdGhlcmUgaXMgYSBkcmFmdCBpbnRlbnRzIHRvIGNsYXNzaWZ5IHRoZSB2YXJpb3VzIHlhbmcg bW9kZWwsIGl0IGlzIHJlYWxseSBhIG1lYW5pbmdmdWwgd29yay4gTWFueSBwb2ludHMgYXJlIGNv bnNpc3RlbnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nLCB3aGVyZWFzLCB0aGVyZSBhcmUgc29tZSBx dWVzdGlvbnMgdW5jbGVhciBuZWVkIHRvIGlucXVpcmUuDQo+Pj4gDQo+Pj4gMS4gICAgICAgV2h5 IFZQTFMgYW5kIFZQV1MgYXJlIGFsbCBzZXJ2aWNlIG1vZGVsLCB3aGljaCBpcyBhdCB0aGUgc2Ft ZSBsZXZlbCB3aXRoIEwzVlBOPyBJbiBteSB1bmRlcnN0YW5kaW5nLCBMM1ZQTiBpcyBhIHR5cGlj YWwgc2VydmljZSBtb2RlbCB3aGljaCBoaWRlcyB0aGUgdW5kZXJsYXkgbmV0d29yaywgYnV0IGJv dGggVlBMUyBhbmQgVlBXUyBpcyBzcGVjaWZpYyB0ZWNobm9sb2d5IHNvbHV0aW9ucy4gTWF5YmUg YSB1bmlmb3JtIEwyVlBOIHdoaWNoIGFic3RyYWN0cyBzZXJ2aWNlIGluZm9ybWF0aW9uIGZyb20g YWxsIGxheWVyMiB0ZWNobm9sb2dpZXMgbW9yZSBsaWtlIHNlcnZpY2UgbW9kZWwuDQo+PiANCj4+ IFNlY3Rpb24gMi4xIGdvZXMgdG8gc29tZSBsZW5ndGggdG8gZGVzY3JpYmUgdGhhdCB0aGVyZSBh cmUgdmFyaW91cyB0eXBlcyBvZiBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscyBhdCB2 YXJpb3VzIGxldmVscyBvZiBhYnN0cmFjdGlvbnMuIFRoaXMgbWVhbnMgdGhhdCBib3RoIGdlbmVy aWMgbW9kZWxzIChlLmcuIGEgdGVjaG5vbG9neSBhZ25vc3RpYyBMMyBWUE4gbW9kZWwpIGFuZCBt b3JlIGltcGxlbWVudGF0aW9uLW9yaWVudGVkIG1vZGVscyAoZS5nLiBWUExTKSB3b3VsZCBiZSBj bGFzc2lmaWVkIGFzIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9kZWxzIHdpdGhvdXQgYmVp bmcgYXQgdGhlIGV4YWN0IHNhbWUgbGV2ZWwgb2YgYWJzdHJhY3Rpb24uDQo+PiANCj4+PiAyLiAg ICAgICBXaGF0IGlzIHRoZSBsYXllciBvZiB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywg VnhMQU4sIEdSRSwgVlBMUywgZXRjPw0KPj4gDQo+PiBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQg VnhMQU4sIEdSRSwgVlBMUyBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJz IHJlc2lkaW5nIG9uIGEgZGV2aWNlLCB0aGVuIGl04oCZcyBOZXR3b3JrIEVsZW1lbnQgWUFORyBE YXRhIG1vZGVscy4gSWYgeW914oCZcmUgdGFsa2luZyBhYm91dCBWeExBTiwgR1JFLCBWUExTIGNv bmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgYXMgcGFydCBvZiBhbiAiYWJz dHJhY3QgbW9kZWwgdGhhdCBhbGxvd3MgaW5zdGFuY2VzIG8gdGhlIHNlcnZpY2UgdG8gYmUgZGVj b21wb3NlZCBpbnRvIGluc3RhbmNlIGRhdGEgYWNjb3JkaW5nIHRvIHRoZSBOZXR3b3JrIEVsZW1l bnQgZGF0YSBtb2RlbHMgb2YgdGhlIHBhcnRpY2lwYXRpbmcgbmV0d29yayBlbGVtZW50c+KAnSwg dGhlbiBpdCB3b3VsZCBiZSBjbGFzc2lmaWVkIGFzIGEgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0 YSBNb2RlbHMuIA0KPj4gDQo+Pj4gMy4gICAgICAgSW4gVE1OIE0uMzAxMCwgbmV0d29yayBtb2Rl bCBhbHNvIGEgcGFydGljdWxhciBsYXllciwgc2hvdWxkIHNwZWNpZmljIHlhbmcgbW9kZWwgY292 ZXIgdGhpcyBsYXllcj8NCj4+IA0KPj4gSSBoYXZlIGRvbmUgc29tZSByZWFkaW5nIG9uIE0uMzAx MCBhbmQgYmVsaWV2ZSB3ZSBhcmUgd2VsbCBhbGlnbmVkIGluIHRoZSBkcmFmdC4gVGhlIG5ldHdv cmsgbW9kZWwgd291bGQgYmUgY2xhc3NpZmllZCBhZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFORyBE YXRhIE1vZGVsLg0KPj4gDQo+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+IFlhbGkNCj4+PiANCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gDQo+IA0KDQo= From nobody Sun Apr 24 18:11:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9C12B061 for ; Sun, 24 Apr 2016 18:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0GLDy-sRwK4 for ; Sun, 24 Apr 2016 18:10:57 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4457C12B027 for ; Sun, 24 Apr 2016 18:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10814; q=dns/txt; s=iport; t=1461546657; x=1462756257; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S82irBwgrNIVCONEeLJPigResgpXc51GHRN7bbFGG6A=; b=dEWNHM0L7sw+VO1fcvqtQG1+ZoaoblYe9ixkd6HuknBzqvLqBeZZfo8w yvaZIjcYh2YOqAgu+Zz8MkVbUX4DthqJU7yCcNkU9M9REeKXLBXuxGvaW zc8b9ZOAtbtxtjFT8MN6fQgLNGwe8kNj35Fsf80cbhNWc4iK5vq9OEhIt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgDDbR1X/5ldJa1egzhTfQa5bQENg?= =?us-ascii?q?XUXC4UiSgIcejgUAQEBAQEBAWUnhEEBAQEDAQEBASARNwMLBQsCAQYCEgYCAiM?= =?us-ascii?q?DAgICJQsUAQIOAgQOBRuIBwgOkiedF5BKAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR8hSWBdQiCToQaI4MCK4IrBZgPAY4UjxCPLgEeAQFCggoWgUtshyk+fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,530,1454976000"; d="scan'208";a="263749754" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2016 01:10:56 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3P1AtFF008147 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Apr 2016 01:10:56 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 24 Apr 2016 20:10:55 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Sun, 24 Apr 2016 20:10:54 -0500 From: "Carl Moberg (camoberg)" To: "zhangyali (D)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A//8tEkCAAlrGAP//J36ggAUcG4A= Date: Mon, 25 Apr 2016 01:10:54 +0000 Message-ID: <6522411F-4426-4125-9A3E-60B16CB2AB3A@cisco.com> References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.139] Content-Type: text/plain; charset="utf-8" Content-ID: <797BB2067E4834428F718ED5EA772001@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 01:10:59 -0000 WWFsaSwNCg0KPiBPbiBBcHIgMjMsIDIwMTYsIGF0IDQ6MTIgQU0sIHpoYW5neWFsaSAoRCkgPHpo YW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIENhcmwsDQo+IA0KPiBUaGFu a3MgZm9yIHlvdXIgc3VnZ2VzdGlvbi4oSSBhbHNvIHRoaW5rIHRoZSBJUFNlYyB5YW5nIG1vZGVs IGlzIG5ldHdvcmsgZWxlbWVudCBtb2RlbCkuDQo+IEkgdGhpbmsgdGhlIG1haW4gY3JpdGVyaWEg dG8gZGlzdGluZ3Vpc2ggdGhlIHNlcnZpY2UgbW9kZWwgYW5kIG5ldHdvcmsgZWxlbWVudCBtb2Rl bCBpcyB0aGUgcGVyc3BlY3RpdmUgd2hlbiBkZWZpbmUgdGhlIG1vZGVsLCBuYW1lbHksIHRoZSBt b2RlbCB3aWxsIGJlIG5ldHdvcmsgc2VydmljZSBtb2RlbCB3aGVuIGl0IGRlc2NyaWJlIHRoZSB3 aG9sZSBuZXR3b3JrIHNlcnZpY2Ugc3RhbmRpbmcgb24gdGhlIHdob2xlIHNpdHVhdGlvbiwgb3Ig ZWxzZSwgaXQgd2lsbCBiZSBhIG5ldHdvcmsgZWxlbWVudCBtb2RlbC4gQSBzaW1wbGUgZXhhbXBs ZSwgd2hlbiBJIGRlc2NyaWJlIGEgVlBOIHNlcnZpY2UsIGlmIHRoZSBtb2RlbCBkZXNjcmliZXMg d2hpY2ggdHdvIGVuZHBvaW50cyBuZWVkIGJlIGNvbm5lY3RlZCB0b2dldGhlciwgaXQgaXMgc2Vy dmljZSBtb2RlbC4gQW5kIGlmIHRoZSBtb2RlbCBkZXNjcmliZXMgdGhlIGV4dGVybmFsIGNvbm5l Y3Rpdml0eSBvZiBlYWNoIGRldmljZSwgaXQgd2lsbCBiZSBuZXR3b3JrIGVsZW1lbnQgc2Vydmlj ZS4gRG9lcyB0aGlzIG1ldGhvZCBtYWtlIHNlbnNlPw0KDQpJIHRoaW5rIGl0IGRvZXMgbWFrZSBz ZW5zZSwgeWVzLg0KDQo+IEJlc3QsDQo+IFlhbGkNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCj4g5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdA Y2lzY28uY29tXSANCj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIy5pelIDE2OjA0DQo+IOaU tuS7tuS6ujogemhhbmd5YWxpIChEKQ0KPiDmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0KPiDkuLvp opg6IFJlOiBbbmV0bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+IA0KPiANCj4gLS0N Cj4gQ2FybCBNb2JlcmcNCj4gVGVjaG5vbG9neSBEaXJlY3RvciwgQ1ZHDQo+IGNhbW9iZXJnQGNp c2NvLmNvbQ0KPiANCj4+IE9uIEFwciAyMiwgMjAxNiwgYXQgNDo0MyBBTSwgemhhbmd5YWxpIChE KSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBDYXJsLA0KPj4g DQo+PiBJbmRlZWQsIHRoZXJlIGlzIHVuY2xlYXIgZnVuY3Rpb25hbCBwYXJ0aXRpb25pbmcgYmV0 d2VlbiBvcmNoZXN0cmF0b3IgYW5kIGNvbnRyb2xsZXIuIFNvIGxldCdzIGdvIGJhY2sgdG8gdGhl IGRpdmlzaW9uIG9mIG5ldHdvcmsgZWxlbWVudCB5YW5nIG1vZGVsIGFuZCBzZXJ2aWNlIHlhbmcg bW9kZWwuDQo+PiANCj4+IEluIG15IHZpZXcsIGVsZW1lbnQgeWFuZyBtb2RlbCBzaG91bGQgYmUg dGhlIGRldGFpbGVkIGNvbmZpZ3VyYXRpb24gZm9yIG9uZSBkZXZpY2UsIHN1Y2ggYXMsIG10dSwg aG9wLWxpbWl0LGV0Yy4gQnV0IHNlcnZpY2UgbW9kZWwgc2hvdWxkIGJlIGEgbGFyZ2VzY2FsZSBk ZXNjcmlwdGlvbiwgc3VjaCBhcywgdGhlIGVuZHBvaW50cyBpbiB0aGUgVlBOLiBCdXQgc29tZXRp bWVzLCBtYW55IGNvbmZpZ3VyYXRpb25zIHlhbmcgbW9kZWwgaW5jbHVkZSBtYW55IGRldmljZXMn IGNvbmZpZ3VyYXRpb24gb3IgZG8gbm90IGRpc3Rpbmd1aXNoIHdoaWNoIGRldmljZXMgYXJlIGNv bmZpZ3VyZWQuIFNvIGNvdWxkIHlvdSBnaXZlIG1lIHNvbWUgbW9yZSBzcGVjaWZpYyBtZXRob2Qg dG8gY2xhc3NpZnkgdGhlbT8gTWF5YmUgdGhlIGRyYWZ0IFtkcmFmdC10cmFuLWlwc2VjbWUteWFu Zy0wMV0gaXMgYSBnb29kIGV4YW1wbGUuDQo+IA0KPiBUaGUgbWV0aG9kIHRvIGNsYXNzaWZ5IG1v ZGVscyBhbG9uZyB0aGUgc3VnZ2VzdGVkIGFic3RyYWN0aW9uIGxheWVycyBhcmUgZGVmaW5lZCBp biBzZWN0aW9ucyAyLjEgYW5kIDIuMi4gVGhlIGludGVudCBoZXJlIGlzIG9mIGNvdXJzZSB0byBi ZSBjbGVhciBlbm91Z2ggaW4gdGhvc2UgZGVzY3JpcHRpb25zIGZvciBwZW9wbGUgdG8gYmUgYWJs ZSB0byB1c2UgdGhlbSAoaS5lLiBjbGFzc2lmeSBtb2RlbHMpLiBJZiB5b3UgdGhpbmsgdGhlIGNv bnRlbnQgb2YgdGhvc2Ugc2VjdGlvbnMgYXJlIG5vdCBjbGVhciBlbm91Z2ggb3IgcGxhaW4gd3Jv bmcsIEnigJlkIGJlIG1vcmUgdGhhbiBoYXBweSB0byB0YWtlIHRoYXQgZmVlZGJhY2suDQo+IA0K PiBJIGFtIG5vdCBhbiBleHBlcnQgaW4gSVBTZWMsIGJ1dCBnbGFuY2luZyB0aHJvdWdoIGRyYWZ0 LXRyYW4taXBzZWNtZS15YW5nLTAxIEkgc2VlIG1hbnkgcmVmZXJlbmNlcyB0byDigJx0aGUgc3lz dGVt4oCdLCBhcyBpbjoNCj4gDQo+IOKAnOKAneKAnQ0KPiBUaGUgSVBTRUMgR2xvYmFsIFN0YXRp c3RpY3MgY29udGFpbmVyIGlzIHVzZWQgdG8gbWFpbnRhaW4gaW5mb3JtYXRpb24gcmVsYXRlZCB0 byBhbGwgdGhlIElQU0VDIHR1bm5lbHMgZXN0YWJsaXNoZWQgaW4gdGhlIHN5c3RlbS4NCj4g4oCc 4oCdIg0KPiANCj4gDQo+IEZyb20gc2VjdGlvbiAyLjIuIGluIHRoZSBjbGFzc2lmaWNhdGlvbiBt b2RlbDoNCj4gDQo+IOKAnOKAneKAnQ0KPiBOZXR3b3JrIEVsZW1lbnQgWUFORyBEYXRhIE1vZGVs cyBkZXNjcmliZSB0aGUgY29uZmlndXJhdGlvbiwgc3RhdGUgZGF0YSBhbmQgb3BlcmF0aW9ucyBv ZiBhIG5ldHdvcmsgZGV2aWNlIGFzIGRlZmluZWQgYnkgdGhlIHZlbmRvciBvZiB0aGF0IGRldmlj ZS4gIFRoZSBtb2RlbHMgYXJlIGNvbW1vbmx5IHN0cnVjdHVyZWQgYXJvdW5kIGZlYXR1cmVzIG9m IHRoZSBkZXZpY2UsIGUuZy4gaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gW1JGQzcyMjNdLCBPU1BG IGNvbmZpZ3VyYXRpb24gW0ktRC5pZXRmLW9zcGYteWFuZ10sIGFuZCBmaXJld2FsbCBydWxlcyBk ZWZpbml0aW9ucyBbSS1ELmlldGYtbmV0bW9kLWFjbC1tb2RlbF0uDQo+IOKAnOKAneKAnQ0KPiAN Cj4gSSB3b3VsZCB0aGVuIHN1Z2dlc3QgdGhhdCB0aGUgbW9kdWxlcyBpbiBkcmFmdC10cmFuLWlw c2VjbWUteWFuZyByZXByZXNlbnQgTmV0d29yayBFbGVtZW50IFlBTkcgRGF0YSBNb2RlbHMuDQo+ IA0KPj4gQmVzdCwNCj4+IFlhbGkNCj4+IA0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4g 5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdAY2lzY28u Y29tXQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIx5pelIDE2OjQxDQo+PiDmlLbku7bk uro6IHpoYW5neWFsaSAoRCkNCj4+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+PiDkuLvpopg6 IFJlOiBbbmV0bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+PiANCj4+PiBPbiBBcHIg MjEsIDIwMTYsIGF0IDEwOjMwIEFNLCB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgQ2FybCwNCj4+PiANCj4+PiBUaGFua3MgZm9yIHlv dXIgYW5zd2VycyB2ZXJ5IG11Y2guIEZyb20geW91ciBleHBsYW5hdGlvbiwgdGhlIG1haW4gdmll dyBpcyB0aGF0IGRvIG5vdCBkaXN0aW5ndWlzaCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIG5ldHdv cmsgbGV2ZWwgYW5kIHNlcnZpY2UgbGV2ZWwgbW9kZWwsIHdoaWNoIGFsbCBjYWxsZWQgIm5ldHdv cmsgc2VydmljZSBtb2RlbCIsIHJpZ2h0Pw0KPj4+IElmIHNvLCB0aGUgcXVlc3Rpb24gaXMgdGhh dCBob3cgdGhlc2UgInNhbWUgbGF5ZXIiIG1vZGVsIGNvdWxkIGJlIHVzZWQgaW4gdGhlIGxheWVy ZWQgYXJjaGl0ZWN0dXJlLCBzdWNoIGFzLCB0aGVyZSBhcmUgb3JjaGVzdHJhdG9yIGxheWVyLCBj b250cm9sbGVyIGxheWVyIGFuZCBkZXZpY2UgbGF5ZXI/IEluIG15IHVuZGVyc3RhbmRpbmcsIHRo ZSBOQkkgb2Ygb3JjaGVzdHJhdG9yIHNob3VsZCBub3QgaW5jbHVkZSBhbnkgdGVjaG5vbG9neSBk ZXRhaWxzIHdoaWNoIHNob3VsZCBleGlzdCBpbiB0aGUgTkJJIG9mIGNvbnRyb2xsZXIuIFRoZSBv cmNoZXN0cmF0b3Igd2lsbCBjb21wbGV0ZSB0aGUgbWFwcGluZyBmcm9tIE5CSSBvZiBvcmNoZXN0 cmF0b3IgdG8gTkJJIG9mIGNvbnRyb2xsZXIuDQo+PiANCj4+IFRoZSB2aWV3IG9mIHRoaXMgdmFy aWVzIHdpbGRseSBhY3Jvc3Mgc3RhbmRhcmRzIGJvZGllcywgb3BlbiBzb3VyY2UgcHJvamVjdHMs IHZlbmRvcnMgYW5kIG1hbnkgb3RoZXIgZW50aXRpZXMgaW52b2x2ZWQuIEkuZS4gbW9zdCBvcmNo ZXN0cmF0b3JzIGRvIGxlYWsgdGVjaG5vbG9neSBkZXRhaWxzIGFuZCBOQklzIG9mIGNvbnRyb2xs ZXJzIGNvbnRhaW4gYWJzdHJhY3Rpb25zIGFib3ZlIHRoZSBuZXR3b3JrIGxldmVsLg0KPj4gDQo+ Pj4gTGV0J3MgdGFrZSBMMlZQTiBhcyBhIGV4YW1wbGUuIEluIHRoZSBOQkkgb2Ygb3JjaGVzdHJh dG9yLCB0aGUgeWFuZyBtb2RlbCBqdXN0IG5lZWQgZXhwcmVzcyBuZWNlc3NhcnkgaW5mb3JtYXRp b24gb2YgTDJWUE4sIHN1Y2ggYXMsIHNpdGVzIGluZm9ybWF0aW9uIGFuZCB0b3BvbG9neSBiZXR3 ZWVuIHNpdGVzLiBGb3IgdGhlIE5CSSBvZiBjb250cm9sbGVyLCB0aGUgeWFuZyBtb2RlbCBtYXkg YmUgc29tZSB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywgVlBMUywgVlBXUywgZXRjLiBU aGUgb3JjaGVzdHJhdG9yIHdpbGwgY2hvb3NlIG9uZSBvciBzb21lIHNvbHV0aW9ucyBkZXBlbmRz IG9uIHVzZXJzJyByZXF1aXJlbWVudC4gVGhlbiB0aGUgY29udHJvbGxlciB3aWxsIGNvbXBsZXRl IHRoZSBuZXR3b3JrIGVsZW1lbnQgY29uZmlndXJhdGlvbiAodXNpbmcgbmV0d29yayBlbGVtZW50 IHlhbmcgbW9kZWwgKSBhY2NvcmRpbmcgdG8gdGVjaG5vbG9neSBzb2x1dGlvbnMgY2hvc2VuIGJ5 IG9yY2hlc3RyYXRvci4NCj4+IA0KPj4gVGhhdCBpcyBhYnNvbHV0ZWx5IG9uZSB3YXkgb2YgbG9v a2luZyAoYW5kIHBlcmhhcHMgZXZlbiBpbXBsZW1lbnRpbmcpIGl0LCBhbW9uZyBzZXZlcmFsIG90 aGVycy4gSW4gdGhpcyBjYXNlLCBhbmQgdW5kZXIgdGhlIHN1Z2dlc3RlZCBjbGFzc2lmaWNhdGlv biBpbiB0aGUgZG9jdW1lbnQsIGJvdGggdGhlIGNvbnRyb2xsZXIgYW5kIG9yY2hlc3RyYXRvciBt b2RlbHMgd291bGQgYmUgZXhhbXBsZXMgb2YgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2Rl bHMgd2l0aCBkaWZmZXJlbnQgYWJzdHJhY3Rpb24gbGV2ZWxzLg0KPj4gDQo+Pj4gVGhvdWdoIEkg YW0gbm90IHN1cmUgaWYgdGhlIHByb2Nlc3MgaXMgc3VpdGFibGUsIHRoZSBzZXJ2aWNlIG1vZGVs IGFuZCBuZXR3b3JrIG1vZGVsIGFyZSBkaWZmZXJlbmNlIHdoaWNoIGFyZSB1c2VkIGluIGRpZmZl cmVudCBwbGFjZXMuIEFueSBjb21tZW50cz8NCj4+IA0KPj4gQWJvdmUuDQo+PiANCj4+PiANCj4+ PiBCZXN0LA0KPj4+IFlhbGkNCj4+PiANCj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+Pj4g 5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdAY2lzY28u Y29tXQ0KPj4+IOWPkemAgeaXtumXtDogMjAxNuW5tDTmnIgyMeaXpSAxNTo0Nw0KPj4+IOaUtuS7 tuS6ujogemhhbmd5YWxpIChEKQ0KPj4+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+Pj4g5Li7 6aKYOiBSZTogW25ldG1vZF0geWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlvbg0KPj4+IA0KPj4+IFlh bGksDQo+Pj4gDQo+Pj4+IE9uIEFwciAyMSwgMjAxNiwgYXQgNjowMyBBTSwgemhhbmd5YWxpIChE KSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gSGkgYWxsLA0K Pj4+PiANCj4+Pj4gSSBub3RpY2VkIHRoYXQgdGhlcmUgaXMgYSBkcmFmdCBpbnRlbnRzIHRvIGNs YXNzaWZ5IHRoZSB2YXJpb3VzIHlhbmcgbW9kZWwsIGl0IGlzIHJlYWxseSBhIG1lYW5pbmdmdWwg d29yay4gTWFueSBwb2ludHMgYXJlIGNvbnNpc3RlbnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nLCB3 aGVyZWFzLCB0aGVyZSBhcmUgc29tZSBxdWVzdGlvbnMgdW5jbGVhciBuZWVkIHRvIGlucXVpcmUu DQo+Pj4+IA0KPj4+PiAxLiAgICAgICBXaHkgVlBMUyBhbmQgVlBXUyBhcmUgYWxsIHNlcnZpY2Ug bW9kZWwsIHdoaWNoIGlzIGF0IHRoZSBzYW1lIGxldmVsIHdpdGggTDNWUE4/IEluIG15IHVuZGVy c3RhbmRpbmcsIEwzVlBOIGlzIGEgdHlwaWNhbCBzZXJ2aWNlIG1vZGVsIHdoaWNoIGhpZGVzIHRo ZSB1bmRlcmxheSBuZXR3b3JrLCBidXQgYm90aCBWUExTIGFuZCBWUFdTIGlzIHNwZWNpZmljIHRl Y2hub2xvZ3kgc29sdXRpb25zLiBNYXliZSBhIHVuaWZvcm0gTDJWUE4gd2hpY2ggYWJzdHJhY3Rz IHNlcnZpY2UgaW5mb3JtYXRpb24gZnJvbSBhbGwgbGF5ZXIyIHRlY2hub2xvZ2llcyBtb3JlIGxp a2Ugc2VydmljZSBtb2RlbC4NCj4+PiANCj4+PiBTZWN0aW9uIDIuMSBnb2VzIHRvIHNvbWUgbGVu Z3RoIHRvIGRlc2NyaWJlIHRoYXQgdGhlcmUgYXJlIHZhcmlvdXMgdHlwZXMgb2YgTmV0d29yayBT ZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMgYXQgdmFyaW91cyBsZXZlbHMgb2YgYWJzdHJhY3Rpb25z LiBUaGlzIG1lYW5zIHRoYXQgYm90aCBnZW5lcmljIG1vZGVscyAoZS5nLiBhIHRlY2hub2xvZ3kg YWdub3N0aWMgTDMgVlBOIG1vZGVsKSBhbmQgbW9yZSBpbXBsZW1lbnRhdGlvbi1vcmllbnRlZCBt b2RlbHMgKGUuZy4gVlBMUykgd291bGQgYmUgY2xhc3NpZmllZCBhcyBOZXR3b3JrIFNlcnZpY2Ug WUFORyBEYXRhIE1vZGVscyB3aXRob3V0IGJlaW5nIGF0IHRoZSBleGFjdCBzYW1lIGxldmVsIG9m IGFic3RyYWN0aW9uLg0KPj4+IA0KPj4+PiAyLiAgICAgICBXaGF0IGlzIHRoZSBsYXllciBvZiB0 ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywgVnhMQU4sIEdSRSwgVlBMUywgZXRjPw0KPj4+ IA0KPj4+IElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBWeExBTiwgR1JFLCBWUExTIGNvbmZpZ3Vy YXRpb24gYW5kIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgcmVzaWRpbmcgb24gYSBkZXZpY2UsIHRo ZW4gaXTigJlzIE5ldHdvcmsgRWxlbWVudCBZQU5HIERhdGEgbW9kZWxzLiBJZiB5b3XigJlyZSB0 YWxraW5nIGFib3V0IFZ4TEFOLCBHUkUsIFZQTFMgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9u YWwgcGFyYW1ldGVycyBhcyBwYXJ0IG9mIGFuICJhYnN0cmFjdCBtb2RlbCB0aGF0IGFsbG93cyBp bnN0YW5jZXMgbyB0aGUgc2VydmljZSB0byBiZSBkZWNvbXBvc2VkIGludG8gaW5zdGFuY2UgZGF0 YSBhY2NvcmRpbmcgdG8gdGhlIE5ldHdvcmsgRWxlbWVudCBkYXRhIG1vZGVscyBvZiB0aGUgcGFy dGljaXBhdGluZyBuZXR3b3JrIGVsZW1lbnRz4oCdLCB0aGVuIGl0IHdvdWxkIGJlIGNsYXNzaWZp ZWQgYXMgYSBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscy4gDQo+Pj4gDQo+Pj4+IDMu ICAgICAgIEluIFRNTiBNLjMwMTAsIG5ldHdvcmsgbW9kZWwgYWxzbyBhIHBhcnRpY3VsYXIgbGF5 ZXIsIHNob3VsZCBzcGVjaWZpYyB5YW5nIG1vZGVsIGNvdmVyIHRoaXMgbGF5ZXI/DQo+Pj4gDQo+ Pj4gSSBoYXZlIGRvbmUgc29tZSByZWFkaW5nIG9uIE0uMzAxMCBhbmQgYmVsaWV2ZSB3ZSBhcmUg d2VsbCBhbGlnbmVkIGluIHRoZSBkcmFmdC4gVGhlIG5ldHdvcmsgbW9kZWwgd291bGQgYmUgY2xh c3NpZmllZCBhZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVsLg0KPj4+IA0KPj4+ PiBCZXN0IFJlZ2FyZHMsDQo+Pj4+IFlhbGkNCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQo+Pj4gDQo+PiANCj4gDQoNCg== From nobody Sun Apr 24 18:11:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B24C12D09D for ; Sun, 24 Apr 2016 18:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsJJ_IXl7rJA for ; Sun, 24 Apr 2016 18:11:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB9312B027 for ; Sun, 24 Apr 2016 18:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10814; q=dns/txt; s=iport; t=1461546664; x=1462756264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S82irBwgrNIVCONEeLJPigResgpXc51GHRN7bbFGG6A=; b=FiI12j7cGWkW+bTkepxGEaBxxkYYMCdsDCRbmSW1ssP/SLojnfDkxOQM JGpnPuBbw9/jYy6m7Hg2ypMMv39LJsVTTlle3gd4OrVPXpeLyicnw+puA EBsT/iHKzBLbv2pjTT69jRBSLF2i4RZGlD+hnQEadl6Z+TFdT5062Crd+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgA7bh1X/4gNJK1egzhTfQa5bQENg?= =?us-ascii?q?XUXC4UiSgIcejgUAQEBAQEBAWUnhEEBAQEDAQEBASARNwMLBQsCAQYCEgYCAiM?= =?us-ascii?q?DAgICJQsUAQIOAgQOBRuIBwgOkiedF5BLAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR8hSWBdQiCToQaI4MCK4IrBZgPAY4UjxCPLgEeAQFCggoWgUtshyk+fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,530,1454976000"; d="scan'208";a="97252212" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2016 01:11:02 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3P1B260004804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Apr 2016 01:11:02 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 24 Apr 2016 20:11:01 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Sun, 24 Apr 2016 20:11:01 -0500 From: "Carl Moberg (camoberg)" To: "zhangyali (D)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A//8tEkCAAlrGAP//J36ggAUcLQA= Date: Mon, 25 Apr 2016 01:11:01 +0000 Message-ID: <5A0E2959-26A2-47C2-9888-AFA63C8E1730@cisco.com> References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.139] Content-Type: text/plain; charset="utf-8" Content-ID: <52B7DB42FBE9224A85539CEB34192D6E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 01:11:17 -0000 WWFsaSwNCg0KPiBPbiBBcHIgMjMsIDIwMTYsIGF0IDQ6MTIgQU0sIHpoYW5neWFsaSAoRCkgPHpo YW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIENhcmwsDQo+IA0KPiBUaGFu a3MgZm9yIHlvdXIgc3VnZ2VzdGlvbi4oSSBhbHNvIHRoaW5rIHRoZSBJUFNlYyB5YW5nIG1vZGVs IGlzIG5ldHdvcmsgZWxlbWVudCBtb2RlbCkuDQo+IEkgdGhpbmsgdGhlIG1haW4gY3JpdGVyaWEg dG8gZGlzdGluZ3Vpc2ggdGhlIHNlcnZpY2UgbW9kZWwgYW5kIG5ldHdvcmsgZWxlbWVudCBtb2Rl bCBpcyB0aGUgcGVyc3BlY3RpdmUgd2hlbiBkZWZpbmUgdGhlIG1vZGVsLCBuYW1lbHksIHRoZSBt b2RlbCB3aWxsIGJlIG5ldHdvcmsgc2VydmljZSBtb2RlbCB3aGVuIGl0IGRlc2NyaWJlIHRoZSB3 aG9sZSBuZXR3b3JrIHNlcnZpY2Ugc3RhbmRpbmcgb24gdGhlIHdob2xlIHNpdHVhdGlvbiwgb3Ig ZWxzZSwgaXQgd2lsbCBiZSBhIG5ldHdvcmsgZWxlbWVudCBtb2RlbC4gQSBzaW1wbGUgZXhhbXBs ZSwgd2hlbiBJIGRlc2NyaWJlIGEgVlBOIHNlcnZpY2UsIGlmIHRoZSBtb2RlbCBkZXNjcmliZXMg d2hpY2ggdHdvIGVuZHBvaW50cyBuZWVkIGJlIGNvbm5lY3RlZCB0b2dldGhlciwgaXQgaXMgc2Vy dmljZSBtb2RlbC4gQW5kIGlmIHRoZSBtb2RlbCBkZXNjcmliZXMgdGhlIGV4dGVybmFsIGNvbm5l Y3Rpdml0eSBvZiBlYWNoIGRldmljZSwgaXQgd2lsbCBiZSBuZXR3b3JrIGVsZW1lbnQgc2Vydmlj ZS4gRG9lcyB0aGlzIG1ldGhvZCBtYWtlIHNlbnNlPw0KDQpJIHRoaW5rIGl0IGRvZXMgbWFrZSBz ZW5zZSwgeWVzLg0KDQo+IEJlc3QsDQo+IFlhbGkNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCj4g5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdA Y2lzY28uY29tXSANCj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIy5pelIDE2OjA0DQo+IOaU tuS7tuS6ujogemhhbmd5YWxpIChEKQ0KPiDmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0KPiDkuLvp opg6IFJlOiBbbmV0bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+IA0KPiANCj4gLS0N Cj4gQ2FybCBNb2JlcmcNCj4gVGVjaG5vbG9neSBEaXJlY3RvciwgQ1ZHDQo+IGNhbW9iZXJnQGNp c2NvLmNvbQ0KPiANCj4+IE9uIEFwciAyMiwgMjAxNiwgYXQgNDo0MyBBTSwgemhhbmd5YWxpIChE KSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBDYXJsLA0KPj4g DQo+PiBJbmRlZWQsIHRoZXJlIGlzIHVuY2xlYXIgZnVuY3Rpb25hbCBwYXJ0aXRpb25pbmcgYmV0 d2VlbiBvcmNoZXN0cmF0b3IgYW5kIGNvbnRyb2xsZXIuIFNvIGxldCdzIGdvIGJhY2sgdG8gdGhl IGRpdmlzaW9uIG9mIG5ldHdvcmsgZWxlbWVudCB5YW5nIG1vZGVsIGFuZCBzZXJ2aWNlIHlhbmcg bW9kZWwuDQo+PiANCj4+IEluIG15IHZpZXcsIGVsZW1lbnQgeWFuZyBtb2RlbCBzaG91bGQgYmUg dGhlIGRldGFpbGVkIGNvbmZpZ3VyYXRpb24gZm9yIG9uZSBkZXZpY2UsIHN1Y2ggYXMsIG10dSwg aG9wLWxpbWl0LGV0Yy4gQnV0IHNlcnZpY2UgbW9kZWwgc2hvdWxkIGJlIGEgbGFyZ2VzY2FsZSBk ZXNjcmlwdGlvbiwgc3VjaCBhcywgdGhlIGVuZHBvaW50cyBpbiB0aGUgVlBOLiBCdXQgc29tZXRp bWVzLCBtYW55IGNvbmZpZ3VyYXRpb25zIHlhbmcgbW9kZWwgaW5jbHVkZSBtYW55IGRldmljZXMn IGNvbmZpZ3VyYXRpb24gb3IgZG8gbm90IGRpc3Rpbmd1aXNoIHdoaWNoIGRldmljZXMgYXJlIGNv bmZpZ3VyZWQuIFNvIGNvdWxkIHlvdSBnaXZlIG1lIHNvbWUgbW9yZSBzcGVjaWZpYyBtZXRob2Qg dG8gY2xhc3NpZnkgdGhlbT8gTWF5YmUgdGhlIGRyYWZ0IFtkcmFmdC10cmFuLWlwc2VjbWUteWFu Zy0wMV0gaXMgYSBnb29kIGV4YW1wbGUuDQo+IA0KPiBUaGUgbWV0aG9kIHRvIGNsYXNzaWZ5IG1v ZGVscyBhbG9uZyB0aGUgc3VnZ2VzdGVkIGFic3RyYWN0aW9uIGxheWVycyBhcmUgZGVmaW5lZCBp biBzZWN0aW9ucyAyLjEgYW5kIDIuMi4gVGhlIGludGVudCBoZXJlIGlzIG9mIGNvdXJzZSB0byBi ZSBjbGVhciBlbm91Z2ggaW4gdGhvc2UgZGVzY3JpcHRpb25zIGZvciBwZW9wbGUgdG8gYmUgYWJs ZSB0byB1c2UgdGhlbSAoaS5lLiBjbGFzc2lmeSBtb2RlbHMpLiBJZiB5b3UgdGhpbmsgdGhlIGNv bnRlbnQgb2YgdGhvc2Ugc2VjdGlvbnMgYXJlIG5vdCBjbGVhciBlbm91Z2ggb3IgcGxhaW4gd3Jv bmcsIEnigJlkIGJlIG1vcmUgdGhhbiBoYXBweSB0byB0YWtlIHRoYXQgZmVlZGJhY2suDQo+IA0K PiBJIGFtIG5vdCBhbiBleHBlcnQgaW4gSVBTZWMsIGJ1dCBnbGFuY2luZyB0aHJvdWdoIGRyYWZ0 LXRyYW4taXBzZWNtZS15YW5nLTAxIEkgc2VlIG1hbnkgcmVmZXJlbmNlcyB0byDigJx0aGUgc3lz dGVt4oCdLCBhcyBpbjoNCj4gDQo+IOKAnOKAneKAnQ0KPiBUaGUgSVBTRUMgR2xvYmFsIFN0YXRp c3RpY3MgY29udGFpbmVyIGlzIHVzZWQgdG8gbWFpbnRhaW4gaW5mb3JtYXRpb24gcmVsYXRlZCB0 byBhbGwgdGhlIElQU0VDIHR1bm5lbHMgZXN0YWJsaXNoZWQgaW4gdGhlIHN5c3RlbS4NCj4g4oCc 4oCdIg0KPiANCj4gDQo+IEZyb20gc2VjdGlvbiAyLjIuIGluIHRoZSBjbGFzc2lmaWNhdGlvbiBt b2RlbDoNCj4gDQo+IOKAnOKAneKAnQ0KPiBOZXR3b3JrIEVsZW1lbnQgWUFORyBEYXRhIE1vZGVs cyBkZXNjcmliZSB0aGUgY29uZmlndXJhdGlvbiwgc3RhdGUgZGF0YSBhbmQgb3BlcmF0aW9ucyBv ZiBhIG5ldHdvcmsgZGV2aWNlIGFzIGRlZmluZWQgYnkgdGhlIHZlbmRvciBvZiB0aGF0IGRldmlj ZS4gIFRoZSBtb2RlbHMgYXJlIGNvbW1vbmx5IHN0cnVjdHVyZWQgYXJvdW5kIGZlYXR1cmVzIG9m IHRoZSBkZXZpY2UsIGUuZy4gaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gW1JGQzcyMjNdLCBPU1BG IGNvbmZpZ3VyYXRpb24gW0ktRC5pZXRmLW9zcGYteWFuZ10sIGFuZCBmaXJld2FsbCBydWxlcyBk ZWZpbml0aW9ucyBbSS1ELmlldGYtbmV0bW9kLWFjbC1tb2RlbF0uDQo+IOKAnOKAneKAnQ0KPiAN Cj4gSSB3b3VsZCB0aGVuIHN1Z2dlc3QgdGhhdCB0aGUgbW9kdWxlcyBpbiBkcmFmdC10cmFuLWlw c2VjbWUteWFuZyByZXByZXNlbnQgTmV0d29yayBFbGVtZW50IFlBTkcgRGF0YSBNb2RlbHMuDQo+ IA0KPj4gQmVzdCwNCj4+IFlhbGkNCj4+IA0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4g 5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdAY2lzY28u Y29tXQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDIx5pelIDE2OjQxDQo+PiDmlLbku7bk uro6IHpoYW5neWFsaSAoRCkNCj4+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+PiDkuLvpopg6 IFJlOiBbbmV0bW9kXSB5YW5nIG1vZGVsIGNsYXNzaWZpY2F0aW9uDQo+PiANCj4+PiBPbiBBcHIg MjEsIDIwMTYsIGF0IDEwOjMwIEFNLCB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgQ2FybCwNCj4+PiANCj4+PiBUaGFua3MgZm9yIHlv dXIgYW5zd2VycyB2ZXJ5IG11Y2guIEZyb20geW91ciBleHBsYW5hdGlvbiwgdGhlIG1haW4gdmll dyBpcyB0aGF0IGRvIG5vdCBkaXN0aW5ndWlzaCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIG5ldHdv cmsgbGV2ZWwgYW5kIHNlcnZpY2UgbGV2ZWwgbW9kZWwsIHdoaWNoIGFsbCBjYWxsZWQgIm5ldHdv cmsgc2VydmljZSBtb2RlbCIsIHJpZ2h0Pw0KPj4+IElmIHNvLCB0aGUgcXVlc3Rpb24gaXMgdGhh dCBob3cgdGhlc2UgInNhbWUgbGF5ZXIiIG1vZGVsIGNvdWxkIGJlIHVzZWQgaW4gdGhlIGxheWVy ZWQgYXJjaGl0ZWN0dXJlLCBzdWNoIGFzLCB0aGVyZSBhcmUgb3JjaGVzdHJhdG9yIGxheWVyLCBj b250cm9sbGVyIGxheWVyIGFuZCBkZXZpY2UgbGF5ZXI/IEluIG15IHVuZGVyc3RhbmRpbmcsIHRo ZSBOQkkgb2Ygb3JjaGVzdHJhdG9yIHNob3VsZCBub3QgaW5jbHVkZSBhbnkgdGVjaG5vbG9neSBk ZXRhaWxzIHdoaWNoIHNob3VsZCBleGlzdCBpbiB0aGUgTkJJIG9mIGNvbnRyb2xsZXIuIFRoZSBv cmNoZXN0cmF0b3Igd2lsbCBjb21wbGV0ZSB0aGUgbWFwcGluZyBmcm9tIE5CSSBvZiBvcmNoZXN0 cmF0b3IgdG8gTkJJIG9mIGNvbnRyb2xsZXIuDQo+PiANCj4+IFRoZSB2aWV3IG9mIHRoaXMgdmFy aWVzIHdpbGRseSBhY3Jvc3Mgc3RhbmRhcmRzIGJvZGllcywgb3BlbiBzb3VyY2UgcHJvamVjdHMs IHZlbmRvcnMgYW5kIG1hbnkgb3RoZXIgZW50aXRpZXMgaW52b2x2ZWQuIEkuZS4gbW9zdCBvcmNo ZXN0cmF0b3JzIGRvIGxlYWsgdGVjaG5vbG9neSBkZXRhaWxzIGFuZCBOQklzIG9mIGNvbnRyb2xs ZXJzIGNvbnRhaW4gYWJzdHJhY3Rpb25zIGFib3ZlIHRoZSBuZXR3b3JrIGxldmVsLg0KPj4gDQo+ Pj4gTGV0J3MgdGFrZSBMMlZQTiBhcyBhIGV4YW1wbGUuIEluIHRoZSBOQkkgb2Ygb3JjaGVzdHJh dG9yLCB0aGUgeWFuZyBtb2RlbCBqdXN0IG5lZWQgZXhwcmVzcyBuZWNlc3NhcnkgaW5mb3JtYXRp b24gb2YgTDJWUE4sIHN1Y2ggYXMsIHNpdGVzIGluZm9ybWF0aW9uIGFuZCB0b3BvbG9neSBiZXR3 ZWVuIHNpdGVzLiBGb3IgdGhlIE5CSSBvZiBjb250cm9sbGVyLCB0aGUgeWFuZyBtb2RlbCBtYXkg YmUgc29tZSB0ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywgVlBMUywgVlBXUywgZXRjLiBU aGUgb3JjaGVzdHJhdG9yIHdpbGwgY2hvb3NlIG9uZSBvciBzb21lIHNvbHV0aW9ucyBkZXBlbmRz IG9uIHVzZXJzJyByZXF1aXJlbWVudC4gVGhlbiB0aGUgY29udHJvbGxlciB3aWxsIGNvbXBsZXRl IHRoZSBuZXR3b3JrIGVsZW1lbnQgY29uZmlndXJhdGlvbiAodXNpbmcgbmV0d29yayBlbGVtZW50 IHlhbmcgbW9kZWwgKSBhY2NvcmRpbmcgdG8gdGVjaG5vbG9neSBzb2x1dGlvbnMgY2hvc2VuIGJ5 IG9yY2hlc3RyYXRvci4NCj4+IA0KPj4gVGhhdCBpcyBhYnNvbHV0ZWx5IG9uZSB3YXkgb2YgbG9v a2luZyAoYW5kIHBlcmhhcHMgZXZlbiBpbXBsZW1lbnRpbmcpIGl0LCBhbW9uZyBzZXZlcmFsIG90 aGVycy4gSW4gdGhpcyBjYXNlLCBhbmQgdW5kZXIgdGhlIHN1Z2dlc3RlZCBjbGFzc2lmaWNhdGlv biBpbiB0aGUgZG9jdW1lbnQsIGJvdGggdGhlIGNvbnRyb2xsZXIgYW5kIG9yY2hlc3RyYXRvciBt b2RlbHMgd291bGQgYmUgZXhhbXBsZXMgb2YgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2Rl bHMgd2l0aCBkaWZmZXJlbnQgYWJzdHJhY3Rpb24gbGV2ZWxzLg0KPj4gDQo+Pj4gVGhvdWdoIEkg YW0gbm90IHN1cmUgaWYgdGhlIHByb2Nlc3MgaXMgc3VpdGFibGUsIHRoZSBzZXJ2aWNlIG1vZGVs IGFuZCBuZXR3b3JrIG1vZGVsIGFyZSBkaWZmZXJlbmNlIHdoaWNoIGFyZSB1c2VkIGluIGRpZmZl cmVudCBwbGFjZXMuIEFueSBjb21tZW50cz8NCj4+IA0KPj4gQWJvdmUuDQo+PiANCj4+PiANCj4+ PiBCZXN0LA0KPj4+IFlhbGkNCj4+PiANCj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+Pj4g 5Y+R5Lu25Lq6OiBDYXJsIE1vYmVyZyAoY2Ftb2JlcmcpIFttYWlsdG86Y2Ftb2JlcmdAY2lzY28u Y29tXQ0KPj4+IOWPkemAgeaXtumXtDogMjAxNuW5tDTmnIgyMeaXpSAxNTo0Nw0KPj4+IOaUtuS7 tuS6ujogemhhbmd5YWxpIChEKQ0KPj4+IOaKhOmAgTogbmV0bW9kQGlldGYub3JnDQo+Pj4g5Li7 6aKYOiBSZTogW25ldG1vZF0geWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlvbg0KPj4+IA0KPj4+IFlh bGksDQo+Pj4gDQo+Pj4+IE9uIEFwciAyMSwgMjAxNiwgYXQgNjowMyBBTSwgemhhbmd5YWxpIChE KSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gSGkgYWxsLA0K Pj4+PiANCj4+Pj4gSSBub3RpY2VkIHRoYXQgdGhlcmUgaXMgYSBkcmFmdCBpbnRlbnRzIHRvIGNs YXNzaWZ5IHRoZSB2YXJpb3VzIHlhbmcgbW9kZWwsIGl0IGlzIHJlYWxseSBhIG1lYW5pbmdmdWwg d29yay4gTWFueSBwb2ludHMgYXJlIGNvbnNpc3RlbnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nLCB3 aGVyZWFzLCB0aGVyZSBhcmUgc29tZSBxdWVzdGlvbnMgdW5jbGVhciBuZWVkIHRvIGlucXVpcmUu DQo+Pj4+IA0KPj4+PiAxLiAgICAgICBXaHkgVlBMUyBhbmQgVlBXUyBhcmUgYWxsIHNlcnZpY2Ug bW9kZWwsIHdoaWNoIGlzIGF0IHRoZSBzYW1lIGxldmVsIHdpdGggTDNWUE4/IEluIG15IHVuZGVy c3RhbmRpbmcsIEwzVlBOIGlzIGEgdHlwaWNhbCBzZXJ2aWNlIG1vZGVsIHdoaWNoIGhpZGVzIHRo ZSB1bmRlcmxheSBuZXR3b3JrLCBidXQgYm90aCBWUExTIGFuZCBWUFdTIGlzIHNwZWNpZmljIHRl Y2hub2xvZ3kgc29sdXRpb25zLiBNYXliZSBhIHVuaWZvcm0gTDJWUE4gd2hpY2ggYWJzdHJhY3Rz IHNlcnZpY2UgaW5mb3JtYXRpb24gZnJvbSBhbGwgbGF5ZXIyIHRlY2hub2xvZ2llcyBtb3JlIGxp a2Ugc2VydmljZSBtb2RlbC4NCj4+PiANCj4+PiBTZWN0aW9uIDIuMSBnb2VzIHRvIHNvbWUgbGVu Z3RoIHRvIGRlc2NyaWJlIHRoYXQgdGhlcmUgYXJlIHZhcmlvdXMgdHlwZXMgb2YgTmV0d29yayBT ZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMgYXQgdmFyaW91cyBsZXZlbHMgb2YgYWJzdHJhY3Rpb25z LiBUaGlzIG1lYW5zIHRoYXQgYm90aCBnZW5lcmljIG1vZGVscyAoZS5nLiBhIHRlY2hub2xvZ3kg YWdub3N0aWMgTDMgVlBOIG1vZGVsKSBhbmQgbW9yZSBpbXBsZW1lbnRhdGlvbi1vcmllbnRlZCBt b2RlbHMgKGUuZy4gVlBMUykgd291bGQgYmUgY2xhc3NpZmllZCBhcyBOZXR3b3JrIFNlcnZpY2Ug WUFORyBEYXRhIE1vZGVscyB3aXRob3V0IGJlaW5nIGF0IHRoZSBleGFjdCBzYW1lIGxldmVsIG9m IGFic3RyYWN0aW9uLg0KPj4+IA0KPj4+PiAyLiAgICAgICBXaGF0IGlzIHRoZSBsYXllciBvZiB0 ZWNobm9sb2d5IHNvbHV0aW9ucywgc3VjaCBhcywgVnhMQU4sIEdSRSwgVlBMUywgZXRjPw0KPj4+ IA0KPj4+IElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCBWeExBTiwgR1JFLCBWUExTIGNvbmZpZ3Vy YXRpb24gYW5kIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgcmVzaWRpbmcgb24gYSBkZXZpY2UsIHRo ZW4gaXTigJlzIE5ldHdvcmsgRWxlbWVudCBZQU5HIERhdGEgbW9kZWxzLiBJZiB5b3XigJlyZSB0 YWxraW5nIGFib3V0IFZ4TEFOLCBHUkUsIFZQTFMgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9u YWwgcGFyYW1ldGVycyBhcyBwYXJ0IG9mIGFuICJhYnN0cmFjdCBtb2RlbCB0aGF0IGFsbG93cyBp bnN0YW5jZXMgbyB0aGUgc2VydmljZSB0byBiZSBkZWNvbXBvc2VkIGludG8gaW5zdGFuY2UgZGF0 YSBhY2NvcmRpbmcgdG8gdGhlIE5ldHdvcmsgRWxlbWVudCBkYXRhIG1vZGVscyBvZiB0aGUgcGFy dGljaXBhdGluZyBuZXR3b3JrIGVsZW1lbnRz4oCdLCB0aGVuIGl0IHdvdWxkIGJlIGNsYXNzaWZp ZWQgYXMgYSBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVscy4gDQo+Pj4gDQo+Pj4+IDMu ICAgICAgIEluIFRNTiBNLjMwMTAsIG5ldHdvcmsgbW9kZWwgYWxzbyBhIHBhcnRpY3VsYXIgbGF5 ZXIsIHNob3VsZCBzcGVjaWZpYyB5YW5nIG1vZGVsIGNvdmVyIHRoaXMgbGF5ZXI/DQo+Pj4gDQo+ Pj4gSSBoYXZlIGRvbmUgc29tZSByZWFkaW5nIG9uIE0uMzAxMCBhbmQgYmVsaWV2ZSB3ZSBhcmUg d2VsbCBhbGlnbmVkIGluIHRoZSBkcmFmdC4gVGhlIG5ldHdvcmsgbW9kZWwgd291bGQgYmUgY2xh c3NpZmllZCBhZCBhcyBOZXR3b3JrIFNlcnZpY2UgWUFORyBEYXRhIE1vZGVsLg0KPj4+IA0KPj4+ PiBCZXN0IFJlZ2FyZHMsDQo+Pj4+IFlhbGkNCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQo+Pj4gDQo+PiANCj4gDQoNCg== From nobody Sun Apr 24 18:11:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EED12B077 for ; Sun, 24 Apr 2016 18:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltokLQYvZnZB for ; Sun, 24 Apr 2016 18:11:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6058F12D094 for ; Sun, 24 Apr 2016 18:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10814; q=dns/txt; s=iport; t=1461546676; x=1462756276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oI7yfsG/54XjKKhdzxSNbvhKkG1kfSg1bcoqTUfnXpA=; b=DTgvAzTBGEPGfEnmpw+31/2QXoBeByRUvTJ5oUUvl3edovjNt3x4gZuX KZ9eOaNaNFymfPd+SG1HRQvsNpYEQeOw2ys0UoD86ZKZ2gfaY1z1KEtEy vXk6KuhMtSMuENgMIdb6dvF3LEey0BVYg1gDqfxRpvoyUHVNHl322gGat M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgA7bh1X/5hdJa1egzhTfQa5bQENg?= =?us-ascii?q?XUXC4UiSgIcejgUAQEBAQEBAWUnhEEBAQEDAQEBASARNwMLBQsCAQYCEgYCAiM?= =?us-ascii?q?DAgICJQsUAQIOAgQOBRuIBwgOkiedF5BLAQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QR8hSWBdYJWhBojgwIrgisFmA8BjhSPEI8uAR4BAUKCChaBS2yHKT5/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,530,1454976000"; d="scan'208";a="100985143" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2016 01:10:49 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3P1AnKQ025287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Apr 2016 01:10:49 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 24 Apr 2016 20:10:48 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Sun, 24 Apr 2016 20:10:48 -0500 From: "Carl Moberg (camoberg)" To: "zhangyali (D)" Thread-Topic: [netmod] yang model classification Thread-Index: AdGbgcIYpno5OLJvT8SJoe69YiZ7/wAACX2AABJ8NoAACjqu8P//vW0A//8tEkCAAlrGAP//J36ggAUVCwA= Date: Mon, 25 Apr 2016 01:10:48 +0000 Message-ID: References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.139] 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] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 01:11:35 -0000 WWFsaSwNCg0KPiBPbiBBcHIgMjMsIDIwMTYsIGF0IDQ6MTIgQU0sIHpoYW5neWFsaSAoRCkgPHpo YW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIENhcmwsDQo+IA0KPiBUaGFu a3MgZm9yIHlvdXIgc3VnZ2VzdGlvbi4oSSBhbHNvIHRoaW5rIHRoZSBJUFNlYyB5YW5nIG1vZGVs IGlzIG5ldHdvcmsgZWxlbWVudCBtb2RlbCkuDQo+IEkgdGhpbmsgdGhlIG1haW4gY3JpdGVyaWEg dG8gZGlzdGluZ3Vpc2ggdGhlIHNlcnZpY2UgbW9kZWwgYW5kIG5ldHdvcmsgZWxlbWVudCBtb2Rl bCBpcyB0aGUgcGVyc3BlY3RpdmUgd2hlbiBkZWZpbmUgdGhlIG1vZGVsLCBuYW1lbHksIHRoZSBt b2RlbCB3aWxsIGJlIG5ldHdvcmsgc2VydmljZSBtb2RlbCB3aGVuIGl0IGRlc2NyaWJlIHRoZSB3 aG9sZSBuZXR3b3JrIHNlcnZpY2Ugc3RhbmRpbmcgb24gdGhlIHdob2xlIHNpdHVhdGlvbiwgb3Ig ZWxzZSwgaXQgd2lsbCBiZSBhIG5ldHdvcmsgZWxlbWVudCBtb2RlbC4gQSBzaW1wbGUgZXhhbXBs ZSwgd2hlbiBJIGRlc2NyaWJlIGEgVlBOIHNlcnZpY2UsIGlmIHRoZSBtb2RlbCBkZXNjcmliZXMg d2hpY2ggdHdvIGVuZHBvaW50cyBuZWVkIGJlIGNvbm5lY3RlZCB0b2dldGhlciwgaXQgaXMgc2Vy dmljZSBtb2RlbC4gQW5kIGlmIHRoZSBtb2RlbCBkZXNjcmliZXMgdGhlIGV4dGVybmFsIGNvbm5l Y3Rpdml0eSBvZiBlYWNoIGRldmljZSwgaXQgd2lsbCBiZSBuZXR3b3JrIGVsZW1lbnQgc2Vydmlj ZS4gRG9lcyB0aGlzIG1ldGhvZCBtYWtlIHNlbnNlPw0KDQogSSB0aGluayBpdCBkb2VzIG1ha2Ug c2Vuc2UsIHllcy4NCg0KPiBCZXN0LA0KPiBZYWxpDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+IOWPkeS7tuS6ujogQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSBbbWFpbHRvOmNhbW9iZXJn QGNpc2NvLmNvbV0gDQo+IOWPkemAgeaXtumXtDogMjAxNuW5tDTmnIgyMuaXpSAxNjowNA0KPiDm lLbku7bkuro6IHpoYW5neWFsaSAoRCkNCj4g5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmcNCj4g5Li7 6aKYOiBSZTogW25ldG1vZF0geWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlvbg0KPiANCj4gDQo+IC0t DQo+IENhcmwgTW9iZXJnDQo+IFRlY2hub2xvZ3kgRGlyZWN0b3IsIENWRw0KPiBjYW1vYmVyZ0Bj aXNjby5jb20NCj4gDQo+PiBPbiBBcHIgMjIsIDIwMTYsIGF0IDQ6NDMgQU0sIHpoYW5neWFsaSAo RCkgPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgQ2FybCwNCj4+ IA0KPj4gSW5kZWVkLCB0aGVyZSBpcyB1bmNsZWFyIGZ1bmN0aW9uYWwgcGFydGl0aW9uaW5nIGJl dHdlZW4gb3JjaGVzdHJhdG9yIGFuZCBjb250cm9sbGVyLiBTbyBsZXQncyBnbyBiYWNrIHRvIHRo ZSBkaXZpc2lvbiBvZiBuZXR3b3JrIGVsZW1lbnQgeWFuZyBtb2RlbCBhbmQgc2VydmljZSB5YW5n IG1vZGVsLg0KPj4gDQo+PiBJbiBteSB2aWV3LCBlbGVtZW50IHlhbmcgbW9kZWwgc2hvdWxkIGJl IHRoZSBkZXRhaWxlZCBjb25maWd1cmF0aW9uIGZvciBvbmUgZGV2aWNlLCBzdWNoIGFzLCBtdHUs IGhvcC1saW1pdCxldGMuIEJ1dCBzZXJ2aWNlIG1vZGVsIHNob3VsZCBiZSBhIGxhcmdlc2NhbGUg ZGVzY3JpcHRpb24sIHN1Y2ggYXMsIHRoZSBlbmRwb2ludHMgaW4gdGhlIFZQTi4gQnV0IHNvbWV0 aW1lcywgbWFueSBjb25maWd1cmF0aW9ucyB5YW5nIG1vZGVsIGluY2x1ZGUgbWFueSBkZXZpY2Vz JyBjb25maWd1cmF0aW9uIG9yIGRvIG5vdCBkaXN0aW5ndWlzaCB3aGljaCBkZXZpY2VzIGFyZSBj b25maWd1cmVkLiBTbyBjb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIG1vcmUgc3BlY2lmaWMgbWV0aG9k IHRvIGNsYXNzaWZ5IHRoZW0/IE1heWJlIHRoZSBkcmFmdCBbZHJhZnQtdHJhbi1pcHNlY21lLXlh bmctMDFdIGlzIGEgZ29vZCBleGFtcGxlLg0KPiANCj4gVGhlIG1ldGhvZCB0byBjbGFzc2lmeSBt b2RlbHMgYWxvbmcgdGhlIHN1Z2dlc3RlZCBhYnN0cmFjdGlvbiBsYXllcnMgYXJlIGRlZmluZWQg aW4gc2VjdGlvbnMgMi4xIGFuZCAyLjIuIFRoZSBpbnRlbnQgaGVyZSBpcyBvZiBjb3Vyc2UgdG8g YmUgY2xlYXIgZW5vdWdoIGluIHRob3NlIGRlc2NyaXB0aW9ucyBmb3IgcGVvcGxlIHRvIGJlIGFi bGUgdG8gdXNlIHRoZW0gKGkuZS4gY2xhc3NpZnkgbW9kZWxzKS4gSWYgeW91IHRoaW5rIHRoZSBj b250ZW50IG9mIHRob3NlIHNlY3Rpb25zIGFyZSBub3QgY2xlYXIgZW5vdWdoIG9yIHBsYWluIHdy b25nLCBJ4oCZZCBiZSBtb3JlIHRoYW4gaGFwcHkgdG8gdGFrZSB0aGF0IGZlZWRiYWNrLg0KPiAN Cj4gSSBhbSBub3QgYW4gZXhwZXJ0IGluIElQU2VjLCBidXQgZ2xhbmNpbmcgdGhyb3VnaCBkcmFm dC10cmFuLWlwc2VjbWUteWFuZy0wMSBJIHNlZSBtYW55IHJlZmVyZW5jZXMgdG8g4oCcdGhlIHN5 c3RlbeKAnSwgYXMgaW46DQo+IA0KPiDigJzigJ3igJ0NCj4gVGhlIElQU0VDIEdsb2JhbCBTdGF0 aXN0aWNzIGNvbnRhaW5lciBpcyB1c2VkIHRvIG1haW50YWluIGluZm9ybWF0aW9uIHJlbGF0ZWQg dG8gYWxsIHRoZSBJUFNFQyB0dW5uZWxzIGVzdGFibGlzaGVkIGluIHRoZSBzeXN0ZW0uDQo+IOKA nOKAnSINCj4gDQo+IA0KPiBGcm9tIHNlY3Rpb24gMi4yLiBpbiB0aGUgY2xhc3NpZmljYXRpb24g bW9kZWw6DQo+IA0KPiDigJzigJ3igJ0NCj4gTmV0d29yayBFbGVtZW50IFlBTkcgRGF0YSBNb2Rl bHMgZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGEgYW5kIG9wZXJhdGlvbnMg b2YgYSBuZXR3b3JrIGRldmljZSBhcyBkZWZpbmVkIGJ5IHRoZSB2ZW5kb3Igb2YgdGhhdCBkZXZp Y2UuICBUaGUgbW9kZWxzIGFyZSBjb21tb25seSBzdHJ1Y3R1cmVkIGFyb3VuZCBmZWF0dXJlcyBv ZiB0aGUgZGV2aWNlLCBlLmcuIGludGVyZmFjZSBjb25maWd1cmF0aW9uIFtSRkM3MjIzXSwgT1NQ RiBjb25maWd1cmF0aW9uIFtJLUQuaWV0Zi1vc3BmLXlhbmddLCBhbmQgZmlyZXdhbGwgcnVsZXMg ZGVmaW5pdGlvbnMgW0ktRC5pZXRmLW5ldG1vZC1hY2wtbW9kZWxdLg0KPiDigJzigJ3igJ0NCj4g DQo+IEkgd291bGQgdGhlbiBzdWdnZXN0IHRoYXQgdGhlIG1vZHVsZXMgaW4gZHJhZnQtdHJhbi1p cHNlY21lLXlhbmcgcmVwcmVzZW50IE5ldHdvcmsgRWxlbWVudCBZQU5HIERhdGEgTW9kZWxzLg0K PiANCj4+IEJlc3QsDQo+PiBZYWxpDQo+PiANCj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+ IOWPkeS7tuS6ujogQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSBbbWFpbHRvOmNhbW9iZXJnQGNpc2Nv LmNvbV0NCj4+IOWPkemAgeaXtumXtDogMjAxNuW5tDTmnIgyMeaXpSAxNjo0MQ0KPj4g5pS25Lu2 5Lq6OiB6aGFuZ3lhbGkgKEQpDQo+PiDmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0KPj4g5Li76aKY OiBSZTogW25ldG1vZF0geWFuZyBtb2RlbCBjbGFzc2lmaWNhdGlvbg0KPj4gDQo+Pj4gT24gQXBy IDIxLCAyMDE2LCBhdCAxMDozMCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxpMzY5QGh1YXdl aS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIENhcmwsDQo+Pj4gDQo+Pj4gVGhhbmtzIGZvciB5 b3VyIGFuc3dlcnMgdmVyeSBtdWNoLiBGcm9tIHlvdXIgZXhwbGFuYXRpb24sIHRoZSBtYWluIHZp ZXcgaXMgdGhhdCBkbyBub3QgZGlzdGluZ3Vpc2ggdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBuZXR3 b3JrIGxldmVsIGFuZCBzZXJ2aWNlIGxldmVsIG1vZGVsLCB3aGljaCBhbGwgY2FsbGVkICJuZXR3 b3JrIHNlcnZpY2UgbW9kZWwiLCByaWdodD8NCj4+PiBJZiBzbywgdGhlIHF1ZXN0aW9uIGlzIHRo YXQgaG93IHRoZXNlICJzYW1lIGxheWVyIiBtb2RlbCBjb3VsZCBiZSB1c2VkIGluIHRoZSBsYXll cmVkIGFyY2hpdGVjdHVyZSwgc3VjaCBhcywgdGhlcmUgYXJlIG9yY2hlc3RyYXRvciBsYXllciwg Y29udHJvbGxlciBsYXllciBhbmQgZGV2aWNlIGxheWVyPyBJbiBteSB1bmRlcnN0YW5kaW5nLCB0 aGUgTkJJIG9mIG9yY2hlc3RyYXRvciBzaG91bGQgbm90IGluY2x1ZGUgYW55IHRlY2hub2xvZ3kg ZGV0YWlscyB3aGljaCBzaG91bGQgZXhpc3QgaW4gdGhlIE5CSSBvZiBjb250cm9sbGVyLiBUaGUg b3JjaGVzdHJhdG9yIHdpbGwgY29tcGxldGUgdGhlIG1hcHBpbmcgZnJvbSBOQkkgb2Ygb3JjaGVz dHJhdG9yIHRvIE5CSSBvZiBjb250cm9sbGVyLg0KPj4gDQo+PiBUaGUgdmlldyBvZiB0aGlzIHZh cmllcyB3aWxkbHkgYWNyb3NzIHN0YW5kYXJkcyBib2RpZXMsIG9wZW4gc291cmNlIHByb2plY3Rz LCB2ZW5kb3JzIGFuZCBtYW55IG90aGVyIGVudGl0aWVzIGludm9sdmVkLiBJLmUuIG1vc3Qgb3Jj aGVzdHJhdG9ycyBkbyBsZWFrIHRlY2hub2xvZ3kgZGV0YWlscyBhbmQgTkJJcyBvZiBjb250cm9s bGVycyBjb250YWluIGFic3RyYWN0aW9ucyBhYm92ZSB0aGUgbmV0d29yayBsZXZlbC4NCj4+IA0K Pj4+IExldCdzIHRha2UgTDJWUE4gYXMgYSBleGFtcGxlLiBJbiB0aGUgTkJJIG9mIG9yY2hlc3Ry YXRvciwgdGhlIHlhbmcgbW9kZWwganVzdCBuZWVkIGV4cHJlc3MgbmVjZXNzYXJ5IGluZm9ybWF0 aW9uIG9mIEwyVlBOLCBzdWNoIGFzLCBzaXRlcyBpbmZvcm1hdGlvbiBhbmQgdG9wb2xvZ3kgYmV0 d2VlbiBzaXRlcy4gRm9yIHRoZSBOQkkgb2YgY29udHJvbGxlciwgdGhlIHlhbmcgbW9kZWwgbWF5 IGJlIHNvbWUgdGVjaG5vbG9neSBzb2x1dGlvbnMsIHN1Y2ggYXMsIFZQTFMsIFZQV1MsIGV0Yy4g VGhlIG9yY2hlc3RyYXRvciB3aWxsIGNob29zZSBvbmUgb3Igc29tZSBzb2x1dGlvbnMgZGVwZW5k cyBvbiB1c2VycycgcmVxdWlyZW1lbnQuIFRoZW4gdGhlIGNvbnRyb2xsZXIgd2lsbCBjb21wbGV0 ZSB0aGUgbmV0d29yayBlbGVtZW50IGNvbmZpZ3VyYXRpb24gKHVzaW5nIG5ldHdvcmsgZWxlbWVu dCB5YW5nIG1vZGVsICkgYWNjb3JkaW5nIHRvIHRlY2hub2xvZ3kgc29sdXRpb25zIGNob3NlbiBi eSBvcmNoZXN0cmF0b3IuDQo+PiANCj4+IFRoYXQgaXMgYWJzb2x1dGVseSBvbmUgd2F5IG9mIGxv b2tpbmcgKGFuZCBwZXJoYXBzIGV2ZW4gaW1wbGVtZW50aW5nKSBpdCwgYW1vbmcgc2V2ZXJhbCBv dGhlcnMuIEluIHRoaXMgY2FzZSwgYW5kIHVuZGVyIHRoZSBzdWdnZXN0ZWQgY2xhc3NpZmljYXRp b24gaW4gdGhlIGRvY3VtZW50LCBib3RoIHRoZSBjb250cm9sbGVyIGFuZCBvcmNoZXN0cmF0b3Ig bW9kZWxzIHdvdWxkIGJlIGV4YW1wbGVzIG9mIE5ldHdvcmsgU2VydmljZSBZQU5HIERhdGEgTW9k ZWxzIHdpdGggZGlmZmVyZW50IGFic3RyYWN0aW9uIGxldmVscy4NCj4+IA0KPj4+IFRob3VnaCBJ IGFtIG5vdCBzdXJlIGlmIHRoZSBwcm9jZXNzIGlzIHN1aXRhYmxlLCB0aGUgc2VydmljZSBtb2Rl bCBhbmQgbmV0d29yayBtb2RlbCBhcmUgZGlmZmVyZW5jZSB3aGljaCBhcmUgdXNlZCBpbiBkaWZm ZXJlbnQgcGxhY2VzLiBBbnkgY29tbWVudHM/DQo+PiANCj4+IEFib3ZlLg0KPj4gDQo+Pj4gDQo+ Pj4gQmVzdCwNCj4+PiBZYWxpDQo+Pj4gDQo+Pj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4+ IOWPkeS7tuS6ujogQ2FybCBNb2JlcmcgKGNhbW9iZXJnKSBbbWFpbHRvOmNhbW9iZXJnQGNpc2Nv LmNvbV0NCj4+PiDlj5HpgIHml7bpl7Q6IDIwMTblubQ05pyIMjHml6UgMTU6NDcNCj4+PiDmlLbk u7bkuro6IHpoYW5neWFsaSAoRCkNCj4+PiDmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0KPj4+IOS4 u+mimDogUmU6IFtuZXRtb2RdIHlhbmcgbW9kZWwgY2xhc3NpZmljYXRpb24NCj4+PiANCj4+PiBZ YWxpLA0KPj4+IA0KPj4+PiBPbiBBcHIgMjEsIDIwMTYsIGF0IDY6MDMgQU0sIHpoYW5neWFsaSAo RCkgPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhpIGFsbCwN Cj4+Pj4gDQo+Pj4+IEkgbm90aWNlZCB0aGF0IHRoZXJlIGlzIGEgZHJhZnQgaW50ZW50cyB0byBj bGFzc2lmeSB0aGUgdmFyaW91cyB5YW5nIG1vZGVsLCBpdCBpcyByZWFsbHkgYSBtZWFuaW5nZnVs IHdvcmsuIE1hbnkgcG9pbnRzIGFyZSBjb25zaXN0ZW50IHdpdGggbXkgdW5kZXJzdGFuZGluZywg d2hlcmVhcywgdGhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zIHVuY2xlYXIgbmVlZCB0byBpbnF1aXJl Lg0KPj4+PiANCj4+Pj4gMS4gICAgICAgV2h5IFZQTFMgYW5kIFZQV1MgYXJlIGFsbCBzZXJ2aWNl IG1vZGVsLCB3aGljaCBpcyBhdCB0aGUgc2FtZSBsZXZlbCB3aXRoIEwzVlBOPyBJbiBteSB1bmRl cnN0YW5kaW5nLCBMM1ZQTiBpcyBhIHR5cGljYWwgc2VydmljZSBtb2RlbCB3aGljaCBoaWRlcyB0 aGUgdW5kZXJsYXkgbmV0d29yaywgYnV0IGJvdGggVlBMUyBhbmQgVlBXUyBpcyBzcGVjaWZpYyB0 ZWNobm9sb2d5IHNvbHV0aW9ucy4gTWF5YmUgYSB1bmlmb3JtIEwyVlBOIHdoaWNoIGFic3RyYWN0 cyBzZXJ2aWNlIGluZm9ybWF0aW9uIGZyb20gYWxsIGxheWVyMiB0ZWNobm9sb2dpZXMgbW9yZSBs aWtlIHNlcnZpY2UgbW9kZWwuDQo+Pj4gDQo+Pj4gU2VjdGlvbiAyLjEgZ29lcyB0byBzb21lIGxl bmd0aCB0byBkZXNjcmliZSB0aGF0IHRoZXJlIGFyZSB2YXJpb3VzIHR5cGVzIG9mIE5ldHdvcmsg U2VydmljZSBZQU5HIERhdGEgTW9kZWxzIGF0IHZhcmlvdXMgbGV2ZWxzIG9mIGFic3RyYWN0aW9u cy4gVGhpcyBtZWFucyB0aGF0IGJvdGggZ2VuZXJpYyBtb2RlbHMgKGUuZy4gYSB0ZWNobm9sb2d5 IGFnbm9zdGljIEwzIFZQTiBtb2RlbCkgYW5kIG1vcmUgaW1wbGVtZW50YXRpb24tb3JpZW50ZWQg bW9kZWxzIChlLmcuIFZQTFMpIHdvdWxkIGJlIGNsYXNzaWZpZWQgYXMgTmV0d29yayBTZXJ2aWNl IFlBTkcgRGF0YSBNb2RlbHMgd2l0aG91dCBiZWluZyBhdCB0aGUgZXhhY3Qgc2FtZSBsZXZlbCBv ZiBhYnN0cmFjdGlvbi4NCj4+PiANCj4+Pj4gMi4gICAgICAgV2hhdCBpcyB0aGUgbGF5ZXIgb2Yg dGVjaG5vbG9neSBzb2x1dGlvbnMsIHN1Y2ggYXMsIFZ4TEFOLCBHUkUsIFZQTFMsIGV0Yz8NCj4+ PiANCj4+PiBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgVnhMQU4sIEdSRSwgVlBMUyBjb25maWd1 cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIHJlc2lkaW5nIG9uIGEgZGV2aWNlLCB0 aGVuIGl04oCZcyBOZXR3b3JrIEVsZW1lbnQgWUFORyBEYXRhIG1vZGVscy4gSWYgeW914oCZcmUg dGFsa2luZyBhYm91dCBWeExBTiwgR1JFLCBWUExTIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlv bmFsIHBhcmFtZXRlcnMgYXMgcGFydCBvZiBhbiAiYWJzdHJhY3QgbW9kZWwgdGhhdCBhbGxvd3Mg aW5zdGFuY2VzIG8gdGhlIHNlcnZpY2UgdG8gYmUgZGVjb21wb3NlZCBpbnRvIGluc3RhbmNlIGRh dGEgYWNjb3JkaW5nIHRvIHRoZSBOZXR3b3JrIEVsZW1lbnQgZGF0YSBtb2RlbHMgb2YgdGhlIHBh cnRpY2lwYXRpbmcgbmV0d29yayBlbGVtZW50c+KAnSwgdGhlbiBpdCB3b3VsZCBiZSBjbGFzc2lm aWVkIGFzIGEgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbHMuIA0KPj4+IA0KPj4+PiAz LiAgICAgICBJbiBUTU4gTS4zMDEwLCBuZXR3b3JrIG1vZGVsIGFsc28gYSBwYXJ0aWN1bGFyIGxh eWVyLCBzaG91bGQgc3BlY2lmaWMgeWFuZyBtb2RlbCBjb3ZlciB0aGlzIGxheWVyPw0KPj4+IA0K Pj4+IEkgaGF2ZSBkb25lIHNvbWUgcmVhZGluZyBvbiBNLjMwMTAgYW5kIGJlbGlldmUgd2UgYXJl IHdlbGwgYWxpZ25lZCBpbiB0aGUgZHJhZnQuIFRoZSBuZXR3b3JrIG1vZGVsIHdvdWxkIGJlIGNs YXNzaWZpZWQgYWQgYXMgTmV0d29yayBTZXJ2aWNlIFlBTkcgRGF0YSBNb2RlbC4NCj4+PiANCj4+ Pj4gQmVzdCBSZWdhcmRzLA0KPj4+PiBZYWxpDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0 DQo+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPj4+IA0KPj4gDQo+IA0KDQo= From nobody Sun Apr 24 18:31:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97512B077 for ; Sun, 24 Apr 2016 18:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQe-nBwkXzlw for ; Sun, 24 Apr 2016 18:31:49 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A1512B061 for ; Sun, 24 Apr 2016 18:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 54473258AF8 for ; Sun, 24 Apr 2016 18:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461547909; bh=O1kJIu7usJZaBnkzGI1kvtcSzQdmnNoSQngvTdqZkAA=; h=Subject:References:To:From:Date:In-Reply-To:From; b=ZHfA+6vN0cnc09vQkMpZY9kpaEjpLMASN2sbO6Dfj23e9yvX0LUp6pxluCidGiaWm DKgQ66les1MImgTu8mN/mpIq+Em2mgK7KUaXxkxGI/1/jPgDOo6c4EDowqx0mvHDaG YOkJ7QFZSX7yqWhAjiqznxAI2q33Lh7bVpT3X2Fc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id ED1B3250978 for ; Sun, 24 Apr 2016 18:31:48 -0700 (PDT) References: <89464A41-4084-4CB8-92A0-88335B2B69B1@cisco.com> <5420574D-7C27-45A5-BDE0-C4B6E9FDA678@cisco.com> <4F517FA6-936C-463C-B5EB-0256A323CAD9@cisco.com> To: "netmod@ietf.org" From: "Joel M. Halpern" Message-ID: <571D7380.1090205@joelhalpern.com> Date: Sun, 24 Apr 2016 21:31:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] yang model classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 01:31:51 -0000 What is the relationship between this taxonomy and the many models that do not fit its cateogrization? Three examples: Models used in ODL to generate results which may be neither network services nor network elements. They may be in between, or in some other dimension? Also, models used to describe things in other aspects of environments, such as Policy models? And models of things which are not conventional network elements, such as models of compute platforms, models of applications, even models of control systems. Yours, Joel From nobody Wed Apr 27 00:55:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EA012D5FC for ; Wed, 27 Apr 2016 00:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ksNgOdIEN_c for ; Wed, 27 Apr 2016 00:55:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6BEF12D605 for ; Wed, 27 Apr 2016 00:55:13 -0700 (PDT) Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id EBB051AE00A0; Wed, 27 Apr 2016 09:55:11 +0200 (CEST) Date: Wed, 27 Apr 2016 09:55:11 +0200 (CEST) Message-Id: <20160427.095511.62299994686131994.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <571A1874.6070306@cisco.com> References: <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <571A1874.6070306@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 07:55:21 -0000 Benoit Claise wrote: > Hi Martin, > > Removed some extra ones on which we agree. > See in line. > > > >>>> - Terminology: > >>>> The following terms are defined in [RFC6241 > >>>> ]: > >>>> > >>>> ... > >>>> > >>>> o configuration datastore: a configuration datastore is an > >>>> instantiated data tree with configuration data > >>>> > >>>> o datastore: an instantiated data tree > >>>> > >>>> RFC6241 has different definition for "configuration datastore" and > >>>> "datastore". > >>>> I would just provide the pointer to the RFC 6241 definitions. > >>>> If you intend to provide an adapted definition for the YANG mappings, > >>>> then you should say so. > >>> How about: > >>> > >>> OLD: > >>> > >>> o configuration datastore: a configuration datastore is an > >>> instantiated data tree with configuration data > >>> > >>> o datastore: an instantiated data tree > >>> > >>> NEW: > >>> > >>> o configuration datastore: When modelled with YANG, a configuration > >>> datastore is an instantiated data tree with configuration data > >>> > >>> o datastore: When modelled with YANG, an instantiated data tree > >>> > >> This issue is with "The following terms are defined in [RFC6241]", but > >> you re-define those terms. I don't think it is correct to say that we "re-define" these terms. It sounds like we give the terms a different meaning. I agree that the OLD text gave that impression, but I think the NEW proposed text fixes this. The terms are defined in 6241, and they keep their meaning. We clarify the meaning of two of the terms in a YANG context. > >> So give a warning about the redefinition to the readers. > > Yes, that's what my proposed text does. It says that "datastore" is > > defined in 6241, and when YANG is used, it means the instantiated data > > tree. > OLD: > > The following terms are defined in [RFC6241 > ]: > > NEW: > > The following terms are defined in [RFC6241 > ], but re-defined in this > document in YANG context: /martin From nobody Wed Apr 27 02:53:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E7112D6AE; Wed, 27 Apr 2016 02:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk1KJrVwIn4i; Wed, 27 Apr 2016 02:53:50 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095B512D6AC; Wed, 27 Apr 2016 02:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11221; q=dns/txt; s=iport; t=1461750830; x=1462960430; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=17RQOeUIbA5mJC4xpgl7muPPj7+9eDZO+v0NvcU5EV8=; b=msv78O5c3rbN0EW5Kg1JZo+E71rwBeIKs6YdZSRHSulVepqIuYwdWzsn /X1sQMrhBW9c9BsUax3rP9vtt6HovRVe+TB5/i0kHxudOBs5jpYiOfMFu ls3sfQCry38+Cn1vY2Y8nZrVrucgmz0fNDIVgFlN7Q8yC2ThCOk1ocmlh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAQCTiyBX/xbLJq1EGoQLfbR4hHMBD?= =?us-ascii?q?YF0IoVtAoFxFAEBAQEBAQFlJ4RCAgQjVQEQLAwKCwICCQMCAQIBRQYNCAEBiCY?= =?us-ascii?q?OLLMIkTMBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhiHJVgkGCVgWNVIo8jheJO?= =?us-ascii?q?oVXjzAeAQFCg206MAGHbwIeBytsAQEB?= X-IronPort-AV: E=Sophos;i="5.24,540,1454976000"; d="scan'208,217";a="634353798" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 09:53:47 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3R9rl0H006189; Wed, 27 Apr 2016 09:53:47 GMT References: <571F3E77.5030002@cisco.com> From: Benoit Claise To: NETMOD Working Group X-Forwarded-Message-Id: <571F3E77.5030002@cisco.com> Message-ID: <57208C2A.8020605@cisco.com> Date: Wed, 27 Apr 2016 11:53:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <571F3E77.5030002@cisco.com> Content-Type: multipart/alternative; boundary="------------000303090403060903080603" Archived-At: Cc: "draft-ietf-netmod-rfc6020bis@ietf.org" Subject: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 09:53:52 -0000 This is a multi-part message in MIME format. --------------000303090403060903080603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is second and final part of my AD review. -7.14.3. The output Statement If a "config" statement is present for any node in the output tree, the "config" statement is ignored. What does "ignored" mean? We can't set a leaf as RPC output? If I take a the example in 7.15.3 ... yang-version 1.1; namespace "urn:example:server-farm"; prefix "sfarm"; import ietf-yang-types { prefix "yang"; } list server { key name; leaf name { type string; } action reset { input { leaf reset-at { type yang:date-and-time; mandatory true; } } output { leaf reset-finished-at { type yang:date-and-time; mandatory true; } } } } } I guess it means that reset-at is not instantiated, and only part of RPC-reply It was not clear to me without investigation. A sentence around this would be welcome. - section 7.17 Editorial: augment "/if:interfaces/if:interface" { when "if:type = 'mymod:some-new-iftype'"; leaf mandatory-leaf { mandatory true; type string; } } } Discussing with Martin, this example should be improved with derived-from (more flexible than equal), like in section 10.4.1.1 - Section8.2. Configuration Data Modification to be consistent with a previous comment (AD review part 1): - Section4.2.7. Choices To be consistent with When a node from one case is created in the data tree, all nodes from all other cases are implicitly deleted. This text in section 7.9 should be updated. OLD: Since only one of the choice's cases can be valid at any time, the creation of a node from one case implicitly deletes all nodes from all other cases. If a request creates a node from a case, the server will delete any existing nodes that are defined in other cases inside the choice. NEW: Since only one of the choice's cases can be valid at any time_in the data tree_, the creation of a node from one case implicitly deletes all nodes from all other cases. If a request creates a node from a case, the server will delete any existing nodes that are defined in other cases inside the choice. OLD: o If a request creates configuration data nodes under a "choice", any existing nodes from other "case" branches are deleted by the server. NEW: o If a request creates configuration data nodes under a "choice", any existing nodes from other "case" branches_in the data tree_ are deleted by the server. And also: OLD: o If a request modifies a configuration data node such that any node's "when" expression becomes false, then the node with the "when" expression is deleted by the server. NEW: o If a request modifies a configuration data node such that any node's "when" expression becomes false, then the node with the "when" expression_in the data tree_ is deleted by the server. - section8.3. NETCONF Constraint Enforcement Model For configuration data, there are three windows when constraints MUST be enforced: o during parsing of RPC payloads o during processing of NETCONF operations o during validation Each of these scenarios is considered in the following sections. Second bullet (why "s" on operations, btw), isn't "8.3.2. NETCONF Processing" OLD: o during processing of NETCONF operations NEW ? o during processing of NETCONF Processing - Section 9 Editorial proposal: OLD: When a server sends _data encoded in XML_, it MUST use the canonical form defined in this section. NEW: When a server sends _XML encoded data___, it MUST use the canonical form defined in this section. This would more in line with the text in 9: The lexical representation of a value of a certain type is used in the_XML encoding_ and when specifying default values and numerical ranges in YANG modules. - section 10 XPath Functions OLD: This document defines two generic XPath functions and four YANG type- specific XPath functions. NEW: This document defines two generic XPath functions and five YANG type- specific XPath functions. - I haven't checked, but I hope that all the RFC6020 errata are taken into account. https://www.rfc-editor.org/errata_search.php?rfc=6020 Regards, Benoit --------------000303090403060903080603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Here is second and final part of my AD review.

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

What does "ignored" mean?
We can't set a leaf as RPC output? If I take a the example in 7.15.3 ...

       yang-version 1.1;
       namespace "urn:example:server-farm";
       prefix "sfarm";

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

       list server {
         key name;
         leaf name {
           type string;
         }
         action reset {
           input {
             leaf reset-at {
               type yang:date-and-time;
               mandatory true;
              }
            }
            output {
              leaf reset-finished-at {
                type yang:date-and-time;
                mandatory true;
              }
            }
          }
        }
      }


I guess it means that reset-at is not instantiated, and only part of RPC-reply 
It was not clear to me without investigation. A sentence around this would be welcome.

- section 7.17
Editorial:
       augment "/if:interfaces/if:interface" {
          when "if:type = 'mymod:some-new-iftype'";

          leaf mandatory-leaf {
             mandatory true;
             type string;
          }
       }
     }

Discussing with Martin, this example should be improved with derived-from (more flexible than equal), like in section 10.4.1.1



- Section 8.2.  Configuration Data Modification
to be consistent with a previous comment (AD review part 1):

- Section 4.2.7.  Choices

To be consistent with

   When a node from one case is created in the data tree, all nodes from
   all other cases are implicitly deleted. 


This text in section 7.9 should be updated.
OLD:
   Since only one of the choice's cases can be valid at any time, the
   creation of a node from one case implicitly deletes all nodes from
   all other cases.  If a request creates a node from a case, the server
   will delete any existing nodes that are defined in other cases inside
   the choice.

NEW:
   Since only one of the choice's cases can be valid at any time in the data tree, the
   creation of a node from one case implicitly deletes all nodes from
   all other cases.  If a request creates a node from a case, the server
   will delete any existing nodes that are defined in other cases inside
   the choice.

OLD:
   o  If a request creates configuration data nodes under a "choice",
      any existing nodes from other "case" branches are deleted by the
      server.
NEW:
   o  If a request creates configuration data nodes under a "choice",
      any existing nodes from other "case" branches in the data tree are deleted by the
      server.

And also:
OLD:
   o  If a request modifies a configuration data node such that any
      node's "when" expression becomes false, then the node with the
      "when" expression is deleted by the server.

NEW:
   o  If a request modifies a configuration data node such that any
      node's "when" expression becomes false, then the node with the
      "when" expression in the data tree is deleted by the server.

- section 8.3.  NETCONF Constraint Enforcement Model

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

   o  during parsing of RPC payloads

   o  during processing of NETCONF operations

   o  during validation

   Each of these scenarios is considered in the following sections.

Second bullet (why "s" on operations, btw), isn't "8.3.2.  NETCONF <edit-config> Processing"
OLD: 

   o  during processing of NETCONF operations

NEW ?
   o  during processing of NETCONF <edit-config> Processing



- Section 9

Editorial proposal:
OLD:    
   When a server sends data encoded in XML, it MUST use the canonical
   form defined in this section.

NEW:
   When a server sends XML encoded data, it MUST use the canonical
   form defined in this section.


This would more in line with the text in 9:

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

- section 10 XPath Functions

OLD:
   This document defines two generic XPath functions and four YANG type-
   specific XPath functions.

NEW:

   This document defines two generic XPath functions and five YANG type-
   specific XPath functions.


- I haven't checked, but I hope that all the RFC6020 errata are taken into account.
https://www.rfc-editor.org/errata_search.php?rfc=6020

Regards, Benoit

--------------000303090403060903080603-- From nobody Wed Apr 27 03:04:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2E312D6B8 for ; Wed, 27 Apr 2016 03:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEFzXLAxWP6v for ; Wed, 27 Apr 2016 03:04:06 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E08812D6B5 for ; Wed, 27 Apr 2016 03:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7617; q=dns/txt; s=iport; t=1461751446; x=1462961046; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=GpKY0qaEzNHoftH1rTf5yyrTO1nCUMemFEGHRnffssM=; b=CLPVd2Z5nJHyiiJ9Yf68LWfKeqUAkwHE84vzCQQYZIcFNhuqbfnFwLqb wcyFFvctkGVJo7DpI9aTunmwDkQBemcPy+2X+iwhRhTorcjjdlyaJPJ1i oJ73S4+Jkz/YctOr0xnq2z7OFeESaBqywZ5nQfxj4une17qUde6wxiEMK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtAQDYjSBX/xbLJq1ehAt9tHiEcwENg?= =?us-ascii?q?XQehXECgXEUAQEBAQEBAWUnhEIBAQR5EAsOCgklDwJGBg0GAgEBiCYOxGMBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuKEwWTH4RxhXyIG4k6hVePMB4BAUKDb?= =?us-ascii?q?TowiS4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,540,1454976000"; d="scan'208,217";a="634353923" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 10:04:04 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3RA43st008358; Wed, 27 Apr 2016 10:04:03 GMT To: Martin Bjorklund References: <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <571A1874.6070306@cisco.com> <20160427.095511.62299994686131994.mbj@tail-f.com> From: Benoit Claise Message-ID: <57208E93.202@cisco.com> Date: Wed, 27 Apr 2016 12:04:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160427.095511.62299994686131994.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------030807010302020900020401" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 10:04:14 -0000 This is a multi-part message in MIME format. --------------030807010302020900020401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, > Benoit Claise wrote: >> Hi Martin, >> >> Removed some extra ones on which we agree. >> See in line. >>>>>> - Terminology: >>>>>> The following terms are defined in [RFC6241 >>>>>> ]: >>>>>> >>>>>> ... >>>>>> >>>>>> o configuration datastore: a configuration datastore is an >>>>>> instantiated data tree with configuration data >>>>>> >>>>>> o datastore: an instantiated data tree >>>>>> >>>>>> RFC6241 has different definition for "configuration datastore" and >>>>>> "datastore". >>>>>> I would just provide the pointer to the RFC 6241 definitions. >>>>>> If you intend to provide an adapted definition for the YANG mappings, >>>>>> then you should say so. >>>>> How about: >>>>> >>>>> OLD: >>>>> >>>>> o configuration datastore: a configuration datastore is an >>>>> instantiated data tree with configuration data >>>>> >>>>> o datastore: an instantiated data tree >>>>> >>>>> NEW: >>>>> >>>>> o configuration datastore: When modelled with YANG, a configuration >>>>> datastore is an instantiated data tree with configuration data >>>>> >>>>> o datastore: When modelled with YANG, an instantiated data tree >>>>> >>>> This issue is with "The following terms are defined in [RFC6241]", but >>>> you re-define those terms. > I don't think it is correct to say that we "re-define" these terms. > It sounds like we give the terms a different meaning. Playing with words? :-) > I agree that > the OLD text gave that impression, but I think the NEW proposed text > fixes this. This does not work. Reading the terminology ... The following terms are defined in [RFC6241 ]: o configuration datastore: ... o datastore: ... ... I will not even bother reading the definitions, because I know them from 6241. Doing this, I will not spot the subtle "different meaning" you inserted in the definitions. Regards, Benoit > > The terms are defined in 6241, and they keep their meaning. We > clarify the meaning of two of the terms in a YANG context. > >>>> So give a warning about the redefinition to the readers. >>> Yes, that's what my proposed text does. It says that "datastore" is >>> defined in 6241, and when YANG is used, it means the instantiated data >>> tree. >> OLD: >> >> The following terms are defined in [RFC6241 >> ]: >> >> NEW: >> >> The following terms are defined in [RFC6241 >> ], but re-defined in this >> document in YANG context: > > /martin > . > --------------030807010302020900020401 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Hi Martin,
Benoit Claise <bclaise@cisco.com> wrote:

Hi Martin,

Removed some extra ones on which we agree.
See in line.


          

            

              

                
- Terminology:
   The following terms are defined in [RFC6241
   <https://tools.ietf.org/html/rfc6241>]:

     ...

     o  configuration datastore: a configuration datastore is an
        instantiated data tree with configuration data

     o  datastore: an instantiated data tree

RFC6241 has different definition for "configuration datastore" and
"datastore".
I would just provide the pointer to the RFC 6241 definitions.
If you intend to provide an adapted definition for the YANG mappings,
then you should say so.


              

              
How about:

OLD:

     o  configuration datastore: a configuration datastore is an
        instantiated data tree with configuration data

     o  datastore: an instantiated data tree

NEW:

     o  configuration datastore: When modelled with YANG, a configuration
        datastore is an instantiated data tree with configuration data

     o  datastore: When modelled with YANG, an instantiated data tree



            

            
This issue is with "The following terms are defined in [RFC6241]", but
you re-define those terms.


          

        

      

      
I don't think it is correct to say that we "re-define" these terms.
It sounds like we give the terms a different meaning. 

    

    Playing with words? :-)

    

      
 I agree that
the OLD text gave that impression, but I think the NEW proposed text
fixes this.

    

    This does not work.

    

    Reading the terminology ...

    

      
   The following terms are defined in [RFC6241
   <https://tools.ietf.org/html/rfc6241>]:

    

    
     o  configuration datastore: ... 

     o  datastore: ... 

    ... I will not even bother reading the definitions, because I know
    them from 6241.

    Doing this, I will not spot the subtle "different meaning" you
    inserted in the definitions.

    

    Regards, Benoit

    

      

The terms are defined in 6241, and they keep their meaning.  We
clarify the meaning of two of the terms in a YANG context.



      

        

          

            
So give a warning about the redefinition to the readers.


          

          
Yes, that's what my proposed text does.  It says that "datastore" is
defined in 6241, and when YANG is used, it means the instantiated data
tree.


        

        
OLD:

  The following terms are defined in [RFC6241
  <https://tools.ietf.org/html/rfc6241>]:

NEW:

  The following terms are defined in [RFC6241
  <https://tools.ietf.org/html/rfc6241>], but re-defined in this
  document in YANG context:


      

      

/martin
.



    

    

  


--------------030807010302020900020401--


From nobody Wed Apr 27 03:27:55 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4512D6E2 for ; Wed, 27 Apr 2016 03:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFvQ-RfusPnY for ; Wed, 27 Apr 2016 03:27: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 B533112D6EF for ; Wed, 27 Apr 2016 03:27:52 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 80D7C11BF; Wed, 27 Apr 2016 12:27: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 zfJs3Z73qseV; Wed, 27 Apr 2016 12:27: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; Wed, 27 Apr 2016 12:27:50 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE0A920047; Wed, 27 Apr 2016 12:27: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 WqLLPbSlzdtE; Wed, 27 Apr 2016 12:27: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 9C2A620046; Wed, 27 Apr 2016 12:27:49 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D0A2E3AB82C3; Wed, 27 Apr 2016 12:27:48 +0200 (CEST)
Date: Wed, 27 Apr 2016 12:27:48 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20160427102748.GC21463@elstar.local>
Mail-Followup-To: Benoit Claise , Martin Bjorklund , netmod@ietf.org
References: <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <571A1874.6070306@cisco.com> <20160427.095511.62299994686131994.mbj@tail-f.com> <57208E93.202@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57208E93.202@cisco.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Apr 2016 10:27:55 -0000

On Wed, Apr 27, 2016 at 12:04:03PM +0200, Benoit Claise wrote:

> > > > > This issue is with "The following terms are defined in [RFC6241]", but
> > > > > you re-define those terms.
> >
> > I don't think it is correct to say that we "re-define" these terms.
> > It sounds like we give the terms a different meaning.
>
> Playing with words? :-)

That's what the IETF is good for. ;-)

I think we _refine_ definitions here to make it clear what they mean
in the context of YANG. We do not _redefine_ definitions.

/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 Apr 27 03:38:04 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531D12D138; Wed, 27 Apr 2016 03:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3tWuwlKZlGx; Wed, 27 Apr 2016 03:38: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 1610B12D669; Wed, 27 Apr 2016 03:38:02 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id E28301AE00A0; Wed, 27 Apr 2016 12:38:00 +0200 (CEST)
Date: Wed, 27 Apr 2016 12:38:00 +0200 (CEST)
Message-Id: <20160427.123800.635890758896303567.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <57208C2A.8020605@cisco.com>
References: <571F3E77.5030002@cisco.com> <57208C2A.8020605@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 2)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 10:38:04 -0000

Benoit Claise  wrote:
> Dear all,
> 
> Here is second and final part of my AD review.
> 
> -7.14.3.  The output Statement
> 
>    If a "config" statement is present for any node in the output tree,
>    the "config" statement is ignored.
> 
> What does "ignored" mean?

It means that it is treated as if it wasn't there.

> We can't set a leaf as RPC output? If I take a the example in 7.15.3
> ...
> 
>        yang-version 1.1;
>        namespace "urn:example:server-farm";
>        prefix "sfarm";
> 
>        import ietf-yang-types {
>          prefix "yang";
>        }
> 
>        list server {
>          key name;
>          leaf name {
>            type string;
>          }
>          action reset {
>            input {
>              leaf reset-at {
>                type yang:date-and-time;
>                mandatory true;
>               }
>             }
>             output {
>               leaf reset-finished-at {
>                 type yang:date-and-time;
>                 mandatory true;
>               }
>             }
>           }
>         }
>       }
> 
> 
> I guess it means that reset-at is not instantiated, and only part of
> RPC-reply
> It was not clear to me without investigation. A sentence around this
> would be welcome.
> 
> - section 7.17
> Editorial:
>        augment "/if:interfaces/if:interface" {
>           when "if:type = 'mymod:some-new-iftype'";
> 
>           leaf mandatory-leaf {
>              mandatory true;
>              type string;
>           }
>        }
>      }
> 
> Discussing with Martin, this example should be improved with
> derived-from (more flexible than equal), like in section 10.4.1.1

Fixed.

> - Section8.2.  Configuration Data Modification
> to be consistent with a previous comment (AD review part 1):
> 
>    - Section4.2.7.  Choices
> 
>    To be consistent with
> 
>        When a node from one case is created in the data tree, all nodes from
>        all other cases are implicitly deleted.
> 
> 
>    This text in section 7.9 should be updated.
>    OLD:
>        Since only one of the choice's cases can be valid at any time, the
>        creation of a node from one case implicitly deletes all nodes from
>        all other cases.  If a request creates a node from a case, the server
>        will delete any existing nodes that are defined in other cases inside
>        the choice.
> 
>    NEW:
>        Since only one of the choice's cases can be valid at any time_in the
>        data tree_, the
>        creation of a node from one case implicitly deletes all nodes from
>        all other cases.  If a request creates a node from a case, the server
>        will delete any existing nodes that are defined in other cases inside
>        the choice.
> 
> OLD:
>    o  If a request creates configuration data nodes under a "choice",
>       any existing nodes from other "case" branches are deleted by the
>       server.
> NEW:
>    o  If a request creates configuration data nodes under a "choice",
>       any existing nodes from other "case" branches_in the data tree_ are
>       deleted by the
>       server.

Ok.

> And also:
> OLD:
>    o  If a request modifies a configuration data node such that any
>       node's "when" expression becomes false, then the node with the
>       "when" expression is deleted by the server.
> 
> NEW:
>    o  If a request modifies a configuration data node such that any
>       node's "when" expression becomes false, then the node with the
>       "when" expression_in the data tree_  is deleted by the server.

Ok.

> - section8.3.  NETCONF Constraint Enforcement Model
> 
>    For configuration data, there are three windows when constraints MUST
>    be enforced:
> 
>    o  during parsing of RPC payloads
> 
>    o  during processing of NETCONF operations
> 
>    o  during validation
> 
>    Each of these scenarios is considered in the following sections.
> 
> Second bullet (why "s" on operations, btw), isn't "8.3.2.  NETCONF
>  Processing"
> 
> OLD:
> 
>    o  during processing of NETCONF operations
> 
> 
> NEW ?
>    o  during processing of NETCONF  Processing

I think the current text is fine, but I can live with:

NEW:

  o  during processing of the  operation

> - Section 9
> 
> Editorial proposal:
> 
> OLD: When a server sends _data encoded in XML_, it MUST use the
> canonical form defined in this section.
> 
> NEW: When a server sends _XML encoded data___, it MUST use the
> canonical form defined in this section.

Ok.

> This would more in line with the text in 9:
> 
>   The lexical representation of a value of a certain type is used in
>    the_XML encoding_  and when specifying default values and numerical
>    ranges in YANG modules.
> 
> 
> - section 10 XPath Functions
> 
> OLD:
>    This document defines two generic XPath functions and four YANG type-
>    specific XPath functions.
> 
> NEW:
> 
>    This document defines two generic XPath functions and five YANG type-
>    specific XPath functions.


Ok.

> - I haven't checked, but I hope that all the RFC6020 errata are taken
> - into account.
> https://www.rfc-editor.org/errata_search.php?rfc=6020

Yes they are.


/martin


From nobody Wed Apr 27 03:43:29 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F6F12D71D for ; Wed, 27 Apr 2016 03:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqiRBGB8Z7dG for ; Wed, 27 Apr 2016 03:43: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 D012F12D5BE for ; Wed, 27 Apr 2016 03:43:25 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 5EF001AE00A0; Wed, 27 Apr 2016 12:43:24 +0200 (CEST)
Date: Wed, 27 Apr 2016 12:43:24 +0200 (CEST)
Message-Id: <20160427.124324.1763217338408362847.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <57208E93.202@cisco.com>
References: <571A1874.6070306@cisco.com> <20160427.095511.62299994686131994.mbj@tail-f.com> <57208E93.202@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 10:43:27 -0000

Benoit Claise  wrote:
> Hi Martin,
> > Benoit Claise  wrote:
> >> Hi Martin,
> >>
> >> Removed some extra ones on which we agree.
> >> See in line.
> >>>>>> - Terminology:
> >>>>>>     The following terms are defined in [RFC6241
> >>>>>>     ]:
> >>>>>>
> >>>>>>       ...
> >>>>>>
> >>>>>>       o  configuration datastore: a configuration datastore is an
> >>>>>>          instantiated data tree with configuration data
> >>>>>>
> >>>>>>       o  datastore: an instantiated data tree
> >>>>>>
> >>>>>> RFC6241 has different definition for "configuration datastore" and
> >>>>>> "datastore".
> >>>>>> I would just provide the pointer to the RFC 6241 definitions.
> >>>>>> If you intend to provide an adapted definition for the YANG mappings,
> >>>>>> then you should say so.
> >>>>> How about:
> >>>>>
> >>>>> OLD:
> >>>>>
> >>>>>       o  configuration datastore: a configuration datastore is an
> >>>>>          instantiated data tree with configuration data
> >>>>>
> >>>>>       o  datastore: an instantiated data tree
> >>>>>
> >>>>> NEW:
> >>>>>
> >>>>>       o configuration datastore: When modelled with YANG, a configuration
> >>>>>          datastore is an instantiated data tree with configuration data
> >>>>>
> >>>>>       o  datastore: When modelled with YANG, an instantiated data tree
> >>>>>
> >>>> This issue is with "The following terms are defined in [RFC6241]", but
> >>>> you re-define those terms.
> > I don't think it is correct to say that we "re-define" these terms.
> > It sounds like we give the terms a different meaning.
> Playing with words? :-)
> >   I agree that
> > the OLD text gave that impression, but I think the NEW proposed text
> > fixes this.
> This does not work.
> 
> Reading the terminology ...
> 
>        The following terms are defined in [RFC6241
>        ]:
> 
>      o  configuration datastore: ...
> 
>      o  datastore: ...
> 
> ... I will not even bother reading the definitions, because I know
> them from 6241.
> Doing this, I will not spot the subtle "different meaning" you
> inserted in the definitions.

Ok, how about moving the specialized-meaning-text to its own paragraph:


  The following terms are defined in [RFC6241]:

   o  configuration data

   o  configuration datastore

   o  datastore

   o  running configuration datastore

   o  state data

   When modelled with YANG, a datastore is realized as an instantiated
   data tree.

   When modelled with YANG, a configuration datastore is realized as an
   instantiated data tree with configuration data.



/martin


From nobody Wed Apr 27 04:19:36 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6430012D797 for ; Wed, 27 Apr 2016 04:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTMUWu4aHuvG for ; Wed, 27 Apr 2016 04:19:34 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3167E12D125 for ; Wed, 27 Apr 2016 04:19:34 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C801F7DE; Wed, 27 Apr 2016 13:19: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 F7RXbTbv3jEt; Wed, 27 Apr 2016 13:19:20 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Apr 2016 13:19:32 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A758320047; Wed, 27 Apr 2016 13:19:31 +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 MT_7lT40_VWz; Wed, 27 Apr 2016 13:19:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8ABA20046; Wed, 27 Apr 2016 13:19:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E07F13AB8473; Wed, 27 Apr 2016 13:19:23 +0200 (CEST)
Date: Wed, 27 Apr 2016 13:19:23 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160427111923.GA21712@elstar.local>
Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, netmod@ietf.org
References: <571A1874.6070306@cisco.com> <20160427.095511.62299994686131994.mbj@tail-f.com> <57208E93.202@cisco.com> <20160427.124324.1763217338408362847.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160427.124324.1763217338408362847.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Apr 2016 11:19:35 -0000

On Wed, Apr 27, 2016 at 12:43:24PM +0200, Martin Bjorklund wrote:
> Ok, how about moving the specialized-meaning-text to its own paragraph:
> 
> 
>   The following terms are defined in [RFC6241]:
> 
>    o  configuration data
> 
>    o  configuration datastore
> 
>    o  datastore
> 
>    o  running configuration datastore
> 
>    o  state data
> 
>    When modelled with YANG, a datastore is realized as an instantiated
>    data tree.
> 
>    When modelled with YANG, a configuration datastore is realized as an
>    instantiated data tree with configuration data.
>

Looks good to me.

/js

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


From nobody Wed Apr 27 04:20:11 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A4A12D7B5 for ; Wed, 27 Apr 2016 04:20:09 -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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87AehT9eFKUG for ; Wed, 27 Apr 2016 04:20:07 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8FC12D7A9 for ; Wed, 27 Apr 2016 04:20:00 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 583EE1CC008F; Wed, 27 Apr 2016 13:20:03 +0200 (CEST)
From: Ladislav Lhotka 
To: Benoit Claise , Martin Bjorklund 
In-Reply-To: <57208E93.202@cisco.com>
References: <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <571A1874.6070306@cisco.com> <20160427.095511.62299994686131994.mbj@tail-f.com> <57208E93.202@cisco.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 27 Apr 2016 13:20:00 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 11:20:09 -0000

Benoit Claise  writes:

> Hi Martin,
>> Benoit Claise  wrote:
>>> Hi Martin,
>>>
>>> Removed some extra ones on which we agree.
>>> See in line.
>>>>>>> - Terminology:
>>>>>>>     The following terms are defined in [RFC6241
>>>>>>>     ]:
>>>>>>>
>>>>>>>       ...
>>>>>>>
>>>>>>>       o  configuration datastore: a configuration datastore is an
>>>>>>>          instantiated data tree with configuration data
>>>>>>>
>>>>>>>       o  datastore: an instantiated data tree
>>>>>>>
>>>>>>> RFC6241 has different definition for "configuration datastore" and
>>>>>>> "datastore".
>>>>>>> I would just provide the pointer to the RFC 6241 definitions.
>>>>>>> If you intend to provide an adapted definition for the YANG mappings,
>>>>>>> then you should say so.
>>>>>> How about:
>>>>>>
>>>>>> OLD:
>>>>>>
>>>>>>       o  configuration datastore: a configuration datastore is an
>>>>>>          instantiated data tree with configuration data
>>>>>>
>>>>>>       o  datastore: an instantiated data tree
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>>       o  configuration datastore: When modelled with YANG, a configuration
>>>>>>          datastore is an instantiated data tree with configuration data
>>>>>>
>>>>>>       o  datastore: When modelled with YANG, an instantiated data tree
>>>>>>
>>>>> This issue is with "The following terms are defined in [RFC6241]", but
>>>>> you re-define those terms.
>> I don't think it is correct to say that we "re-define" these terms.
>> It sounds like we give the terms a different meaning.
> Playing with words? :-)
>>   I agree that
>> the OLD text gave that impression, but I think the NEW proposed text
>> fixes this.
> This does not work.
>
> Reading the terminology ...
>
>         The following terms are defined in [RFC6241
>         ]:
>
>       o  configuration datastore: ...
>
>       o  datastore: ...
>
> ... I will not even bother reading the definitions, because I know them 
> from 6241.
> Doing this, I will not spot the subtle "different meaning" you inserted 
> in the definitions.

I think it would be useful to state what "configuration data" mean in
YANG context: it is a subtree of the main data tree containing only
instances of "config true" data nodes. I don't think the definition
inherited from 6241 is useful, in fact I am not even sure it is correct.

The problem I have with the refined definitions of "datastore" and
"configuration datastore" is the cabbalistic word "instantiated". I
think it should be explained or removed. As a matter of fact, the
meaning of "instantiate" in the definition of "uses" is clearly
different.

Lada

>
> Regards, Benoit
>>
>> The terms are defined in 6241, and they keep their meaning.  We
>> clarify the meaning of two of the terms in a YANG context.
>>
>>>>> So give a warning about the redefinition to the readers.
>>>> Yes, that's what my proposed text does.  It says that "datastore" is
>>>> defined in 6241, and when YANG is used, it means the instantiated data
>>>> tree.
>>> OLD:
>>>
>>>    The following terms are defined in [RFC6241
>>>    ]:
>>>
>>> NEW:
>>>
>>>    The following terms are defined in [RFC6241
>>>    ], but re-defined in this
>>>    document in YANG context:
>>
>> /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 Apr 27 04:41:15 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695F12D778 for ; Wed, 27 Apr 2016 04:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfKt7z6YvL33 for ; Wed, 27 Apr 2016 04:41:10 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0119.outbound.protection.outlook.com [104.47.2.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E4612D106 for ; Wed, 27 Apr 2016 04:41:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2y1Pi/W5wi+mct2Hxm0OSzcPxcj9mYQIaxO1sQ4PpqI=; b=W9B4xOJQxlWpEYWFJkHB+7SVF7TEyTBIT1uUah/P42GRTD/cI4SDICO+jn3hIoyHT0YU+PfZD8ssfQA0ZaNgKWu3V4w9dP7hxrBsW9ivWHvWJeG3xzq4LxLVYxJF7ux7ycnH4fh3v9N60Am7bZHdmJvI0KD9qQHEZbEwyKlsV3k=
Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (81.159.99.181) by HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 27 Apr 2016 11:41:07 +0000
Message-ID: <00aa01d1a079$377422e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Clyde Wildes (cwildes)" 
References: <20160320151006.2321.64042.idtracker@ietfa.amsl.com>  <01cb01d18914$ab13ae40$4001a8c0@gateway.2wire.net> <0CA65B1D-6699-42BC-8FD9-1EBEB692EE55@cisco.com>   <00ee01d18cd6$78724620$4001a8c0@gateway.2wire.net> <73ABB15F-1A72-4239-B85A-38EA6C8AFE91@cisco.com>
Date: Wed, 27 Apr 2016 12:21:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.159.99.181]
X-ClientProxiedBy: AM3PR04CA0100.eurprd04.prod.outlook.com (10.163.180.154) To HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22)
X-MS-Office365-Filtering-Correlation-Id: b4307151-a090-4a9b-715e-08d36e90d2bc
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 2:sJJX8njNK0x8UaKsRHI1KdXoML10QYK43sJequjhBYvZwRzDakrTfVDkS1b41w+8xROE4AtiK8Ov5uLfYHjCAeHF8hp5ix0xH+l2o1VyeuiyAw7BLcGtO6fZ40NiBEsg+ZTM59vAJQHWytINrQW8FSIO9ea4K4SJkYDuUz+GWHp5+7gVxHboCs9Qpyu7lbvw; 3:SqQeGp2HMqX/SHSSVUzXVhVuBmkzEYq8H8cA0JjMSbVjiZfsravfwFdbIs7kjEkWBDuvogwTzISjq6801iJjffiGMA96a0xjPV6VOLRBU4Ply7OmRlHMdY+m3mofUB+w; 25:7jVKOe6nGxrCEc8xbL7tD+84GEwAuS6Sc3fYmi8YLKUbdlh8eK0hi2I9ka5Rf0/ptjp5wj3lFGDzBmqT89UaM6wGd+qKPJCw+6r9VohuHToF00h3rFO98sC+5oMlMVnsA6nnNVdBd/pKyD8ntwyGmBSXlXZgCSsPqP1gIWFVVku1z72snZ3Vc5JpwuU3T7omVbgcOxaOjqdw1iGiQq3OKbMl1k8aa7C2t+PnyZaWyLWJR6/QXTudloJxY0JcPCoyKAZQp54Xy3vlNwwEb0YZyJKvajh+l7YOclNzGVcQuUSbzX6epPddU9N1SUc5r0gBkuYc42X1APbNa9x9UeVGTQ==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1626;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR07MB1626; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1626; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 4:pkG2faac6nq2EURzUDTjyTMmAKRAYwzzyJBPNauNlvq8KTm9mNmPX2PXD0VB4fIcwOwzO8zTNz8nspXiKT/UP9omvSKVs94c+dMD5whaoEKDkn5+8cn88HxKviP9DDlKNi9systwauH6ACCdcWjmob6p7Zx1YXlEu3pSZT2ArFcsayN8swvgdeKHiaAjfvh3+4QwRzEiJHkh2VTsPabO1r2ugYS7qE3yzUgbGVvlLWOA1VYwMmcNKwJAKvFV1v5+uvRCeVLDXKvas97KUpQwoOfn0oufLwv/8OCflPWygTZG0natnbGm3+0ryccCr+yzZbXN+QV3llJTODRDyorzf2N4mo9HdfHmBl8wBe+YxskiI6jZbtq/nrngMQ+6Z3Dru3r+5cTqQF0Bnjtp/OquFCTc7tjihO4defq379JjkvxTKmY6/pFu6vNkG0DrKGA7
X-Forefront-PRVS: 0925081676
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(51444003)(13464003)(24454002)(377454003)(3846002)(6116002)(92566002)(44716002)(66066001)(116806002)(47776003)(62236002)(50986999)(1096002)(81166005)(19580395003)(2906002)(50466002)(5820100001)(81686999)(1456003)(9686002)(586003)(19580405001)(230783001)(81816999)(93886004)(86362001)(110136002)(23676002)(14496001)(44736004)(4326007)(189998001)(230700001)(84392002)(1556002)(76176999)(33646002)(77096005)(61296003)(15975445007)(42186005)(5008740100001)(5004730100002)(50226002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1626; H:pc6; FPR:; SPF:None; MLV:sfv;  LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNjI2OzIzOmlsWS80Y21sT2VhQ1hwVy9xMUx0RjgxY1pF?= =?utf-8?B?RXR4R0NmOEd0VGxUNVM2Q0dvaVFsNVU4Z3pxMGxRZTdJOTFBUXlCekJKK1BW?= =?utf-8?B?NXNaZHVSTzVQNnFXb01xQlVnQjlKcUNWYWhEYnRjdnhyK21EYzIyUUUxSktY?= =?utf-8?B?MGltR2JLMGduU1E5NTNFMWJrdkdwdGZJeWYyTGo3dVhYV1pVVFBsVi9pTVBy?= =?utf-8?B?YnBIcjNQZGtjZFkvY3FTVTltVUtyRjNnaGpNSlBkRTMrRGY5RVJBVWtlR000?= =?utf-8?B?WFhmOS9BSTVaTUErTEhKRTFiT2RZYU1PSzNlVXh0S1hHQ0N3VXhueEh4VHRk?= =?utf-8?B?Q2lYcHd5b2wydXZxZGJ2R3FNbzI5alQ4OXdBMEhKTXJOc1ZIck9SVlovVTQv?= =?utf-8?B?djYzUDJ5Zm9OTGNzSHM3WXk4NGRmb0lERWZSYlVieHZsaTBDYnRlZndWQ29X?= =?utf-8?B?RjIvRmVNd3ByRlRWV2FBK1VNSXhPNERZWkVvSDNjYkN5ZEJkd0FqcklWTWYr?= =?utf-8?B?RGhCNlFZTWVOR0tKRENOYmhkR25NZmhaUUxVcFFkVHFOcjhkR0lZN2ZxMVBt?= =?utf-8?B?ZTFCZE1pS295ODFSUVErc0xlZitQbkN0Z3lUd0xGZi9yWmdxdkxhNVB3VTRk?= =?utf-8?B?ZStaZzEwc29oV3IwRTRqY2Y4aUpza21QNXUxczhFZEdUZUFNMWhUUU5odjJO?= =?utf-8?B?eDlRSmRzb0tWUEVzOWwzd0g5OE91aDZHcXJ6K3lObWJrdlZWcmd6MzZVc01k?= =?utf-8?B?eEtyb05mN09tOEZkVk90akdlQXVZNVc0YTJaL2d5aTgwVkdCemZmd3lvVk1D?= =?utf-8?B?SmhpT1prU1UvUjNlZW93ZGRnd1o4S0MvaWhWVk0rYXNXQXJGclNuTm5FZWFm?= =?utf-8?B?NnBObXBZTDl0SC9DOWs4bktsTkJSNG1DbmpHN2FLekMwMGhoMFg3UC92dXVo?= =?utf-8?B?eWd3ZHNRZUFvWHNtSVN0MlB0OHZCSFRDL1QyYUIyNGxWdmNKRlU3aEhFUnZz?= =?utf-8?B?QkNia1ZndC9MajM1UFEyVW8xdkE4MUw3cm1qL0RXYUdYNXg2U1ExQmwwdWhD?= =?utf-8?B?NWdwQzJYTzM1MkdGajlRYjV4Zm5VczFqU3lma1I5c2ZGbVJyWW9UMDdMWU1O?= =?utf-8?B?NVExMDBQLzZUR3lCUGNNMHpDOFlhUHV0MUpNU0p4S1hwQUFmenBRU2w0NTdY?= =?utf-8?B?NU5ScmxraU1PZE5qUEcyb2ZaMFBTR2dOSXdLUTVYdWl5NitZR0NTZE96RTEv?= =?utf-8?B?Y0xKSjllTW15Q3lrZkI2SHhHbkNqa0R3aHhlc0JERTNVbFpFZjVKMGdNL3dJ?= =?utf-8?B?amNSdXVBZ0RsN2lXemx0K2FmTzI2SDQxbjlqL0RVSUl1ekEyb3lJMDNSUHVU?= =?utf-8?B?cTg2MkwwVDVPRXhQRUQyY3orZzZpOUxyeUwzdGVWd3c2OTdaN0NVM1B3Vzl6?= =?utf-8?B?a1dFZWU0RERXOCs5T2RYU0lMc1Y1MmZCSGQ1YWtPS3FwcS9MWUtjei8vREIy?= =?utf-8?B?cTAzSUtaK3JrbjR5OXNaQTBpbVJDZEtQYUpEQ3EwdkxKWHdvdHA1OG1ValVn?= =?utf-8?B?NW5BMkgxZXVadEhDQnlDdVZiMUZtdnFiVUNVZGt1Q1l1eCtUOXdwR3FCUi83?= =?utf-8?B?c1lIOHQyZlFzSlo4dGJ0UElQYTY5TGdDSEhRa0QveUdOeXRxSEhGemZhcGNj?= =?utf-8?B?Wmh0ZE9JZDVUVkNndHp1azdyY0FkcDdDYng3dS9iVHArYkU3QjRwQ0IxbGRm?= =?utf-8?B?RVR0bXArS3FyQ0lHdXI2QT09?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 5:NhAA02C9+pvoE0wETRXQ4ndFHBTMxYK5OPtboHLh0ae+3oes6xmcnj8Ux1Br3VRYte+Hx+y8o5wIUDwDFYVZq/oc0L1LQ8Z9x7hdD6FPrYtRsgtakMR97JPhQjchsNeAdW+nj7VEcyZFMshKRdnr2g==; 24:8Z7mVfTMun3c7bAO+B57LHNC7BoO0DVJC1ifn7J4fDEtQuG3YWlxMuTHL8osVrAvXRryWi/g8UtIFLlUE0kMMVZW8sC7GwdAT6UvVCTwb9I=; 7:uLoDDjDOh4mYTORYHAOBOMbGyzyOXhWCUWqBihaf24JlqmTLineXDmloO+r4eR5Kv4IoXMu//7igDuvi6+2cBm2XRKej0/aw+pjdAviQJfrG47+wf+FFREVlJFAz7f4jUyfVKxmT1m0JGin4i1ZYVXnKvcdU4LxCio8zEXBMMP430RGzRzITmrHBE+Rk017/
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2016 11:41:07.4126 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1626
Archived-At: 
Cc: "Kiran Koushik Agrahara Sreenivasa \(kkoushik\)" , netmod WG 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 11:41:12 -0000

Clyde

Weeell; I still think that we may regret having so many features and so
many possible combinations;  For me, it is not a question of whether
they are there in the wild but whether it is right to have such a
complex model; a bit like ABNF where all sorts of things are possible
but sometimes a short sentence can replace lines of meta-syntactic
language.  As I said before, rough consensus will prevail, whether I am
in the rough or not.

Some minor editorial remarks

The names are still lengthy giving a line length I count as 76 which
exceeds what the RFC Editor normally allows ( 72). e.g., one of many,
(except that my MUA is going to mangle this example)
"         |     |        +--rw severity-operator?   enumeration
{selector-sevop-"

s.1 'draft'

s.3 I think that this example is fine, but would put it in a
non-Normative Appendix with a reference thereto - else people will take
it literally and you will get the same identity appearing many times
(well, that will still occur with an Appendix but at least we can say
you got it wrong).

s.4.1  'Copyright (c) 2015 '

s.4.2  'Copyright (c) 2015 '

s..4.2 The description of log-buffer confuses me.  'The buffer is
circular in nature" so there is only one of them; but it is a list keyed
on 'name' so there are lots of them.  " "This leaf configures the amount
number of log messages that can be stored in the local memory  logging
buffer." so there is only one of them. Or....?

s.5  I think it wrong to put the e-mail addresses in the RFC; editors
yes, acknowledgements no.  If you are going to do that, then take me out
of the list.

s.6
"   prefix: ietf-syslog-types reference: RFC XXXX"
suggest
"   prefix: ietf-syslog-types
    reference: RFC XXXX
"

Tom Petch

----- Original Message -----
From: "Clyde Wildes (cwildes)" 
To: "t.petch" 
Cc: "netmod WG" ; "Kiran Koushik Agrahara Sreenivasa
(kkoushik)" ; "Martin Bjorklund" 
Sent: Monday, April 04, 2016 10:12 PM
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt


> Tom,
>
> I took an action item in the Netmod review of the item-syslog model to
ask you if you are ok with the resulting draft published as a result
Martin's and your comments.
>
> https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-07
>
> Diffs from v6 to v7:
>
>
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-
syslog-model-07.txt
>
> Please comment.
>
> Thanks,
>
> Clyde
>
>
>
> On 4/2/16, 4:54 AM, "t.petch"  wrote:
>
> >---- Original Message -----
> >From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)"
> >
> >Cc: "t.petch" ; 
> >Sent: Monday, March 28, 2016 9:55 PM
> >
> >Hi Andy
> >
> >We did solicit and incorporate feature support from at least 5+
vendors
> >for this model.
> >The model represents a minimal common feature set. They are also
> >hierarchical as Clyde noted below.
> >
> >Thanks
> >Kiran
> >
> >
> >
> >If I remember my mathematical teminology, I prefer a highest common
> >factor, to which augmentations can be applied, whereas others prefer
a
> >lowest common denominator, partitioned by  features.
> >
> >I do not doubt that everything you model is there in implementations
but
> >I prefer a widely, preferably universal, core which can then be added
> >to.
> >
> >It is a judgement call rather than an engineering one, a matter of
> >philosophy even, so I leave it up to rough consensus.
> >
> >Tom Petch
> >
> >From: Andy Bierman >
> >Date: Monday, March 28, 2016 at 3:32 PM
> >To: "Clyde Wildes (cwildes)"
> >>
> >Cc: "t.petch" >,
> >"netmod@ietf.org"
> >>, Kiran Koushik Agrahara
> >Sreenivasa >
> >Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-syslog-model-07.txt
> >
> >On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (cwildes)
> >> wrote:
> >Tom,
> >
> >I understand your concern with the complexity of the model. That
said,
> >as we progressed we encountered some vendors and some IETF RFC
authors
> >who requested that a particular feature of interest be included. We
felt
> >that we had to make features that were not implemented by two or more
> >vendors a YANG feature to gain acceptance. Which is preferred in this
> >case: augmentation to add features; deviation not-supported
statements
> >to remove features; or the use of feature statements? During early
model
> >development our YANG doctor advisor advocated using feature.
> >
> >I read your post on "features - a Cartesian explosion" post. Note
that
> >in the case of the latest ietf-syslog model four of the features are
> >nested such that they are not encountered unless a higher level
feature
> >is enabled.
> >
> >What would your preference be:
> >- remove the feature statements and ask vendors to supply deviation
> >statements for those leaves not implemented
> >- remove all leaves conditioned by feature and ask vendors to supply
> >annotated models with augmentation
> >- leave things as they are
> >
> >It sounds like B would be your preference?
> >
> >
> >I agree with Tom.
> >IMO if the functionality is not supported by at least 2 vendors then
> >remove it from the standard.  The vendor can write a module
> >that augments the  base module.
> >
> >
> >
> >Thanks,
> >
> >Clyde
> >
> >
> >
> >Andy
> >
> >
> >
> >
> >
> >On 3/28/16, 10:09 AM, "t.petch"
> >> wrote:
> >
> >>
> >>----- Original Message -----
> >>From: "Clyde Wildes (cwildes)"
> >>
> >>To: >
> >>Cc: "Martin Bjorklund" >;
> >"t.petch"
> >>>; "Kiran Koushik
> >Agrahara Sreenivasa (kkoushik)"
> >>>
> >>Sent: Sunday, March 20, 2016 7:53 PM
> >>
> >>> Hi,
> >>>
> >>> This revision incorporates feedback from Martin Bjorklunk (19
> >>comments) and Tom Petch (10 comments). Thanks to both of you for
your
> >>valuable feedback!
> >>>
> >>> Regarding Tom's comment - "4.1 What a lot of features?  Again,
makes
> >>things more complex, more error prone - are they all really
needed?":
> >We
> >>started the draft two years ago and it has evolved from feedback
> >>received from all of the folks that appear in the Acknowledgements
> >>section. Please review the current draft where I believe that I
address
> >>all of your comments except possibly this one. The tradeoff is to
leave
> >>the feature specific functionality out of the draft and leave it to
the
> >>implementations to add back through augmentation. That said most of
the
> >>features that are called out have been implemented by at least two
> >>vendors, but not all, leading to the feature designation.
> >>
> >>Clyde
> >>
> >>Yeeees; I did a separate post on the topic thinking that an
implementor
> >>might share my concerns about the large number of possible
variations
> >in
> >>an implementation when there were a large number of features, that
> >>perhaps there should be guidelines about it, but it did not get any
> >>traction.  It is one those issues where I think, in a year or two's
> >>time, others might share my concern, but not yet:-(.
> >>
> >>I don't doubt that the variation exists and needs modelling, just
that
> >>such use of 'features' may have unfortunate consequences - but I
have
> >no
> >>alternative suggestion.
> >>
> >>Tom Petch
> >>
> >>> Thanks,
> >>>
> >>> Clyde


From nobody Wed Apr 27 04:41:17 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19112D106 for ; Wed, 27 Apr 2016 04:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYniFs0osE8u for ; Wed, 27 Apr 2016 04:41:10 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0119.outbound.protection.outlook.com [104.47.2.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE1C12D75B for ; Wed, 27 Apr 2016 04:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gTHdnFd6t9isOg0kjLfzwYVdpLhsig4BMWGWs582ILU=; b=fZ2ZwEJPAE3hXnxVn66eDl0VG8e56Rspz5imrJxqYTkwtITvX/YupeTgiaYFCgdhMjSWUYIvcvXf0SKU7yELlXIKyABWGZ61pa6BSUhLAQKwO8fqjR22KKU8LhwSTnrTUZOaeZ9nzg2Q0bPy7wfL0VY1nS4MM6te778DN3SsY+g=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (81.159.99.181) by HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 27 Apr 2016 11:41:06 +0000
Message-ID: <00a901d1a079$3707cc80$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Kent Watsen , 
References:  
Date: Wed, 27 Apr 2016 10:06:45 +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.159.99.181]
X-ClientProxiedBy: AM3PR04CA0100.eurprd04.prod.outlook.com (10.163.180.154) To HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22)
X-MS-Office365-Filtering-Correlation-Id: f4fe20be-67ff-48d5-b125-08d36e90d23b
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 2:Squ8Q/AaEK8aNgw/HXS1sU8aw7krAIs7GC48Oxf7zrTmVb1g75XpFZLcLz/2GVI3Ui0Zux6WIF4WdvsAS97PakF0lLmlw/CYcz9meISgHoVHrUdxWC0yRqcj2J0xasTOyUkQ3j9gOv2ZIyQjUH1PAvdw2swadfR6b52We8eZvhOAtUfvFn2gOSUrGlxFzgZU; 3:gaekmyCdxh4jpFUgiS81IRyE90wdo9Ug0W1pEK24UEC71wFolTGxylg7v5McRxHCcml0E2Jh8cWIFV9ZdsgVXjVRxQDsPUp7OufZ2RvYfSG2cm4JFVwgCLiUiBd/pc7c; 25:pFRLDwQsFhrSnu1+cqgBq8IaA6pSY8kydaaiYUT5z+gsy/xQzZtFVDIpafLsu/Iy/AAF+Y2+dxLRuT5utdb4EGvQxA4xCAKe8gfWm6PH6t7835mXCCdSKyjGguuzqDytSveAaeoOKig/+TS3LWHZuqlOoXfGTbStGlWC7hA5uc6P6Xe5BFGaPemebcVauthi+qusJ91MIoxj6iJaVHGd4f+CugnxiebJNyQXjMPo2bXMmDpku/WG5JwFRUX97kyh0VTYiRcgy6HjwDOrXQBhuA+/m2JPRtsbeyNi/cJBifSGsddaVTEZR1WDhl58QM7CVKFuCLEoCC9nRQ6H0hXrlQ==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1626;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR07MB1626; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1626; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 4:xwivkO1K0m7sFOcTJM9guullpfE7j5RuLzEniuUedNjES0hFqvkBJ8g1Cib7Ak9uuMYVHsvgxkAmIpOhsuVUsA0VkOkI78ex9FxR7H6ASop78QflFYnCCdSpB6Ju3pDKkqENKis9kkCD6Foc3g3jyzpyCROjG/XlD9FgTe6yMx1VVgqNZu+8xAqHi0Z177mjD3P2flEMiqrruN4YKBebBPJ0xoYKrss7IfUd67PUWxE9EZSmO+c4xSd0xVMpC9cutqEfgoqupmpjZU6dkj6KmsperxphfK/sdhmzAhrID2ndLRfe3BWe8Ja8URfIg0E1L5TyMtYiz3AgE5yeskyTB5sj3MWOukomu8tTL4eM0tjxLpBYSaBzpi4IOYGQRbVhel1sSSwSnUPgHH0NaqVKZ+kNTuOrAmeDW0BFV0nJ2Dh2uxF+C379rqzomySepeVw
X-Forefront-PRVS: 0925081676
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(3846002)(6116002)(92566002)(2870700001)(44716002)(66066001)(116806002)(47776003)(62236002)(50986999)(1096002)(81166005)(19580395003)(2906002)(50466002)(5001770100001)(81686999)(1456003)(9686002)(586003)(107886002)(19580405001)(230783001)(81816999)(86362001)(23676002)(14496001)(44736004)(189998001)(84392002)(1556002)(76176999)(33646002)(77096005)(61296003)(15975445007)(42186005)(5008740100001)(5004730100002)(50226002)(74416001)(7059030)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1626; H:pc6; FPR:; SPF:None; MLV:sfv;  LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNjI2OzIzOkNxNlUvZ2EySTY4STNGSi9vaDljeXVPTHVD?= =?utf-8?B?ZnpIM04ybnRYOXFOenJScWVDcHNzR3NJRVV0VFVUYURua0RiNTAyODVySWhL?= =?utf-8?B?VmNpMWJTM0tVOEdWNTZLQnhpVHoyYVVBaGJpV3Axa1NWdmEzQWFNUS9iODBC?= =?utf-8?B?WmxmTXk4NjNQN3ViSTVkcmdrNnpHTWxtZlpHbnQ2dmhzY2FhV2JxSXJERS9N?= =?utf-8?B?MUZyMmZxeFczMW1vLzd1UFl0cWJUZjdaQThjMDdoWlBhMnVKUDNYQUFvRDdR?= =?utf-8?B?RWJRVHNRbEVsUUt2aFM4OFdVcmdwMTFQU3hUUkxybUl4WTFBbFAyVVd1dUxE?= =?utf-8?B?cyt1Zjh4MmwzbndCVG1KKzhWMkFMUFdCZGZVSGwvcjVuNFBWbXFlNC9NeHlS?= =?utf-8?B?ZWMwUk1CSUdTQjMwMHdqaXBQWjJPcFZNNlAvN0VEUEZMa2NSamduUVZCRm1h?= =?utf-8?B?UXZUL1RFUHN5L0hXeE5sMHE2MitUeVNCUmNuYTArNjV5eUR6SjZ1cDFUeE5N?= =?utf-8?B?VzNVc1YwZzFsRDUzTCsyL3BJMHZWdUVHem1zT0xMbFUrM3crTE5OaGxod2Er?= =?utf-8?B?Z2k0Mmc5TlB2UjVvVCtwcWVHZXRjdWY5NXVINkNpaUtmMVZTOE8rWmppd2V0?= =?utf-8?B?bEpCKytFTHMzTzhGNW9vaTdPZ2p1RTZneVd5QjJZK3cyMFh5NThCTDRTYW8v?= =?utf-8?B?cXVXV0luYytvb1pJcXZoaCtQRG1FdWU4RXhnQ0xtWTRndFR0cko4NnRYeU0y?= =?utf-8?B?Wm9GNndneElsUytpOUNNMmVNaUovempvOGRqdmh3YXZEeXV3d0E5T05sbC9v?= =?utf-8?B?NlN5Vnlob3gxajAvTEZQZE5kY0trYTFXQjFmbkdSQy8yUU5UdjVQQXprWnl1?= =?utf-8?B?TkwvL2p5S1k3Y20welJGTlVlT2xMV2Q1WFBZcy9OTzloL0NpSVJYQkJkMHZn?= =?utf-8?B?QlkySHh6Yk15VTQ5SU1NYWtXSnRlMlU1bFhFL3haZnM0N2tvbXJ6ZXp2ckRr?= =?utf-8?B?dUcvOURuY3VzczErOENaUjQvQUVqUHdyQlc4bGJsVGtKUUxXcEtyM2JhT0xp?= =?utf-8?B?ejJJVG5yOFFsNmppem5ML3lSYmpwb0tNYTZvNUVsWWZmdS9FZXZXUEJOcW5k?= =?utf-8?B?OXI0MXRpN3ZzdmV3Tit0czJEUURTSnp2OWx4b3lwVnBqMWNLSzVLT0NUWXJW?= =?utf-8?B?dEd2VWFFMXQxV3FFcG5oWXFBeEV5U25ETS9QOHVCUGZMai9nd2RIaURXc2V4?= =?utf-8?B?RDJSd0ZiQS9tdzd5SzdxYlJtMXY2NEZxakF0Vkc0NUJaREJhMm1VYy9RZGsw?= =?utf-8?B?RVZDRTFMSFhvTFhPZ1JCSTJWRmI2RHZmNHhPYTdSTGZUOUlBVVhBV25LMWlE?= =?utf-8?B?YnZ0Mlo0OGV4SXhNemVZTnNxYXFZdENqNEMrY0w3bkJtOGZaMEpvVVlEbGxB?= =?utf-8?B?RkNlckpod2plUUlabzgvRFpBbFFNemh2OUJWSVZjTVExUEtjV0VVbFBWYTVv?= =?utf-8?B?NlpzQ0ZWZTZrWUhOZzhUTXVyZE9OU2ZvSkl3TkEzTkNXNGN5RlJJcmpTWFYv?= =?utf-8?B?QmZ2Nk1FZG5FaEVtTnlPZjRhakVsdEtFUVEwU2hScTBjUWFsTmNtdjdqYUZ3?= =?utf-8?B?WXZFS2VXaURuRHIwajVIWWNpaWVVY1hCOGhXWXdnT0RrSWFSc2pEM2JRPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 5:Kn0Sr4ORansYMkZ8rUrgVXJjZoSnh+2zUrd0GkjgZ3WxQAi44UgydciPBs+Yhqd3rkiLklsuNpJ6Gztzn9JlZoPpK31zBqqrJ6e5/CrRAx79jLwuaJnyfQjzyiEcJT1UhD9D8ai2YCNhrOUM/cQ3jw==; 24:7cYhCqdNNbhZwED6Sfpq1TiQDfAESBe+XGP5Y0vHyYGw6QmfsSBfsj1PIvBk5F8bOFI2p92WLeUr/xfyouTdpZGfOUvlQwDK1Q5vazVFuqI=; 7:5dwVb9RmPAd5hv9EQf8sO2EzPebntWLzZ/FbbYp51e8uo7JdNOQVQPOVkrmvjDbbLNaCyeeuJVf0fOSBLbFY+fxiiZcJ/rgKmDheSdwlmpfw7EDECPX30/vAVAl2OHTs5DGH7e+cMAxlWV8cTFH4jJQKjqZb9PkgBMQinDPJRiBfBEEWNYWt6JGB0i74lVdX
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2016 11:41:06.7720 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1626
Archived-At: 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 11:41:13 -0000

Kent

Has there been any progress in the IEEE on their work to produce
Ethernet related models, as was mentioned earlier on in this thread?

Tom Petch


----- Original Message -----
From: "Kent Watsen" 
To: 
Sent: Thursday, April 21, 2016 4:18 PM
Subject: Re: [netmod] call for consensus to adopt
draft-wilton-netmod-intf-ext-yang as NETMOD WG draft


>
> [I wanted to formally close this thread, modeled after Lou's recent
closure of another draft]
>
> This poll is complete and the document is adopted,
>
> Authors,
>
> Please resubmit the draft with the only change being to rename the
draft to draft-ietf-netmod-intf-ext-yang-00
>
> Thank you!
> Kent (and co-chairs)
>
>
>
> From: netmod >
on behalf of Kent Watsen
>
> Date: Monday, February 29, 2016 at 6:07 PM
> To: "netmod@ietf.org"
>
> Subject: Re: [netmod] call for consensus to adopt
draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
>
>
> The chairs were just reviewing notes and realized that this thread
never closed properly.
>
> Juergen has some concerns regarding realistic milestones, that were
never addressed.  Robert, can you please try to address Juergen’s
concerns now?
>
> Also, there were only a two responses before indicating willingness to
review the draft as it progresses (thanks Dan and Martin).  Can others
that support this draft and willing to review this draft say so?
>
> Thanks,
> Netmod Chairs
>
>
> From: netmod >
on behalf of Kent Watsen
>
> Date: Tuesday, December 15, 2015 at 11:48 AM
> To: "netmod@ietf.org"
>
> Subject: [netmod] call for consensus to adopt
draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
>
>
> The minutes for IETF 94 show that there was in-room support for
adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes
also show that this decision would be confirmed on the mailing list,
which I am doing now.
>
> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item
and correspondingly add this to the WG charter as a milestone?  Please
comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG
Chairs will gauge whether or not there is consensus to move forward with
the document.
>
> Thanks,
> Kent
>
>
>


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


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


From nobody Wed Apr 27 04:41:31 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27A12D79A for ; Wed, 27 Apr 2016 04:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.226
X-Spam-Level: 
X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, THIS_AD=1.695] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hILeOs-VJ2nn for ; Wed, 27 Apr 2016 04:41:13 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0133.outbound.protection.outlook.com [104.47.2.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A435712D774 for ; Wed, 27 Apr 2016 04:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8tKXDES6/DadGqBEW1/rSPwsQnzza33am6DY0cNhRfA=; b=OMgIVcQGAwtk1vJ7fF6bGK+fjqjznML/wmHhVJtNAdol65a8cqzp57jc5DV8ObzYYGF+22hwwmY4gZGJd6GzLtxPKo/eIiBXc90b0RLb80+KmBLjfGOSNcbEd8aCMGcWrZ0euoWesqONII5JmXka3hCtwyl+0FousY/blHIip14=
Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (81.159.99.181) by HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22) with Microsoft SMTP Server (TLS) id 15.1.477.8; Wed, 27 Apr 2016 11:41:08 +0000
Message-ID: <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: , Martin Bjorklund 
References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com>
Date: Wed, 27 Apr 2016 12:36:44 +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.159.99.181]
X-ClientProxiedBy: AM3PR04CA0100.eurprd04.prod.outlook.com (10.163.180.154) To HE1PR07MB1626.eurprd07.prod.outlook.com (10.166.124.22)
X-MS-Office365-Filtering-Correlation-Id: b45e47fb-5d2b-4715-a70a-08d36e90d352
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 2:zmVA3jGbzx1YrXk5JbijhnTQBumE6iMCyYQX4xjptdcZAWOu1Q010iiwbLnCg2Emvpelm/6l3aSP3+tUtMCZ1DBQLqKbmQOCabnIgzy5LVM1A7jiN7RY6x7dpZrsZ3lyRQ23SZiDgWGbFp9NQexTveIaoU1A6EDnF5+H2lyRLRVJEM58wfYZ7t2ykMTVdqmz; 3:l0tZxG7z0QCSXxDKZqPciol831sNTuvFoV+eeE8PxNCUgVDadLRQjdjhspAknKySv4r8QFrlvfj6wuB++PnuSmLzdiZz9tG6XE80BaZ5JLHMh4Pr3Wy0Y6lVxtAT/Heu
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1626;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 25:5TatPj4Kln874DZ8c2V7MJz5Ahe5KTCb2zA7fPF/caibZgD/GdifKOvxDvtJDSGLqpshBcMXBMkN8+NtCKeN6It4A3wRtlAm/EGbZAyncaKz0vcMsrrBqN5D+0/7QrhRFH/mods0BFAxivGu63x5TFbfJveJVLwA6pLLNYwcL8udIkJKDVt++htYlDQLhn6mHYEIXE2tvF5nUOAw/v6jxVyZCG6OudNllRJ4N2YLKS4AbRH0RZY1ty3BIYNbUopeeQTxPvn/wh/GGsL+RmAzKZoaSi7SMKZ84RKOaUMKTifcG5xsVhfDhZANaxuD/wL/x3E2esqthBo4FLUz9C4ELD/P1qsY21GHK0RpEmTrCiEhvKuAjU0+/Mlz52pHiPknNCvf68eX8OaOvdqFZ9/4t/VT+pBa+ULB7KeSpC8eiuosoKG1OohLMoeUUy4ROv6RpoXDFCPpvOAqtNkV6txdP00kWcPSzXW4bXnt+ock7mQhs7Tj8pAmyue/jgXmc/r42IdaJnnTzEGoXjgkOjxPSpYyw/Xf50A8GyZ5weieQd3mb0ZSfs7mEF0bV+YyQvTZPgzbWpzn8mD9x9mbQfd4CqX9IsmTrwpY4EnytfMF4d50elGK9dhUc1/3s6Il49sQBxeKf9pVKKawN0pbFT41TEhcoMQIW940Ru3g+OtShTKeuZS51q9NXxf/AVDP0oauBRU9jOC2VEOlMXGypPh1eqxZ1A3dA47XTN+9oKx8vMvo/v/3R2e7i2JFtVt404dDsXeYPegjEtPPq6OAsiyJYg==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR07MB1626; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1626; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 4:Yh9PkHgrnQ+RvU1JfBmvd/HM0TQc0ARBDgqS2tG383N5nLd2HTBVx0TUYcyRwIOV0/iK+sNPL9fcwLf9s5nYaside7YIpLhW6UcTvV5kJdFvaTT6d3Y3PoaycNWbdOM3mAIeFk8IrZEOPqUzBrfgTVgP+WIACQy5kf2pAf4dCbE97QnKzEptBTB9yyrLEae3lzH8luAdByokLzBFgR3bEIxKxtmhvQnKhGWtU+G2e+a6Q0kOj0mEtjztjMwFWMEGva6GiDeL4OxqjbV9q03j7kArBH4dl5eMykwMfuSvrVn+mBG2xvOSKZnqNXrojoBYNjrx3nTiz28Mic0ezCIapQYjXogXAV1MxN2dWBvetmLAoZ5Ckhq8J1niu0gBFaO6lYZ00YDs31G8dY2+YczS0sykhWXfpwsy3kiC3Jx1yRvLnqhhvdVphhLKbAFeTDan
X-Forefront-PRVS: 0925081676
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(51444003)(13464003)(24454002)(377454003)(3846002)(561944003)(6116002)(92566002)(44716002)(66066001)(116806002)(47776003)(62236002)(50986999)(1096002)(81166005)(19580395003)(23756003)(2906002)(50466002)(5001770100001)(81686999)(1456003)(9686002)(586003)(19580405001)(230783001)(81816999)(93886004)(86362001)(14496001)(44736004)(4326007)(189998001)(230700001)(84392002)(1556002)(76176999)(33646002)(77096005)(61296003)(15975445007)(229853001)(42186005)(5008740100001)(5004730100002)(50226002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1626; H:pc6; FPR:; SPF:None; MLV:sfv;  LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1626; 23:HHJfDgdfhQx4w8Lfj9u/B0WUDq+QQLpfM9LY6kh?= =?iso-8859-1?Q?VRLdTium3CPbZW/aVYuOTyh4j3UuFCPZZMyN26nIep59DtdWw/fwltSw0T?= =?iso-8859-1?Q?IeW1+6/eT3MQaEwpwmLRNRFOg/vTcU/ymA1ebXC0IBX8H+yUhcUjEBBk9n?= =?iso-8859-1?Q?gr3dO0MGd+ABn9C6JAC9LOrUe1aksk0jo9shaQTq9vE5wHBIQbCL6A/Gl/?= =?iso-8859-1?Q?BV1ZslKXw5Di8azEtsDBsCOMEOT2TpsDBaS/+7SdwXCEMqR+a3jdUULWLS?= =?iso-8859-1?Q?VCLL9tuzdBA3qVHP8WSgu0VlRRgF+2J9squ/TU3pMbvSEbMxQmNuIE/gXd?= =?iso-8859-1?Q?fx7k2/7H4l1+/ItmnPigi+Y/yBCMj+lq7lMV6/tHB7cZZ9GTuwOWxuB+KH?= =?iso-8859-1?Q?bmirKrcnzIr1XLj3phu3VsnKq/QxGq15auJxWd/qgxQTR1Js42ld6BajUL?= =?iso-8859-1?Q?w4YvsVFEBjh8olQpzeRb9Vqegh84fQUWYrPPVaNatP3LW1ydsSPf2C5Mpz?= =?iso-8859-1?Q?kF6zAagW2lEFkniRhz58DPy9dbZbVLAou7lPAGKxb6p997+nVHvR8nTr7K?= =?iso-8859-1?Q?IB+77zVaQwlLUr8GXqvpz+6y6YmcUWOOF16fDqk3wZwSL6oVR5zbmOU7pE?= =?iso-8859-1?Q?kOrSEua6ZLMa178sYqd1Q+YlMTCAatLZYUtrCBy55EEQuNx80r84KoNRvz?= =?iso-8859-1?Q?0IcMGrEUZwDVIQuqkH3QGjlpCAI9Evqtllrw0fM3UlwPzPt1ZrNmVrH/tU?= =?iso-8859-1?Q?DrJJABAjZizDp5PgeTb0keJvPtra2bccPwb8DMWGxM8qejQb3HnPewFAgw?= =?iso-8859-1?Q?+Rado2VjZQYhgKjs2D43WaBOt30nNrQqomWptuB6KfaweVzSFJoo7Sn4Ea?= =?iso-8859-1?Q?ddin/0B5a67fa5kgo8DgYbWUj3ROywPUP3ZlTp8htq/3rJ9w5drVe3rw03?= =?iso-8859-1?Q?3CDRc3S8ALsdsdMH4WLSNkO/gmHEvFPk+IZMtOx4H/EjBI6N+B1LXlm4PQ?= =?iso-8859-1?Q?mEKBb4at9o+y2B8p05IZbCJxL9s+2z/PAgC0wAw67u1lxyS7tOggmNYR0n?= =?iso-8859-1?Q?HkJxrs8OQXVMccSTzEm8KYWKDq27BySP1DEdYs7e5PjXVSOoeiM3aya1Ew?= =?iso-8859-1?Q?WcAatixfIo7J+TiBj/0ZPZmP0qNf4Pk378OfL+LUTmx834YVQmipLLTgGd?= =?iso-8859-1?Q?Juhx2b1l9HKz+wn2hXd5J8jHN/TMaOOLRWcK5Fxi5xD5Eafyohyev4dbE2?= =?iso-8859-1?Q?czP6lzpUeI7rQhusRg32TD5NUAzKwG9YjdxcGC/szJLk62HUaV+RmGejd2?= =?iso-8859-1?Q?lezapVagGC+gnKpdXaW0CijKbQ2cyTdno/ISWGdhqgefRd/a1E8lKiyep4?= =?iso-8859-1?Q?I4V3zxWk=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1626; 5:ICmzFvK2sboUdOm54dAQBp5bxTOuJo5yM5+vp97fZJ7eSaM0rn56dfU5v7uWCbJBB4rMEBj/eaLxxE5tjSNpusznUF6Js3FcA4d53KzUZ3rQ7NwSL6zgvwbx5e4qmTkiepTCmygbAyCgXYsrvn0ufg==; 24:KZqnwznTP0rAez+spjqVAykYa9QPZHGIgbllT3fSLSwj3e/UYmAXvPSgK46HKHT/GpCETB9Ctk3nIWcblPs7nHbG6pjYpvuj7yQEl0v/4Do=; 7:rQf462jIveVSU4RQmzba5RreeLqTOYSsRE4rv/COJIGUnX9NF5C33k0JMIRIpeIEiS4d6E+9rg00uLM37Y0wsJZ5eUuH/Pt+gcK/bhiUixEOUHTD01Qm3oN851hg+WMi4RtQxPZwz3Pnns6sZ/G9dANRHvV1nxi2oQ1CNM6Fa5THACJUGbhykuopCyxQyBam
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2016 11:41:08.4752 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1626
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 11:41:16 -0000

I see that the definition of 'datastores' has cropped up in this AD
Review, as in the e-mail below.

Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last
Call and redefines, or recreates, the term for us

   A YANG datastore is a conceptual datastore that contains hierarchical
   data defined in YANG data models.  It is what is referred in existing
   RFCs as "NETCONF datastore".  However, as the same datastore is no
   longer tied to NETCONF as a specific transport, the term "YANG
   datastore" is deemed more appropriate.

I think that the concept of datastore has been troublesome to those
coming to YANG lately, such as openconfig and I2RS, and that this will
just muddy the waters more, especially as it is tucked away in an
Informational document.  If I2RS want to define such terminology, then
it should be in the I2RS Architecture or some such; but IMHO they should
not be defining YANG datastores at all.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Thursday, April 21, 2016 2:58 PM
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)


> Benoit Claise  wrote:
> > Hi Martin,
> >
> > Thanks for engaging quickly.
> > [I removed the resolved entries]
> > > Hi Benoit,
> > >
> > > Benoit Claise  wrote:
> > >> Dear all,
> > >>
> > >> Here is part 1 of my AD review.
> > >>
> > >> I found this useful:
> > >>
http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/
rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.
txt
> > >>
> > >> - Do we want to mention RESTCONF in the abstract? From the new
charter:
> > >>
> > >>     The NETMOD working group has defined the data modeling
language
> > >>     YANG, which can be used to specify network management data
models
> > >>     that are transported over such protocols as NETCONF and
RESTCONF.
> > >>
> > >> OLD:
> > >>
> > >>     YANG is a data modeling language used to model configuration
data,
> > >>     state data, remote procedure calls, and notifications for
network
> > >>     management protocols like the Network Configuration Protocol
> > >>     (NETCONF).
> > >>
> > >> NEW:
> > >>
> > >>     YANG is a data modeling language used to model configuration
data,
> > >>     state data, remote procedure calls, and notifications for
network
> > >>     management protocols transported over such protocols as
Network
> > >>     Configuration Protocol (NETCONF) and RESTCONF. This document
specifies
> > >>     the YANG mappings to NETCONF.
> > > The first paragraph in the introduction mentions other protocols;
> > > RESCTONF and CoMI.  My personal opinion is that this is
sufficient,
> > > but I'd like to hear what others think.
> > The current abstract doesn't even mention the mapping to NETCONF.
>
> See Juergen's proposal, I think that one is better.
>
> > >> - Section 1.1
> > >> Since this document introduces the NETCONF mapping, the protocol
> > >> change must be included in section 1.1
> > >> Example: no NETCONF capability exchange in YANG 1.1, we use
> > >> exclusively the YANG library
> > >> Any other ones?
> > And this one?
>
> NEW:
>
>    The following changes are done to the NETCONF mapping:
>
>    o  A server advertises support for YANG 1.1 modules by using ietf-
>       yang-library [I-D.ietf-netconf-yang-library] instead of listing
>       them as capabilities in the  message.
>
> > >> - Terminology:
> > >>   The following terms are defined in [RFC6241
> > >>   ]:
> > >>
> > >>     ...
> > >>
> > >>     o  configuration datastore: a configuration datastore is an
> > >>        instantiated data tree with configuration data
> > >>
> > >>     o  datastore: an instantiated data tree
> > >>
> > >> RFC6241 has different definition for "configuration datastore"
and
> > >> "datastore".
> > >> I would just provide the pointer to the RFC 6241 definitions.
> > >> If you intend to provide an adapted definition for the YANG
mappings,
> > >> then you should say so.
> > > How about:
> > >
> > > OLD:
> > >
> > >     o  configuration datastore: a configuration datastore is an
> > >        instantiated data tree with configuration data
> > >
> > >     o  datastore: an instantiated data tree
> > >
> > > NEW:
> > >
> > >     o  configuration datastore: When modelled with YANG, a
configuration
> > >        datastore is an instantiated data tree with configuration
data
> > >
> > >     o  datastore: When modelled with YANG, an instantiated data
tree
> > >
> > This issue is with "The following terms are defined in [RFC6241]",
but
> > you re-define those terms.
> > So give a warning about the redefinition to the readers.
>
> Yes, that's what my proposed text does.  It says that "datastore" is
> defined in 6241, and when YANG is used, it means the instantiated data
> tree.
>
> > >> - Section 4.1
> > >>
> > >>     YANG models can describe constraints to be enforced on the
data,
> > >>     restricting the appearance or value of nodes based on the
presence or
> > >>     value of other nodes in the hierarchy.
> > >>
> > >> I was looking for an example of appearance.
> > >> NEW?
> > >>     YANG models can describe constraints to be enforced on the
data,
> > >>     restricting the appearance (for example, with the "when"
statement)
> > >>     or value of nodes based on the presence or value of other
nodes in
> > >>     the hierarchy.
> > > This is very early in the document, and the text tries to give a
very
> > > high level function overview.  I am not sure that mentioning
"when" at
> > > this time actually helps a first time reader.
> > The first time I read this, I was wondering how YANG data models can
> > describe constraints on HOW data appear, while you wanted to express
> > WHETHER a data appear. Maybe "when" is not the best way to help the
> > first time user, but something is needed.
>
> How about "restricting the presence or value of nodes"?
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Apr 27 05:07:00 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECF412D7D9 for ; Wed, 27 Apr 2016 05:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.518
X-Spam-Level: 
X-Spam-Status: No, score=-15.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUADTKmBk4OX for ; Wed, 27 Apr 2016 05:06:57 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05BE12D7E4 for ; Wed, 27 Apr 2016 05:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2899; q=dns/txt; s=iport; t=1461758817; x=1462968417; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=neFRBkbMUSjbQBG2Ot3HVzvTeCoJD15Ju9k7Z8MY+RI=; b=U9NPotiWRtq5NrBMjc/bbHhd9U1JQkHeG78FCwjBprhcHnOtpEOSS92c UnY/+IQkHG7AoJEjUaALMojxzS7BTzi/0rjlYnaOEdI7C07+mNazW4Soz G3L28hKXwy3HTfHfghzd6BXqT8kU8mrRqs9OmKCExza4KEFZAGm9nJRSE Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDWqSBX/xbLJq1ehAt9uWsBDYF1H?= =?us-ascii?q?oVxAoFzFAEBAQEBAQFlJ4RCAQEEOEEQCw4KCSUPAkYGDQYCAQGIJg7DbwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBEgSGIYRLihMBBJgQhXyIG4k6hVePMB4BAUKDbTowi?= =?us-ascii?q?S4BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="676944090"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 12:06:53 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3RC6rMq008917; Wed, 27 Apr 2016 12:06:53 GMT
To: Martin Bjorklund 
References: <571A1874.6070306@cisco.com> <20160427.095511.62299994686131994.mbj@tail-f.com> <57208E93.202@cisco.com> <20160427.124324.1763217338408362847.mbj@tail-f.com>
From: Benoit Claise 
Message-ID: <5720AB5D.80306@cisco.com>
Date: Wed, 27 Apr 2016 14:06:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160427.124324.1763217338408362847.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] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 12:06:59 -0000

On 4/27/2016 12:43 PM, Martin Bjorklund wrote:
> Benoit Claise  wrote:
>> Hi Martin,
>>> Benoit Claise  wrote:
>>>> Hi Martin,
>>>>
>>>> Removed some extra ones on which we agree.
>>>> See in line.
>>>>>>>> - Terminology:
>>>>>>>>      The following terms are defined in [RFC6241
>>>>>>>>      ]:
>>>>>>>>
>>>>>>>>        ...
>>>>>>>>
>>>>>>>>        o  configuration datastore: a configuration datastore is an
>>>>>>>>           instantiated data tree with configuration data
>>>>>>>>
>>>>>>>>        o  datastore: an instantiated data tree
>>>>>>>>
>>>>>>>> RFC6241 has different definition for "configuration datastore" and
>>>>>>>> "datastore".
>>>>>>>> I would just provide the pointer to the RFC 6241 definitions.
>>>>>>>> If you intend to provide an adapted definition for the YANG mappings,
>>>>>>>> then you should say so.
>>>>>>> How about:
>>>>>>>
>>>>>>> OLD:
>>>>>>>
>>>>>>>        o  configuration datastore: a configuration datastore is an
>>>>>>>           instantiated data tree with configuration data
>>>>>>>
>>>>>>>        o  datastore: an instantiated data tree
>>>>>>>
>>>>>>> NEW:
>>>>>>>
>>>>>>>        o configuration datastore: When modelled with YANG, a configuration
>>>>>>>           datastore is an instantiated data tree with configuration data
>>>>>>>
>>>>>>>        o  datastore: When modelled with YANG, an instantiated data tree
>>>>>>>
>>>>>> This issue is with "The following terms are defined in [RFC6241]", but
>>>>>> you re-define those terms.
>>> I don't think it is correct to say that we "re-define" these terms.
>>> It sounds like we give the terms a different meaning.
>> Playing with words? :-)
>>>    I agree that
>>> the OLD text gave that impression, but I think the NEW proposed text
>>> fixes this.
>> This does not work.
>>
>> Reading the terminology ...
>>
>>         The following terms are defined in [RFC6241
>>         ]:
>>
>>       o  configuration datastore: ...
>>
>>       o  datastore: ...
>>
>> ... I will not even bother reading the definitions, because I know
>> them from 6241.
>> Doing this, I will not spot the subtle "different meaning" you
>> inserted in the definitions.
> Ok, how about moving the specialized-meaning-text to its own paragraph:
>
>
>    The following terms are defined in [RFC6241]:
>
>     o  configuration data
>
>     o  configuration datastore
>
>     o  datastore
>
>     o  running configuration datastore
>
>     o  state data
>
>     When modelled with YANG, a datastore is realized as an instantiated
>     data tree.
>
>     When modelled with YANG, a configuration datastore is realized as an
>     instantiated data tree with configuration data.
That works.

Regards, Benoit
>
>
> /martin
> .
>


From nobody Wed Apr 27 05:15:45 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5752F12D7F8 for ; Wed, 27 Apr 2016 05:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn4O8_VfBKPs for ; Wed, 27 Apr 2016 05:15: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 135E712D7E6 for ; Wed, 27 Apr 2016 05:15: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 C962D8F9; Wed, 27 Apr 2016 14:15: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 KbslY_ZmkZvV; Wed, 27 Apr 2016 14:15: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; Wed, 27 Apr 2016 14:15:39 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 337D020047; Wed, 27 Apr 2016 14:15:39 +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 Nt_aIAsZ7D1p; Wed, 27 Apr 2016 14:15:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D2D020046; Wed, 27 Apr 2016 14:15:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8B9243AB8675; Wed, 27 Apr 2016 14:15:33 +0200 (CEST)
Date: Wed, 27 Apr 2016 14:15:33 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Message-ID: <20160427121533.GA21846@elstar.local>
Mail-Followup-To: "t.petch" , bclaise@cisco.com, Martin Bjorklund , netmod@ietf.org
References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Apr 2016 12:15:44 -0000

Tom,

please send a comment to i2rs saying that they should import terms
rather than trying to (re-)define them. As long as people keep
(re-)defining terms, we will have confusion and in this specific case
I think it is the NETMOD or NETCONF WGs that should define the terms,
not any other WGs.

/js

On Wed, Apr 27, 2016 at 12:36:44PM +0100, t.petch wrote:
> I see that the definition of 'datastores' has cropped up in this AD
> Review, as in the e-mail below.
> 
> Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last
> Call and redefines, or recreates, the term for us
> 
>    A YANG datastore is a conceptual datastore that contains hierarchical
>    data defined in YANG data models.  It is what is referred in existing
>    RFCs as "NETCONF datastore".  However, as the same datastore is no
>    longer tied to NETCONF as a specific transport, the term "YANG
>    datastore" is deemed more appropriate.
> 
> I think that the concept of datastore has been troublesome to those
> coming to YANG lately, such as openconfig and I2RS, and that this will
> just muddy the waters more, especially as it is tucked away in an
> Informational document.  If I2RS want to define such terminology, then
> it should be in the I2RS Architecture or some such; but IMHO they should
> not be defining YANG datastores at all.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Cc: 
> Sent: Thursday, April 21, 2016 2:58 PM
> Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
> 
> 
> > Benoit Claise  wrote:
> > > Hi Martin,
> > >
> > > Thanks for engaging quickly.
> > > [I removed the resolved entries]
> > > > Hi Benoit,
> > > >
> > > > Benoit Claise  wrote:
> > > >> Dear all,
> > > >>
> > > >> Here is part 1 of my AD review.
> > > >>
> > > >> I found this useful:
> > > >>
> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/
> rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.
> txt
> > > >>
> > > >> - Do we want to mention RESTCONF in the abstract? From the new
> charter:
> > > >>
> > > >>     The NETMOD working group has defined the data modeling
> language
> > > >>     YANG, which can be used to specify network management data
> models
> > > >>     that are transported over such protocols as NETCONF and
> RESTCONF.
> > > >>
> > > >> OLD:
> > > >>
> > > >>     YANG is a data modeling language used to model configuration
> data,
> > > >>     state data, remote procedure calls, and notifications for
> network
> > > >>     management protocols like the Network Configuration Protocol
> > > >>     (NETCONF).
> > > >>
> > > >> NEW:
> > > >>
> > > >>     YANG is a data modeling language used to model configuration
> data,
> > > >>     state data, remote procedure calls, and notifications for
> network
> > > >>     management protocols transported over such protocols as
> Network
> > > >>     Configuration Protocol (NETCONF) and RESTCONF. This document
> specifies
> > > >>     the YANG mappings to NETCONF.
> > > > The first paragraph in the introduction mentions other protocols;
> > > > RESCTONF and CoMI.  My personal opinion is that this is
> sufficient,
> > > > but I'd like to hear what others think.
> > > The current abstract doesn't even mention the mapping to NETCONF.
> >
> > See Juergen's proposal, I think that one is better.
> >
> > > >> - Section 1.1
> > > >> Since this document introduces the NETCONF mapping, the protocol
> > > >> change must be included in section 1.1
> > > >> Example: no NETCONF capability exchange in YANG 1.1, we use
> > > >> exclusively the YANG library
> > > >> Any other ones?
> > > And this one?
> >
> > NEW:
> >
> >    The following changes are done to the NETCONF mapping:
> >
> >    o  A server advertises support for YANG 1.1 modules by using ietf-
> >       yang-library [I-D.ietf-netconf-yang-library] instead of listing
> >       them as capabilities in the  message.
> >
> > > >> - Terminology:
> > > >>   The following terms are defined in [RFC6241
> > > >>   ]:
> > > >>
> > > >>     ...
> > > >>
> > > >>     o  configuration datastore: a configuration datastore is an
> > > >>        instantiated data tree with configuration data
> > > >>
> > > >>     o  datastore: an instantiated data tree
> > > >>
> > > >> RFC6241 has different definition for "configuration datastore"
> and
> > > >> "datastore".
> > > >> I would just provide the pointer to the RFC 6241 definitions.
> > > >> If you intend to provide an adapted definition for the YANG
> mappings,
> > > >> then you should say so.
> > > > How about:
> > > >
> > > > OLD:
> > > >
> > > >     o  configuration datastore: a configuration datastore is an
> > > >        instantiated data tree with configuration data
> > > >
> > > >     o  datastore: an instantiated data tree
> > > >
> > > > NEW:
> > > >
> > > >     o  configuration datastore: When modelled with YANG, a
> configuration
> > > >        datastore is an instantiated data tree with configuration
> data
> > > >
> > > >     o  datastore: When modelled with YANG, an instantiated data
> tree
> > > >
> > > This issue is with "The following terms are defined in [RFC6241]",
> but
> > > you re-define those terms.
> > > So give a warning about the redefinition to the readers.
> >
> > Yes, that's what my proposed text does.  It says that "datastore" is
> > defined in 6241, and when YANG is used, it means the instantiated data
> > tree.
> >
> > > >> - Section 4.1
> > > >>
> > > >>     YANG models can describe constraints to be enforced on the
> data,
> > > >>     restricting the appearance or value of nodes based on the
> presence or
> > > >>     value of other nodes in the hierarchy.
> > > >>
> > > >> I was looking for an example of appearance.
> > > >> NEW?
> > > >>     YANG models can describe constraints to be enforced on the
> data,
> > > >>     restricting the appearance (for example, with the "when"
> statement)
> > > >>     or value of nodes based on the presence or value of other
> nodes in
> > > >>     the hierarchy.
> > > > This is very early in the document, and the text tries to give a
> very
> > > > high level function overview.  I am not sure that mentioning
> "when" at
> > > > this time actually helps a first time reader.
> > > The first time I read this, I was wondering how YANG data models can
> > > describe constraints on HOW data appear, while you wanted to express
> > > WHETHER a data appear. Maybe "when" is not the best way to help the
> > > first time user, but something is needed.
> >
> > How about "restricting the presence or value of nodes"?
> >
> >
> > /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

-- 
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 Apr 27 05:20:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FBD12D5AC for ; Wed, 27 Apr 2016 05:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level: 
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQZ66MKUzRnh for ; Wed, 27 Apr 2016 05:20:22 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA37812D0DF for ; Wed, 27 Apr 2016 05:20:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6519; q=dns/txt; s=iport; t=1461759621; x=1462969221; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=dlnDpnhtV8Jrv6gZdEoH28/mWsFSnILdn72EJmS21ak=; b=lvFla//N0KW+HIbdRZDnH3XpgY1cMjJ6wXS4NP5QFnusJYH1PDObSrri ozd1tml7E9M/V+UcoSoFxmdaw7hAZNyEmh2zV08ZDiqX7rPa3CC1M0xyO r2S5EhxoUWehsF2bZxrVO47eFL0I2rHx5E27c9DaFsk1htMdOK/pP8saZ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQB4rSBX/xbLJq1ehAt9uWsBDYF1F?= =?us-ascii?q?w2FIUoCgXEUAQEBAQEBAWUnhEEBAQEEAQEBNTYKAQwECxEBAwEBAQkWDwkDAgE?= =?us-ascii?q?CARUiBggGAQwGAgEBBYghDsN7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhg0mBA?= =?us-ascii?q?oQnhWwBBJgQhXyIG4FnTocFI4U0h2WHSx4BAUKDbTowAQEBiSsBAQE?=
X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="634356629"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 12:20:19 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3RCKJxj011308; Wed, 27 Apr 2016 12:20:19 GMT
To: "t.petch" , Martin Bjorklund 
References: <571652B4.6000005@cisco.com> <20160421.122409.329112641806495413.mbj@tail-f.com> <5718D6F1.5040902@cisco.com> <20160421.155857.43464387853940362.mbj@tail-f.com> <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net>
From: Benoit Claise 
Message-ID: <5720AE83.4000508@cisco.com>
Date: Wed, 27 Apr 2016 14:20:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <00ab01d1a079$3812d3e0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 12:20:24 -0000

Tom,
> I see that the definition of 'datastores' has cropped up in this AD
> Review, as in the e-mail below.
>
> Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last
> Call and redefines, or recreates, the term for us
>
>     A YANG datastore is a conceptual datastore that contains hierarchical
>     data defined in YANG data models.  It is what is referred in existing
>     RFCs as "NETCONF datastore".  However, as the same datastore is no
>     longer tied to NETCONF as a specific transport, the term "YANG
>     datastore" is deemed more appropriate.
>
> I think that the concept of datastore has been troublesome to those
> coming to YANG lately, such as openconfig and I2RS, and that this will
> just muddy the waters more, especially as it is tucked away in an
> Informational document.  If I2RS want to define such terminology, then
> it should be in the I2RS Architecture or some such; but IMHO they should
> not be defining YANG datastores at all.
Agreed.
Timely review as draft-ietf-i2rs-pub-sub-requirements is on the next 
IESG telechat.

Regards, Benoit
>
> Tom Petch
>
> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Cc: 
> Sent: Thursday, April 21, 2016 2:58 PM
> Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)
>
>
>> Benoit Claise  wrote:
>>> Hi Martin,
>>>
>>> Thanks for engaging quickly.
>>> [I removed the resolved entries]
>>>> Hi Benoit,
>>>>
>>>> Benoit Claise  wrote:
>>>>> Dear all,
>>>>>
>>>>> Here is part 1 of my AD review.
>>>>>
>>>>> I found this useful:
>>>>>
> http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/
> rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.
> txt
>>>>> - Do we want to mention RESTCONF in the abstract? From the new
> charter:
>>>>>      The NETMOD working group has defined the data modeling
> language
>>>>>      YANG, which can be used to specify network management data
> models
>>>>>      that are transported over such protocols as NETCONF and
> RESTCONF.
>>>>> OLD:
>>>>>
>>>>>      YANG is a data modeling language used to model configuration
> data,
>>>>>      state data, remote procedure calls, and notifications for
> network
>>>>>      management protocols like the Network Configuration Protocol
>>>>>      (NETCONF).
>>>>>
>>>>> NEW:
>>>>>
>>>>>      YANG is a data modeling language used to model configuration
> data,
>>>>>      state data, remote procedure calls, and notifications for
> network
>>>>>      management protocols transported over such protocols as
> Network
>>>>>      Configuration Protocol (NETCONF) and RESTCONF. This document
> specifies
>>>>>      the YANG mappings to NETCONF.
>>>> The first paragraph in the introduction mentions other protocols;
>>>> RESCTONF and CoMI.  My personal opinion is that this is
> sufficient,
>>>> but I'd like to hear what others think.
>>> The current abstract doesn't even mention the mapping to NETCONF.
>> See Juergen's proposal, I think that one is better.
>>
>>>>> - Section 1.1
>>>>> Since this document introduces the NETCONF mapping, the protocol
>>>>> change must be included in section 1.1
>>>>> Example: no NETCONF capability exchange in YANG 1.1, we use
>>>>> exclusively the YANG library
>>>>> Any other ones?
>>> And this one?
>> NEW:
>>
>>     The following changes are done to the NETCONF mapping:
>>
>>     o  A server advertises support for YANG 1.1 modules by using ietf-
>>        yang-library [I-D.ietf-netconf-yang-library] instead of listing
>>        them as capabilities in the  message.
>>
>>>>> - Terminology:
>>>>>    The following terms are defined in [RFC6241
>>>>>    ]:
>>>>>
>>>>>      ...
>>>>>
>>>>>      o  configuration datastore: a configuration datastore is an
>>>>>         instantiated data tree with configuration data
>>>>>
>>>>>      o  datastore: an instantiated data tree
>>>>>
>>>>> RFC6241 has different definition for "configuration datastore"
> and
>>>>> "datastore".
>>>>> I would just provide the pointer to the RFC 6241 definitions.
>>>>> If you intend to provide an adapted definition for the YANG
> mappings,
>>>>> then you should say so.
>>>> How about:
>>>>
>>>> OLD:
>>>>
>>>>      o  configuration datastore: a configuration datastore is an
>>>>         instantiated data tree with configuration data
>>>>
>>>>      o  datastore: an instantiated data tree
>>>>
>>>> NEW:
>>>>
>>>>      o  configuration datastore: When modelled with YANG, a
> configuration
>>>>         datastore is an instantiated data tree with configuration
> data
>>>>      o  datastore: When modelled with YANG, an instantiated data
> tree
>>> This issue is with "The following terms are defined in [RFC6241]",
> but
>>> you re-define those terms.
>>> So give a warning about the redefinition to the readers.
>> Yes, that's what my proposed text does.  It says that "datastore" is
>> defined in 6241, and when YANG is used, it means the instantiated data
>> tree.
>>
>>>>> - Section 4.1
>>>>>
>>>>>      YANG models can describe constraints to be enforced on the
> data,
>>>>>      restricting the appearance or value of nodes based on the
> presence or
>>>>>      value of other nodes in the hierarchy.
>>>>>
>>>>> I was looking for an example of appearance.
>>>>> NEW?
>>>>>      YANG models can describe constraints to be enforced on the
> data,
>>>>>      restricting the appearance (for example, with the "when"
> statement)
>>>>>      or value of nodes based on the presence or value of other
> nodes in
>>>>>      the hierarchy.
>>>> This is very early in the document, and the text tries to give a
> very
>>>> high level function overview.  I am not sure that mentioning
> "when" at
>>>> this time actually helps a first time reader.
>>> The first time I read this, I was wondering how YANG data models can
>>> describe constraints on HOW data appear, while you wanted to express
>>> WHETHER a data appear. Maybe "when" is not the best way to help the
>>> first time user, but something is needed.
>> How about "restricting the presence or value of nodes"?
>>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Apr 27 05:53:00 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D612D14A; Wed, 27 Apr 2016 05:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAKAAlwQM7JG; Wed, 27 Apr 2016 05:52: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 CB34A12D10B; Wed, 27 Apr 2016 05:52:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8C18173D; Wed, 27 Apr 2016 14:52:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SUmc_Me-I6Kf; Wed, 27 Apr 2016 14:52: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, 27 Apr 2016 14:52:55 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDD7020047; Wed, 27 Apr 2016 14:52:55 +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 E8pd-zI1Xocz; Wed, 27 Apr 2016 14:52:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 666D620046; Wed, 27 Apr 2016 14:52:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5E18B3AB8777; Wed, 27 Apr 2016 14:52:53 +0200 (CEST)
Date: Wed, 27 Apr 2016 14:52:53 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160427125253.GA21946@elstar.local>
Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
References: <571F3E77.5030002@cisco.com> <57208C2A.8020605@cisco.com> <20160427.123800.635890758896303567.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160427.123800.635890758896303567.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 2)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Apr 2016 12:53:00 -0000

On Wed, Apr 27, 2016 at 12:38:00PM +0200, Martin Bjorklund wrote:

> > And also:
> > OLD:
> >    o  If a request modifies a configuration data node such that any
> >       node's "when" expression becomes false, then the node with the
> >       "when" expression is deleted by the server.
> > 
> > NEW:
> >    o  If a request modifies a configuration data node such that any
> >       node's "when" expression becomes false, then the node with the
> >       "when" expression_in the data tree_  is deleted by the server.
> 
> Ok.

It is actually "the node in the data tree that corresponds to the
schema node with a when expression" since the when expression is a
property of the schema tree node, not a property of a data tree
node. Not sure this helps with readability though.

/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 Apr 27 05:54:13 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9EB12D14F for ; Wed, 27 Apr 2016 05:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level: 
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5AbpZo2Gj_o for ; Wed, 27 Apr 2016 05:54:09 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183DB12D10B for ; Wed, 27 Apr 2016 05:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3408; q=dns/txt; s=iport; t=1461761649; x=1462971249; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=KT83VsM3DYCYGw5gAPsmOEoj6Jqr+V+ByC/l90KWVhA=; b=DCGWNPWq8vJJAQkKBA3RSl7GDmlLoAO5zEDmaXFP+eh/Ivd/mi6AzTWO 6WiVEw7J73oigQiyEyACIVOa2t3EScK0t/3GVUL7tkjoEXlueLxF+p86O 2KPluObAoQCVduVXhvq609pwoPra96sCMHk1+aVKXnAajniVWNLkVMG1l c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAAEtiBX/xbLJq1ehAsrUrtuFwuFI?= =?us-ascii?q?0oCgXgBAQEBAQFmJ4RBAQEBBAEBARoGDwEFNhcECxEDAQEBAQICIwMCAicfCQg?= =?us-ascii?q?GAQwGAgEBiCYOslGRLwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEfIUlgXWCVoc9g?= =?us-ascii?q?lYFh3SQHI4XgWeETYMGhVePMGKCNoE2OzCJLgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="637198293"
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/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 12:54:06 +0000
Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3RCs6fg011168; Wed, 27 Apr 2016 12:54:06 GMT
To: "t.petch" , Kent Watsen , netmod@ietf.org
References:   <00a901d1a079$3707cc80$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: 
Date: Wed, 27 Apr 2016 13:54:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <00a901d1a079$3707cc80$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 12:54:11 -0000

Hi Tom,

Yes, 802.3 passed a CFI (call-for-interest) at the last IEEE plenary and 
have formed a study group to create a PAR (project authorization 
request).  Once the PAR has passed then there will be a formal design 
team to work on the Ethernet models.

Thanks,
Rob


On 27/04/2016 10:06, t.petch wrote:
> Kent
>
> Has there been any progress in the IEEE on their work to produce
> Ethernet related models, as was mentioned earlier on in this thread?
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Kent Watsen" 
> To: 
> Sent: Thursday, April 21, 2016 4:18 PM
> Subject: Re: [netmod] call for consensus to adopt
> draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
>
>
>> [I wanted to formally close this thread, modeled after Lou's recent
> closure of another draft]
>> This poll is complete and the document is adopted,
>>
>> Authors,
>>
>> Please resubmit the draft with the only change being to rename the
> draft to draft-ietf-netmod-intf-ext-yang-00
>> Thank you!
>> Kent (and co-chairs)
>>
>>
>>
>> From: netmod >
> on behalf of Kent Watsen
> >
>> Date: Monday, February 29, 2016 at 6:07 PM
>> To: "netmod@ietf.org"
> >
>> Subject: Re: [netmod] call for consensus to adopt
> draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
>>
>> The chairs were just reviewing notes and realized that this thread
> never closed properly.
>> Juergen has some concerns regarding realistic milestones, that were
> never addressed.  Robert, can you please try to address Juergen’s
> concerns now?
>> Also, there were only a two responses before indicating willingness to
> review the draft as it progresses (thanks Dan and Martin).  Can others
> that support this draft and willing to review this draft say so?
>> Thanks,
>> Netmod Chairs
>>
>>
>> From: netmod >
> on behalf of Kent Watsen
> >
>> Date: Tuesday, December 15, 2015 at 11:48 AM
>> To: "netmod@ietf.org"
> >
>> Subject: [netmod] call for consensus to adopt
> draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
>>
>> The minutes for IETF 94 show that there was in-room support for
> adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes
> also show that this decision would be confirmed on the mailing list,
> which I am doing now.
>> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item
> and correspondingly add this to the WG charter as a milestone?  Please
> comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG
> Chairs will gauge whether or not there is consensus to move forward with
> the document.
>> Thanks,
>> Kent
>>
>>
>>
>
> ------------------------------------------------------------------------
> --------
>
>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Apr 27 08:09:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7A312D85A for ; Wed, 27 Apr 2016 08:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.217
X-Spam-Level: 
X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90kEV_Lp0O-Q for ; Wed, 27 Apr 2016 08:09:39 -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 CD13D12D11F for ; Wed, 27 Apr 2016 08:09:38 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIQ25000; Wed, 27 Apr 2016 15:09:36 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Apr 2016 16:09:35 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 27 Apr 2016 23:09:21 +0800
From: "Zhuangyan (Yan)" 
To: Robert Wilton , "t.petch" , "Kent Watsen" , "netmod@ietf.org" 
Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
Thread-Index: AQHRc0XzOmgxKIY1jkmkuTyx7LV2V5+UmGeAgAl0hWv//44ugIAAqZgQ
Date: Wed, 27 Apr 2016 15:09:20 +0000
Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785941E5823@nkgeml513-mbx.china.huawei.com>
References:   <00a901d1a079$3707cc80$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.46.231.23]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5720D630.02FC, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 28327137114706db6f692c780a0201dc
Archived-At: 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 15:09:42 -0000

VGhhbmsgeW91LCBSb2JlcnQuIFNvbWUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmb3IgVG9tIGFu
ZCBhbGwuDQoNClllcy4gV2UgYXJlIG5vdyB3b3JraW5nIG9uIHRoZSBQQVIsIENTRCBhbmQgT2Jq
ZWN0aXZlcyBvZiB0aGlzIHByb2plY3QuIE9uY2UgdGhleSBhcmUgYXBwcm92ZWQsIHRoZXJlIHdp
bGwgYmUgYSBUYXNrIEZvcmNlIHRvIHdvcmsgb24gdGhlIEV0aGVybmV0IG1vZGVscy4NCllvdSBj
YW4gZmluZCByZWxhdGl2ZSBkb2N1bWVudHMgYW5kIGluZm9ybWF0aW9uIGF0IGh0dHA6Ly93d3cu
aWVlZTgwMi5vcmcvMy9ZQU5HL2luZGV4Lmh0bWwgLg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoLg0K
DQpCZXN0IFJlZ2FyZHMsDQoNCllhbg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bk
uro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9iZXJ0
IFdpbHRvbg0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDI35pelIDIwOjU0DQrmlLbku7bkuro6
IHQucGV0Y2g7IEtlbnQgV2F0c2VuOyBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRt
b2RdIGNhbGwgZm9yIGNvbnNlbnN1cyB0byBhZG9wdCBkcmFmdC13aWx0b24tbmV0bW9kLWludGYt
ZXh0LXlhbmcgYXMgTkVUTU9EIFdHIGRyYWZ0DQoNCkhpIFRvbSwNCg0KWWVzLCA4MDIuMyBwYXNz
ZWQgYSBDRkkgKGNhbGwtZm9yLWludGVyZXN0KSBhdCB0aGUgbGFzdCBJRUVFIHBsZW5hcnkgYW5k
IGhhdmUgZm9ybWVkIGEgc3R1ZHkgZ3JvdXAgdG8gY3JlYXRlIGEgUEFSIChwcm9qZWN0IGF1dGhv
cml6YXRpb24gcmVxdWVzdCkuICBPbmNlIHRoZSBQQVIgaGFzIHBhc3NlZCB0aGVuIHRoZXJlIHdp
bGwgYmUgYSBmb3JtYWwgZGVzaWduIHRlYW0gdG8gd29yayBvbiB0aGUgRXRoZXJuZXQgbW9kZWxz
Lg0KDQpUaGFua3MsDQpSb2INCg0KDQpPbiAyNy8wNC8yMDE2IDEwOjA2LCB0LnBldGNoIHdyb3Rl
Og0KPiBLZW50DQo+DQo+IEhhcyB0aGVyZSBiZWVuIGFueSBwcm9ncmVzcyBpbiB0aGUgSUVFRSBv
biB0aGVpciB3b3JrIHRvIHByb2R1Y2UgDQo+IEV0aGVybmV0IHJlbGF0ZWQgbW9kZWxzLCBhcyB3
YXMgbWVudGlvbmVkIGVhcmxpZXIgb24gaW4gdGhpcyB0aHJlYWQ/DQo+DQo+IFRvbSBQZXRjaA0K
Pg0KPg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJLZW50IFdhdHNl
biIgPGt3YXRzZW5AanVuaXBlci5uZXQ+DQo+IFRvOiA8bmV0bW9kQGlldGYub3JnPg0KPiBTZW50
OiBUaHVyc2RheSwgQXByaWwgMjEsIDIwMTYgNDoxOCBQTQ0KPiBTdWJqZWN0OiBSZTogW25ldG1v
ZF0gY2FsbCBmb3IgY29uc2Vuc3VzIHRvIGFkb3B0IA0KPiBkcmFmdC13aWx0b24tbmV0bW9kLWlu
dGYtZXh0LXlhbmcgYXMgTkVUTU9EIFdHIGRyYWZ0DQo+DQo+DQo+PiBbSSB3YW50ZWQgdG8gZm9y
bWFsbHkgY2xvc2UgdGhpcyB0aHJlYWQsIG1vZGVsZWQgYWZ0ZXIgTG91J3MgcmVjZW50DQo+IGNs
b3N1cmUgb2YgYW5vdGhlciBkcmFmdF0NCj4+IFRoaXMgcG9sbCBpcyBjb21wbGV0ZSBhbmQgdGhl
IGRvY3VtZW50IGlzIGFkb3B0ZWQsDQo+Pg0KPj4gQXV0aG9ycywNCj4+DQo+PiBQbGVhc2UgcmVz
dWJtaXQgdGhlIGRyYWZ0IHdpdGggdGhlIG9ubHkgY2hhbmdlIGJlaW5nIHRvIHJlbmFtZSB0aGUN
Cj4gZHJhZnQgdG8gZHJhZnQtaWV0Zi1uZXRtb2QtaW50Zi1leHQteWFuZy0wMA0KPj4gVGhhbmsg
eW91IQ0KPj4gS2VudCAoYW5kIGNvLWNoYWlycykNCj4+DQo+Pg0KPj4NCj4+IEZyb206IG5ldG1v
ZCANCj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmc+Pg0KPiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4NCj4gPGt3YXRzZW5AanVuaXBlci5u
ZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+Pg0KPj4gRGF0ZTogTW9uZGF5LCBGZWJydWFy
eSAyOSwgMjAxNiBhdCA2OjA3IFBNDQo+PiBUbzogIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPiINCj4gPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn
Pj4NCj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBjYWxsIGZvciBjb25zZW5zdXMgdG8gYWRvcHQN
Cj4gZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIE5FVE1PRCBXRyBkcmFmdA0K
Pj4NCj4+IFRoZSBjaGFpcnMgd2VyZSBqdXN0IHJldmlld2luZyBub3RlcyBhbmQgcmVhbGl6ZWQg
dGhhdCB0aGlzIHRocmVhZA0KPiBuZXZlciBjbG9zZWQgcHJvcGVybHkuDQo+PiBKdWVyZ2VuIGhh
cyBzb21lIGNvbmNlcm5zIHJlZ2FyZGluZyByZWFsaXN0aWMgbWlsZXN0b25lcywgdGhhdCB3ZXJl
DQo+IG5ldmVyIGFkZHJlc3NlZC4gIFJvYmVydCwgY2FuIHlvdSBwbGVhc2UgdHJ5IHRvIGFkZHJl
c3MgSnVlcmdlbuKAmXMgDQo+IGNvbmNlcm5zIG5vdz8NCj4+IEFsc28sIHRoZXJlIHdlcmUgb25s
eSBhIHR3byByZXNwb25zZXMgYmVmb3JlIGluZGljYXRpbmcgd2lsbGluZ25lc3MgDQo+PiB0bw0K
PiByZXZpZXcgdGhlIGRyYWZ0IGFzIGl0IHByb2dyZXNzZXMgKHRoYW5rcyBEYW4gYW5kIE1hcnRp
bikuICBDYW4gb3RoZXJzIA0KPiB0aGF0IHN1cHBvcnQgdGhpcyBkcmFmdCBhbmQgd2lsbGluZyB0
byByZXZpZXcgdGhpcyBkcmFmdCBzYXkgc28/DQo+PiBUaGFua3MsDQo+PiBOZXRtb2QgQ2hhaXJz
DQo+Pg0KPj4NCj4+IEZyb206IG5ldG1vZCANCj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxt
YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiBvbiBiZWhhbGYgb2YgS2VudCBXYXRz
ZW4NCj4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+Pg0K
Pj4gRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgYXQgMTE6NDggQU0NCj4+IFRvOiAi
bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Ig0KPiA8bmV0bW9kQGlldGYu
b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KPj4gU3ViamVjdDogW25ldG1vZF0gY2FsbCBm
b3IgY29uc2Vuc3VzIHRvIGFkb3B0DQo+IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFu
ZyBhcyBORVRNT0QgV0cgZHJhZnQNCj4+DQo+PiBUaGUgbWludXRlcyBmb3IgSUVURiA5NCBzaG93
IHRoYXQgdGhlcmUgd2FzIGluLXJvb20gc3VwcG9ydCBmb3INCj4gYWRvcHRpbmcgZHJhZnQtd2ls
dG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgZHJhZnQuICAgVGhlIG1pbnV0ZXMNCj4g
YWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhlIG1h
aWxpbmcgbGlzdCwgDQo+IHdoaWNoIEkgYW0gZG9pbmcgbm93Lg0KPj4gU2hvdWxkIHdlIG1vdmUg
dG8gYWRvcHQgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEgV0cgDQo+PiBp
dGVtDQo+IGFuZCBjb3JyZXNwb25kaW5nbHkgYWRkIHRoaXMgdG8gdGhlIFdHIGNoYXJ0ZXIgYXMg
YSBtaWxlc3RvbmU/ICBQbGVhc2UgDQo+IGNvbW1lbnQgYnkgVHVlc2RheSwgRGVjZW1iZXIgMjIs
IDIwMTUgYXQgOUFNIEVTVCBhdCB3aGljaCB0aW1lIHRoZSBXRyANCj4gQ2hhaXJzIHdpbGwgZ2F1
Z2Ugd2hldGhlciBvciBub3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCANCj4g
d2l0aCB0aGUgZG9jdW1lbnQuDQo+PiBUaGFua3MsDQo+PiBLZW50DQo+Pg0KPj4NCj4+DQo+DQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gLS0tLS0tLS0NCj4NCj4NCj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0
DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlz
dA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0K


From nobody Thu Apr 28 00:13:55 2016
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6C012B030; Thu, 28 Apr 2016 00:13:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160428071353.27701.64534.idtracker@ietfa.amsl.com>
Date: Thu, 28 Apr 2016 00:13:53 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-12.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 07:13:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

        Title           : The YANG 1.1 Data Modeling Language
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc6020bis-12.txt
	Pages           : 208
	Date            : 2016-04-28

Abstract:
   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols.  This document also specifies the YANG mappings
   to the Network Configuration Protocol (NETCONF).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-12


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

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


From nobody Thu Apr 28 01:18:25 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8DA12D09C for ; Thu, 28 Apr 2016 01:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level: 
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A4Ph9Fie9Kc for ; Thu, 28 Apr 2016 01:18:23 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE8212B04D for ; Thu, 28 Apr 2016 01:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=319; q=dns/txt; s=iport; t=1461831503; x=1463041103; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=OOwNzPjNpyOASPNC3rsE1HvGz9DMZ7JUQFEo8nOOpoA=; b=KTBVjPaf9/n77WuMwkmLZOfRgTDYAvrEs4e85dDJXv2fk3JJ5npSutzR F8n8b/lLGdaKy9YLjV058FW+eDW6+Dam51qqULLGZ9ssRnAn8dUcfPsvj raoMQOmUXK2uPN2r7elmUQmnGeZF41qBdKRnd3eMUyQyJHRHQISq3DSKd g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAQDOxiFX/xbLJq1evGyCDwENgXaHd?= =?us-ascii?q?RQBAQEBAQEBZSeEaxVANgIFFgsCCwMCAQIBSw0IAQGIJqIYj12RHAEBAQcCAR1?= =?us-ascii?q?8hSWMCIJWAQSYEI4XgVEBh2iFV48wHgEBQoNtOolmAQEB?=
X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208";a="634369807"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 08:18:20 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3S8IKYv014470 for ; Thu, 28 Apr 2016 08:18:20 GMT
From: Benoit Claise 
To: NETMOD Working Group 
Message-ID: <5721C74B.2000709@cisco.com>
Date: Thu, 28 Apr 2016 10:18:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] draft-ietf-netmod-rfc6020bis: now in IETF Last Call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 08:18:24 -0000

Dear all,

Now that draft-ietf-netmod-rfc6020bis v12 has posted, I sent this 
document to IETF Last Call.
During this 2 weeks period, your feedback is obviously welcome.
I also tentatively placed this document on the May 19th IESG telechat, 
assuming that the IETF Last Call will go smoothly.

Regards, Benoit



From nobody Thu Apr 28 02:39:05 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7C12D0E9 for ; Thu, 28 Apr 2016 02:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsrTTaXbyY84 for ; Thu, 28 Apr 2016 02:39:01 -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 24AB312D5F3 for ; Thu, 28 Apr 2016 02:38:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C8958DB; Thu, 28 Apr 2016 11:38: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 63lnA0nuJmCI; Thu, 28 Apr 2016 11:38: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; Thu, 28 Apr 2016 11:38:57 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04D8B20050; Thu, 28 Apr 2016 11:38:57 +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 3a0Y40rogDvG; Thu, 28 Apr 2016 11:38:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D99820055; Thu, 28 Apr 2016 11:38:54 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 48D773ABA719; Thu, 28 Apr 2016 11:38:54 +0200 (CEST)
Date: Thu, 28 Apr 2016 11:38:54 +0200
From: Juergen Schoenwaelder 
To: "Ing-Wher (Helen) Chen" 
Message-ID: <20160428093854.GA23908@elstar.local>
Mail-Followup-To: "Ing-Wher (Helen) Chen" , Martin Bjorklund , "netmod@ietf.org" 
References:  <20160419182250.GA3771@elstar.local>  <20160420.164755.1169712416411367784.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.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 28 Apr 2016 09:39:04 -0000

On Wed, Apr 20, 2016 at 03:24:25PM +0000, Ing-Wher (Helen) Chen wrote:
> 
> The technical problem of generalizing is the difficulty in creating
> a URN based on domain names that is also persistent.  Limiting the
> scope of the "rdns" URN namespace to only YANG modules means that
> there is a smaller persistency problem to solve and that it can be
> solved by taking advantage of properties specific to YANG modules.
>

Can you detail which properties specific to YANG modules make the
smaller persistency problem solvable?

/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 Apr 28 07:14:32 2016
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CED12D186; Thu, 28 Apr 2016 07:14:31 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20160428141431.27693.11854.idtracker@ietfa.amsl.com>
Date: Thu, 28 Apr 2016 07:14:31 -0700
Archived-At: 
Cc: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6020bis@ietf.org
Subject: [netmod] Last Call:  (The YANG 1.1 Data Modeling Language) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: ietf@ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 14:14:31 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'The YANG 1.1 Data Modeling Language'
   as Proposed Standard

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

The following URL https://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt&url2=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-12.txt, highlighting the changes with RFC6020,  might help for your review.

Abstract


   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols.  This document also specifies the YANG mappings
   to the Network Configuration Protocol (NETCONF).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ballot/


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



From nobody Thu Apr 28 12:15:16 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1477112D869 for ; Thu, 28 Apr 2016 12:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzksIyFqWVDB for ; Thu, 28 Apr 2016 12:15:12 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DDBF12D641 for ; Thu, 28 Apr 2016 12:15:12 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ECFFFAF3; Thu, 28 Apr 2016 21:15:10 +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 5oBNLSpJ1VJw; Thu, 28 Apr 2016 21:14:52 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Apr 2016 21:15:10 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AE9520047; Thu, 28 Apr 2016 21:15:10 +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 SKK44rY3b2Fh; Thu, 28 Apr 2016 21:15:09 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC39620046; Thu, 28 Apr 2016 21:15:08 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C65723ABBB4A; Thu, 28 Apr 2016 21:15:07 +0200 (CEST)
Date: Thu, 28 Apr 2016 21:15:06 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org, Martin Bjorklund , Benoit Claise 
Message-ID: <20160428191506.GA25163@elstar.local>
Mail-Followup-To: netmod@ietf.org, Martin Bjorklund , Benoit Claise 
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160307102636.GA41749@elstar.local>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: Re: [netmod] Fwd: Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 28 Apr 2016 19:15:15 -0000

On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen Schoenwaelder wrote:
> On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote:
> >   So perhaps the proposal is to add
> > 
> >     After applying all deviations announced by a server, in any order,
> >     the resulting data model MUST still be valid.
> > 
> >   just before the beginning of section 7.20.3.1?
> 
> I like to see whether we have consensus to add this clarifying
> sentence. I believe it documents something that we always assumed to
> be true but we did not write it down explicitly. If anyone disagrees
> with adding this clarification, please speak up now.
>

I have not heard anyone disagreeing with adding this clarification.

Martin did not put this additional sentence into -12 and since we seem
to have consensus on adding this clarification I like to ask him to
add this sentence if another revision is made before the IESG
telechat. I am CCing Benoit in case he wants to add this as a comment
to his IESG evaluation record.

/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 Apr 28 12:34:06 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19812D942; Thu, 28 Apr 2016 12:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level: 
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2pMGBs_tBfJ; Thu, 28 Apr 2016 12:33:58 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B9E12D946; Thu, 28 Apr 2016 12:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7434; q=dns/txt; s=iport; t=1461872038; x=1463081638; h=from:to:cc:subject:date:message-id:mime-version; bh=yJquQEkv6eij7dam+d28qATlQbNFjk9MtWjvoyRdF1c=; b=GUGqJ54Q2N26DY8cH+RVBWmUJs9iPJDmXwaQNayxDfE8PpNyNrEJgABW 7p0LDskCSAI7c5GPh8zsZFBDN3gNmyUZ6382kpLnytl4B7sT5eqsSTX8K R9UA36fWKZbHxTSBNMzqJwZFGdx7qB7sXqJH6YwjXCzS5UOjDLr2HQr5R Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgAKZSJX/4MNJK1egmxMU30GtGeEc?= =?us-ascii?q?wENgXYkhWsegRA4FAEBAQEBAQFlHAuESCNWEgFKAgQwJwQOIIgPDrJTkR0BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQERBIYhgXUIigsrgisFjVSKPAGBLYROiBuPEY8vA?= =?us-ascii?q?R4BAUKDa2wBhislGH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,548,1454976000";  d="scan'208,217";a="267261753"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 19:33:57 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3SJXu7j021540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 19:33:57 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 15:33:55 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 15:33:55 -0400
From: "Tarek Saad (tsaad)" 
To: "draft-ietf-netmod-schema-mount@ietf.org" 
Thread-Topic: Use of schema mounts for common model
Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLng==
Date: Thu, 28 Apr 2016 19:33:55 +0000
Message-ID: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.243.62]
Content-Type: multipart/alternative; boundary="_000_4A05DD100885435C9D139634388B9F4Bciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "teas@ietf.org" , "netmod@ietf.org" 
Subject: [netmod] Use of schema mounts for common model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 19:34:00 -0000

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

SGkgYXV0aG9ycy9XRywNCg0KSW4gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUsIHdlIGFyZSBkcml2
aW5nIHRoZSBkZWZpbml0aW9uIGZvciBhIGdlbmVyaWMgVEUgWUFORyBtb2RlbCB0aGF0IGNhbi9t
YXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4gbmVjZXNzYXJ5KSBmb3IgZGlmZmVyZW50IGRh
dGEgcGxhbmUgdGVjaG5vbG9naWVzIChlLmcuIE1QTFMsIE9UTiwgV0RNLCBldGMuKS4NClJldmll
d2luZyB0aGUgc2NoZW1hIG1vdW50IGlkZWEgcHJlc2VudGVkIGluIGRyYWZ0LWlldGYtbmV0bW9k
LXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXMgdXNlZnVsIGFu
ZCBjYW4gZmFjaWxpdGF0ZSB0aGUgcmV1c2Ugb2YgdGhlIG91ciBtb2RlbCBpbiBtdWx0aXBsZSBw
bGFjZXMgaW4gdGhlIFlBTkcgdHJlZSAob25jZSBwZXIgZWFjaCB0ZWNobm9sb2d5KSwgZS5nLjoN
CuKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nDQri
gKYvb3RuL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nDQoNCldl
IGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUgeW91ciBmZWVk
YmFjay4NCg0KVGhlIGdlbmVyaWMgVEUgbW9kZWwgY3VycmVudGx5IHJlZmVyZW5jZXMgZGF0YSBu
b2RlcyBpbiB0aGUgZ2xvYmFsIHRyZWUgKGUuZy4gZnJvbSB0aGUgaWV0Zi1pbnRlcmZhY2VzIG1v
ZGVsIHRvIGRlZmluZSBhZGRpdGlvbmFsIFRFIHByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRoIGEg
c3BlY2lmaWMgZGV2aWNlIGludGVyZmFjZSkuIE91ciB1bmRlcnN0YW5kaW5nIGFmdGVyIHJlYWRp
bmcgc2VjdGlvbiAzLjEgb2YgeW91ciBkcmFmdCBpcyB0aGUgbW91bnRlZCBtb2RlbCBjYW4gKm5v
dCogcmVmZXJlbmNlIGFueSBkYXRhIG5vZGVzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBtb3Vu
dC1wb2ludCAoZS5nLiBnbG9iYWwgZGF0YSBub2RlcyBpbiB0aGUgeWFuZyB0cmVlKS4gVGhpcyBw
b3NlcyBhIGxpbWl0YXRpb24gZm9yIHVzLCBkbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9yIHRo
aXMgcHJvYmxlbT8NCg0KT25lIHBvc3NpYmxlIHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRv
IHJlcGxhY2UgdGhlIGxlYWYtcmVmcyBwb2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEgbm9kZXMg
KGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQgbmFtZXMgKGUuZy4gdGhlIGludGVy
ZmFjZSBuYW1lKS4uIFRoaXMgZGVjb3VwbGVzIHRoZSBkYXRhLW5vZGVzIGRlZmluZWQgaW4gdGhl
IFRFIGdlbmVyaWMgbW9kZWwgZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUgKGUuZy4gdGhl
IGFjdHVhbCBpbnRlcmZhY2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZlZWRiYWNrIG9u
IHRoaXMgb3IgYmV0dGVyIHN1Z2dlc3Rpb25zPw0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KRXhjZXJw
dCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudA0KDQozLjE8aHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wMSNzZWN0aW9u
LTMuMT4uICBBdWdtZW50IGFuZCBWYWxpZGF0aW9uIGluIE1vdW50ZWQgRGF0YQ0KDQoNCiAgIEFs
bCBwYXRocyAoaW4gbGVhZnJlZnMsIGluc3RhbmNlLWlkZW50aWZpZXJzLCBYUGF0aCBleHByZXNz
aW9ucywgYW5kDQogICB0YXJnZXQgbm9kZXMgb2YgYXVnbWVudHMpIGluIHRoZSBkYXRhIG1vZGVs
cyBtb3VudGVkIGF0IGEgbW91bnQgcG9pbnQNCiAgIGFyZSBpbnRlcnByZXRlZCB3aXRoIHRoZSBt
b3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlDQogICBtb3VudGVkIGRhdGEgbm9k
ZXMgYXMgaXRzIGNoaWxkcmVuLiAgVGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGENCiAgIG1v
dW50ZWQgc3VidHJlZSBjYW4gbmV2ZXIgcmVmZXIgdG8gZGF0YSBvdXRzaWRlIG9mIHRoaXMgc3Vi
dHJlZS4NCg0KDQoNCg0K

--_000_4A05DD100885435C9D139634388B9F4Bciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <4EDE293CDAFCF7409F0D9A213A08AA69@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBhdXRob3Jz
L1dHLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gZHJhZnQtaWV0Zi10ZWFzLXlh
bmctdGUsIHdlIGFyZSBkcml2aW5nIHRoZSBkZWZpbml0aW9uIGZvciBhIGdlbmVyaWMgVEUgWUFO
RyBtb2RlbCB0aGF0IGNhbi9tYXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4gbmVjZXNzYXJ5
KSBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9naWVzIChlLmcuIE1QTFMsIE9UTiwg
V0RNLCBldGMuKS48L2Rpdj4NCjxkaXY+UmV2aWV3aW5nIHRoZSBzY2hlbWEgbW91bnQgaWRlYSBw
cmVzZW50ZWQgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LCB3ZSBhcmUgdGhpbmtp
bmcgdGhpcyBwcm9wb3NhbCBpcyB1c2VmdWwgYW5kIGNhbiBmYWNpbGl0YXRlIHRoZSByZXVzZSBv
ZiB0aGUgb3VyIG1vZGVsIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgWUFORyB0cmVlIChvbmNl
IHBlciBlYWNoIHRlY2hub2xvZ3kpLCBlLmcuOjwvZGl2Pg0KPGRpdj7igKYvbXBscy9tb3VudC1w
b2ludHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZzwvZGl2Pg0KPGRpdj7igKYvb3Ru
L21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5XZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1Z2dlc3Rpb24g
YW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj5UaGUgZ2VuZXJpYyBURSBtb2RlbCBjdXJyZW50bHkgcmVmZXJlbmNlcyBkYXRhIG5v
ZGVzIGluIHRoZSBnbG9iYWwgdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWludGVyZmFjZXMgbW9k
ZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUgcHJvcGVydGllcyBhc3NvY2lhdGVkIHdpdGggYSBz
cGVjaWZpYyBkZXZpY2UgaW50ZXJmYWNlKS4gT3VyIHVuZGVyc3RhbmRpbmcgYWZ0ZXIgcmVhZGlu
ZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRyYWZ0IGlzIHRoZQ0KIG1vdW50ZWQgbW9kZWwgY2FuICo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5ub3Q8L3NwYW4+KiByZWZlcmVuY2UgYW55
IGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIG1vdW50LXBvaW50IChlLmcuIGds
b2JhbCBkYXRhIG5vZGVzIGluIHRoZSB5YW5nIHRyZWUpLiBUaGlzIHBvc2VzIGEgbGltaXRhdGlv
biBmb3IgdXMsIGRvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPzwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T25lIHBvc3NpYmxlIHNvbHV0aW9uIHdlIHRob3Vn
aHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcyBwb2ludGluZyB0byB0aGUgZ2xvYmFs
IGRhdGEgbm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQgbmFtZXMgKGUu
Zy4gdGhlIGludGVyZmFjZSBuYW1lKS4uIFRoaXMgZGVjb3VwbGVzIHRoZSBkYXRhLW5vZGVzIGRl
ZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwgZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsDQog
dHJlZSAoZS5nLiB0aGUgYWN0dWFsIGludGVyZmFjZSBpZXRmLWludGVyZmFjZXMgbW9kZWwpLiBB
bnkgZmVlZGJhY2sgb24gdGhpcyBvciBiZXR0ZXIgc3VnZ2VzdGlvbnM/PC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5UYXJlazwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+RXhjZXJwdCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1t
b3VudDwvZGl2Pg0KPGRpdj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6
IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJl
Zm9yZTogYWx3YXlzOyI+PHNwYW4gY2xhc3M9ImgzIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDBwdDsg
ZGlzcGxheTogaW5saW5lOyBmb250LXNpemU6IDFlbTsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij48aDMg
c3R5bGU9ImxpbmUtaGVpZ2h0OiAwcHQ7IGRpc3BsYXk6IGlubGluZTsgZm9udC1zaXplOiAxZW07
Ij48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMy4xIiBocmVmPSJodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rp
b24tMy4xIiBzdHlsZT0iY29sb3I6IGJsYWNrOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4zLjE8
L2E+LiAgQXVnbWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERhdGE8L2gzPjwvc3Bhbj4N
Cg0KICAgQWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmllcnMsIFhQYXRo
IGV4cHJlc3Npb25zLCBhbmQNCiAgIHRhcmdldCBub2RlcyBvZiBhdWdtZW50cykgaW4gdGhlIGRh
dGEgbW9kZWxzIG1vdW50ZWQgYXQgYSBtb3VudCBwb2ludA0KICAgYXJlIGludGVycHJldGVkIHdp
dGggdGhlIG1vdW50IHBvaW50IGFzIHRoZSByb290IG5vZGUsIGFuZCB0aGUNCiAgIG1vdW50ZWQg
ZGF0YSBub2RlcyBhcyBpdHMgY2hpbGRyZW4uICA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv
cjogcmdiKDI1NSwgMjU1LCAwKTsiPlRoaXMgbWVhbnMgdGhhdCBkYXRhIHdpdGhpbiBhDQogICBt
b3VudGVkIHN1YnRyZWUgY2FuIG5ldmVyIHJlZmVyIHRvIGRhdGEgb3V0c2lkZSBvZiB0aGlzIHN1
YnRyZWUuPC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_4A05DD100885435C9D139634388B9F4Bciscocom_--


From nobody Thu Apr 28 21:09:46 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD6112D529 for ; Thu, 28 Apr 2016 21:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw4QnkLulf0x for ; Thu, 28 Apr 2016 21:09:43 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E3612D523 for ; Thu, 28 Apr 2016 21:09:42 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id j11so119609256lfb.1 for ; Thu, 28 Apr 2016 21:09:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=KH3pL/KO7z4BRzhULYudjMPhgwX5u5kUbb1hRFJbZho=; b=igc6Ph+qdLunjEZSbWO+aYnGnQ4Lf2/t0JCQiHNFDTuaYCSqOs5rTGMVP8Wj09J2wz xaib21enIySz4oyBx1l9/Q8ipm+GHRWEsmoBAFaBbBhXzU+t+2EYMNvToFmw2Nq+STr0 QrpQMs14gcdxHlgL5TUnqmE1pU1w+SwskWkBVS7wDmfRZIKI9vnJMU13Zz2My6Q4Oqk7 19JxsMwf3VjQDZaa5synYVtvHgClTLzvN0KdLnaf3dZzrPs+sA/OzVGy/tuyXSSO1FMb 8n6pFt/dfvK8OVNv/G9Yv6cyZIiUZvU5nw5Lcur7tL92AUI2ViSD2bvt5gTtt2Cv8m+/ KJVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=KH3pL/KO7z4BRzhULYudjMPhgwX5u5kUbb1hRFJbZho=; b=TxrNyjhhe+EdKQAXCnhKUPQ5N/NrEsQT7GNUrU74vD5FGfwjraYZydnAZOH5FznjHD jTicueplMYeu7aGySSP0LsMTVF4IIQL25ih7nxpmwOdBmjAl+u9kg+YLVM8dDAMYirk0 u+yt9BWfHMzKW90KgnnuUx1XnT9GUaK0GrPT3cizyDnifjs+PIRtvMJAv0Qd3iu3VnsF dsbU+iHlKZwcmAyh/tuEHcrzRgZTtCJkMpOdCz5ZBnlIw2iWd4QMF+KutcdG4uwWm1YV dO8czPGdtdtLsXapvZ74CmcOHHg0mTqFQ8ZZjdT/+rfWoUETMI63pj6j+sQIY3Gx0tw0 /plw==
X-Gm-Message-State: AOPr4FXx1Ea5gT9t4irrF1lHhIKucyMmVsW/9FcC7i4hAUwQoiM/K7qrYG3YF8VAYZu7qRHasV6P/8ayOYALHA==
MIME-Version: 1.0
X-Received: by 10.112.184.79 with SMTP id es15mr7646616lbc.30.1461902980562; Thu, 28 Apr 2016 21:09:40 -0700 (PDT)
Received: by 10.112.198.70 with HTTP; Thu, 28 Apr 2016 21:09:40 -0700 (PDT)
In-Reply-To: <20160428191506.GA25163@elstar.local>
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local>
Date: Thu, 28 Apr 2016 21:09:40 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder ,  "netmod@ietf.org" , Martin Bjorklund , Benoit Claise 
Content-Type: multipart/alternative; boundary=001a1133ac90da55a7053197cfc9
Archived-At: 
Subject: Re: [netmod] Fwd: Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 04:09:45 -0000

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

On Thu, Apr 28, 2016 at 12:15 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen Schoenwaelder wrote:
> > On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote:
> > >   So perhaps the proposal is to add
> > >
> > >     After applying all deviations announced by a server, in any order,
> > >     the resulting data model MUST still be valid.
> > >
> > >   just before the beginning of section 7.20.3.1?
> >
> > I like to see whether we have consensus to add this clarifying
> > sentence. I believe it documents something that we always assumed to
> > be true but we did not write it down explicitly. If anyone disagrees
> > with adding this clarification, please speak up now.
> >
>
> I have not heard anyone disagreeing with adding this clarification.
>
> Martin did not put this additional sentence into -12 and since we seem
> to have consensus on adding this clarification I like to ask him to
> add this sentence if another revision is made before the IESG
> telechat. I am CCing Benoit in case he wants to add this as a comment
> to his IESG evaluation record.
>
>
Was it unclear before that the result of deviations were allowed to be
invalid?
I do not object to this text, but I hope those 3 words "in any order" are
enough
of a clue to developers that on the server "only one wins" but the client
does not know which one.  I will add a YANG guideline to avoid duplicate
deviation targets.  (issue #33)



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

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




On Thu, Apr 28, 2016 at 12:15 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen S=
choenwaelder wrote:

> On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote:=


> >=C2=A0 =C2=A0So perhaps the proposal is to add

> >

> >=C2=A0 =C2=A0 =C2=A0After applying all deviations announced by a s=
erver, in any order,

> >=C2=A0 =C2=A0 =C2=A0the resulting data model MUST still be valid.<=
br>
> >

> >=C2=A0 =C2=A0just before the beginning of section 7.20.3.1?

>

> I like to see whether we have consensus to add this clarifying

> sentence. I believe it documents something that we always assumed to
> be true but we did not write it down explicitly. If anyone disagrees
> with adding this clarification, please speak up now.

>



I have not heard anyone disagreeing with adding this clarification.



Martin did not put this additional sentence into -12 and since we seem

to have consensus on adding this clarification I like to ask him to

add this sentence if another revision is made before the IESG

telechat. I am CCing Benoit in case he wants to add this as a comment

to his IESG evaluation record.



Was it unclear before that the result of deviations =
were allowed to be invalid?
I do not object to this text, but I h=
ope those 3 words "in any order" are enough
of a clue t=
o developers that on the server "only one wins" but the client
does not know which one.=C2=A0 I will add a YANG guideline to avoid=
 duplicate
deviation targets. =C2=A0(issue #33)




/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





--001a1133ac90da55a7053197cfc9--


From nobody Fri Apr 29 00:49:30 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE812D588 for ; Fri, 29 Apr 2016 00:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level: 
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPQWc6c3Bi_l for ; Fri, 29 Apr 2016 00:49:27 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC3712D56A for ; Fri, 29 Apr 2016 00:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1224; q=dns/txt; s=iport; t=1461916167; x=1463125767; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=eFK63Sukg9mMNeLz0WpTxEMJbDn672vWoMyZhIjt0Es=; b=ea21njyRu0H76vbSmmcBLV5K138HyyZaXdfsU1kdO2FhmWJlc3hoHPJz fLJ9yDHJpGWMuqwR/pZgVdpxqRqgX4YAyPkQeQwHVgBMCOUxDdvlh17zW InxNoH01fXmQtWIBElrudcnKsmvJclYuNCWPM0qBXsOYC8mqP7MEWMgub 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABJESNX/xbLJq1ewHeGDwKBdgEBA?= =?us-ascii?q?QEBAWYnhEIBAQQ4QBELGAkWDwkDAgECAUUGAQwIAQGIJsMyAQEBAQEBAQECAQE?= =?us-ascii?q?BAQEBGoYhhEuEJ4VsAQSYEYhzhSSBZ4RNgwaFV48wYoIFG4FNOogYAQEB?=
X-IronPort-AV: E=Sophos;i="5.24,550,1454976000"; d="scan'208";a="637227191"
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/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 07:49:24 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3T7nOXx026581; Fri, 29 Apr 2016 07:49:24 GMT
To: netmod@ietf.org, Martin Bjorklund 
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local>
From: Benoit Claise 
Message-ID: <57231204.4040706@cisco.com>
Date: Fri, 29 Apr 2016 09:49:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160428191506.GA25163@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Fwd: Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 07:49:29 -0000

On 4/28/2016 9:15 PM, Juergen Schoenwaelder wrote:
> On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen Schoenwaelder wrote:
>> On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote:
>>>    So perhaps the proposal is to add
>>>
>>>      After applying all deviations announced by a server, in any order,
>>>      the resulting data model MUST still be valid.
>>>
>>>    just before the beginning of section 7.20.3.1?
>> I like to see whether we have consensus to add this clarifying
>> sentence. I believe it documents something that we always assumed to
>> be true but we did not write it down explicitly. If anyone disagrees
>> with adding this clarification, please speak up now.
>>
> I have not heard anyone disagreeing with adding this clarification.
>
> Martin did not put this additional sentence into -12 and since we seem
> to have consensus on adding this clarification I like to ask him to
> add this sentence if another revision is made before the IESG
> telechat. I am CCing Benoit in case he wants to add this as a comment
> to his IESG evaluation record.
Thanks. We're at IETF last call statge, so there is still time to 
include this change.

Regards, B.
>
> /js
>


From nobody Fri Apr 29 01:18:20 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3315D12D53F for ; Fri, 29 Apr 2016 01:18: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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJxBV1qlfpCZ for ; Fri, 29 Apr 2016 01:18:15 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0E12B03D for ; Fri, 29 Apr 2016 01:18:15 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EA9C81CC0249; Fri, 29 Apr 2016 10:18:19 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" , Martin Bjorklund , Benoit Claise 
In-Reply-To: 
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local> 
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 29 Apr 2016 10:18:15 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Fwd: Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 08:18:18 -0000

Andy Bierman  writes:

> On Thu, Apr 28, 2016 at 12:15 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen Schoenwaelder wrote:
>> > On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote:
>> > >   So perhaps the proposal is to add
>> > >
>> > >     After applying all deviations announced by a server, in any order,
>> > >     the resulting data model MUST still be valid.
>> > >
>> > >   just before the beginning of section 7.20.3.1?
>> >
>> > I like to see whether we have consensus to add this clarifying
>> > sentence. I believe it documents something that we always assumed to
>> > be true but we did not write it down explicitly. If anyone disagrees
>> > with adding this clarification, please speak up now.
>> >
>>
>> I have not heard anyone disagreeing with adding this clarification.
>>
>> Martin did not put this additional sentence into -12 and since we seem
>> to have consensus on adding this clarification I like to ask him to
>> add this sentence if another revision is made before the IESG
>> telechat. I am CCing Benoit in case he wants to add this as a comment
>> to his IESG evaluation record.
>>
>>
> Was it unclear before that the result of deviations were allowed to be
> invalid?

Right, I think it goes pretty much without saying, so this sentence is
IMO unnecessary. The real problem is that different ways of applying the
deviations may lead to different data models, all valid.

I think this should be avoided although I don't know how to do it. In
hindsight, it would probably be better to allow the server to specify
just a single deviation module with no other content. Then it would be
easier to state some rules.

> I do not object to this text, but I hope those 3 words "in any order" are
> enough
> of a clue to developers that on the server "only one wins" but the client
> does not know which one.  I will add a YANG guideline to avoid duplicate
> deviation targets.  (issue #33)

I don't think it is clear that only one wins. Three deviations adding
default values to the same leaf-list target could be possibly applied
together.

Lada

>
>
>
> /js
>>
>>
>
> Andy
>
>
>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Apr 29 02:27:20 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E9812D758 for ; Fri, 29 Apr 2016 02:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4a09aPlTMKY for ; Fri, 29 Apr 2016 02:27: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 DA07712D757 for ; Fri, 29 Apr 2016 02:27: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 9C31111D9; Fri, 29 Apr 2016 11:27: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 qT2fsswf_ycO; Fri, 29 Apr 2016 11:26: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; Fri, 29 Apr 2016 11:27:14 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C94992004E; Fri, 29 Apr 2016 11:27: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 bhjDR01OHidI; Fri, 29 Apr 2016 11:27: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 59DCB20063; Fri, 29 Apr 2016 11:27:05 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6B8823ABCDB1; Fri, 29 Apr 2016 11:27:05 +0200 (CEST)
Date: Fri, 29 Apr 2016 11:27:05 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429092705.GB26370@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" , Martin Bjorklund , Benoit Claise 
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Fwd: Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 09:27:18 -0000

On Fri, Apr 29, 2016 at 10:18:15AM +0200, Ladislav Lhotka wrote:
> Andy Bierman  writes:
> 
> > On Thu, Apr 28, 2016 at 12:15 PM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen Schoenwaelder wrote:
> >> > On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder wrote:
> >> > >   So perhaps the proposal is to add
> >> > >
> >> > >     After applying all deviations announced by a server, in any order,
> >> > >     the resulting data model MUST still be valid.
> >> > >
> >> > >   just before the beginning of section 7.20.3.1?
> >> >
> >> > I like to see whether we have consensus to add this clarifying
> >> > sentence. I believe it documents something that we always assumed to
> >> > be true but we did not write it down explicitly. If anyone disagrees
> >> > with adding this clarification, please speak up now.
> >> >
> >>
> >> I have not heard anyone disagreeing with adding this clarification.
> >>
> >> Martin did not put this additional sentence into -12 and since we seem
> >> to have consensus on adding this clarification I like to ask him to
> >> add this sentence if another revision is made before the IESG
> >> telechat. I am CCing Benoit in case he wants to add this as a comment
> >> to his IESG evaluation record.
> >>
> >>
> > Was it unclear before that the result of deviations were allowed to be
> > invalid?
> 
> Right, I think it goes pretty much without saying, so this sentence is
> IMO unnecessary.
>

Apparently, this was not clear to every reader and hence the proposal
to add this sentence in order to make this explicit.

/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 Apr 29 02:59:23 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5401E12B03C for ; Fri, 29 Apr 2016 02:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM1wnfqWBHz6 for ; Fri, 29 Apr 2016 02:59:18 -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 A662412B032 for ; Fri, 29 Apr 2016 02:59:18 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id CE7C8600E4; Fri, 29 Apr 2016 11:59:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461923956; bh=XZol6EIgX0wDwJzqTBKk2L/QZFV90VugUF3NYPxsGtI=; h=From:Date:To; b=Pi5ca2zUsuEmVCxHCribGtAzMFLU5Jr6atpe8ieq2OIcfdDBHdG8FQ1b/zuloi+4s nmXnKcnlvqzAObqlWszc+P4EjZCQ/YfEkzc7koYxqdg4EBs3b/2nP6SEvnRLwOaSfF RGUEsdwdYbGNRMDppKjux2bbIQBS17+jKdW0VV1o=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160429092705.GB26370@elstar.local>
Date: Fri, 29 Apr 2016 11:59:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <06CA4144-62D2-45BB-847A-CFCD34882461@nic.cz>
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local>   <20160429092705.GB26370@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 09:59:21 -0000

> On 29 Apr 2016, at 11:27, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Apr 29, 2016 at 10:18:15AM +0200, Ladislav Lhotka wrote:
>> Andy Bierman  writes:
>>=20
>>> On Thu, Apr 28, 2016 at 12:15 PM, Juergen Schoenwaelder <
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>=20
>>>> On Mon, Mar 07, 2016 at 11:26:36AM +0100, Juergen Schoenwaelder =
wrote:
>>>>> On Tue, Feb 16, 2016 at 12:42:27PM +0100, Juergen Schoenwaelder =
wrote:
>>>>>>  So perhaps the proposal is to add
>>>>>>=20
>>>>>>    After applying all deviations announced by a server, in any =
order,
>>>>>>    the resulting data model MUST still be valid.
>>>>>>=20
>>>>>>  just before the beginning of section 7.20.3.1?
>>>>>=20
>>>>> I like to see whether we have consensus to add this clarifying
>>>>> sentence. I believe it documents something that we always assumed =
to
>>>>> be true but we did not write it down explicitly. If anyone =
disagrees
>>>>> with adding this clarification, please speak up now.
>>>>>=20
>>>>=20
>>>> I have not heard anyone disagreeing with adding this clarification.
>>>>=20
>>>> Martin did not put this additional sentence into -12 and since we =
seem
>>>> to have consensus on adding this clarification I like to ask him to
>>>> add this sentence if another revision is made before the IESG
>>>> telechat. I am CCing Benoit in case he wants to add this as a =
comment
>>>> to his IESG evaluation record.
>>>>=20
>>>>=20
>>> Was it unclear before that the result of deviations were allowed to =
be
>>> invalid?
>>=20
>> Right, I think it goes pretty much without saying, so this sentence =
is
>> IMO unnecessary.
>>=20
>=20
> Apparently, this was not clear to every reader and hence the proposal
> to add this sentence in order to make this explicit.

It's just hand-waving, and has little to do with the subject of this =
thread.

Lada

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

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





From nobody Fri Apr 29 03:01:46 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02BF12D0A3 for ; Fri, 29 Apr 2016 03:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level: 
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exS3mg1Vw8Ur for ; Fri, 29 Apr 2016 03:01:43 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DACA12D155 for ; Fri, 29 Apr 2016 03:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=344; q=dns/txt; s=iport; t=1461924102; x=1463133702; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=vxupLHsibAFWzN9FJDuqrkjj7QRbUnasvp6popImQCY=; b=W/bJaIbYnc0nv9BrcrcWKTe0FLbPCwbzRfGC4fJua3hLfpqyZTV2PcQc ckcCXeToaha21i9AdLw+0WW8Br8+b1cQfM7JZoUmlrAhm7KSk9IBBbfMV SLSIH3E4Ci3thB3CCPVEjgEaBsMT3ZS6OUboCW4MT6hdTE5si2VYU/DFk k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABLLyNX/xbLJq1ewH2GDwKBeAEBA?= =?us-ascii?q?QEBAWYnhEIBAQQ4QBELGAkWDwkDAgECAUUGAQwIAQGIJsNzAQEBAQEBAQECAQE?= =?us-ascii?q?BAQEBGoYhhEuKEwEEmBGIc4UkgVEBh2iFV48wYoNtOogYAQEB?=
X-IronPort-AV: E=Sophos;i="5.24,551,1454976000"; d="scan'208";a="635409731"
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/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 10:01:40 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3TA1de9018263; Fri, 29 Apr 2016 10:01:39 GMT
To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" , Martin Bjorklund 
References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local>   <20160429092705.GB26370@elstar.local>
From: Benoit Claise 
Message-ID: <57233102.8090206@cisco.com>
Date: Fri, 29 Apr 2016 12:01:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160429092705.GB26370@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Fwd: Multiple deviations with same target
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 10:01:45 -0000

On 4/29/2016 11:27 AM, Juergen Schoenwaelder wrote:
>> Right, I think it goes pretty much without saying, so this sentence is
>> >IMO unnecessary.
>> >
> Apparently, this was not clear to every reader and hence the proposal
> to add this sentence in order to make this explicit.
This is a always a good principle IMO.

Regards, Benoit


From nobody Fri Apr 29 03:29:58 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB512D5F8; Fri, 29 Apr 2016 03:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX3Y4pAm4TXT; Fri, 29 Apr 2016 03:29: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 0F64E12D5ED; Fri, 29 Apr 2016 03:29:45 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A1F31AE0119; Fri, 29 Apr 2016 12:29:43 +0200 (CEST)
Date: Fri, 29 Apr 2016 12:29:43 +0200 (CEST)
Message-Id: <20160429.122943.1926404425708749601.mbj@tail-f.com>
To: tsaad@cisco.com
From: Martin Bjorklund 
In-Reply-To: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com>
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, netmod@ietf.org, teas@ietf.org, draft-ietf-netmod-schema-mount@ietf.org
Subject: Re: [netmod] Use of schema mounts for common model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 10:29:53 -0000

IlRhcmVrIFNhYWQgKHRzYWFkKSIgPHRzYWFkQGNpc2NvLmNvbT4gd3JvdGU6DQo+IEhpIGF1dGhv
cnMvV0csDQo+IA0KPiBJbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRyaXZpbmcg
dGhlIGRlZmluaXRpb24gZm9yIGENCj4gZ2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21h
eSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQgd2hlbg0KPiBuZWNlc3NhcnkpIGZvciBkaWZmZXJlbnQg
ZGF0YSBwbGFuZSB0ZWNobm9sb2dpZXMgKGUuZy4gTVBMUywgT1ROLCBXRE0sDQo+IGV0Yy4pLg0K
PiBSZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBpZGVhIHByZXNlbnRlZCBpbg0KPiBkcmFmdC1p
ZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQsIHdlIGFyZSB0aGlua2luZyB0aGlzIHByb3Bvc2FsIGlz
DQo+IHVzZWZ1bCBhbmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwg
aW4gbXVsdGlwbGUNCj4gcGxhY2VzIGluIHRoZSBZQU5HIHRyZWUgKG9uY2UgcGVyIGVhY2ggdGVj
aG5vbG9neSksIGUuZy46DQo+IOKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1
bGU9aWV0Zi10ZS55YW5nDQo+IOKApi9vdG4vbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVs
ZT1pZXRmLXRlLnlhbmcNCg0KU2NoZW1hIG1vdW50IGlzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQg
c29sdXRpb24gdG8geW91ciBwcm9ibGVtLiAgSQ0KdGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4g
eW91ciBjYXNlIGlzIHRvIGRlZmluZSBncm91cGluZ3MuDQpHcm91cGluZ3MgYXJlIGRlc2lnbmVk
IHRvIGJlIHJlLXVzZWQgYXQgZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUNCmhpZXJhcmNoeS4NCg0K
PiBXZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIg
ZmVlZGJhY2suDQo+IA0KPiBUaGUgZ2VuZXJpYyBURSBtb2RlbCBjdXJyZW50bHkgcmVmZXJlbmNl
cyBkYXRhIG5vZGVzIGluIHRoZSBnbG9iYWwNCj4gdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWlu
dGVyZmFjZXMgbW9kZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUNCj4gcHJvcGVydGllcyBhc3Nv
Y2lhdGVkIHdpdGggYSBzcGVjaWZpYyBkZXZpY2UgaW50ZXJmYWNlKS4gT3VyDQo+IHVuZGVyc3Rh
bmRpbmcgYWZ0ZXIgcmVhZGluZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRyYWZ0IGlzIHRoZSBtb3Vu
dGVkDQo+IG1vZGVsIGNhbiAqbm90KiByZWZlcmVuY2UgYW55IGRhdGEgbm9kZXMgb3V0c2lkZSB0
aGUgc2NvcGUgb2YgdGhlDQo+IG1vdW50LXBvaW50IChlLmcuIGdsb2JhbCBkYXRhIG5vZGVzIGlu
IHRoZSB5YW5nIHRyZWUpLiBUaGlzIHBvc2VzIGENCj4gbGltaXRhdGlvbiBmb3IgdXMsIGRvIHlv
dSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPw0KPiANCj4gT25lIHBvc3NpYmxl
IHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcw0KPiBw
b2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEgbm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3
aXRoIGNvbnRleHQNCj4gbmFtZXMgKGUuZy4gdGhlIGludGVyZmFjZSBuYW1lKS4uIFRoaXMgZGVj
b3VwbGVzIHRoZSBkYXRhLW5vZGVzDQo+IGRlZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwg
ZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUNCj4gKGUuZy4gdGhlIGFjdHVhbCBpbnRlcmZh
Y2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZlZWRiYWNrIG9uDQo+IHRoaXMgb3IgYmV0
dGVyIHN1Z2dlc3Rpb25zPw0KDQpJZiB5b3UgdXNlIGdyb3VwaW5ncyBpbnN0ZWFkLCB5b3UgY2Fu
IHN0aWxsIHVzZSBwcm9wZXIgbGVhZnJlZnMuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gUmVn
YXJkcywNCj4gVGFyZWsNCj4gDQo+IEV4Y2VycHQgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1zY2hl
bWEtbW91bnQNCj4gDQo+IDMuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4xPi4NCj4gQXVnbWVudCBhbmQgVmFs
aWRhdGlvbiBpbiBNb3VudGVkIERhdGENCj4gDQo+IA0KPiAgICBBbGwgcGF0aHMgKGluIGxlYWZy
ZWZzLCBpbnN0YW5jZS1pZGVudGlmaWVycywgWFBhdGggZXhwcmVzc2lvbnMsIGFuZA0KPiAgICB0
YXJnZXQgbm9kZXMgb2YgYXVnbWVudHMpIGluIHRoZSBkYXRhIG1vZGVscyBtb3VudGVkIGF0IGEg
bW91bnQgcG9pbnQNCj4gICAgYXJlIGludGVycHJldGVkIHdpdGggdGhlIG1vdW50IHBvaW50IGFz
IHRoZSByb290IG5vZGUsIGFuZCB0aGUNCj4gICAgbW91bnRlZCBkYXRhIG5vZGVzIGFzIGl0cyBj
aGlsZHJlbi4gIFRoaXMgbWVhbnMgdGhhdCBkYXRhIHdpdGhpbiBhDQo+ICAgIG1vdW50ZWQgc3Vi
dHJlZSBjYW4gbmV2ZXIgcmVmZXIgdG8gZGF0YSBvdXRzaWRlIG9mIHRoaXMgc3VidHJlZS4NCj4g
DQo+IA0KPiANCj4gDQo=


From nobody Fri Apr 29 04:52:37 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50E12D653 for ; Fri, 29 Apr 2016 04:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbgvS-69P1if for ; Fri, 29 Apr 2016 04:52:34 -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 8354612D651 for ; Fri, 29 Apr 2016 04:52:31 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id 2B9FD607E7 for ; Fri, 29 Apr 2016 13:52:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461930750; bh=hGtCznhUOnqojq2ofdokcJDjO1ev4YupZQhXIm2xqKU=; h=From:Date:To; b=m+Mjcpv4cStXuoyeSPHLsVGDwYDmUiCaKK7OGgnMqWppemzSyLI8V2Kims/qSNMmn xZKXVPSFYnbPd7YRBlNipZrOwXbwoat3jwqFYKUim1p0fkoAkCmlooTpX+ZZ2Sa6Na BU4DzRTyiPsybUJZzUZO2c6l6x3lj8uNamLh7h40=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz>
Date: Fri, 29 Apr 2016 13:52:33 +0200
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 11:52:35 -0000

Hi,

if we have

typedef foo {
  type enumeration {
    enum one;
    enum two;
  }
}

typedef bar {
  type foo;
}

what is the set of values permitted for "bar"? Is it empty or the same =
as for "foo"?

Lada

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





From nobody Fri Apr 29 04:57:06 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65112D655 for ; Fri, 29 Apr 2016 04:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id banGr3C0hg47 for ; Fri, 29 Apr 2016 04:57:03 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBA412D652 for ; Fri, 29 Apr 2016 04:57:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 877C31204; Fri, 29 Apr 2016 13:57:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EHRmXDrD-gZi; Fri, 29 Apr 2016 13:56: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; Fri, 29 Apr 2016 13:57:02 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED34C2004E; Fri, 29 Apr 2016 13:57:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pngynD4ah_tE; Fri, 29 Apr 2016 13:57:01 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF6B620047; Fri, 29 Apr 2016 13:57:00 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 29CEB3ABD417; Fri, 29 Apr 2016 13:56:59 +0200 (CEST)
Date: Fri, 29 Apr 2016 13:56:59 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429115659.GA26870@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 11:57:05 -0000

On Fri, Apr 29, 2016 at 01:52:33PM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> if we have
> 
> typedef foo {
>   type enumeration {
>     enum one;
>     enum two;
>   }
> }
> 
> typedef bar {
>   type foo;
> }
> 
> what is the set of values permitted for "bar"? Is it empty or the
> same as for "foo"?

The set is { one, two } - where is the hidden catch??

/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 Apr 29 05:02:41 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800F912D64E for ; Fri, 29 Apr 2016 05:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FYUlTPwjxTn for ; Fri, 29 Apr 2016 05:02:38 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F48912D138 for ; Fri, 29 Apr 2016 05:02:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C480FAFD; Fri, 29 Apr 2016 14:02:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T_IZqm7fJ8g7; Fri, 29 Apr 2016 14:02: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, 29 Apr 2016 14:02:36 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E81832004E; Fri, 29 Apr 2016 14:02:35 +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 3hv-Ddyy8uWX; Fri, 29 Apr 2016 14:02:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 074DD20047; Fri, 29 Apr 2016 14:02:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0E1343ABD50C; Fri, 29 Apr 2016 14:02:35 +0200 (CEST)
Date: Fri, 29 Apr 2016 14:02:34 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429120234.GA26941@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 12:02:40 -0000

On Fri, Apr 29, 2016 at 02:01:08PM +0200, Ladislav Lhotka wrote:
> 
> > On 29 Apr 2016, at 13:56, Juergen Schoenwaelder  wrote:
> > 
> > On Fri, Apr 29, 2016 at 01:52:33PM +0200, Ladislav Lhotka wrote:
> >> Hi,
> >> 
> >> if we have
> >> 
> >> typedef foo {
> >>  type enumeration {
> >>    enum one;
> >>    enum two;
> >>  }
> >> }
> >> 
> >> typedef bar {
> >>  type foo;
> >> }
> >> 
> >> what is the set of values permitted for "bar"? Is it empty or the
> >> same as for "foo"?
> > 
> > The set is { one, two } - where is the hidden catch??
> 
> In sec. 9.6.4 of 6020bis:
> 
>    When an existing enumeration type is restricted, the set of assigned
>    names in the new type MUST be a subset of the base type's set of
>    assigned names.  The value of such an assigned name MUST NOT be
>    changed.
> 
> In our case there are no names assigned in the new type "bar", i.e. empty set (which is a subset of the base type's set).
>

There is no type restriction hence there is no restriction of the
value space.

/js

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


From nobody Fri Apr 29 05:07:36 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7113612D135 for ; Fri, 29 Apr 2016 05:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iirdvC--gyZV for ; Fri, 29 Apr 2016 05:07:33 -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 5545512D65A for ; Fri, 29 Apr 2016 05:01:06 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id BC1C9607E8; Fri, 29 Apr 2016 14:01:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461931264; bh=1ZEoehLgiUNnk04OVRW7GOfF5dpM+INqQ7Fg7I7WTFo=; h=From:Date:To; b=TN+hbZOjkxoosVEF6tC2QkOjw9Cw0FGw/52Qkzm3njZq1fq7gO3cYcoQEVm5Ng4Mk nkqG3/z+AtAPB3Cl4MsTD4c5J1y+qjOn/ohofVejUp/rzlyTeXsTVN5h7ANth3BZYE G2QzwfBnSHWdjl4QtxStD2vi/djiMr1Kq/lrO32o=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160429115659.GA26870@elstar.local>
Date: Fri, 29 Apr 2016 14:01:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:07:34 -0000

> On 29 Apr 2016, at 13:56, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Apr 29, 2016 at 01:52:33PM +0200, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> if we have
>>=20
>> typedef foo {
>>  type enumeration {
>>    enum one;
>>    enum two;
>>  }
>> }
>>=20
>> typedef bar {
>>  type foo;
>> }
>>=20
>> what is the set of values permitted for "bar"? Is it empty or the
>> same as for "foo"?
>=20
> The set is { one, two } - where is the hidden catch??

In sec. 9.6.4 of 6020bis:

   When an existing enumeration type is restricted, the set of assigned
   names in the new type MUST be a subset of the base type's set of
   assigned names.  The value of such an assigned name MUST NOT be
   changed.

In our case there are no names assigned in the new type "bar", i.e. =
empty set (which is a subset of the base type's set).

Lada

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

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





From nobody Fri Apr 29 05:19:11 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE9812D65D for ; Fri, 29 Apr 2016 05:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7icfnJTBobiF for ; Fri, 29 Apr 2016 05:19:06 -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 8A65212D138 for ; Fri, 29 Apr 2016 05:19:06 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id 336FA60802; Fri, 29 Apr 2016 14:19:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461932345; bh=eYvctKOIxShsVaSArHSgkoBeVRae8ca1nCRWUnpjZRE=; h=From:Date:To; b=xZbHF7w6ZgUhz5KWKNge3quq4MePzueD9v8aqLEyMeE/8vHXeWwJGgYtbuLKy070s uyNhzAjL3tfwWIxmRxao0kPo3402RlH3zA/6q6XTbD9g5HemJj+f6ZAzMTyHGrPlR5 Ua//3CgdpOc7OvK9ccvEPQ61GYN5e+rLy/+H6tnE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160429120234.GA26941@elstar.local>
Date: Fri, 29 Apr 2016 14:19:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz>
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:19:09 -0000

> On 29 Apr 2016, at 14:02, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Apr 29, 2016 at 02:01:08PM +0200, Ladislav Lhotka wrote:
>>=20
>>> On 29 Apr 2016, at 13:56, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Fri, Apr 29, 2016 at 01:52:33PM +0200, Ladislav Lhotka wrote:
>>>> Hi,
>>>>=20
>>>> if we have
>>>>=20
>>>> typedef foo {
>>>> type enumeration {
>>>>   enum one;
>>>>   enum two;
>>>> }
>>>> }
>>>>=20
>>>> typedef bar {
>>>> type foo;
>>>> }
>>>>=20
>>>> what is the set of values permitted for "bar"? Is it empty or the
>>>> same as for "foo"?
>>>=20
>>> The set is { one, two } - where is the hidden catch??
>>=20
>> In sec. 9.6.4 of 6020bis:
>>=20
>>   When an existing enumeration type is restricted, the set of =
assigned
>>   names in the new type MUST be a subset of the base type's set of
>>   assigned names.  The value of such an assigned name MUST NOT be
>>   changed.
>>=20
>> In our case there are no names assigned in the new type "bar", i.e. =
empty set (which is a subset of the base type's set).
>>=20
>=20
> There is no type restriction hence there is no restriction of the
> value space.

The problem here is that enum statements aren't really restrictions but =
rather specify the new set of values. It would be kind of discontinuos: =
with

typedef bar {
 type foo {
   enum one;
   enum two;
 }
}

the "bar" set would be {one, two}. If I remove the "enum two;" =
statement, the set would be just {one}, but then if I remove the "enum =
one;" statement, the set would again become {one, two}.

Lada

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

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





From nobody Fri Apr 29 05:30:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3D12D130 for ; Fri, 29 Apr 2016 05:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzrMBRElMsrP for ; Fri, 29 Apr 2016 05:30:30 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF36912D12B for ; Fri, 29 Apr 2016 05:30:29 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B8A611CA; Fri, 29 Apr 2016 14:30: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 y28vF9JWuhwf; Fri, 29 Apr 2016 14:30: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, 29 Apr 2016 14:30:27 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0F3020047; Fri, 29 Apr 2016 14:30:27 +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 q6Bi2oRnp8cd; Fri, 29 Apr 2016 14:30:25 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B80E52004A; Fri, 29 Apr 2016 14:30:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C0C4E3ABD708; Fri, 29 Apr 2016 14:30:25 +0200 (CEST)
Date: Fri, 29 Apr 2016 14:30:25 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429123025.GD26941@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 12:30:32 -0000

On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote:
> 
> The problem here is that enum statements aren't really restrictions but rather specify the new set of values. It would be kind of discontinuos: with
> 
> typedef bar {
>  type foo {
>    enum one;
>    enum two;
>  }
> }
> 
> the "bar" set would be {one, two}. If I remove the "enum two;" statement, the set would be just {one}, but then if I remove the "enum one;" statement, the set would again become {one, two}.
>

So what? Apparently, being able to use foo without having to repeat
all values of foo is the main reason to define foo in the first place.

/js

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


From nobody Fri Apr 29 05:36:57 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7485E12D661 for ; Fri, 29 Apr 2016 05:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN4rzKXb5-By for ; Fri, 29 Apr 2016 05:36: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 5B1B912D65B for ; Fri, 29 Apr 2016 05:36:53 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id 147A461784 for ; Fri, 29 Apr 2016 14:36:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461933412; bh=7VJNaWOXRDPTL3WnAso6m6n9a0Ut1Yg6Zvm2P1/Rx9U=; h=From:Date:To; b=nmbQ+XUL9Q7mBIz1Q+loDDt1Db81hSt6U0c3h/riJW+2Qpuf6foBsX8VbdpdZIy3F p4y3cdc9vO3Jmv9KMmd7MLOBe8ZWck0R9+xO2u27GSmtG+21QC7hXoh5b6e85Oa5XK yug1DlRGQVojCHlZ6atzpid8sEEsJKXzlkVe4NuM=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160429123025.GD26941@elstar.local>
Date: Fri, 29 Apr 2016 14:36:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz>
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local>
To: NETMOD WG 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:36:55 -0000

> On 29 Apr 2016, at 14:30, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote:
>>=20
>> The problem here is that enum statements aren't really restrictions =
but rather specify the new set of values. It would be kind of =
discontinuos: with
>>=20
>> typedef bar {
>> type foo {
>>  enum one;
>>  enum two;
>> }
>> }
>>=20
>> the "bar" set would be {one, two}. If I remove the "enum two;" =
statement, the set would be just {one}, but then if I remove the "enum =
one;" statement, the set would again become {one, two}.
>>=20
>=20
> So what? Apparently, being able to use foo without having to repeat
> all values of foo is the main reason to define foo in the first place.

So what about this:

typedef bar {
 type foo {
   enum one {
     if-feature fancy;
   }
 }
}

If "fancy" feature is supported then the "bar" set is {one}. But if it =
isn't supported, then what?

Lada

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

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





From nobody Fri Apr 29 05:41:15 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D138212D527 for ; Fri, 29 Apr 2016 05:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMFQB5Y2W4Jx for ; Fri, 29 Apr 2016 05:41:12 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1E212B049 for ; Fri, 29 Apr 2016 05:41:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 949EB11CD; Fri, 29 Apr 2016 14:41:10 +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 lWcsO8jbl8x5; Fri, 29 Apr 2016 14:40:48 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Apr 2016 14:41:09 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DFF020050; Fri, 29 Apr 2016 14:41:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pEF9s3yL4inT; Fri, 29 Apr 2016 14:41:08 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 940F32004A; Fri, 29 Apr 2016 14:41:08 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C40673ABD835; Fri, 29 Apr 2016 14:41:07 +0200 (CEST)
Date: Fri, 29 Apr 2016 14:41:07 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429124105.GE26941@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 12:41:14 -0000

On Fri, Apr 29, 2016 at 02:36:55PM +0200, Ladislav Lhotka wrote:
> 
> > On 29 Apr 2016, at 14:30, Juergen Schoenwaelder  wrote:
> > 
> > On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote:
> >> 
> >> The problem here is that enum statements aren't really restrictions but rather specify the new set of values. It would be kind of discontinuos: with
> >> 
> >> typedef bar {
> >> type foo {
> >>  enum one;
> >>  enum two;
> >> }
> >> }
> >> 
> >> the "bar" set would be {one, two}. If I remove the "enum two;" statement, the set would be just {one}, but then if I remove the "enum one;" statement, the set would again become {one, two}.
> >> 
> > 
> > So what? Apparently, being able to use foo without having to repeat
> > all values of foo is the main reason to define foo in the first place.
> 
> So what about this:
> 
> typedef bar {
>  type foo {
>    enum one {
>      if-feature fancy;
>    }
>  }
> }
> 
> If "fancy" feature is supported then the "bar" set is {one}. But if it isn't supported, then what?
>

If the "fancy" feature is not set, the value set of "bar" is {} (since
there is a restriction reducing the value set to an empty set).

/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 Apr 29 05:57:37 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1EF12D0E5 for ; Fri, 29 Apr 2016 05:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI7uzPKP8KNP for ; Fri, 29 Apr 2016 05:57:35 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2865E12B02D for ; Fri, 29 Apr 2016 05:57:35 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id 5845F600E1; Fri, 29 Apr 2016 14:57:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461934653; bh=1cNulHFKU+95meYmrngx8+qIA13lC8AWCP5awkyJOJw=; h=From:Date:To; b=wO+M68u1RWXRJp2VySr4PXu3tSJQkSOhlF1Vbux3qNTY07O+46RoPrXovdEJKwtT4 Bc7H11aBIFzJapHo7t/x0ZbUXFUB99rK/WWF9yg9UYXikLpnVfRAzqyAiHLWzrdUNP wWU6EHFl97NOlcLmLEF7o7+eSBj3aQs67DW8IPdk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160429124105.GE26941@elstar.local>
Date: Fri, 29 Apr 2016 14:57:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:57:36 -0000

> On 29 Apr 2016, at 14:41, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Apr 29, 2016 at 02:36:55PM +0200, Ladislav Lhotka wrote:
>>=20
>>> On 29 Apr 2016, at 14:30, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote:
>>>>=20
>>>> The problem here is that enum statements aren't really restrictions =
but rather specify the new set of values. It would be kind of =
discontinuos: with
>>>>=20
>>>> typedef bar {
>>>> type foo {
>>>> enum one;
>>>> enum two;
>>>> }
>>>> }
>>>>=20
>>>> the "bar" set would be {one, two}. If I remove the "enum two;" =
statement, the set would be just {one}, but then if I remove the "enum =
one;" statement, the set would again become {one, two}.
>>>>=20
>>>=20
>>> So what? Apparently, being able to use foo without having to repeat
>>> all values of foo is the main reason to define foo in the first =
place.
>>=20
>> So what about this:
>>=20
>> typedef bar {
>> type foo {
>>   enum one {
>>     if-feature fancy;
>>   }
>> }
>> }
>>=20
>> If "fancy" feature is supported then the "bar" set is {one}. But if =
it isn't supported, then what?
>>=20
>=20
> If the "fancy" feature is not set, the value set of "bar" is {} (since
> there is a restriction reducing the value set to an empty set).

I think you have no support for this conclusion in 6020bis text, it =
depends on what "conditional" means. One defensible interpretation is =
that=20

type foo {
  enum one {
    if-feature fancy;
  }
}

is equivalent to

type foo {
}

if feature "fancy" isn't supported.

Or are you saying that "type foo {}" is not the same as "type foo;"?

Lada

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

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





From nobody Fri Apr 29 06:07:19 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551F512D664 for ; Fri, 29 Apr 2016 06:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48p1vC9jN8YE for ; Fri, 29 Apr 2016 06:07: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 38B1C12D671 for ; Fri, 29 Apr 2016 06:07:17 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F215B94; Fri, 29 Apr 2016 15:07: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 7iANzk_pF05S; Fri, 29 Apr 2016 15:06:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Apr 2016 15:07:15 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5984E2004A; Fri, 29 Apr 2016 15:07:15 +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 qgxoZQspwON0; Fri, 29 Apr 2016 15:07: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 C262020047; Fri, 29 Apr 2016 15:07:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2DC663ABD8EC; Fri, 29 Apr 2016 15:07:12 +0200 (CEST)
Date: Fri, 29 Apr 2016 15:07:12 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429130712.GA27146@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 13:07:19 -0000

On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
> 
> Or are you saying that "type foo {}" is not the same as "type foo;"?
>

Yes, "type foo {}" has a restriction while "type foo;" does not have a
restriction. OK, I think I see your point now that we have a case
where there is a subtle difference between "{}" and ";" and so you
suggest to interpret "type foo {}" as all values of foo?

/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 Apr 29 06:28:38 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6B12D118 for ; Fri, 29 Apr 2016 06:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eZaw8sV20XZ for ; Fri, 29 Apr 2016 06:28:34 -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 385ED12B036 for ; Fri, 29 Apr 2016 06:28:34 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id 7578B60799; Fri, 29 Apr 2016 15:28:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461936511; bh=sjyIOk61x9xZoAkDIP3uwG4AnTRaikP5xYyUtVQyvX0=; h=From:Date:To; b=Hx1g0T/Lwnb1NsdibmUDkLqHnnPD6wn7U8vj5MQAlnb690yUl3zSwg2nXhtnGcXxq KltFPStd57gulUaxOR8woLP2R2RT5OKZsBx5wAy49JXMp0YeEzTT1FDeZ5ZR0pQrEM C2yfvpB2K+yYznfEOPsJtrT1VCrc2dLqPrSo/4gE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160429130712.GA27146@elstar.local>
Date: Fri, 29 Apr 2016 15:28:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz>
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 13:28:36 -0000

> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>=20
>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>=20
>=20
> Yes, "type foo {}" has a restriction while "type foo;" does not have a
> restriction. OK, I think I see your point now that we have a case
> where there is a subtle difference between "{}" and ";" and so you
> suggest to interpret "type foo {}" as all values of foo?

Now it becomes really interesting! :-) I wonder if there is any YANG =
parser out there that is able to distinguish those two syntactic forms. =
I think they must be considered identical by all means.

My point was that the text about restrictions of the "enumeration" type =
is unclear, and IMO the more logical answer to my original question is =
that the "bar" set is empty. This is most likely not the 1.0 semantics =
though.

Lada

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

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





From nobody Fri Apr 29 06:30:06 2016
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B7612D106; Fri, 29 Apr 2016 06:30:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160429133005.12413.20638.idtracker@ietfa.amsl.com>
Date: Fri, 29 Apr 2016 06:30:05 -0700
Archived-At: 
Cc: netmod-chairs@ietf.org, netmod@ietf.org
Subject: [netmod] netmod - New Meeting Session Request for IETF 96
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 13:30:05 -0000

A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group.


---------------------------------------------------------
Working Group Name: NETCONF Data Modeling Language
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 80
Conflicts to Avoid: 
 First Priority: netconf rtgwg 
 Second Priority: i2rs anima 
 Third Priority: saag


Special Requests:
  
---------------------------------------------------------


From nobody Fri Apr 29 06:37:18 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917A612D6A1 for ; Fri, 29 Apr 2016 06:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqJ5ktMtQcUe for ; Fri, 29 Apr 2016 06:37:10 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FBC12D69B for ; Fri, 29 Apr 2016 06:37:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E22B074B; Fri, 29 Apr 2016 15:37:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kjUXIR6rbYIZ; Fri, 29 Apr 2016 15:36: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, 29 Apr 2016 15:37:08 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B8552004E; Fri, 29 Apr 2016 15:37:08 +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 bXGaBTUrCIr3; Fri, 29 Apr 2016 15:37:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B92242004A; Fri, 29 Apr 2016 15:37:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1A5C83ABDA37; Fri, 29 Apr 2016 15:37:05 +0200 (CEST)
Date: Fri, 29 Apr 2016 15:37:05 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160429133705.GA27239@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 29 Apr 2016 13:37:16 -0000

On Fri, Apr 29, 2016 at 03:28:34PM +0200, Ladislav Lhotka wrote:
> 
> > On 29 Apr 2016, at 15:07, Juergen Schoenwaelder  wrote:
> > 
> > On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
> >> 
> >> Or are you saying that "type foo {}" is not the same as "type foo;"?
> >> 
> > 
> > Yes, "type foo {}" has a restriction while "type foo;" does not have a
> > restriction. OK, I think I see your point now that we have a case
> > where there is a subtle difference between "{}" and ";" and so you
> > suggest to interpret "type foo {}" as all values of foo?
> 
> Now it becomes really interesting! :-) I wonder if there is any YANG parser out there that is able to distinguish those two syntactic forms. I think they must be considered identical by all means.
> 
> My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not the 1.0 semantics though.
>

I see the reasoning but then having to repeat all enumerations
whenever you use foo seems not at all user friendly...

/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 Apr 29 06:51:31 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF47912D69F for ; Fri, 29 Apr 2016 06:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyVJzKyHtmcp for ; Fri, 29 Apr 2016 06:51: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 98AAB12D6A5 for ; Fri, 29 Apr 2016 06:51:24 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 55CC71AE0119; Fri, 29 Apr 2016 15:51:23 +0200 (CEST)
To: Ladislav Lhotka 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz>
From: Per Hedeland 
Message-ID: <572366DA.4050302@tail-f.com>
Date: Fri, 29 Apr 2016 15:51:22 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 13:51:29 -0000

On 2016-04-29 15:28, Ladislav Lhotka wrote:
> 
>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder  wrote:
>>
>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>
>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>
>>
>> Yes, "type foo {}" has a restriction while "type foo;" does not have a
>> restriction. OK, I think I see your point now that we have a case
>> where there is a subtle difference between "{}" and ";" and so you
>> suggest to interpret "type foo {}" as all values of foo?
> 
> Now it becomes really interesting! :-) I wonder if there is any YANG parser out there that is able to distinguish those two syntactic forms. I think they must be considered identical by all means.

+1. Though if I read the ABNF right, "type foo {}" is actually illegal
if foo is an enum type.:-)

> My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not the 1.0 semantics though.

No, it isn't - and I think the answer to your *original* question is
quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
says:

   An enumeration can be restricted with the "enum" (Section 9.6.4)
   statement.

If there is no "enum" statement, there is no restriction, and thus foo
and bar are identical. The "if-feature removes all the enum
restrictions" case is perhaps ambiguous with an "extremely literal"
interpretation of "if-feature", but to me (just having implemented
if-feature for enums/bits in our compiler) it is obvious that this case
too is a restriction and not an identity - the if-feature only modifies
the specifics of the restriction.

But adding some text that clarifies this can't hurt I guess (just like
the text that points out that the outcome of if-feature evaluation does
not affect the value assignment).

--Per


From nobody Fri Apr 29 07:15:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99A412D0F8 for ; Fri, 29 Apr 2016 07:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3LkeU0-x_JQ for ; Fri, 29 Apr 2016 07:15: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 032F012D14D for ; Fri, 29 Apr 2016 07:15:29 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id 969A260822; Fri, 29 Apr 2016 16:15:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461939327; bh=7ZtzL6E8q9N07dY70m5UwDAX3tZr/UQUbIl4LpGfatM=; h=From:Date:To; b=kpkW9ZnUxxOkXhZAC3lzotfxJHf3rkwNQPCQoQu3w4ZWfbUUiuxWULRsQpQ0lyX7z ULqRhmykUOekuNe2G/naqrpsQF9sslXun7rqjuHp/1+JBe8CKPlgK0lhyXQaV4GmwS DxQdLtdv/T0mAGLGvA0vlzKRe8715S5GDETwOSsI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <572366DA.4050302@tail-f.com>
Date: Fri, 29 Apr 2016 16:15:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C713E00-7CBD-4DC7-BCF7-9FC502124D46@nic.cz>
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz> <572366DA.4050302@tail-f.com>
To: Per Hedeland 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 14:15:31 -0000

> On 29 Apr 2016, at 15:51, Per Hedeland  wrote:
>=20
> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>=20
>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>=20
>>>> Or are you saying that "type foo {}" is not the same as "type =
foo;"?
>>>>=20
>>>=20
>>> Yes, "type foo {}" has a restriction while "type foo;" does not have =
a
>>> restriction. OK, I think I see your point now that we have a case
>>> where there is a subtle difference between "{}" and ";" and so you
>>> suggest to interpret "type foo {}" as all values of foo?
>>=20
>> Now it becomes really interesting! :-) I wonder if there is any YANG =
parser out there that is able to distinguish those two syntactic forms. =
I think they must be considered identical by all means.
>=20
> +1. Though if I read the ABNF right, "type foo {}" is actually illegal
> if foo is an enum type.:-)

I don't think so:

   type-stmt           =3D type-keyword sep identifier-ref-arg-str =
optsep
                         (";" /
                          "{" stmtsep
                              [type-body-stmts]
                          "}") stmtsep

Everything inside the braces is optional.
=20
>=20
>> My point was that the text about restrictions of the "enumeration" =
type is unclear, and IMO the more logical answer to my original question =
is that the "bar" set is empty. This is most likely not the 1.0 =
semantics though.
>=20
> No, it isn't - and I think the answer to your *original* question is
> quite clearly "bar is the same set as foo" in both 1 and 1.1, since =
1.1
> says:
>=20
>   An enumeration can be restricted with the "enum" (Section 9.6.4)
>   statement.
>=20
> If there is no "enum" statement, there is no restriction, and thus foo
> and bar are identical. The "if-feature removes all the enum
> restrictions" case is perhaps ambiguous with an "extremely literal"
> interpretation of "if-feature", but to me (just having implemented
> if-feature for enums/bits in our compiler) it is obvious that this =
case
> too is a restriction and not an identity - the if-feature only =
modifies
> the specifics of the restriction.

Yes, this makes sense, too, but needs to be explained. In a way, =
solution Y10-02 would have been more straightforward.

Lada

>=20
> But adding some text that clarifies this can't hurt I guess (just like
> the text that points out that the outcome of if-feature evaluation =
does
> not affect the value assignment).
>=20
> --Per

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





From nobody Fri Apr 29 07:32:36 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B212D691 for ; Fri, 29 Apr 2016 07:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F2YSvLYU8JN for ; Fri, 29 Apr 2016 07:32:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 42BE312D6A4 for ; Fri, 29 Apr 2016 07:32:20 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id C6B0C1AE0119; Fri, 29 Apr 2016 16:32:18 +0200 (CEST)
To: Ladislav Lhotka 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz> <572366DA.4050302@tail-f.com> <6C713E00-7CBD-4DC7-BCF7-9FC502124D46@nic.cz>
From: Per Hedeland 
Message-ID: <57237072.2030900@tail-f.com>
Date: Fri, 29 Apr 2016 16:32:18 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <6C713E00-7CBD-4DC7-BCF7-9FC502124D46@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 14:32:33 -0000

On 2016-04-29 16:15, Ladislav Lhotka wrote:
> 
>> On 29 Apr 2016, at 15:51, Per Hedeland  wrote:
>>
>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>
>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder  wrote:
>>>>
>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>>
>>>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>>>
>>>>
>>>> Yes, "type foo {}" has a restriction while "type foo;" does not have a
>>>> restriction. OK, I think I see your point now that we have a case
>>>> where there is a subtle difference between "{}" and ";" and so you
>>>> suggest to interpret "type foo {}" as all values of foo?
>>>
>>> Now it becomes really interesting! :-) I wonder if there is any YANG parser out there that is able to distinguish those two syntactic forms. I think they must be considered identical by all means.
>>
>> +1. Though if I read the ABNF right, "type foo {}" is actually illegal
>> if foo is an enum type.:-)
> 
> I don't think so:
> 
>    type-stmt           = type-keyword sep identifier-ref-arg-str optsep
>                          (";" /
>                           "{" stmtsep
>                               [type-body-stmts]
>                           "}") stmtsep
> 
> Everything inside the braces is optional.

Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
flipping between the two) has:

   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              type-body-stmts
                          "}")

>>> My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not the 1.0 semantics though.
>>
>> No, it isn't - and I think the answer to your *original* question is
>> quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
>> says:
>>
>>   An enumeration can be restricted with the "enum" (Section 9.6.4)
>>   statement.
>>
>> If there is no "enum" statement, there is no restriction, and thus foo
>> and bar are identical. The "if-feature removes all the enum
>> restrictions" case is perhaps ambiguous with an "extremely literal"
>> interpretation of "if-feature", but to me (just having implemented
>> if-feature for enums/bits in our compiler) it is obvious that this case
>> too is a restriction and not an identity - the if-feature only modifies
>> the specifics of the restriction.
> 
> Yes, this makes sense, too, but needs to be explained.

I think some text would be appreciated if you think it is needed.

> In a way, solution Y10-02 would have been more straightforward.

Please don't do that.

--Per

> Lada
> 
>>
>> But adding some text that clarifies this can't hurt I guess (just like
>> the text that points out that the outcome of if-feature evaluation does
>> not affect the value assignment).
>>
>> --Per
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Fri Apr 29 08:07:47 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EF412D125 for ; Fri, 29 Apr 2016 08:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neKu91O4ojNT for ; Fri, 29 Apr 2016 08:07:43 -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 7BA4912B03A for ; Fri, 29 Apr 2016 08:07:41 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb] (unknown [IPv6:2001:718:1a02:1:9564:50a0:dd9:13bb]) by mail.nic.cz (Postfix) with ESMTPSA id DE287607E5; Fri, 29 Apr 2016 17:07:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461942459; bh=R3m78Aad/9YBDgIxmdECqU1jkTyu+z2kyaIh3grmeOU=; h=From:Date:To; b=LwVvtYoTlAXopn4ZBVY2felYFnGR6RE2ySefF0iOb7wtlEvskr0z2dStqZV+Bdes7 sd1eaIN173dJXQ4Yjcjj5m9SjuLKX9Ri9MmOmyh9YRMBZ+74HvSmol7FDcEU647N1y g01LtXe1OeE4UQkRwoS971i4Wde107cDY+9VFEMs=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <57237072.2030900@tail-f.com>
Date: Fri, 29 Apr 2016 17:07:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D32FB4D-07DD-4445-8488-1064978C3AF0@nic.cz>
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz> <572366DA.4050302@tail-f.com> <6C713E00-7CBD-4DC7-BCF7-9FC502124D46@nic.cz> <57237072.2030900@tail-f.com>
To: Per Hedeland 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 15:07:46 -0000

> On 29 Apr 2016, at 16:32, Per Hedeland  wrote:
>=20
> On 2016-04-29 16:15, Ladislav Lhotka wrote:
>>=20
>>> On 29 Apr 2016, at 15:51, Per Hedeland  wrote:
>>>=20
>>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>>=20
>>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder =
 wrote:
>>>>>=20
>>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>>>=20
>>>>>> Or are you saying that "type foo {}" is not the same as "type =
foo;"?
>>>>>>=20
>>>>>=20
>>>>> Yes, "type foo {}" has a restriction while "type foo;" does not =
have a
>>>>> restriction. OK, I think I see your point now that we have a case
>>>>> where there is a subtle difference between "{}" and ";" and so you
>>>>> suggest to interpret "type foo {}" as all values of foo?
>>>>=20
>>>> Now it becomes really interesting! :-) I wonder if there is any =
YANG parser out there that is able to distinguish those two syntactic =
forms. I think they must be considered identical by all means.
>>>=20
>>> +1. Though if I read the ABNF right, "type foo {}" is actually =
illegal
>>> if foo is an enum type.:-)
>>=20
>> I don't think so:
>>=20
>>   type-stmt           =3D type-keyword sep identifier-ref-arg-str =
optsep
>>                         (";" /
>>                          "{" stmtsep
>>                              [type-body-stmts]
>>                          "}") stmtsep
>>=20
>> Everything inside the braces is optional.
>=20
> Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
> flipping between the two) has:
>=20
>   type-stmt           =3D type-keyword sep identifier-ref-arg-str =
optsep
>                         (";" /
>                          "{" stmtsep
>                              type-body-stmts
>                          "}")
>=20
>>>> My point was that the text about restrictions of the "enumeration" =
type is unclear, and IMO the more logical answer to my original question =
is that the "bar" set is empty. This is most likely not the 1.0 =
semantics though.
>>>=20
>>> No, it isn't - and I think the answer to your *original* question is
>>> quite clearly "bar is the same set as foo" in both 1 and 1.1, since =
1.1
>>> says:
>>>=20
>>>  An enumeration can be restricted with the "enum" (Section 9.6.4)
>>>  statement.
>>>=20
>>> If there is no "enum" statement, there is no restriction, and thus =
foo
>>> and bar are identical. The "if-feature removes all the enum
>>> restrictions" case is perhaps ambiguous with an "extremely literal"
>>> interpretation of "if-feature", but to me (just having implemented
>>> if-feature for enums/bits in our compiler) it is obvious that this =
case
>>> too is a restriction and not an identity - the if-feature only =
modifies
>>> the specifics of the restriction.
>>=20
>> Yes, this makes sense, too, but needs to be explained.
>=20
> I think some text would be appreciated if you think it is needed.

OLD
   When an existing enumeration type is restricted, the set of assigned
   names in the new type MUST be a subset of the base type's set of
   assigned names.  The value of such an assigned name MUST NOT be
   changed.

NEW
   When an existing enumeration type is restricted by means of one or =
more
   "enum" statements (even if any or all of them are disabled through an
   "if-feature" statement), the set of assigned names in the new type =
MUST
   be a subset of the base type's set of assigned names.  The value of =
such
   an assigned name MUST NOT be changed.

   If a new type is derived from an existing enumeration type and no =
"enum"
   restrictions are specified, then the sets of permitted values are the =
same
   for both types.

And the same for bits type, mutatis mutandis.

Lada=20

>=20
>> In a way, solution Y10-02 would have been more straightforward.
>=20
> Please don't do that.
>=20
> --Per
>=20
>> Lada
>>=20
>>>=20
>>> But adding some text that clarifies this can't hurt I guess (just =
like
>>> the text that points out that the outcome of if-feature evaluation =
does
>>> not affect the value assignment).
>>>=20
>>> --Per
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Fri Apr 29 08:46:12 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A77512D0A7 for ; Fri, 29 Apr 2016 08:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0u8kUgBzlnm for ; Fri, 29 Apr 2016 08:46:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BEC0F12B039 for ; Fri, 29 Apr 2016 08:46:09 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 22BAA1AE0119; Fri, 29 Apr 2016 17:46:08 +0200 (CEST)
To: Ladislav Lhotka 
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz> <572366DA.4050302@tail-f.com> <6C713E00-7CBD-4DC7-BCF7-9FC502124D46@nic.cz> <57237072.2030900@tail-f.com> <0D32FB4D-07DD-4445-8488-1064978C3AF0@nic.cz>
From: Per Hedeland 
Message-ID: <572381BF.2090809@tail-f.com>
Date: Fri, 29 Apr 2016 17:46:07 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <0D32FB4D-07DD-4445-8488-1064978C3AF0@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 15:46:11 -0000

On 2016-04-29 17:07, Ladislav Lhotka wrote:
> 
>> On 29 Apr 2016, at 16:32, Per Hedeland  wrote:
>>
>> On 2016-04-29 16:15, Ladislav Lhotka wrote:
>>>
>>>> On 29 Apr 2016, at 15:51, Per Hedeland  wrote:
>>>>
>>>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>>>
>>>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder  wrote:
>>>>>>
>>>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>>>>
>>>>>>> Or are you saying that "type foo {}" is not the same as "type foo;"?
>>>>>>>
>>>>>>
>>>>>> Yes, "type foo {}" has a restriction while "type foo;" does not have a
>>>>>> restriction. OK, I think I see your point now that we have a case
>>>>>> where there is a subtle difference between "{}" and ";" and so you
>>>>>> suggest to interpret "type foo {}" as all values of foo?
>>>>>
>>>>> Now it becomes really interesting! :-) I wonder if there is any YANG parser out there that is able to distinguish those two syntactic forms. I think they must be considered identical by all means.
>>>>
>>>> +1. Though if I read the ABNF right, "type foo {}" is actually illegal
>>>> if foo is an enum type.:-)
>>>
>>> I don't think so:
>>>
>>>   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
>>>                         (";" /
>>>                          "{" stmtsep
>>>                              [type-body-stmts]
>>>                          "}") stmtsep
>>>
>>> Everything inside the braces is optional.
>>
>> Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
>> flipping between the two) has:
>>
>>   type-stmt           = type-keyword sep identifier-ref-arg-str optsep
>>                         (";" /
>>                          "{" stmtsep
>>                              type-body-stmts
>>                          "}")
>>
>>>>> My point was that the text about restrictions of the "enumeration" type is unclear, and IMO the more logical answer to my original question is that the "bar" set is empty. This is most likely not the 1.0 semantics though.
>>>>
>>>> No, it isn't - and I think the answer to your *original* question is
>>>> quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1
>>>> says:
>>>>
>>>>  An enumeration can be restricted with the "enum" (Section 9.6.4)
>>>>  statement.
>>>>
>>>> If there is no "enum" statement, there is no restriction, and thus foo
>>>> and bar are identical. The "if-feature removes all the enum
>>>> restrictions" case is perhaps ambiguous with an "extremely literal"
>>>> interpretation of "if-feature", but to me (just having implemented
>>>> if-feature for enums/bits in our compiler) it is obvious that this case
>>>> too is a restriction and not an identity - the if-feature only modifies
>>>> the specifics of the restriction.
>>>
>>> Yes, this makes sense, too, but needs to be explained.
>>
>> I think some text would be appreciated if you think it is needed.
> 
> OLD
>    When an existing enumeration type is restricted, the set of assigned
>    names in the new type MUST be a subset of the base type's set of
>    assigned names.  The value of such an assigned name MUST NOT be
>    changed.
> 
> NEW
>    When an existing enumeration type is restricted by means of one or more
>    "enum" statements (even if any or all of them are disabled through an
>    "if-feature" statement), the set of assigned names in the new type MUST
>    be a subset of the base type's set of assigned names.  The value of such
>    an assigned name MUST NOT be changed.
> 
>    If a new type is derived from an existing enumeration type and no "enum"
>    restrictions are specified, then the sets of permitted values are the same
>    for both types.
> 
> And the same for bits type, mutatis mutandis.

Agree with the first paragraph, but I do think the second is superfluous
- it just says "if there is no restriction statement, the type isn't
restricted". This is true for all types.

--Per

> Lada 
> 
>>
>>> In a way, solution Y10-02 would have been more straightforward.
>>
>> Please don't do that.
>>
>> --Per
>>
>>> Lada
>>>
>>>>
>>>> But adding some text that clarifies this can't hurt I guess (just like
>>>> the text that points out that the outcome of if-feature evaluation does
>>>> not affect the value assignment).
>>>>
>>>> --Per
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Fri Apr 29 09:17:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEE12D15E; Fri, 29 Apr 2016 09:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level: 
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxWDaSXYfjfe; Fri, 29 Apr 2016 09:17:21 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD3F12D147; Fri, 29 Apr 2016 09:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17876; q=dns/txt; s=iport; t=1461946640; x=1463156240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DN2yQSt7utfpvgKgcKeFzJifVbBYp876IsrpWKjxu9Y=; b=CAh5SmprREyPbPtq4al1SIljgQWoKY4ogW2D14izHMCvoLjTlgZp166d VagvgNC+jXXw2IUl6lFo0GUBvKZYQsFw8rvC6yD6Af8MFvFtyR58VzDa8 ZGO+gm1YF1ZAwHgLIDWiAxxib/fTP7hQ9ORVtjlliS1JlI/BrXTFSwPUg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgDkhyNX/5hdJa1dgmxMU30GtHeEc?= =?us-ascii?q?wENgXYkhWwCHIEOOBQBAQEBAQEBZSeEQgEBBCNWEAIBCA4xAwICAjAUEQIEDgU?= =?us-ascii?q?biA8OszWRIgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdoJWhFSCaSuCKwWNV?= =?us-ascii?q?oVMhHEBhXuIG4FnhE2IXYYkiQsBHgEBQoIFG4FLbAGHRCUYAX4BAQE?=
X-IronPort-AV: E=Sophos; i="5.24,552,1454976000"; d="scan'208,217"; a="97431017"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 16:17:19 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3TGHJtj025505 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 16:17:19 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 12:17:17 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 12:17:18 -0400
From: "Tarek Saad (tsaad)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] Use of schema mounts for common model
Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLnp+hBBqAgAAeDQA=
Date: Fri, 29 Apr 2016 16:17:18 +0000
Message-ID: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com>
In-Reply-To: <20160429.122943.1926404425708749601.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.64]
Content-Type: multipart/alternative; boundary="_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" 
Subject: Re: [netmod] Use of schema mounts for common model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 16:17:24 -0000

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

VGhhbmtzIE1hcnRpbiwgcGxlYXNlIHNlZSBpbmxpbmUuLg0KDQoNCk9uIDIwMTYtMDQtMjksIDY6
MjkgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWls
LWYuY29tPj4gd3JvdGU6DQoNCiJUYXJlayBTYWFkICh0c2FhZCkiIDx0c2FhZEBjaXNjby5jb208
bWFpbHRvOnRzYWFkQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgYXV0aG9ycy9XRywNCkluIGRyYWZ0
LWlldGYtdGVhcy15YW5nLXRlLCB3ZSBhcmUgZHJpdmluZyB0aGUgZGVmaW5pdGlvbiBmb3IgYQ0K
Z2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21heSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQg
d2hlbg0KbmVjZXNzYXJ5KSBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9naWVzIChl
LmcuIE1QTFMsIE9UTiwgV0RNLA0KZXRjLikuDQpSZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBp
ZGVhIHByZXNlbnRlZCBpbg0KZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LCB3ZSBhcmUg
dGhpbmtpbmcgdGhpcyBwcm9wb3NhbCBpcw0KdXNlZnVsIGFuZCBjYW4gZmFjaWxpdGF0ZSB0aGUg
cmV1c2Ugb2YgdGhlIG91ciBtb2RlbCBpbiBtdWx0aXBsZQ0KcGxhY2VzIGluIHRoZSBZQU5HIHRy
ZWUgKG9uY2UgcGVyIGVhY2ggdGVjaG5vbG9neSksIGUuZy46DQrigKYvbXBscy9tb3VudC1wb2lu
dHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZw0K4oCmL290bi9tb3VudC1wb2ludHMv
bW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZw0KDQpTY2hlbWEgbW91bnQgaXMgcHJvYmFi
bHkgbm90IHRoZSByaWdodCBzb2x1dGlvbiB0byB5b3VyIHByb2JsZW0uICBJDQp0aGluayBhIGJl
dHRlciBzb2x1dGlvbiBpbiB5b3VyIGNhc2UgaXMgdG8gZGVmaW5lIGdyb3VwaW5ncy4NCkdyb3Vw
aW5ncyBhcmUgZGVzaWduZWQgdG8gYmUgcmUtdXNlZCBhdCBkaWZmZXJlbnQgcGxhY2VzIGluIHRo
ZQ0KaGllcmFyY2h5Lg0KDQpXZSB0aG91Z2h0IG9mIHRoaXMgZWFybGllciwgYW5kIGZvdW5kIGdy
b3VwaW5ncyBwb3NlIHRoZWlyIG93biBzZXQgb2YgY2hhbGxlbmdlcyB0b28uLiBTcGVjaWZpY2Fs
bHk6DQotIGEgZ3JvdXBpbmdzIHdpdGggbGVhZnJlZnMgY291bGQgbm90IHJlZmVyZW5jZSBkYXRh
IG5vZGVzIHRoYXQgcmVzaWRlIGluIGFub3RoZXIgZ3JvdXBpbmcNCi0gYSBncm91cGluZyB3aXRo
IGxlYWZyZWZzIG9mIHJlbGF0aXZlIHBhdGggd2VyZSBjaGFsbGVuZ2Ugd2hlbiB0aGUgcmVsYXRp
dmUgcGF0aCByZWZlcmVuY2VzIGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgZ3JvdXBpbmcNCi0gdGhl
IGF1Z21lbnRhdGlvbiBvZiB0aGUgZ3JvdXBpbmcgYnkgb3RoZXIgbW9kdWxlcyBpcyBub3QgYXMg
c3RyYWlnaHRmb3J3YXJkDQoNClRoYXQgc2FpZCwgdGhlIGdyb3VwaW5nIHByb3Bvc2FsIHNlZW1z
IHRvDQoNCm9uZSBjb3VsZCBhbHNvIHRoaW5rIHRoYXQgd2l0aCBncm91cGluZ3Mgb25lIGNvdWxk
IGFkZHJlc3MgcmV1c2Ugb2YgdGhlIGEgbW9kZWwgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSBmb3Ig
bG9naWNhbCBkZXZpY2VzIG9yIFZNIChzZWUgYmVsb3cpLiBJbiBmYWN0LCBpbiB5b3VyIGRyYWZ0
IChzZWN0aW9uIDIpIHlvdSBleHBsaWNpdGx5IGRpc2NvdXJhZ2UgdGhpcyBhcHByb2FjaCBhcyBu
b3Qgc2NhbGFibGUgc29sdXRpb24NCg0KDQogICBXaXRoIHRoZSAidXNlcyIgYXBwcm9hY2gsIGll
dGYtaW50ZXJmYWNlcyB3b3VsZCBoYXZlIHRvIGRlZmluZSBhDQogICBncm91cGluZyB3aXRoIGFs
bCBpdHMgbm9kZXMsIGFuZCB0aGUgbmV3IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXMNCiAgIHdv
dWxkIGhhdmUgdG8gdXNlIHRoaXMgZ3JvdXBpbmcuICBUaGlzIGlzIGEgbm90IGEgc2NhbGFibGUg
c29sdXRpb24sDQogICBzaW5jZSBldmVyeSB0aW1lIHRoZXJlIGlzIGEgbmV3IG1vZGVsIGRlZmlu
ZWQsIHdlIHdvdWxkIGhhdmUgdG8NCiAgIHVwZGF0ZSBvdXIgbW9kZWwgZm9yIGxvZ2ljYWwgZGV2
aWNlcyB0byB1c2UgYSBncm91cGluZyBmcm9tIHRoZSBuZXcNCiAgIG1vZGVsLiAgQW5vdGhlciBw
cm9ibGVtIGlzIHRoYXQgdGhpcyBhcHByb2FjaCBjYW5ub3QgaGFuZGxlIHZlbmRvci0NCg0KDQoN
CldlIGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUgeW91ciBm
ZWVkYmFjay4NClRoZSBnZW5lcmljIFRFIG1vZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEg
bm9kZXMgaW4gdGhlIGdsb2JhbA0KdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWludGVyZmFjZXMg
bW9kZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUNCnByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRo
IGEgc3BlY2lmaWMgZGV2aWNlIGludGVyZmFjZSkuIE91cg0KdW5kZXJzdGFuZGluZyBhZnRlciBy
ZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJhZnQgaXMgdGhlIG1vdW50ZWQNCm1vZGVsIGNh
biAqbm90KiByZWZlcmVuY2UgYW55IGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhl
DQptb3VudC1wb2ludCAoZS5nLiBnbG9iYWwgZGF0YSBub2RlcyBpbiB0aGUgeWFuZyB0cmVlKS4g
VGhpcyBwb3NlcyBhDQpsaW1pdGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9u
IGZvciB0aGlzIHByb2JsZW0/DQpPbmUgcG9zc2libGUgc29sdXRpb24gd2UgdGhvdWdodCBvZiB3
YXMgdG8gcmVwbGFjZSB0aGUgbGVhZi1yZWZzDQpwb2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEg
bm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQNCm5hbWVzIChlLmcuIHRo
ZSBpbnRlcmZhY2UgbmFtZSkuLiBUaGlzIGRlY291cGxlcyB0aGUgZGF0YS1ub2Rlcw0KZGVmaW5l
ZCBpbiB0aGUgVEUgZ2VuZXJpYyBtb2RlbCBmcm9tIHRob3NlIGluIHRoZSBnbG9iYWwgdHJlZQ0K
KGUuZy4gdGhlIGFjdHVhbCBpbnRlcmZhY2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZl
ZWRiYWNrIG9uDQp0aGlzIG9yIGJldHRlciBzdWdnZXN0aW9ucz8NCg0KSWYgeW91IHVzZSBncm91
cGluZ3MgaW5zdGVhZCwgeW91IGNhbiBzdGlsbCB1c2UgcHJvcGVyIGxlYWZyZWZzLg0KDQpOb3Qg
aW4gYWxsIGNhc2VzIOKAlCBhcyBkZXNjcmliZWQgYWJvdmUuDQoNClJlZ2FyZHMsDQpUYXJlaw0K
DQoNCg0KL21hcnRpbg0KDQoNCg0KUmVnYXJkcywNClRhcmVrDQpFeGNlcnB0IGZyb20gZHJhZnQt
aWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50DQozLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wMSNzZWN0aW9uLTMuMT4uDQpBdWdtZW50
IGFuZCBWYWxpZGF0aW9uIGluIE1vdW50ZWQgRGF0YQ0KICAgIEFsbCBwYXRocyAoaW4gbGVhZnJl
ZnMsIGluc3RhbmNlLWlkZW50aWZpZXJzLCBYUGF0aCBleHByZXNzaW9ucywgYW5kDQogICAgdGFy
Z2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRlZCBhdCBhIG1v
dW50IHBvaW50DQogICAgYXJlIGludGVycHJldGVkIHdpdGggdGhlIG1vdW50IHBvaW50IGFzIHRo
ZSByb290IG5vZGUsIGFuZCB0aGUNCiAgICBtb3VudGVkIGRhdGEgbm9kZXMgYXMgaXRzIGNoaWxk
cmVuLiAgVGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGENCiAgICBtb3VudGVkIHN1YnRyZWUg
Y2FuIG5ldmVyIHJlZmVyIHRvIGRhdGEgb3V0c2lkZSBvZiB0aGlzIHN1YnRyZWUuDQoNCg==

--_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <6B980E3C296CC94681706D4E9526FA79@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9u
dC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4NCjxkaXY+VGhhbmtzIE1hcnRpbiwgcGxl
YXNlIHNlZSBpbmxpbmUuLjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05B
VFVSRSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz
dHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsi
Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTog
Q29uc29sYXMsIG1vbm9zcGFjZTsiPk9uIDIwMTYtMDQtMjksIDY6MjkgQU0sICZxdW90O01hcnRp
biBCam9ya2x1bmQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJq
QHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog
MTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48YnI+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i
Zm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgYm9yZGVy
LWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsg
Ym9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdp
bjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2PiZxdW90O1RhcmVrIFNhYWQgKHRzYWFkKSZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzYWFkQGNpc2NvLmNvbSI+dHNhYWRAY2lzY28uY29tPC9h
PiZndDsgd3JvdGU6PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ
T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ
Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+SGkgYXV0aG9ycy9XRyw8L2Rpdj4N
CjxkaXY+PC9kaXY+DQo8ZGl2PkluIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLCB3ZSBhcmUgZHJp
dmluZyB0aGUgZGVmaW5pdGlvbiBmb3IgYTwvZGl2Pg0KPGRpdj5nZW5lcmljIFRFIFlBTkcgbW9k
ZWwgdGhhdCBjYW4vbWF5IGJlIHVzZWQgKGFuZCBleHRlbmRlZCB3aGVuPC9kaXY+DQo8ZGl2Pm5l
Y2Vzc2FyeSkgZm9yIGRpZmZlcmVudCBkYXRhIHBsYW5lIHRlY2hub2xvZ2llcyAoZS5nLiBNUExT
LCBPVE4sIFdETSw8L2Rpdj4NCjxkaXY+ZXRjLikuPC9kaXY+DQo8ZGl2PlJldmlld2luZyB0aGUg
c2NoZW1hIG1vdW50IGlkZWEgcHJlc2VudGVkIGluPC9kaXY+DQo8ZGl2PmRyYWZ0LWlldGYtbmV0
bW9kLXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXM8L2Rpdj4N
CjxkaXY+dXNlZnVsIGFuZCBjYW4gZmFjaWxpdGF0ZSB0aGUgcmV1c2Ugb2YgdGhlIG91ciBtb2Rl
bCBpbiBtdWx0aXBsZTwvZGl2Pg0KPGRpdj5wbGFjZXMgaW4gdGhlIFlBTkcgdHJlZSAob25jZSBw
ZXIgZWFjaCB0ZWNobm9sb2d5KSwgZS5nLjo8L2Rpdj4NCjxkaXY+4oCmL21wbHMvbW91bnQtcG9p
bnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlhbmc8L2Rpdj4NCjxkaXY+4oCmL290bi9t
b3VudC1wb2ludHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZzwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2NoZW1hIG1vdW50IGlzIHByb2JhYmx5
IG5vdCB0aGUgcmlnaHQgc29sdXRpb24gdG8geW91ciBwcm9ibGVtLiZuYnNwOyZuYnNwO0k8L2Rp
dj4NCjxkaXY+dGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4geW91ciBjYXNlIGlzIHRvIGRlZmlu
ZSBncm91cGluZ3MuPC9kaXY+DQo8ZGl2Pkdyb3VwaW5ncyBhcmUgZGVzaWduZWQgdG8gYmUgcmUt
dXNlZCBhdCBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZTwvZGl2Pg0KPGRpdj5oaWVyYXJjaHkuPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFt
aWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250
LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+V2UgdGhvdWdo
dCBvZiB0aGlzIGVhcmxpZXIsIGFuZCBmb3VuZCBncm91cGluZ3MgcG9zZSB0aGVpciBvd24gc2V0
IG9mIGNoYWxsZW5nZXMgdG9vLi4gU3BlY2lmaWNhbGx5OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u
dC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPi0gYSBncm91
cGluZ3Mgd2l0aCBsZWFmcmVmcyBjb3VsZCBub3QgcmVmZXJlbmNlIGRhdGEgbm9kZXMgdGhhdCBy
ZXNpZGUgaW4gYW5vdGhlciBncm91cGluZzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAx
MnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPi0gYSBncm91cGluZyB3aXRo
IGxlYWZyZWZzIG9mIHJlbGF0aXZlIHBhdGggd2VyZSBjaGFsbGVuZ2Ugd2hlbiB0aGUgcmVsYXRp
dmUgcGF0aCByZWZlcmVuY2VzIGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgZ3JvdXBpbmc8L2Rpdj4N
CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25v
c3BhY2U7Ij4tIHRoZSBhdWdtZW50YXRpb24gb2YgdGhlIGdyb3VwaW5nIGJ5IG90aGVyIG1vZHVs
ZXMgaXMgbm90IGFzIHN0cmFpZ2h0Zm9yd2FyZDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXpl
OiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0K
PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9z
cGFjZTsiPlRoYXQgc2FpZCwgdGhlIGdyb3VwaW5nIHByb3Bvc2FsIHNlZW1zIHRvJm5ic3A7PC9k
aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywg
bW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZv
bnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+b25lIGNvdWxkIGFsc28gdGhpbmsgdGhh
dCB3aXRoIGdyb3VwaW5ncyBvbmUgY291bGQgYWRkcmVzcyByZXVzZSBvZiB0aGUgYSBtb2RlbCAo
ZS5nLiBJZXRmLWludGVyZmFjZXMpIGZvciBsb2dpY2FsIGRldmljZXMgb3IgVk0gKHNlZSBiZWxv
dykuIEluIGZhY3QsIGluIHlvdXIgZHJhZnQgKHNlY3Rpb24gMikgeW91IGV4cGxpY2l0bHkgZGlz
Y291cmFnZQ0KIHRoaXMgYXBwcm9hY2ggYXMgbm90IHNjYWxhYmxlIHNvbHV0aW9uPC9kaXY+DQo8
ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3Nw
YWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFt
aWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9u
dCBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiIHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tn
cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7V2l0aCB0aGUgJnF1
b3Q7dXNlcyZxdW90OyBhcHByb2FjaCwgaWV0Zi1pbnRlcmZhY2VzIHdvdWxkIGhhdmUgdG8gZGVm
aW5lIGE8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvbnNvbGFzLG1vbm9zcGFjZSIg
c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAw
KTsiPiZuYnNwOyAmbmJzcDtncm91cGluZyB3aXRoIGFsbCBpdHMgbm9kZXMsIGFuZCB0aGUgbmV3
IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9
IkNvbnNvbGFzLG1vbm9zcGFjZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI1NSwgMjU1LCAwKTsiPiZuYnNwOyAmbmJzcDt3b3VsZCBoYXZlIHRvIHVzZSB0
aGlzIGdyb3VwaW5nLiAmbmJzcDtUaGlzIGlzIGEgbm90IGEgc2NhbGFibGUgc29sdXRpb24sPC9m
b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiIHN0eWxlPSJm
b250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJz
cDsgJm5ic3A7c2luY2UgZXZlcnkgdGltZSB0aGVyZSBpcyBhIG5ldyBtb2RlbCBkZWZpbmVkLCB3
ZSB3b3VsZCBoYXZlIHRvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyxt
b25vc3BhY2UiIHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7dXBkYXRlIG91ciBtb2RlbCBmb3IgbG9naWNhbCBk
ZXZpY2VzIHRvIHVzZSBhIGdyb3VwaW5nIGZyb20gdGhlIG5ldzwvZm9udD48L2Rpdj4NCjxkaXY+
PGZvbnQgZmFjZT0iQ29uc29sYXMsbW9ub3NwYWNlIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+
PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsg
Jm5ic3A7bW9kZWwuDQo8L3NwYW4+Jm5ic3A7QW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgdGhpcyBh
cHByb2FjaCBjYW5ub3QgaGFuZGxlIHZlbmRvci08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i
TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBD
b25zb2xhcywgbW9ub3NwYWNlOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMp
OyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRp
bmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR
VU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEs
IDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNv
bGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+
DQo8ZGl2PldlIGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUg
eW91ciBmZWVkYmFjay48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlRoZSBnZW5lcmljIFRFIG1v
ZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEgbm9kZXMgaW4gdGhlIGdsb2JhbDwvZGl2Pg0K
PGRpdj50cmVlIChlLmcuIGZyb20gdGhlIGlldGYtaW50ZXJmYWNlcyBtb2RlbCB0byBkZWZpbmUg
YWRkaXRpb25hbCBURTwvZGl2Pg0KPGRpdj5wcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCBhIHNw
ZWNpZmljIGRldmljZSBpbnRlcmZhY2UpLiBPdXI8L2Rpdj4NCjxkaXY+dW5kZXJzdGFuZGluZyBh
ZnRlciByZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJhZnQgaXMgdGhlIG1vdW50ZWQ8L2Rp
dj4NCjxkaXY+bW9kZWwgY2FuICpub3QqIHJlZmVyZW5jZSBhbnkgZGF0YSBub2RlcyBvdXRzaWRl
IHRoZSBzY29wZSBvZiB0aGU8L2Rpdj4NCjxkaXY+bW91bnQtcG9pbnQgKGUuZy4gZ2xvYmFsIGRh
dGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9zZXMgYTwvZGl2Pg0KPGRpdj5saW1p
dGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9uIGZvciB0aGlzIHByb2JsZW0/
PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5PbmUgcG9zc2libGUgc29sdXRpb24gd2UgdGhvdWdo
dCBvZiB3YXMgdG8gcmVwbGFjZSB0aGUgbGVhZi1yZWZzPC9kaXY+DQo8ZGl2PnBvaW50aW5nIHRv
IHRoZSBnbG9iYWwgZGF0YSBub2RlcyAoZS5nLiBJZXRmLWludGVyZmFjZXMpIHdpdGggY29udGV4
dDwvZGl2Pg0KPGRpdj5uYW1lcyAoZS5nLiB0aGUgaW50ZXJmYWNlIG5hbWUpLi4gVGhpcyBkZWNv
dXBsZXMgdGhlIGRhdGEtbm9kZXM8L2Rpdj4NCjxkaXY+ZGVmaW5lZCBpbiB0aGUgVEUgZ2VuZXJp
YyBtb2RlbCBmcm9tIHRob3NlIGluIHRoZSBnbG9iYWwgdHJlZTwvZGl2Pg0KPGRpdj4oZS5nLiB0
aGUgYWN0dWFsIGludGVyZmFjZSBpZXRmLWludGVyZmFjZXMgbW9kZWwpLiBBbnkgZmVlZGJhY2sg
b248L2Rpdj4NCjxkaXY+dGhpcyBvciBiZXR0ZXIgc3VnZ2VzdGlvbnM/PC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPklmIHlvdSB1c2UgZ3JvdXBpbmdzIGluc3RlYWQsIHlv
dSBjYW4gc3RpbGwgdXNlIHByb3BlciBsZWFmcmVmcy48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdCBpbiBhbGwgY2FzZXMg4oCUIGFzIGRlc2NyaWJlZCBh
Ym92ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m
YW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4
OyI+UmVnYXJkcyw8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29s
YXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5UYXJlazwvc3Bh
bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25v
c3BhY2U7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFuPjwvZGl2
Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0
eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgYm9yZGVyLWxlZnQtY29sb3I6
IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQt
c3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAw
cHggNXB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxk
aXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u
dC1zaXplOiAxMnB4OyI+L21hcnRpbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4
OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJmb250LXNp
emU6IDEycHg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1s
ZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBw
eCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj48L2Rpdj4NCjxkaXY+
UmVnYXJkcyw8L2Rpdj4NCjxkaXY+VGFyZWs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkV4Y2Vy
cHQgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQ8L2Rpdj4NCjxkaXY+PC9kaXY+
DQo8ZGl2PjMuMSZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4xIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4x
PC9hPiZndDsuPC9kaXY+DQo8ZGl2PkF1Z21lbnQgYW5kIFZhbGlkYXRpb24gaW4gTW91bnRlZCBE
YXRhPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7QWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmllcnMsIFhQ
YXRoIGV4cHJlc3Npb25zLCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
dGFyZ2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRlZCBhdCBh
IG1vdW50IHBvaW50PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FyZSBpbnRl
cnByZXRlZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlPC9k
aXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21vdW50ZWQgZGF0YSBub2RlcyBhcyBp
dHMgY2hpbGRyZW4uJm5ic3A7Jm5ic3A7VGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGE8L2Rp
dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW91bnRlZCBzdWJ0cmVlIGNhbiBuZXZl
ciByZWZlciB0byBkYXRhIG91dHNpZGUgb2YgdGhpcyBzdWJ0cmVlLjwvZGl2Pg0KPGRpdj48L2Rp
dj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_--


From nobody Fri Apr 29 09:28:14 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA6D12D15D for ; Fri, 29 Apr 2016 09:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.996
X-Spam-Level: 
X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtwnPtvBpJE1 for ; Fri, 29 Apr 2016 09:28:10 -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 01BB312D147 for ; Fri, 29 Apr 2016 09:28:10 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:188b:9e9a:4fb6:df90] (unknown [IPv6:2a01:5e0:29:ffff:188b:9e9a:4fb6:df90]) by mail.nic.cz (Postfix) with ESMTPSA id A705260829; Fri, 29 Apr 2016 18:28:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1461947288; bh=xSK0IG3fx7ZmH0obcz6IZn+EhcGINUXqllYZM+4PWgs=; h=From:Date:To; b=RUR11LItjNSMYJIU2aks5SJgj2V3xpam43zYZO3FpFQ2gD1vIcVGgBzOPQWwDZzIb 6zFEK9nNVd75IjbmJj00SXEsqgEsOMVK6TVvRsoJYHo4/bbP+ehJY4jema+mQfYmM9 /CDD3BWt8Sd0pbhsrXd5mIPMm8XeisbxMqaBgKEY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <572381BF.2090809@tail-f.com>
Date: Fri, 29 Apr 2016 18:28:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <92FD35B9-EBA9-493C-8BA6-8A93F48A9322@nic.cz>
References: <31355654-7825-49CE-8B97-C31F35A06BF5@nic.cz> <20160429115659.GA26870@elstar.local>  <20160429120234.GA26941@elstar.local> <69E53F65-6E3A-46BA-B955-F2F5A119E98D@nic.cz> <20160429123025.GD26941@elstar.local> <32A79FC4-5BA8-4CB8-8318-772AA3DCCBC3@nic.cz> <20160429124105.GE26941@elstar.local>  <20160429130712.GA27146@elstar.local> <5B8D49EC-D17F-484D-9032-164B2CB196C0@nic.cz> <572366DA.4050302@tail-f.com> <6C713E00-7CBD-4DC7-BCF7-9FC502124D46@nic.cz> <57237072.2030900@tail-f.com> <0D32FB4D-07DD-4445-8488-1064978C3AF0@nic.cz> <572381BF.2090809@tail-f.com>
To: Per Hedeland 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] restricted enumeration
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 16:28:13 -0000

> On 29 Apr 2016, at 17:46, Per Hedeland  wrote:
>=20
> On 2016-04-29 17:07, Ladislav Lhotka wrote:
>>=20
>>> On 29 Apr 2016, at 16:32, Per Hedeland  wrote:
>>>=20
>>> On 2016-04-29 16:15, Ladislav Lhotka wrote:
>>>>=20
>>>>> On 29 Apr 2016, at 15:51, Per Hedeland  wrote:
>>>>>=20
>>>>> On 2016-04-29 15:28, Ladislav Lhotka wrote:
>>>>>>=20
>>>>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder =
 wrote:
>>>>>>>=20
>>>>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote:
>>>>>>>>=20
>>>>>>>> Or are you saying that "type foo {}" is not the same as "type =
foo;"?
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Yes, "type foo {}" has a restriction while "type foo;" does not =
have a
>>>>>>> restriction. OK, I think I see your point now that we have a =
case
>>>>>>> where there is a subtle difference between "{}" and ";" and so =
you
>>>>>>> suggest to interpret "type foo {}" as all values of foo?
>>>>>>=20
>>>>>> Now it becomes really interesting! :-) I wonder if there is any =
YANG parser out there that is able to distinguish those two syntactic =
forms. I think they must be considered identical by all means.
>>>>>=20
>>>>> +1. Though if I read the ABNF right, "type foo {}" is actually =
illegal
>>>>> if foo is an enum type.:-)
>>>>=20
>>>> I don't think so:
>>>>=20
>>>>  type-stmt           =3D type-keyword sep identifier-ref-arg-str =
optsep
>>>>                        (";" /
>>>>                         "{" stmtsep
>>>>                             [type-body-stmts]
>>>>                         "}") stmtsep
>>>>=20
>>>> Everything inside the braces is optional.
>>>=20
>>> Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was
>>> flipping between the two) has:
>>>=20
>>>  type-stmt           =3D type-keyword sep identifier-ref-arg-str =
optsep
>>>                        (";" /
>>>                         "{" stmtsep
>>>                             type-body-stmts
>>>                         "}")
>>>=20
>>>>>> My point was that the text about restrictions of the =
"enumeration" type is unclear, and IMO the more logical answer to my =
original question is that the "bar" set is empty. This is most likely =
not the 1.0 semantics though.
>>>>>=20
>>>>> No, it isn't - and I think the answer to your *original* question =
is
>>>>> quite clearly "bar is the same set as foo" in both 1 and 1.1, =
since 1.1
>>>>> says:
>>>>>=20
>>>>> An enumeration can be restricted with the "enum" (Section 9.6.4)
>>>>> statement.
>>>>>=20
>>>>> If there is no "enum" statement, there is no restriction, and thus =
foo
>>>>> and bar are identical. The "if-feature removes all the enum
>>>>> restrictions" case is perhaps ambiguous with an "extremely =
literal"
>>>>> interpretation of "if-feature", but to me (just having implemented
>>>>> if-feature for enums/bits in our compiler) it is obvious that this =
case
>>>>> too is a restriction and not an identity - the if-feature only =
modifies
>>>>> the specifics of the restriction.
>>>>=20
>>>> Yes, this makes sense, too, but needs to be explained.
>>>=20
>>> I think some text would be appreciated if you think it is needed.
>>=20
>> OLD
>>   When an existing enumeration type is restricted, the set of =
assigned
>>   names in the new type MUST be a subset of the base type's set of
>>   assigned names.  The value of such an assigned name MUST NOT be
>>   changed.
>>=20
>> NEW
>>   When an existing enumeration type is restricted by means of one or =
more
>>   "enum" statements (even if any or all of them are disabled through =
an
>>   "if-feature" statement), the set of assigned names in the new type =
MUST
>>   be a subset of the base type's set of assigned names.  The value of =
such
>>   an assigned name MUST NOT be changed.
>>=20
>>   If a new type is derived from an existing enumeration type and no =
"enum"
>>   restrictions are specified, then the sets of permitted values are =
the same
>>   for both types.
>>=20
>> And the same for bits type, mutatis mutandis.
>=20
> Agree with the first paragraph, but I do think the second is =
superfluous
> - it just says "if there is no restriction statement, the type isn't
> restricted". This is true for all types.

OK, Lada

>=20
> --Per
>=20
>> Lada=20
>>=20
>>>=20
>>>> In a way, solution Y10-02 would have been more straightforward.
>>>=20
>>> Please don't do that.
>>>=20
>>> --Per
>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> But adding some text that clarifies this can't hurt I guess (just =
like
>>>>> the text that points out that the outcome of if-feature evaluation =
does
>>>>> not affect the value assignment).
>>>>>=20
>>>>> --Per
>>>>=20
>>>> --
>>>> 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 Fri Apr 29 10:05:03 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4B12D13E; Fri, 29 Apr 2016 10:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj6_jr2mAGHN; Fri, 29 Apr 2016 10:04:57 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FEE12D12B; Fri, 29 Apr 2016 10:04:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F12602411E5; Fri, 29 Apr 2016 10:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461949496; bh=hwMPH6/7VVfwrOtHc55Mnx3pXmddpW5sg6hBTRTyMXQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cq9qLddIDAStd89DKnNU5e6CfzqtjwRl3eO7JZ2KGG0X9oJdCHKZyr9gmIwHocdW7 K1jWayh+nU0z0X8AzEUBSvpFYPptXFhmLUq0FON9RdstjCfWvVOapDfZNB56tJKZq0 R+ZtaN354zYa/hikw8RmuippPSTNRCSt6Gv+fIR0=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 040EC240E6E; Fri, 29 Apr 2016 10:04:55 -0700 (PDT)
To: "Tarek Saad (tsaad)" , Martin Bjorklund 
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Fri, 29 Apr 2016 13:04:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "teas@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" 
Subject: Re: [netmod] Use of schema mounts for common model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 17:04:59 -0000

With regard to leafrefs trying to point into groupings, would 
instance-identifiers work for your use case?

Yours,
Joel

On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:
> Thanks Martin, please see inline..
>
>
> On 2016-04-29, 6:29 AM, "Martin Bjorklund"  > wrote:
>
>     "Tarek Saad (tsaad)" > wrote:
>
>         Hi authors/WG,
>         In draft-ietf-teas-yang-te, we are driving the definition for a
>         generic TE YANG model that can/may be used (and extended when
>         necessary) for different data plane technologies (e.g. MPLS,
>         OTN, WDM,
>         etc.).
>         Reviewing the schema mount idea presented in
>         draft-ietf-netmod-schema-mount, we are thinking this proposal is
>         useful and can facilitate the reuse of the our model in multiple
>         places in the YANG tree (once per each technology), e.g.:
>         …/mpls/mount-points/mount-point/module=ietf-te.yang
>         …/otn/mount-points/mount-point/module=ietf-te.yang
>
>
>     Schema mount is probably not the right solution to your problem.  I
>     think a better solution in your case is to define groupings.
>     Groupings are designed to be re-used at different places in the
>     hierarchy.
>
>
> We thought of this earlier, and found groupings pose their own set of
> challenges too.. Specifically:
> - a groupings with leafrefs could not reference data nodes that reside
> in another grouping
> - a grouping with leafrefs of relative path were challenge when the
> relative path references data nodes outside the grouping
> - the augmentation of the grouping by other modules is not as
> straightforward
>
> That said, the grouping proposal seems to
>
> one could also think that with groupings one could address reuse of the
> a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In
> fact, in your draft (section 2) you explicitly discourage this approach
> as not scalable solution
>
>
>    With the "uses" approach, ietf-interfaces would have to define a
>    grouping with all its nodes, and the new model for logical devices
>    would have to use this grouping.  This is a not a scalable solution,
>    since every time there is a new model defined, we would have to
>    update our model for logical devices to use a grouping from the new
>    model.  Another problem is that this approach cannot handle vendor-
>
>
>
>         We have a comment/concern/suggestion and we value your feedback.
>         The generic TE model currently references data nodes in the global
>         tree (e.g. from the ietf-interfaces model to define additional TE
>         properties associated with a specific device interface). Our
>         understanding after reading section 3.1 of your draft is the mounted
>         model can *not* reference any data nodes outside the scope of the
>         mount-point (e.g. global data nodes in the yang tree). This poses a
>         limitation for us, do you have a suggestion for this problem?
>         One possible solution we thought of was to replace the leaf-refs
>         pointing to the global data nodes (e.g. Ietf-interfaces) with
>         context
>         names (e.g. the interface name).. This decouples the data-nodes
>         defined in the TE generic model from those in the global tree
>         (e.g. the actual interface ietf-interfaces model). Any feedback on
>         this or better suggestions?
>
>
>     If you use groupings instead, you can still use proper leafrefs.
>
>
> Not in all cases — as described above.
>
> Regards,
> Tarek
>
>
>
>     /martin
>
>
>
>         Regards,
>         Tarek
>         Excerpt from draft-ietf-netmod-schema-mount
>         3.1.
>         Augment and Validation in Mounted Data
>             All paths (in leafrefs, instance-identifiers, XPath
>         expressions, and
>             target nodes of augments) in the data models mounted at a
>         mount point
>             are interpreted with the mount point as the root node, and the
>             mounted data nodes as its children.  This means that data
>         within a
>             mounted subtree can never refer to data outside of this subtree.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Fri Apr 29 12:33:49 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5FD12B04F for ; Fri, 29 Apr 2016 12:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tlPwLV0Ppn8 for ; Fri, 29 Apr 2016 12:33:46 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40BF512D0E2 for ; Fri, 29 Apr 2016 12:33:46 -0700 (PDT)
Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 00098A32A79ED; Fri, 29 Apr 2016 19:33:42 +0000 (GMT)
Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u3TJXjPl032028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2016 19:33:45 GMT
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u3TJXisW013793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Apr 2016 19:33:44 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.238]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 29 Apr 2016 15:33:44 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: EXT Ladislav Lhotka , Dean Bogdanovic 
Thread-Topic: [netmod] input Interface match
Thread-Index: AQHRnJ269dP64/K530y33Rlek8ACEJ+hYckg
Date: Fri, 29 Apr 2016 19:33:44 +0000
Message-ID: 
References: <4480964A-C459-45C9-BCD6-A6EAF409C38D@gmail.com>  <015E0A28-E0A0-415D-AE00-F90CBA444A4A@gmail.com>  <0EC4FCB5-1228-4D98-AC5C-12961765AA5D@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] input Interface match
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 19:33:49 -0000

SGkgZ3V5cywNCg0KSSBhZ3JlZSB0aGF0IHdlIG1heSB3YW50IHRvIGNvbnNpZGVyIG90aGVyIG1l
dGFkYXRhIGl0ZW1zIGFuZCBhbHNvIGFncmVlIHRoZXkgd2lsbCB0ZW5kIHRvIGJlIG1vcmUgaW1w
bGVtZW50YXRpb24tc3BlY2lmaWMuICBCdXQgcmF0aGVyIHRoYW4gaG9sZCB1cCB0aGlzIGJhc2Ug
QUNMIG1vZGVsIGZvciBtZXRhZGF0YSB3aHkgZG9uJ3Qgd2UgdHJlYXQgbWV0YWRhdGEgaW4gZWl0
aGVyIGEgZm9sbG93IHVwIGV4dGVuc2lvbiBkcmFmdCBvciBsZWF2ZSB0aGVtIHRvIHZlbmRvci1z
cGVjaWZpYyBhdWdtZW50YXRpb25zIChpZiB0aGVyZSBpc24ndCBlbm91Z2ggY29tbW9uYWxpdHkp
Lg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgbW9kZWwgc2hvdWxkIGhhdmUgaW5ncmVzcyB2cyBlZ3Jl
c3MgYXMgYW4gYXR0cmlidXRlIG9mIGFuIEFDTC4gQW4gQUNMIGlzIGRpcmVjdGlvbmxlc3Mgb24g
aXRzIG93biBhbmQgZGlyZWN0aW9uIGNhbiBiZSBwYXJ0IG9mIGhvdyBpdCBpcyBhcHBsaWVkIHRv
IGFuIG9iamVjdCAoZS5nLiBtYXliZSBhbiBhdWdtZW50YXRpb24gdG8gdGhlIGludGVyZmFjZXMg
bW9kdWxlIHRvIGFkZCAiaW5ncmVzcy1hY2wiIGFuZCAiZWdyZXNzLWFjbCIgbGVhZnJlZnMpLg0K
DQpKYXNvbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRVhUIExhZGlzbGF2
IExob3RrYSBbbWFpbHRvOmxob3RrYUBuaWMuY3pdIA0KU2VudDogRnJpZGF5LCBBcHJpbCAyMiwg
MjAxNiA5OjQ5DQpUbzogRGVhbiBCb2dkYW5vdmljOyBTdGVybmUsIEphc29uIChOb2tpYSAtIENB
KQ0KQ2M6IG5ldG1vZCBXRw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGlucHV0IEludGVyZmFjZSBt
YXRjaA0KDQpEZWFuIEJvZ2Rhbm92aWMgPGl2YW5kZWFuQGdtYWlsLmNvbT4gd3JpdGVzOg0KDQo+
IEFueSBvdGhlciBvcGluaW9ucyBvbiB0aGlzIGlzc3VlPyBUaGVyZSB3ZXJlIHF1aXRlIGEgZmV3
IGhhbmRzIGluIHRoZSANCj4gYWlyIGR1cmluZyB0aGUgV0cgbWVldGluZw0KDQpVbmxpa2UgcGFj
a2V0IGhlYWRlciBmaWVsZHMsIG1ldGFkYXRhIGFyZSB2ZXJ5IG11Y2ggaW1wbGVtZW50YXRpb24t
c3BlY2lmaWMsIGFuZCBtYXkgYWxzbyBkZXBlbmQgb24gdGhlIGNvbnRleHQgLSBlLmcuIHdoZXRo
ZXIgcGFja2V0IGZpbHRlcmluZyBpcyBpbmdyZXNzIG9yIGVncmVzcy4NCg0KVGhlIGRyYWZ0IGNp
dGVzIG5mdGFibGVzIGJ1dCBpbiBmYWN0IG5mdGFibGVzIGluY2x1ZGVzIHNldmVyYWwgbWV0YWRh
dGEgaXRlbXMsIG5vdCBvbmx5IGlucHV0LWludGVyZmFjZToNCg0KaHR0cDovL3dpa2kubmZ0YWJs
ZXMub3JnL3dpa2ktbmZ0YWJsZXMvaW5kZXgucGhwL01hdGNoaW5nX3BhY2tldF9tZXRhaW5mb3Jt
YXRpb24NCg0KSSB3b3VsZCBzdWdnZXN0IHRvIHRoaW5rIGFib3V0IG90aGVyIGFzcGVjdHMgb2Yg
QUNMIHR5cGUsIHN1Y2ggYXMgImluZ3Jlc3MtYWNsIiB2ZXJzdXMgImVncmVzcy1hY2wiLCBhbmQg
ZWl0aGVyIGRlZmluZSBhZGRpdGlvbmFsIGxlYWZzIGZvciB0aGVzZSBhc3BlY3RzIG9yIHV0aWxp
emUgbXVsdGlwbGUgaW5oZXJpdGFuY2Ugb2YgaWRlbnRpdGllcyB0aGF0IGlzIHBvc3NpYmxlIGlu
IFlBTkcgMS4xLg0KDQpUaGVuLCBJIHdvdWxkIGV4dGVuZCB0aGUgIm1ldGFkYXRhIiBncm91cGlu
ZyB3aXRoIG90aGVyIHJlYXNvbmFibHkgY29tbW9uIG1ldGFkYXRhIGl0ZW1zIChmb3IgZXhhbXBs
ZSwgb3V0cHV0LWludGVyZmFjZSBvciBwYWNrZXQtbGVuZ3RoKSwgYW5kIG1ha2UgZWFjaCBpdGVt
IGNvbmRpdGlvbmFsIHZpYSAid2hlbiIgYW5kL29yICJpZi1mZWF0dXJlIi4NCg0KTGFkYQ0KDQo+
DQo+IERlYW4NCj4NCj4+IE9uIEFwciA4LCAyMDE2LCBhdCA4OjI1IEFNLCBTdGVybmUsIEphc29u
IChOb2tpYSAtIENBKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhp
IERlYW4sDQo+PiAgDQo+PiBXZSBzaG91bGQgcmVtb3ZlIHRoZSBtZXRhZGF0YSBncm91cGluZyBm
cm9tIHRoZSBiYXNlIG1vZGVsLiAgSXQgaXMgb3V0IG9mIHBsYWNlIHdpdGggdGhlIHJlc3Qgb2Yg
dGhlIG1vZGVsIGFuZCBhIGZhaXJseSBjbGVhbiBsaW5lIHRvIGRyYXcgYXMgYSBib3VuZGFyeSBm
b3IgZnV0dXJlIGV4dGVuc2lvbi9hdWdtZW50YXRpb24uDQo+PiAgDQo+PiBSZWdhcmRzLA0KPj4g
SmFzb24NCj4+ICANCj4+IEZyb206IEVYVCBEZWFuIEJvZ2Rhbm92aWMgW21haWx0bzppdmFuZGVh
bkBnbWFpbC5jb21dDQo+PiBTZW50OiBGcmlkYXksIEFwcmlsIDA4LCAyMDE2IDk6MjUNCj4+IFRv
OiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBKQ0KPj4gQ2M6IG5ldG1vZCBXRw0KPj4gU3ViamVj
dDogUmU6IFtuZXRtb2RdIGlucHV0IEludGVyZmFjZSBtYXRjaA0KPj4gIA0KPj4gSmFzb24sDQo+
PiAgDQo+PiBBZnRlciBsb29raW5nIGF0IHRoZSBkb2N1bWVudCBhbmQgdGhlIG1vZGVsLCBpdCBp
cyBhbHNvIGFib3V0IGhhdmluZyBtZXRhZGF0YSBncm91cGluZyBpbiB0aGUgbW9kZWwuIElmIHlv
dSB3YW50IHRvIGhhdmUgbWV0YWRhdGEgZ3JvdXBpbmcgaW4gdGhlIG1vZGVsLCB0aGVuIHlvdSBo
YXZlIHRvIGhhdmUgc29tZXRoaW5nIGluc2lkZSBhbmQgdGhlbiBpbnB1dC1pbnRlcmZhY2UgcXVl
c3Rpb25zIGNvbWVzIHVwLiBJZiB5b3UgZG9u4oCZdCBoYXZlIHRvIGhhdmUgbWV0YWRhdGEgZ3Jv
dXBpbmcgaW4gdGhlIGJhc2UgbW9kZWwsIGV2ZXJ5dGhpbmcgaXMgZWFzeS4NCj4+ICANCj4+IEkg
YmVsaWV2ZSB0aGlzIGlzIHRoZSByaWdodCBxdWVzdGlvbg0KPj4gIA0KPj4gRGVhbg0KPj4gIA0K
Pj4gT24gQXByIDgsIDIwMTYsIGF0IDk6MjAgQU0sIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0Ep
IDxqYXNvbi5zdGVybmVAbm9raWEuY29tIDxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+
IHdyb3RlOg0KPj4gIA0KPj4gSGkgRGVhbiwNCj4+ICANCj4+IEp1c3QgdG8gY2xhcmlmeSAtPiB0
aGUgbWFpbiBxdWVzdGlvbiBwb3NlZCBpbiB0aGUgV0cgbWVldGluZyB3YXMgYWJvdXQgdGhlIGlu
cHV0LWludGVyZmFjZSBtYXRjaCBjcml0ZXJpYS4gIEZyb20gdGhlIG1lZXRpbmcgbWludXRlczoN
Cj4+ICANCj4+IENoYWlyczogY2FsbCBmb3IgaWYgaW50ZXJmYWNlIHNob3VsZCBiZSBpbiBiYXNl
Og0KPj4gICAgIDYgcHJlZmVyIE5PVCBoYXZpbmcgaXQgaW4gdGhlIGRvYyBhdCBhbGwNCj4+ICAg
ICA1IHByZWZlciBoYXZpbmcgaXQgaW4sIGJ1dCBhcyBhIGZlYXR1cmUNCj4+ICAgICAyIHByZWZl
ciBoYXZpbmcgaXQgaW4gdGhlIGRvYyBhcyByZXF1aXJlZA0KPj4gIA0KPj4gTWF5YmUgd2Ugc2hv
dWxkIGdldCBhZ3JlZW1lbnQgb24gd2hhdCB0byBkbyBhYm91dCBpbnB1dC1pbnRlcmZhY2UgKG9u
IHRoZSBsaXN0KSBmaXJzdCBhbmQgdGhlbiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IHRvIGRvIGFi
b3V0IHRoZSBtZXRhZGF0YSBncm91cGluZy4NCj4+ICANCj4+IE1hdGNoaW5nIG9uIGJhc2ljIElQ
djQvSVB2NC9NQUMgaGVhZGVyIGZpZWxkcyBpcyBjb21tb24gZnVuY3Rpb25hbGl0eS4gIEJ1dCBo
YXZpbmcgdGhhdCBpbnB1dC1pbnRlcmZhY2UgbWF0Y2ggb24gbWV0YWRhdGEgaW4gdGhlIGNvcmUg
bW9kZWwgaXMgb3V0IG9mIHBsYWNlLiAgSXQgc2hvdWxkIGJlIGxlZnQgdG8gZnVydGhlciBleHRl
bnNpb24gZHJhZnRzIG9yIHZlbmRvciBzcGVjaWZpYyBhdWdtZW50YXRpb25zIChhbG9uZyB3aXRo
IHdoYXRldmVyIG90aGVyIG1ldGFkYXRhIG1pZ2h0IGJlIHVzZWZ1bCBvciB2ZW5kb3Itc3BlY2lm
aWMpLiBNYW55IG1ham9yIGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3VwcG9ydCBtYXRjaGluZyBv
biBpbnB1dC1pbnRlcmZhY2UgKENpc2NvIElPUy1YUiwgTm9raWEgU1IgT1MsIEJyb2NhZGUsIG90
aGVycykuICBUaGUgdHlwaWNhbCB3YXkgdG8gYXNzb2NpYXRlIEFDTHMgYW5kIEludGVyZmFjZXMg
aXMgYnkgYXNzaWduaW5nIGFuIEFDTCB0byBhbiBpbnRlcmZhY2UgYXMgc2hvd24gaW4gc2VjdGlv
biBBLjMuIG9mIHRoZSBBQ0wgZHJhZnQuICAgVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIG9mIHRo
aXMgb24gdGhlIE5FVE1PRCB0aHJlYWQg4oCcUmVtb3ZlIGlucHV0LWludGVyZmFjZSAobWV0YWRh
dGEpIGZyb20gbmV0bW9kLWFjbC1tb2RlbC0wNyA/4oCdLg0KPj4gIA0KPj4gUmVnYXJkcywNCj4+
IEphc29uDQo+PiAgDQo+PiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZyANCj4+IDxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg
RVhUIERlYW4gQm9nZGFub3ZpYw0KPj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDEx
OjEyDQo+PiBUbzogbmV0bW9kIFdHDQo+PiBTdWJqZWN0OiBbbmV0bW9kXSBpbnB1dCBJbnRlcmZh
Y2UgbWF0Y2gNCj4+ICANCj4+IEFzIHRoZSBhY3Rpb24gaXRlbSBmcm9tIHRoZSBuZXRtb2QgV0cg
YW5kLCBob3BlZnVsbHksIGxhc3Qgb3BlbiBpdGVtIA0KPj4gaW4gdGhlIEFDTCBkcmFmdCBpcyB0
aGUgbGVhZiBpbnB1dCBpbnRlcmZhY2UgaW4gdGhlIG1ldGFkYXRhIGdyb3VwaW5nDQo+PiAgDQo+
PiBncm91cGluZyBtZXRhZGF0YSB7DQo+PiAgICAgZGVzY3JpcHRpb24NCj4+ICAgICAgICJGaWVs
ZHMgYXNzb2NpYXRlZCB3aXRoIGEgcGFja2V0IHdoaWNoIGFyZSBub3QgaW4NCj4+ICAgICAgIHRo
ZSBoZWFkZXIuIjsNCj4+ICAgICBsZWFmIGlucHV0LWludGVyZmFjZSB7DQo+PiAgICAgICB0eXBl
IGlmOmludGVyZmFjZS1yZWYgew0KPj4gICAgICAgICByZXF1aXJlLWluc3RhbmNlIGZhbHNlOw0K
Pj4gICAgICAgfQ0KPj4gICAgICAgZGVzY3JpcHRpb24NCj4+ICAgICAgICAgIlBhY2tldCB3YXMg
cmVjZWl2ZWQgb24gdGhpcyBpbnRlcmZhY2UuIjsNCj4+ICAgICB9DQo+PiAgIH0NCj4+IH0NCj4+
ICANCj4+ICANCj4+IEhlcmUgYXJlIHR3byBxdWVzdGlvbnM6DQo+PiBPbmUNCj4+IERvIHdhbnQg
dG8gaGF2ZSBhIG1ldGFkYXRhIGdyb3VwaW5nIGluIHRoZSBiYXNpYyBBQ0wgbW9kZWw/IElmIHll
cywgDQo+PiB3ZSBoYXZlIHRvIHB1dCBpbiBzb21lIGxlYWZzIGluIHRoZXJlLiBUaGVyZSBhcmUg
aW1wbGVtZW50YXRpb25zIA0KPj4gd2hpY2ggdXNlIG1ldGFkYXRhIGFzIG1hdGNoIGNvbmRpdGlv
bg0KPj4gIA0KPj4gSWYgd2UgYWdyZWUgdGhhdCBtZXRhZGF0YSBncm91cGluZyBpcyBub3QgbmVl
ZGVkIGluIHRoZSBiYXNpYyBtb2RlbCwgDQo+PiB0aGVuIHRoZSBhdXRob3JzIHdvdWxkIHJlbW92
ZSB0aGUgZ3JvdXBpbmcgZnJvbSB0aGUgbW9kZWwgYW5kIEkgDQo+PiBiZWxpZXZlIHRoYXQgbm8g
bW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZCBvbiB0aGlzIHBvaW50DQo+PiAgDQo+PiBEZWFuDQo+
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCi0tDQpMYWRpc2xhdiBMaG90a2EsIENaLk5J
QyBMYWJzDQpQR1AgS2V5IElEOiBFNzRFOEMwQw0K


From nobody Fri Apr 29 13:55:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8412D641; Fri, 29 Apr 2016 13:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSLMbzhwXJbw; Fri, 29 Apr 2016 13:55:24 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676C812D111; Fri, 29 Apr 2016 13:55:24 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id u64so131348083lff.3; Fri, 29 Apr 2016 13:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=D+B60/l0XDvP2psF5UjcpH/C9sEXnKLumgVNbGJUCYY=; b=VT0jvFRNSClUTgwavrJtjlcMiE6hL98YSpgVv53DYXB4Yweei9sDAalzUGfsqcuzWw Ap7vYJgrXHjuJmb80qwNUS9PTCU1XL72C5gicktpJrFRgxR7MMRSKOUzmZ8OJGUcIJtN x0vZviVEJUlRjKk+2wKzPsSyMNY5nv9Rwkew43KLNKqgayBJrUTVLSz3n9y+CA/R3BY3 MdxxkiE8i6f9iJZElc99kurIJ0IF0kzppUu5A6Kw7LyMosFh+meiQ5/B0sWcd6gP9L4l WkF6vTNLKCIXIOxdXOuo+yT9FTcJGwvrgtna7K9yzMrljfO5IQyDiVVVUArR4HZM7FNq LiNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=D+B60/l0XDvP2psF5UjcpH/C9sEXnKLumgVNbGJUCYY=; b=OdS6ozzuvCzVfMU/jWPIbGxXtTEI0BftGYgaHnG5EfjIoFTPxjDKQzetR0dQk1f75Y RdaeHiYmUUF+g0OASadbKIeOmsCs7xJo4aLAC7fOIJ7E7hRMCTFqJPrx148BJD8PGpbI Q9lOj8DG4QQXNtif1uB+3grOpJucxDyGtWvC7Xvp6zY56qis0nolOzx8Emcg/AEGbnZT XAheppD8jHRL9mEmZRX7PMHNfqv6v8N9ZreG5AvAXj65THFbrzZVTjeNXBAGR7FVSDLR BpLeCQ3r3ICLxXUr3rIMIOwCTEo9yHUhQt5V42w+SVh8QX8Yf8o3ouXcvEPngp+ihCSw TvXw==
X-Gm-Message-State: AOPr4FWDZjTHu+LW7jbfZ3JoKsGli250VTzPPFmPl1olrKXO6a8+u0jI+bJVxeVcP/u0TA==
X-Received: by 10.25.18.215 with SMTP id 84mr9656770lfs.154.1461963322598; Fri, 29 Apr 2016 13:55:22 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id s4sm2581040lbr.34.2016.04.29.13.55.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2016 13:55:21 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Joel M. Halpern'" , "'Tarek Saad \(tsaad\)'" , "'Martin Bjorklund'" 
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> 
In-Reply-To: 
Date: Fri, 29 Apr 2016 16:55:18 -0400
Message-ID: <01fc01d1a259$71cfae00$556f0a00$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHWgJx6jSrWpXJ0ftSLGH1x1joEWQIIa3FCAl1chQsCIJL6KJ9jcbMA
Content-Language: en-us
Archived-At: 
Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, netmod@ietf.org, teas@ietf.org, draft-ietf-netmod-schema-mount@ietf.org
Subject: Re: [netmod] [Teas]  Use of schema mounts for common model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 20:55:27 -0000

We still hope that schema mount can handle cross-referencing across mounted
modules. It is also needed when ietf-interfaces model is mounted to
logical-network-element  and network-instance models.

More comments for this case below in-line.

Thanks,

- Xufeng

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Friday, April 29, 2016 1:05 PM
> To: Tarek Saad (tsaad) ; Martin Bjorklund

> Cc: draft-ietf-teas-yang-te@ietf.org; mpls@ietf.org; teas@ietf.org;
> netmod@ietf.org; draft-ietf-netmod-schema-mount@ietf.org
> Subject: Re: [Teas] [netmod] Use of schema mounts for common model
> 
> With regard to leafrefs trying to point into groupings, would
instance-identifiers
> work for your use case?
> 

In this case, it would be hard to specify the must conditions for these
instance-identifiers to make them always applicable when the groupings are
used in various situations. If we are willing to re-structure everything,
the method used in draft-halpern-supa-generic-policy-data-model could be an
option to explore. 

> Yours,
> Joel
> 
> On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:
> > Thanks Martin, please see inline..
> >
> >
> > On 2016-04-29, 6:29 AM, "Martin Bjorklund"  > > wrote:
> >
> >     "Tarek Saad (tsaad)" >
wrote:
> >
> >         Hi authors/WG,
> >         In draft-ietf-teas-yang-te, we are driving the definition for a
> >         generic TE YANG model that can/may be used (and extended when
> >         necessary) for different data plane technologies (e.g. MPLS,
> >         OTN, WDM,
> >         etc.).
> >         Reviewing the schema mount idea presented in
> >         draft-ietf-netmod-schema-mount, we are thinking this proposal is
> >         useful and can facilitate the reuse of the our model in multiple
> >         places in the YANG tree (once per each technology), e.g.:
> >         ./mpls/mount-points/mount-point/module=ietf-te.yang
> >         ./otn/mount-points/mount-point/module=ietf-te.yang
> >
> >
> >     Schema mount is probably not the right solution to your problem.  I
> >     think a better solution in your case is to define groupings.
> >     Groupings are designed to be re-used at different places in the
> >     hierarchy.
> >
> >
> > We thought of this earlier, and found groupings pose their own set of
> > challenges too.. Specifically:
> > - a groupings with leafrefs could not reference data nodes that reside
> > in another grouping
> > - a grouping with leafrefs of relative path were challenge when the
> > relative path references data nodes outside the grouping
> > - the augmentation of the grouping by other modules is not as
> > straightforward
> >
> > That said, the grouping proposal seems to
> >
> > one could also think that with groupings one could address reuse of
> > the a model (e.g. Ietf-interfaces) for logical devices or VM (see
> > below). In fact, in your draft (section 2) you explicitly discourage
> > this approach as not scalable solution
> >
> >
> >    With the "uses" approach, ietf-interfaces would have to define a
> >    grouping with all its nodes, and the new model for logical devices
> >    would have to use this grouping.  This is a not a scalable solution,
> >    since every time there is a new model defined, we would have to
> >    update our model for logical devices to use a grouping from the new
> >    model.  Another problem is that this approach cannot handle vendor-
> >
> >
> >
> >         We have a comment/concern/suggestion and we value your feedback.
> >         The generic TE model currently references data nodes in the
global
> >         tree (e.g. from the ietf-interfaces model to define additional
TE
> >         properties associated with a specific device interface). Our
> >         understanding after reading section 3.1 of your draft is the
mounted
> >         model can *not* reference any data nodes outside the scope of
the
> >         mount-point (e.g. global data nodes in the yang tree). This
poses a
> >         limitation for us, do you have a suggestion for this problem?
> >         One possible solution we thought of was to replace the leaf-refs
> >         pointing to the global data nodes (e.g. Ietf-interfaces) with
> >         context
> >         names (e.g. the interface name).. This decouples the data-nodes
> >         defined in the TE generic model from those in the global tree
> >         (e.g. the actual interface ietf-interfaces model). Any feedback
on
> >         this or better suggestions?
> >
In this case, there are multiple augmentations to ietf-te.yang, such as
ietf-rsvp-te and ietf-sr-te. If ietf-te is a grouping, we cannot do the
augmentations before ietf-te is used. Using the grouping would be very
awkward when ietf-te is used. We would have to make the same many
augmentations at that time. Even worse, there could be future augmentations,
we cannot specify these augmentations now because they are not defined yet.

> >
> >     If you use groupings instead, you can still use proper leafrefs.
> >
> >
> > Not in all cases - as described above.
> >
> > Regards,
> > Tarek
> >
> >
> >
> >     /martin
> >
> >
> >
> >         Regards,
> >         Tarek
> >         Excerpt from draft-ietf-netmod-schema-mount
> >         3.1 01#section-3.1>.
> >         Augment and Validation in Mounted Data
> >             All paths (in leafrefs, instance-identifiers, XPath
> >         expressions, and
> >             target nodes of augments) in the data models mounted at a
> >         mount point
> >             are interpreted with the mount point as the root node, and
the
> >             mounted data nodes as its children.  This means that data
> >         within a
> >             mounted subtree can never refer to data outside of this
subtree.
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas