From nobody Fri Mar 1 02:32:57 2019 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 D2453130E5A for ; Fri, 1 Mar 2019 02:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 kSli2wbTNQDR for ; Fri, 1 Mar 2019 02:32:53 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B9943130E5B for ; Fri, 1 Mar 2019 02:32:53 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 66C7E61B03DFF952B878 for ; Fri, 1 Mar 2019 10:32:51 +0000 (GMT) Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 1 Mar 2019 10:32:46 +0000 Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 1 Mar 2019 10:32:46 +0000 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 1 Mar 2019 10:32:46 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.156]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Fri, 1 Mar 2019 18:32:34 +0800 From: Qin Wu To: NETMOD WG CC: "xiechf.bri@chinatelecom.cn" , wangzitao Thread-Topic: I-D Action: draft-wwx-netmod-event-yang-01.txt Thread-Index: AdTQGbHQZFiRB+YXRJew3BBATgq7Ag== Date: Fri, 1 Mar 2019 10:32:34 +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.134.31.203] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] I-D Action: draft-wwx-netmod-event-yang-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 10:32:56 -0000 di0wMSBpcyBwb3N0ZWQgdG8gYWRkcmVzcyBhIGZldyBjb21tZW50cyBkaXNjdXNzZWQgaW4gbGFz dCBJRVRGIG1lZXRpbmc6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13 d3gtbmV0bW9kLWV2ZW50LXlhbmcvDQpUaGUgY2hhbmdlcyBpbmNsdWRlOg0KMS5TZXBhcmF0ZSBp ZXRmLWV2ZW50LXRyaWdnZXIueWFuZyBmcm9tIEV2ZW50IG1hbmFnZW1lbnQgbW9kZWxhbmQgaWV0 Zi1ldmVudC55YW5nIGFuZCBtYWtlIGl0IHJldXNhYmxlIGluIG90aGVyIFlBTkcgbW9kZWxzLg0K Mi4gQ2xhcmlmeSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGJvb2xlYW4gdHJpZ2dlciBjb25kaXRp b24gYW5kIHRocmVzaG9sZCB0cmlnZ2VyIGNvbmRpdGlvbi4NCjMuIENoYW5nZSBldnQtc21wLW1p biBhbmQgZXZ0LXNtcC1tYXggaW50byBtaW4tZGF0YS1vYmplY3QgYW5kIG1heC1kYXRhLW9iamVj dCBpbiB0aGUgZGF0YSBtb2RlbC4NCkZ1cnRoZXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClJl Z2FyZHMhDQpRaW4vTWljaGFsZS9DaG9uZ2ZlbmcNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCreiy83KsbzkOiAyMDE5xOoz1MIxyNUgMTg6MjgN CsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9uOiBkcmFmdC13 d3gtbmV0bW9kLWV2ZW50LXlhbmctMDEudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K DQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgbW9kZWwgZm9yIFBvbGlj eSBiYXNlZCBFdmVudCBNYW5hZ2VtZW50DQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1pY2hh ZWwgV2FuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBRaW4gV3UNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2hvbmdmZW5nIFhpZQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXd3eC1u ZXRtb2QtZXZlbnQteWFuZy0wMS50eHQNCglQYWdlcyAgICAgICAgICAgOiAyMw0KCURhdGUgICAg ICAgICAgICA6IDIwMTktMDMtMDENCg0KQWJzdHJhY3Q6DQogICBbUkZDODMyOF0gZGVmaW5lcyBh IHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IGZyYW1ld29yayB0aGF0IGFsbG93DQogICBkZWZpbml0 aW9uIG9mIGEgZGF0YSBtb2RlbCB0byBiZSB1c2VkIHRvIHJlcHJlc2VudCBoaWdoLWxldmVsLA0K ICAgcG9zc2libHkgbmV0d29yay13aWRlIHBvbGljaWVzLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGFuIFlBTkcgZGF0YQ0KICAgbW9kZWwgZm9yIHRoZSBwb2xpY3kgYmFzZWQgZXZlbnQgbWFuYWdl bWVudCBbUkZDNzk1MF0uICBUaGUgcG9saWN5DQogICBiYXNlZCBFdmVudCBZQU5HIHByb3ZpZGVz IHRoZSBhYmlsaXR5IGZvciB0aGUgbmV0d29yayBtYW5hZ2VtZW50DQogICBmdW5jdGlvbiAod2l0 aGluIGEgY29udHJvbGxlciwgYW4gb3JjaGVzdHJhdG9yLCBvciBhIG5ldHdvcmsgZWxlbWVudCkN CiAgIHRvIGNvbnRyb2wgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIG1vbml0b3Igc3RhdGUgY2hhbmdl IG9uIHRoZSBuZXR3b3JrDQogICBlbGVtZW50IGFuZCB0YWtlIHNpbXBsZSBhbmQgaW5zdGFudCBh Y3Rpb24gd2hlbiBhIHRyaWdnZXIgY29uZGl0aW9uDQogICBvbiB0aGUgc3lzdGVtIHN0YXRlIGlz IG1ldC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd3eC1uZXRtb2Qt ZXZlbnQteWFuZy8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxl IGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3eC1uZXRtb2QtZXZlbnQt eWFuZy0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13d3gt bmV0bW9kLWV2ZW50LXlhbmctMDENCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXd3eC1uZXRtb2QtZXZlbnQteWFuZy0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWls aW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBo dHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRm LzFzaGFkb3ctc2l0ZXMudHh0DQo= From nobody Fri Mar 1 13:11:47 2019 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 0E0A0130F43; Fri, 1 Mar 2019 13:09:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147459904.6101.3031475853004699962.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:09:59 -0800 Archived-At: Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 104 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:08 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netmod Session 1 (2:00 requested) Monday, 25 March 2019, Afternoon Session I 1350-1550 Room Name: Congress Hall 1 size: 250 --------------------------------------------- netmod Session 2 (2:00 requested) Friday, 29 March 2019, Morning Session II 1050-1250 Room Name: Congress Hall 3 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/netmod.ics Request Information: --------------------------------------------------------- Working Group Name: Network Modeling 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: 100 Conflicts to Avoid: First Priority: netconf Second Priority: rtgwg i2rs teas Third Priority: saag People who must be present: Lou Berger Joel Jaeggli Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: MUST schedule 1st session for Monday or Tuesday. SHOULD schedule 2nd session for Monday or Tuesday but, if not possible, then Wed-Fri okay (just will be one chair down). --------------------------------------------------------- From nobody Sat Mar 2 08:00:25 2019 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 2B7C7130E6C; Sat, 2 Mar 2019 08:00:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155154241709.27243.17803559592839097276@ietfa.amsl.com> Date: Sat, 02 Mar 2019 08:00:17 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-module-tags-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 16:00:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Module Tags Authors : Christian Hopps Lou Berger Dean Bogdanovic Filename : draft-ietf-netmod-module-tags-06.txt Pages : 15 Date : 2019-03-02 Abstract: This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be standardized and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document also provides guidance to future model writers, as such, this document updates RFC8407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-module-tags-06 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 3 02:13:20 2019 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 2CE83129619 for ; Sun, 3 Mar 2019 02:13:19 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 MgO1K8VA4xoD for ; Sun, 3 Mar 2019 02:13:17 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A29AF129A87 for ; Sun, 3 Mar 2019 02:13:17 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 9CF7D604D1; Sun, 3 Mar 2019 05:13:16 -0500 (EST) References: <155159408008.27213.6660557576883092694@ietfa.amsl.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: NETMOD WG Date: Sun, 03 Mar 2019 05:13:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [netmod] Fwd: I-D Action: draft-chopps-netmod-geo-location-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 10:13:19 -0000 --=-=-= Content-Type: text/plain; format=flowed FYI, Updated to make motion vector 3d vs 2d, also added some more non-normative explanation text, on nesting and out-of-scope non-location attributes. internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : YANG Geo Location > Author : Christian Hopps > Filename : draft-chopps-netmod-geo-location-01.txt > Pages : 22 > Date : 2019-03-02 > > Abstract: > This document defines a generic geographical location object YANG > grouping. The geographical location grouping is intended to be used > in YANG models for specifying a location on or in reference to the > Earth or any other astronomical object. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01 > https://datatracker.ietf.org/doc/html/draft-chopps-netmod-geo-location-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-chopps-netmod-geo-location-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx7qLsACgkQLh2DDte4 MCURMg//WuhkWM0Xr7Qr9Guf0lmAfPQQXvgh2n30h1cfKYp+5l8N81TfgQZrwk/q J+x4+DtaXbCcGK/vkIpmCB68Ib2jazLO9nA59dKVn9/YCSVk3Zf5NlQtuvLdpqE8 xZukrWE5pXN8WvAyzZm/NNIoSziuvgp0PDpiBYHvQgyMdhXHJbnF9VlN4kEsXkAq YTQ5YE78t/z3vZwERGquDut/yojfMeOnU0Xqfy7gHbGIGHuSw+mDyigmCizGT2Pq Tr7AzfNthOvEnIrHnlQFx6K4hGl9zICMpBI48dUKdHd0BSlwTU496p4ghkYose8L Vn2M65orO/BQAXvbZYa1tnfhUhdNmTQrVDJvGJMwrup3rtyE97hj13KuYDjeyiVq Mx9HeUPwkzqVT+vEM2XsXNjgCG3QCmawhm5wQp1sq8Im8cuwJojtuF5qws/lHk2q puU5C5XA3R14ZQhBhTq+qbNPlT//yM+P2/0hQREmJuOLfj4913301KmcaYw8ex11 Fry8kos9rGIV7dT5EC3TmKAZxwoPV+L+upeqZm4zpzJnb4zr0cVT+H3wjWabuaFD 92AQ5wxsxkgr6sS7r2mVaBji8o+ztHXBtTb2YWeHqH4uXB9y6cCQaX4f/D2Mo0Dc S/TuwwryFSD48s8YQn7NivqM7ffd6IhbamYPXLplzjXlAiLQr5Y= =OsUo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 4 00:40:10 2019 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 32737127AC2 for ; Mon, 4 Mar 2019 00:40:10 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 YO9SbgrGUE2j for ; Mon, 4 Mar 2019 00:40:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6996C1276D0 for ; Mon, 4 Mar 2019 00:40:08 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EC671AE0118; Mon, 4 Mar 2019 09:40:06 +0100 (CET) Date: Mon, 04 Mar 2019 09:40:06 +0100 (CET) Message-Id: <20190304.094006.527512831015675938.mbj@tail-f.com> To: rwilton@cisco.com Cc: adrian@olddog.co.uk, joelja@bogus.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> References: <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 08:40:10 -0000 IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBB ZHJpYW4sDQo+IA0KPiBJIG1vc3RseSBhZ3JlZSB3aXRoIHlvdXIgbGFzdCBzZW50ZW5jZS4NCj4g DQo+IEkgdGhpbmsgdGhhdCBpZiB5b3UgYWx3YXlzIHByZXNlcnZlIHdoaXRlc3BhY2UgdGhlbiBh IHNpbmdsZSBzbGFzaCBpcw0KPiBmaW5lLiAgSS5lLiB0aGUgc2luZ2xlIHNsYXNoIGp1c3QgYnJl YWtzIHRoZSBsaW5lLCBhbmQgSSB0aGluayB0aGF0DQo+IHRoaXMgbWF0Y2hlcyBob3cgZWRpdG9y cywgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCBldGMgbm9ybWFsbHkgYmVoYXZlLg0KPiANCj4gV2hh dCBJ4oCZbSBub3Qga2VlbiBvbiBpcyB1c2luZyBhIHNpbmdsZSBzbGFzaCwgYW5kIHRoZW4gYXV0 b21hdGljYWxseQ0KPiBzdHJpcHBpbmcgbGVhZGluZyB3aGl0ZXNwYWNlIG9uIHRoZSBsaW5lIGZv bGxvd2luZyBhIHNsYXNoLg0KDQpBbmQgdGhpcyBpcyB0aGUgc29sdXRpb24gdGhhdCBJIHByZWZl ci4gIFRoZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBJDQp2aWV3IGV4YW1wbGVzIGFzIHNvbWV0 aGluZyB0aGF0IGlzIHRoZXJlIHRvIGlsbHVzdHJhdGUgc29tZSBwb2ludCB0bw0KdGhlIHJlYWRl ciwgYW5kIEkgdGhpbmsgdGhhdCBhIHByZXR0aWVyIGZvcm1hdHRlZCBleGFtcGxlIHdpdGggbGVz cw0Kbm9pc2UgaGVscHMgdGhlIHJlYWRlci4gIEkgYWxzbyB0aGluayB0aGF0IGlzIG1vc3QgY2Fz ZXMsIHRoaXMgd29ya3MNCndlbGw7IGkuZS4sIG1vc3QgY2FzZXMgYXJlIF9ub3RfIG9uIHRoZSBm b3JtOg0KDQogICAxMjM0NSAgICAgIDc4OTkwDQogICAgICAgICAgXi0tLS0tLS0tLS0tLS0tIEkg bmVlZCBhIGxpbmUgYnJlYWsgaGVyZQ0KDQoNCkZvciB0aGlzIHByb2JsZW0sIEkgcHJlZmVyIGEg c29sdXRpb24gdGhhdCBpcyBpbnR1aXRpdmUgYW5kIGhhcyBsZXNzDQpub2lzZSBhbmQgd29ya3Mg Zm9yIDkwJSBvZiB0aGUgY2FzZXMsIHRoYW4gYSBsZXNzIGludHVpdGl2ZSBzb2x1dGlvbg0Kd2l0 aCBtb3JlIG5vaXNlIHRoYXQgd29ya3MgZm9yIDEwMCUgb2YgdGhlIGNhc2VzLg0KDQoNCi9tYXJ0 aW4NCg0KDQoNCj4gDQo+IElmIHdlIHdhbnQgdG8gaGF2ZSBjb250cm9sIG9mIGxheW91dCBhbmQg YmUgYWJsZSB0byBzdHJpcCBleHRyYQ0KPiB3aGl0ZXNwYWNlIHRoZW4gbXkgYXJndW1lbnQgaXMg dGhhdCBpdCBpcyBiZXR0ZXIgdG8gYmUgZXhwbGljaXQsIGFuZA0KPiB1c2luZyB0d28gc2xhc2hl cyBpcyBvbmUgd2F5IG9mIGFjaGlldmluZyB0aGlzLg0KPiANCj4gVGhhbmtzLA0KPiBSb2INCj4g DQo+IA0KPiANCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4gU2VudDogMjcgRmVicnVhcnkgMjAxOSAwOTo0MQ0KPiBU bzogJ0pvZWwgSmFlZ2dsaScgPGpvZWxqYUBib2d1cy5jb20+DQo+IENjOiBuZXRtb2RAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0 IG1vZGVzPw0KPiANCj4gQ29tcGxldGUgYWdyZWVtZW50LCBKb2VsLg0KPiANCj4gV2hhdCBmb2xs b3dzIG1heSBsb29rIGJldHRlciBpbiBwcm9wb3J0aW9uYWwgZm9udHMuDQo+IA0KPiBXaXRoIGEg c2luZ2xlIHNsYXNoIHdlIGNhbiB3cmFwIGFzIGZvbGxvd3MNCj4gDQo+IDEyMzQ1NjcgICAgICAg IDkwMTIzNDUNCj4gDQo+IEdvZXMgdG/igKYNCj4gDQo+IDEyMzQ1NjcgICAgXA0KPiAgICAgOTAx MjM0NQ0KPiANCj4g4oCmYW5kIHVud3JhcHBpbmcgaXMgZWFzeS4NCj4gDQo+IEhvd2V2ZXIsIGlm IEkgd2FudCB0byBtYW51YWxseSB3cmFwIHRoZSBsaW5lIHdpdGggaW5kZW50YXRpb24NCj4gDQo+ IFRoZSBxdWljayBicm93biBmb3gganVtcHMgb3ZlciB0aGUgbGF6eSBkb2cNCj4gDQo+IC4uZ29p bmcgdG/igKYNCj4gDQo+IFRoZSBxdWljayBicm93biBmb3hcDQo+ICAgICAgIGp1bXBzIG92ZXIg dGhlIGxhenkgZG9nDQo+IA0KPiDigKZJIGFtIGdvaW5nIHRvIHVuZm9sZCBhc+KApg0KPiANCj4g VGhlIHF1aWNrIGJyb3duIGZveCAgICAgIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+IA0KPiAN Cj4gQ29udmVyc2VseSwgaWYgSSByZXNvbHZlIHRoaXMgc2Vjb25kIGNhc2UgYnkgc3RyaXBwaW5n IGxlYWRpbmcgc3BhY2VzDQo+IEkgZ2V04oCmDQo+IA0KPiBUaGUgcXVpY2sgYnJvd24gZm94anVt cHMgb3ZlciB0aGUgbGF6eSBkb2cNCj4gDQo+IFNvIEkgaGF2ZSB0byBmb2xkIGFz4oCmDQo+IA0K PiBUaGUgcXVpY2sgYnJvd24gZm94IFwNCj4gICAgICAganVtcHMgb3ZlciB0aGUgbGF6eSBkb2cN Cj4gDQo+IEJ1dCB0aGlzIGNhdXNlcyB0aGUgZmlyc3QgY2FzZSB0byB1bmZvbGQgYXMNCj4gDQo+ IDEyMzQ1NjcgICAgOTAxMjM0NQ0KPiANCj4g4oCmaS5lLiwgd2l0aCBtaXNzaW5nIHNwYWNlcy4N Cj4gDQo+IFRoaXMgaXMgd2hhdCBjYXVzZWQgdGhlIHVzZSBvZiB0aGUgc2Vjb25kIHNsYXNoIHNv 4oCmDQo+IA0KPiAxMjM0NTY3ICAgIFwNCj4gXCAgICA5MDEyMzQ1DQo+IA0KPiDigKZhbmTigKYN Cj4gDQo+IFRoZSBxdWljayBicm93biBmb3hcDQo+ICAgICAgXCBqdW1wcyBvdmVyIHRoZSBsYXp5 IGRvZw0KPiANCj4gDQo+IFNvLCBteSBwb2ludCBpcywgaWYgYW5kIG9ubHkgaWYgd2UgZG8gbm90 IGNhcmUgYWJvdXQgdGhlc2Ug4oCcc3BhY2VzIG9uDQo+IHRoZSBmb2xk4oCdIGNhc2VzLCB3ZSBj YW4gb3BlcmF0ZSB3aXRoIGEgc2luZ2xlIHNsYXNoLg0KPiANCj4gQ2hlZXJzLA0KPiBBZHJpYW4N Cj4gDQo+IEZyb206IEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9lbGph QGJvZ3VzLmNvbT4+DQo+IFNlbnQ6IDI3IEZlYnJ1YXJ5IDIwMTkgMDY6MzENCj4gVG86IEFkcmlh biBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+ Pg0KPiBDYzogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50K2ll dGZAd2F0c2VuLm5ldD4+Ow0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4NCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0 IG1vZGVzPw0KPiANCj4gDQo+IA0KPiBPbiBGZWIgMjYsIDIwMTksIGF0IDE0OjI2LCBBZHJpYW4g RmFycmVsDQo+IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVr Pj4gd3JvdGU6DQo+IA0KPiBIZXkuDQo+IA0KPiBJ4oCZdmUgYmVlbiBoYXZpbmcgdGhpcyBkaXNj dXNzaW9uIHdpdGggS2VudCBvZmYtbGluZSwgYnV0IHRob3VnaHQgaXQNCj4gc2hvdWxkIGNvbWUg dG8gdGhlIGxpc3QuDQo+IA0KPiBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8g aGF2ZSB0d28gYXBwcm9hY2hlcy4gV2hpbGUgaXQgd291bGQNCj4gYmUgcmVsYXRpdmVseSBlYXN5 IHRvIGNvZGUgZm9yIGJvdGggYXBwcm9hY2hlcywgaXQgc2VlbXMgdG8gYWRkIGENCj4gZGVncmVl IG9mIGNvbmZ1c2lvbiBpZiBib3RoIGhhdmUgdG8gYmUgaGFuZGxlZCBieSB0aGUgc2FtZSBjb2Rl DQo+IChjb25zaWRlciBkZWNpZGluZyB3aGV0aGVyIGxlYWRpbmcgc3BhY2UgY2hhcmFjdGVycyBh cmUgdG8gYmUgcmV0YWluZWQNCj4gb3Igbm90LCBzb21ldGhpbmcgdGhhdCBjYW4gb25seSBiZSBk ZWNpZGVkIHdoZW4gdGhlIGZpcnN0IG5vbi1zcGFjZQ0KPiBjaGFyYWN0ZXIgaXMgZm91bmQpLCBv ciBieSBoYXZpbmcgZGlmZmVyZW50IGNvZGUgZm9yIHRoZSB0d28gZGlmZmVyZW50DQo+IGNhc2Vz Lg0KPiANCj4gSXQgZG9lc27igJl0IHNlZW0gdG8gbWUgdGhhdCBib3RoIGNhc2VzIGFyZSBuZWVk ZWQuIFdlIGNhbiBwaWNrIG9uZSBvcg0KPiB0aGUgb3RoZXIuDQo+IA0KPiBBIHNpbmdsZSBzbGFz aCBoYXMgYmVlbiB1c2VkIHRvIHdyYXAgbG9uZyBsaW5lcyBpbiBlZGl0b3JzIGFuZCBzaGVsbHMN Cj4gZm9yIGRlY2FkZXMgYXQgdGhpcyBwb2ludC4NCj4gDQo+IGFuZCB5ZWFoIHdoYXRldmVyIGl0 IGlzIG9uZSBtZXRob2Qgc2VlbXMgYmV0dGVyIHRoYW4gdHdvLg0KPiANCj4gDQo+IEFuZCAqaWYq IHdlIHdhbnQgdG8gYWxsb3cgbWFudWFsIGZvbGRpbmcgc28gdGhhdCBpbmRlbnRzIGNhbiBiZSBt YWRlDQo+IHRvIG1ha2UgdGhlIGRvY3VtZW50IG1vcmUgaHVtYW4tcmVhZGFibGUgdGhlbiB3ZSBo YXZlIHRvIHVzZSBhIGxlYWRpbmcNCj4g4oCYXOKAmSBvbiBjb250aW51YXRpb24gbGluZXMgdG8g c2hvdyB3aGljaCBzcGFjZXMgc2hvdWxkIGJlIHN0cmlwcGVkIGFuZA0KPiB3aGljaCByZXRhaW5l ZC4NCj4gDQo+IENoZWVycywNCj4gQWRyaWFuDQo+IA0KPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+DQo+IE9uIEJl aGFsZiBPZiBLZW50IFdhdHNlbg0KPiBTZW50OiAyNSBGZWJydWFyeSAyMDE5IDIyOjIyDQo+IFRv OiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogW25l dG1vZF0gYXJ0d29yayBmb2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQo+IA0KPiANCj4gSSBo YWQgYSBjaGF0IHdpdGggdGhlIHRvb2xzIHRlYW0gcmVjZW50bHkgYW5kLCBpbiB0aGUgY291cnNl IG9mDQo+IHRoaW5ncywgaXQgd2FzIGltcGxpZWQNCj4gdGhhdCB0aGUgZG91YmxlIGJhY2tzbGFz aCBhcHByb2FjaCB3ZSBoYXZlIG5vdyB3YXMgYm90aCBzdXJwcmlzaW5nIGFuZA0KPiBub24taW50 dWl0aXZlLg0KPiANCj4gVGhpcyBnb3QgbWUgdGhpbmtpbmcgdGhhdCB3ZSBtYXkgaGF2ZSB0aHJv d24gdGhlIHByb3ZlcmJpYWwgYmFieSBvdXQNCj4gd2l0aCB0aGUgYmF0aHdhdGVyLg0KPiBUaGF0 IGlzLCBjdXJyZW50bHkgd2UgaGF2ZSBhIGhlYWRlciB0aGF0IHJlYWRzOg0KPiANCj4gDQo+ICAg Tk9URTogJ1xcJyBsaW5lIHdyYXBwaW5nIHBlciBCQ1AgWFggKFJGQyBYWFhYKQ0KPiANCj4gU28g d2h5IG5vdCAqYWxzbyogc3VwcG9ydCBhIGhlYWRlciB0aGF0IHJlYWRzIChub3RlIHRoZSBzaW5n ZSBzbGFzaCk6DQo+IA0KPiANCj4gICBOT1RFOiAnXCcgbGluZSB3cmFwcGluZyBwZXIgQkNQIFhY IChSRkMgWFhYWCkNCj4gDQo+IFdoZXJlYnkgdGhpcyBzZWNvbmQgZm9ybSBvbmx5IHN1cHBvcnRz IHRoZSBmb2xkZWQgbGluZSBjb250aW51aW5nIG9uDQo+IGNvbHVtbiAxIChubyBpbmRlbnRzKS4N Cj4gDQo+IFRob3VnaHRzPw0KPiANCj4gS2VudCAvLyBjb250cmlidXRvcg0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0K From nobody Mon Mar 4 01:59:46 2019 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 45536131069 for ; Mon, 4 Mar 2019 01:59:45 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 Gq1QraUsSNiF for ; Mon, 4 Mar 2019 01:59:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B04A4130FC7 for ; Mon, 4 Mar 2019 01:59:42 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 417AD1AE0118; Mon, 4 Mar 2019 10:59:40 +0100 (CET) Date: Mon, 04 Mar 2019 10:59:40 +0100 (CET) Message-Id: <20190304.105940.312797647046250578.mbj@tail-f.com> To: chopps@chopps.org Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 09:59:45 -0000 Hi, Just some quick comments on the YANG: The pattern '[-0-9a-z #x22#x23#x5B#x5D' + '!$%&()*+,\./:;<=>?@\\^_`{|}~]+'; doesn't seem to be correct. I think it should be: '[-0-9a-z "#[\]' + '!$%&()*+,./:;<=>?@\\^_`{|}~]+'; i.e., don't use hex codes (the regex dialect we use don't support them, and besides, the normal syntax is \x22 etc.), and don't escape characters that don't need escapes. However, it seems libxml2's regexp engine requires both "[" and "^" to be escaped: '[-0-9a-z "#\[\]' + '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; This expression isn't wrong, but it seems to me that these characters should not have to be escaped. The pattern allows double quote (") but not single quote ('). Is that intentional? [a simple way to test the patterns is to have a "default" statement and a YANG complier that verifies defaults] I recommend that you rename the example module in section to "example-uses-geo-location" (and change the namespace to urn:example:uses-geo-location). We should not use the "ietf" namespace for examples. /martin Christian Hopps wrote: > FYI. > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: I-D Action: draft-chopps-netmod-geo-location-00.txt > > Date: February 26, 2019 at 3:59:23 PM EST > > To: > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : YANG Geo Location > > Author : Christian Hopps > > Filename : draft-chopps-netmod-geo-location-00.txt > > Pages : 17 > > Date : 2019-02-26 > > > > Abstract: > > This document defines a generic geographical location object YANG > > grouping. The geographical location grouping is intended to be used > > in YANG models for specifying a location on or in reference to the > > Earth or any other astronomical object. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-chopps-netmod-geo-location-00 > > https://datatracker.ietf.org/doc/html/draft-chopps-netmod-geo-location-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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > From nobody Mon Mar 4 03:08:56 2019 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 F227B1310C1 for ; Mon, 4 Mar 2019 03:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 ZhkpBpbC4nXj for ; Mon, 4 Mar 2019 03:08:51 -0800 (PST) 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 C4916130F07 for ; Mon, 4 Mar 2019 03:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37082; q=dns/txt; s=iport; t=1551697730; x=1552907330; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NWEMn3vGtOMQBxl80m44/jK2UOdF4KxXvRJFRjDxNsk=; b=B2U2FxVRvCuL/yrDWI2/Rxz0YVIOwTFDWN8m8LobX1MlE/70TYY9hQ6G RMyA/RJqkiHvX2xcxV+lZLddPVaJL4PCu3YfXu7QfOGfkHWs+rkTomzz+ 6ubPBf8UBADRDJ8sZlTi6O52iINohZ/IbakM963xj3m65vuN8VNtHk8zn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAADdBn1c/5RdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ2BAmiBAycKgz5AlXCaHAsBARgBCoQ?= =?us-ascii?q?DRgIXhAoiNwYNAQEDAQEDAQMCbRwMhUoBAQEDAQEBChcKQQsFBwQCAQYCDgM?= =?us-ascii?q?EAQEhBwMCAgIlCxQJCAIEDgUIE4MIgRFcCA+MUJtmgS+KHwWBLwGLJxeBQD+?= =?us-ascii?q?BEYMSgx4BAQKBdoJzglcCihADLAKCAYQFkz0JApJqIZMinQcCERSBKDUigVZ?= =?us-ascii?q?wFTuCbIsMhT9BMQGPdYEfAQE?= X-IronPort-AV: E=Sophos;i="5.58,439,1544486400"; d="scan'208,217";a="525149563" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 11:08:42 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x24B8gON014605 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Mar 2019 11:08:42 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Mar 2019 05:08:41 -0600 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 4 Mar 2019 05:08:41 -0600 From: "Rob Wilton (rwilton)" To: Martin Bjorklund CC: "adrian@olddog.co.uk" , "joelja@bogus.com" , "netmod@ietf.org" Thread-Topic: [netmod] artwork folding: dual support modes? Thread-Index: AQHUzViIs88uqV1md0esD7eI1tBXvaXzDpmAgACHaICAADTYgP//oJLAgAgqNQD//77wgA== Date: Mon, 4 Mar 2019 11:08:41 +0000 Message-ID: <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> References: <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> <20190304.094006.527512831015675938.mbj@tail-f.com> In-Reply-To: <20190304.094006.527512831015675938.mbj@tail-f.com> 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.63.23.61] Content-Type: multipart/alternative; boundary="_000_8ddf74d483674c598e52ece716f70d0aXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 11:08:54 -0000 --_000_8ddf74d483674c598e52ece716f70d0aXCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnV0IHRoaXMgYmVoYXZpb3VyIGlzIHN0aWxsIGRpZmZlcmVudCBmcm9tIHRoZSBmcmVxdWVudGx5 IHVzZWQgbWVhbmluZyBvZiDigJhc4oCZIHRvZGF5IGluIHByb2dyYW1taW5nIGxhbmd1YWdlcywg d2hpY2ggYXMgSSBrbm93IGl0IGp1c3Qgc3BsaXRzIGxpbmVzIGFuZCBwcmVzZXJ2ZXMgd2hpdGVz cGFjZS4NCg0KDQoNCg0KDQpZQU5HIHJlcXVpcmVzIGEgc2VwYXJhdG9yIGNoYXJhY3RlciBiZXR3 ZWVuIGEga2V5d29yZCBhbmQgaXRzIGFyZ3VtZW50LiAgV2hhdCBoYXBwZW5zIGlmIHRoZSB0b29s IGhhcHBlbnMgdG8gc3BsaXQgdGhlIGxpbmUgYmV0d2VlbiB0aGUgdHdvIG9mIHRoZW0uDQoNCg0K DQpFLmcNCg0KICAgICAgICAgICAgICAgICAgICAgICBjb250YWluZXJcDQoNCiAgdGVzdA0KDQoN Cg0KQWZ0ZXIgdGhlIGFydHdvcmsgZm9sZGluZywgdGhpcyB3b3VsZCBiZWNvbWUNCg0KICAgICAg ICAgICAgICAgICAgICAgICBjb250YWluZXJ0ZXN0DQoNCg0KDQpUaGlzIGNvdWxkIGJlIG1pdGln YXRlZCBieSBhIHNtYXJ0ZXIgZm9sZGluZyB0b29sIChlLmcuIHNwbGl0IGJlZm9yZSB0aGUg4oCY cuKAmSBvciBhZnRlciB0aGUgZmlyc3Qgc3BhY2UpLg0KDQoNCg0KT3IsIHdoYXQgaWYgdGhlIHRv b2wgd2FzIGJlaW5nIHVzZWQgdG8gZm9sZCBhIHRhYmxlIHRoYXQgd2FzIHVzaW5nIHdoaXRlc3Bh Y2UgdG8gYWxpZ24gdGhlIGNvbHVtbnMuICBUaGlzIGNvdWxkIGVhc2lseSBicmVhayBpZiB3aGl0 ZXNwYWNlIGlzIHN0cmlwcGVkLg0KDQoNCg0KVGhhbmtzLA0KUm9iDQoNCg0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYu Y29tPg0KU2VudDogMDQgTWFyY2ggMjAxOSAwODo0MA0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24p IDxyd2lsdG9uQGNpc2NvLmNvbT4NCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBqb2VsamFAYm9n dXMuY29tOyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhcnR3b3JrIGZv bGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCg0KDQoNCiJSb2IgV2lsdG9uIChyd2lsdG9uKSIg PHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQo+ IEhpIEFkcmlhbiwNCg0KPg0KDQo+IEkgbW9zdGx5IGFncmVlIHdpdGggeW91ciBsYXN0IHNlbnRl bmNlLg0KDQo+DQoNCj4gSSB0aGluayB0aGF0IGlmIHlvdSBhbHdheXMgcHJlc2VydmUgd2hpdGVz cGFjZSB0aGVuIGEgc2luZ2xlIHNsYXNoIGlzDQoNCj4gZmluZS4gIEkuZS4gdGhlIHNpbmdsZSBz bGFzaCBqdXN0IGJyZWFrcyB0aGUgbGluZSwgYW5kIEkgdGhpbmsgdGhhdA0KDQo+IHRoaXMgbWF0 Y2hlcyBob3cgZWRpdG9ycywgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCBldGMgbm9ybWFsbHkgYmVo YXZlLg0KDQo+DQoNCj4gV2hhdCBJ4oCZbSBub3Qga2VlbiBvbiBpcyB1c2luZyBhIHNpbmdsZSBz bGFzaCwgYW5kIHRoZW4gYXV0b21hdGljYWxseQ0KDQo+IHN0cmlwcGluZyBsZWFkaW5nIHdoaXRl c3BhY2Ugb24gdGhlIGxpbmUgZm9sbG93aW5nIGEgc2xhc2guDQoNCg0KDQpBbmQgdGhpcyBpcyB0 aGUgc29sdXRpb24gdGhhdCBJIHByZWZlci4gIFRoZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBJ IHZpZXcgZXhhbXBsZXMgYXMgc29tZXRoaW5nIHRoYXQgaXMgdGhlcmUgdG8gaWxsdXN0cmF0ZSBz b21lIHBvaW50IHRvIHRoZSByZWFkZXIsIGFuZCBJIHRoaW5rIHRoYXQgYSBwcmV0dGllciBmb3Jt YXR0ZWQgZXhhbXBsZSB3aXRoIGxlc3Mgbm9pc2UgaGVscHMgdGhlIHJlYWRlci4gIEkgYWxzbyB0 aGluayB0aGF0IGlzIG1vc3QgY2FzZXMsIHRoaXMgd29ya3Mgd2VsbDsgaS5lLiwgbW9zdCBjYXNl cyBhcmUgX25vdF8gb24gdGhlIGZvcm06DQoNCg0KDQogICAxMjM0NSAgICAgIDc4OTkwDQoNCiAg ICAgICAgICBeLS0tLS0tLS0tLS0tLS0gSSBuZWVkIGEgbGluZSBicmVhayBoZXJlDQoNCg0KDQoN Cg0KRm9yIHRoaXMgcHJvYmxlbSwgSSBwcmVmZXIgYSBzb2x1dGlvbiB0aGF0IGlzIGludHVpdGl2 ZSBhbmQgaGFzIGxlc3Mgbm9pc2UgYW5kIHdvcmtzIGZvciA5MCUgb2YgdGhlIGNhc2VzLCB0aGFu IGEgbGVzcyBpbnR1aXRpdmUgc29sdXRpb24gd2l0aCBtb3JlIG5vaXNlIHRoYXQgd29ya3MgZm9y IDEwMCUgb2YgdGhlIGNhc2VzLg0KDQoNCg0KDQoNCi9tYXJ0aW4NCg0KDQoNCg0KDQoNCg0KPg0K DQo+IElmIHdlIHdhbnQgdG8gaGF2ZSBjb250cm9sIG9mIGxheW91dCBhbmQgYmUgYWJsZSB0byBz dHJpcCBleHRyYQ0KDQo+IHdoaXRlc3BhY2UgdGhlbiBteSBhcmd1bWVudCBpcyB0aGF0IGl0IGlz IGJldHRlciB0byBiZSBleHBsaWNpdCwgYW5kDQoNCj4gdXNpbmcgdHdvIHNsYXNoZXMgaXMgb25l IHdheSBvZiBhY2hpZXZpbmcgdGhpcy4NCg0KPg0KDQo+IFRoYW5rcywNCg0KPiBSb2INCg0KPg0K DQo+DQoNCj4NCg0KPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQoN Cj4gU2VudDogMjcgRmVicnVhcnkgMjAxOSAwOTo0MQ0KDQo+IFRvOiAnSm9lbCBKYWVnZ2xpJyA8 am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9lbGphQGJvZ3VzLmNvbT4+DQoNCj4gQ2M6IG5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFJlOiBbbmV0 bW9kXSBhcnR3b3JrIGZvbGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCg0KPg0KDQo+IENvbXBs ZXRlIGFncmVlbWVudCwgSm9lbC4NCg0KPg0KDQo+IFdoYXQgZm9sbG93cyBtYXkgbG9vayBiZXR0 ZXIgaW4gcHJvcG9ydGlvbmFsIGZvbnRzLg0KDQo+DQoNCj4gV2l0aCBhIHNpbmdsZSBzbGFzaCB3 ZSBjYW4gd3JhcCBhcyBmb2xsb3dzDQoNCj4NCg0KPiAxMjM0NTY3ICAgICAgICA5MDEyMzQ1DQoN Cj4NCg0KPiBHb2VzIHRv4oCmDQoNCj4NCg0KPiAxMjM0NTY3ICAgIFwNCg0KPiAgICAgOTAxMjM0 NQ0KDQo+DQoNCj4g4oCmYW5kIHVud3JhcHBpbmcgaXMgZWFzeS4NCg0KPg0KDQo+IEhvd2V2ZXIs IGlmIEkgd2FudCB0byBtYW51YWxseSB3cmFwIHRoZSBsaW5lIHdpdGggaW5kZW50YXRpb24NCg0K Pg0KDQo+IFRoZSBxdWljayBicm93biBmb3gganVtcHMgb3ZlciB0aGUgbGF6eSBkb2cNCg0KPg0K DQo+IC4uZ29pbmcgdG/igKYNCg0KPg0KDQo+IFRoZSBxdWljayBicm93biBmb3hcDQoNCj4gICAg ICAganVtcHMgb3ZlciB0aGUgbGF6eSBkb2cNCg0KPg0KDQo+IOKApkkgYW0gZ29pbmcgdG8gdW5m b2xkIGFz4oCmDQoNCj4NCg0KPiBUaGUgcXVpY2sgYnJvd24gZm94ICAgICAganVtcHMgb3ZlciB0 aGUgbGF6eSBkb2cNCg0KPg0KDQo+DQoNCj4gQ29udmVyc2VseSwgaWYgSSByZXNvbHZlIHRoaXMg c2Vjb25kIGNhc2UgYnkgc3RyaXBwaW5nIGxlYWRpbmcgc3BhY2VzDQoNCj4gSSBnZXTigKYNCg0K Pg0KDQo+IFRoZSBxdWljayBicm93biBmb3hqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KDQo+DQoN Cj4gU28gSSBoYXZlIHRvIGZvbGQgYXPigKYNCg0KPg0KDQo+IFRoZSBxdWljayBicm93biBmb3gg XA0KDQo+ICAgICAgIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQoNCj4NCg0KPiBCdXQgdGhpcyBj YXVzZXMgdGhlIGZpcnN0IGNhc2UgdG8gdW5mb2xkIGFzDQoNCj4NCg0KPiAxMjM0NTY3ICAgIDkw MTIzNDUNCg0KPg0KDQo+IOKApmkuZS4sIHdpdGggbWlzc2luZyBzcGFjZXMuDQoNCj4NCg0KPiBU aGlzIGlzIHdoYXQgY2F1c2VkIHRoZSB1c2Ugb2YgdGhlIHNlY29uZCBzbGFzaCBzb+KApg0KDQo+ DQoNCj4gMTIzNDU2NyAgICBcDQoNCj4gXCAgICA5MDEyMzQ1DQoNCj4NCg0KPiDigKZhbmTigKYN Cg0KPg0KDQo+IFRoZSBxdWljayBicm93biBmb3hcDQoNCj4gICAgICBcIGp1bXBzIG92ZXIgdGhl IGxhenkgZG9nDQoNCj4NCg0KPg0KDQo+IFNvLCBteSBwb2ludCBpcywgaWYgYW5kIG9ubHkgaWYg d2UgZG8gbm90IGNhcmUgYWJvdXQgdGhlc2Ug4oCcc3BhY2VzIG9uDQoNCj4gdGhlIGZvbGTigJ0g Y2FzZXMsIHdlIGNhbiBvcGVyYXRlIHdpdGggYSBzaW5nbGUgc2xhc2guDQoNCj4NCg0KPiBDaGVl cnMsDQoNCj4gQWRyaWFuDQoNCj4NCg0KPiBGcm9tOiBKb2VsIEphZWdnbGkgPGpvZWxqYUBib2d1 cy5jb208bWFpbHRvOmpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1cy5jb20lM2Nt YWlsdG86am9lbGphQGJvZ3VzLmNvbT4+Pg0KDQo+IFNlbnQ6IDI3IEZlYnJ1YXJ5IDIwMTkgMDY6 MzENCg0KPiBUbzogQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRy aWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayUzY21haWx0bzphZHJp YW5Ab2xkZG9nLmNvLnVrPj4+DQoNCj4gQ2M6IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2Vu Lm5ldDxtYWlsdG86a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4u bmV0JTNjbWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0Pj4+Ow0KDQo+IG5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmclM2NtYWlsdG86 bmV0bW9kQGlldGYub3JnPj4NCg0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gYXJ0d29yayBmb2xk aW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQoNCj4NCg0KPg0KDQo+DQoNCj4gT24gRmViIDI2LCAy MDE5LCBhdCAxNDoyNiwgQWRyaWFuIEZhcnJlbA0KDQo+IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1h aWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrJTNjbWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWs+Pj4gd3JvdGU6DQoNCj4NCg0KPiBIZXkuDQoNCj4NCg0K PiBJ4oCZdmUgYmVlbiBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uIHdpdGggS2VudCBvZmYtbGluZSwg YnV0IHRob3VnaHQgaXQNCg0KPiBzaG91bGQgY29tZSB0byB0aGUgbGlzdC4NCg0KPg0KDQo+IEkg ZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIHR3byBhcHByb2FjaGVzLiBX aGlsZSBpdCB3b3VsZA0KDQo+IGJlIHJlbGF0aXZlbHkgZWFzeSB0byBjb2RlIGZvciBib3RoIGFw cHJvYWNoZXMsIGl0IHNlZW1zIHRvIGFkZCBhDQoNCj4gZGVncmVlIG9mIGNvbmZ1c2lvbiBpZiBi b3RoIGhhdmUgdG8gYmUgaGFuZGxlZCBieSB0aGUgc2FtZSBjb2RlDQoNCj4gKGNvbnNpZGVyIGRl Y2lkaW5nIHdoZXRoZXIgbGVhZGluZyBzcGFjZSBjaGFyYWN0ZXJzIGFyZSB0byBiZSByZXRhaW5l ZA0KDQo+IG9yIG5vdCwgc29tZXRoaW5nIHRoYXQgY2FuIG9ubHkgYmUgZGVjaWRlZCB3aGVuIHRo ZSBmaXJzdCBub24tc3BhY2UNCg0KPiBjaGFyYWN0ZXIgaXMgZm91bmQpLCBvciBieSBoYXZpbmcg ZGlmZmVyZW50IGNvZGUgZm9yIHRoZSB0d28gZGlmZmVyZW50DQoNCj4gY2FzZXMuDQoNCj4NCg0K PiBJdCBkb2VzbuKAmXQgc2VlbSB0byBtZSB0aGF0IGJvdGggY2FzZXMgYXJlIG5lZWRlZC4gV2Ug Y2FuIHBpY2sgb25lIG9yDQoNCj4gdGhlIG90aGVyLg0KDQo+DQoNCj4gQSBzaW5nbGUgc2xhc2gg aGFzIGJlZW4gdXNlZCB0byB3cmFwIGxvbmcgbGluZXMgaW4gZWRpdG9ycyBhbmQgc2hlbGxzDQoN Cj4gZm9yIGRlY2FkZXMgYXQgdGhpcyBwb2ludC4NCg0KPg0KDQo+IGFuZCB5ZWFoIHdoYXRldmVy IGl0IGlzIG9uZSBtZXRob2Qgc2VlbXMgYmV0dGVyIHRoYW4gdHdvLg0KDQo+DQoNCj4NCg0KPiBB bmQgKmlmKiB3ZSB3YW50IHRvIGFsbG93IG1hbnVhbCBmb2xkaW5nIHNvIHRoYXQgaW5kZW50cyBj YW4gYmUgbWFkZQ0KDQo+IHRvIG1ha2UgdGhlIGRvY3VtZW50IG1vcmUgaHVtYW4tcmVhZGFibGUg dGhlbiB3ZSBoYXZlIHRvIHVzZSBhIGxlYWRpbmcNCg0KPiDigJhc4oCZIG9uIGNvbnRpbnVhdGlv biBsaW5lcyB0byBzaG93IHdoaWNoIHNwYWNlcyBzaG91bGQgYmUgc3RyaXBwZWQgYW5kDQoNCj4g d2hpY2ggcmV0YWluZWQuDQoNCj4NCg0KPiBDaGVlcnMsDQoNCj4gQWRyaWFuDQoNCj4NCg0KPiBG cm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmclM2NtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc+Pj4NCg0KPiBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NCg0KPiBT ZW50OiAyNSBGZWJydWFyeSAyMDE5IDIyOjIyDQoNCj4gVG86IG5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmclM2NtYWlsdG86bmV0bW9k QGlldGYub3JnPj4NCg0KPiBTdWJqZWN0OiBbbmV0bW9kXSBhcnR3b3JrIGZvbGRpbmc6IGR1YWwg c3VwcG9ydCBtb2Rlcz8NCg0KPg0KDQo+DQoNCj4gSSBoYWQgYSBjaGF0IHdpdGggdGhlIHRvb2xz IHRlYW0gcmVjZW50bHkgYW5kLCBpbiB0aGUgY291cnNlIG9mDQoNCj4gdGhpbmdzLCBpdCB3YXMg aW1wbGllZCB0aGF0IHRoZSBkb3VibGUgYmFja3NsYXNoIGFwcHJvYWNoIHdlIGhhdmUgbm93DQoN Cj4gd2FzIGJvdGggc3VycHJpc2luZyBhbmQgbm9uLWludHVpdGl2ZS4NCg0KPg0KDQo+IFRoaXMg Z290IG1lIHRoaW5raW5nIHRoYXQgd2UgbWF5IGhhdmUgdGhyb3duIHRoZSBwcm92ZXJiaWFsIGJh Ynkgb3V0DQoNCj4gd2l0aCB0aGUgYmF0aHdhdGVyLg0KDQo+IFRoYXQgaXMsIGN1cnJlbnRseSB3 ZSBoYXZlIGEgaGVhZGVyIHRoYXQgcmVhZHM6DQoNCj4NCg0KPg0KDQo+ICAgTk9URTogJ1xcJyBs aW5lIHdyYXBwaW5nIHBlciBCQ1AgWFggKFJGQyBYWFhYKQ0KDQo+DQoNCj4gU28gd2h5IG5vdCAq YWxzbyogc3VwcG9ydCBhIGhlYWRlciB0aGF0IHJlYWRzIChub3RlIHRoZSBzaW5nZSBzbGFzaCk6 DQoNCj4NCg0KPg0KDQo+ICAgTk9URTogJ1wnIGxpbmUgd3JhcHBpbmcgcGVyIEJDUCBYWCAoUkZD IFhYWFgpDQoNCj4NCg0KPiBXaGVyZWJ5IHRoaXMgc2Vjb25kIGZvcm0gb25seSBzdXBwb3J0cyB0 aGUgZm9sZGVkIGxpbmUgY29udGludWluZyBvbg0KDQo+IGNvbHVtbiAxIChubyBpbmRlbnRzKS4N Cg0KPg0KDQo+IFRob3VnaHRzPw0KDQo+DQoNCj4gS2VudCAvLyBjb250cmlidXRvcg0KDQo+DQoN Cj4NCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnJTNjbWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4+DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K Pg0K --_000_8ddf74d483674c598e52ece716f70d0aXCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CdXQgdGhpcyBiZWhhdmlvdXIgaXMgc3RpbGwg ZGlmZmVyZW50IGZyb20gdGhlIGZyZXF1ZW50bHkgdXNlZCBtZWFuaW5nIG9mIOKAmFzigJkgdG9k YXkgaW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCB3aGljaCBhcyBJIGtub3cgaXQganVzdCBzcGxp dHMgbGluZXMgYW5kIHByZXNlcnZlcyB3aGl0ZXNwYWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllB TkcgcmVxdWlyZXMgYSBzZXBhcmF0b3IgY2hhcmFjdGVyIGJldHdlZW4gYSBrZXl3b3JkIGFuZCBp dHMgYXJndW1lbnQuJm5ic3A7IFdoYXQgaGFwcGVucyBpZiB0aGUgdG9vbCBoYXBwZW5zIHRvIHNw bGl0IHRoZSBsaW5lIGJldHdlZW4gdGhlIHR3byBvZiB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5FLmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2NvbnRh aW5lclw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyB0ZXN0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BZnRlciB0aGUgYXJ0d29yayBmb2xkaW5nLCB0aGlzIHdv dWxkIGJlY29tZSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29u dGFpbmVydGVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBjb3Vs ZCBiZSBtaXRpZ2F0ZWQgYnkgYSBzbWFydGVyIGZvbGRpbmcgdG9vbCAoZS5nLiBzcGxpdCBiZWZv cmUgdGhlIOKAmHLigJkgb3IgYWZ0ZXIgdGhlIGZpcnN0IHNwYWNlKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+T3IsIHdoYXQgaWYgdGhlIHRvb2wgd2FzIGJlaW5nIHVzZWQgdG8gZm9s ZCBhIHRhYmxlIHRoYXQgd2FzIHVzaW5nIHdoaXRlc3BhY2UgdG8gYWxpZ24gdGhlIGNvbHVtbnMu Jm5ic3A7IFRoaXMgY291bGQgZWFzaWx5IGJyZWFrIGlmIHdoaXRlc3BhY2UgaXMgc3RyaXBwZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE1hcnRpbiBCam9y a2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OyA8YnI+DQpTZW50OiAwNCBNYXJjaCAyMDE5IDA4 OjQwPGJyPg0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZn dDs8YnI+DQpDYzogYWRyaWFuQG9sZGRvZy5jby51azsgam9lbGphQGJvZ3VzLmNvbTsgbmV0bW9k QGlldGYub3JnPGJyPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVh bCBzdXBwb3J0IG1vZGVzPzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZxdW90O1JvYiBXaWx0 b24gKHJ3aWx0b24pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5yd2ls dG9uQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgSGkgQWRyaWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgSSBtb3N0bHkgYWdyZWUgd2l0aCB5b3VyIGxhc3Qgc2VudGVuY2UuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJIHRoaW5rIHRoYXQgaWYgeW91IGFsd2F5cyBw cmVzZXJ2ZSB3aGl0ZXNwYWNlIHRoZW4gYSBzaW5nbGUgc2xhc2ggaXMNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBmaW5lLiZuYnNwOyBJLmUuIHRoZSBzaW5n bGUgc2xhc2gganVzdCBicmVha3MgdGhlIGxpbmUsIGFuZCBJIHRoaW5rIHRoYXQNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGlzIG1hdGNoZXMgaG93IGVk aXRvcnMsIHByb2dyYW1taW5nIGxhbmd1YWdlcywgZXRjIG5vcm1hbGx5IGJlaGF2ZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFdoYXQgSeKAmW0gbm90IGtlZW4gb24gaXMgdXNp bmcgYSBzaW5nbGUgc2xhc2gsIGFuZCB0aGVuIGF1dG9tYXRpY2FsbHkNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzdHJpcHBpbmcgbGVhZGluZyB3aGl0ZXNw YWNlIG9uIHRoZSBsaW5lIGZvbGxvd2luZyBhIHNsYXNoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5BbmQgdGhpcyBpcyB0aGUgc29sdXRpb24gdGhhdCBJIHByZWZlci4mbmJzcDsgVGhl IHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0IEkgdmlldyBleGFtcGxlcyBhcyBzb21ldGhpbmcgdGhh dCBpcyB0aGVyZSB0byBpbGx1c3RyYXRlIHNvbWUgcG9pbnQgdG8gdGhlIHJlYWRlciwgYW5kIEkg dGhpbmsgdGhhdCBhIHByZXR0aWVyIGZvcm1hdHRlZCBleGFtcGxlIHdpdGggbGVzcyBub2lzZSBo ZWxwcyB0aGUgcmVhZGVyLiZuYnNwOw0KIEkgYWxzbyB0aGluayB0aGF0IGlzIG1vc3QgY2FzZXMs IHRoaXMgd29ya3Mgd2VsbDsgaS5lLiwgbW9zdCBjYXNlcyBhcmUgX25vdF8gb24gdGhlIGZvcm06 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAxMjM0NSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3ODk5MDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IF4tLS0tLS0tLS0tLS0tLSBJIG5lZWQgYSBsaW5lIGJyZWFrIGhlcmU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5Gb3IgdGhpcyBwcm9ibGVtLCBJIHByZWZlciBhIHNvbHV0aW9uIHRoYXQg aXMgaW50dWl0aXZlIGFuZCBoYXMgbGVzcyBub2lzZSBhbmQgd29ya3MgZm9yIDkwJSBvZiB0aGUg Y2FzZXMsIHRoYW4gYSBsZXNzIGludHVpdGl2ZSBzb2x1dGlvbiB3aXRoIG1vcmUgbm9pc2UgdGhh dCB3b3JrcyBmb3IgMTAwJSBvZiB0aGUgY2FzZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L21hcnRp bjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgSWYgd2Ugd2FudCB0byBoYXZlIGNvbnRyb2wgb2YgbGF5b3V0IGFuZCBiZSBhYmxlIHRv IHN0cmlwIGV4dHJhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgd2hpdGVzcGFjZSB0aGVuIG15IGFyZ3VtZW50IGlzIHRoYXQgaXQgaXMgYmV0dGVyIHRvIGJl IGV4cGxpY2l0LCBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyB1c2luZyB0d28gc2xhc2hlcyBpcyBvbmUgd2F5IG9mIGFjaGlldmluZyB0aGlzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBSb2I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogbmV0bW9kICZs dDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5uZXRtb2QtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+Jmd0OyBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZW50OiAyNyBGZWJydWFyeSAyMDE5 IDA5OjQxPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiAn Sm9lbCBKYWVnZ2xpJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBib2d1cy5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5qb2VsamFAYm9n dXMuY29tPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bmV0bW9kQGlldGYub3Jn PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg U3ViamVjdDogUmU6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0IG1vZGVz PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ29tcGxldGUgYWdyZWVtZW50LCBK b2VsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgV2hhdCBmb2xsb3dzIG1heSBs b29rIGJldHRlciBpbiBwcm9wb3J0aW9uYWwgZm9udHMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBXaXRoIGEgc2luZ2xlIHNsYXNoIHdlIGNhbiB3cmFwIGFzIGZvbGxvd3M8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDEyMzQ1NjcmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOTAxMjM0NTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgR29lcyB0b+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMTIz NDU2NyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkwMTIzNDU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IOKApmFuZCB1bndyYXBwaW5nIGlzIGVhc3kuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIb3dldmVyLCBpZiBJIHdhbnQgdG8gbWFudWFsbHkg d3JhcCB0aGUgbGluZSB3aXRoIGluZGVudGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBUaGUgcXVpY2sgYnJvd24gZm94IGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAuLmdvaW5nIHRv4oCmPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgcXVpY2sgYnJvd24gZm94XDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsg4oCmSSBhbSBnb2luZyB0byB1bmZvbGQgYXPigKY8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IFRoZSBxdWljayBicm93biBmb3gmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsganVtcHMgb3ZlciB0aGUgbGF6eSBkb2c8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBD b252ZXJzZWx5LCBpZiBJIHJlc29sdmUgdGhpcyBzZWNvbmQgY2FzZSBieSBzdHJpcHBpbmcgbGVh ZGluZyBzcGFjZXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBJIGdldOKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIHF1aWNrIGJy b3duIGZveGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBTbyBJIGhhdmUgdG8gZm9sZCBhc+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgVGhlIHF1aWNrIGJyb3duIGZveCBcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGp1 bXBzIG92ZXIgdGhlIGxhenkgZG9nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBC dXQgdGhpcyBjYXVzZXMgdGhlIGZpcnN0IGNhc2UgdG8gdW5mb2xkIGFzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAxMjM0NTY3Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkwMTIzNDU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IOKApmkuZS4sIHdpdGggbWlzc2luZyBzcGFj ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGlzIGlzIHdoYXQgY2F1c2Vk IHRoZSB1c2Ugb2YgdGhlIHNlY29uZCBzbGFzaCBzb+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgMTIzNDU2NyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFwmbmJzcDsmbmJzcDsmbmJzcDsgOTAxMjM0NTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg4oCmYW5k4oCmPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgcXVpY2sgYnJvd24gZm94XDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBcIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU28sIG15 IHBvaW50IGlzLCBpZiBhbmQgb25seSBpZiB3ZSBkbyBub3QgY2FyZSBhYm91dCB0aGVzZSDigJxz cGFjZXMgb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0 aGUgZm9sZOKAnSBjYXNlcywgd2UgY2FuIG9wZXJhdGUgd2l0aCBhIHNpbmdsZSBzbGFzaC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IENoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQWRyaWFuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBGcm9tOiBKb2VsIEphZWdnbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2VsamFA Ym9ndXMuY29tJTNjbWFpbHRvOmpvZWxqYUBib2d1cy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5qb2VsamFAYm9ndXMuY29tJmx0O21haWx0 bzpqb2VsamFAYm9ndXMuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZW50OiAyNyBGZWJydWFyeSAyMDE5IDA2OjMxPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiBBZHJpYW4gRmFy cmVsICZsdDs8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayUzY21haWx0bzphZHJp YW5Ab2xkZG9nLmNvLnVrIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+YWRyaWFuQG9sZGRvZy5jby51ayZsdDttYWlsdG86YWRyaWFuQG9sZGRvZy5j by51azwvc3Bhbj48L2E+Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgQ2M6IEtlbnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCYjNDM7 aWV0ZkB3YXRzZW4ubmV0JTNjbWFpbHRvOmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmtlbnQmIzQzO2ll dGZAd2F0c2VuLm5ldCZsdDttYWlsdG86a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0PC9zcGFuPjwv YT4mZ3Q7Jmd0Ozs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyUzY21haWx0bzpuZXRtb2RAaWV0Zi5vcmci Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm5l dG1vZEBpZXRmLm9yZyZsdDttYWlsdG86bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN1YmplY3Q6IFJlOiBb bmV0bW9kXSBhcnR3b3JrIGZvbGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg T24gRmViIDI2LCAyMDE5LCBhdCAxNDoyNiwgQWRyaWFuIEZhcnJlbCA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrJTNjbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5hZHJpYW5Ab2xkZG9nLmNvLnVr Jmx0O21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPC9zcGFuPjwvYT4mZ3Q7Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEhleS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEnigJl2ZSBiZWVuIGhhdmluZyB0aGlzIGRpc2N1c3Npb24gd2l0aCBL ZW50IG9mZi1saW5lLCBidXQgdGhvdWdodCBpdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHNob3VsZCBjb21lIHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSSBkb27igJl0IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRv IGhhdmUgdHdvIGFwcHJvYWNoZXMuIFdoaWxlIGl0IHdvdWxkDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYmUgcmVsYXRpdmVseSBlYXN5IHRvIGNvZGUgZm9y IGJvdGggYXBwcm9hY2hlcywgaXQgc2VlbXMgdG8gYWRkIGENCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkZWdyZWUgb2YgY29uZnVzaW9uIGlmIGJvdGggaGF2 ZSB0byBiZSBoYW5kbGVkIGJ5IHRoZSBzYW1lIGNvZGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAoY29uc2lkZXIgZGVjaWRpbmcgd2hldGhlciBsZWFkaW5n IHNwYWNlIGNoYXJhY3RlcnMgYXJlIHRvIGJlIHJldGFpbmVkDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgb3Igbm90LCBzb21ldGhpbmcgdGhhdCBjYW4gb25s eSBiZSBkZWNpZGVkIHdoZW4gdGhlIGZpcnN0IG5vbi1zcGFjZQ0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGNoYXJhY3RlciBpcyBmb3VuZCksIG9yIGJ5IGhh dmluZyBkaWZmZXJlbnQgY29kZSBmb3IgdGhlIHR3byBkaWZmZXJlbnQNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEl0IGRvZXNu4oCZdCBzZWVtIHRvIG1lIHRoYXQgYm90aCBjYXNlcyBh cmUgbmVlZGVkLiBXZSBjYW4gcGljayBvbmUgb3INCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgb3RoZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBBIHNpbmdsZSBzbGFzaCBoYXMgYmVlbiB1c2VkIHRvIHdyYXAgbG9uZyBsaW5lcyBp biBlZGl0b3JzIGFuZCBzaGVsbHMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBmb3IgZGVjYWRlcyBhdCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgYW5kIHllYWggd2hhdGV2ZXIgaXQgaXMgb25lIG1ldGhvZCBzZWVtcyBi ZXR0ZXIgdGhhbiB0d28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQW5kICppZiogd2Ugd2FudCB0 byBhbGxvdyBtYW51YWwgZm9sZGluZyBzbyB0aGF0IGluZGVudHMgY2FuIGJlIG1hZGUNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0byBtYWtlIHRoZSBkb2N1 bWVudCBtb3JlIGh1bWFuLXJlYWRhYmxlIHRoZW4gd2UgaGF2ZSB0byB1c2UgYSBsZWFkaW5nDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg4oCYXOKAmSBvbiBj b250aW51YXRpb24gbGluZXMgdG8gc2hvdyB3aGljaCBzcGFjZXMgc2hvdWxkIGJlIHN0cmlwcGVk IGFuZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdoaWNo IHJldGFpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2hlZXJzLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBZHJpYW48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZyb206IG5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnJTNjbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmcmbHQ7bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9z cGFuPjwvYT4mZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgU2VudDogMjUgRmVicnVhcnkgMjAxOSAyMjoyMjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyUzY21haWx0bzpuZXRtb2RAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm5ldG1vZEBpZXRmLm9yZyZsdDtt YWlsdG86bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN1YmplY3Q6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGlu ZzogZHVhbCBzdXBwb3J0IG1vZGVzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgaGFkIGEgY2hh dCB3aXRoIHRoZSB0b29scyB0ZWFtIHJlY2VudGx5IGFuZCwgaW4gdGhlIGNvdXJzZSBvZg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoaW5ncywgaXQgd2Fz IGltcGxpZWQgdGhhdCB0aGUgZG91YmxlIGJhY2tzbGFzaCBhcHByb2FjaCB3ZSBoYXZlIG5vdw0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdhcyBib3RoIHN1 cnByaXNpbmcgYW5kIG5vbi1pbnR1aXRpdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBUaGlzIGdvdCBtZSB0aGlua2luZyB0aGF0IHdlIG1heSBoYXZlIHRocm93biB0aGUgcHJv dmVyYmlhbCBiYWJ5IG91dA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHdpdGggdGhlIGJhdGh3YXRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgVGhhdCBpcywgY3VycmVudGx5IHdlIGhhdmUgYSBoZWFkZXIgdGhhdCBy ZWFkczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyBOT1RFOiAnXFwnIGxpbmUg d3JhcHBpbmcgcGVyIEJDUCBYWCAoUkZDIFhYWFgpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBTbyB3aHkgbm90ICphbHNvKiBzdXBwb3J0IGEgaGVhZGVyIHRoYXQgcmVhZHMgKG5v dGUgdGhlIHNpbmdlIHNsYXNoKTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyBO T1RFOiAnXCcgbGluZSB3cmFwcGluZyBwZXIgQkNQIFhYIChSRkMgWFhYWCk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFdoZXJlYnkgdGhpcyBzZWNvbmQgZm9ybSBvbmx5IHN1cHBv cnRzIHRoZSBmb2xkZWQgbGluZSBjb250aW51aW5nIG9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgY29sdW1uIDEgKG5vIGluZGVudHMpLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhvdWdodHM/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBLZW50IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBocmVmPSJtYWlsdG86 bmV0bW9kQGlldGYub3JnJTNjbWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bmV0bW9kQGlldGYub3JnJmx0 O21haWx0bzpuZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8ddf74d483674c598e52ece716f70d0aXCHRCD007ciscocom_-- From nobody Mon Mar 4 03:49:18 2019 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 461F0130F2A for ; Mon, 4 Mar 2019 03:49:17 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 6-OvJszoTznb for ; Mon, 4 Mar 2019 03:49:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 317211288BD for ; Mon, 4 Mar 2019 03:49:14 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id DEF7E1AE0118; Mon, 4 Mar 2019 12:49:11 +0100 (CET) Date: Mon, 04 Mar 2019 12:49:12 +0100 (CET) Message-Id: <20190304.124912.231750494593528236.mbj@tail-f.com> To: rwilton@cisco.com Cc: adrian@olddog.co.uk, joelja@bogus.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> References: <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> <20190304.094006.527512831015675938.mbj@tail-f.com> <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 11:49:17 -0000 IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBCdXQg dGhpcyBiZWhhdmlvdXIgaXMgc3RpbGwgZGlmZmVyZW50IGZyb20gdGhlIGZyZXF1ZW50bHkgdXNl ZCBtZWFuaW5nDQo+IG9mIOKAmFzigJkgdG9kYXkgaW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCB3 aGljaCBhcyBJIGtub3cgaXQganVzdCBzcGxpdHMNCj4gbGluZXMgYW5kIHByZXNlcnZlcyB3aGl0 ZXNwYWNlLg0KDQpSaWdodCwgYnV0IHdlJ3JlIG5vdCBkb2luZyBhIHByb2dyYW1taW5nIGxhbmd1 YWdlLCB3ZSB0cnkgdG8gZml0IGxvbmcNCmxpbmVzIGluIGV4YW1wbGVzIGludG8gdGhlIGZvcm1h dCByZXF1aXJlZCBieSBSRkNzLCBpbmNsdWRpbmcNCmluZGVudGF0aW9uLiAgRm9yIGV4YW1wbGUs IHN1cHBvc2UgeW91IGhhdmU6DQoNCiAgSGVyZSdzIGFuIGV4YW1wbGU6DQoNCiAgZm9vIGJhciBi YXogXA0KICBidXp6DQoNClVuZm9sZGVkLCBkbyB5b3UgdGhpbmsgdGhpcyBpczoNCg0KICBmb28g YmFyIGJheiBidXp6DQoNCm9yDQoNCiAgZm9vIGJhciBiYXogICAgYnV6eg0KDQoNCj4gWUFORyBy ZXF1aXJlcyBhIHNlcGFyYXRvciBjaGFyYWN0ZXIgYmV0d2VlbiBhIGtleXdvcmQgYW5kIGl0cw0K PiBhcmd1bWVudC4gIFdoYXQgaGFwcGVucyBpZiB0aGUgdG9vbCBoYXBwZW5zIHRvIHNwbGl0IHRo ZSBsaW5lIGJldHdlZW4NCj4gdGhlIHR3byBvZiB0aGVtLg0KPiANCj4gDQo+IA0KPiBFLmcNCj4g DQo+ICAgICAgICAgICAgICAgICAgICAgICAgY29udGFpbmVyXA0KPiANCj4gICB0ZXN0DQo+IA0K PiANCj4gDQo+IEFmdGVyIHRoZSBhcnR3b3JrIGZvbGRpbmcsIHRoaXMgd291bGQgYmVjb21lDQo+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lcnRlc3QNCj4gDQo+IA0KPiANCj4g VGhpcyBjb3VsZCBiZSBtaXRpZ2F0ZWQgYnkgYSBzbWFydGVyIGZvbGRpbmcgdG9vbCAoZS5nLiBz cGxpdCBiZWZvcmUNCj4gdGhlIOKAmHLigJkgb3IgYWZ0ZXIgdGhlIGZpcnN0IHNwYWNlKS4NCg0K DQoxLiAgRG9uJ3QgdXNlIGEgdG9vbCB0byBhZGQgbGluZSBicmVha3MgLSByZW1lbWJlciB0aGUg Z29hbCB3YXMgdG8NCiAgICBoYXZlIGEgcmVhZGFibGUgZXhhbXBsZS4NCg0KMi4gIERvbid0IHVz ZSB0aGlzIGFsZy4gZm9yIFlBTkcgbW9kdWxlcywgc2luY2UgWUFORyBoYXMgYnVpbHRpbiAvDQog ICAgbmF0aXZlIHN1cHBvcnQgZm9yIHNwbGl0dGluZyBsb25nIGxpbmVzLg0KDQoNCj4gT3IsIHdo YXQgaWYgdGhlIHRvb2wgd2FzIGJlaW5nIHVzZWQgdG8gZm9sZCBhIHRhYmxlIHRoYXQgd2FzIHVz aW5nDQo+IHdoaXRlc3BhY2UgdG8gYWxpZ24gdGhlIGNvbHVtbnMuICBUaGlzIGNvdWxkIGVhc2ls eSBicmVhayBpZg0KPiB3aGl0ZXNwYWNlIGlzIHN0cmlwcGVkLg0KDQpEb24ndCB1c2UgdGhpcyBh bGcgZm9yIHRhYmxlcyAob3IgYXNjaWkgYXJ0IGluIGdlbmVyYWwpIC0tIGl0IHdvbid0DQpoZWxw IHJlYWRlcnMuDQoNCg0KL21hcnRpbg0KDQoNCg0KDQoNCj4gDQo+IA0KPiANCj4gVGhhbmtzLA0K PiBSb2INCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gU2VudDogMDQgTWFy Y2ggMjAxOSAwODo0MA0KPiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28u Y29tPg0KPiBDYzogYWRyaWFuQG9sZGRvZy5jby51azsgam9lbGphQGJvZ3VzLmNvbTsgbmV0bW9k QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhcnR3b3JrIGZvbGRpbmc6IGR1YWwg c3VwcG9ydCBtb2Rlcz8NCj4gDQo+IA0KPiANCj4gIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndp bHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4NCj4gd3JvdGU6DQo+IA0K PiA+IEhpIEFkcmlhbiwNCj4gDQo+ID4NCj4gDQo+ID4gSSBtb3N0bHkgYWdyZWUgd2l0aCB5b3Vy IGxhc3Qgc2VudGVuY2UuDQo+IA0KPiA+DQo+IA0KPiA+IEkgdGhpbmsgdGhhdCBpZiB5b3UgYWx3 YXlzIHByZXNlcnZlIHdoaXRlc3BhY2UgdGhlbiBhIHNpbmdsZSBzbGFzaCBpcw0KPiANCj4gPiBm aW5lLiAgSS5lLiB0aGUgc2luZ2xlIHNsYXNoIGp1c3QgYnJlYWtzIHRoZSBsaW5lLCBhbmQgSSB0 aGluayB0aGF0DQo+IA0KPiA+IHRoaXMgbWF0Y2hlcyBob3cgZWRpdG9ycywgcHJvZ3JhbW1pbmcg bGFuZ3VhZ2VzLCBldGMgbm9ybWFsbHkgYmVoYXZlLg0KPiANCj4gPg0KPiANCj4gPiBXaGF0IEni gJltIG5vdCBrZWVuIG9uIGlzIHVzaW5nIGEgc2luZ2xlIHNsYXNoLCBhbmQgdGhlbiBhdXRvbWF0 aWNhbGx5DQo+IA0KPiA+IHN0cmlwcGluZyBsZWFkaW5nIHdoaXRlc3BhY2Ugb24gdGhlIGxpbmUg Zm9sbG93aW5nIGEgc2xhc2guDQo+IA0KPiANCj4gDQo+IEFuZCB0aGlzIGlzIHRoZSBzb2x1dGlv biB0aGF0IEkgcHJlZmVyLiAgVGhlIHJlYXNvbiBmb3IgdGhpcyBpcyB0aGF0IEkNCj4gdmlldyBl eGFtcGxlcyBhcyBzb21ldGhpbmcgdGhhdCBpcyB0aGVyZSB0byBpbGx1c3RyYXRlIHNvbWUgcG9p bnQgdG8NCj4gdGhlIHJlYWRlciwgYW5kIEkgdGhpbmsgdGhhdCBhIHByZXR0aWVyIGZvcm1hdHRl ZCBleGFtcGxlIHdpdGggbGVzcw0KPiBub2lzZSBoZWxwcyB0aGUgcmVhZGVyLiAgSSBhbHNvIHRo aW5rIHRoYXQgaXMgbW9zdCBjYXNlcywgdGhpcyB3b3Jrcw0KPiB3ZWxsOyBpLmUuLCBtb3N0IGNh c2VzIGFyZSBfbm90XyBvbiB0aGUgZm9ybToNCj4gDQo+IA0KPiANCj4gICAgMTIzNDUgICAgICA3 ODk5MA0KPiANCj4gICAgICAgICAgIF4tLS0tLS0tLS0tLS0tLSBJIG5lZWQgYSBsaW5lIGJyZWFr IGhlcmUNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBGb3IgdGhpcyBwcm9ibGVtLCBJIHByZWZlciBh IHNvbHV0aW9uIHRoYXQgaXMgaW50dWl0aXZlIGFuZCBoYXMgbGVzcw0KPiBub2lzZSBhbmQgd29y a3MgZm9yIDkwJSBvZiB0aGUgY2FzZXMsIHRoYW4gYSBsZXNzIGludHVpdGl2ZSBzb2x1dGlvbg0K PiB3aXRoIG1vcmUgbm9pc2UgdGhhdCB3b3JrcyBmb3IgMTAwJSBvZiB0aGUgY2FzZXMuDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gL21hcnRpbg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g Pg0KPiANCj4gPiBJZiB3ZSB3YW50IHRvIGhhdmUgY29udHJvbCBvZiBsYXlvdXQgYW5kIGJlIGFi bGUgdG8gc3RyaXAgZXh0cmENCj4gDQo+ID4gd2hpdGVzcGFjZSB0aGVuIG15IGFyZ3VtZW50IGlz IHRoYXQgaXQgaXMgYmV0dGVyIHRvIGJlIGV4cGxpY2l0LCBhbmQNCj4gDQo+ID4gdXNpbmcgdHdv IHNsYXNoZXMgaXMgb25lIHdheSBvZiBhY2hpZXZpbmcgdGhpcy4NCj4gDQo+ID4NCj4gDQo+ID4g VGhhbmtzLA0KPiANCj4gPiBSb2INCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ID4g RnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmc+Pg0KPiA+IE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQo+IA0KPiA+IFNl bnQ6IDI3IEZlYnJ1YXJ5IDIwMTkgMDk6NDENCj4gDQo+ID4gVG86ICdKb2VsIEphZWdnbGknIDxq b2VsamFAYm9ndXMuY29tPG1haWx0bzpqb2VsamFAYm9ndXMuY29tPj4NCj4gDQo+ID4gQ2M6IG5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiANCj4gPiBTdWJqZWN0OiBS ZTogW25ldG1vZF0gYXJ0d29yayBmb2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQo+IA0KPiA+ DQo+IA0KPiA+IENvbXBsZXRlIGFncmVlbWVudCwgSm9lbC4NCj4gDQo+ID4NCj4gDQo+ID4gV2hh dCBmb2xsb3dzIG1heSBsb29rIGJldHRlciBpbiBwcm9wb3J0aW9uYWwgZm9udHMuDQo+IA0KPiA+ DQo+IA0KPiA+IFdpdGggYSBzaW5nbGUgc2xhc2ggd2UgY2FuIHdyYXAgYXMgZm9sbG93cw0KPiAN Cj4gPg0KPiANCj4gPiAxMjM0NTY3ICAgICAgICA5MDEyMzQ1DQo+IA0KPiA+DQo+IA0KPiA+IEdv ZXMgdG/igKYNCj4gDQo+ID4NCj4gDQo+ID4gMTIzNDU2NyAgICBcDQo+IA0KPiA+ICAgICA5MDEy MzQ1DQo+IA0KPiA+DQo+IA0KPiA+IOKApmFuZCB1bndyYXBwaW5nIGlzIGVhc3kuDQo+IA0KPiA+ DQo+IA0KPiA+IEhvd2V2ZXIsIGlmIEkgd2FudCB0byBtYW51YWxseSB3cmFwIHRoZSBsaW5lIHdp dGggaW5kZW50YXRpb24NCj4gDQo+ID4NCj4gDQo+ID4gVGhlIHF1aWNrIGJyb3duIGZveCBqdW1w cyBvdmVyIHRoZSBsYXp5IGRvZw0KPiANCj4gPg0KPiANCj4gPiAuLmdvaW5nIHRv4oCmDQo+IA0K PiA+DQo+IA0KPiA+IFRoZSBxdWljayBicm93biBmb3hcDQo+IA0KPiA+ICAgICAgIGp1bXBzIG92 ZXIgdGhlIGxhenkgZG9nDQo+IA0KPiA+DQo+IA0KPiA+IOKApkkgYW0gZ29pbmcgdG8gdW5mb2xk IGFz4oCmDQo+IA0KPiA+DQo+IA0KPiA+IFRoZSBxdWljayBicm93biBmb3ggICAgICBqdW1wcyBv dmVyIHRoZSBsYXp5IGRvZw0KPiANCj4gPg0KPiANCj4gPg0KPiANCj4gPiBDb252ZXJzZWx5LCBp ZiBJIHJlc29sdmUgdGhpcyBzZWNvbmQgY2FzZSBieSBzdHJpcHBpbmcgbGVhZGluZyBzcGFjZXMN Cj4gDQo+ID4gSSBnZXTigKYNCj4gDQo+ID4NCj4gDQo+ID4gVGhlIHF1aWNrIGJyb3duIGZveGp1 bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+IA0KPiA+DQo+IA0KPiA+IFNvIEkgaGF2ZSB0byBmb2xk IGFz4oCmDQo+IA0KPiA+DQo+IA0KPiA+IFRoZSBxdWljayBicm93biBmb3ggXA0KPiANCj4gPiAg ICAgICBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KPiANCj4gPg0KPiANCj4gPiBCdXQgdGhpcyBj YXVzZXMgdGhlIGZpcnN0IGNhc2UgdG8gdW5mb2xkIGFzDQo+IA0KPiA+DQo+IA0KPiA+IDEyMzQ1 NjcgICAgOTAxMjM0NQ0KPiANCj4gPg0KPiANCj4gPiDigKZpLmUuLCB3aXRoIG1pc3Npbmcgc3Bh Y2VzLg0KPiANCj4gPg0KPiANCj4gPiBUaGlzIGlzIHdoYXQgY2F1c2VkIHRoZSB1c2Ugb2YgdGhl IHNlY29uZCBzbGFzaCBzb+KApg0KPiANCj4gPg0KPiANCj4gPiAxMjM0NTY3ICAgIFwNCj4gDQo+ ID4gXCAgICA5MDEyMzQ1DQo+IA0KPiA+DQo+IA0KPiA+IOKApmFuZOKApg0KPiANCj4gPg0KPiAN Cj4gPiBUaGUgcXVpY2sgYnJvd24gZm94XA0KPiANCj4gPiAgICAgIFwganVtcHMgb3ZlciB0aGUg bGF6eSBkb2cNCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ID4gU28sIG15IHBvaW50IGlzLCBpZiBh bmQgb25seSBpZiB3ZSBkbyBub3QgY2FyZSBhYm91dCB0aGVzZSDigJxzcGFjZXMgb24NCj4gDQo+ ID4gdGhlIGZvbGTigJ0gY2FzZXMsIHdlIGNhbiBvcGVyYXRlIHdpdGggYSBzaW5nbGUgc2xhc2gu DQo+IA0KPiA+DQo+IA0KPiA+IENoZWVycywNCj4gDQo+ID4gQWRyaWFuDQo+IA0KPiA+DQo+IA0K PiA+IEZyb206IEpvZWwgSmFlZ2dsaQ0KPiA+IDxqb2VsamFAYm9ndXMuY29tPG1haWx0bzpqb2Vs amFAYm9ndXMuY29tPG1haWx0bzpqb2VsamFAYm9ndXMuY29tJTNjbWFpbHRvOmpvZWxqYUBib2d1 cy5jb20+Pj4NCj4gDQo+ID4gU2VudDogMjcgRmVicnVhcnkgMjAxOSAwNjozMQ0KPiANCj4gPiBU bzogQWRyaWFuIEZhcnJlbA0KPiA+IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrJTNjbWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+Pj4NCj4gDQo+ID4gQ2M6IEtlbnQgV2F0c2VuDQo+ID4gPGtlbnQraWV0ZkB3 YXRzZW4ubmV0PG1haWx0bzprZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCtpZXRmQHdh dHNlbi5uZXQlM2NtYWlsdG86a2VudCtpZXRmQHdhdHNlbi5uZXQ+Pj47DQo+IA0KPiA+IG5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmcl M2NtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2Rd IGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0IG1vZGVzPw0KPiANCj4gPg0KPiANCj4gPg0K PiANCj4gPg0KPiANCj4gPiBPbiBGZWIgMjYsIDIwMTksIGF0IDE0OjI2LCBBZHJpYW4gRmFycmVs DQo+IA0KPiA+IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVr PG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrJTNjbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+ Pj4NCj4gPiB3cm90ZToNCj4gDQo+ID4NCj4gDQo+ID4gSGV5Lg0KPiANCj4gPg0KPiANCj4gPiBJ 4oCZdmUgYmVlbiBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uIHdpdGggS2VudCBvZmYtbGluZSwgYnV0 IHRob3VnaHQgaXQNCj4gDQo+ID4gc2hvdWxkIGNvbWUgdG8gdGhlIGxpc3QuDQo+IA0KPiA+DQo+ IA0KPiA+IEkgZG9u4oCZdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIHR3byBhcHBy b2FjaGVzLiBXaGlsZSBpdCB3b3VsZA0KPiANCj4gPiBiZSByZWxhdGl2ZWx5IGVhc3kgdG8gY29k ZSBmb3IgYm90aCBhcHByb2FjaGVzLCBpdCBzZWVtcyB0byBhZGQgYQ0KPiANCj4gPiBkZWdyZWUg b2YgY29uZnVzaW9uIGlmIGJvdGggaGF2ZSB0byBiZSBoYW5kbGVkIGJ5IHRoZSBzYW1lIGNvZGUN Cj4gDQo+ID4gKGNvbnNpZGVyIGRlY2lkaW5nIHdoZXRoZXIgbGVhZGluZyBzcGFjZSBjaGFyYWN0 ZXJzIGFyZSB0byBiZSByZXRhaW5lZA0KPiANCj4gPiBvciBub3QsIHNvbWV0aGluZyB0aGF0IGNh biBvbmx5IGJlIGRlY2lkZWQgd2hlbiB0aGUgZmlyc3Qgbm9uLXNwYWNlDQo+IA0KPiA+IGNoYXJh Y3RlciBpcyBmb3VuZCksIG9yIGJ5IGhhdmluZyBkaWZmZXJlbnQgY29kZSBmb3IgdGhlIHR3byBk aWZmZXJlbnQNCj4gDQo+ID4gY2FzZXMuDQo+IA0KPiA+DQo+IA0KPiA+IEl0IGRvZXNu4oCZdCBz ZWVtIHRvIG1lIHRoYXQgYm90aCBjYXNlcyBhcmUgbmVlZGVkLiBXZSBjYW4gcGljayBvbmUgb3IN Cj4gDQo+ID4gdGhlIG90aGVyLg0KPiANCj4gPg0KPiANCj4gPiBBIHNpbmdsZSBzbGFzaCBoYXMg YmVlbiB1c2VkIHRvIHdyYXAgbG9uZyBsaW5lcyBpbiBlZGl0b3JzIGFuZCBzaGVsbHMNCj4gDQo+ ID4gZm9yIGRlY2FkZXMgYXQgdGhpcyBwb2ludC4NCj4gDQo+ID4NCj4gDQo+ID4gYW5kIHllYWgg d2hhdGV2ZXIgaXQgaXMgb25lIG1ldGhvZCBzZWVtcyBiZXR0ZXIgdGhhbiB0d28uDQo+IA0KPiA+ DQo+IA0KPiA+DQo+IA0KPiA+IEFuZCAqaWYqIHdlIHdhbnQgdG8gYWxsb3cgbWFudWFsIGZvbGRp bmcgc28gdGhhdCBpbmRlbnRzIGNhbiBiZSBtYWRlDQo+IA0KPiA+IHRvIG1ha2UgdGhlIGRvY3Vt ZW50IG1vcmUgaHVtYW4tcmVhZGFibGUgdGhlbiB3ZSBoYXZlIHRvIHVzZSBhIGxlYWRpbmcNCj4g DQo+ID4g4oCYXOKAmSBvbiBjb250aW51YXRpb24gbGluZXMgdG8gc2hvdyB3aGljaCBzcGFjZXMg c2hvdWxkIGJlIHN0cmlwcGVkIGFuZA0KPiANCj4gPiB3aGljaCByZXRhaW5lZC4NCj4gDQo+ID4N Cj4gDQo+ID4gQ2hlZXJzLA0KPiANCj4gPiBBZHJpYW4NCj4gDQo+ID4NCj4gDQo+ID4gRnJvbTog bmV0bW9kDQo+ID4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmclM2NtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc+Pj4NCj4gDQo+ID4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQo+ IA0KPiA+IFNlbnQ6IDI1IEZlYnJ1YXJ5IDIwMTkgMjI6MjINCj4gDQo+ID4gVG86DQo+ID4gbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y ZyUzY21haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KPiANCj4gPiBTdWJqZWN0OiBbbmV0bW9kXSBh cnR3b3JrIGZvbGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCj4gDQo+ID4NCj4gDQo+ID4NCj4g DQo+ID4gSSBoYWQgYSBjaGF0IHdpdGggdGhlIHRvb2xzIHRlYW0gcmVjZW50bHkgYW5kLCBpbiB0 aGUgY291cnNlIG9mDQo+IA0KPiA+IHRoaW5ncywgaXQgd2FzIGltcGxpZWQgdGhhdCB0aGUgZG91 YmxlIGJhY2tzbGFzaCBhcHByb2FjaCB3ZSBoYXZlIG5vdw0KPiANCj4gPiB3YXMgYm90aCBzdXJw cmlzaW5nIGFuZCBub24taW50dWl0aXZlLg0KPiANCj4gPg0KPiANCj4gPiBUaGlzIGdvdCBtZSB0 aGlua2luZyB0aGF0IHdlIG1heSBoYXZlIHRocm93biB0aGUgcHJvdmVyYmlhbCBiYWJ5IG91dA0K PiANCj4gPiB3aXRoIHRoZSBiYXRod2F0ZXIuDQo+IA0KPiA+IFRoYXQgaXMsIGN1cnJlbnRseSB3 ZSBoYXZlIGEgaGVhZGVyIHRoYXQgcmVhZHM6DQo+IA0KPiA+DQo+IA0KPiA+DQo+IA0KPiA+ICAg Tk9URTogJ1xcJyBsaW5lIHdyYXBwaW5nIHBlciBCQ1AgWFggKFJGQyBYWFhYKQ0KPiANCj4gPg0K PiANCj4gPiBTbyB3aHkgbm90ICphbHNvKiBzdXBwb3J0IGEgaGVhZGVyIHRoYXQgcmVhZHMgKG5v dGUgdGhlIHNpbmdlIHNsYXNoKToNCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ID4gICBOT1RFOiAn XCcgbGluZSB3cmFwcGluZyBwZXIgQkNQIFhYIChSRkMgWFhYWCkNCj4gDQo+ID4NCj4gDQo+ID4g V2hlcmVieSB0aGlzIHNlY29uZCBmb3JtIG9ubHkgc3VwcG9ydHMgdGhlIGZvbGRlZCBsaW5lIGNv bnRpbnVpbmcgb24NCj4gDQo+ID4gY29sdW1uIDEgKG5vIGluZGVudHMpLg0KPiANCj4gPg0KPiAN Cj4gPiBUaG91Z2h0cz8NCj4gDQo+ID4NCj4gDQo+ID4gS2VudCAvLyBjb250cmlidXRvcg0KPiAN Cj4gPg0KPiANCj4gPg0KPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiANCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IA0KPiA+IG5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmcl M2NtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+ID4NCg== From nobody Mon Mar 4 03:59:59 2019 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 CDE0412D4E6 for ; Mon, 4 Mar 2019 03:59:57 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 RGeOLmOIMp1I for ; Mon, 4 Mar 2019 03:59:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2CD130F3E for ; Mon, 4 Mar 2019 03:59:55 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 39ED81AE0118; Mon, 4 Mar 2019 12:59:53 +0100 (CET) Date: Mon, 04 Mar 2019 12:59:54 +0100 (CET) Message-Id: <20190304.125954.2202467396264498027.mbj@tail-f.com> To: chopps@chopps.org Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20190304.105940.312797647046250578.mbj@tail-f.com> References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> <20190304.105940.312797647046250578.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 11:59:58 -0000 Martin Bjorklund wrote: > Hi, > > Just some quick comments on the YANG: > > The pattern > > '[-0-9a-z #x22#x23#x5B#x5D' + > '!$%&()*+,\./:;<=>?@\\^_`{|}~]+'; > > doesn't seem to be correct. I think it should be: > > '[-0-9a-z "#[\]' + > '!$%&()*+,./:;<=>?@\\^_`{|}~]+'; > > i.e., don't use hex codes (the regex dialect we use > don't support them, and besides, the normal syntax is \x22 etc.), and > don't escape characters that don't need escapes. > > However, it seems libxml2's regexp engine requires both "[" and "^" to > be escaped: > > '[-0-9a-z "#\[\]' + > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; > > This expression isn't wrong, but it seems to me that these characters > should not have to be escaped. It turns out that "[" actually must be escaped, but the handling of "^" is a bug in libxml2: https://bugzilla.gnome.org/show_bug.cgi?id=779751 https://bugzilla.gnome.org/show_bug.cgi?id=674411 /martin > > > The pattern allows double quote (") but not single quote ('). Is > that intentional? > > [a simple way to test the patterns is to have a "default" statement > and a YANG complier that verifies defaults] > > > > I recommend that you rename the example module in section to > "example-uses-geo-location" (and change the namespace to > urn:example:uses-geo-location). We should not use the "ietf" > namespace for examples. > > > > /martin > > > > > > > Christian Hopps wrote: > > FYI. > > > > > Begin forwarded message: > > > > > > From: internet-drafts@ietf.org > > > Subject: I-D Action: draft-chopps-netmod-geo-location-00.txt > > > Date: February 26, 2019 at 3:59:23 PM EST > > > To: > > > Reply-To: internet-drafts@ietf.org > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > > > > Title : YANG Geo Location > > > Author : Christian Hopps > > > Filename : draft-chopps-netmod-geo-location-00.txt > > > Pages : 17 > > > Date : 2019-02-26 > > > > > > Abstract: > > > This document defines a generic geographical location object YANG > > > grouping. The geographical location grouping is intended to be used > > > in YANG models for specifying a location on or in reference to the > > > Earth or any other astronomical object. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-chopps-netmod-geo-location-00 > > > https://datatracker.ietf.org/doc/html/draft-chopps-netmod-geo-location-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/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Mar 4 04:08:22 2019 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 A40F113104E for ; Mon, 4 Mar 2019 04:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 HdPxII5DbDie for ; Mon, 4 Mar 2019 04:08:18 -0800 (PST) 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 7E0E812D4EB for ; Mon, 4 Mar 2019 04:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9096; q=dns/txt; s=iport; t=1551701297; x=1552910897; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=246+TgE94/Jbxg/drv6mtXq9pmIBP9J8u/RBjYA4I/8=; b=Z0DRsFqBo+rJhMCmLrQcWP+/6hgj1vdd/SsM/v7dHdtjHevQctA6hZ2A 39xu8ZXO5MjpCcwcFe+UKvbqH0Ca0UMiLs4E+FXxLF84/LHcLbBF2NiT1 YxBvPOcuPtDOPg+FsnfSx+NB3JyNYOG7hHglf1K5qePfODjscGgdEMvVQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAACEFH1c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgndQIRIng0hAiHmMSi2YNYFnDRgLhAN?= =?us-ascii?q?GAoRDNwYNAQEDAQEDAQMCbRwMhUoBAQEDAQEBChcPAQU2CwUHBAkCDgMEAQE?= =?us-ascii?q?BAgIjAwICJx8JCAYNBgIBAReDBwGBbQgPjE6bZoEvhUSEWwWBCyQBiz6BQD+?= =?us-ascii?q?BESeCa4MeAQGBSYMiglcCihADLAKNFYtRXQmSbgYZiniBa4Y/lXyHMoFdIoF?= =?us-ascii?q?WMxoIGxU7gmyLDIU/PwMwkRUBAQ?= X-IronPort-AV: E=Sophos;i="5.58,440,1544486400"; d="scan'208";a="10530253" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 12:08:15 +0000 Received: from [10.63.23.61] (dhcp-ensft1-uk-vla370-10-63-23-61.cisco.com [10.63.23.61]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x24C8ESd019949; Mon, 4 Mar 2019 12:08:14 GMT To: Martin Bjorklund Cc: adrian@olddog.co.uk, joelja@bogus.com, netmod@ietf.org References: <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> <20190304.094006.527512831015675938.mbj@tail-f.com> <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> <20190304.124912.231750494593528236.mbj@tail-f.com> From: Robert Wilton Message-ID: <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> Date: Mon, 4 Mar 2019 12:08:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <20190304.124912.231750494593528236.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.61, dhcp-ensft1-uk-vla370-10-63-23-61.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 12:08:21 -0000 On 04/03/2019 11:49, Martin Bjorklund wrote: > "Rob Wilton (rwilton)" wrote: >> But this behaviour is still different from the frequently used meaning >> of ‘\’ today in programming languages, which as I know it just splits >> lines and preserves whitespace. > Right, but we're not doing a programming language, we try to fit long > lines in examples into the format required by RFCs, including > indentation. But this does give a different meaning to a well used notation, that may well cause surprise and confusion. > For example, suppose you have: > > Here's an example: > > foo bar baz \ > buzz > > Unfolded, do you think this is: > > foo bar baz buzz > > or > > foo bar baz buzz This one.  The counter example: foo bar baz\ buzz Do you think that this is: foo bar bazbuzz Or foo bar baz buzz > > >> YANG requires a separator character between a keyword and its >> argument. What happens if the tool happens to split the line between >> the two of them. >> >> >> >> E.g >> >> container\ >> >> test >> >> >> >> After the artwork folding, this would become >> >> containertest >> >> >> >> This could be mitigated by a smarter folding tool (e.g. split before >> the ‘r’ or after the first space). > > 1. Don't use a tool to add line breaks - remember the goal was to > have a readable example. No line break is added.  It was performing a line split on "container test". > > 2. Don't use this alg. for YANG modules, since YANG has builtin / > native support for splitting long lines. > > >> Or, what if the tool was being used to fold a table that was using >> whitespace to align the columns. This could easily break if >> whitespace is stripped. > Don't use this alg for tables (or ascii art in general) -- it won't > help readers. The choice of solution seems to make it quite restricted where it can be validly used.  I.e. it is only safe to use to fold documents where whitespace has no significance, and can be arbitrarily removed from the folded object without changing the document's meaning. I think that this would mean that the folding mechanism isn't safe on either XML or JSON documents (since whitespace is significant, e.g. within a string). There seems to be a ever growing list of things that we can't safely use this form of artwork folding on.  Are there are any examples of stuff that we can safely use it on? ;-) Thanks, Rob > > > /martin > > > > > >> >> >> Thanks, >> Rob >> >> >> >> >> >> -----Original Message----- >> From: Martin Bjorklund >> Sent: 04 March 2019 08:40 >> To: Rob Wilton (rwilton) >> Cc: adrian@olddog.co.uk; joelja@bogus.com; netmod@ietf.org >> Subject: Re: [netmod] artwork folding: dual support modes? >> >> >> >> "Rob Wilton (rwilton)" > >> wrote: >> >>> Hi Adrian, >>> I mostly agree with your last sentence. >>> I think that if you always preserve whitespace then a single slash is >>> fine. I.e. the single slash just breaks the line, and I think that >>> this matches how editors, programming languages, etc normally behave. >>> What I’m not keen on is using a single slash, and then automatically >>> stripping leading whitespace on the line following a slash. >> >> >> And this is the solution that I prefer. The reason for this is that I >> view examples as something that is there to illustrate some point to >> the reader, and I think that a prettier formatted example with less >> noise helps the reader. I also think that is most cases, this works >> well; i.e., most cases are _not_ on the form: >> >> >> >> 12345 78990 >> >> ^-------------- I need a line break here >> >> >> >> >> >> For this problem, I prefer a solution that is intuitive and has less >> noise and works for 90% of the cases, than a less intuitive solution >> with more noise that works for 100% of the cases. >> >> >> >> >> >> /martin >> >> >> >> >> >> >> >>> If we want to have control of layout and be able to strip extra >>> whitespace then my argument is that it is better to be explicit, and >>> using two slashes is one way of achieving this. >>> Thanks, >>> Rob >>> From: netmod > >>> On Behalf Of Adrian Farrel >>> Sent: 27 February 2019 09:41 >>> To: 'Joel Jaeggli' > >>> Cc: netmod@ietf.org >>> Subject: Re: [netmod] artwork folding: dual support modes? >>> Complete agreement, Joel. >>> What follows may look better in proportional fonts. >>> With a single slash we can wrap as follows >>> 1234567 9012345 >>> Goes to… >>> 1234567 \ >>> 9012345 >>> …and unwrapping is easy. >>> However, if I want to manually wrap the line with indentation >>> The quick brown fox jumps over the lazy dog >>> ..going to… >>> The quick brown fox\ >>> jumps over the lazy dog >>> …I am going to unfold as… >>> The quick brown fox jumps over the lazy dog >>> Conversely, if I resolve this second case by stripping leading spaces >>> I get… >>> The quick brown foxjumps over the lazy dog >>> So I have to fold as… >>> The quick brown fox \ >>> jumps over the lazy dog >>> But this causes the first case to unfold as >>> 1234567 9012345 >>> …i.e., with missing spaces. >>> This is what caused the use of the second slash so… >>> 1234567 \ >>> \ 9012345 >>> …and… >>> The quick brown fox\ >>> \ jumps over the lazy dog >>> So, my point is, if and only if we do not care about these “spaces on >>> the fold†cases, we can operate with a single slash. >>> Cheers, >>> Adrian >>> From: Joel Jaeggli >>> >> >>> Sent: 27 February 2019 06:31 >>> To: Adrian Farrel >>> >> >>> Cc: Kent Watsen >>> >>; >>> netmod@ietf.org> >>> Subject: Re: [netmod] artwork folding: dual support modes? >>> On Feb 26, 2019, at 14:26, Adrian Farrel >>> >> >>> wrote: >>> Hey. >>> I’ve been having this discussion with Kent off-line, but thought it >>> should come to the list. >>> I don’t think it is a good idea to have two approaches. While it would >>> be relatively easy to code for both approaches, it seems to add a >>> degree of confusion if both have to be handled by the same code >>> (consider deciding whether leading space characters are to be retained >>> or not, something that can only be decided when the first non-space >>> character is found), or by having different code for the two different >>> cases. >>> It doesn’t seem to me that both cases are needed. We can pick one or >>> the other. >>> A single slash has been used to wrap long lines in editors and shells >>> for decades at this point. >>> and yeah whatever it is one method seems better than two. >>> And *if* we want to allow manual folding so that indents can be made >>> to make the document more human-readable then we have to use a leading >>> ‘\’ on continuation lines to show which spaces should be stripped and >>> which retained. >>> Cheers, >>> Adrian >>> From: netmod >>> >> >>> On Behalf Of Kent Watsen >>> Sent: 25 February 2019 22:22 >>> To: >>> netmod@ietf.org> >>> Subject: [netmod] artwork folding: dual support modes? >>> I had a chat with the tools team recently and, in the course of >>> things, it was implied that the double backslash approach we have now >>> was both surprising and non-intuitive. >>> This got me thinking that we may have thrown the proverbial baby out >>> with the bathwater. >>> That is, currently we have a header that reads: >>> NOTE: '\\' line wrapping per BCP XX (RFC XXXX) >>> So why not *also* support a header that reads (note the singe slash): >>> NOTE: '\' line wrapping per BCP XX (RFC XXXX) >>> Whereby this second form only supports the folded line continuing on >>> column 1 (no indents). >>> Thoughts? >>> Kent // contributor >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org> >>> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Mar 4 04:15:46 2019 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 2DDE3130F3E for ; Mon, 4 Mar 2019 04:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 Rh63U84xZ8gM for ; Mon, 4 Mar 2019 04:15:40 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 50930129B88 for ; Mon, 4 Mar 2019 04:15:40 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24CFOA9021980; Mon, 4 Mar 2019 12:15:24 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3C00222044; Mon, 4 Mar 2019 12:15:24 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 301B82203C; Mon, 4 Mar 2019 12:15:24 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24CFMEB020440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Mar 2019 12:15:23 GMT Reply-To: From: "Adrian Farrel" To: "'Martin Bjorklund'" , Cc: , References: <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> <20190304.094006.527512831015675938.mbj@tail-f.com> <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> <20190304.124912.231750494593528236.mbj@tail-f.com> In-Reply-To: <20190304.124912.231750494593528236.mbj@tail-f.com> Date: Mon, 4 Mar 2019 12:15:21 -0000 Organization: Old Dog Consulting Message-ID: <0a8601d4d283$f13b2180$d3b16480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMHu3WhtJkAHXxS/VctXzN5BZqX3AFAA0wXAiaXwNYCd9eZJ6NmmLQg Content-Language: en-gb X-Originating-IP: 87.112.237.8 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24468.007 X-TM-AS-Result: No--24.874-10.0-31-10 X-imss-scan-details: No--24.874-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24468.007 X-TMASE-Result: 10--24.874200-10.000000 X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbBrhN1MlBxtXlavqJJda2A9tw+n+iKWyyDUi 2rTIOxGGHj9B9PDoFzY5OiEBrpf5GIn6k1037kFFbMGKOuLn5FW/yN2q8U674pMxNpDOG+h6MoL 75Np9g5Hofwk6BENqt4SntUu3UyDoN6IarY2VLsXLXx7n52sqBtvZ+Av1leBDtXl9IxEPXOpL2N LsmEw1pour1HfBNMzymoZiR6+1rnpJJDuM6qazTp+EzsRrGT9IAlw1lJDBMtbnlNKhb+fAftzDh HEbpyKJL2xKyO2nWckXrDym7KLmMXmg0CBYPBomVP9jNEQH04qISipZVWCNK3rLpEOVMxqCIQ+L dPSbXXfjwrdDzo+b5CLwFvmVycNTyttJ+hdquL10+657dxGJGEopYlyHMD9xFdX7UGTqqi88pP1 yRKiQEKV1uIiqSYhttNBc5cDzl52kOIY39zkh2INoF/xJo8tUGK57kZ/2mal5QxmV/TDSy+SRrT Xa9QISP0hUFl/RZU7F6+8r30DovKNvJJBiq11aeqVpqRXfKN798SfleimUWgFbHA9TqNLQzMTXS bS0boyUdP0yWQMv8Q0+N8q2MiER3yonOZkt7j1+H/Q3vgskAlNYbkWQyPvqrnXbZcNeApMqbQiL HBNHpvdblpHZADIqZb0EtRCZTyjD6egsHKBhOPVFR4sC8dPyh8Ytn75ClDNq4coTktrGXwO6X04 dSW3WmlpTJ7lBraGT9qSqoOimPOWQ0Aaj99laj5hLPCX3ZdPj5lyuq8IOQSvkvrkNi/adupCV1T w0TOmq/r7ujTTNh0vG5ZTMMcYZhTfqy01DegSeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b+BikYCu AJJ8gtuKBGekqUpPjKoPgsq7cA= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 12:15:44 -0000 We can go round and round =F0=9F=98=8A How do I fold foo bar baz buzz so that it can be unfolded? Clearly a possibility is foo bar baz \ buzz But what if the line length would break in the white space? You could solve it as=20 foo bar \ baz buzz which requires slightly more complex folding. Actually, this case arises more often than you might think when the line = length would cause a fold before a single space. Thus, if the line length is 11 foo bar baz buzz ..would fold as... foo bar baz\ buzz ...and unfold as... foo bar bazbuzz ...if leading spaces are stripped. And if leading spaces are not stripped then we cannot handle manual = padding for reasons of visual formatting. For example... foo bar baz\ buzz Personally, I am *really* struggling to understand why we cannot use the = two-slash approach only.=20 Cheers, Adrian -----Original Message----- From: Martin Bjorklund =20 Sent: 04 March 2019 11:49 To: rwilton@cisco.com Cc: adrian@olddog.co.uk; joelja@bogus.com; netmod@ietf.org Subject: Re: [netmod] artwork folding: dual support modes? "Rob Wilton (rwilton)" wrote: > But this behaviour is still different from the frequently used meaning > of =E2=80=98\=E2=80=99 today in programming languages, which as I know = it just splits > lines and preserves whitespace. Right, but we're not doing a programming language, we try to fit long lines in examples into the format required by RFCs, including indentation. For example, suppose you have: Here's an example: foo bar baz \ buzz Unfolded, do you think this is: foo bar baz buzz or foo bar baz buzz > YANG requires a separator character between a keyword and its > argument. What happens if the tool happens to split the line between > the two of them. >=20 >=20 >=20 > E.g >=20 > container\ >=20 > test >=20 >=20 >=20 > After the artwork folding, this would become >=20 > containertest >=20 >=20 >=20 > This could be mitigated by a smarter folding tool (e.g. split before > the =E2=80=98r=E2=80=99 or after the first space). 1. Don't use a tool to add line breaks - remember the goal was to have a readable example. 2. Don't use this alg. for YANG modules, since YANG has builtin / native support for splitting long lines. > Or, what if the tool was being used to fold a table that was using > whitespace to align the columns. This could easily break if > whitespace is stripped. Don't use this alg for tables (or ascii art in general) -- it won't help readers. /martin >=20 >=20 >=20 > Thanks, > Rob >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Martin Bjorklund > Sent: 04 March 2019 08:40 > To: Rob Wilton (rwilton) > Cc: adrian@olddog.co.uk; joelja@bogus.com; netmod@ietf.org > Subject: Re: [netmod] artwork folding: dual support modes? >=20 >=20 >=20 > "Rob Wilton (rwilton)" > > wrote: >=20 > > Hi Adrian, >=20 > > >=20 > > I mostly agree with your last sentence. >=20 > > >=20 > > I think that if you always preserve whitespace then a single slash = is >=20 > > fine. I.e. the single slash just breaks the line, and I think that >=20 > > this matches how editors, programming languages, etc normally = behave. >=20 > > >=20 > > What I=E2=80=99m not keen on is using a single slash, and then = automatically >=20 > > stripping leading whitespace on the line following a slash. >=20 >=20 >=20 > And this is the solution that I prefer. The reason for this is that I > view examples as something that is there to illustrate some point to > the reader, and I think that a prettier formatted example with less > noise helps the reader. I also think that is most cases, this works > well; i.e., most cases are _not_ on the form: >=20 >=20 >=20 > 12345 78990 >=20 > ^-------------- I need a line break here >=20 >=20 >=20 >=20 >=20 > For this problem, I prefer a solution that is intuitive and has less > noise and works for 90% of the cases, than a less intuitive solution > with more noise that works for 100% of the cases. >=20 >=20 >=20 >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > >=20 > > If we want to have control of layout and be able to strip extra >=20 > > whitespace then my argument is that it is better to be explicit, and >=20 > > using two slashes is one way of achieving this. >=20 > > >=20 > > Thanks, >=20 > > Rob >=20 > > >=20 > > >=20 > > >=20 > > From: netmod = > > > On Behalf Of Adrian Farrel >=20 > > Sent: 27 February 2019 09:41 >=20 > > To: 'Joel Jaeggli' > >=20 > > Cc: netmod@ietf.org >=20 > > Subject: Re: [netmod] artwork folding: dual support modes? >=20 > > >=20 > > Complete agreement, Joel. >=20 > > >=20 > > What follows may look better in proportional fonts. >=20 > > >=20 > > With a single slash we can wrap as follows >=20 > > >=20 > > 1234567 9012345 >=20 > > >=20 > > Goes to=E2=80=A6 >=20 > > >=20 > > 1234567 \ >=20 > > 9012345 >=20 > > >=20 > > =E2=80=A6and unwrapping is easy. >=20 > > >=20 > > However, if I want to manually wrap the line with indentation >=20 > > >=20 > > The quick brown fox jumps over the lazy dog >=20 > > >=20 > > ..going to=E2=80=A6 >=20 > > >=20 > > The quick brown fox\ >=20 > > jumps over the lazy dog >=20 > > >=20 > > =E2=80=A6I am going to unfold as=E2=80=A6 >=20 > > >=20 > > The quick brown fox jumps over the lazy dog >=20 > > >=20 > > >=20 > > Conversely, if I resolve this second case by stripping leading = spaces >=20 > > I get=E2=80=A6 >=20 > > >=20 > > The quick brown foxjumps over the lazy dog >=20 > > >=20 > > So I have to fold as=E2=80=A6 >=20 > > >=20 > > The quick brown fox \ >=20 > > jumps over the lazy dog >=20 > > >=20 > > But this causes the first case to unfold as >=20 > > >=20 > > 1234567 9012345 >=20 > > >=20 > > =E2=80=A6i.e., with missing spaces. >=20 > > >=20 > > This is what caused the use of the second slash so=E2=80=A6 >=20 > > >=20 > > 1234567 \ >=20 > > \ 9012345 >=20 > > >=20 > > =E2=80=A6and=E2=80=A6 >=20 > > >=20 > > The quick brown fox\ >=20 > > \ jumps over the lazy dog >=20 > > >=20 > > >=20 > > So, my point is, if and only if we do not care about these = =E2=80=9Cspaces on >=20 > > the fold=E2=80=9D cases, we can operate with a single slash. >=20 > > >=20 > > Cheers, >=20 > > Adrian >=20 > > >=20 > > From: Joel Jaeggli > > = >> >=20 > > Sent: 27 February 2019 06:31 >=20 > > To: Adrian Farrel > > = >> >=20 > > Cc: Kent Watsen > > = >>; >=20 > > = netmod@ietf.org> >=20 > > Subject: Re: [netmod] artwork folding: dual support modes? >=20 > > >=20 > > >=20 > > >=20 > > On Feb 26, 2019, at 14:26, Adrian Farrel >=20 > > = >> > > wrote: >=20 > > >=20 > > Hey. >=20 > > >=20 > > I=E2=80=99ve been having this discussion with Kent off-line, but = thought it >=20 > > should come to the list. >=20 > > >=20 > > I don=E2=80=99t think it is a good idea to have two approaches. = While it would >=20 > > be relatively easy to code for both approaches, it seems to add a >=20 > > degree of confusion if both have to be handled by the same code >=20 > > (consider deciding whether leading space characters are to be = retained >=20 > > or not, something that can only be decided when the first non-space >=20 > > character is found), or by having different code for the two = different >=20 > > cases. >=20 > > >=20 > > It doesn=E2=80=99t seem to me that both cases are needed. We can = pick one or >=20 > > the other. >=20 > > >=20 > > A single slash has been used to wrap long lines in editors and = shells >=20 > > for decades at this point. >=20 > > >=20 > > and yeah whatever it is one method seems better than two. >=20 > > >=20 > > >=20 > > And *if* we want to allow manual folding so that indents can be made >=20 > > to make the document more human-readable then we have to use a = leading >=20 > > =E2=80=98\=E2=80=99 on continuation lines to show which spaces = should be stripped and >=20 > > which retained. >=20 > > >=20 > > Cheers, >=20 > > Adrian >=20 > > >=20 > > From: netmod > > = >> >=20 > > On Behalf Of Kent Watsen >=20 > > Sent: 25 February 2019 22:22 >=20 > > To: > > = netmod@ietf.org> >=20 > > Subject: [netmod] artwork folding: dual support modes? >=20 > > >=20 > > >=20 > > I had a chat with the tools team recently and, in the course of >=20 > > things, it was implied that the double backslash approach we have = now >=20 > > was both surprising and non-intuitive. >=20 > > >=20 > > This got me thinking that we may have thrown the proverbial baby out >=20 > > with the bathwater. >=20 > > That is, currently we have a header that reads: >=20 > > >=20 > > >=20 > > NOTE: '\\' line wrapping per BCP XX (RFC XXXX) >=20 > > >=20 > > So why not *also* support a header that reads (note the singe = slash): >=20 > > >=20 > > >=20 > > NOTE: '\' line wrapping per BCP XX (RFC XXXX) >=20 > > >=20 > > Whereby this second form only supports the folded line continuing on >=20 > > column 1 (no indents). >=20 > > >=20 > > Thoughts? >=20 > > >=20 > > Kent // contributor >=20 > > >=20 > > >=20 > > _______________________________________________ >=20 > > netmod mailing list >=20 > > = netmod@ietf.org> >=20 > > https://www.ietf.org/mailman/listinfo/netmod >=20 > > From nobody Mon Mar 4 04:29:32 2019 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 CCFBD13105F for ; Mon, 4 Mar 2019 04:29:30 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 i5FWn6c7r9xy for ; Mon, 4 Mar 2019 04:29:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC213103B for ; Mon, 4 Mar 2019 04:29:27 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D40A21AE0118; Mon, 4 Mar 2019 13:29:25 +0100 (CET) Date: Mon, 04 Mar 2019 13:29:26 +0100 (CET) Message-Id: <20190304.132926.1893685857666021666.mbj@tail-f.com> To: rwilton@cisco.com Cc: adrian@olddog.co.uk, joelja@bogus.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> References: <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> <20190304.124912.231750494593528236.mbj@tail-f.com> <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 12:29:31 -0000 Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gT24gMDQvMDMv MjAxOSAxMTo0OSwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPiAiUm9iIFdpbHRvbiAocndp bHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+IEJ1dCB0aGlzIGJlaGF2aW91 ciBpcyBzdGlsbCBkaWZmZXJlbnQgZnJvbSB0aGUgZnJlcXVlbnRseSB1c2VkIG1lYW5pbmcNCj4g Pj4gb2Yg4oCYXOKAmSB0b2RheSBpbiBwcm9ncmFtbWluZyBsYW5ndWFnZXMsIHdoaWNoIGFzIEkg a25vdyBpdCBqdXN0IHNwbGl0cw0KPiA+PiBsaW5lcyBhbmQgcHJlc2VydmVzIHdoaXRlc3BhY2Uu DQo+ID4gUmlnaHQsIGJ1dCB3ZSdyZSBub3QgZG9pbmcgYSBwcm9ncmFtbWluZyBsYW5ndWFnZSwg d2UgdHJ5IHRvIGZpdCBsb25nDQo+ID4gbGluZXMgaW4gZXhhbXBsZXMgaW50byB0aGUgZm9ybWF0 IHJlcXVpcmVkIGJ5IFJGQ3MsIGluY2x1ZGluZw0KPiA+IGluZGVudGF0aW9uLg0KPiANCj4gQnV0 IHRoaXMgZG9lcyBnaXZlIGEgZGlmZmVyZW50IG1lYW5pbmcgdG8gYSB3ZWxsIHVzZWQgbm90YXRp b24sIHRoYXQNCj4gbWF5IHdlbGwgY2F1c2Ugc3VycHJpc2UgYW5kIGNvbmZ1c2lvbi4NCj4gDQo+ IA0KPiA+ICAgIEZvciBleGFtcGxlLCBzdXBwb3NlIHlvdSBoYXZlOg0KPiA+DQo+ID4gICAgSGVy ZSdzIGFuIGV4YW1wbGU6DQo+ID4NCj4gPiAgICBmb28gYmFyIGJheiBcDQo+ID4gICAgYnV6eg0K PiA+DQo+ID4gVW5mb2xkZWQsIGRvIHlvdSB0aGluayB0aGlzIGlzOg0KPiA+DQo+ID4gICAgZm9v IGJhciBiYXogYnV6eg0KPiA+DQo+ID4gb3INCj4gPg0KPiA+ICAgIGZvbyBiYXIgYmF6ICAgIGJ1 enoNCj4gDQo+IFRoaXMgb25lLsKgIFRoZSBjb3VudGVyIGV4YW1wbGU6DQoNCkJ1dCBub3RlIHRo YXQgZmlndXJlcyBpbiBSRkNzIGFyZSBub3JtYWxseSBpbmRlbnRlZCB3aXRoIDMgc3BhY2VzDQoo dGhleSBfY2FuXyBiZSBvdXRkZW50ZWQsIGlmIHRoZSBsaW5lcyBhcmUgbG9uZyBlbm91Z2gpLg0K DQo+IA0KPiAgIGZvbyBiYXIgYmF6XA0KPiAgIGJ1enoNCj4gDQo+IERvIHlvdSB0aGluayB0aGF0 IHRoaXMgaXM6DQo+IA0KPiAgIGZvbyBiYXIgYmF6YnV6eg0KDQpUaGlzIG9uZS4NCg0KPiBPcg0K PiANCj4gICBmb28gYmFyIGJheiAgYnV6eg0KPiANCj4gDQo+ID4NCj4gPg0KPiA+PiBZQU5HIHJl cXVpcmVzIGEgc2VwYXJhdG9yIGNoYXJhY3RlciBiZXR3ZWVuIGEga2V5d29yZCBhbmQgaXRzDQo+ ID4+IGFyZ3VtZW50LiAgV2hhdCBoYXBwZW5zIGlmIHRoZSB0b29sIGhhcHBlbnMgdG8gc3BsaXQg dGhlIGxpbmUgYmV0d2Vlbg0KPiA+PiB0aGUgdHdvIG9mIHRoZW0uDQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+IEUuZw0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICBjb250YWluZXJc DQo+ID4+DQo+ID4+ICAgIHRlc3QNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gQWZ0ZXIgdGhlIGFy dHdvcmsgZm9sZGluZywgdGhpcyB3b3VsZCBiZWNvbWUNCj4gPj4NCj4gPj4gICAgICAgICAgICAg ICAgICAgICAgICAgY29udGFpbmVydGVzdA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGlzIGNv dWxkIGJlIG1pdGlnYXRlZCBieSBhIHNtYXJ0ZXIgZm9sZGluZyB0b29sIChlLmcuIHNwbGl0IGJl Zm9yZQ0KPiA+PiB0aGUg4oCYcuKAmSBvciBhZnRlciB0aGUgZmlyc3Qgc3BhY2UpLg0KPiA+DQo+ ID4gMS4gIERvbid0IHVzZSBhIHRvb2wgdG8gYWRkIGxpbmUgYnJlYWtzIC0gcmVtZW1iZXIgdGhl IGdvYWwgd2FzIHRvDQo+ID4gICAgICBoYXZlIGEgcmVhZGFibGUgZXhhbXBsZS4NCj4gDQo+IE5v IGxpbmUgYnJlYWsgaXMgYWRkZWQuwqAgSXQgd2FzIHBlcmZvcm1pbmcgYSBsaW5lIHNwbGl0IG9u ICJjb250YWluZXINCj4gdGVzdCIuDQoNCkkgbWVhbnQsIGRvbid0IHVzZSB0b29scyB0byBkbyBm b2xkaW5nIChvciB1c2UgYSBzbWFydCB0b29sKS4NCg0KPiA+IDIuICBEb24ndCB1c2UgdGhpcyBh bGcuIGZvciBZQU5HIG1vZHVsZXMsIHNpbmNlIFlBTkcgaGFzIGJ1aWx0aW4gLw0KPiA+ICAgICAg bmF0aXZlIHN1cHBvcnQgZm9yIHNwbGl0dGluZyBsb25nIGxpbmVzLg0KPiA+DQo+ID4NCj4gPj4g T3IsIHdoYXQgaWYgdGhlIHRvb2wgd2FzIGJlaW5nIHVzZWQgdG8gZm9sZCBhIHRhYmxlIHRoYXQg d2FzIHVzaW5nDQo+ID4+IHdoaXRlc3BhY2UgdG8gYWxpZ24gdGhlIGNvbHVtbnMuICBUaGlzIGNv dWxkIGVhc2lseSBicmVhayBpZg0KPiA+PiB3aGl0ZXNwYWNlIGlzIHN0cmlwcGVkLg0KPiA+IERv bid0IHVzZSB0aGlzIGFsZyBmb3IgdGFibGVzIChvciBhc2NpaSBhcnQgaW4gZ2VuZXJhbCkgLS0g aXQgd29uJ3QNCj4gPiBoZWxwIHJlYWRlcnMuDQo+IA0KPiBUaGUgY2hvaWNlIG9mIHNvbHV0aW9u IHNlZW1zIHRvIG1ha2UgaXQgcXVpdGUgcmVzdHJpY3RlZCB3aGVyZSBpdCBjYW4NCj4gYmUgdmFs aWRseSB1c2VkLsKgIEkuZS4gaXQgaXMgb25seSBzYWZlIHRvIHVzZSB0byBmb2xkIGRvY3VtZW50 cyB3aGVyZQ0KPiB3aGl0ZXNwYWNlIGhhcyBubyBzaWduaWZpY2FuY2UsIGFuZCBjYW4gYmUgYXJi aXRyYXJpbHkgcmVtb3ZlZCBmcm9tDQo+IHRoZSBmb2xkZWQgb2JqZWN0IHdpdGhvdXQgY2hhbmdp bmcgdGhlIGRvY3VtZW50J3MgbWVhbmluZy4NCj4gDQo+IEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxk IG1lYW4gdGhhdCB0aGUgZm9sZGluZyBtZWNoYW5pc20gaXNuJ3Qgc2FmZSBvbg0KPiBlaXRoZXIg WE1MIG9yIEpTT04gZG9jdW1lbnRzIChzaW5jZSB3aGl0ZXNwYWNlIGlzIHNpZ25pZmljYW50LA0K PiBlLmcuIHdpdGhpbiBhIHN0cmluZykuDQoNCkZvciB0aGUgdXNlIGNhc2UgdGhhdCBJIGVudmlz aW9uLCBpLmUuLCBtYW51YWxseSBhZGRlZCBcJ3MsIEkgZG9uJ3QNCnRoaW5rIHRoaXMgaXMgYW4g aXNzdWUuICBJdCBtaWdodCBiZSB0aGF0IHdlJ3JlIHRyeWluZyB0byBzb2x2ZQ0KZGlmZmVyZW50 IHByb2JsZW1zIC0gSSB3b3VsZCBsaWtlIGEgc29sdXRpb24gdGhhdCBpcyBpbnR1aXRpdmUgZm9y IHRoZQ0KcmVhZGVyIGFuZCBoYXMgYSBtaW5pbWFsIGFtb3VudCBvZiBub2lzZSwgYnV0IEkgdGhp bmsgdGhhdCBzb21lIG90aGVycw0KdGhpbmsgaXQgaXMgbW9yZSBpbXBvcnRhbnQgdGhhdCB0b29s cyBjYW4gYmUgdXNlZCB0byBhdXRvbWF0ZSB0aGUNCmZvbGRpbmcgcHJvY2Vzcy4NCg0KPiBUaGVy ZSBzZWVtcyB0byBiZSBhIGV2ZXIgZ3Jvd2luZyBsaXN0IG9mIHRoaW5ncyB0aGF0IHdlIGNhbid0 IHNhZmVseQ0KPiB1c2UgdGhpcyBmb3JtIG9mIGFydHdvcmsgZm9sZGluZyBvbi7CoCBBcmUgdGhl cmUgYXJlIGFueSBleGFtcGxlcyBvZg0KPiBzdHVmZiB0aGF0IHdlIGNhbiBzYWZlbHkgdXNlIGl0 IG9uPyA7LSkNCg0KDQpKdXN0IHRvIGJlIGNsZWFyOiBteSBwcmVmZXJlbmNlIGlzIGZvciBhIHNp bmdsZSBcIGFzIGRlc2NyaWJlZCBhYm92ZSwNCmJ1dCBJIGFtIG9rIHdpdGggdGhlIHNvbHV0aW9u IGluIHRoZSBjdXJyZW50IGRyYWZ0IChhbiBhZGRpdGlvbmFsIFwgb24NCnRoZSBuZXh0IGxpbmUp Lg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KDQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiANCj4gDQo+ ID4NCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4+DQo+ID4+ DQo+ID4+IFRoYW5rcywNCj4gPj4gUm9iDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IE1hcnRpbiBCam9ya2x1 bmQgPG1iakB0YWlsLWYuY29tPg0KPiA+PiBTZW50OiAwNCBNYXJjaCAyMDE5IDA4OjQwDQo+ID4+ IFRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4+IENjOiBh ZHJpYW5Ab2xkZG9nLmNvLnVrOyBqb2VsamFAYm9ndXMuY29tOyBuZXRtb2RAaWV0Zi5vcmcNCj4g Pj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0IG1v ZGVzPw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAiUm9iIFdpbHRvbiAocndpbHRvbikiIDxyd2ls dG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+Pg0KPiA+PiB3cm90ZToNCj4g Pj4NCj4gPj4+IEhpIEFkcmlhbiwNCj4gPj4+IEkgbW9zdGx5IGFncmVlIHdpdGggeW91ciBsYXN0 IHNlbnRlbmNlLg0KPiA+Pj4gSSB0aGluayB0aGF0IGlmIHlvdSBhbHdheXMgcHJlc2VydmUgd2hp dGVzcGFjZSB0aGVuIGEgc2luZ2xlIHNsYXNoIGlzDQo+ID4+PiBmaW5lLiAgSS5lLiB0aGUgc2lu Z2xlIHNsYXNoIGp1c3QgYnJlYWtzIHRoZSBsaW5lLCBhbmQgSSB0aGluayB0aGF0DQo+ID4+PiB0 aGlzIG1hdGNoZXMgaG93IGVkaXRvcnMsIHByb2dyYW1taW5nIGxhbmd1YWdlcywgZXRjIG5vcm1h bGx5IGJlaGF2ZS4NCj4gPj4+IFdoYXQgSeKAmW0gbm90IGtlZW4gb24gaXMgdXNpbmcgYSBzaW5n bGUgc2xhc2gsIGFuZCB0aGVuIGF1dG9tYXRpY2FsbHkNCj4gPj4+IHN0cmlwcGluZyBsZWFkaW5n IHdoaXRlc3BhY2Ugb24gdGhlIGxpbmUgZm9sbG93aW5nIGEgc2xhc2guDQo+ID4+DQo+ID4+DQo+ ID4+IEFuZCB0aGlzIGlzIHRoZSBzb2x1dGlvbiB0aGF0IEkgcHJlZmVyLiAgVGhlIHJlYXNvbiBm b3IgdGhpcyBpcyB0aGF0IEkNCj4gPj4gdmlldyBleGFtcGxlcyBhcyBzb21ldGhpbmcgdGhhdCBp cyB0aGVyZSB0byBpbGx1c3RyYXRlIHNvbWUgcG9pbnQgdG8NCj4gPj4gdGhlIHJlYWRlciwgYW5k IEkgdGhpbmsgdGhhdCBhIHByZXR0aWVyIGZvcm1hdHRlZCBleGFtcGxlIHdpdGggbGVzcw0KPiA+ PiBub2lzZSBoZWxwcyB0aGUgcmVhZGVyLiAgSSBhbHNvIHRoaW5rIHRoYXQgaXMgbW9zdCBjYXNl cywgdGhpcyB3b3Jrcw0KPiA+PiB3ZWxsOyBpLmUuLCBtb3N0IGNhc2VzIGFyZSBfbm90XyBvbiB0 aGUgZm9ybToNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgIDEyMzQ1ICAgICAgNzg5OTANCj4g Pj4NCj4gPj4gICAgICAgICAgICBeLS0tLS0tLS0tLS0tLS0gSSBuZWVkIGEgbGluZSBicmVhayBo ZXJlDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEZvciB0aGlzIHByb2JsZW0s IEkgcHJlZmVyIGEgc29sdXRpb24gdGhhdCBpcyBpbnR1aXRpdmUgYW5kIGhhcyBsZXNzDQo+ID4+ IG5vaXNlIGFuZCB3b3JrcyBmb3IgOTAlIG9mIHRoZSBjYXNlcywgdGhhbiBhIGxlc3MgaW50dWl0 aXZlIHNvbHV0aW9uDQo+ID4+IHdpdGggbW9yZSBub2lzZSB0aGF0IHdvcmtzIGZvciAxMDAlIG9m IHRoZSBjYXNlcy4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gL21hcnRpbg0K PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gSWYgd2Ugd2Fu dCB0byBoYXZlIGNvbnRyb2wgb2YgbGF5b3V0IGFuZCBiZSBhYmxlIHRvIHN0cmlwIGV4dHJhDQo+ ID4+PiB3aGl0ZXNwYWNlIHRoZW4gbXkgYXJndW1lbnQgaXMgdGhhdCBpdCBpcyBiZXR0ZXIgdG8g YmUgZXhwbGljaXQsIGFuZA0KPiA+Pj4gdXNpbmcgdHdvIHNsYXNoZXMgaXMgb25lIHdheSBvZiBh Y2hpZXZpbmcgdGhpcy4NCj4gPj4+IFRoYW5rcywNCj4gPj4+IFJvYg0KPiA+Pj4gRnJvbTogbmV0 bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmc+Pg0KPiA+Pj4gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4gPj4+IFNlbnQ6IDI3IEZl YnJ1YXJ5IDIwMTkgMDk6NDENCj4gPj4+IFRvOiAnSm9lbCBKYWVnZ2xpJyA8am9lbGphQGJvZ3Vz LmNvbTxtYWlsdG86am9lbGphQGJvZ3VzLmNvbT4+DQo+ID4+PiBDYzogbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gYXJ0 d29yayBmb2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQo+ID4+PiBDb21wbGV0ZSBhZ3JlZW1l bnQsIEpvZWwuDQo+ID4+PiBXaGF0IGZvbGxvd3MgbWF5IGxvb2sgYmV0dGVyIGluIHByb3BvcnRp b25hbCBmb250cy4NCj4gPj4+IFdpdGggYSBzaW5nbGUgc2xhc2ggd2UgY2FuIHdyYXAgYXMgZm9s bG93cw0KPiA+Pj4gMTIzNDU2NyAgICAgICAgOTAxMjM0NQ0KPiA+Pj4gR29lcyB0b+KApg0KPiA+ Pj4gMTIzNDU2NyAgICBcDQo+ID4+PiAgICAgIDkwMTIzNDUNCj4gPj4+IOKApmFuZCB1bndyYXBw aW5nIGlzIGVhc3kuDQo+ID4+PiBIb3dldmVyLCBpZiBJIHdhbnQgdG8gbWFudWFsbHkgd3JhcCB0 aGUgbGluZSB3aXRoIGluZGVudGF0aW9uDQo+ID4+PiBUaGUgcXVpY2sgYnJvd24gZm94IGp1bXBz IG92ZXIgdGhlIGxhenkgZG9nDQo+ID4+PiAuLmdvaW5nIHRv4oCmDQo+ID4+PiBUaGUgcXVpY2sg YnJvd24gZm94XA0KPiA+Pj4gICAgICAgIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+ID4+PiDi gKZJIGFtIGdvaW5nIHRvIHVuZm9sZCBhc+KApg0KPiA+Pj4gVGhlIHF1aWNrIGJyb3duIGZveCAg ICAgIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+ID4+PiBDb252ZXJzZWx5LCBpZiBJIHJlc29s dmUgdGhpcyBzZWNvbmQgY2FzZSBieSBzdHJpcHBpbmcgbGVhZGluZyBzcGFjZXMNCj4gPj4+IEkg Z2V04oCmDQo+ID4+PiBUaGUgcXVpY2sgYnJvd24gZm94anVtcHMgb3ZlciB0aGUgbGF6eSBkb2cN Cj4gPj4+IFNvIEkgaGF2ZSB0byBmb2xkIGFz4oCmDQo+ID4+PiBUaGUgcXVpY2sgYnJvd24gZm94 IFwNCj4gPj4+ICAgICAgICBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KPiA+Pj4gQnV0IHRoaXMg Y2F1c2VzIHRoZSBmaXJzdCBjYXNlIHRvIHVuZm9sZCBhcw0KPiA+Pj4gMTIzNDU2NyAgICA5MDEy MzQ1DQo+ID4+PiDigKZpLmUuLCB3aXRoIG1pc3Npbmcgc3BhY2VzLg0KPiA+Pj4gVGhpcyBpcyB3 aGF0IGNhdXNlZCB0aGUgdXNlIG9mIHRoZSBzZWNvbmQgc2xhc2ggc2/igKYNCj4gPj4+IDEyMzQ1 NjcgICAgXA0KPiA+Pj4gXCAgICA5MDEyMzQ1DQo+ID4+PiDigKZhbmTigKYNCj4gPj4+IFRoZSBx dWljayBicm93biBmb3hcDQo+ID4+PiAgICAgICBcIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+ ID4+PiBTbywgbXkgcG9pbnQgaXMsIGlmIGFuZCBvbmx5IGlmIHdlIGRvIG5vdCBjYXJlIGFib3V0 IHRoZXNlIOKAnHNwYWNlcyBvbg0KPiA+Pj4gdGhlIGZvbGTigJ0gY2FzZXMsIHdlIGNhbiBvcGVy YXRlIHdpdGggYSBzaW5nbGUgc2xhc2guDQo+ID4+PiBDaGVlcnMsDQo+ID4+PiBBZHJpYW4NCj4g Pj4+IEZyb206IEpvZWwgSmFlZ2dsaQ0KPiA+Pj4gPGpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpv ZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1cy5jb20lM2NtYWlsdG86am9lbGphQGJv Z3VzLmNvbT4+Pg0KPiA+Pj4gU2VudDogMjcgRmVicnVhcnkgMjAxOSAwNjozMQ0KPiA+Pj4gVG86 IEFkcmlhbiBGYXJyZWwNCj4gPj4+IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrJTNjbWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+Pj4NCj4gPj4+IENjOiBLZW50IFdhdHNlbg0KPiA+Pj4gPGtlbnQraWV0ZkB3 YXRzZW4ubmV0PG1haWx0bzprZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCtpZXRmQHdh dHNlbi5uZXQlM2NtYWlsdG86a2VudCtpZXRmQHdhdHNlbi5uZXQ+Pj47DQo+ID4+PiBuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnJTNj bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQo+ID4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gYXJ0 d29yayBmb2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQo+ID4+PiBPbiBGZWIgMjYsIDIwMTks IGF0IDE0OjI2LCBBZHJpYW4gRmFycmVsDQo+ID4+PiA8YWRyaWFuQG9sZGRvZy5jby51azxtYWls dG86YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayUzY21haWx0 bzphZHJpYW5Ab2xkZG9nLmNvLnVrPj4+DQo+ID4+PiB3cm90ZToNCj4gPj4+IEhleS4NCj4gPj4+ IEnigJl2ZSBiZWVuIGhhdmluZyB0aGlzIGRpc2N1c3Npb24gd2l0aCBLZW50IG9mZi1saW5lLCBi dXQgdGhvdWdodCBpdA0KPiA+Pj4gc2hvdWxkIGNvbWUgdG8gdGhlIGxpc3QuDQo+ID4+PiBJIGRv buKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSB0d28gYXBwcm9hY2hlcy4gV2hp bGUgaXQgd291bGQNCj4gPj4+IGJlIHJlbGF0aXZlbHkgZWFzeSB0byBjb2RlIGZvciBib3RoIGFw cHJvYWNoZXMsIGl0IHNlZW1zIHRvIGFkZCBhDQo+ID4+PiBkZWdyZWUgb2YgY29uZnVzaW9uIGlm IGJvdGggaGF2ZSB0byBiZSBoYW5kbGVkIGJ5IHRoZSBzYW1lIGNvZGUNCj4gPj4+IChjb25zaWRl ciBkZWNpZGluZyB3aGV0aGVyIGxlYWRpbmcgc3BhY2UgY2hhcmFjdGVycyBhcmUgdG8gYmUgcmV0 YWluZWQNCj4gPj4+IG9yIG5vdCwgc29tZXRoaW5nIHRoYXQgY2FuIG9ubHkgYmUgZGVjaWRlZCB3 aGVuIHRoZSBmaXJzdCBub24tc3BhY2UNCj4gPj4+IGNoYXJhY3RlciBpcyBmb3VuZCksIG9yIGJ5 IGhhdmluZyBkaWZmZXJlbnQgY29kZSBmb3IgdGhlIHR3byBkaWZmZXJlbnQNCj4gPj4+IGNhc2Vz Lg0KPiA+Pj4gSXQgZG9lc27igJl0IHNlZW0gdG8gbWUgdGhhdCBib3RoIGNhc2VzIGFyZSBuZWVk ZWQuIFdlIGNhbiBwaWNrIG9uZSBvcg0KPiA+Pj4gdGhlIG90aGVyLg0KPiA+Pj4gQSBzaW5nbGUg c2xhc2ggaGFzIGJlZW4gdXNlZCB0byB3cmFwIGxvbmcgbGluZXMgaW4gZWRpdG9ycyBhbmQgc2hl bGxzDQo+ID4+PiBmb3IgZGVjYWRlcyBhdCB0aGlzIHBvaW50Lg0KPiA+Pj4gYW5kIHllYWggd2hh dGV2ZXIgaXQgaXMgb25lIG1ldGhvZCBzZWVtcyBiZXR0ZXIgdGhhbiB0d28uDQo+ID4+PiBBbmQg KmlmKiB3ZSB3YW50IHRvIGFsbG93IG1hbnVhbCBmb2xkaW5nIHNvIHRoYXQgaW5kZW50cyBjYW4g YmUgbWFkZQ0KPiA+Pj4gdG8gbWFrZSB0aGUgZG9jdW1lbnQgbW9yZSBodW1hbi1yZWFkYWJsZSB0 aGVuIHdlIGhhdmUgdG8gdXNlIGEgbGVhZGluZw0KPiA+Pj4g4oCYXOKAmSBvbiBjb250aW51YXRp b24gbGluZXMgdG8gc2hvdyB3aGljaCBzcGFjZXMgc2hvdWxkIGJlIHN0cmlwcGVkIGFuZA0KPiA+ Pj4gd2hpY2ggcmV0YWluZWQuDQo+ID4+PiBDaGVlcnMsDQo+ID4+PiBBZHJpYW4NCj4gPj4+IEZy b206IG5ldG1vZA0KPiA+Pj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmclM2NtYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+Pj4NCj4gPj4+IE9uIEJlaGFsZiBPZiBLZW50IFdhdHNl bg0KPiA+Pj4gU2VudDogMjUgRmVicnVhcnkgMjAxOSAyMjoyMg0KPiA+Pj4gVG86DQo+ID4+PiBu ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnJTNjbWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQo+ID4+PiBTdWJqZWN0OiBbbmV0bW9kXSBh cnR3b3JrIGZvbGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCj4gPj4+IEkgaGFkIGEgY2hhdCB3 aXRoIHRoZSB0b29scyB0ZWFtIHJlY2VudGx5IGFuZCwgaW4gdGhlIGNvdXJzZSBvZg0KPiA+Pj4g dGhpbmdzLCBpdCB3YXMgaW1wbGllZCB0aGF0IHRoZSBkb3VibGUgYmFja3NsYXNoIGFwcHJvYWNo IHdlIGhhdmUgbm93DQo+ID4+PiB3YXMgYm90aCBzdXJwcmlzaW5nIGFuZCBub24taW50dWl0aXZl Lg0KPiA+Pj4gVGhpcyBnb3QgbWUgdGhpbmtpbmcgdGhhdCB3ZSBtYXkgaGF2ZSB0aHJvd24gdGhl IHByb3ZlcmJpYWwgYmFieSBvdXQNCj4gPj4+IHdpdGggdGhlIGJhdGh3YXRlci4NCj4gPj4+IFRo YXQgaXMsIGN1cnJlbnRseSB3ZSBoYXZlIGEgaGVhZGVyIHRoYXQgcmVhZHM6DQo+ID4+PiAgICBO T1RFOiAnXFwnIGxpbmUgd3JhcHBpbmcgcGVyIEJDUCBYWCAoUkZDIFhYWFgpDQo+ID4+PiBTbyB3 aHkgbm90ICphbHNvKiBzdXBwb3J0IGEgaGVhZGVyIHRoYXQgcmVhZHMgKG5vdGUgdGhlIHNpbmdl IHNsYXNoKToNCj4gPj4+ICAgIE5PVEU6ICdcJyBsaW5lIHdyYXBwaW5nIHBlciBCQ1AgWFggKFJG QyBYWFhYKQ0KPiA+Pj4gV2hlcmVieSB0aGlzIHNlY29uZCBmb3JtIG9ubHkgc3VwcG9ydHMgdGhl IGZvbGRlZCBsaW5lIGNvbnRpbnVpbmcgb24NCj4gPj4+IGNvbHVtbiAxIChubyBpbmRlbnRzKS4N Cj4gPj4+IFRob3VnaHRzPw0KPiA+Pj4gS2VudCAvLyBjb250cmlidXRvcg0KPiA+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gPj4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmclM2NtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0K From nobody Mon Mar 4 05:16:40 2019 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 80BAC131130 for ; Mon, 4 Mar 2019 05:16:37 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 KYiOWFa3YuYo for ; Mon, 4 Mar 2019 05:16:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29E05130E6C for ; Mon, 4 Mar 2019 05:16:33 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A4081AE0118; Mon, 4 Mar 2019 14:16:30 +0100 (CET) Date: Mon, 04 Mar 2019 14:16:30 +0100 (CET) Message-Id: <20190304.141630.1246282625623673890.mbj@tail-f.com> To: adrian@olddog.co.uk Cc: rwilton@cisco.com, joelja@bogus.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <0a8601d4d283$f13b2180$d3b16480$@olddog.co.uk> References: <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> <20190304.124912.231750494593528236.mbj@tail-f.com> <0a8601d4d283$f13b2180$d3b16480$@olddog.co.uk> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 13:16:38 -0000 IkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3cm90ZToNCj4gV2UgY2FuIGdv IHJvdW5kIGFuZCByb3VuZCDwn5iKDQo+IA0KPiBIb3cgZG8gSSBmb2xkDQo+ICAgZm9vIGJhciBi YXogICAgICAgICBidXp6DQo+IHNvIHRoYXQgaXQgY2FuIGJlIHVuZm9sZGVkPw0KPiANCj4gQ2xl YXJseSBhIHBvc3NpYmlsaXR5IGlzDQo+ICAgZm9vIGJhciBiYXogICAgICAgICBcDQo+ICAgYnV6 eg0KPiANCj4gQnV0IHdoYXQgaWYgdGhlIGxpbmUgbGVuZ3RoIHdvdWxkIGJyZWFrIGluIHRoZSB3 aGl0ZSBzcGFjZT8NCj4gWW91IGNvdWxkIHNvbHZlIGl0IGFzIA0KPiAgIGZvbyBiYXIgXA0KPiAg IGJheiAgICAgICAgIGJ1enoNCj4gd2hpY2ggcmVxdWlyZXMgc2xpZ2h0bHkgbW9yZSBjb21wbGV4 IGZvbGRpbmcuDQo+IA0KPiBBY3R1YWxseSwgdGhpcyBjYXNlIGFyaXNlcyBtb3JlIG9mdGVuIHRo YW4geW91IG1pZ2h0IHRoaW5rIHdoZW4gdGhlDQo+IGxpbmUgbGVuZ3RoIHdvdWxkIGNhdXNlIGEg Zm9sZCBiZWZvcmUgYSBzaW5nbGUgc3BhY2UuDQo+IFRodXMsIGlmIHRoZSBsaW5lIGxlbmd0aCBp cyAxMQ0KPiBmb28gYmFyIGJheiBidXp6DQo+IC4ud291bGQgZm9sZCBhcy4uLg0KPiBmb28gYmFy IGJhelwNCj4gIGJ1enoNCj4gLi4uYW5kIHVuZm9sZCBhcy4uLg0KPiBmb28gYmFyIGJhemJ1enoN Cj4gLi4uaWYgbGVhZGluZyBzcGFjZXMgYXJlIHN0cmlwcGVkLg0KPiANCj4gQW5kIGlmIGxlYWRp bmcgc3BhY2VzIGFyZSBub3Qgc3RyaXBwZWQgdGhlbiB3ZSBjYW5ub3QgaGFuZGxlIG1hbnVhbA0K PiBwYWRkaW5nIGZvciByZWFzb25zIG9mIHZpc3VhbCBmb3JtYXR0aW5nLiBGb3IgZXhhbXBsZS4u Lg0KPiBmb28gYmFyIGJhelwNCj4gICAgICAgIGJ1enoNCj4gDQo+IFBlcnNvbmFsbHksIEkgYW0g KnJlYWxseSogc3RydWdnbGluZyB0byB1bmRlcnN0YW5kIHdoeSB3ZSBjYW5ub3QgdXNlDQo+IHRo ZSB0d28tc2xhc2ggYXBwcm9hY2ggb25seS4NCg0KTWF5YmUgYi9jIGlmIHdlIGRvLCBwZW9wbGUg d2lsbCBzdGFydCB0byB1c2UgaXQgYW5kIHdyaXRlIHRoaW5ncw0KbGlrZToNCg0KICAgICAgICAg ICAibG9jYXRpb24iOiAiZmlsZTovL2V4YW1wbGUub3JnL3lhbmcvcGFja2FnZXMvaWV0Zi1yb3V0 aW5nQHZcDQogICBcMS4zLjEuanNvbiIsDQogICAgICAgICAgICJkZXNjcmlwdGlvbiI6ICJUaGlz IHBhY2thZ2UgZGVmaW5lcyBhIHNtYWxsIHNhbXBsZSBzZXQgb2YgSVwNCiAgIFxFVEYgcm91dGlu ZyBZQU5HIG1vZHVsZXMgdGhhdCBjb3VsZCByZXByZXNlbnQgdGhlIHNldCBvZiBJRVRGIHJvdXRp XA0KICAgXG5nIGZ1bmN0aW9uYWxpdHkgdGhhdCBhIGJhc2ljIElQIG5ldHdvcmsgZGV2aWNlIG1p Z2h0IGJlIGV4cGVjdGVkIHRcDQogICBcbyBzdXBwb3J0LiIsDQoNCg0KSSBrbm93LCBpdCBjYW4g ZWFzaWx5IGJlIHJlLXdyaXR0ZW4gaW50bzoNCg0KICAgICAgICAgICAibG9jYXRpb24iOiAiZmls ZTovL2V4YW1wbGUub3JnL3lhbmcvcGFja2FnZXNcDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFwvaWV0Zi1yb3V0aW5nQHYxLjMuMS5qc29uIiwNCiAgICAgICAgICAgImRlc2NyaXB0aW9u IjogIlRoaXMgcGFja2FnZSBkZWZpbmVzIGEgc21hbGwgc2FtcGxlIHNldCBcDQogICAgICAgICAg ICAgICAgICAgICAgICAgIFxvZiBJRVRGIHJvdXRpbmcgWUFORyBtb2R1bGVzIHRoYXQgY291bGQg XA0KICAgICAgICAgICAgICAgICAgICAgICAgICBccmVwcmVzZW50IHRoZSBzZXQgb2YgSUVURiBy b3V0aW5nIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgXGZ1bmN0aW9uYWxpdHkgdGhhdCBh IGJhc2ljIElQIG5ldHdvcmsgXA0KICAgICAgICAgICAgICAgICAgICAgICAgICBcZGV2aWNlIG1p Z2h0IGJlIGV4cGVjdGVkIHRvIHN1cHBvcnQuIiwNCg0Kd2hpY2ggaXMgYWxtb3N0IGFzIHJlYWRh YmxlIGFzOg0KDQogICAgICAgICAgICJsb2NhdGlvbiI6ICJmaWxlOi8vZXhhbXBsZS5vcmcveWFu Zy9wYWNrYWdlc1wNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC9pZXRmLXJvdXRpbmdA djEuMy4xLmpzb24iLA0KICAgICAgICAgICAiZGVzY3JpcHRpb24iOiAiVGhpcyBwYWNrYWdlIGRl ZmluZXMgYSBzbWFsbCBzYW1wbGUgc2V0IFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIG9m IElFVEYgcm91dGluZyBZQU5HIG1vZHVsZXMgdGhhdCBjb3VsZCBcDQogICAgICAgICAgICAgICAg ICAgICAgICAgICByZXByZXNlbnQgdGhlIHNldCBvZiBJRVRGIHJvdXRpbmcgXA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgZnVuY3Rpb25hbGl0eSB0aGF0IGEgYmFzaWMgSVAgbmV0d29yayBc DQogICAgICAgICAgICAgICAgICAgICAgICAgICBkZXZpY2UgbWlnaHQgYmUgZXhwZWN0ZWQgdG8g c3VwcG9ydC4iLA0KDQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiBDaGVlcnMsDQo+IEFkcmlhbg0KPiAN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBCam9ya2x1 bmQgPG1iakB0YWlsLWYuY29tPiANCj4gU2VudDogMDQgTWFyY2ggMjAxOSAxMTo0OQ0KPiBUbzog cndpbHRvbkBjaXNjby5jb20NCj4gQ2M6IGFkcmlhbkBvbGRkb2cuY28udWs7IGpvZWxqYUBib2d1 cy5jb207IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gYXJ0d29yayBm b2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQo+IA0KPiAiUm9iIFdpbHRvbiAocndpbHRvbiki IDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gQnV0IHRoaXMgYmVoYXZpb3VyIGlzIHN0 aWxsIGRpZmZlcmVudCBmcm9tIHRoZSBmcmVxdWVudGx5IHVzZWQgbWVhbmluZw0KPiA+IG9mIOKA mFzigJkgdG9kYXkgaW4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLCB3aGljaCBhcyBJIGtub3cgaXQg anVzdCBzcGxpdHMNCj4gPiBsaW5lcyBhbmQgcHJlc2VydmVzIHdoaXRlc3BhY2UuDQo+IA0KPiBS aWdodCwgYnV0IHdlJ3JlIG5vdCBkb2luZyBhIHByb2dyYW1taW5nIGxhbmd1YWdlLCB3ZSB0cnkg dG8gZml0IGxvbmcNCj4gbGluZXMgaW4gZXhhbXBsZXMgaW50byB0aGUgZm9ybWF0IHJlcXVpcmVk IGJ5IFJGQ3MsIGluY2x1ZGluZw0KPiBpbmRlbnRhdGlvbi4gIEZvciBleGFtcGxlLCBzdXBwb3Nl IHlvdSBoYXZlOg0KPiANCj4gICBIZXJlJ3MgYW4gZXhhbXBsZToNCj4gDQo+ICAgZm9vIGJhciBi YXogXA0KPiAgIGJ1enoNCj4gDQo+IFVuZm9sZGVkLCBkbyB5b3UgdGhpbmsgdGhpcyBpczoNCj4g DQo+ICAgZm9vIGJhciBiYXogYnV6eg0KPiANCj4gb3INCj4gDQo+ICAgZm9vIGJhciBiYXogICAg YnV6eg0KPiANCj4gDQo+ID4gWUFORyByZXF1aXJlcyBhIHNlcGFyYXRvciBjaGFyYWN0ZXIgYmV0 d2VlbiBhIGtleXdvcmQgYW5kIGl0cw0KPiA+IGFyZ3VtZW50LiAgV2hhdCBoYXBwZW5zIGlmIHRo ZSB0b29sIGhhcHBlbnMgdG8gc3BsaXQgdGhlIGxpbmUgYmV0d2Vlbg0KPiA+IHRoZSB0d28gb2Yg dGhlbS4NCj4gPiANCj4gPiANCj4gPiANCj4gPiBFLmcNCj4gPiANCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgIGNvbnRhaW5lclwNCj4gPiANCj4gPiAgIHRlc3QNCj4gPiANCj4gPiANCj4gPiAN Cj4gPiBBZnRlciB0aGUgYXJ0d29yayBmb2xkaW5nLCB0aGlzIHdvdWxkIGJlY29tZQ0KPiA+IA0K PiA+ICAgICAgICAgICAgICAgICAgICAgICAgY29udGFpbmVydGVzdA0KPiA+IA0KPiA+IA0KPiA+ IA0KPiA+IFRoaXMgY291bGQgYmUgbWl0aWdhdGVkIGJ5IGEgc21hcnRlciBmb2xkaW5nIHRvb2wg KGUuZy4gc3BsaXQgYmVmb3JlDQo+ID4gdGhlIOKAmHLigJkgb3IgYWZ0ZXIgdGhlIGZpcnN0IHNw YWNlKS4NCj4gDQo+IA0KPiAxLiAgRG9uJ3QgdXNlIGEgdG9vbCB0byBhZGQgbGluZSBicmVha3Mg LSByZW1lbWJlciB0aGUgZ29hbCB3YXMgdG8NCj4gICAgIGhhdmUgYSByZWFkYWJsZSBleGFtcGxl Lg0KPiANCj4gMi4gIERvbid0IHVzZSB0aGlzIGFsZy4gZm9yIFlBTkcgbW9kdWxlcywgc2luY2Ug WUFORyBoYXMgYnVpbHRpbiAvDQo+ICAgICBuYXRpdmUgc3VwcG9ydCBmb3Igc3BsaXR0aW5nIGxv bmcgbGluZXMuDQo+IA0KPiANCj4gPiBPciwgd2hhdCBpZiB0aGUgdG9vbCB3YXMgYmVpbmcgdXNl ZCB0byBmb2xkIGEgdGFibGUgdGhhdCB3YXMgdXNpbmcNCj4gPiB3aGl0ZXNwYWNlIHRvIGFsaWdu IHRoZSBjb2x1bW5zLiAgVGhpcyBjb3VsZCBlYXNpbHkgYnJlYWsgaWYNCj4gPiB3aGl0ZXNwYWNl IGlzIHN0cmlwcGVkLg0KPiANCj4gRG9uJ3QgdXNlIHRoaXMgYWxnIGZvciB0YWJsZXMgKG9yIGFz Y2lpIGFydCBpbiBnZW5lcmFsKSAtLSBpdCB3b24ndA0KPiBoZWxwIHJlYWRlcnMuDQo+IA0KPiAN Cj4gL21hcnRpbg0KPiANCj4gDQo+IA0KPiANCj4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gVGhh bmtzLA0KPiA+IFJvYg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt Zi5jb20+DQo+ID4gU2VudDogMDQgTWFyY2ggMjAxOSAwODo0MA0KPiA+IFRvOiBSb2IgV2lsdG9u IChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4gQ2M6IGFkcmlhbkBvbGRkb2cuY28u dWs7IGpvZWxqYUBib2d1cy5jb207IG5ldG1vZEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBb bmV0bW9kXSBhcnR3b3JrIGZvbGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCj4gPiANCj4gPiAN Cj4gPiANCj4gPiAiUm9iIFdpbHRvbiAocndpbHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWls dG86cndpbHRvbkBjaXNjby5jb20+Pg0KPiA+IHdyb3RlOg0KPiA+IA0KPiA+ID4gSGkgQWRyaWFu LA0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IEkgbW9zdGx5IGFncmVlIHdpdGggeW91ciBsYXN0 IHNlbnRlbmNlLg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IEkgdGhpbmsgdGhhdCBpZiB5b3Ug YWx3YXlzIHByZXNlcnZlIHdoaXRlc3BhY2UgdGhlbiBhIHNpbmdsZSBzbGFzaCBpcw0KPiA+IA0K PiA+ID4gZmluZS4gIEkuZS4gdGhlIHNpbmdsZSBzbGFzaCBqdXN0IGJyZWFrcyB0aGUgbGluZSwg YW5kIEkgdGhpbmsgdGhhdA0KPiA+IA0KPiA+ID4gdGhpcyBtYXRjaGVzIGhvdyBlZGl0b3JzLCBw cm9ncmFtbWluZyBsYW5ndWFnZXMsIGV0YyBub3JtYWxseSBiZWhhdmUuDQo+ID4gDQo+ID4gPg0K PiA+IA0KPiA+ID4gV2hhdCBJ4oCZbSBub3Qga2VlbiBvbiBpcyB1c2luZyBhIHNpbmdsZSBzbGFz aCwgYW5kIHRoZW4gYXV0b21hdGljYWxseQ0KPiA+IA0KPiA+ID4gc3RyaXBwaW5nIGxlYWRpbmcg d2hpdGVzcGFjZSBvbiB0aGUgbGluZSBmb2xsb3dpbmcgYSBzbGFzaC4NCj4gPiANCj4gPiANCj4g PiANCj4gPiBBbmQgdGhpcyBpcyB0aGUgc29sdXRpb24gdGhhdCBJIHByZWZlci4gIFRoZSByZWFz b24gZm9yIHRoaXMgaXMgdGhhdCBJDQo+ID4gdmlldyBleGFtcGxlcyBhcyBzb21ldGhpbmcgdGhh dCBpcyB0aGVyZSB0byBpbGx1c3RyYXRlIHNvbWUgcG9pbnQgdG8NCj4gPiB0aGUgcmVhZGVyLCBh bmQgSSB0aGluayB0aGF0IGEgcHJldHRpZXIgZm9ybWF0dGVkIGV4YW1wbGUgd2l0aCBsZXNzDQo+ ID4gbm9pc2UgaGVscHMgdGhlIHJlYWRlci4gIEkgYWxzbyB0aGluayB0aGF0IGlzIG1vc3QgY2Fz ZXMsIHRoaXMgd29ya3MNCj4gPiB3ZWxsOyBpLmUuLCBtb3N0IGNhc2VzIGFyZSBfbm90XyBvbiB0 aGUgZm9ybToNCj4gPiANCj4gPiANCj4gPiANCj4gPiAgICAxMjM0NSAgICAgIDc4OTkwDQo+ID4g DQo+ID4gICAgICAgICAgIF4tLS0tLS0tLS0tLS0tLSBJIG5lZWQgYSBsaW5lIGJyZWFrIGhlcmUN Cj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBGb3IgdGhpcyBwcm9ibGVtLCBJIHBy ZWZlciBhIHNvbHV0aW9uIHRoYXQgaXMgaW50dWl0aXZlIGFuZCBoYXMgbGVzcw0KPiA+IG5vaXNl IGFuZCB3b3JrcyBmb3IgOTAlIG9mIHRoZSBjYXNlcywgdGhhbiBhIGxlc3MgaW50dWl0aXZlIHNv bHV0aW9uDQo+ID4gd2l0aCBtb3JlIG5vaXNlIHRoYXQgd29ya3MgZm9yIDEwMCUgb2YgdGhlIGNh c2VzLg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4g PiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiBJZiB3 ZSB3YW50IHRvIGhhdmUgY29udHJvbCBvZiBsYXlvdXQgYW5kIGJlIGFibGUgdG8gc3RyaXAgZXh0 cmENCj4gPiANCj4gPiA+IHdoaXRlc3BhY2UgdGhlbiBteSBhcmd1bWVudCBpcyB0aGF0IGl0IGlz IGJldHRlciB0byBiZSBleHBsaWNpdCwgYW5kDQo+ID4gDQo+ID4gPiB1c2luZyB0d28gc2xhc2hl cyBpcyBvbmUgd2F5IG9mIGFjaGlldmluZyB0aGlzLg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+ IFRoYW5rcywNCj4gPiANCj4gPiA+IFJvYg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+DQo+ID4g DQo+ID4gPg0KPiA+IA0KPiA+ID4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiA+ID4gT24gQmVoYWxmIE9mIEFk cmlhbiBGYXJyZWwNCj4gPiANCj4gPiA+IFNlbnQ6IDI3IEZlYnJ1YXJ5IDIwMTkgMDk6NDENCj4g PiANCj4gPiA+IFRvOiAnSm9lbCBKYWVnZ2xpJyA8am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9l bGphQGJvZ3VzLmNvbT4+DQo+ID4gDQo+ID4gPiBDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQo+ID4gDQo+ID4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gYXJ0d29y ayBmb2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/DQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4g Q29tcGxldGUgYWdyZWVtZW50LCBKb2VsLg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IFdoYXQg Zm9sbG93cyBtYXkgbG9vayBiZXR0ZXIgaW4gcHJvcG9ydGlvbmFsIGZvbnRzLg0KPiA+IA0KPiA+ ID4NCj4gPiANCj4gPiA+IFdpdGggYSBzaW5nbGUgc2xhc2ggd2UgY2FuIHdyYXAgYXMgZm9sbG93 cw0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IDEyMzQ1NjcgICAgICAgIDkwMTIzNDUNCj4gPiAN Cj4gPiA+DQo+ID4gDQo+ID4gPiBHb2VzIHRv4oCmDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4g MTIzNDU2NyAgICBcDQo+ID4gDQo+ID4gPiAgICAgOTAxMjM0NQ0KPiA+IA0KPiA+ID4NCj4gPiAN Cj4gPiA+IOKApmFuZCB1bndyYXBwaW5nIGlzIGVhc3kuDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ ID4gSG93ZXZlciwgaWYgSSB3YW50IHRvIG1hbnVhbGx5IHdyYXAgdGhlIGxpbmUgd2l0aCBpbmRl bnRhdGlvbg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IFRoZSBxdWljayBicm93biBmb3gganVt cHMgb3ZlciB0aGUgbGF6eSBkb2cNCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiAuLmdvaW5nIHRv 4oCmDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gVGhlIHF1aWNrIGJyb3duIGZveFwNCj4gPiAN Cj4gPiA+ICAgICAgIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+ID4gDQo+ID4gPg0KPiA+IA0K PiA+ID4g4oCmSSBhbSBnb2luZyB0byB1bmZvbGQgYXPigKYNCj4gPiANCj4gPiA+DQo+ID4gDQo+ ID4gPiBUaGUgcXVpY2sgYnJvd24gZm94ICAgICAganVtcHMgb3ZlciB0aGUgbGF6eSBkb2cNCj4g PiANCj4gPiA+DQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gQ29udmVyc2VseSwgaWYgSSByZXNv bHZlIHRoaXMgc2Vjb25kIGNhc2UgYnkgc3RyaXBwaW5nIGxlYWRpbmcgc3BhY2VzDQo+ID4gDQo+ ID4gPiBJIGdldOKApg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IFRoZSBxdWljayBicm93biBm b3hqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IFNvIEkg aGF2ZSB0byBmb2xkIGFz4oCmDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gVGhlIHF1aWNrIGJy b3duIGZveCBcDQo+ID4gDQo+ID4gPiAgICAgICBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KPiA+ IA0KPiA+ID4NCj4gPiANCj4gPiA+IEJ1dCB0aGlzIGNhdXNlcyB0aGUgZmlyc3QgY2FzZSB0byB1 bmZvbGQgYXMNCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiAxMjM0NTY3ICAgIDkwMTIzNDUNCj4g PiANCj4gPiA+DQo+ID4gDQo+ID4gPiDigKZpLmUuLCB3aXRoIG1pc3Npbmcgc3BhY2VzLg0KPiA+ IA0KPiA+ID4NCj4gPiANCj4gPiA+IFRoaXMgaXMgd2hhdCBjYXVzZWQgdGhlIHVzZSBvZiB0aGUg c2Vjb25kIHNsYXNoIHNv4oCmDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gMTIzNDU2NyAgICBc DQo+ID4gDQo+ID4gPiBcICAgIDkwMTIzNDUNCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiDigKZh bmTigKYNCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiBUaGUgcXVpY2sgYnJvd24gZm94XA0KPiA+ IA0KPiA+ID4gICAgICBcIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQo+ID4gDQo+ID4gPg0KPiA+ IA0KPiA+ID4NCj4gPiANCj4gPiA+IFNvLCBteSBwb2ludCBpcywgaWYgYW5kIG9ubHkgaWYgd2Ug ZG8gbm90IGNhcmUgYWJvdXQgdGhlc2Ug4oCcc3BhY2VzIG9uDQo+ID4gDQo+ID4gPiB0aGUgZm9s ZOKAnSBjYXNlcywgd2UgY2FuIG9wZXJhdGUgd2l0aCBhIHNpbmdsZSBzbGFzaC4NCj4gPiANCj4g PiA+DQo+ID4gDQo+ID4gPiBDaGVlcnMsDQo+ID4gDQo+ID4gPiBBZHJpYW4NCj4gPiANCj4gPiA+ DQo+ID4gDQo+ID4gPiBGcm9tOiBKb2VsIEphZWdnbGkNCj4gPiA+IDxqb2VsamFAYm9ndXMuY29t PG1haWx0bzpqb2VsamFAYm9ndXMuY29tPG1haWx0bzpqb2VsamFAYm9ndXMuY29tJTNjbWFpbHRv OmpvZWxqYUBib2d1cy5jb20+Pj4NCj4gPiANCj4gPiA+IFNlbnQ6IDI3IEZlYnJ1YXJ5IDIwMTkg MDY6MzENCj4gPiANCj4gPiA+IFRvOiBBZHJpYW4gRmFycmVsDQo+ID4gPiA8YWRyaWFuQG9sZGRv Zy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5j by51ayUzY21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPj4+DQo+ID4gDQo+ID4gPiBDYzogS2Vu dCBXYXRzZW4NCj4gPiA+IDxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCtpZXRmQHdh dHNlbi5uZXQ8bWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0JTNjbWFpbHRvOmtlbnQraWV0ZkB3 YXRzZW4ubmV0Pj4+Ow0KPiA+IA0KPiA+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyUzY21haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ Pg0KPiA+IA0KPiA+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVh bCBzdXBwb3J0IG1vZGVzPw0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPg0K PiA+IA0KPiA+ID4gT24gRmViIDI2LCAyMDE5LCBhdCAxNDoyNiwgQWRyaWFuIEZhcnJlbA0KPiA+ IA0KPiA+ID4gPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs8 bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWslM2NtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+ Pg0KPiA+ID4gd3JvdGU6DQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gSGV5Lg0KPiA+IA0KPiA+ ID4NCj4gPiANCj4gPiA+IEnigJl2ZSBiZWVuIGhhdmluZyB0aGlzIGRpc2N1c3Npb24gd2l0aCBL ZW50IG9mZi1saW5lLCBidXQgdGhvdWdodCBpdA0KPiA+IA0KPiA+ID4gc2hvdWxkIGNvbWUgdG8g dGhlIGxpc3QuDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gSSBkb27igJl0IHRoaW5rIGl0IGlz IGEgZ29vZCBpZGVhIHRvIGhhdmUgdHdvIGFwcHJvYWNoZXMuIFdoaWxlIGl0IHdvdWxkDQo+ID4g DQo+ID4gPiBiZSByZWxhdGl2ZWx5IGVhc3kgdG8gY29kZSBmb3IgYm90aCBhcHByb2FjaGVzLCBp dCBzZWVtcyB0byBhZGQgYQ0KPiA+IA0KPiA+ID4gZGVncmVlIG9mIGNvbmZ1c2lvbiBpZiBib3Ro IGhhdmUgdG8gYmUgaGFuZGxlZCBieSB0aGUgc2FtZSBjb2RlDQo+ID4gDQo+ID4gPiAoY29uc2lk ZXIgZGVjaWRpbmcgd2hldGhlciBsZWFkaW5nIHNwYWNlIGNoYXJhY3RlcnMgYXJlIHRvIGJlIHJl dGFpbmVkDQo+ID4gDQo+ID4gPiBvciBub3QsIHNvbWV0aGluZyB0aGF0IGNhbiBvbmx5IGJlIGRl Y2lkZWQgd2hlbiB0aGUgZmlyc3Qgbm9uLXNwYWNlDQo+ID4gDQo+ID4gPiBjaGFyYWN0ZXIgaXMg Zm91bmQpLCBvciBieSBoYXZpbmcgZGlmZmVyZW50IGNvZGUgZm9yIHRoZSB0d28gZGlmZmVyZW50 DQo+ID4gDQo+ID4gPiBjYXNlcy4NCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiBJdCBkb2VzbuKA mXQgc2VlbSB0byBtZSB0aGF0IGJvdGggY2FzZXMgYXJlIG5lZWRlZC4gV2UgY2FuIHBpY2sgb25l IG9yDQo+ID4gDQo+ID4gPiB0aGUgb3RoZXIuDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gQSBz aW5nbGUgc2xhc2ggaGFzIGJlZW4gdXNlZCB0byB3cmFwIGxvbmcgbGluZXMgaW4gZWRpdG9ycyBh bmQgc2hlbGxzDQo+ID4gDQo+ID4gPiBmb3IgZGVjYWRlcyBhdCB0aGlzIHBvaW50Lg0KPiA+IA0K PiA+ID4NCj4gPiANCj4gPiA+IGFuZCB5ZWFoIHdoYXRldmVyIGl0IGlzIG9uZSBtZXRob2Qgc2Vl bXMgYmV0dGVyIHRoYW4gdHdvLg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4g PiBBbmQgKmlmKiB3ZSB3YW50IHRvIGFsbG93IG1hbnVhbCBmb2xkaW5nIHNvIHRoYXQgaW5kZW50 cyBjYW4gYmUgbWFkZQ0KPiA+IA0KPiA+ID4gdG8gbWFrZSB0aGUgZG9jdW1lbnQgbW9yZSBodW1h bi1yZWFkYWJsZSB0aGVuIHdlIGhhdmUgdG8gdXNlIGEgbGVhZGluZw0KPiA+IA0KPiA+ID4g4oCY XOKAmSBvbiBjb250aW51YXRpb24gbGluZXMgdG8gc2hvdyB3aGljaCBzcGFjZXMgc2hvdWxkIGJl IHN0cmlwcGVkIGFuZA0KPiA+IA0KPiA+ID4gd2hpY2ggcmV0YWluZWQuDQo+ID4gDQo+ID4gPg0K PiA+IA0KPiA+ID4gQ2hlZXJzLA0KPiA+IA0KPiA+ID4gQWRyaWFuDQo+ID4gDQo+ID4gPg0KPiA+ IA0KPiA+ID4gRnJvbTogbmV0bW9kDQo+ID4gPiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y ZyUzY21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+Pg0KPiA+IA0KPiA+ID4gT24gQmVo YWxmIE9mIEtlbnQgV2F0c2VuDQo+ID4gDQo+ID4gPiBTZW50OiAyNSBGZWJydWFyeSAyMDE5IDIy OjIyDQo+ID4gDQo+ID4gPiBUbzoNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmclM2NtYWlsdG86bmV0bW9kQGlldGYub3Jn Pj4NCj4gPiANCj4gPiA+IFN1YmplY3Q6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBz dXBwb3J0IG1vZGVzPw0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiBJIGhh ZCBhIGNoYXQgd2l0aCB0aGUgdG9vbHMgdGVhbSByZWNlbnRseSBhbmQsIGluIHRoZSBjb3Vyc2Ug b2YNCj4gPiANCj4gPiA+IHRoaW5ncywgaXQgd2FzIGltcGxpZWQgdGhhdCB0aGUgZG91YmxlIGJh Y2tzbGFzaCBhcHByb2FjaCB3ZSBoYXZlIG5vdw0KPiA+IA0KPiA+ID4gd2FzIGJvdGggc3VycHJp c2luZyBhbmQgbm9uLWludHVpdGl2ZS4NCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiBUaGlzIGdv dCBtZSB0aGlua2luZyB0aGF0IHdlIG1heSBoYXZlIHRocm93biB0aGUgcHJvdmVyYmlhbCBiYWJ5 IG91dA0KPiA+IA0KPiA+ID4gd2l0aCB0aGUgYmF0aHdhdGVyLg0KPiA+IA0KPiA+ID4gVGhhdCBp cywgY3VycmVudGx5IHdlIGhhdmUgYSBoZWFkZXIgdGhhdCByZWFkczoNCj4gPiANCj4gPiA+DQo+ ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gICBOT1RFOiAnXFwnIGxpbmUgd3JhcHBpbmcgcGVyIEJD UCBYWCAoUkZDIFhYWFgpDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gU28gd2h5IG5vdCAqYWxz byogc3VwcG9ydCBhIGhlYWRlciB0aGF0IHJlYWRzIChub3RlIHRoZSBzaW5nZSBzbGFzaCk6DQo+ ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+ICAgTk9URTogJ1wnIGxpbmUgd3Jh cHBpbmcgcGVyIEJDUCBYWCAoUkZDIFhYWFgpDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4gV2hl cmVieSB0aGlzIHNlY29uZCBmb3JtIG9ubHkgc3VwcG9ydHMgdGhlIGZvbGRlZCBsaW5lIGNvbnRp bnVpbmcgb24NCj4gPiANCj4gPiA+IGNvbHVtbiAxIChubyBpbmRlbnRzKS4NCj4gPiANCj4gPiA+ DQo+ID4gDQo+ID4gPiBUaG91Z2h0cz8NCj4gPiANCj4gPiA+DQo+ID4gDQo+ID4gPiBLZW50IC8v IGNvbnRyaWJ1dG9yDQo+ID4gDQo+ID4gPg0KPiA+IA0KPiA+ID4NCj4gPiANCj4gPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gDQo+ID4gPiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gDQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnJTNjbWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4+DQo+ID4gDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0KPiA+IA0KPiA+ID4NCj4gDQo= From nobody Mon Mar 4 05:39:45 2019 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 06F27131138 for ; Mon, 4 Mar 2019 05:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 DIyx-4tLogey for ; Mon, 4 Mar 2019 05:39:39 -0800 (PST) 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 DD74C13111C for ; Mon, 4 Mar 2019 05:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11772; q=dns/txt; s=iport; t=1551706778; x=1552916378; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=tbvsbqGbVH9zzXc8fRK3qIAVVTYkAfMpQi6Kc2evVG8=; b=iJwD0pcM0IJVnW/UPqG3O0lVHo9kgcXSCpSN8N5dgKUpz6KtvxFVCC1Z qiX/1lSsk8HlqpGPDZ9YgTsbMmRLH5ZFnBs/Ky0UJmUYwWXd5v6nMXXD2 TRyNhOs3mVGgaAaDtj3qN5vRqDKmrbn8EkErFye0DITUpPjan+LVIUvvV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABDKX1c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgneBAyeDSECIeYxSJY5pizMNGAuEA0Y?= =?us-ascii?q?ChEQ3Bg0BAQMBAQMBAwJtHAyFSgEBAQQBAQoXDwEFNgsMBAkCDgMEAQEBAgI?= =?us-ascii?q?jAwICJx8JCAYBDAYCAQEXgwcBgXUPjFKbZoEvhUSEYIELJAGLPoFAP4ERJwy?= =?us-ascii?q?CX4MeAQGEa4JXAooPAQMsAphmXQmHQ4srBhmCTIgsiCqKZIsYhzKBXSKBVjM?= =?us-ascii?q?aCBsVO4JsCYsDhT8/AzCRFQEB?= X-IronPort-AV: E=Sophos;i="5.58,440,1544486400"; d="scan'208";a="10535220" 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; 04 Mar 2019 13:39:36 +0000 Received: from [10.63.23.61] (dhcp-ensft1-uk-vla370-10-63-23-61.cisco.com [10.63.23.61]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x24Ddas1005109; Mon, 4 Mar 2019 13:39:36 GMT To: Martin Bjorklund , adrian@olddog.co.uk Cc: joelja@bogus.com, netmod@ietf.org References: <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> <20190304.124912.231750494593528236.mbj@tail-f.com> <0a8601d4d283$f13b2180$d3b16480$@olddog.co.uk> <20190304.141630.1246282625623673890.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Mon, 4 Mar 2019 13:39:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <20190304.141630.1246282625623673890.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.61, dhcp-ensft1-uk-vla370-10-63-23-61.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 13:39:43 -0000 On 04/03/2019 13:16, Martin Bjorklund wrote: > "Adrian Farrel" wrote: >> We can go round and round 😊 >> >> How do I fold >> foo bar baz buzz >> so that it can be unfolded? >> >> Clearly a possibility is >> foo bar baz \ >> buzz >> >> But what if the line length would break in the white space? >> You could solve it as >> foo bar \ >> baz buzz >> which requires slightly more complex folding. >> >> Actually, this case arises more often than you might think when the >> line length would cause a fold before a single space. >> Thus, if the line length is 11 >> foo bar baz buzz >> ..would fold as... >> foo bar baz\ >> buzz >> ...and unfold as... >> foo bar bazbuzz >> ...if leading spaces are stripped. >> >> And if leading spaces are not stripped then we cannot handle manual >> padding for reasons of visual formatting. For example... >> foo bar baz\ >> buzz >> >> Personally, I am *really* struggling to understand why we cannot use >> the two-slash approach only. > Maybe b/c if we do, people will start to use it and write things > like: > > "location": "file://example.org/yang/packages/ietf-routing@v\ > \1.3.1.json", > "description": "This package defines a small sample set of I\ > \ETF routing YANG modules that could represent the set of IETF routi\ > \ng functionality that a basic IP network device might be expected t\ > \o support.", > > > I know, it can easily be re-written into: > > "location": "file://example.org/yang/packages\ > \/ietf-routing@v1.3.1.json", > "description": "This package defines a small sample set \ > \of IETF routing YANG modules that could \ > \represent the set of IETF routing \ > \functionality that a basic IP network \ > \device might be expected to support.", > > which is almost as readable as: > > "location": "file://example.org/yang/packages\ > /ietf-routing@v1.3.1.json", > "description": "This package defines a small sample set \ > of IETF routing YANG modules that could \ > represent the set of IETF routing \ > functionality that a basic IP network \ > device might be expected to support.", If I was fixing this by hand then I would probably get to this instead: "location": "file://example.org/yang/packages/ietf-routing@v\ \1.3.1.json", "description": "This package defines a small sample set of \ \IETF routing YANG modules that could represent the set of IETF \ \routing functionality that a basic IP network device might be \ \expected to support.", I think that for the rest of that example (pages 34-37 of draft-rwilton-netmod-yang-packages-00), I think that the folding works pretty well, and the output is reasonably readable. Thanks, Rob > > /martin > > >> Cheers, >> Adrian >> >> >> -----Original Message----- >> From: Martin Bjorklund >> Sent: 04 March 2019 11:49 >> To: rwilton@cisco.com >> Cc: adrian@olddog.co.uk; joelja@bogus.com; netmod@ietf.org >> Subject: Re: [netmod] artwork folding: dual support modes? >> >> "Rob Wilton (rwilton)" wrote: >>> But this behaviour is still different from the frequently used meaning >>> of ‘\’ today in programming languages, which as I know it just splits >>> lines and preserves whitespace. >> Right, but we're not doing a programming language, we try to fit long >> lines in examples into the format required by RFCs, including >> indentation. For example, suppose you have: >> >> Here's an example: >> >> foo bar baz \ >> buzz >> >> Unfolded, do you think this is: >> >> foo bar baz buzz >> >> or >> >> foo bar baz buzz >> >> >>> YANG requires a separator character between a keyword and its >>> argument. What happens if the tool happens to split the line between >>> the two of them. >>> >>> >>> >>> E.g >>> >>> container\ >>> >>> test >>> >>> >>> >>> After the artwork folding, this would become >>> >>> containertest >>> >>> >>> >>> This could be mitigated by a smarter folding tool (e.g. split before >>> the ‘r’ or after the first space). >> >> 1. Don't use a tool to add line breaks - remember the goal was to >> have a readable example. >> >> 2. Don't use this alg. for YANG modules, since YANG has builtin / >> native support for splitting long lines. >> >> >>> Or, what if the tool was being used to fold a table that was using >>> whitespace to align the columns. This could easily break if >>> whitespace is stripped. >> Don't use this alg for tables (or ascii art in general) -- it won't >> help readers. >> >> >> /martin >> >> >> >> >> >>> >>> >>> Thanks, >>> Rob >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Martin Bjorklund >>> Sent: 04 March 2019 08:40 >>> To: Rob Wilton (rwilton) >>> Cc: adrian@olddog.co.uk; joelja@bogus.com; netmod@ietf.org >>> Subject: Re: [netmod] artwork folding: dual support modes? >>> >>> >>> >>> "Rob Wilton (rwilton)" > >>> wrote: >>> >>>> Hi Adrian, >>>> I mostly agree with your last sentence. >>>> I think that if you always preserve whitespace then a single slash is >>>> fine. I.e. the single slash just breaks the line, and I think that >>>> this matches how editors, programming languages, etc normally behave. >>>> What I’m not keen on is using a single slash, and then automatically >>>> stripping leading whitespace on the line following a slash. >>> >>> >>> And this is the solution that I prefer. The reason for this is that I >>> view examples as something that is there to illustrate some point to >>> the reader, and I think that a prettier formatted example with less >>> noise helps the reader. I also think that is most cases, this works >>> well; i.e., most cases are _not_ on the form: >>> >>> >>> >>> 12345 78990 >>> >>> ^-------------- I need a line break here >>> >>> >>> >>> >>> >>> For this problem, I prefer a solution that is intuitive and has less >>> noise and works for 90% of the cases, than a less intuitive solution >>> with more noise that works for 100% of the cases. >>> >>> >>> >>> >>> >>> /martin >>> >>> >>> >>> >>> >>> >>> >>>> If we want to have control of layout and be able to strip extra >>>> whitespace then my argument is that it is better to be explicit, and >>>> using two slashes is one way of achieving this. >>>> Thanks, >>>> Rob >>>> From: netmod > >>>> On Behalf Of Adrian Farrel >>>> Sent: 27 February 2019 09:41 >>>> To: 'Joel Jaeggli' > >>>> Cc: netmod@ietf.org >>>> Subject: Re: [netmod] artwork folding: dual support modes? >>>> Complete agreement, Joel. >>>> What follows may look better in proportional fonts. >>>> With a single slash we can wrap as follows >>>> 1234567 9012345 >>>> Goes to… >>>> 1234567 \ >>>> 9012345 >>>> …and unwrapping is easy. >>>> However, if I want to manually wrap the line with indentation >>>> The quick brown fox jumps over the lazy dog >>>> ..going to… >>>> The quick brown fox\ >>>> jumps over the lazy dog >>>> …I am going to unfold as… >>>> The quick brown fox jumps over the lazy dog >>>> Conversely, if I resolve this second case by stripping leading spaces >>>> I get… >>>> The quick brown foxjumps over the lazy dog >>>> So I have to fold as… >>>> The quick brown fox \ >>>> jumps over the lazy dog >>>> But this causes the first case to unfold as >>>> 1234567 9012345 >>>> …i.e., with missing spaces. >>>> This is what caused the use of the second slash so… >>>> 1234567 \ >>>> \ 9012345 >>>> …and… >>>> The quick brown fox\ >>>> \ jumps over the lazy dog >>>> So, my point is, if and only if we do not care about these “spaces on >>>> the fold†cases, we can operate with a single slash. >>>> Cheers, >>>> Adrian >>>> From: Joel Jaeggli >>>> >> >>>> Sent: 27 February 2019 06:31 >>>> To: Adrian Farrel >>>> >> >>>> Cc: Kent Watsen >>>> >>; >>>> netmod@ietf.org> >>>> Subject: Re: [netmod] artwork folding: dual support modes? >>>> On Feb 26, 2019, at 14:26, Adrian Farrel >>>> >> >>>> wrote: >>>> Hey. >>>> I’ve been having this discussion with Kent off-line, but thought it >>>> should come to the list. >>>> I don’t think it is a good idea to have two approaches. While it would >>>> be relatively easy to code for both approaches, it seems to add a >>>> degree of confusion if both have to be handled by the same code >>>> (consider deciding whether leading space characters are to be retained >>>> or not, something that can only be decided when the first non-space >>>> character is found), or by having different code for the two different >>>> cases. >>>> It doesn’t seem to me that both cases are needed. We can pick one or >>>> the other. >>>> A single slash has been used to wrap long lines in editors and shells >>>> for decades at this point. >>>> and yeah whatever it is one method seems better than two. >>>> And *if* we want to allow manual folding so that indents can be made >>>> to make the document more human-readable then we have to use a leading >>>> ‘\’ on continuation lines to show which spaces should be stripped and >>>> which retained. >>>> Cheers, >>>> Adrian >>>> From: netmod >>>> >> >>>> On Behalf Of Kent Watsen >>>> Sent: 25 February 2019 22:22 >>>> To: >>>> netmod@ietf.org> >>>> Subject: [netmod] artwork folding: dual support modes? >>>> I had a chat with the tools team recently and, in the course of >>>> things, it was implied that the double backslash approach we have now >>>> was both surprising and non-intuitive. >>>> This got me thinking that we may have thrown the proverbial baby out >>>> with the bathwater. >>>> That is, currently we have a header that reads: >>>> NOTE: '\\' line wrapping per BCP XX (RFC XXXX) >>>> So why not *also* support a header that reads (note the singe slash): >>>> NOTE: '\' line wrapping per BCP XX (RFC XXXX) >>>> Whereby this second form only supports the folded line continuing on >>>> column 1 (no indents). >>>> Thoughts? >>>> Kent // contributor >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Mar 4 07:37:22 2019 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 883F81310BA for ; Mon, 4 Mar 2019 07:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9FGmAR6P6XeP for ; Mon, 4 Mar 2019 07:37:17 -0800 (PST) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FDF12D7EA for ; Mon, 4 Mar 2019 07:37:16 -0800 (PST) Received: from ex-hc1.corp.adtran.com (ex-hc1.adtran.com [76.164.174.81]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-95-XLHBqnwyMDS6Sp2u9s471w-3; Mon, 04 Mar 2019 10:37:13 -0500 Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0382.000; Mon, 4 Mar 2019 09:36:39 -0600 From: JOEY BOYD To: "netmod@ietf.org" Thread-Topic: error-message Thread-Index: AdTSn2llQGSojFl0QmmWuHXdWeKWOQ== Date: Mon, 4 Mar 2019 15:36:38 +0000 Message-ID: <26CE489EF4611643B3EFE43D06E02654018CCE2A94@ex-mb3.corp.adtran.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.118.104] MIME-Version: 1.0 X-MC-Unique: XLHBqnwyMDS6Sp2u9s471w-3 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_26CE489EF4611643B3EFE43D06E02654018CCE2A94exmb3corpadtr_" Archived-At: Subject: [netmod] error-message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 15:37:20 -0000 --_000_26CE489EF4611643B3EFE43D06E02654018CCE2A94exmb3corpadtr_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, Is the addition of an 'error-message' to an existing 'must' statement consi= dered backward compatible? I don't see 'error-message' mentioned in the "Up= dating a Module" section which leads me to believe that it isn't but wanted= to double check to see what implications adding one to an existing module = would have. Thanks and regards, Joey --_000_26CE489EF4611643B3EFE43D06E02654018CCE2A94exmb3corpadtr_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi,

 

Is the addition of an ‘error-message’ to= an existing ‘must’ statement considered backward compatible? I= don’t see ‘error-message’ mentioned in the “Updati= ng a Module” section which leads me to believe that it isn’t bu= t wanted to double check to see what implications adding one to an existing module would have= .

 

Thanks and regards,
Joey

 

--_000_26CE489EF4611643B3EFE43D06E02654018CCE2A94exmb3corpadtr_-- From nobody Mon Mar 4 07:48:42 2019 Return-Path: <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@amazonses.watsen.net> 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 5C5EF1310E9 for ; Mon, 4 Mar 2019 07:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 q96qQhfpO7mR for ; Mon, 4 Mar 2019 07:48:39 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D791310D5 for ; Mon, 4 Mar 2019 07:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551714517; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DR0Jqn016nfyN5O8M/VIStQJMpW6VDM3bxl87E5XDs8=; b=UVG9wkFjL8GM0ddHVBhX1HDLnAYkXMPE6i7Q6vFI7Nf/yEmk7yW2mPcUQ+91rzoD J9lRAWUQAMe3qgcO5B4D8p+LGljSajCDFNfVhlduy787+lvwBZcqz70kD5zHC8+Sf14 6gfeB763TYO36pB+M/7LTgsb3CY+GyV96yrdDFMs= From: Kent Watsen Message-ID: <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_96A21EA2-FFD8-40B6-97D5-2DB3B5A31D23" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 4 Mar 2019 15:48:36 +0000 In-Reply-To: <20190304.132926.1893685857666021666.mbj@tail-f.com> Cc: rwilton@cisco.com, netmod@ietf.org To: Martin Bjorklund References: <8ddf74d483674c598e52ece716f70d0a@XCH-RCD-007.cisco.com> <20190304.124912.231750494593528236.mbj@tail-f.com> <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> <20190304.132926.1893685857666021666.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.04-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 15:48:41 -0000 --Apple-Mail=_96A21EA2-FFD8-40B6-97D5-2DB3B5A31D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > But note that figures in RFCs are normally indented with 3 spaces > (they _can_ be outdented, if the lines are long enough). The days of scraping from plain-text RFCs are over [1]. Extracting, if = needed at all, should be from the XML, where there are no such issues. = Extracting from the plain-text output makes about as much sense as = extracting from the HTML or PDF outputs. Lossless extractions are critical for formal verifications (e.g., doctor = reviews, shepherd reviews, AUTH48 reviews). Both the double-backslash = approach we currently have, and the single-backslash approach we had = originally (where the continuation-line begins on column 1, as it has = been in programming languages for decades) provide lossless extractions. The double-backslash approach is ideal for when pretty-indents are = desired. The single-backslash approach is ideal for when the = pretty-indents are not needed. Both are completely valid and useful. = My contention is that we unnecessarily threw out one when reaching for = the other. =20 [1] https://pypi.org/project/xiax Kent= --Apple-Mail=_96A21EA2-FFD8-40B6-97D5-2DB3B5A31D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

But note that = figures in RFCs are normally indented with 3 spaces
(they _can_ be outdented, if the = lines are long enough).

The days of scraping = from plain-text RFCs are over [1].  Extracting, if needed at all, = should be from the XML, where there are no such issues. Extracting from = the plain-text output makes about as much sense as extracting from the = HTML or PDF outputs.

Lossless extractions are critical for formal verifications = (e.g., doctor reviews, shepherd reviews, AUTH48 reviews).   Both = the double-backslash approach we currently have, and the = single-backslash approach we had originally (where the continuation-line = begins on column 1, as it has been in programming languages for decades) = provide lossless extractions.

The double-backslash approach is ideal = for when pretty-indents are desired.   The single-backslash = approach is ideal for when the pretty-indents are not needed.  Both = are completely valid and useful.   My contention is that we = unnecessarily threw out one when reaching for the other. =  

[1] https://pypi.org/project/xiax

Kent
= --Apple-Mail=_96A21EA2-FFD8-40B6-97D5-2DB3B5A31D23-- From nobody Mon Mar 4 08:04:30 2019 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 9F56B12F1AC for ; Mon, 4 Mar 2019 08:04:29 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 m0O3XnVIdmPG for ; Mon, 4 Mar 2019 08:04:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 931BE12F1A2 for ; Mon, 4 Mar 2019 08:04:26 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B3D51AE0118; Mon, 4 Mar 2019 17:04:23 +0100 (CET) Date: Mon, 04 Mar 2019 17:04:23 +0100 (CET) Message-Id: <20190304.170423.167423260282534149.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> References: <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> <20190304.132926.1893685857666021666.mbj@tail-f.com> <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 16:04:30 -0000 Kent Watsen wrote: > > > > But note that figures in RFCs are normally indented with 3 spaces > > (they _can_ be outdented, if the lines are long enough). > > > The days of scraping from plain-text RFCs are over [1]. Extracting, > if needed at all, should be from the XML, where there are no such > issues. Extracting from the plain-text output makes about as much > sense as extracting from the HTML or PDF outputs. I am confused. Are you saying that the unfolding algorithm only is supposed to work on data extracted from the XML version of the I-D or RFC? If so, I think this needs to be clarified in the draft. > Lossless extractions are critical for formal verifications (e.g., > doctor reviews, shepherd reviews, AUTH48 reviews). Both the > double-backslash approach we currently have, and the single-backslash > approach we had originally (where the continuation-line begins on > column 1, as it has been in programming languages for decades) provide > lossless extractions. ... as does the single-backslash with leading space removal. /martin > > The double-backslash approach is ideal for when pretty-indents are > desired. The single-backslash approach is ideal for when the > pretty-indents are not needed. Both are completely valid and useful. > My contention is that we unnecessarily threw out one when reaching for > the other. > > [1] https://pypi.org/project/xiax > > Kent From nobody Mon Mar 4 08:12:44 2019 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 32C7F1310A0 for ; Mon, 4 Mar 2019 08:12:42 -0800 (PST) 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 EwpanYA-QTAp for ; Mon, 4 Mar 2019 08:12:39 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 66F0C1228B7 for ; Mon, 4 Mar 2019 08:12:34 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24GCVnb027357; Mon, 4 Mar 2019 16:12:31 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6029C2203A; Mon, 4 Mar 2019 16:12:31 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 4AD862203C; Mon, 4 Mar 2019 16:12:31 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24GCRdi023502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Mar 2019 16:12:29 GMT Reply-To: From: "Adrian Farrel" To: "'Martin Bjorklund'" , Cc: References: <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> <20190304.132926.1893685857666021666.mbj@tail-f.com> <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> <20190304.170423.167423260282534149.mbj@tail-f.com> In-Reply-To: <20190304.170423.167423260282534149.mbj@tail-f.com> Date: Mon, 4 Mar 2019 16:12:26 -0000 Organization: Old Dog Consulting Message-ID: <000d01d4d2a5$114b6ea0$33e24be0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKEdcDUrOPo8QRw3BTdzRKElgVrdwFRv8svAXIrEBMCznCsTaRvyocg Content-Language: en-gb X-Originating-IP: 87.112.237.8 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24470.000 X-TM-AS-Result: No--3.177-10.0-31-10 X-imss-scan-details: No--3.177-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24470.000 X-TMASE-Result: 10--3.176900-10.000000 X-TMASE-MatchedRID: 9zTThWtzImvxIbpQ8BhdbPHkpkyUphL9ou/UrlGog/JJJReS9JUB3DC0 pJIQUiJO02sd5C8tlITMwqhRUBj1nKqQdkl4gbpY84dsinZ5e1jSL+EVfOJR0yJ8zskw0dbrZtL Yf3KWWVLYHOC/v3JS12NuoFAqzEAvB85Y5vI5GEWWLCkl1lq7B/cku775L1VGnF7LoJiAZVajxY yRBa/qJX3mXSdV7KK4+9plyoHtIZcLbigRnpKlKZx+7GyJjhAUyb4/EN1NwIj+x7MCoqhuY9oB2 +QCQ1u6X+OqojgndQF3Wk1khBW7i5YARLp/D3swHZFxozpd5mXCLVdf1y1kP4qzI6asJSh55D9s mqVBD9yilnnVDECPd/H7AvsTxZMb7DafdH0+BI6wFMlIPaIBbQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 16:12:42 -0000 >> The days of scraping from plain-text RFCs are over [1]. Extracting, >> if needed at all, should be from the XML, where there are no such >> issues. Extracting from the plain-text output makes about as much >> sense as extracting from the HTML or PDF outputs. > > I am confused. Are you saying that the unfolding algorithm only is > supposed to work on data extracted from the XML version of the I-D or > RFC? If so, I think this needs to be clarified in the draft. Quite! If the problem is to extract from XML then there is no problem because wrapping is not needed in the XML (unless manual wrapping has been done). The problem to be addressed when Qin and I started this work was that human-readable copies needed to include some form of wrapping, and we wanted a format that made it abundantly clear that the wrapped version was not normative, and told the reader how to unwrap in order to make valid examples. I fear we are losing touch with the problem statement. Adrian From nobody Mon Mar 4 08:24:56 2019 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 1C96F12D829 for ; Mon, 4 Mar 2019 08:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 6RoFRRF70Qea for ; Mon, 4 Mar 2019 08:24:52 -0800 (PST) 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 6EEA4128B14 for ; Mon, 4 Mar 2019 08:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2311; q=dns/txt; s=iport; t=1551716691; x=1552926291; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7QJ+L8XvOsOPlDrhxUeLGDH6RjKWU+DiZrBebNFHwbs=; b=jc6JglAplqdp0+W6lIBfVSIBs8XcMTHlgINmXOiK/beVbdzWmMZPTNOc 9k3BfLk2n650W8isgkY/5/auofzpdfvusMPYEWL28GsgKS6ozIXpgpXxy YhyNQkxK1SHybabd56x3dXSuMRRd29j6jEsDkYZWoNsmvXQOhdKskcX2c 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AAAPUH1c/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJ4gQMnhAiIeYxTJZocDR+ETQKERzgSAQEDAQEDAQM?= =?us-ascii?q?CbRwMhUsBBSMPAQVBEAsOCgICJgICVwYBDAYCAQGDHgGBdakOgS+FRIRdBYE?= =?us-ascii?q?LJIl1gUqBQD+BOAyCX4gLglcCpAQJh0OLKwYZiniIKopkhVuFPYcygV4hgVY?= =?us-ascii?q?zGggbFYMnH4pthT8/AzCRFQEB?= X-IronPort-AV: E=Sophos;i="5.58,440,1544486400"; d="scan'208";a="10538318" 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; 04 Mar 2019 16:24:48 +0000 Received: from [10.63.23.61] (dhcp-ensft1-uk-vla370-10-63-23-61.cisco.com [10.63.23.61]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x24GOmco024122; Mon, 4 Mar 2019 16:24:48 GMT To: Martin Bjorklund , kent+ietf@watsen.net Cc: netmod@ietf.org References: <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> <20190304.132926.1893685857666021666.mbj@tail-f.com> <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> <20190304.170423.167423260282534149.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Mon, 4 Mar 2019 16:24:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <20190304.170423.167423260282534149.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.61, dhcp-ensft1-uk-vla370-10-63-23-61.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 16:24:54 -0000 The nice thing with the two slash approach is that it always works.  It doesn't matter whether it is text or XML, you just strip what is between the two slashes. The C '\' approach doesn't really work with indentation, and I'm not convinced that extracting code from text RFCs is dead just yet. Martin's strip leading white space approach doesn't safely work with documents that may contain meaningful white space.  Will everyone also include the trailing space at the end of the line before the '\' when required? I still think that the double slash approach is sufficient on its own. If we must have two, then I would suggest the double slash approach, and also Martin's, but perhaps use '+' instead or '\'. Thanks, Rob On 04/03/2019 16:04, Martin Bjorklund wrote: > Kent Watsen wrote: >> >>> But note that figures in RFCs are normally indented with 3 spaces >>> (they _can_ be outdented, if the lines are long enough). >> >> The days of scraping from plain-text RFCs are over [1]. Extracting, >> if needed at all, should be from the XML, where there are no such >> issues. Extracting from the plain-text output makes about as much >> sense as extracting from the HTML or PDF outputs. > I am confused. Are you saying that the unfolding algorithm only is > supposed to work on data extracted from the XML version of the I-D or > RFC? If so, I think this needs to be clarified in the draft. > > >> Lossless extractions are critical for formal verifications (e.g., >> doctor reviews, shepherd reviews, AUTH48 reviews). Both the >> double-backslash approach we currently have, and the single-backslash >> approach we had originally (where the continuation-line begins on >> column 1, as it has been in programming languages for decades) provide >> lossless extractions. > ... as does the single-backslash with leading space removal. > > > /martin > > > >> The double-backslash approach is ideal for when pretty-indents are >> desired. The single-backslash approach is ideal for when the >> pretty-indents are not needed. Both are completely valid and useful. >> My contention is that we unnecessarily threw out one when reaching for >> the other. >> >> [1] https://pypi.org/project/xiax >> >> Kent > . > From nobody Mon Mar 4 09:54:53 2019 Return-Path: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@amazonses.watsen.net> 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 5E019131038 for ; Mon, 4 Mar 2019 09:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 pvA5rNVJZh17 for ; Mon, 4 Mar 2019 09:54:49 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C09130F2A for ; Mon, 4 Mar 2019 09:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551722087; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=a2/9DdyLAM97AZmQ7GZ+OPcVo08S9OtKMyx4z+VZJfo=; b=F1euHbBjPzlIIIhWPVo8o3f0XcheLy3/ZZuw0xQfMttrRGlq2bwYcexuojLPAu91 6U/S2XJ0vscc4C3Av/zT0PiAqMQGg035oHdxm0v9cbM31bU3uzSUz5uihcGE7iSMnml tn96wN99U65imb/M9AjzeqU4j/PdnbY/mkic3PBw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: <20190304.170423.167423260282534149.mbj@tail-f.com> Date: Mon, 4 Mar 2019 17:54:47 +0000 Cc: rwilton@cisco.com, netmod@ietf.org Content-Transfer-Encoding: 7bit Message-ID: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> References: <85b4bfc8-1d55-8df2-98b2-85e685996309@cisco.com> <20190304.132926.1893685857666021666.mbj@tail-f.com> <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> <20190304.170423.167423260282534149.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.04-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 17:54:51 -0000 > On Mar 4, 2019, at 11:04 AM, Martin Bjorklund wrote: > > Kent Watsen wrote: >> >> >>> But note that figures in RFCs are normally indented with 3 spaces >>> (they _can_ be outdented, if the lines are long enough). >> >> >> The days of scraping from plain-text RFCs are over [1]. Extracting, >> if needed at all, should be from the XML, where there are no such >> issues. Extracting from the plain-text output makes about as much >> sense as extracting from the HTML or PDF outputs. > > I am confused. Are you saying that the unfolding algorithm only is > supposed to work on data extracted from the XML version of the I-D or > RFC? If so, I think this needs to be clarified in the draft. The unfolding algorithm works as long as the input == the output. The problem is that plain-text RFCs introduce a lot of artifacts that makes lossless extraction difficult. I don't believe we should try to design a solution for input != output. Now that IETF has officially moved to XML as the sole format, there is no longer a need to support extracting from plain-text. In general, folks are advised to always extract from XML. I support adding a statement to this affect. >> Lossless extractions are critical for formal verifications (e.g., >> doctor reviews, shepherd reviews, AUTH48 reviews). Both the >> double-backslash approach we currently have, and the single-backslash >> approach we had originally (where the continuation-line begins on >> column 1, as it has been in programming languages for decades) provide >> lossless extractions. > > ... as does the single-backslash with leading space removal. No, there are cases where this fails. We went thru this before. This is why we adopted the double-backslash approach. Kent // contributor (also on my previous emails in this thread) From nobody Mon Mar 4 10:35:45 2019 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 15A94130DDA for ; Mon, 4 Mar 2019 10:35:44 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 HvR7tWZrO44u for ; Mon, 4 Mar 2019 10:35:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E2128B14 for ; Mon, 4 Mar 2019 10:35:42 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 75F021AE0118; Mon, 4 Mar 2019 19:35:40 +0100 (CET) Date: Mon, 04 Mar 2019 19:35:40 +0100 (CET) Message-Id: <20190304.193540.1020759172873811211.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> References: <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> <20190304.170423.167423260282534149.mbj@tail-f.com> <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 18:35:44 -0000 Kent Watsen wrote: > > > > On Mar 4, 2019, at 11:04 AM, Martin Bjorklund wrote: > > > > Kent Watsen wrote: > >> > >> > >>> But note that figures in RFCs are normally indented with 3 spaces > >>> (they _can_ be outdented, if the lines are long enough). > >> > >> > >> The days of scraping from plain-text RFCs are over [1]. Extracting, > >> if needed at all, should be from the XML, where there are no such > >> issues. Extracting from the plain-text output makes about as much > >> sense as extracting from the HTML or PDF outputs. > > > > I am confused. Are you saying that the unfolding algorithm only is > > supposed to work on data extracted from the XML version of the I-D or > > RFC? If so, I think this needs to be clarified in the draft. > > The unfolding algorithm works as long as the input == the output. The > problem is that plain-text RFCs introduce a lot of artifacts that makes > lossless extraction difficult. I don't believe we should try to design a > solution for input != output. > > Now that IETF has officially moved to XML as the sole format I'm not sure what you mean, can you provide a pointer? AFAICT, the latest published RFC is still only available as txt and pdf. If the only format was XML, why bother with any line breaking at all? >, there > is no longer a need to support extracting from plain-text. In general, > folks are advised to always extract from XML. I support adding a > statement to this affect. > > > > >> Lossless extractions are critical for formal verifications (e.g., > >> doctor reviews, shepherd reviews, AUTH48 reviews). Both the > >> double-backslash approach we currently have, and the single-backslash > >> approach we had originally (where the continuation-line begins on > >> column 1, as it has been in programming languages for decades) provide > >> lossless extractions. > > > > ... as does the single-backslash with leading space removal. > > No, there are cases where this fails. We went thru this before. Only if you have data with > 69 spaces in a row that needs to be preserved. /martin > This is why > we adopted the double-backslash approach. > > > Kent // contributor (also on my previous emails in this thread) > > > From nobody Mon Mar 4 10:49:15 2019 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 6C971130DEA for ; Mon, 4 Mar 2019 10:49:14 -0800 (PST) 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 0BM997GvWd_I for ; Mon, 4 Mar 2019 10:49:12 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 3A26312DF71 for ; Mon, 4 Mar 2019 10:49:12 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24In91C000628; Mon, 4 Mar 2019 18:49:09 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4C9912203A; Mon, 4 Mar 2019 18:49:09 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 376052203C; Mon, 4 Mar 2019 18:49:09 +0000 (GMT) Received: from LAPTOPK7AS653V ([87.112.237.8]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x24In8aD009822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Mar 2019 18:49:08 GMT Reply-To: From: "Adrian Farrel" To: "'Martin Bjorklund'" , Cc: References: <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> <20190304.170423.167423260282534149.mbj@tail-f.com> <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> <20190304.193540.1020759172873811211.mbj@tail-f.com> In-Reply-To: <20190304.193540.1020759172873811211.mbj@tail-f.com> Date: Mon, 4 Mar 2019 18:49:06 -0000 Organization: Old Dog Consulting Message-ID: <003501d4d2ba$f3124d80$d936e880$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFyKxATlucIggUaAx2AP6rC98J8FQLOcKxNAky/MygCh5qL56aEBv5w Content-Language: en-gb X-Originating-IP: 87.112.237.8 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24470.002 X-TM-AS-Result: No--1.949-10.0-31-10 X-imss-scan-details: No--1.949-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24470.002 X-TMASE-Result: 10--1.948600-10.000000 X-TMASE-MatchedRID: cgbqQT5W8hfxIbpQ8BhdbPHkpkyUphL9Ct4iaV1DkENQKAQSutQYXOyV M+eG9WifcqtPRcRUe0yun8wjeYlO7zcki55oXTR0WHGJY8KbuMTurwUTtj+IjW3D6f6IpbLIAvK 0O9Xf2H5cluisitUZqBy+Hgt9edCCgHrPhMMd52GeAiCmPx4NwLTrdaH1ZWqCdcD5PxhxmQMp58 nSkVckyA1fA1QHegDv3QfwsVk0UbvqwGfCk7KUsxNofyXVU0HdMdum30RPg76ukQXk8CLTpOpHR 3tY7B2+E2TooPxbY+ilQy7eJuDB5bXDdVwFjJadZy5j36p4pK1YmAWncQw0zQkCnkA3h/n1D701 dfVAizuSL9OvtUca/e6+D482nHhrftwZ3X11IV0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 18:49:14 -0000 >> Now that IETF has officially moved to XML as the sole format > > I'm not sure what you mean, can you provide a pointer? AFAICT, > the latest published RFC is still only available as txt and pdf. > > If the only format was XML, why bother with any line breaking at all? I think maybe the IETF is moving towards the XML being the definitive version of drafts and RFCs. But, it is never going to be the case that people go to the XML to read a document. They will pick HTML or text or PDF. So the reader will see folded lines. And the reader needs to know what a folded line means and how to map it to reality. Adrian From nobody Mon Mar 4 10:59:42 2019 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 5168B1310E9 for ; Mon, 4 Mar 2019 10:59:41 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 PCokq-WYps2K for ; Mon, 4 Mar 2019 10:59:40 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3BC1310D5 for ; Mon, 4 Mar 2019 10:59:40 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DAF71AE0118; Mon, 4 Mar 2019 19:59:38 +0100 (CET) Date: Mon, 04 Mar 2019 19:59:37 +0100 (CET) Message-Id: <20190304.195937.709564100094551712.mbj@tail-f.com> To: adrian@olddog.co.uk Cc: kent+ietf@watsen.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <003501d4d2ba$f3124d80$d936e880$@olddog.co.uk> References: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> <20190304.193540.1020759172873811211.mbj@tail-f.com> <003501d4d2ba$f3124d80$d936e880$@olddog.co.uk> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 18:59:41 -0000 "Adrian Farrel" wrote: > >> Now that IETF has officially moved to XML as the sole format > > > > I'm not sure what you mean, can you provide a pointer? AFAICT, > > the latest published RFC is still only available as txt and pdf. > > > > If the only format was XML, why bother with any line breaking at all? > > I think maybe the IETF is moving towards the XML being the definitive > version of drafts and RFCs. Yes I know that. But that's quite different from "XML as the sole format"! /martin > But, it is never going to be the case that > people go to the XML to read a document. They will pick HTML or text or PDF. > > > So the reader will see folded lines. And the reader needs to know what a > folded line means and how to map it to reality. > > Adrian > From nobody Mon Mar 4 12:20:28 2019 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 3D076130E5B for ; Mon, 4 Mar 2019 12:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 ysqZKR0H77eU for ; Mon, 4 Mar 2019 12:20:25 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D4F21128D0B for ; Mon, 4 Mar 2019 12:20:25 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 36F79604D0; Mon, 4 Mar 2019 15:20:25 -0500 (EST) References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> <20190304.105940.312797647046250578.mbj@tail-f.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Martin Bjorklund Cc: chopps@chopps.org, netmod@ietf.org In-reply-to: <20190304.105940.312797647046250578.mbj@tail-f.com> Date: Mon, 04 Mar 2019 15:20:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 20:20:27 -0000 --=-=-= Content-Type: text/plain; format=flowed Martin Bjorklund writes: > Hi, > > Just some quick comments on the YANG: > > However, it seems libxml2's regexp engine requires both "[" and "^" to > be escaped: > > '[-0-9a-z "#\[\]' + > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; > > This expression isn't wrong, but it seems to me that these characters > should not have to be escaped. > > The pattern allows double quote (") but not single quote ('). Is > that intentional? The intent was "ascii-printable". Would be nice if there was an easier way to specify this. :) > [a simple way to test the patterns is to have a "default" statement > and a YANG complier that verifies defaults] Does pyang do this? > I recommend that you rename the example module in section to > "example-uses-geo-location" (and change the namespace to > urn:example:uses-geo-location). We should not use the "ietf" > namespace for examples. Will do. Thanks, Chris. > /martin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx9iIgACgkQLh2DDte4 MCXxbg/5AcPGYpXrQcC+W5s+RK9Q1/sDbznYdYazxxkFFiH7e2x2102NpBM43EkJ opFQHUtPYnweb/FEM1FspY9wOmxzzgqdrHcnyHINFYg4khHX+hed0RfsSrUC/ZOd 9MVdnLqHq2dUCEvG3Vs54a/0Hj3RuAeZ54NKadtqr/9Dzq6CVS72eBlzmTUWhsPq gF+STvWF1hObyihRz+KefyeYz/ZMssRR8yy15XjvMBKlxEbb4exyOGtdigGy8Wss aPmFgHjZ3auWzbZzJQ5vulLD4rSz71ApSL0uLt7rHjWD3v5mBI3PYQ1NvLebYJyX s3PxRcnrjOj986+ZaHH247X0Ej4OJ9xk64N9o6pjvYj2YEQMMk5mKtfB1mcLLibT 6Il0nNL+805ezdMnKHHE8PjQpkd12/L0+jf41cJr++/9rL+xquInWECw+kCHalsP taDhA4o3xh0XhnR4E/nZ62GmuIwrW2PqtJzBHWR2CYs6PhGFHrcaeWLdX4lRnr1+ MTyEonG8dHQalkYWXOz5+foYuZ0n9VXXUWgXX5MRwzgK/o7zRViHACHDi5QwX3+U 0DvwX7ok9tH4e9xMh3e+PxIzQcIYf4FuO0VtzhKJUOTUqfTmxtXyJjNHEI0vEfiR pTXmQx4RprWFc6+N5hZhTKuLkgWaE/+g2pQnUGBBRVYBA/Rj/gA= =ZBVG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 4 13:28:53 2019 Return-Path: <010001694a9bd6f5-87034dff-c252-4e16-8028-f38e9184d2da-000000@amazonses.watsen.net> 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 80B00131186 for ; Mon, 4 Mar 2019 13:28:44 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 nMd_VzkXoz4y for ; Mon, 4 Mar 2019 13:28:42 -0800 (PST) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C4E131199 for ; Mon, 4 Mar 2019 13:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551734921; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=NzUhs0zfeeVJoI/GczXdHTtuQccSG6CdDluhwFv+qgc=; b=AFrf58qdWrZ5zid+zwM2jV9ywkTmjf9Xp+eidFKFkG5s0uGIBeP6JDN+BsSBclcU dsiKhSmNv3B+oKQql0m1Rufxi0TuQEkIgss+ItY3krp6EHedRKk/43PpFQ6+hfrZudj 9V1zlqnXPg5fJk2HupIKJAxiJLNLXzTVVeAW/Gq0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: <20190304.193540.1020759172873811211.mbj@tail-f.com> Date: Mon, 4 Mar 2019 21:28:41 +0000 Cc: rwilton@cisco.com, netmod@ietf.org Content-Transfer-Encoding: 7bit Message-ID: <010001694a9bd6f5-87034dff-c252-4e16-8028-f38e9184d2da-000000@email.amazonses.com> References: <0100016949647f53-8a4d372a-c576-4489-a1e5-b885c6510a1f-000000@email.amazonses.com> <20190304.170423.167423260282534149.mbj@tail-f.com> <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> <20190304.193540.1020759172873811211.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.04-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:28:51 -0000 >> Now that IETF has officially moved to XML as the sole format > > I'm not sure what you mean, can you provide a pointer? AFAICT, the > latest published RFC is still only available as txt and pdf. I meant that XML is the sole *input* format, per RFC 7990, but you're right about the XML not currently being easily accessed. I've signed up for the IETF 104 CodeSprint to fix this, as well as to introduce folding support into the publishing process. >> No, there are cases where this fails. We went thru this before. > > Only if you have data with > 69 spaces in a row that needs to be > preserved. More generally, anytime the fold occurs where space characters follow. But why are you arguing for this? - the double-backslash approach works great for when indents are desired. My interest in this thread was/is only to cover the common case when there are no indents, and the continuation line always begins on column 1, in which case the 2nd backslash is unneeded and somewhat counterintuitive. Kent // contributor From nobody Mon Mar 4 13:32:03 2019 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 1F14912D4E7 for ; Mon, 4 Mar 2019 13:32:02 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.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 L2UFLE8I8q88 for ; Mon, 4 Mar 2019 13:31:59 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 CD19512008A for ; Mon, 4 Mar 2019 13:31:58 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id y13so5189537iop.11 for ; Mon, 04 Mar 2019 13:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rr/METY0lQkR88lMGg4VUJj0BUztFsUTvcQdwXwG/Kc=; b=VS+e5LB0VLr21d7yAfTF6iq+Dun+S4oJWDUyZIvpN/Syjg1x1S5A0n9bCyefvMtzIg Ld7ijSPWR4SlfKwY/C+AJDreYjJm4uc26sFA3nBQYZZyF1SpIKOTHzdiEs64tjWUGHeE /kqe9F7pbcxpiDh1z8ym4D5LDS0XJIi587joX2TtrAWFiMWqUOliUS5jrO9RgW5S1Z+M BCZyY4mEEdbZjlvYWeATfJeq61CtGA71ILPrfFCkobLOyL0JQ104nCpq+hT+5aDsNNSG WHgzud5X+uW+Gvfz0331LvSczmkutmFVitJNKXLR20bRqfR86ws3OwHXAc9RxZl17P7J 514g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rr/METY0lQkR88lMGg4VUJj0BUztFsUTvcQdwXwG/Kc=; b=g6GK4L7qBZgvPyURBpQqdHNciWjyscSjZZ0cWLcwE+MishED0KSEZBBH8Jnk10KjLv b28EzA0jAuDk7AW4jtNJj6kHRDyn2MIIyiQFLMhNr9DEQUCZfYA0iKSStghgyyJnwVJq 0R1DSxxAenxeurXHMk/Zy3qoueuLVm6ms2eJAuRgIOb3bP6MZuISsuzQ5+3mRE51t6N6 /YvoS5rMzMWOU4tn6Xwaeig5KPMtS9wMW7Y99Qf5qGi8Rot75xGHQnihfxh5U4p3MSm/ Md7QFy+T+5Q/wd1Oe47OiY9PnWH3txWyexiCAcLeRt3jEcs1wYHrLVsswhmQsUDnGyeJ eu9Q== X-Gm-Message-State: APjAAAXAID6OopPzQiBg8L4mAWvMZxHaGsUmetbzzHmihocfwDkr6JBI UMeXHJ1tNzz51nM2NQnuUMx7W8qdf9odTJuNdACM2Q== X-Google-Smtp-Source: APXvYqzZEZ21MsZ9XW1fIyLCfTDxvLhUrvP9wuwDIDxElK8L+8x3Dwp2m6lFwIsj0sF7jPlYG6ExyaMJNZ66PQvM2+g= X-Received: by 2002:a5d:9a98:: with SMTP id c24mr11427076iom.212.1551735117896; Mon, 04 Mar 2019 13:31:57 -0800 (PST) MIME-Version: 1.0 References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> <20190304.105940.312797647046250578.mbj@tail-f.com> In-Reply-To: From: William Lupton Date: Mon, 4 Mar 2019 21:31:46 +0000 Message-ID: To: Christian Hopps Cc: Martin Bjorklund , netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000007cf55405834b7c46" Archived-At: Subject: Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:32:02 -0000 --0000000000007cf55405834b7c46 Content-Type: text/plain; charset="UTF-8" > The intent was "ascii-printable". Would be nice if there was an easier way to specify this. :) Printable ASCII characters are ' ' (space) through '~' (tilde) so naively [ -~] should work ... but perhaps that makes unacceptable assumptions about the locale and/or character encoding? (Certainly it should be OK if we can assume UTF-8, because all printable ASCII characters retain their ASCII representations in UTF-8.) On Mon, 4 Mar 2019 at 20:20, Christian Hopps wrote: > > Martin Bjorklund writes: > > > Hi, > > > > Just some quick comments on the YANG: > > > > However, it seems libxml2's regexp engine requires both "[" and "^" to > > be escaped: > > > > '[-0-9a-z "#\[\]' + > > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; > > > > This expression isn't wrong, but it seems to me that these characters > > should not have to be escaped. > > > > The pattern allows double quote (") but not single quote ('). Is > > that intentional? > > The intent was "ascii-printable". Would be nice if there was an easier way > to specify this. :) > > > [a simple way to test the patterns is to have a "default" statement > > and a YANG complier that verifies defaults] > > Does pyang do this? > > > I recommend that you rename the example module in section to > > "example-uses-geo-location" (and change the namespace to > > urn:example:uses-geo-location). We should not use the "ietf" > > namespace for examples. > > Will do. > > Thanks, > Chris. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000007cf55405834b7c46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The intent was "ascii-printable= ". Would be nice if there was an easier way to specify this. :)
Printable ASCII characters are ' ' (space) through = 9;~' (tilde) so naively [ -~] should work ... but perhaps that makes un= acceptable assumptions about the locale and/or character encoding? (Certain= ly it should be OK if we can assume UTF-8, because all printable ASCII char= acters retain their ASCII representations in UTF-8.)

<= div class=3D"gmail_quote">
On Mon, 4 M= ar 2019 at 20:20, Christian Hopps <= chopps@chopps.org> wrote:

Martin Bjorklund <mb= j@tail-f.com> writes:

> Hi,
>
> Just some quick comments on the YANG:
>
> However, it seems libxml2's regexp engine requires both "[&qu= ot; and "^" to
> be escaped:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'[-0-9a-z "#\[\]' +
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'!$%&()*+,./:;<=3D>?@\\= \^_`{|}~]+';
>
> This expression isn't wrong, but it seems to me that these charact= ers
> should not have to be escaped.
>
> The pattern allows double quote (") but not single quote (').= =C2=A0 Is
> that intentional?

The intent was "ascii-printable". Would be nice if there was an e= asier way to specify this. :)

> [a simple way to test the patterns is to have a "default" st= atement
> and a YANG complier that verifies defaults]

Does pyang do this?

> I recommend that you rename the example module in section to
> "example-uses-geo-location" (and change the namespace to
> urn:example:uses-geo-location).=C2=A0 =C2=A0We should not use the &quo= t;ietf"
> namespace for examples.

Will do.

Thanks,
Chris.

> /martin
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000007cf55405834b7c46-- From nobody Mon Mar 4 13:52:28 2019 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 A1866131084 for ; Mon, 4 Mar 2019 13:52:27 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 MhW8aFzyMAVg for ; Mon, 4 Mar 2019 13:52:25 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9877813108F for ; Mon, 4 Mar 2019 13:52:25 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F49B1AE0443; Mon, 4 Mar 2019 22:52:23 +0100 (CET) Date: Mon, 04 Mar 2019 22:52:23 +0100 (CET) Message-Id: <20190304.225223.810570484724895529.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <010001694a9bd6f5-87034dff-c252-4e16-8028-f38e9184d2da-000000@email.amazonses.com> References: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> <20190304.193540.1020759172873811211.mbj@tail-f.com> <010001694a9bd6f5-87034dff-c252-4e16-8028-f38e9184d2da-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:52:28 -0000 Kent Watsen wrote: > > > >> Now that IETF has officially moved to XML as the sole format > > > > I'm not sure what you mean, can you provide a pointer? AFAICT, the > > latest published RFC is still only available as txt and pdf. > > I meant that XML is the sole *input* format, per RFC 7990, but you're > right about the XML not currently being easily accessed. I've signed > up for the IETF 104 CodeSprint to fix this, as well as to introduce > folding support into the publishing process. > > > >> No, there are cases where this fails. We went thru this before. > > > > Only if you have data with > 69 spaces in a row that needs to be > > preserved. > > More generally, anytime the fold occurs where space characters > follow. No, b/c you wouldn't fold there. > But why are you arguing for this? - the double-backslash approach > works great for when indents are desired. Let's agree that it works :) I'm arguing that *if* we are to define two solutions, we should use this one. (And as I explained, my preference is this one over the double-backslash solution, but I accept the WG consensus for the double-backslash solution) > My interest in this thread was/is only to cover the common case > when there are no indents, and the continuation line always begins > on column 1, in which case the 2nd backslash is unneeded and > somewhat counterintuitive. But your continuation line will not start at column 1 (since artwork is indented with 3 spaces by default). So this solution doesn't really work. /martin From nobody Mon Mar 4 14:23:49 2019 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 C0F6C13108B for ; Mon, 4 Mar 2019 14:23:47 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 BNiZgi7H8l4W for ; Mon, 4 Mar 2019 14:23:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF67213108C for ; Mon, 4 Mar 2019 14:23:45 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id C631C1AE0443; Mon, 4 Mar 2019 23:23:42 +0100 (CET) Date: Mon, 04 Mar 2019 23:23:42 +0100 (CET) Message-Id: <20190304.232342.453679466518724925.mbj@tail-f.com> To: chopps@chopps.org Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> <20190304.105940.312797647046250578.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 22:23:48 -0000 Christian Hopps wrote: > > Martin Bjorklund writes: > > > Hi, > > > > Just some quick comments on the YANG: > > > > However, it seems libxml2's regexp engine requires both "[" and "^" to > > be escaped: > > > > '[-0-9a-z "#\[\]' + > > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; > > > > This expression isn't wrong, but it seems to me that these characters > > should not have to be escaped. > > > > The pattern allows double quote (") but not single quote ('). Is > > that intentional? > > The intent was "ascii-printable". Would be nice if there was an easier > way to specify this. :) Hmm, one pattern includes space (but not tab etc), and another doesn't include space. Was that intentional? You may be able to use Unicode properties and write something like: pattern '[\p{IsBasicLatin}-[\p{Lu}\p{Cc}\p{Z}]]+'; Lu = uppercase letter Cc = ascii control Z = whitespace > > [a simple way to test the patterns is to have a "default" statement > > and a YANG complier that verifies defaults] > > Does pyang do this? Yes. /martin From nobody Mon Mar 4 14:39:37 2019 Return-Path: <010001694adcb594-c4949ed4-2ea4-403c-928f-cd2da66ddfd8-000000@amazonses.watsen.net> 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 2D9941311D8 for ; Mon, 4 Mar 2019 14:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 NdxDEP5jOYiG for ; Mon, 4 Mar 2019 14:39:34 -0800 (PST) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBBA1311D1 for ; Mon, 4 Mar 2019 14:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551739172; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=zSKveyhs4QcrjkzsgF0LZNOjmgXVqfS1i4cDr8W1pYM=; b=Hsm5nLHqm0Auup0V1U+sXf8SEwGdbEWvrwxUQo47ux5s7FtCdCVsNHJ0Hl93m5IZ YqyRqKakJAcdikjk+4xfQg1UQc9wXqV4th0wZn4uukygNi/XDUkyOs+rZtINqecwWfu Xl7s0xeQ5frshuSdes4AG+frGiUG6KdK0BTG41jM= From: Kent Watsen Message-ID: <010001694adcb594-c4949ed4-2ea4-403c-928f-cd2da66ddfd8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC5CA42-5143-41B5-9F62-6C10E30B4B6F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 4 Mar 2019 22:39:32 +0000 In-Reply-To: <20190304.225223.810570484724895529.mbj@tail-f.com> Cc: rwilton@cisco.com, netmod@ietf.org To: Martin Bjorklund References: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> <20190304.193540.1020759172873811211.mbj@tail-f.com> <010001694a9bd6f5-87034dff-c252-4e16-8028-f38e9184d2da-000000@email.amazonses.com> <20190304.225223.810570484724895529.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.04-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 22:39:36 -0000 --Apple-Mail=_ACC5CA42-5143-41B5-9F62-6C10E30B4B6F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >>>> No, there are cases where this fails. We went thru this before. >>> >>> Only if you have data with > 69 spaces in a row that needs to be >>> preserved. >> >> More generally, anytime the fold occurs where space characters >> follow. > > No, b/c you wouldn't fold there. A human wouldn't, but an automated folding solution sure could. >> But why are you arguing for this? - the double-backslash approach >> works great for when indents are desired. > > Let's agree that it works :) > > I'm arguing that *if* we are to define two solutions, we should use > this one. (And as I explained, my preference is this one over the > double-backslash solution, but I accept the WG consensus for the > double-backslash solution) Okay, now I understand your position, but I don't agree with it and, as mentioned before, how to support indents was thoroughly debated before. I can't recall if you were sailing then, but I'm guessing you were which is why you're raising this now. >> My interest in this thread was/is only to cover the common case >> when there are no indents, and the continuation line always begins >> on column 1, in which case the 2nd backslash is unneeded and >> somewhat counterintuitive. > > But your continuation line will not start at column 1 (since artwork > is indented with 3 spaces by default). So this solution doesn't > really work. Not in the XML. If rfcstrip/xym wish to extract from plain-text, then they should detect the artwork-level indent/outdent and apply that adjustment to the entire content prior to running the unfolding logic. Kent // contributor --Apple-Mail=_ACC5CA42-5143-41B5-9F62-6C10E30B4B6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
No, there are cases where this fails.  We went thru this = before.

Only if you have data = with > 69 spaces in a row that needs to be
preserved.

More generally, anytime the fold = occurs where space characters
follow.  

No, b/c you wouldn't fold there.

A human = wouldn't, but an automated folding solution sure could.


But = why are you arguing for this? - the double-backslash approach
works great for when indents are desired.   

Let's agree that it works :)

I'm arguing that *if* we are to define two solutions, we = should use
this one. =  (And as I explained, my preference is this one over the
double-backslash solution, but I = accept the WG consensus for the
double-backslash solution)

Okay, now I = understand your position, but I don't agree with it and,
as = mentioned before, how to support indents was thoroughly = debated
before.   I can't recall if you were sailing = then, but I'm guessing you
were which is why you're raising = this now.


My = interest in this thread was/is only to cover the common case 
when there = are no indents, and the continuation line always begins
on = column 1, in which case the 2nd backslash is unneeded and 
somewhat = counterintuitive.

But your continuation line will not start at column 1 (since = artwork
is indented = with 3 spaces by default).  So this solution doesn't
really work.

Not in the = XML.   If rfcstrip/xym wish to extract from plain-text, then
they should detect the artwork-level indent/outdent and apply = that
adjustment to the entire content prior to = running the unfolding logic.

Kent // = contributor 


= --Apple-Mail=_ACC5CA42-5143-41B5-9F62-6C10E30B4B6F-- From nobody Mon Mar 4 21:36:21 2019 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 657CD130F7B; Mon, 4 Mar 2019 21:36:19 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ErOpmkEDr3FR; Mon, 4 Mar 2019 21:36:17 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B855130F75; Mon, 4 Mar 2019 21:36:17 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id AB33E604AD; Tue, 5 Mar 2019 00:36:16 -0500 (EST) References: User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: "netmod\@ietf.org" Cc: XML2RFC Interest Group Cc: chopps@chopps.org Date: Tue, 05 Mar 2019 00:36:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [netmod] New tool: Using Emacs Org Mode for writing RFCs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 05:36:19 -0000 --=-=-= Content-Type: text/plain; format=flowed Check it out: https://github.com/choppsv1/org-rfc-export If you are an Emacs user, especially one who is familiar with/uses Org Mode, I think you'll like this. I've been working on an org mode exporter for writing RFCs. As it's now in MELPA (package: ox-rfc) I figured it was a good time to announce it's availability. Basically you write your RFC in Org Mode and export it to XML. The back-end supports exporting to XML (for manual xml2rfc), but also supports exporting to text, HTML, or PDF, including directly into a buffer for easy previewing. Highlights: - Powerful Org Mode - Simple Citations/References. - Lists (Numbered, Unnumbered) - Definition Lists (term + definition) - Tables - Embedded Code (Literate Programming e.g., embed yang model, trees, examples) In particular YANG embedding is pretty neat. There's no need for separate files and tree generation (and example validation) can be automated from the embedded text. Check out the README and the examples (currently in the ert-tests directory). Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx+Cs8ACgkQLh2DDte4 MCW8TQ//YJvh/nNmQFiWDLlNXcaV+2XkU7mjFdbcLm0qDGUajR+UFI2/5F7r/T0E hP2mDvakFrRorAWx2iLTZZZ+8zGjYq/7OXmC57LutFRB8x6sPSbNdpufRtecS6xg AWRDZS/wBfAy5XwEKIcrqgjeQDDgLBEahAw7AXFSr9sCywUe0qOPMToe9EcFfN5E N8GTl2HyK0Qm60lI2OPH3kK976yGjF658T8AHgy1BRAWvHTtl2+/y4RUqoi1W3mi 9bA0jrv6YvO1fkZ6/6BAxsj7iihqLYHIWsErVIcs+E+842Vs+f6w+ufm5+3QQLyZ nSgzyTl/SKF5o3b2Y35h/PVSIVHD5/NOKomN40xw817BD7FaPoC8dfbMZ727xEIW LBbIheoSRFYsglJdT0k5I3imxLexJnKpx4M2iOqqr6YetMYlkXQbBijEXQIQKrRq hJN+XrMpGYvk14lOq91+yxbMLzKxLqNsHmj5ob8BeNxlTxdlYSvWzICBOec56wLg zcMxSoEv21juMvN0KNNSjTd6orZz/Q6D5518zwuXH0kIPfCjpLuL5YhRV0CLurKn I6DJZ2icTiTWcgjnjHO3FpKGKfoJkXqDwdRYegHnWytNAkXYBi3rfltah7/gJTVy BwSIs5pNZAyONOad+u9OtBXvEDmzvLvrKlLb4uyuzmY3SoCWcaw= =Z0TU -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 5 02:51:42 2019 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 AF00B1275F3; Tue, 5 Mar 2019 02:51:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155178310065.24599.645096412312913846@ietfa.amsl.com> Date: Tue, 05 Mar 2019 02:51:40 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 10:51:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG 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-07.txt Pages : 32 Date : 2019-03-05 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. The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-07 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-intf-ext-yang-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 5 04:31:07 2019 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 24F0F12941A; Tue, 5 Mar 2019 04:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 A3gGXnsSDqDN; Tue, 5 Mar 2019 04:31:02 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::719]) (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 9C105130E9A; Tue, 5 Mar 2019 04:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ru2HtMqhg8wPzgJiT9LBEjrgeO95mgorvcUFx7RQyw=; b=dFNfL2MnKmRLHtHSwV8PuT10god/6sXtZGc6NQR6U2glaVvdTvCgwcVqGXj28b7iyB5KCtMr0iqXuGK1Pj7Pvh9a1yoM7os5Jfv+B1RCLgPEXsDnwxBf4eLbjbwsr7U/U1v/mftQtM/MuL7YsrqibA55Jt187rPbDyJWyvhOuR0= Received: from DB6PR0701MB2182.eurprd07.prod.outlook.com (10.168.55.16) by DB6PR0701MB2198.eurprd07.prod.outlook.com (10.168.55.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Tue, 5 Mar 2019 12:30:57 +0000 Received: from DB6PR0701MB2182.eurprd07.prod.outlook.com ([fe80::2ca5:1eed:afe4:86ea]) by DB6PR0701MB2182.eurprd07.prod.outlook.com ([fe80::2ca5:1eed:afe4:86ea%11]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 12:30:57 +0000 From: tom petch To: Christian Hopps CC: "ietf@ietf.org" , "ibagdona@gmail.com" , "netmod-chairs@ietf.org" , Joel Jaeggli , "draft-ietf-netmod-module-tags@ietf.org" , "netmod@ietf.org" Thread-Topic: Last Call: (YANG Module Tags) to Proposed Standard Thread-Index: AQHUydSfM9CY41Ramk6z6eaef4VGDQ== Date: Tue, 5 Mar 2019 12:30:57 +0000 Message-ID: <078b01d4d34e$ff92af20$4001a8c0@gateway.2wire.net> References: <155046177009.4059.13560986764723643834.idtracker@ietfa.amsl.com> <02d801d4c9d4$615cabe0$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0216.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::36) To DB6PR0701MB2182.eurprd07.prod.outlook.com (2603:10a6:4:4a::16) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 835cbb0f-8927-4735-096f-08d6a1666ace x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6PR0701MB2198; x-ms-traffictypediagnostic: DB6PR0701MB2198: x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(136003)(366004)(376002)(189003)(199004)(13464003)(81156014)(446003)(4720700003)(102836004)(6916009)(99286004)(186003)(6506007)(386003)(93886005)(76176011)(44716002)(62236002)(53936002)(229853002)(71200400001)(81816011)(6486002)(9686003)(86152003)(2906002)(486006)(6512007)(6436002)(66574012)(68736007)(476003)(14496001)(44736005)(5660300002)(66066001)(14444005)(26005)(81686011)(71190400001)(256004)(52116002)(478600001)(106356001)(84392002)(1556002)(105586002)(305945005)(4326008)(7736002)(86362001)(61296003)(316002)(6246003)(81166006)(54906003)(50226002)(3846002)(8676002)(25786009)(97736004)(6116002)(14454004)(8936002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2198; H:DB6PR0701MB2182.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2198; 23:ew1fBB9WJmCVOkyOLuX2F+MdeiRySj7MdFGAn?= =?iso-8859-1?Q?TH2WSIez8dsLoA29Dv16JUrsL3eiwXCUgKtrGZFeNVsbuOwHtb8WlMriO/?= =?iso-8859-1?Q?V92IUgfNLXcL5tg5PnPG8WQlpA81qPd9rq4jIVFJjEOv677untQImhrngT?= =?iso-8859-1?Q?wjqxd8jI+e3fXiTSfp0ZFZQX4j+EdX+iIZzbzXo3xIlySankcNiYrUVe8u?= =?iso-8859-1?Q?noUY3Mbunyh3JaJGrLYOVnXR/L1x0awRrnMPl2Qul0Y5JMZa1XhBkqAc0X?= =?iso-8859-1?Q?8dXHrYOQPM8MBCyNDRMIH68RphNQO6ZaWGm66FAkcGbjY+CoLV6ytT8xc1?= =?iso-8859-1?Q?FpcdoytkFxhT4BZxNkCwpxFY7vwp8s+ppuTK1gBIPpGBh7Y4hlK/1mjQOf?= =?iso-8859-1?Q?AREyWSrai4pqKnG/XlDebWL6KpZC0YwhsnR6Hv0E2CqkMawv2R/4DuTsK8?= =?iso-8859-1?Q?mn4EtNFbOTWV0qbI3MW9yVFffTNdE7IEDV5zZ2Av0TIqzofzcvIfcm/dqZ?= =?iso-8859-1?Q?McwKkQU108ZbtiU+tQEdbduqZBpO2NafHGeFy1PMxvmq7qtTEjn9J7Jtmn?= =?iso-8859-1?Q?pjxrRZIKP9XCEVwXYXt8Nkl4Aw4wuoFSmbfV7H3c5/jb74g7/MHPgWhHh/?= =?iso-8859-1?Q?uQM1GCZ4rk56m9651vxbTzwHbmO170GnuP1BESIBk4SoHiJdUASjaJA0f9?= =?iso-8859-1?Q?tCJqJ+A7qtL/lxfjTiG1o/sD8YQTyxMFN+yq38l69CGSbWJiix8iFZwnWX?= =?iso-8859-1?Q?jKuUFQr/GBnNTTxYvPjZn4n5o3eOD5ISoTjGFFTT2sdXd4PbeqS854rlw3?= =?iso-8859-1?Q?hF9Xc2R/87hZYQSVgZELViMsOzNtYeuN4BqdI630xPxIlYatzyNpugWaQy?= =?iso-8859-1?Q?TJEWPIu0Lfxgm46qhKc+xQajlGXaYwTSqJ4FSh0BQyrh7RI2WmX4Z3mTfO?= =?iso-8859-1?Q?INC0GtWwlsr70WanURFOIsOjrZxsXD11l179Jl+4VwfjBuD8Ox/ahzwOuB?= =?iso-8859-1?Q?KA17BkxxtIuk7O4HozT1xR8CXLXO5SE7gKIBj3QYiL053xd7zxeUrabIVQ?= =?iso-8859-1?Q?uzjAqUz1uI9T00EcTupyPgtqiGGnX+HI6LnBiS3Kr/cTsbLoGqUhN4qoEl?= =?iso-8859-1?Q?4VEIThFYc3eSA8++lk3er8VKspWfcyKnH6g5zmSfBvY2CfZqAhR3sx+YDA?= =?iso-8859-1?Q?Dk+iuVGraTFJmXP9nAGWy92YJSX1BZIf/Gx28plxzMJ1J9HnV9o1zBMHAH?= =?iso-8859-1?Q?Sps7RZ0A4+R4hjZMjbz/W15f400EKRWb7V/M51haugQ6DK+x2pYa/hPofI?= =?iso-8859-1?Q?WPxm6krnux1+TEiQHqFtrdmyqxNuSLoc1X+h+ssw1vGaI3Fy61AtEmVMSm?= =?iso-8859-1?Q?PyRU1/dQThRmk/mP5mfhaKOTgVbPriaLcwRs/DNFnooE+soKWnm9nbcsAn?= =?iso-8859-1?Q?Y0HYa4XVEtrTDoZNXx+/zHvwiSe+/T02DD9obSvFB0arwwogeoNSXGKmoX?= =?iso-8859-1?Q?BVYiEoodzmwvzGsxqWqqgsVeF4VKVwoDGG07OLyplRp8UNOiT/z1ekCIyY?= =?iso-8859-1?Q?rCklROrAP9aY/zlD4ARH/TFZRrGRjSO4RPdzgUspJ39DhXf6CgQ1RMbFEb?= =?iso-8859-1?Q?wNRFPPJvllk+A=3D=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: W58xFf1tiJ/tiXdln7Kl4dwTQzFP+Pcn6gJMh+Oc3ajW7fTizbphNmZROH8rHPiFh9dGxOU853s598LCkrK2B5W7fWhZ8xnYmUzIPEyfsvy5U/EgiVdGGokvgJZcf9n5RBCynjHopvJBLZ8Pr87frxsFjYs2r8DFfBDM7h6TO3upoqFnRPCUbGWECdJfZUwwEgDCuqXOzsQNFyOtJRY/M+8FFwj6xfR7mn5OYQ2KxLWmwfEUjhEUvAwg+mTM5+0UBbuJCHgzmFh1BxEYDqyDX8wEEfiIFFEleoQwYB6vPxFL7GNIQQmjGLGO3lkUZbd4KBMLF1iBEYRGd5bNGlFnbAlOiKEN4ibb6ZBNYcGoRm0dCDMpCQgr8jOXGkTpImbExoE4HPKtoNDIvTNz2/f6KtZRUWbl5/ITr56b3t5VD60= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 835cbb0f-8927-4735-096f-08d6a1666ace X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 12:30:57.6032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2198 Archived-At: Subject: Re: [netmod] Last Call: (YANG Module Tags) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 12:31:06 -0000 Chris I am still left thinking that the existing urn: scheme would do the job just as well. Tom Petch ----- Original Message ----- From: "Christian Hopps" Sent: Thursday, February 21, 2019 12:05 PM > Perhaps we could add some more text in the "Tag Values" section to make this clearer: > > > Except for the conflict-avoiding prefix, this document is not specifying any structure on (i.e., restricting) the tag values on purpose. The intent here is to avoid arbitrarily restricting the values that designers, implementers and users may can use. As a result of this choice, designers, implementers and users are free to add any structure they may find useful to their own tag values. > > > Thanks, > Chris. > > Christian Hopps writes: > > > The document does *not* create ways for specifying names for objects. Its a way to associate meta-data with an implemented yang module. Even says this right at the start of the abstract. > > > > The body of the document does *not* fail to specify the syntax. As you even quoted: > > > > > > All tags SHOULD begin with a prefix indicating who owns their > > definition. An IANA registry is used to support standardizing > > tag prefixes. Currently 3 prefixes are defined with all others > > reserved. No further structure is imposed by this document on > > the value following the standard prefix, and the value can > > contain any yang type 'string' characters except > > carriage-returns, newlines and tabs. > > > > > > "NO FURTHER STRUCTURE..." > > > > There's no structure. People are free to pick any value they want for the tag. If a vendor or an operator wants to create their own sub-structure they are free to do so; however, the base specification does not and should not say this as we specifically do *not* want to restrict things. > > > > I think the problem is that some people want to start restricting this concept and get into specifying and limiting tags to some arbitrary structure, and so they say it's missing. It's not missing, it's intentionally designed to not have it. Its simple, and it's powerful in it's simplicity. > > > > I don't know why there would be any objection to using IANA to create a registry for specifying standard values for a specific use (module tags). That's what IANA is for. There are countless examples of standardizing values w/o using URNs to do it. > > > > Thanks, > > Chris. > > > > > > tom petch writes: > > > >> This I-D creates new way of specifying names for objects; why? > >> > >> We have several existing ways, such as urn: (currently being used by > >> IPPM for its registry, in form of urn:ietf:.. ) and YANG already makes > >> extensive use of urn: so that is part of the vocabulary of YANG modules, > >> so why do we need a new one? > >> > >> And for a new one, the specification seems vague; again, urn or, more > >> generally, uri provides an example of how to specify things. > >> > >> More specifically, > >> > >> - the body of the document fails to specify the syntax. Delve into the > >> YANG module and I find > >> pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; > >> but I expect something in the body, ABNF perhaps. > >> > >> - that pattern allows an infinite depth and is accompnied by > >> length "1..max"; > >> so we could have thousands of characters and the structure seems to be a > >> tree yet the I-D fails to specify how the tree is used, who can create > >> what where. Can I, or someone else, create > >> ietf:hardware:cisco:router:2513:trn > >> Well, the I-D says > >> " No further structure is imposed by this document on the value" > >> so the answer is yes: not a good way to start IMHO - better to start > >> small and expand as needs arise. The I-D cites #hashtags as part of its > >> justification; for me, the opposite is true, where standards work is > >> concerned. > >> > >> In the same vein, > >> "If the module definition is IETF standards track, the tags MUST also be > >> IETF standard tags" > >> but I see nothing to stop proprietary modules using ietf: tags. > >> > >> - CR NL tab are excluded but type string allows > >> any Unicode or ISO/IEC 10646 character > >> so scope there for i18n > >> > >> - there is work for IANA but the I-D references the obsolete RFC5226 and > >> so, e.g., fails to specify a Group name (which I find makes the > >> difference between being able to find something readily on the IANA > >> website and not). > >> > >> - " Other SDOs (standard organizations) wishing to standardize their > >> own > >> set of tags could allocate a top level prefix from this registry." > >> How? Documents like those on URI give guidelines, an e-mail to IANA > >> perhaps. > >> > >> - "The allocation policy for this registry is Specification Required" > >> So what should a Designated Expert look for? It is customary for an I-D > >> to give guidance, if only to the IESG who have to appoint the expert. > >> > >> Then there are a number of glitches. > >> > >> The Abstract contains > >> this document updates [RFC8407]. > >> which looks like a reference, not allowed in Abstract > >> > >> The YANG module contains > >> " described in BCP 14 [RFC2119] [RFC8174] " > >> which again looks like a reference whereas YANG modules must be plain > >> text. > >> > >> Copyright is 2018 > >> > >> YANG module import statement lacks a reference statement > >> > >> The I-D contains an update to RFC8407 which says > >> "The module writer can use existing standard tags" > >> The phrase "module writer" is not used by RFC8407. > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "The IESG" > >> To: "IETF-Announce" > >> Cc: ; ; "Joel Jaeggli" > >> ; ; > >> > >> Sent: Monday, February 18, 2019 3:49 AM > >> Subject: Last Call: (YANG Module > >> Tags) to Proposed Standard > >> > >> > >>> > >>> The IESG has received a request from the Network Modeling WG (netmod) > >> to > >>> consider the following document: - 'YANG Module Tags' > >>> 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 2019-03-03. Exceptionally, comments may > >> be > >>> sent to iesg@ietf.org instead. In either case, please retain the > >> beginning of > >>> the Subject line to allow automated sorting. > >>> > >>> Abstract > From nobody Tue Mar 5 05:32:16 2019 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 D08991310F6; Tue, 5 Mar 2019 05:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 XJZixwGYn1WY; Tue, 5 Mar 2019 05:32:10 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34741310A6; Tue, 5 Mar 2019 05:32:10 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 0E007604E8; Tue, 5 Mar 2019 14:32:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1551792728; bh=e7gs2I/DQgLKLc46kGprNn2cLM6h/a7fuoXzg8//C+g=; h=From:Date:Cc:To:Subject; b=ojM3A3RuxmDKnruXhKjH31uRsHSOJi5kJ/cMpWwz5AvngVW2dayFHYWPo1LEaFUkv B18RHFD112GPgsooGgwui2yTE0DnhY9UETKw8jBXZIif8l5neeLKccU55cJhoqEJZw toJ/Io80vHNsC8CpwVY/Dr9LBjIJj3SQRXbq94KI= Content-Type: text/plain; charset="utf-8" From: =?utf-8?q?Michal_Va=C5=A1ko?= X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Tue, 05 Mar 2019 14:32:08 +0100 Cc: "netconf" To: "netmod" MIME-Version: 1.0 Message-ID: <4a3-5c7e7a80-3-125b9e20@241827065> User-Agent: SOGoMail 2.3.23 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] netconf-config-change and NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 13:32:14 -0000 Hi, I have encountered a problem while validating ietf-netconf-notification= s netconf-config-change notification while following NMDA. The RFC [1] = says that the "target" instance-identifier in this notification should = be validated against operational datastore. In my use-case there was a = running datastore modification and the "target" was not found in the op= erational datastore so the notification failed to be validated. I still= believe the notification should be valid and this seems to be the resu= lt of a flaw in the specification somewhere. Thanks for any input. Regards, Michal [1] https://tools.ietf.org/html/rfc8342#section-6.1 From nobody Tue Mar 5 05:54:35 2019 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 2C09B131268 for ; Tue, 5 Mar 2019 05:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 UctsLIJNn14a for ; Tue, 5 Mar 2019 05:54:31 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE851310F6 for ; Tue, 5 Mar 2019 05:54:31 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 57373604CC; Tue, 5 Mar 2019 08:54:30 -0500 (EST) References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> <20190304.105940.312797647046250578.mbj@tail-f.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: William Lupton Cc: Christian Hopps , Martin Bjorklund , netmod@ietf.org In-reply-to: Date: Tue, 05 Mar 2019 08:54:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 13:54:34 -0000 --=-=-= Content-Type: text/plain; format=flowed William Lupton writes: >> The intent was "ascii-printable". Would be nice if there was an easier > way to specify this. :) > > Printable ASCII characters are ' ' (space) through '~' (tilde) so naively [ > -~] should work ... but perhaps that makes unacceptable assumptions about > the locale and/or character encoding? (Certainly it should be OK if we can > assume UTF-8, because all printable ASCII characters retain their ASCII > representations in UTF-8.) I think your suggestion is a good one! YANG references says it will work too (its the range between the UTF code points, which in this case are the ascii values), but then that reference is also where i got the "#x22" hex format from that Martin said was invalid. :) Thanks, Chris. > > On Mon, 4 Mar 2019 at 20:20, Christian Hopps wrote: > >> >> Martin Bjorklund writes: >> >> > Hi, >> > >> > Just some quick comments on the YANG: >> > >> > However, it seems libxml2's regexp engine requires both "[" and "^" to >> > be escaped: >> > >> > '[-0-9a-z "#\[\]' + >> > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; >> > >> > This expression isn't wrong, but it seems to me that these characters >> > should not have to be escaped. >> > >> > The pattern allows double quote (") but not single quote ('). Is >> > that intentional? >> >> The intent was "ascii-printable". Would be nice if there was an easier way >> to specify this. :) >> >> > [a simple way to test the patterns is to have a "default" statement >> > and a YANG complier that verifies defaults] >> >> Does pyang do this? >> >> > I recommend that you rename the example module in section to >> > "example-uses-geo-location" (and change the namespace to >> > urn:example:uses-geo-location). We should not use the "ietf" >> > namespace for examples. >> >> Will do. >> >> Thanks, >> Chris. >> >> > /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx+f5UACgkQLh2DDte4 MCVYJg//edsHu5NrMTxuMt6bXVpT3ol33pAFX+W6lMBuVU/2J1I5Cbm0pJCyxfsk 0DIvQV3xJaFEXS925HNtuSs/ag/orfn/BEfJM+Y0Gs4xDZmmAdBzgMRnkltZbLI8 6ucR5o8v2TbXX0bInCW2XVwE4tU/50nPxQ6yY3M4SamIKbRnCWpZfBXL92VysDk1 uAnV6YC8XHQXNHs2HB9k5Mz/qGcerOq9IOLVL1kJTITll7xhr1fPkzSv15Cfpw0S zaOLMcIDPiDa9O1LvJCfzYVOaQ0kPZWvUKa3JsKSXhtKAXaIFRAWK6qIi6lRRyFw mYLskADtQEubv5mg4YH/14wSKVICrQNiBQeTx6LFax4+q116KLhcJI9zFauYSht3 ACd5hXcwLgNjAnO8iL88QUCwAChZAvS8nbYxWmIFklETN+5qMoJ4Vi4hMSSO67vh JPyrqsF/+/CLTO/rjXF2RoAL1dK5iUlQi6bLBJ8WdqWihChlchl+J3bLodwEo4Qp Xo2jp4ZAXIdhxu9kDjx8aYC/2vob1P1kx0CslGCmcktyxXVAl/oJLsuuRf9go/fR FVANMdW7yQvF2WB2HmD5E97vbsQy20r2sFDOHhfkaMX6nHz9UnjUHDm3nolQt58F 04wR/Tkc6p57c/uDr9ErUVJGKTNzYpEIsoffGlZolutU9LRL31I= =t+gA -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 5 05:54:49 2019 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 1134D1312C0; Tue, 5 Mar 2019 05:54:46 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZqL_oPD9gcQ5; Tue, 5 Mar 2019 05:54:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89A131291; Tue, 5 Mar 2019 05:54:43 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 208111AE0386; Tue, 5 Mar 2019 14:54:41 +0100 (CET) Date: Tue, 05 Mar 2019 14:54:41 +0100 (CET) Message-Id: <20190305.145441.1898245510911942384.mbj@tail-f.com> To: mvasko@cesnet.cz Cc: netmod@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <4a3-5c7e7a80-3-125b9e20@241827065> References: <4a3-5c7e7a80-3-125b9e20@241827065> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [netconf] netconf-config-change and NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 13:54:48 -0000 Hi, Michal Va=A8ko wrote: > Hi, > I have encountered a problem while validating > ietf-netconf-notifications netconf-config-change notification while > following NMDA. The RFC [1] says that the "target" instance-identifie= r > in this notification should be validated against operational > datastore. In my use-case there was a running datastore modification > and the "target" was not found in the operational datastore so the > notification failed to be validated. I still believe the notification= > should be valid and this seems to be the result of a flaw in the > specification somewhere. Thanks for any input. I think that the problem existed even before NMDA. The netconf-config-change says that the target refers to a node in the affected datastore, and if the affected datastore was startup the instance-identifier wouldn't validate with the given XPath context. Also, even in the case that the datastore was 'running', if the operation was 'delete', the target node could presumably point to the deleted node, which wouldn't validate. Not sure what the right fix is; maybe we shouldn't use an instance-identifier at all in this notification? Or maybe it is ok since the description clearly says that the target refers to a node in the affected datastore. [OTOH, in general it is very hard to tell if validation against the operational state works or not, since it requires a stable snapshot of the operational state.] /martin > = > Regards, > Michal > = > [1] https://tools.ietf.org/html/rfc8342#section-6.1 > = > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > = From nobody Tue Mar 5 06:05:22 2019 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 B40BA131140 for ; Tue, 5 Mar 2019 06:05:18 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 daRc7dysQwaC for ; Tue, 5 Mar 2019 06:05:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9018B131284 for ; Tue, 5 Mar 2019 06:05:02 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 6CC2E1AE0386; Tue, 5 Mar 2019 15:05:00 +0100 (CET) Date: Tue, 05 Mar 2019 15:05:01 +0100 (CET) Message-Id: <20190305.150501.1809357052440270699.mbj@tail-f.com> To: chopps@chopps.org Cc: wlupton@broadband-forum.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 14:05:19 -0000 Christian Hopps wrote: > > William Lupton writes: > > >> The intent was "ascii-printable". Would be nice if there was an easier > > way to specify this. :) > > > > Printable ASCII characters are ' ' (space) through '~' (tilde) so > > naively [ > > -~] should work ... but perhaps that makes unacceptable assumptions > > -about > > the locale and/or character encoding? (Certainly it should be OK if we > > can > > assume UTF-8, because all printable ASCII characters retain their > > ASCII > > representations in UTF-8.) > > I think your suggestion is a good one! Not sure I get it. What exactly is the suggestion? > YANG references > says > it will work too (its the range between the UTF code points, which in > this case are the ascii values), but then that reference is also where > i got the "#x22" hex format from that Martin said was invalid. :) But they use the hex form in the grammar that describes XSD, and that grammar uses EBNF as explained in https://www.w3.org/TR/2000/WD-xml-2e-20000814. /martin > > Thanks, > Chris. > > > > > On Mon, 4 Mar 2019 at 20:20, Christian Hopps > > wrote: > > > >> > >> Martin Bjorklund writes: > >> > >> > Hi, > >> > > >> > Just some quick comments on the YANG: > >> > > >> > However, it seems libxml2's regexp engine requires both "[" and "^" to > >> > be escaped: > >> > > >> > '[-0-9a-z "#\[\]' + > >> > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+'; > >> > > >> > This expression isn't wrong, but it seems to me that these characters > >> > should not have to be escaped. > >> > > >> > The pattern allows double quote (") but not single quote ('). Is > >> > that intentional? > >> > >> The intent was "ascii-printable". Would be nice if there was an easier > >> way > >> to specify this. :) > >> > >> > [a simple way to test the patterns is to have a "default" statement > >> > and a YANG complier that verifies defaults] > >> > >> Does pyang do this? > >> > >> > I recommend that you rename the example module in section to > >> > "example-uses-geo-location" (and change the namespace to > >> > urn:example:uses-geo-location). We should not use the "ietf" > >> > namespace for examples. > >> > >> Will do. > >> > >> Thanks, > >> Chris. > >> > >> > /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > From nobody Tue Mar 5 07:04:09 2019 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 97DA4124B0C for ; Tue, 5 Mar 2019 07:04:07 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.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 ewrdxX6Nlv-m for ; Tue, 5 Mar 2019 07:04:04 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 489461286E7 for ; Tue, 5 Mar 2019 07:04:04 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id l15so4904334iti.4 for ; Tue, 05 Mar 2019 07:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kU0kfcy/2iaWx0Gp0e28SzQglzqHnvB3ZcGrHexsUCE=; b=nNbX305MH6Y7e57Fsqti+Eus037JZrJhz2bA8OutcgG32v2V6n0Mjc9taTI3m7AMik Dxi74MwBdHP8lVE/aTa4zeFKwppUJFLcsuhOjbSFiAuEod48V9HUGnEFR1bvd3ReXFJd H8/ibVP3Sn1VXRLj1LHyZxTQH2xui3B/NhuuGoLkKLvD1/Rs78zHlxSwzzC0DL94eGYR cikGZ2utyvn8hth3c3yVikOJhs5ooUo+vqvxJaVeffXaOp0CvkOzp2NGkP/wSSudtnAl 41JBQABbm5F+Eb92uvMKLHVTCvTTIQnGXttepnjrGkR9gs73JmdcYiQZuT3gg/jq9gTC B6lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kU0kfcy/2iaWx0Gp0e28SzQglzqHnvB3ZcGrHexsUCE=; b=nX8WPQmEyJvQ8f83Qh5CvlT93q7n3jPoDGdh88Vlan6L6XyfV6SFqPMpswpUuY1kiT vjElHGp7iNsSQKshW1aujks/uh8UWER0PPSPPZ9DUrjKImR1UKbGJvaCkU0mCKj4Q7a1 +G+iGtszCtibqCfRy+v5CiyKc09HJOLAzeetLGxqXWXpJ8qTAjaf7eiisHpButQnR0jp Zqu4mMUPyyKKA+Kobob7DZem8S0thhQLbXGdRVPALybmFgO+Far6WXGLoGibhmkT5zA0 I5G5QbiU2YieBY0ocKVwMzgxs1BkF9paEVVttu4SXxlZkL1I9/eZ1Hp1spLKhwhQAgrb q3iQ== X-Gm-Message-State: APjAAAVB6togVFlyLFA/EbiP7KwbaGhU1rZuTSfXc/i+uT3Lktmwr/Z+ MaxhcgQR43xSZqqmbagU6sJXJ+H6CrfaYkWReaaHHw== X-Google-Smtp-Source: APXvYqxP7/fSThzIuq2mMPUL0PPJdSKvBjCYlo8T2W5bw+r+WzUg6vKXoOZK5UsOE97zfQ5cXFErSIrwfhNSaiXwprw= X-Received: by 2002:a24:38c:: with SMTP id e134mr2861995ite.24.1551798243028; Tue, 05 Mar 2019 07:04:03 -0800 (PST) MIME-Version: 1.0 References: <20190305.150501.1809357052440270699.mbj@tail-f.com> In-Reply-To: <20190305.150501.1809357052440270699.mbj@tail-f.com> From: William Lupton Date: Tue, 5 Mar 2019 15:03:52 +0000 Message-ID: To: Martin Bjorklund Cc: Christian Hopps , netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000000a093d05835a2f6d" Archived-At: Subject: Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 15:04:08 -0000 --0000000000000a093d05835a2f6d Content-Type: text/plain; charset="UTF-8" On Tue, 5 Mar 2019 at 14:05, Martin Bjorklund wrote: > Christian Hopps wrote: > > > > William Lupton writes: > > > > >> The intent was "ascii-printable". Would be nice if there was an easier > > > way to specify this. :) > > > > > > Printable ASCII characters are ' ' (space) through '~' (tilde) so > > > naively [ > > > -~] should work ... but perhaps that makes unacceptable assumptions > > > -about > > > the locale and/or character encoding? (Certainly it should be OK if we > > > can > > > assume UTF-8, because all printable ASCII characters retain their > > > ASCII > > > representations in UTF-8.) > > > > I think your suggestion is a good one! > > Not sure I get it. What exactly is the suggestion? > Presumably the suggestion of using the [ -~] ("space through tilde") closure. I forgot to include other whitespace characters (CR, LF, FF) so if those are to be included it could be [\s!-~] ("whitespace plus exclamation mark through tilde"). --0000000000000a093d05835a2f6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 5 Mar 2019 at 14:05, Martin Bjorklund= <mbj@tail-f.com> wrote:
Christian Hopps <chopps@chopps.org&= gt; wrote:
>
> William Lupton <wlupton@broadband-forum.org> writes:
>
> >> The intent was "ascii-printable". Would be nice if = there was an easier
> > way to specify this. :)
> >
> > Printable ASCII characters are ' ' (space) through '~= ' (tilde) so
> > naively [
> > -~] should work ... but perhaps that makes unacceptable assumptio= ns
> > -about
> > the locale and/or character encoding? (Certainly it should be OK = if we
> > can
> > assume UTF-8, because all printable ASCII characters retain their=
> > ASCII
> > representations in UTF-8.)
>
> I think your suggestion is a good one!

Not sure I get it.=C2=A0 What exactly is the suggestion?

Presumably the suggestion of using the [ -~] ("space= through tilde") closure. I forgot to include other whitespace charact= ers (CR, LF, FF) so if those are to be included it could be [\s!-~] ("= whitespace plus exclamation mark through tilde").
--0000000000000a093d05835a2f6d-- From nobody Tue Mar 5 07:33:32 2019 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 B241F124B0C for ; Tue, 5 Mar 2019 07:33:30 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 pF7v9_dHL8K2 for ; Tue, 5 Mar 2019 07:33:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6DD31200D8 for ; Tue, 5 Mar 2019 07:33:28 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F1CD1AE0386; Tue, 5 Mar 2019 16:33:26 +0100 (CET) Date: Tue, 05 Mar 2019 16:33:27 +0100 (CET) Message-Id: <20190305.163327.150084339168999902.mbj@tail-f.com> To: wlupton@broadband-forum.org Cc: chopps@chopps.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190305.150501.1809357052440270699.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / 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-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 15:33:31 -0000 William Lupton wrote: > On Tue, 5 Mar 2019 at 14:05, Martin Bjorklund wrote: > > > Christian Hopps wrote: > > > > > > William Lupton writes: > > > > > > >> The intent was "ascii-printable". Would be nice if there was an easier > > > > way to specify this. :) > > > > > > > > Printable ASCII characters are ' ' (space) through '~' (tilde) so > > > > naively [ > > > > -~] should work ... but perhaps that makes unacceptable assumptions > > > > -about > > > > the locale and/or character encoding? (Certainly it should be OK if we > > > > can > > > > assume UTF-8, because all printable ASCII characters retain their > > > > ASCII > > > > representations in UTF-8.) > > > > > > I think your suggestion is a good one! > > > > Not sure I get it. What exactly is the suggestion? > > > > Presumably the suggestion of using the [ -~] ("space through tilde") Aha, ok, this is better! > closure. I forgot to include other whitespace characters (CR, LF, FF) so if > those are to be included it could be [\s!-~] ("whitespace plus exclamation > mark through tilde"). /martin From nobody Tue Mar 5 11:02:28 2019 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 E3FBA1200D8 for ; Tue, 5 Mar 2019 11:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 A041xTxGTVLO for ; Tue, 5 Mar 2019 11:02:24 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34112D4EB for ; Tue, 5 Mar 2019 11:02:24 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 89290604ED; Tue, 5 Mar 2019 14:02:23 -0500 (EST) References: <20190305.150501.1809357052440270699.mbj@tail-f.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: William Lupton Cc: Martin Bjorklund , Christian Hopps , netmod@ietf.org In-reply-to: Date: Tue, 05 Mar 2019 14:02:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 19:02:26 -0000 --=-=-= Content-Type: text/plain; format=flowed William Lupton writes: > On Tue, 5 Mar 2019 at 14:05, Martin Bjorklund wrote: > >> Christian Hopps wrote: >> > >> > William Lupton writes: >> > >> > >> The intent was "ascii-printable". Would be nice if there was an easier >> > > way to specify this. :) >> > > >> > > Printable ASCII characters are ' ' (space) through '~' (tilde) so >> > > naively [ >> > > -~] should work ... but perhaps that makes unacceptable assumptions >> > > -about >> > > the locale and/or character encoding? (Certainly it should be OK if we >> > > can >> > > assume UTF-8, because all printable ASCII characters retain their >> > > ASCII >> > > representations in UTF-8.) >> > >> > I think your suggestion is a good one! >> >> Not sure I get it. What exactly is the suggestion? >> > > Presumably the suggestion of using the [ -~] ("space through tilde") > closure. I forgot to include other whitespace characters (CR, LF, FF) so if > those are to be included it could be [\s!-~] ("whitespace plus exclamation > mark through tilde"). I mis-poke earlier, it's all printable lowercase ASCII. I'm going to use the pattern: '[ -@\[-\^_-~]*' These 3 ranges seem to make pyang happy. I don't know why I need to break up the second range into 2 adjacent ranges like that to make pyang not complain, but complain it does if I just use: '[ -@\[-~]*' Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx+x74ACgkQLh2DDte4 MCWF5g//SPsunFAwf9u1AkhJpUFihE8hTwjGmXSYWICyXpPSi+jAL+k3RDT0Qdxe 32T0CQngpKLMI+TB9E1mAfa7Y1yNy8Py55/8JoQ0IuYzS4zA2nWi8P3NDHs/XqTj ic11yLZsZ7q5/4qWrakNW08s2zrVGkvV/t4oKS48HNrwEEoxW81eVcd21SHMsCt8 tkNE0hEet9X90P0LJF4s0CoPWB51TlOFKshV2v0gH3Yo+J1jnScltKy8zfha1nSo UeXbpuiu1jvwlgu7TqXGdFKWU0nbmaS0vhC4pUBIeF+6pj0bj/l0eK2fhXwbeWjd Eb8Ehw+/YBVQuFQuCfpzMaHWku5l/SoZhHmGtbysO4PBsMLS2g4XWRibfFY4Ru9x Nq/xvqx3UM5fQ1PitMIH+3G4IBalcUdo/IUdT8TJgK/TSGgcjlTfUm4/2pZr5lh4 cx4uZl3eL/9jzlwcpu+R/J4lKgrEV4VoQx/pGzZ0tmm8fv2nyduO4p9BJdiCJ5e7 sUki9BagY9jlE2ZiGI2VzNHJCHvPpC2BvebZX0lzvVkwoVASjQF4CtbWQQajSY41 Jk3bE1iv/cPBMeZqXQQUa8pfaxK0YxNL00SXtKLTypM+R32IU5EBhVSeTgyzdS+h +aiHbLIKBznxGiYRxB0b4CFoCrqsu2D1vbnSiJC0Y5SrtPNZ22k= =7o/K -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 5 16:27:08 2019 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 0B65E130E9E; Tue, 5 Mar 2019 16:26:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Datatracker on behalf of Elwyn Davies To: Cc: draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155183201188.27630.13798246400958114485@ietfa.amsl.com> Date: Tue, 05 Mar 2019 16:26:51 -0800 Archived-At: Subject: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 00:26:52 -0000 Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netmod-module-tags-06 Reviewer: Elwyn Davies Review Date: 2019-03-05 IETF LC End Date: 2019-03-03 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready.  There are a couple of minor issues and a small number of nits. Apologies for the slightly late delivery of the review. Major issues: None Minor issues: Abstract/s1: I would judge that RFC 8407 ought to be normative since it is updated. S4.2: using the Netmod working group as contact point for the module is not future proof.  I am  not sure what the correct contact ought to be: IESG? S7.2: [This is a thought that occurred to me...] ought there to be an ietf: security tag? S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative Nits/editorial comments: Abstract: s/modules/module's/ Abstract: OLD: This document also provides guidance to future model writers, as such, this document updates RFC8407. NEW: This document also provides guidance to future model writers; as such, this document updates RFC8407. ENDS S1.1, title: s/use cases of/use cases for/ S1.1, para 1: s/documents progression/document's development/ S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/ S1.1, para 4: s/e.g./e.g.,/ S2, para 1:    > All tags SHOULD begin with a prefix indicating who owns their definition. If I read correctly, the YANG definition in s4.2 REQUIRES that all tags have a prefix.  For clarity, it would better if this read:    All tags MUST begin with a prefix; it is intended that this prefix SHOULD [or maybe 'should'] indicate  the ownership or origination of the definition. S2, para 1: s/yang type/YANG type/ (I think) S2.2: s/follwing/following/ S3.1, para 2: OLD: If the module definition is IETF standards track, the tags MUST also be Section 2.1. Thus, new modules can drive the addition of new standard tags to the IANA registry, and the IANA registry can serve as a check against duplication. NEW: If the module is defined in an IETF standards track document, the tags MUST use the prefix defined in Section 2.1. Thus, definitions of new modules can drive the addition of new standard tags to the IANA registry defined in Section 7.2, and the IANA registry can serve as a check against duplication. ENDS S3.2: s/standard/IETF Standard/ S3.3: It would be useful to introduce the term 'masking' used later in the YANG module definition. S4.1: I think this usage of RFC 8340 makes it normative. S4.2, extension module-tag definition: This should contain a pointer to RFC 8342 which discusses the system origin concept. Major issues: Minor issues: Nits/editorial comments: From nobody Wed Mar 6 05:27:05 2019 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 C4BD1127918; Wed, 6 Mar 2019 05:26:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155187880277.24578.18287838352611452713@ietfa.amsl.com> Date: Wed, 06 Mar 2019 05:26:42 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 13:26:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Sub-interface VLAN YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-sub-intf-vlan-model-05.txt Pages : 32 Date : 2019-03-06 Abstract: This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orginating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-05 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 6 05:33:04 2019 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 881381279AF; Wed, 6 Mar 2019 05:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 qUr4rkZ_m-Xs; Wed, 6 Mar 2019 05:32:55 -0800 (PST) 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 7F7DD1275E9; Wed, 6 Mar 2019 05:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6984; q=dns/txt; s=iport; t=1551879175; x=1553088775; h=from:to:cc:subject:date:message-id:mime-version; bh=mOtxFANpLJe25EhKMrI6MqWD3kTEP7DSKlr3ZA18wHE=; b=cesHk00cl0ovEBrh9RPTqlZW3Q4MZQLyqqgYofnGqQmmfetjyrg4PeLa x7RXUbZJpm1PiDEfzHw02Nqnv5kTBxa3xKqwuPYSe4Gn4F0TL37IU2icb Hk7eIH+a7gnEht9poJRAcEDA3CC0ijymIAUbXgxci2loVn/1eUTzU/GvO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACSy39c/5ldJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYENgQJogQMxjBigB4VzgXsLAQGEbIQzIjQJDQEBAwE?= =?us-ascii?q?BAwEDAm0dC4V+TBIBgQAmAQQODYMbgRFkrFOKK4EvAYsoF4FAP48FApBLk0Q?= =?us-ascii?q?JAoF3kH8hky+Kb5IxAhEUgSgfOCiBLnAVgyiCP44LQY0ngR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,448,1544486400"; d="scan'208,217";a="533478505" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2019 13:32:54 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x26DWsOo023414 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Mar 2019 13:32:54 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Mar 2019 07:32:53 -0600 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 6 Mar 2019 07:32:53 -0600 From: "Rob Wilton (rwilton)" To: "netmod-chairs@ietf.org" CC: "netmod@ietf.org" Thread-Topic: Drafts draft-ietf-netmod-sub-intf-vlan-model-05 and draft-ietf-netmod-intf-ext-yang-07 Thread-Index: AdTUIJSUdVlb0ayuQg2LDlG5lFEJFQ== Date: Wed, 6 Mar 2019 13:32:53 +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.63.23.61] Content-Type: multipart/alternative; boundary="_000_c487762e781e4f7c887099f23ba78f36XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: [netmod] Drafts draft-ietf-netmod-sub-intf-vlan-model-05 and draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 13:33:03 -0000 --_000_c487762e781e4f7c887099f23ba78f36XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, WG chairs, I believe that these two drafts are now ready for WG LC. Recent updates: draft-ietf-netmod-intf-ext-yang-07: - minor editorial updates only. draft-ietf-netmod-sub-intf-vlan-model-05: - Addresses comments raised by John Messenger/IEEE 802.1 WG - Restricts the VLAN type of the outer tag to 802.1Q C-VLAN or S-VLA= N types. - Ensures that config cannot be used to match on a second tag withou= t also matching on the outer tag. Thanks, Rob --_000_c487762e781e4f7c887099f23ba78f36XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

WG chairs, I believe that these two drafts are now r= eady for WG LC.

 

Recent updates:

 

draft-ietf-netmod-intf-ext-yang-07:
  - minor editorial updates only.

draft-ietf-netmod-sub-intf-vlan-model-05:

-       = ; Addresses comments raised by John Messenger/IEEE 80= 2.1 WG

-       = ; Restricts the VLAN type of the outer tag to 802.1Q = C-VLAN or S-VLAN types.

-       = ; Ensures that config cannot be used to match on a se= cond tag without also matching on the outer tag.

 

Thanks,

Rob

--_000_c487762e781e4f7c887099f23ba78f36XCHRCD007ciscocom_-- From nobody Wed Mar 6 12:09:14 2019 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 D12CE13104B; Wed, 6 Mar 2019 12:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 7kIQsC1yxTlJ; Wed, 6 Mar 2019 12:09:03 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) (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 084A2128701; Wed, 6 Mar 2019 12:09:03 -0800 (PST) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[192.168.0.132]) by b-painless.mh.aa.net.uk with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.89) (envelope-from ) id 1h1cPj-0004AS-TN; Wed, 06 Mar 2019 19:41:19 +0000 SavedFromEmail: elwynd@dial.pipex.com Date: Wed, 06 Mar 2019 19:39:53 +0000 In-Reply-To: <155183201188.27630.13798246400958114485@ietfa.amsl.com> Importance: normal From: Elwyn Davies To: gen-art@ietf.org Cc: draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_4349032064753420" Message-ID: Archived-At: Subject: Re: [netmod] [Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 20:09:07 -0000 ----_com.samsung.android.email_4349032064753420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkuQWZ0ZXIgY29tcGxldGluZyBteSByZXZpZXcsIEkgcmVhbGl6ZWQgdGhhdCB0aGVyZSB3YXMg YSBmdXJ0aGVyIG1pbm9yIGlzc3VlIHJlbGF0ZWQgdG8gdGhlIHBvc3NpYmxlIHZhbHVlcyBvZiB0 YWcgcHJlZml4ZXMsIHBvc3NpYmxlIHZhbHVlcyBvZiBzdGFuZGFyZGl6ZWQgcHJlZml4ZXMgYW5k IGJlaGF2aW91ciBvZiBpbXBsZW1lbnRhdGlvbnMgaW4gdGhlIGZhY2Ugb2YgdGFnIHByZWZpeGVz IG9yIHZhbHVlcyB0aGF0IGFyZSBub3QgaW4gdGhlIHJlbGV2YW50IHJlZ2lzdHJpZXMuSSB0aGlu ayB0aGF0IHRoZSB0ZXh0IGluIHMyIHNob3VsZCBiZSByZWluZm9yY2VkIHRvIGVtcGhhc2lzZSB0 aGF0IHRoZSBvbmx5IHByZWZpeGVzIHRoYXQgc2hvdWxkIGJlIGV4cGVjdGVkIGFyZSB0aG9zZSBp biB0aGUgSUFOQSByZWdpc3RyeSBkZWZpbmVkIGluIHM3LjEuRWl0aGVyIGEgbmV3IHNlY3Rpb24g b3IgcG9zc2libHkgaW4gczMgdGV4dCBzaG91bGQgYmUgYWRkZWQgdG8gZGVmaW5lIHRoZSBiZWhh dmlvdXIgb2YgWUFORyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBlbmNvdW50ZXIgdGFncyB3aXRoIHBy ZWZpeGVzIHRoYXQgYXJlIG5vdCBpbiB0aGUgczcuMSByZWdpc3RyeSBhbmQgdGFncyB3aXRoIHBy ZWZpeCBpZXRmOiB0aGF0IGFyZSBub3QgaW4gdGhlIHM3LjIgcmVnaXN0cnkuUmVnYXJkcyxFbHd5 biBEYXZpZXPCoMKgwqDCoFNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC4KLS0tLS0tLS0gT3JpZ2lu YWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IERhdGF0cmFja2VyIG9uIGJlaGFsZiBvZiBFbHd5biBE YXZpZXMgPGlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmc+IERhdGU6IDA2LzAzLzIwMTkg IDAwOjI2ICAoR01UKzAwOjAwKSBUbzogZ2VuLWFydEBpZXRmLm9yZyBDYzogZHJhZnQtaWV0Zi1u ZXRtb2QtbW9kdWxlLXRhZ3MuYWxsQGlldGYub3JnLCBpZXRmQGlldGYub3JnLCBuZXRtb2RAaWV0 Zi5vcmcgU3ViamVjdDogW0dlbi1hcnRdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mCsKgIGRy YWZ0LWlldGYtbmV0bW9kLW1vZHVsZS10YWdzLTA2IFJldmlld2VyOiBFbHd5biBEYXZpZXNSZXZp ZXcgcmVzdWx0OiBBbG1vc3QgUmVhZHlJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJl dmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZGJ5IHRoZSBJRVNHIGZvciB0 aGUgSUVURiBDaGFpci7CoCBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy5Gb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNl ZSB0aGUgRkFRIGF0PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZh cT4uRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbmV0bW9kLW1vZHVsZS10YWdzLTA2UmV2aWV3ZXI6IEVs d3luIERhdmllc1JldmlldyBEYXRlOiAyMDE5LTAzLTA1SUVURiBMQyBFbmQgRGF0ZTogMjAxOS0w My0wM0lFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3IgYSB0ZWxlY2hhdFN1bW1h cnk6QWxtb3N0IHJlYWR5LsKgIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBtaW5vciBpc3N1ZXMgYW5k IGEgc21hbGwgbnVtYmVyIG9mIG5pdHMuIEFwb2xvZ2llcyBmb3IgdGhlIHNsaWdodGx5IGxhdGUg ZGVsaXZlcnkgb2YgdGhlIHJldmlldy5NYWpvciBpc3N1ZXM6Tm9uZU1pbm9yIGlzc3VlczpBYnN0 cmFjdC9zMTogSSB3b3VsZCBqdWRnZSB0aGF0IFJGQyA4NDA3IG91Z2h0IHRvIGJlIG5vcm1hdGl2 ZSBzaW5jZSBpdCBpc3VwZGF0ZWQuUzQuMjogdXNpbmcgdGhlIE5ldG1vZCB3b3JraW5nIGdyb3Vw IGFzIGNvbnRhY3QgcG9pbnQgZm9yIHRoZSBtb2R1bGUgaXMgbm90ZnV0dXJlIHByb29mLsKgIEkg YW3CoCBub3Qgc3VyZSB3aGF0IHRoZSBjb3JyZWN0IGNvbnRhY3Qgb3VnaHQgdG8gYmU6IElFU0c/ UzcuMjogW1RoaXMgaXMgYSB0aG91Z2h0IHRoYXQgb2NjdXJyZWQgdG8gbWUuLi5dIG91Z2h0IHRo ZXJlIHRvIGJlIGFuIGlldGY6c2VjdXJpdHkgdGFnP1M5OiBJIHdvdWxkIGNvbnNpZGVyIFJGQ3Mg ODE5OSwgODM0MCwgODM0MiBhbmQgODQwNyB0byBiZSBub3JtYXRpdmVOaXRzL2VkaXRvcmlhbCBj b21tZW50czpBYnN0cmFjdDogcy9tb2R1bGVzL21vZHVsZSdzL0Fic3RyYWN0Ok9MRDpUaGlzIGRv Y3VtZW50IGFsc28gcHJvdmlkZXMgZ3VpZGFuY2UgdG8gZnV0dXJlIG1vZGVsIHdyaXRlcnMsIGFz IHN1Y2gsIHRoaXNkb2N1bWVudCB1cGRhdGVzIFJGQzg0MDcuTkVXOlRoaXMgZG9jdW1lbnQgYWxz byBwcm92aWRlcyBndWlkYW5jZSB0byBmdXR1cmUgbW9kZWwgd3JpdGVyczsgYXMgc3VjaCwgdGhp c2RvY3VtZW50IHVwZGF0ZXMgUkZDODQwNy5FTkRTUzEuMSwgdGl0bGU6IHMvdXNlIGNhc2VzIG9m L3VzZSBjYXNlcyBmb3IvUzEuMSwgcGFyYSAxOiBzL2RvY3VtZW50cyBwcm9ncmVzc2lvbi9kb2N1 bWVudCdzIGRldmVsb3BtZW50L1MxLjEsIHBhcmFzIDIsIDMgYW5kIDU6IFN1Z2dlc3Qgcy9FLmcu L0ZvciBleGFtcGxlL1MxLjEsIHBhcmEgNDogcy9lLmcuL2UuZy4sL1MyLCBwYXJhIDE6wqAgwqA+ IEFsbCB0YWdzIFNIT1VMRCBiZWdpbiB3aXRoIGEgcHJlZml4IGluZGljYXRpbmcgd2hvIG93bnMg dGhlaXIgZGVmaW5pdGlvbi5JZiBJIHJlYWQgY29ycmVjdGx5LCB0aGUgWUFORyBkZWZpbml0aW9u IGluIHM0LjIgUkVRVUlSRVMgdGhhdCBhbGwgdGFncyBoYXZlIGFwcmVmaXguwqAgRm9yIGNsYXJp dHksIGl0IHdvdWxkIGJldHRlciBpZiB0aGlzIHJlYWQ6wqAgwqBBbGwgdGFncyBNVVNUIGJlZ2lu IHdpdGggYSBwcmVmaXg7IGl0IGlzIGludGVuZGVkIHRoYXQgdGhpcyBwcmVmaXggU0hPVUxEwqDC oCBbb3IgbWF5YmUgJ3Nob3VsZCddIGluZGljYXRlIMKgdGhlIG93bmVyc2hpcCBvciBvcmlnaW5h dGlvbiBvZiB0aGUgZGVmaW5pdGlvbi5TMiwgcGFyYSAxOiBzL3lhbmcgdHlwZS9ZQU5HIHR5cGUv IChJIHRoaW5rKVMyLjI6IHMvZm9sbHdpbmcvZm9sbG93aW5nL1MzLjEsIHBhcmEgMjpPTEQ6SWYg dGhlIG1vZHVsZSBkZWZpbml0aW9uIGlzIElFVEYgc3RhbmRhcmRzIHRyYWNrLCB0aGUgdGFncyBN VVNUIGFsc28gYmUgU2VjdGlvbjIuMS4gVGh1cywgbmV3IG1vZHVsZXMgY2FuIGRyaXZlIHRoZSBh ZGRpdGlvbiBvZiBuZXcgc3RhbmRhcmQgdGFncyB0byB0aGUgSUFOQXJlZ2lzdHJ5LCBhbmQgdGhl IElBTkEgcmVnaXN0cnkgY2FuIHNlcnZlIGFzIGEgY2hlY2sgYWdhaW5zdCBkdXBsaWNhdGlvbi5O RVc6SWYgdGhlIG1vZHVsZSBpcyBkZWZpbmVkIGluIGFuIElFVEYgc3RhbmRhcmRzIHRyYWNrIGRv Y3VtZW50LCB0aGUgdGFncyBNVVNUIHVzZXRoZSBwcmVmaXggZGVmaW5lZCBpbiBTZWN0aW9uIDIu MS4gVGh1cywgZGVmaW5pdGlvbnMgb2YgbmV3IG1vZHVsZXMgY2FuIGRyaXZldGhlIGFkZGl0aW9u IG9mIG5ldyBzdGFuZGFyZCB0YWdzIHRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGRlZmluZWQgaW4gU2Vj dGlvbiA3LjIsYW5kIHRoZSBJQU5BIHJlZ2lzdHJ5IGNhbiBzZXJ2ZSBhcyBhIGNoZWNrIGFnYWlu c3QgZHVwbGljYXRpb24uRU5EU1MzLjI6IHMvc3RhbmRhcmQvSUVURiBTdGFuZGFyZC9TMy4zOiBJ dCB3b3VsZCBiZSB1c2VmdWwgdG8gaW50cm9kdWNlIHRoZSB0ZXJtICdtYXNraW5nJyB1c2VkIGxh dGVyIGluIHRoZSBZQU5HbW9kdWxlIGRlZmluaXRpb24uUzQuMTogSSB0aGluayB0aGlzIHVzYWdl IG9mIFJGQyA4MzQwIG1ha2VzIGl0IG5vcm1hdGl2ZS5TNC4yLCBleHRlbnNpb24gbW9kdWxlLXRh ZyBkZWZpbml0aW9uOiBUaGlzIHNob3VsZCBjb250YWluIGEgcG9pbnRlciB0byBSRkM4MzQyIHdo aWNoIGRpc2N1c3NlcyB0aGUgc3lzdGVtIG9yaWdpbiBjb25jZXB0Lk1ham9yIGlzc3VlczpNaW5v ciBpc3N1ZXM6Tml0cy9lZGl0b3JpYWwgY29tbWVudHM6X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19HZW4tYXJ0IG1haWxpbmcgbGlzdEdlbi1hcnRAaWV0Zi5v cmdodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlbi1hcnQ= ----_com.samsung.android.email_4349032064753420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkhpLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+QWZ0ZXIgY29tcGxldGluZyBteSByZXZpZXcsIEkgcmVhbGl6ZWQgdGhhdCB0 aGVyZSB3YXMgYSBmdXJ0aGVyIG1pbm9yIGlzc3VlIHJlbGF0ZWQgdG8gdGhlIHBvc3NpYmxlIHZh bHVlcyBvZiB0YWcgcHJlZml4ZXMsIHBvc3NpYmxlIHZhbHVlcyBvZiBzdGFuZGFyZGl6ZWQgcHJl Zml4ZXMgYW5kIGJlaGF2aW91ciBvZiBpbXBsZW1lbnRhdGlvbnMgaW4gdGhlIGZhY2Ugb2YgdGFn IHByZWZpeGVzIG9yIHZhbHVlcyB0aGF0IGFyZSBub3QgaW4gdGhlIHJlbGV2YW50IHJlZ2lzdHJp ZXMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHRoaW5rIHRoYXQgdGhlIHRleHQgaW4gczIg c2hvdWxkIGJlIHJlaW5mb3JjZWQgdG8gZW1waGFzaXNlIHRoYXQgdGhlIG9ubHkgcHJlZml4ZXMg dGhhdCBzaG91bGQgYmUgZXhwZWN0ZWQgYXJlIHRob3NlIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGRl ZmluZWQgaW4gczcuMS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkVpdGhlciBhIG5ldyBzZWN0 aW9uIG9yIHBvc3NpYmx5IGluIHMzIHRleHQgc2hvdWxkIGJlIGFkZGVkIHRvIGRlZmluZSB0aGUg YmVoYXZpb3VyIG9mIFlBTkcgaW1wbGVtZW50YXRpb25zIHRoYXQgZW5jb3VudGVyIHRhZ3Mgd2l0 aCBwcmVmaXhlcyB0aGF0IGFyZSBub3QgaW4gdGhlIHM3LjEgcmVnaXN0cnkgYW5kIHRhZ3Mgd2l0 aCBwcmVmaXggaWV0ZjogdGhhdCBhcmUgbm90IGluIHRoZSBzNy4yIHJlZ2lzdHJ5LjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+UmVnYXJkcyw8L2Rpdj48ZGl2PkVsd3luIERhdmllcyZuYnNwOzwv ZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdj4mbmJzcDsmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1 cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5T ZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBz dHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2Ug LS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9t OiBEYXRhdHJhY2tlciBvbiBiZWhhbGYgb2YgRWx3eW4gRGF2aWVzICZsdDtpZXRmLXNlY3JldGFy aWF0LXJlcGx5QGlldGYub3JnJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDA2LzAzLzIwMTkgIDAwOjI2 ICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBnZW4tYXJ0QGlldGYub3JnIDwvZGl2PjxkaXY+ Q2M6IGRyYWZ0LWlldGYtbmV0bW9kLW1vZHVsZS10YWdzLmFsbEBpZXRmLm9yZywgaWV0ZkBpZXRm Lm9yZywgbmV0bW9kQGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVjdDogW0dlbi1hcnRdIEdlbmFy dCBsYXN0IGNhbGwgcmV2aWV3IG9mCiZuYnNwOyBkcmFmdC1pZXRmLW5ldG1vZC1tb2R1bGUtdGFn cy0wNiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5SZXZpZXdlcjogRWx3eW4gRGF2aWVzPGJy PlJldmlldyByZXN1bHQ6IEFsbW9zdCBSZWFkeTxicj48YnI+SSBhbSB0aGUgYXNzaWduZWQgR2Vu LUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYTxicj5SZXZpZXcg VGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2Vk PGJyPmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4mbmJzcDsgUGxlYXNlIHRyZWF0IHRo ZXNlIGNvbW1lbnRzIGp1c3Q8YnI+bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxi cj48YnI+Rm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdDxicj48YnI+ Jmx0O2h0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcSZndDsuPGJy Pjxicj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1uZXRtb2QtbW9kdWxlLXRhZ3MtMDY8YnI+UmV2aWV3 ZXI6IEVsd3luIERhdmllczxicj5SZXZpZXcgRGF0ZTogMjAxOS0wMy0wNTxicj5JRVRGIExDIEVu ZCBEYXRlOiAyMDE5LTAzLTAzPGJyPklFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBm b3IgYSB0ZWxlY2hhdDxicj48YnI+U3VtbWFyeTo8YnI+QWxtb3N0IHJlYWR5LiZuYnNwOyBUaGVy ZSBhcmUgYSBjb3VwbGUgb2YgbWlub3IgaXNzdWVzIGFuZCBhIHNtYWxsIG51bWJlciBvZiBuaXRz LiA8YnI+QXBvbG9naWVzIGZvciB0aGUgc2xpZ2h0bHkgbGF0ZSBkZWxpdmVyeSBvZiB0aGUgcmV2 aWV3Ljxicj48YnI+TWFqb3IgaXNzdWVzOjxicj5Ob25lPGJyPjxicj5NaW5vciBpc3N1ZXM6PGJy PkFic3RyYWN0L3MxOiBJIHdvdWxkIGp1ZGdlIHRoYXQgUkZDIDg0MDcgb3VnaHQgdG8gYmUgbm9y bWF0aXZlIHNpbmNlIGl0IGlzPGJyPnVwZGF0ZWQuPGJyPjxicj5TNC4yOiB1c2luZyB0aGUgTmV0 bW9kIHdvcmtpbmcgZ3JvdXAgYXMgY29udGFjdCBwb2ludCBmb3IgdGhlIG1vZHVsZSBpcyBub3Q8 YnI+ZnV0dXJlIHByb29mLiZuYnNwOyBJIGFtJm5ic3A7IG5vdCBzdXJlIHdoYXQgdGhlIGNvcnJl Y3QgY29udGFjdCBvdWdodCB0byBiZTogSUVTRz88YnI+PGJyPlM3LjI6IFtUaGlzIGlzIGEgdGhv dWdodCB0aGF0IG9jY3VycmVkIHRvIG1lLi4uXSBvdWdodCB0aGVyZSB0byBiZSBhbiBpZXRmOjxi cj5zZWN1cml0eSB0YWc/PGJyPjxicj5TOTogSSB3b3VsZCBjb25zaWRlciBSRkNzIDgxOTksIDgz NDAsIDgzNDIgYW5kIDg0MDcgdG8gYmUgbm9ybWF0aXZlPGJyPjxicj5OaXRzL2VkaXRvcmlhbCBj b21tZW50czo8YnI+QWJzdHJhY3Q6IHMvbW9kdWxlcy9tb2R1bGUncy88YnI+PGJyPkFic3RyYWN0 Ojxicj5PTEQ6PGJyPlRoaXMgZG9jdW1lbnQgYWxzbyBwcm92aWRlcyBndWlkYW5jZSB0byBmdXR1 cmUgbW9kZWwgd3JpdGVycywgYXMgc3VjaCwgdGhpczxicj5kb2N1bWVudCB1cGRhdGVzIFJGQzg0 MDcuPGJyPjxicj5ORVc6PGJyPlRoaXMgZG9jdW1lbnQgYWxzbyBwcm92aWRlcyBndWlkYW5jZSB0 byBmdXR1cmUgbW9kZWwgd3JpdGVyczsgYXMgc3VjaCwgdGhpczxicj5kb2N1bWVudCB1cGRhdGVz IFJGQzg0MDcuPGJyPjxicj5FTkRTPGJyPjxicj5TMS4xLCB0aXRsZTogcy91c2UgY2FzZXMgb2Yv dXNlIGNhc2VzIGZvci88YnI+PGJyPlMxLjEsIHBhcmEgMTogcy9kb2N1bWVudHMgcHJvZ3Jlc3Np b24vZG9jdW1lbnQncyBkZXZlbG9wbWVudC88YnI+PGJyPlMxLjEsIHBhcmFzIDIsIDMgYW5kIDU6 IFN1Z2dlc3Qgcy9FLmcuL0ZvciBleGFtcGxlLzxicj48YnI+UzEuMSwgcGFyYSA0OiBzL2UuZy4v ZS5nLiwvPGJyPjxicj5TMiwgcGFyYSAxOjxicj4mbmJzcDsgJm5ic3A7Jmd0OyBBbGwgdGFncyBT SE9VTEQgYmVnaW4gd2l0aCBhIHByZWZpeCBpbmRpY2F0aW5nIHdobyBvd25zIHRoZWlyIGRlZmlu aXRpb24uPGJyPjxicj5JZiBJIHJlYWQgY29ycmVjdGx5LCB0aGUgWUFORyBkZWZpbml0aW9uIGlu IHM0LjIgUkVRVUlSRVMgdGhhdCBhbGwgdGFncyBoYXZlIGE8YnI+cHJlZml4LiZuYnNwOyBGb3Ig Y2xhcml0eSwgaXQgd291bGQgYmV0dGVyIGlmIHRoaXMgcmVhZDo8YnI+Jm5ic3A7ICZuYnNwO0Fs bCB0YWdzIE1VU1QgYmVnaW4gd2l0aCBhIHByZWZpeDsgaXQgaXMgaW50ZW5kZWQgdGhhdCB0aGlz IHByZWZpeCBTSE9VTEQ8YnI+Jm5ic3A7Jm5ic3A7IFtvciBtYXliZSAnc2hvdWxkJ10gaW5kaWNh dGU8YnI+ICZuYnNwO3RoZSBvd25lcnNoaXAgb3Igb3JpZ2luYXRpb24gb2YgdGhlIGRlZmluaXRp b24uPGJyPjxicj5TMiwgcGFyYSAxOiBzL3lhbmcgdHlwZS9ZQU5HIHR5cGUvIChJIHRoaW5rKTxi cj48YnI+UzIuMjogcy9mb2xsd2luZy9mb2xsb3dpbmcvPGJyPjxicj5TMy4xLCBwYXJhIDI6PGJy Pk9MRDo8YnI+SWYgdGhlIG1vZHVsZSBkZWZpbml0aW9uIGlzIElFVEYgc3RhbmRhcmRzIHRyYWNr LCB0aGUgdGFncyBNVVNUIGFsc28gYmUgU2VjdGlvbjxicj4yLjEuIFRodXMsIG5ldyBtb2R1bGVz IGNhbiBkcml2ZSB0aGUgYWRkaXRpb24gb2YgbmV3IHN0YW5kYXJkIHRhZ3MgdG8gdGhlIElBTkE8 YnI+cmVnaXN0cnksIGFuZCB0aGUgSUFOQSByZWdpc3RyeSBjYW4gc2VydmUgYXMgYSBjaGVjayBh Z2FpbnN0IGR1cGxpY2F0aW9uLjxicj48YnI+TkVXOjxicj5JZiB0aGUgbW9kdWxlIGlzIGRlZmlu ZWQgaW4gYW4gSUVURiBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQsIHRoZSB0YWdzIE1VU1QgdXNl PGJyPnRoZSBwcmVmaXggZGVmaW5lZCBpbiBTZWN0aW9uIDIuMS4gVGh1cywgZGVmaW5pdGlvbnMg b2YgbmV3IG1vZHVsZXMgY2FuIGRyaXZlPGJyPnRoZSBhZGRpdGlvbiBvZiBuZXcgc3RhbmRhcmQg dGFncyB0byB0aGUgSUFOQSByZWdpc3RyeSBkZWZpbmVkIGluIFNlY3Rpb24gNy4yLDxicj5hbmQg dGhlIElBTkEgcmVnaXN0cnkgY2FuIHNlcnZlIGFzIGEgY2hlY2sgYWdhaW5zdCBkdXBsaWNhdGlv bi48YnI+PGJyPkVORFM8YnI+PGJyPlMzLjI6IHMvc3RhbmRhcmQvSUVURiBTdGFuZGFyZC88YnI+ PGJyPlMzLjM6IEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBpbnRyb2R1Y2UgdGhlIHRlcm0gJ21hc2tp bmcnIHVzZWQgbGF0ZXIgaW4gdGhlIFlBTkc8YnI+bW9kdWxlIGRlZmluaXRpb24uPGJyPjxicj5T NC4xOiBJIHRoaW5rIHRoaXMgdXNhZ2Ugb2YgUkZDIDgzNDAgbWFrZXMgaXQgbm9ybWF0aXZlLjxi cj48YnI+UzQuMiwgZXh0ZW5zaW9uIG1vZHVsZS10YWcgZGVmaW5pdGlvbjogVGhpcyBzaG91bGQg Y29udGFpbiBhIHBvaW50ZXIgdG8gUkZDPGJyPjgzNDIgd2hpY2ggZGlzY3Vzc2VzIHRoZSBzeXN0 ZW0gb3JpZ2luIGNvbmNlcHQuPGJyPjxicj5NYWpvciBpc3N1ZXM6PGJyPjxicj5NaW5vciBpc3N1 ZXM6PGJyPjxicj5OaXRzL2VkaXRvcmlhbCBjb21tZW50czo8YnI+PGJyPjxicj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5HZW4tYXJ0IG1haWxpbmcg bGlzdDxicj5HZW4tYXJ0QGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZ2VuLWFydDxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_4349032064753420-- From nobody Wed Mar 6 14:50:21 2019 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 1B295130DC4; Wed, 6 Mar 2019 14:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 SVnis6Mghsjj; Wed, 6 Mar 2019 14:50:05 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D9133130F70; Wed, 6 Mar 2019 14:50:04 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0117960505; Wed, 6 Mar 2019 17:50:01 -0500 (EST) From: Christian Hopps Message-Id: <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_236D6ECA-762F-4BD0-8840-F0E4856A9C15"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 17:50:00 -0500 In-Reply-To: <155183201188.27630.13798246400958114485@ietfa.amsl.com> Cc: Christian Hopps , gen-art@ietf.org, draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, netmod@ietf.org To: Datatracker on behalf of Elwyn Davies References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 22:50:08 -0000 --Apple-Mail=_236D6ECA-762F-4BD0-8840-F0E4856A9C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the review! Comments inline. > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-netmod-module-tags-06 > Reviewer: Elwyn Davies > Review Date: 2019-03-05 > IETF LC End Date: 2019-03-03 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > Almost ready. There are a couple of minor issues and a small number = of nits. > Apologies for the slightly late delivery of the review. >=20 > Major issues: > None >=20 > Minor issues: > Abstract/s1: I would judge that RFC 8407 ought to be normative since = it is > updated. RFC8407 is a BCP not a Standard though so I don't think it's appropriate = to make it normative. > S4.2: using the Netmod working group as contact point for the module = is not > future proof. I am not sure what the correct contact ought to be: = IESG? Speaking of 8407 guidelines... It gives guidance here. I will follow it. = :) "The "contact" statement MUST be present. If the module is contained in a document intended for Standards Track status, then the WG web and mailing information SHOULD be present, and the main document author or editor contact information SHOULD be present." > S7.2: [This is a thought that occurred to me...] ought there to be an = ietf: > security tag? Yes, added. > S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative 8199: Informational 8340: BCP 8407: BCP 8342: Standard, and I think your right, moved to Normative. >=20 > Nits/editorial comments: > Abstract: s/modules/module's/ >=20 > Abstract: > OLD: > This document also provides guidance to future model writers, as such, = this > document updates RFC8407. >=20 > NEW: > This document also provides guidance to future model writers; as such, = this > document updates RFC8407. >=20 > ENDS >=20 > S1.1, title: s/use cases of/use cases for/ >=20 > S1.1, para 1: s/documents progression/document's development/ >=20 > S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/ >=20 > S1.1, para 4: s/e.g./e.g.,/ Updated with your suggestions. > S2, para 1: > > All tags SHOULD begin with a prefix indicating who owns their = definition. >=20 > If I read correctly, the YANG definition in s4.2 REQUIRES that all = tags have a > prefix. For clarity, it would better if this read: > All tags MUST begin with a prefix; it is intended that this prefix = SHOULD > [or maybe 'should'] indicate > the ownership or origination of the definition. The intent was to not put the MUST on users. As the final arbiters of = tags, users should be free to do whatever they want and not have = implementations or standards superfluously block them from doing so. How = about we carry the SHOULD into the typedef in the YANG model as well? = That seems reasonable to me, i.e., typedef tag { type string { length "1..max"; pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; } description "A tag is a type 'string' value that does not include carriage return, newline or tab characters. It SHOULD begin with a standard prefix."; > S2, para 1: s/yang type/YANG type/ (I think) >=20 > S2.2: s/follwing/following/ >=20 > S3.1, para 2: > OLD: > If the module definition is IETF standards track, the tags MUST also = be Section > 2.1. Thus, new modules can drive the addition of new standard tags to = the IANA > registry, and the IANA registry can serve as a check against = duplication. >=20 > NEW: > If the module is defined in an IETF standards track document, the tags = MUST use > the prefix defined in Section 2.1. Thus, definitions of new modules = can drive > the addition of new standard tags to the IANA registry defined in = Section 7.2, > and the IANA registry can serve as a check against duplication. >=20 > ENDS >=20 > S3.2: s/standard/IETF Standard/ >=20 > S3.3: It would be useful to introduce the term 'masking' used later in = the YANG > module definition. How about: "Tags of any kind can be assigned and removed by the user using normal configuration mechanisms. In order to remove a tag from the operational datastore the user adds a matching =3Dmasked-tag=3D entry = for a given module." > S4.1: I think this usage of RFC 8340 makes it normative. Covered earlier (BCP). > S4.2, extension module-tag definition: This should contain a pointer = to RFC > 8342 which discusses the system origin concept. Added. Thanks, Chris. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_236D6ECA-762F-4BD0-8840-F0E4856A9C15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyATpgACgkQLh2DDte4 MCVzARAAiTqwvHOXrtXyKB1WCuEW5rjiJYsO8v8atcLYKAMfRiqzGxPUBbgVhFy7 Izydii3lp5XpwPJlNzQyaFKju+4EH4bjeO4W3dvTHlsQFdiTZETPxV7K1i9XydCk lp/1UAwNBSfqgLJwHDHTuoWr7WB99yVxCouIKmR5ZgrJBSKVpT8Vz+qIbNZRyIQo Ul+LrAvXp2Em/mWC34Xg1w241TECtzwxsoRg8w9CkbYARolxwuqycxBjmlzqMaTd +rI10H0doNmhPbcJp2KykOBbKxSFh0JXIYzOYpHJGBnHB+atY3N1kalith3lf1iA jODyqPHYt/DVUbeQ7AeJbgq9ZDw7s/yMRpVsehtIVae9rdrHzl3e6gvvp1NAvAxy WOftLyQKAmEs1yjChoXa68dYH7QH26n6i53NfvLNPAV3wOuHqczdhAYoelovPA0y mIGO3yqXRJWJomedmSqeyPqk+0TsrSZu0WHwN3lAiY1MRruAJBH6KcD2B9L/WJkX 0WiuvMCT51PykVhXT4DhMhKBfEnUgz3PomqVNtf28Wimt6i0d8AQaED/oca6bUk3 W7s9gK87IFF61x9i026bF7Vvt7sdyczpYm1elzPbRTyUszM4B/yO4rO+Y4ueB+dw 9SgN5FLwk1rywuZjnW+sE4wBHpuwmnKYYP2ITD3GwYOjR8AZ6Kg= =1IaK -----END PGP SIGNATURE----- --Apple-Mail=_236D6ECA-762F-4BD0-8840-F0E4856A9C15-- From nobody Wed Mar 6 14:55:34 2019 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 BEB7A13104A; Wed, 6 Mar 2019 14:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 HkQJb07yMCbw; Wed, 6 Mar 2019 14:55:17 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4C748130DC4; Wed, 6 Mar 2019 14:55:17 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7EA7760505; Wed, 6 Mar 2019 17:55:16 -0500 (EST) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5DC4D43C-68B6-4B89-860B-CD2807558CEA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 17:55:15 -0500 In-Reply-To: Cc: Christian Hopps , gen-art@ietf.org, draft-ietf-netmod-module-tags.all@ietf.org, "" , netmod@ietf.org To: Elwyn Davies References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netmod] [Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 22:55:21 -0000 --Apple-Mail=_5DC4D43C-68B6-4B89-860B-CD2807558CEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [I covered this in the previous reply I just sent, and updated the model = text in response too..] The intent here is to not restrict users of tags where we don't have to. = The prefix is only intended to avoid collision between disconnected = groups (designers, implementers and users), since users are the final = group to add/modify/use the tags we don't need to restrict them (and so = we shouldn't). Thanks, Chris. > On Mar 6, 2019, at 2:39 PM, Elwyn Davies = wrote: >=20 > Hi. >=20 > After completing my review, I realized that there was a further minor = issue related to the possible values of tag prefixes, possible values of = standardized prefixes and behaviour of implementations in the face of = tag prefixes or values that are not in the relevant registries. >=20 > I think that the text in s2 should be reinforced to emphasise that the = only prefixes that should be expected are those in the IANA registry = defined in s7.1. >=20 > Either a new section or possibly in s3 text should be added to define = the behaviour of YANG implementations that encounter tags with prefixes = that are not in the s7.1 registry and tags with prefix ietf: that are = not in the s7.2 registry. >=20 > Regards, > Elwyn Davies >=20 >=20 >=20 >=20 >=20 > Sent from Samsung tablet. >=20 > -------- Original message -------- > From: Datatracker on behalf of Elwyn Davies = > Date: 06/03/2019 00:26 (GMT+00:00) > To: gen-art@ietf.org > Cc: draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, = netmod@ietf.org > Subject: [Gen-art] Genart last call review of = draft-ietf-netmod-module-tags-06 >=20 > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-netmod-module-tags-06 > Reviewer: Elwyn Davies > Review Date: 2019-03-05 > IETF LC End Date: 2019-03-03 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > Almost ready. There are a couple of minor issues and a small number = of nits. > Apologies for the slightly late delivery of the review. >=20 > Major issues: > None >=20 > Minor issues: > Abstract/s1: I would judge that RFC 8407 ought to be normative since = it is > updated. >=20 > S4.2: using the Netmod working group as contact point for the module = is not > future proof. I am not sure what the correct contact ought to be: = IESG? >=20 > S7.2: [This is a thought that occurred to me...] ought there to be an = ietf: > security tag? >=20 > S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative >=20 > Nits/editorial comments: > Abstract: s/modules/module's/ >=20 > Abstract: > OLD: > This document also provides guidance to future model writers, as such, = this > document updates RFC8407. >=20 > NEW: > This document also provides guidance to future model writers; as such, = this > document updates RFC8407. >=20 > ENDS >=20 > S1.1, title: s/use cases of/use cases for/ >=20 > S1.1, para 1: s/documents progression/document's development/ >=20 > S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/ >=20 > S1.1, para 4: s/e.g./e.g.,/ >=20 > S2, para 1: > > All tags SHOULD begin with a prefix indicating who owns their = definition. >=20 > If I read correctly, the YANG definition in s4.2 REQUIRES that all = tags have a > prefix. For clarity, it would better if this read: > All tags MUST begin with a prefix; it is intended that this prefix = SHOULD > [or maybe 'should'] indicate > the ownership or origination of the definition. >=20 > S2, para 1: s/yang type/YANG type/ (I think) >=20 > S2.2: s/follwing/following/ >=20 > S3.1, para 2: > OLD: > If the module definition is IETF standards track, the tags MUST also = be Section > 2.1. Thus, new modules can drive the addition of new standard tags to = the IANA > registry, and the IANA registry can serve as a check against = duplication. >=20 > NEW: > If the module is defined in an IETF standards track document, the tags = MUST use > the prefix defined in Section 2.1. Thus, definitions of new modules = can drive > the addition of new standard tags to the IANA registry defined in = Section 7.2, > and the IANA registry can serve as a check against duplication. >=20 > ENDS >=20 > S3.2: s/standard/IETF Standard/ >=20 > S3.3: It would be useful to introduce the term 'masking' used later in = the YANG > module definition. >=20 > S4.1: I think this usage of RFC 8340 makes it normative. >=20 > S4.2, extension module-tag definition: This should contain a pointer = to RFC > 8342 which discusses the system origin concept. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_5DC4D43C-68B6-4B89-860B-CD2807558CEA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyAT9MACgkQLh2DDte4 MCVZ0Q//SL/Um1vunyCtaxR043Z416KOX38Vn6s/8Hk7Hg7k5neieAHN8SJUVL7d QO8wu+OCMry2oBf4ArTRjZb6qKMPFfyWrGZzQFezqXYj3Kv6Ug8x04ma3fvMVddK kQrfx50Kr6fabfxuD+GdN8HUwX7ixEdF3P+3xkVe4T3MkvLvQ120poi8IKqXsS3n CWxSOSCwdKQZXOq39snDsP/ETa4d4G6wpzdkdcboglofCcN+BlxSiqaoK79YQAVH PgcAajJQcNnVPlSwqZ6k3B6cXoLaqv8X3ca3bRXkIYS/6B64H4gPXIuXtvKh+9T2 XH5W8YrzwUuot8sdyKMekrd3I5HkagNDaqB0yhnhlJ5r2URDiiTXKX8Rv0RdHX2u ENByUrhmZ8HbWpITcZ0Uc41ZS8IlP8EVBmED8mM75YpVa/Lh5De+MCE63GRTnoc/ YOnl9o5XSEp2ARfnyNOq6CXOKrTCsv7lembeBa2nQCJrgzruNwhbfOm+W83svAZu zHIr+1xWcVyKGzskN9RyVaKaAkZeFWMpMTK5X05W34YyltZvoVJWvjkWcs0T9oZP XXWmi7piOzwPP06XvH7WL3Z0BNHVyQhuNTU7I2Ssi3u9s2960MoQeeho2wD0iclm u2ThlBoNjdLP5NDjXgMiQSmWuYT27BcEmkGQ7de4pSzYNjC8rnU= =D2ig -----END PGP SIGNATURE----- --Apple-Mail=_5DC4D43C-68B6-4B89-860B-CD2807558CEA-- From nobody Wed Mar 6 19:59:34 2019 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 C011313136F; Wed, 6 Mar 2019 19:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 qcmhxDPjSNwk; Wed, 6 Mar 2019 19:59:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1970131358; Wed, 6 Mar 2019 19:59:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4D3ACB824FD; Wed, 6 Mar 2019 19:59:09 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netmod@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190307035909.4D3ACB824FD@rfc-editor.org> Date: Wed, 6 Mar 2019 19:59:09 -0800 (PST) Archived-At: Subject: [netmod] =?utf-8?q?RFC_8528_on_YANG_Schema_Mount?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 03:59:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8528 Title: YANG Schema Mount Author: M. Bjorklund, L. Lhotka Status: Standards Track Stream: IETF Date: March 2019 Mailbox: mbj@tail-f.com, lhotka@nic.cz Pages: 28 Characters: 54347 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-schema-mount-12.txt URL: https://www.rfc-editor.org/info/rfc8528 DOI: 10.17487/RFC8528 This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module. This document is a product of the Network Modeling Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Mar 7 10:27:48 2019 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 A2FA512797D for ; Thu, 7 Mar 2019 10:27:36 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DdjATGy_dDC for ; Thu, 7 Mar 2019 10:27:35 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 CC5BB12798E for ; Thu, 7 Mar 2019 10:27:31 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id g12so12397165lfb.13 for ; Thu, 07 Mar 2019 10:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1jvXkIfIdqtrU2VZIm9YZN7Q91q3yLakpbEbkB0DFhU=; b=sKu+PAEiBwaCvec2AXOjkjMDhrnSmidswNMSd/pA6dKJ2CfB2Dgql/LtOdtNNY/XrE E9Mdqj5W+D2Hs5vvd7ot1WkWS8N4UEqU0nFqgCUwu97h5M2LXlW2Mb5kQMddpBtsr99Y UimOC3CuGaUYK7HScXFdBJYbq7xKUFw1NTiR0Um0uePPWTr0ftiZRAOpCF2Kij8L7tbZ XWG/LLVfARkoZ0qUg777Tye1O5vj8hJIDiN4FVPYMSSyXeunB1EY7iwR64rJZg9NPDf8 kwkgzKsdf8T9mUqmYhMNC4LEHPMEpcYvgBcsiDnbXMAJGJrNermeFOnVffhKyinsrmXS 9psA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1jvXkIfIdqtrU2VZIm9YZN7Q91q3yLakpbEbkB0DFhU=; b=NETqXXtyNMBwWLVT0cScrQXIZOZ+NGY+E3RhVe2yy3PcJ4AxgWPFU+H0GzKiKojSYx t1J7Zq3ICDX4Myle4T1X6+s28FKQk4iR7iVcY7dgpun3DPp08UndZ33GmchPlTxyD+aT tnWKT7vMvqMr2xN9b1MIHJN5Hk3P4R2z2wFOj1VokELDcyDZ1S/xA+SVHzvsevsi7TCo m9rtQ5txDXlG3fzNdCfwqnOjHhP7mUKQLF1EnxNw+SmamAQklt5y7onPr0GIS3A7eRlG uc/mJgRUV1Le/OtApCjGDySGpfIm4G8D/+hGb7ypZd3momJi9UaaFS+vfLIIqIwALNGE GsUg== X-Gm-Message-State: APjAAAUDUJfMtdmRiEJ+zKPfDvpdGCilY6CgfrrSY656H45Fv5CChNH/ h/lLjMN0O5hgwaXayplBrx9P/EzIPqQFbzRiRO8w1w== X-Google-Smtp-Source: APXvYqyHSG7+y5/lXG7Uk59j67P6hCQN2KedmkKkHWX1fYqhByhTUovvDb8hlRbOD+82ljbDh7SCg/AocJyKuq65cOk= X-Received: by 2002:ac2:53ab:: with SMTP id j11mr7790844lfh.49.1551983249830; Thu, 07 Mar 2019 10:27:29 -0800 (PST) MIME-Version: 1.0 References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> In-Reply-To: <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> From: Andy Bierman Date: Thu, 7 Mar 2019 10:27:18 -0800 Message-ID: To: Christian Hopps Cc: Datatracker on behalf of Elwyn Davies , General Area Review Team , draft-ietf-netmod-module-tags.all@ietf.org, IETF discussion list , NetMod WG Content-Type: multipart/alternative; boundary="0000000000004dd0b60583854262" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 18:27:37 -0000 --0000000000004dd0b60583854262 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps wrote: > Thanks for the review! Comments inline. > > > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies < > ietf-secretariat-reply@ietf.org> wrote: > > > > Reviewer: Elwyn Davies > > Review result: Almost Ready > > > .... > > If I read correctly, the YANG definition in s4.2 REQUIRES that all tags > have a > > prefix. For clarity, it would better if this read: > > All tags MUST begin with a prefix; it is intended that this prefix > SHOULD > > [or maybe 'should'] indicate > > the ownership or origination of the definition. > > The intent was to not put the MUST on users. As the final arbiters of > tags, users should be free to do whatever they want and not have > implementations or standards superfluously block them from doing so. How > about we carry the SHOULD into the typedef in the YANG model as well? That > seems reasonable to me, i.e., > > typedef tag { > type string { > length "1..max"; > pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; > } > description > "A tag is a type 'string' value that does not include carriage > return, newline or tab characters. It SHOULD begin with a > standard prefix."; > > I strongly agree that a prefix SHOULD be present, not MUST be present. I also think the 3 standard prefixes will be insufficient over time. (Having every organization on the planet except IETF share the prefix "vendor:" seems a bit short-sighted) Andy > S2, para 1: s/yang type/YANG type/ (I think) > > > > S2.2: s/follwing/following/ > > > > S3.1, para 2: > > OLD: > > If the module definition is IETF standards track, the tags MUST also be > Section > > 2.1. Thus, new modules can drive the addition of new standard tags to > the IANA > > registry, and the IANA registry can serve as a check against duplication. > > > > NEW: > > If the module is defined in an IETF standards track document, the tags > MUST use > > the prefix defined in Section 2.1. Thus, definitions of new modules can > drive > > the addition of new standard tags to the IANA registry defined in > Section 7.2, > > and the IANA registry can serve as a check against duplication. > > > > ENDS > > > > S3.2: s/standard/IETF Standard/ > > > > S3.3: It would be useful to introduce the term 'masking' used later in > the YANG > > module definition. > > How about: > > "Tags of any kind can be assigned and removed by the user using normal > configuration mechanisms. In order to remove a tag from the > operational datastore the user adds a matching =masked-tag= entry for > a given module." > > > S4.1: I think this usage of RFC 8340 makes it normative. > > Covered earlier (BCP). > > > S4.2, extension module-tag definition: This should contain a pointer to > RFC > > 8342 which discusses the system origin concept. > > Added. > > Thanks, > Chris. > > > > > Major issues: > > > > Minor issues: > > > > Nits/editorial comments: > > > > > > _______________________________________________ > > 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 > --0000000000004dd0b60583854262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 2:51 PM Christ= ian Hopps <chopps@chopps.org>= ; wrote:
Thanks = for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <= ietf-s= ecretariat-reply@ietf.org> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
....
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tag= s have a
> prefix.=C2=A0 For clarity, it would better if this read:
>=C2=A0 =C2=A0 All tags MUST begin with a prefix; it is intended that th= is prefix SHOULD
>=C2=A0 =C2=A0[or maybe 'should'] indicate
>=C2=A0 the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags,= users should be free to do whatever they want and not have implementations= or standards superfluously block them from doing so. How about we carry th= e SHOULD into the typedef in the YANG model as well? That seems reasonable = to me, i.e.,

=C2=A0 typedef tag {
=C2=A0 =C2=A0 type string {
=C2=A0 =C2=A0 =C2=A0 length "1..max";
=C2=A0 =C2=A0 =C2=A0 pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "A tag is a type 'string' value that does= not include carriage
=C2=A0 =C2=A0 =C2=A0 =C2=A0return, newline or tab characters. It SHOULD beg= in with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0standard prefix.";




I strong= ly agree that a prefix SHOULD be present, not MUST be present.
I = also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix &qu= ot;vendor:"
seems a bit short-sighted)

<= div>
Andy

> S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also b= e Section
> 2.1. Thus, new modules can drive the addition of new standard tags to = the IANA
> registry, and the IANA registry can serve as a check against duplicati= on.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags= MUST use
> the prefix defined in Section 2.1. Thus, definitions of new modules ca= n drive
> the addition of new standard tags to the IANA registry defined in Sect= ion 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used = later in the YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal=
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =3Dmasked-tag=3D entry for a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer t= o RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> _______________________________________________
> 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
--0000000000004dd0b60583854262-- From nobody Thu Mar 7 10:37:54 2019 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 415D312796B for ; Thu, 7 Mar 2019 10:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SORTED_RECIPS=2.499, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.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 ybBNAevfqfoz for ; Thu, 7 Mar 2019 10:37:38 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 BF4FF130F08 for ; Thu, 7 Mar 2019 10:37:35 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id l66so17352094itg.3 for ; Thu, 07 Mar 2019 10:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U6x1xC5KpcvLqxF2hruf0TZUQCH7cB4Jqt4RpZWNZCA=; b=rxRZtVpVdZ+Rhnrbk5FWoUN5KJHVHgIcWbhtCE42wIdGqKcRCmwpwGo6VCurcgm1Te /vy0ejX63NvUFk7ydEu/FtD/1Sik/uLMpGLVBulyY8yWum0dKZR0jftK6jcK5ve6sFuV c1Ng+pRpvFQ0b4smqXTI7hKU+dX3/oW3fbbpWKM4kFLKI01isnDGvmGqIOMjjuTeEwEd mJsxrf9uvtZ9dmM/cnxMQHMi9ae5yIv3k7Ufri+Gi0zD6QpGvAAUErYjl9e9waY0EsO6 0MNY/8DcpjIaTrPkneklT94MUH7DJctRw22UjPtZUNGdgrGTotljfUSK27uKX5vhUFNG Cn/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U6x1xC5KpcvLqxF2hruf0TZUQCH7cB4Jqt4RpZWNZCA=; b=tybZuzaEuMTD8D0jIF70hpWa8X5LAZVM+tizLj5k6Ze/uiXkuNwaRlt6MkYqI3x8lL D7ITkQf5zeNYtlnWU/hvh8l1VVwQC2Gz6ccfFKlmqgCWLw+yfuHBIE8y2m37Ezoo1hMy ebRp0UTzPOi7Vy0nPoJol7FkuhuQLilLINZR0itGYLB/AGLTYWWkvcuhkfBmFq9nlqsh Y9Yw70tieLhZfB4gcOa3gnt4Ld1tYytvrYIMDIr6hvVPQF255yV9mpU+rndha66vHSvV 1RjZl8uHbyF0ZbJqdRlV1HMrrlZTfGCYyBvpK3d8PjuSRk2KWmDXPcKuH8QHx2YGxsrO YCGw== X-Gm-Message-State: APjAAAW4bsbY5EW9+OCaRZwJnfcap5zF9UInimatMeNlGhBNZcpUqFBh cEMpWgzuxNZERTm0b0z4OlLhHmBzMnYDJikfzCkdsA== X-Google-Smtp-Source: APXvYqy4SXaieXg0mNx60NXADyosl1N+g1dClzoK53Ldbd5JynkgbMhXwdcY6XrwS2rAMEb2G4K0+MOoZ7oGqCaJLXc= X-Received: by 2002:a24:38c:: with SMTP id e134mr6018636ite.24.1551983854834; Thu, 07 Mar 2019 10:37:34 -0800 (PST) MIME-Version: 1.0 References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> In-Reply-To: From: William Lupton Date: Thu, 7 Mar 2019 18:37:23 +0000 Message-ID: To: Andy Bierman Cc: Christian Hopps , draft-ietf-netmod-module-tags.all@ietf.org, General Area Review Team , Datatracker on behalf of Elwyn Davies , IETF discussion list , NetMod WG Content-Type: multipart/alternative; boundary="0000000000005da58805838566c6" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 18:37:45 -0000 --0000000000005da58805838566c6 Content-Type: text/plain; charset="UTF-8" This remark might be out of context (I haven't been following the details) but this reference to prefixes makes me wonder whether there's any way that registered URN namespaces could be regarded as valid prefixes. https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml On Thu, 7 Mar 2019 at 18:28, Andy Bierman wrote: > > > On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps wrote: > >> Thanks for the review! Comments inline. >> >> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies < >> ietf-secretariat-reply@ietf.org> wrote: >> > >> > Reviewer: Elwyn Davies >> > Review result: Almost Ready >> > >> .... >> > If I read correctly, the YANG definition in s4.2 REQUIRES that all tags >> have a >> > prefix. For clarity, it would better if this read: >> > All tags MUST begin with a prefix; it is intended that this prefix >> SHOULD >> > [or maybe 'should'] indicate >> > the ownership or origination of the definition. >> >> The intent was to not put the MUST on users. As the final arbiters of >> tags, users should be free to do whatever they want and not have >> implementations or standards superfluously block them from doing so. How >> about we carry the SHOULD into the typedef in the YANG model as well? That >> seems reasonable to me, i.e., >> >> typedef tag { >> type string { >> length "1..max"; >> pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; >> } >> description >> "A tag is a type 'string' value that does not include carriage >> return, newline or tab characters. It SHOULD begin with a >> standard prefix."; >> >> > > > I strongly agree that a prefix SHOULD be present, not MUST be present. > I also think the 3 standard prefixes will be insufficient over time. > (Having every organization on the planet except IETF share the prefix > "vendor:" > seems a bit short-sighted) > > > Andy > > > S2, para 1: s/yang type/YANG type/ (I think) >> > >> > S2.2: s/follwing/following/ >> > >> > S3.1, para 2: >> > OLD: >> > If the module definition is IETF standards track, the tags MUST also be >> Section >> > 2.1. Thus, new modules can drive the addition of new standard tags to >> the IANA >> > registry, and the IANA registry can serve as a check against >> duplication. >> > >> > NEW: >> > If the module is defined in an IETF standards track document, the tags >> MUST use >> > the prefix defined in Section 2.1. Thus, definitions of new modules can >> drive >> > the addition of new standard tags to the IANA registry defined in >> Section 7.2, >> > and the IANA registry can serve as a check against duplication. >> > >> > ENDS >> > >> > S3.2: s/standard/IETF Standard/ >> > >> > S3.3: It would be useful to introduce the term 'masking' used later in >> the YANG >> > module definition. >> >> How about: >> >> "Tags of any kind can be assigned and removed by the user using normal >> configuration mechanisms. In order to remove a tag from the >> operational datastore the user adds a matching =masked-tag= entry for >> a given module." >> >> > S4.1: I think this usage of RFC 8340 makes it normative. >> >> Covered earlier (BCP). >> >> > S4.2, extension module-tag definition: This should contain a pointer to >> RFC >> > 8342 which discusses the system origin concept. >> >> Added. >> >> Thanks, >> Chris. >> >> > >> > Major issues: >> > >> > Minor issues: >> > >> > Nits/editorial comments: >> > >> > >> > _______________________________________________ >> > 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 > --0000000000005da58805838566c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This remark might be out of context (I ha= ven't been following the details) but this reference to prefixes makes = me wonder whether there's any way that registered URN namespaces could = be regarded as valid prefixes.=C2=A0https://www.iana.org/assignments/= urn-namespaces/urn-namespaces.xhtml

On Thu, 7 Mar 2019 at 18:28, A= ndy Bierman <andy@yumaworks.com> wrote:


On Wed, Mar 6, 2019 at 2:51 PM Christian= Hopps <chopps@ch= opps.org> wrote:
Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <= ietf-s= ecretariat-reply@ietf.org> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
....
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tag= s have a
> prefix.=C2=A0 For clarity, it would better if this read:
>=C2=A0 =C2=A0 All tags MUST begin with a prefix; it is intended that th= is prefix SHOULD
>=C2=A0 =C2=A0[or maybe 'should'] indicate
>=C2=A0 the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags,= users should be free to do whatever they want and not have implementations= or standards superfluously block them from doing so. How about we carry th= e SHOULD into the typedef in the YANG model as well? That seems reasonable = to me, i.e.,

=C2=A0 typedef tag {
=C2=A0 =C2=A0 type string {
=C2=A0 =C2=A0 =C2=A0 length "1..max";
=C2=A0 =C2=A0 =C2=A0 pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "A tag is a type 'string' value that does= not include carriage
=C2=A0 =C2=A0 =C2=A0 =C2=A0return, newline or tab characters. It SHOULD beg= in with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0standard prefix.";




I strong= ly agree that a prefix SHOULD be present, not MUST be present.
I = also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix &qu= ot;vendor:"
seems a bit short-sighted)

<= div>
Andy

> S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also b= e Section
> 2.1. Thus, new modules can drive the addition of new standard tags to = the IANA
> registry, and the IANA registry can serve as a check against duplicati= on.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags= MUST use
> the prefix defined in Section 2.1. Thus, definitions of new modules ca= n drive
> the addition of new standard tags to the IANA registry defined in Sect= ion 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used = later in the YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal=
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =3Dmasked-tag=3D entry for a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer t= o RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> _______________________________________________
> 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
--0000000000005da58805838566c6-- From nobody Thu Mar 7 10:42:52 2019 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 4F7CC12716C; Thu, 7 Mar 2019 10:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 1NhRtDaXdHWx; Thu, 7 Mar 2019 10:42:49 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E9126C87; Thu, 7 Mar 2019 10:42:49 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 4C2B560510; Thu, 7 Mar 2019 13:42:48 -0500 (EST) References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Andy Bierman Cc: Christian Hopps , Datatracker on behalf of Elwyn Davies , General Area Review Team , draft-ietf-netmod-module-tags.all@ietf.org, IETF discussion list , NetMod WG In-reply-to: Date: Thu, 07 Mar 2019 13:42:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 18:42:50 -0000 --=-=-= Content-Type: text/plain; format=flowed Andy Bierman writes: > I strongly agree that a prefix SHOULD be present, not MUST be present. > I also think the 3 standard prefixes will be insufficient over time. > (Having every organization on the planet except IETF share the prefix > "vendor:" > seems a bit short-sighted) Sounds like you are a strong supporter of the included prefixes registry as well then. :) Thanks, Chris. > > > Andy --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyBZicACgkQLh2DDte4 MCW9fQ//dP93knCna+Am+vf74hnsC7lbr8X6ZpUM3b1MA30GMsm8jzamN7KHwgHR dTQQpkAL5jlxARNq1StTGCn2gqqErRz/fSnWZgzP0EmSU/DQdWPLJT5YcUoRFvE9 Tf1hKnu7kvRvsN08Miljr9ApbykRLpiouNvtCVN5Ud3JDnqwojXvL5AMZPIgCbv7 nI24olmuU4lrFBLN1UhGe5yUdmcRLi3cReh6qXCw8J3R6O0kCknvk082tZ5cEunl 0HgfYwU9J/TZLoxeJNJ8GRAM+KYmrcyaXV6JYvQnjykDXzULPpqEehAZ5xTpGLQB hbAipnNcwbbvt/x1pD4e4Kq4K16x0sO5+OiaVkfvys7mVnKEQkt+zHRaNHzx7ZBC wAYkNZIV0929bLIwC9hg1xuTpVEd1Ivm5pUNVoHGprtTItGyiv0yjlqap0YemOhr zOBcIHi4lwNaKpGOv3DuVVOLF9B+AXPoxoETuu+vreuICYvCc4BYlDEfeAIM2ycf 71HjgeSIlJN9oDzSLa+QNiNXG/plwuyW49RZftEKpU89sBiGphaZlFESeTtlpdev WxbtEmJg2Wl5b7HhOt91WL4mWImetyLDSYhFh1rRHg27t1sD61puGIuMbasxcWXd 157IgUpjcIEED8b7Bxal6xh6s5zELueMp/IVuuZ1oPq9BB023a8= =qVtI -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 7 10:44:34 2019 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 2D4131279A8 for ; Thu, 7 Mar 2019 10:44:33 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MvX5CSHbdUAs for ; Thu, 7 Mar 2019 10:44:30 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 2E6F212795E for ; Thu, 7 Mar 2019 10:44:30 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id d26so12460676lfa.1 for ; Thu, 07 Mar 2019 10:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tjeO3jAD85NokzAEl7st3AVA2KdpBMgw1uVJe75BKtc=; b=lxC559AvsM4J5WozC2Rn4mSZGGWrOSMjNkggHlyk/Dyk9C5GksnK8SSSa8sLuvkfmZ LpbDJP9tzrLn31jqLA6SEtzOSODNEQWBsYXzf4fJlIWeznvg+uqK87d669t8MpPWyRGE RKhyH+5kcGgmIDizVhOOHDSQ8VepD9C9F4bfi039gymh3tFol4JIJEFoQC55qrLPILq7 Y2L8+xXLQU6BQE3dlbfEu1WVjszmm3U9da2Bx2QF8G2qWkS1Vk2peZo4K/movXkpqXYU lRezy+5gXCy92c8ggbLEUfjOiMG5woxXpqOejcwWLqT6obLxxzPZtk0P39bgklDkc4XI kbxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tjeO3jAD85NokzAEl7st3AVA2KdpBMgw1uVJe75BKtc=; b=Hh2lu8wtKid7M8Pu5EMOU+1O/nWHZjWgHIowxLkcNufmQjUMYcssmwMjd+R3gGg8zM fxPYNyQkq2jPyoA1BOXuVrP+OYT3EspLegp0NgjNqPw9eJItC1IGeyVXfzL9dWswthvw LM7DJTYzhK2f6c2vtaIBPBi9tl+JlIVjmnz9pu95F1t2M/VynEKpX30EEGMRUPf+qS8A kLs1Mf8Q88/AHsXko88v6kRKzfJk1ZT7XzFKaw4sR5JuzXKpdPfi8JeBvcWiuFw6mN1S W5wWg9op9oix7qk8fYq6Y3HQf+HDkMc5+mcMCo6qn/CbVOCpsgPva+rNe+onfYAGRcaH AaMg== X-Gm-Message-State: APjAAAWtbqSw2ba19dP8jGSLvaH5fuunyyRkW6W405cmv0zoDDuMqEf1 Jc3X+hwZBtJEB14mYBGU3R1qsn1O4wRXlLF5GuUcgg== X-Google-Smtp-Source: APXvYqw56BB4R2ugy2PrTIHQpxpyeu0VIGbqlxAvizPt4cCJzNUX99scstwb3cLSte7L7R/EFzxHRNCPuCec1fkdZd8= X-Received: by 2002:ac2:53ab:: with SMTP id j11mr7826612lfh.49.1551984268140; Thu, 07 Mar 2019 10:44:28 -0800 (PST) MIME-Version: 1.0 References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> In-Reply-To: From: Andy Bierman Date: Thu, 7 Mar 2019 10:44:16 -0800 Message-ID: To: William Lupton Cc: Christian Hopps , draft-ietf-netmod-module-tags.all@ietf.org, General Area Review Team , Datatracker on behalf of Elwyn Davies , IETF discussion list , NetMod WG Content-Type: multipart/alternative; boundary="000000000000fff3730583857e1c" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 18:44:33 -0000 --000000000000fff3730583857e1c Content-Type: text/plain; charset="UTF-8" On Thu, Mar 7, 2019 at 10:37 AM William Lupton wrote: > This remark might be out of context (I haven't been following the details) > but this reference to prefixes makes me wonder whether there's any way that > registered URN namespaces could be regarded as valid prefixes. > https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml > looks like a great solution and would be less duplication of registries Andy > > On Thu, 7 Mar 2019 at 18:28, Andy Bierman wrote: > >> >> >> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps wrote: >> >>> Thanks for the review! Comments inline. >>> >>> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies < >>> ietf-secretariat-reply@ietf.org> wrote: >>> > >>> > Reviewer: Elwyn Davies >>> > Review result: Almost Ready >>> > >>> .... >>> > If I read correctly, the YANG definition in s4.2 REQUIRES that all >>> tags have a >>> > prefix. For clarity, it would better if this read: >>> > All tags MUST begin with a prefix; it is intended that this prefix >>> SHOULD >>> > [or maybe 'should'] indicate >>> > the ownership or origination of the definition. >>> >>> The intent was to not put the MUST on users. As the final arbiters of >>> tags, users should be free to do whatever they want and not have >>> implementations or standards superfluously block them from doing so. How >>> about we carry the SHOULD into the typedef in the YANG model as well? That >>> seems reasonable to me, i.e., >>> >>> typedef tag { >>> type string { >>> length "1..max"; >>> pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; >>> } >>> description >>> "A tag is a type 'string' value that does not include carriage >>> return, newline or tab characters. It SHOULD begin with a >>> standard prefix."; >>> >>> >> >> >> I strongly agree that a prefix SHOULD be present, not MUST be present. >> I also think the 3 standard prefixes will be insufficient over time. >> (Having every organization on the planet except IETF share the prefix >> "vendor:" >> seems a bit short-sighted) >> >> >> Andy >> >> > S2, para 1: s/yang type/YANG type/ (I think) >>> > >>> > S2.2: s/follwing/following/ >>> > >>> > S3.1, para 2: >>> > OLD: >>> > If the module definition is IETF standards track, the tags MUST also >>> be Section >>> > 2.1. Thus, new modules can drive the addition of new standard tags to >>> the IANA >>> > registry, and the IANA registry can serve as a check against >>> duplication. >>> > >>> > NEW: >>> > If the module is defined in an IETF standards track document, the tags >>> MUST use >>> > the prefix defined in Section 2.1. Thus, definitions of new modules >>> can drive >>> > the addition of new standard tags to the IANA registry defined in >>> Section 7.2, >>> > and the IANA registry can serve as a check against duplication. >>> > >>> > ENDS >>> > >>> > S3.2: s/standard/IETF Standard/ >>> > >>> > S3.3: It would be useful to introduce the term 'masking' used later in >>> the YANG >>> > module definition. >>> >>> How about: >>> >>> "Tags of any kind can be assigned and removed by the user using normal >>> configuration mechanisms. In order to remove a tag from the >>> operational datastore the user adds a matching =masked-tag= entry for >>> a given module." >>> >>> > S4.1: I think this usage of RFC 8340 makes it normative. >>> >>> Covered earlier (BCP). >>> >>> > S4.2, extension module-tag definition: This should contain a pointer >>> to RFC >>> > 8342 which discusses the system origin concept. >>> >>> Added. >>> >>> Thanks, >>> Chris. >>> >>> > >>> > Major issues: >>> > >>> > Minor issues: >>> > >>> > Nits/editorial comments: >>> > >>> > >>> > _______________________________________________ >>> > 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 >> > --000000000000fff3730583857e1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2019 at 10:37 AM Willi= am Lupton <wlupton@broadb= and-forum.org> wrote:
This remark might be out of = context (I haven't been following the details) but this reference to pr= efixes makes me wonder whether there's any way that registered URN name= spaces could be regarded as valid prefixes.=C2=A0ht= tps://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml


looks like a great s= olution and would be less duplication of registries

Andy


=C2=A0

On Thu, 7 Mar 2019 at 18:28, Andy Bierman <= ;andy@yumaworks.com= > wrote:
=


=
On Wed, Mar 6, 2019 at 2:51 PM Christ= ian Hopps <chopps= @chopps.org> wrote:
Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <= ietf-s= ecretariat-reply@ietf.org> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
....
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tag= s have a
> prefix.=C2=A0 For clarity, it would better if this read:
>=C2=A0 =C2=A0 All tags MUST begin with a prefix; it is intended that th= is prefix SHOULD
>=C2=A0 =C2=A0[or maybe 'should'] indicate
>=C2=A0 the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags,= users should be free to do whatever they want and not have implementations= or standards superfluously block them from doing so. How about we carry th= e SHOULD into the typedef in the YANG model as well? That seems reasonable = to me, i.e.,

=C2=A0 typedef tag {
=C2=A0 =C2=A0 type string {
=C2=A0 =C2=A0 =C2=A0 length "1..max";
=C2=A0 =C2=A0 =C2=A0 pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "A tag is a type 'string' value that does= not include carriage
=C2=A0 =C2=A0 =C2=A0 =C2=A0return, newline or tab characters. It SHOULD beg= in with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0standard prefix.";




I strong= ly agree that a prefix SHOULD be present, not MUST be present.
I = also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix &qu= ot;vendor:"
seems a bit short-sighted)

<= div>
Andy

> S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also b= e Section
> 2.1. Thus, new modules can drive the addition of new standard tags to = the IANA
> registry, and the IANA registry can serve as a check against duplicati= on.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags= MUST use
> the prefix defined in Section 2.1. Thus, definitions of new modules ca= n drive
> the addition of new standard tags to the IANA registry defined in Sect= ion 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used = later in the YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal=
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =3Dmasked-tag=3D entry for a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer t= o RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> _______________________________________________
> 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
--000000000000fff3730583857e1c-- From nobody Thu Mar 7 10:48:38 2019 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 E4D60127988 for ; Thu, 7 Mar 2019 10:48:25 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6cbFDp_HQ-d for ; Thu, 7 Mar 2019 10:48:24 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 CDA9D127983 for ; Thu, 7 Mar 2019 10:48:18 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id u2so5516339lfd.4 for ; Thu, 07 Mar 2019 10:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JME2Fko8s4pff8qe9p55jADrUNlj1Egf/n507YOauCY=; b=RF1Fc8YKECWWsUCrzp3X0ebNTQ3qbp64U7F/87J6sbC8Swk+MiBLHTTDvWvPGrByWj 3cbN4HKRcIo0N6W4Wd56ZtaCasxtDV9XOrizTcFx9C/ieg5m9MnC4PZP9f8awb4Lj2+y KqfklQVidc6LzY5JOrRrIc9ocCOlELJXQPUyywDOGDljf7WGprbqfKg+HBY3hflDgNFe oXfGWxg5OvLT6VvroxMHRWiPH21tiNBOw+3742j+zy3LedablQD7pMFtf/3/gD8zA2j4 8GFvdyZCqYweWv3FKOIBdCocKcZHxiD/EQj7wfFOfM6IHmHhad0WZeXFX6OehuRf1kzl u/MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JME2Fko8s4pff8qe9p55jADrUNlj1Egf/n507YOauCY=; b=U6yUwZSpwXVLcahLG/g7IzxC5e7hO8ePtXfQwsmKSZ7FcaaRHhigk3V8/rjsiG9dFF L3kmrnYp/4NKaAuQChU0NqI7FvPZwBO+IkOl1rTVuh9nlFAqN5QVgBkGvnMsJ5dNPuCl CyQ65ACE09nkm3I2a1uRxarRGVKmJvH6vFaWJuF2ifXgV2SgV556kPBCqvbXIjgGq4+F owSB+YqsmY8nA6wCRUhzaY47HxzX9PgqKL1ZTQnsXJpgDpNKMuR93pBQfIzOw9V3v+Id 2U2/GGWcQPszB58SxDV/xD5WDzMxaq/Z2d18svM8EK2jmPnSZrLNAxqCyCoXt4uLQ9YF 1qjw== X-Gm-Message-State: APjAAAWeo9ORStyGC43HQYv6aeTZiMTp5a6crmYT1y1HaFWT1TNdY8vk 5o2xhRt3fgmF7wmu2Ozh/LBHYcSC6Ux4B123WGyhLw== X-Google-Smtp-Source: APXvYqwUpxSgQ14W1hxjulbxn+YJzXWTpEF3WxSIcmKnSS28qCe+EykF3AehYfv2hjJUnHGCI9q0eFJYn2HIpgSmM9Y= X-Received: by 2002:ac2:41c4:: with SMTP id d4mr4588833lfi.104.1551984496756; Thu, 07 Mar 2019 10:48:16 -0800 (PST) MIME-Version: 1.0 References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> In-Reply-To: From: Andy Bierman Date: Thu, 7 Mar 2019 10:48:05 -0800 Message-ID: To: Christian Hopps Cc: Datatracker on behalf of Elwyn Davies , General Area Review Team , draft-ietf-netmod-module-tags.all@ietf.org, IETF discussion list , NetMod WG Content-Type: multipart/alternative; boundary="000000000000a0663a0583858c25" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 18:48:27 -0000 --000000000000a0663a0583858c25 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 7, 2019 at 10:42 AM Christian Hopps wrote: > > Andy Bierman writes: > > > I strongly agree that a prefix SHOULD be present, not MUST be present. > > I also think the 3 standard prefixes will be insufficient over time. > > (Having every organization on the planet except IETF share the prefix > > "vendor:" > > seems a bit short-sighted) > > Sounds like you are a strong supporter of the included prefixes registry > as well then. :) > not really -- in my server implementation the prefix is ignored -- it is just part of a unique string. It is supposed to help clients create unique tags. It is subjective whether vendor:bbf-routing is better than bbf:routing (for example) Andy > > Thanks, > Chris. > > > > > > > Andy > --000000000000a0663a0583858c25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2019 at 10:42 AM Chris= tian Hopps <chopps@chopps.org&g= t; wrote:

Andy Bierman <an= dy@yumaworks.com> writes:

> I strongly agree that a prefix SHOULD be present, not MUST be present.=
> I also think the 3 standard prefixes will be insufficient over time. > (Having every organization on the planet except IETF share the prefix<= br> > "vendor:"
> seems a bit short-sighted)

Sounds like you are a strong supporter of the included prefixes registry as= well then. :)

not really -- in my serv= er implementation the prefix is ignored -- it is just part of
a u= nique string. It is supposed to help clients create unique tags.
= It is subjective whether vendor:bbf-routing is better than bbf:routing (for= example)

Andy

=C2=A0

Thanks,
Chris.

>
>
> Andy
--000000000000a0663a0583858c25-- From nobody Thu Mar 7 11:02:53 2019 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 A7B84129B88; Thu, 7 Mar 2019 11:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 fY80fgZRlQu5; Thu, 7 Mar 2019 11:02:41 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB14128B01; Thu, 7 Mar 2019 11:02:41 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 3C58360510; Thu, 7 Mar 2019 14:02:40 -0500 (EST) References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Andy Bierman Cc: William Lupton , Christian Hopps , draft-ietf-netmod-module-tags.all@ietf.org, General Area Review Team , Datatracker on behalf of Elwyn Davies , IETF discussion list , NetMod WG In-reply-to: Date: Thu, 07 Mar 2019 14:02:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 19:02:44 -0000 --=-=-= Content-Type: text/plain; format=flowed We already have a reviewed and approved prefixes registry. Given nothing is broken here, and the current solution has been reviewed for 2+ years, and with careful consideration approved by the working group, this does not seem like change that should be considered (or perhaps even suggested) at this very late point in the process. Thanks, Chris. Andy Bierman writes: > On Thu, Mar 7, 2019 at 10:37 AM William Lupton > wrote: > >> This remark might be out of context (I haven't been following the details) >> but this reference to prefixes makes me wonder whether there's any way that >> registered URN namespaces could be regarded as valid prefixes. >> https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml >> > > > looks like a great solution and would be less duplication of registries > > Andy > > > > >> >> On Thu, 7 Mar 2019 at 18:28, Andy Bierman wrote: >> >>> >>> >>> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps wrote: >>> >>>> Thanks for the review! Comments inline. >>>> >>>> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies < >>>> ietf-secretariat-reply@ietf.org> wrote: >>>> > >>>> > Reviewer: Elwyn Davies >>>> > Review result: Almost Ready >>>> > >>>> .... >>>> > If I read correctly, the YANG definition in s4.2 REQUIRES that all >>>> tags have a >>>> > prefix. For clarity, it would better if this read: >>>> > All tags MUST begin with a prefix; it is intended that this prefix >>>> SHOULD >>>> > [or maybe 'should'] indicate >>>> > the ownership or origination of the definition. >>>> >>>> The intent was to not put the MUST on users. As the final arbiters of >>>> tags, users should be free to do whatever they want and not have >>>> implementations or standards superfluously block them from doing so. How >>>> about we carry the SHOULD into the typedef in the YANG model as well? That >>>> seems reasonable to me, i.e., >>>> >>>> typedef tag { >>>> type string { >>>> length "1..max"; >>>> pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; >>>> } >>>> description >>>> "A tag is a type 'string' value that does not include carriage >>>> return, newline or tab characters. It SHOULD begin with a >>>> standard prefix."; >>>> >>>> >>> >>> >>> I strongly agree that a prefix SHOULD be present, not MUST be present. >>> I also think the 3 standard prefixes will be insufficient over time. >>> (Having every organization on the planet except IETF share the prefix >>> "vendor:" >>> seems a bit short-sighted) >>> >>> >>> Andy >>> >>> > S2, para 1: s/yang type/YANG type/ (I think) >>>> > >>>> > S2.2: s/follwing/following/ >>>> > >>>> > S3.1, para 2: >>>> > OLD: >>>> > If the module definition is IETF standards track, the tags MUST also >>>> be Section >>>> > 2.1. Thus, new modules can drive the addition of new standard tags to >>>> the IANA >>>> > registry, and the IANA registry can serve as a check against >>>> duplication. >>>> > >>>> > NEW: >>>> > If the module is defined in an IETF standards track document, the tags >>>> MUST use >>>> > the prefix defined in Section 2.1. Thus, definitions of new modules >>>> can drive >>>> > the addition of new standard tags to the IANA registry defined in >>>> Section 7.2, >>>> > and the IANA registry can serve as a check against duplication. >>>> > >>>> > ENDS >>>> > >>>> > S3.2: s/standard/IETF Standard/ >>>> > >>>> > S3.3: It would be useful to introduce the term 'masking' used later in >>>> the YANG >>>> > module definition. >>>> >>>> How about: >>>> >>>> "Tags of any kind can be assigned and removed by the user using normal >>>> configuration mechanisms. In order to remove a tag from the >>>> operational datastore the user adds a matching =masked-tag= entry for >>>> a given module." >>>> >>>> > S4.1: I think this usage of RFC 8340 makes it normative. >>>> >>>> Covered earlier (BCP). >>>> >>>> > S4.2, extension module-tag definition: This should contain a pointer >>>> to RFC >>>> > 8342 which discusses the system origin concept. >>>> >>>> Added. >>>> >>>> Thanks, >>>> Chris. >>>> >>>> > >>>> > Major issues: >>>> > >>>> > Minor issues: >>>> > >>>> > Nits/editorial comments: >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyBas8ACgkQLh2DDte4 MCVeqA/+P/JlqXzDWtH/4tYYRhKxI9efdO7/jFYbh5iOFaO8RTOE3vMz/9UuI46V YPHYlEes/FJ/8Vqx9TVJtwaj0pfJU8p2wIiWPqlw0QuC5a2ONY9CIS6tVr5Jc8On DCNwCg2pfn+V0j8bboCsPp9Hc3ad1Q3uvD9i4410KwPe+dAINdw6J1pC90duhzQK yubV9ZNvTROI+uDdq9TYHSu52Y6lSJtysrWMW8iX9RSq4e3fNvIYD5K1KYoCn63f QxuZgaf2r7uJSdfj843YGHVGi3VqqQZ8KhYfqvElobf3PAEVxwMJ9++c1/PL73LV FLrGxVOXtlFsRNGntO/LpZktR+1/7rL7sseOsxt684Axv5ZSr0Gvy22Ml38qk/id sPUz9sGOe23Yqa9lgkjNc6kY5gNtA9VebCD2NWlYOVJj3IXOAp4EEr4xkuFSWmWw fAivU3Hfg9SfKWs8oZlN1gUJUNPgf/qbtu2pPi3YFjGrtpjOsC8VqjEiX6wjvUW2 Z8Y3g6tBmpckrwx3n20Ha4YT98x/QTwXFv8R5ACxeJUVUssoNvD+aG+KARNBrLfZ CXws+W/Lo3fLLB7Ii4IZF94UOBXJFXauB+ALPy96INxgRrC+JnuVyOAA0AFcFebr 8oDn1ODytMQZvzllcOCTk3cdbY3K4YuV/Rw2ifxh+i5SuvSK3Xw= =gz0k -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 7 11:15:13 2019 Return-Path: <010001695994a2b4-cf449680-5a3e-4500-83d6-8268450726f3-000000@amazonses.watsen.net> 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 A31BF126C87 for ; Thu, 7 Mar 2019 11:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 gE33l-Dm3hBQ for ; Thu, 7 Mar 2019 11:15:09 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA78F1277D9 for ; Thu, 7 Mar 2019 11:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551986107; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=YCnO1um+JXNJnLjDwgMX6RTQPc/bqZCOlqwZZKx30Gg=; b=Ws45HF/X4f7If0IenrFyJeO8Fbk1BOD4fqC5dhWpUw24TMpbn5dxwVkgFpTkuV7d TTaStFqa1muSdYWNFOsfPVUXmTGBuWIMK/zaWUzjVYt3QCgUVRdbEjybqeC7j2SFsq4 3buUStuYtf80B2JACLvnIUBO9J1s+GunnXgpun9k= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <010001695994a2b4-cf449680-5a3e-4500-83d6-8268450726f3-000000@email.amazonses.com> Date: Thu, 7 Mar 2019 19:15:07 +0000 To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.07-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] YANG-next Selection Discussion in Prague X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 19:15:12 -0000 For those interested in the YANG-next, there are three upcoming events: 1) a 2-hour virtual interim on Mar 20 (the IESG-Secretary will send = out the invite shortly) 2) a 10-15 minute presentation on Monday, Mar 25 in NETMOD session = #1 3) a 2-hour deep-dive meeting on Wednesday, Mar 27 (details below) YANG-next Deep Dive Meeting: ------------------------------------------ Wednesday, Mar 27, 15:00-17:00 in Karlin 3 (link to map [1]) Occupancy: up to 60 attendees=20 Configuration: theater=20 Projector: yes [1] = https://datatracker.ietf.org/meeting/104/floor-plan?room=3Dkarlin-3#mezzan= ine Kent // as co-chair From nobody Thu Mar 7 11:34:31 2019 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 CACB9126DFA; Thu, 7 Mar 2019 11:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 LF3NVQinkwZG; Thu, 7 Mar 2019 11:34:27 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9771228B7; Thu, 7 Mar 2019 11:34:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6B233BE1; Thu, 7 Mar 2019 20:34:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id AK-mWPCE1WaU; Thu, 7 Mar 2019 20:34:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 Mar 2019 20:34:23 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 538402007F; Thu, 7 Mar 2019 20:34:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id SMpgyQNHPvSV; Thu, 7 Mar 2019 20:34:23 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id D1B042007A; Thu, 7 Mar 2019 20:34:22 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 7 Mar 2019 20:34:22 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 084043006FF611; Thu, 7 Mar 2019 20:34:21 +0100 (CET) Date: Thu, 7 Mar 2019 20:34:21 +0100 From: Juergen Schoenwaelder To: Christian Hopps CC: Andy Bierman , NetMod WG , General Area Review Team , Message-ID: <20190307193421.6qbdrspgl2eujlnz@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Christian Hopps , Andy Bierman , NetMod WG , General Area Review Team , draft-ietf-netmod-module-tags.all@ietf.org References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 19:34:30 -0000 On Thu, Mar 07, 2019 at 02:02:39PM -0500, Christian Hopps wrote: > > We already have a reviewed and approved prefixes registry. > > Given nothing is broken here, and the current solution has been reviewed for 2+ years, and with careful consideration approved by the working group, this does not seem like change that should be considered (or perhaps even suggested) at this very late point in the process. > It is relatively clear (to me at least) that followup work will be needed if this gets deployed and used widely. Computer programs consuming tags are less tolerant than humans consuming tags and the idea that operators will fix things via configuration likely does not scale. But perhaps this is not bad, if the issue comes back to us in ~3 years, we know at least that tags are a useful 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 Thu Mar 7 12:11:18 2019 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 7FA0E126C87 for ; Thu, 7 Mar 2019 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqGPiD95TaXF for ; Thu, 7 Mar 2019 12:11:14 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09EA12AF7C for ; Thu, 7 Mar 2019 12:11:12 -0800 (PST) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 86D57241B12 for ; Thu, 7 Mar 2019 21:11:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1551989469; bh=m9KoN/MGQfvwb1ybDDoYLigken8mvB4Z5LcmyiGhaK4=; h=Subject:References:To:From:Date:In-Reply-To; b=TIlck/VI7h9UMryfazLMRZG58h7FmkX+pY2SZhMjDkaqDMuGZdnKNDJuDIaNRk50c 9YzwbCQ7T1zQZsVUewU/N62HI9RTrN86Q4IZ3Au5VKivUzD/ocPCRllJefxBExItiM dyR8bGqZFq1GXPEQGFlQlxI6IAfrTi3wpmzTNvCU= References: <20190307035909.4D3ACB824FD@rfc-editor.org> To: netmod@ietf.org From: Robert Varga Openpgp: preference=signencrypt Message-ID: <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> Date: Thu, 7 Mar 2019 21:11:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190307035909.4D3ACB824FD@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="z0Tfx0TkYAL6WejQMchAKS6gL30c6a1l5" Archived-At: Subject: Re: [netmod] RFC 8528 on YANG Schema Mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:11:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --z0Tfx0TkYAL6WejQMchAKS6gL30c6a1l5 Content-Type: multipart/mixed; boundary="F63I9I9SZ9GfaKEPpM9uPEpPS8vJ0VdWM"; protected-headers="v1" From: Robert Varga To: netmod@ietf.org Message-ID: <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> Subject: Re: [netmod] RFC 8528 on YANG Schema Mount References: <20190307035909.4D3ACB824FD@rfc-editor.org> In-Reply-To: <20190307035909.4D3ACB824FD@rfc-editor.org> --F63I9I9SZ9GfaKEPpM9uPEpPS8vJ0VdWM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/03/2019 04:59, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. >=20 > =20 > RFC 8528 >=20 > Title: YANG Schema Mount=20 Awesome, congrats :) One quick question: what are the sub-statements allowed under a 'yangmnt:mount-point "foo"' ? I see RFC8529 is using 'description', but could not find a definitive list. Can I assume it's only config/description/reference/status, or is it a larger set? Thanks, Robert --F63I9I9SZ9GfaKEPpM9uPEpPS8vJ0VdWM-- --z0Tfx0TkYAL6WejQMchAKS6gL30c6a1l5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlyBetcLHG5pdGVAaHEu c2sACgkQJKB0S2uuNduCDA//QvAJ3zZLpFJhtIZNSS3OHxEbU3u/w9Y9Pbh507Ec rnlO4zcT9CztvB0ICYiVQ0YGOpL0pt7Q748LPM/zZkmkejYK0mW2cWqYFZJFi7pX 3xG30PjK64IjyMDzrY05BUWDzYTG3w6C6k+ggLi1zaT8gS2GbTDgeg5x6Od2QwyV dnGQaJzF771rCBim+rEegKN2nGxQ0gkmZdQYL224YzFCoWrGMRoPyeLxveUEOthA JcvGzMauf0bm4IC0aX438ZULdwS7FsScdN+LWKTU4DcLDzFy4OkWePLWjNLNkjO4 iQQ7nf67qECohxaVJY1rPpVt7PeOuViTQ1S2yp+vwouS/CVifKSHKSTjCcI6xSrQ 7AKcnNo6yzOgcHtQkfxqft4mMMvAIFlmQsJXG5K9Ws2xoZ696l0Yj7zzs/Cq5Ilk uI/n78+WbSHguPzUijhO2iBmvY8jEFXr5G9m/RLGsLDKBcHj8VV72PYYCsFLwGWi nMkVACFBX+8W/1meS4Fe2noRybvfYwDlYRmq7LOdCQASWS4CwIh6dUxx6TlDiJ2B 9XxIHiRPVConLNyiAbXWjI4WI+Q6UaAlfXcILHikvkgTJdCaVVldEVxepRfr1Kbc ZPyFXP0N19Po86271dUrTo2QdLdtD1KyFyL5ndoLM3iOrVRuLsm1XND45civm2bk 3tw= =PONo -----END PGP SIGNATURE----- --z0Tfx0TkYAL6WejQMchAKS6gL30c6a1l5-- From nobody Thu Mar 7 12:47:13 2019 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 82B99130EC6 for ; Thu, 7 Mar 2019 12:47:12 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 Linr9c1wI5Cy for ; Thu, 7 Mar 2019 12:47:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E66FF129BBF for ; Thu, 7 Mar 2019 12:47:07 -0800 (PST) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A0FFB1AE0118; Thu, 7 Mar 2019 21:47:04 +0100 (CET) Date: Thu, 07 Mar 2019 21:47:04 +0100 (CET) Message-Id: <20190307.214704.1187558364248640163.mbj@tail-f.com> To: nite@hq.sk Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> References: <20190307035909.4D3ACB824FD@rfc-editor.org> <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] RFC 8528 on YANG Schema Mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:47:13 -0000 Robert Varga wrote: > On 07/03/2019 04:59, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 8528 > > > > Title: YANG Schema Mount > > Awesome, congrats :) > > One quick question: what are the sub-statements allowed under a > 'yangmnt:mount-point "foo"' ? I see RFC8529 is using 'description', but > could not find a definitive list. Wow, nobody catched this! Maybe an argument for https://github.com/netmod-wg/yang-next/issues/54? > Can I assume it's only config/description/reference/status, or is it a > larger set? W/o additional text, I think description/reference/status. But it is not clear at all :( /martin From nobody Thu Mar 7 12:51:47 2019 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 01BCD126C87 for ; Thu, 7 Mar 2019 12:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE2cXBT-VMfU for ; Thu, 7 Mar 2019 12:51:44 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264A912AF7F for ; Thu, 7 Mar 2019 12:51:44 -0800 (PST) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id BB87C241860; Thu, 7 Mar 2019 21:51:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1551991901; bh=CqmWZ7xDqriSOwnZGHzvTSNoVtiE+ts6PILDsVVsq6Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=A3rjxTnd39nKko5y8t0Rc7R/D5NAYCuUlI2vTBQRozOXVSfC+zL0F3UQ0L0Pgrx9B VW1/Zc7oLg9XF5WdaUY7EiVnz0tVD6TMz5oPopp+kjWttbDMrKQhjMJ/kwZv42tJ4l RUYLe8nL6Au0HeCqv4yvupaeB3KO9UalNurBd4ow= To: Martin Bjorklund Cc: netmod@ietf.org References: <20190307035909.4D3ACB824FD@rfc-editor.org> <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> <20190307.214704.1187558364248640163.mbj@tail-f.com> From: Robert Varga Openpgp: preference=signencrypt Message-ID: <64334e62-7329-a0af-6667-f2d37f55bc2b@hq.sk> Date: Thu, 7 Mar 2019 21:51:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190307.214704.1187558364248640163.mbj@tail-f.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DyIUV3XjOAV1gTbmggvtFJtd7GKIeAV78" Archived-At: Subject: Re: [netmod] RFC 8528 on YANG Schema Mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:51:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DyIUV3XjOAV1gTbmggvtFJtd7GKIeAV78 Content-Type: multipart/mixed; boundary="d7uBEqVVGBgqptDPYpRJQVI8f33aGAt99"; protected-headers="v1" From: Robert Varga To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <64334e62-7329-a0af-6667-f2d37f55bc2b@hq.sk> Subject: Re: [netmod] RFC 8528 on YANG Schema Mount References: <20190307035909.4D3ACB824FD@rfc-editor.org> <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> <20190307.214704.1187558364248640163.mbj@tail-f.com> In-Reply-To: <20190307.214704.1187558364248640163.mbj@tail-f.com> --d7uBEqVVGBgqptDPYpRJQVI8f33aGAt99 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/03/2019 21:47, Martin Bjorklund wrote: >> Can I assume it's only config/description/reference/status, or is it a= >> larger set? > W/o additional text, I think description/reference/status. But it is > not clear at all :( Section 3.3 seems to imply "config" is allowed, but I do not have the document sufficiently in-brain yet: > The "config" property of mounted schema nodes is overridden and all > nodes in the mounted schema are read-only ("config false") if at > least one of the following conditions is satisfied for a mount point= : >=20 > o The mount point is itself defined as "config false". Regards, Robert --d7uBEqVVGBgqptDPYpRJQVI8f33aGAt99-- --DyIUV3XjOAV1gTbmggvtFJtd7GKIeAV78 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlyBhF0LHG5pdGVAaHEu c2sACgkQJKB0S2uuNdu3kRAAoIPI3c+nNwF0738APJnBEIe9+qE0IZNAXEV8jcOu nv34AP4/QzJBbUl3L+PkyydK7pjAjDUyG+TWfnm1TH22LCA3BOsCO/cQ3yQcmHcR 9YFqo0hYnFUdqU+oQlpRoIN1HlCsNDka0LKFe7FIuBxWXaRAiGjbA5WgpZsB/ZzI 7jBQNPbHvrOUZ2rX1/nt3TfY4P7Ae+waqOaYmGwjrX6SWZ+srb34eAYTsdMcRIvO 8Vntfpbpg3wx2QYY4yJyQIrh48hdWassLtXkpMzy29j0o21X4cvWUkmbiopD39nJ MnD5VFpfEHPyJa2PRJmmY3cmlV9J33rL57k57YdmyYaJoCkjjPnuozbIwe+PUpsf kjNo94AYO94QRx9vUSgaM7sG/vDaAaJOfa26lHfUMKrclWqVRFgj/tiTXJYRN7U6 iGh4wfA2LFrEK5JofvJkdc8L6lGd0cayY5wSqjX95C7w8P0NzEv6s1kYso4We3Sb leKPPbA4O03L8J1Y9xlQhozbhqZBFQASATt6QS1xb6U0awRZYo1q2aGIZtJ++MXE iRtFWBC6SOXoUxHKyLYykPM43foOJJ8kJPwzBzUDG0iQyJxcSdiXCaajEypTOuYs EObO8ftUC3sCV2vK5DPsBAxLPYRSxOzf847WuSydNtZiqvFfCZbLLsfKo7Bh3TzA VqQ= =JRoF -----END PGP SIGNATURE----- --DyIUV3XjOAV1gTbmggvtFJtd7GKIeAV78-- From nobody Thu Mar 7 12:54:16 2019 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 9DA7A12E036 for ; Thu, 7 Mar 2019 12:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEfEiiNaNlZD for ; Thu, 7 Mar 2019 12:54:12 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300E81275E9 for ; Thu, 7 Mar 2019 12:54:12 -0800 (PST) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 57A50241860; Thu, 7 Mar 2019 21:54:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1551992050; bh=AdlDedx56LZkJ1GgUSq6L8eH42c4UuFINOeUVvoNa7s=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=p8Ory7F/HVoHMYuMe2IIjlKBzZO5KRdUyRJyZT1YHJP9zXXhOb/bJ1I6u1ZdB6cMC fMXCOJE8A3W0QWlAfgeMQFPE3ROzN+6cy+ca3fHh+rjXor5MiBxfqW8Pi0KrzKMlRu 27LjlSL60dh+mq8sCrDbTvCQQDMw9y3T0ucp2L9s= To: Martin Bjorklund Cc: netmod@ietf.org References: <20190307035909.4D3ACB824FD@rfc-editor.org> <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> <20190307.214704.1187558364248640163.mbj@tail-f.com> From: Robert Varga Openpgp: preference=signencrypt Message-ID: <13727816-16d0-b38f-c1dd-2b4f95a94562@hq.sk> Date: Thu, 7 Mar 2019 21:54:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190307.214704.1187558364248640163.mbj@tail-f.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8j7327BXQtlhTLAY5VkOVwKRTM0rKdhxK" Archived-At: Subject: Re: [netmod] RFC 8528 on YANG Schema Mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:54:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8j7327BXQtlhTLAY5VkOVwKRTM0rKdhxK Content-Type: multipart/mixed; boundary="iPy3xVzJ9y9VsQ8GcoftGut2RGWs9gSpS"; protected-headers="v1" From: Robert Varga To: Martin Bjorklund Cc: netmod@ietf.org Message-ID: <13727816-16d0-b38f-c1dd-2b4f95a94562@hq.sk> Subject: Re: [netmod] RFC 8528 on YANG Schema Mount References: <20190307035909.4D3ACB824FD@rfc-editor.org> <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> <20190307.214704.1187558364248640163.mbj@tail-f.com> In-Reply-To: <20190307.214704.1187558364248640163.mbj@tail-f.com> --iPy3xVzJ9y9VsQ8GcoftGut2RGWs9gSpS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/03/2019 21:47, Martin Bjorklund wrote: >> One quick question: what are the sub-statements allowed under a >> 'yangmnt:mount-point "foo"' ? I see RFC8529 is using 'description', bu= t >> could not find a definitive list. > Wow, nobody catched this! Maybe an argument for > https://github.com/netmod-wg/yang-next/issues/54? Yes. Pretty please? :) Bye, Robert --iPy3xVzJ9y9VsQ8GcoftGut2RGWs9gSpS-- --8j7327BXQtlhTLAY5VkOVwKRTM0rKdhxK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlyBhPILHG5pdGVAaHEu c2sACgkQJKB0S2uuNdvcWw/7BAIE7QShHhIQqBOCC0shJHoABWGHTbadZCFpBJCb wh+7nnMOQDa9/rJFff0UYbMDVJAxbXeC0T2CeoLTQBxomkHYAf7gf7+vmfpKB3pI VJhd/PvmR1llSPZfE3XgN41XYrzQmfHnGOseaLkbutNoLhEu8UPYPZzv0jtTFOM3 gjwFHOzub5gSlxCFFHSI+O+6rW58vAUm8rmVYZsA5arn517STwlS/1n3+gqR3g+j +dfZfBUpDu/eUtmoWLLSpbPofR0H+sTvdzox1lE2ZbRzt6lNXPV0W3A9mrSc3jC1 F0QKBKEWsvFLHGQH1JuKMknXhjW6yfdlBgO9qazbacbeJNNmM2DJPsEyCHfob7Is LJL7JUjNF2140pHhHe+EshmxmurgfGVNFl/bHBsAYVzAwLAy1QzC5so3B6qvFbuD G6PFp0dthmuF3OLeOpZAhXUcxcSE0LojP381wwJx1aswNQoTIVOGdaIxR2+to3Ef te9luGg51D2cFXtEunKmbhQadoQvfC8L2Minarb3FXBRe6GoEBYoLv09w6sh2ALg En4zu0RdGuZfpwlUBB5ruaYZ9YfnSIA/D2hc3nhfdJNTfvQWQ+Ph79j0+NmFunY9 t114TfkXlTz+tQKM9vP1GyIvF89BhrUGtB+rdCrcZHjz6gggtYoHcbFN4zeqgNj7 ni4= =7EuC -----END PGP SIGNATURE----- --8j7327BXQtlhTLAY5VkOVwKRTM0rKdhxK-- From nobody Thu Mar 7 13:06:05 2019 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 4B2AC12AF7F; Thu, 7 Mar 2019 13:05:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155199275919.5534.4091583576716041337@ietfa.amsl.com> Date: Thu, 07 Mar 2019 13:05:59 -0800 Archived-At: Subject: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2019-03-20 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:05:59 -0000 The Network Modeling (netmod) Working Group will hold a virtual interim meeting on 2019-03-20 from 10:00 to 12:00 America/New_York. Agenda: Agenda: YANG Next Scoring (cont.) The primary goal of this meeting is to attempt to better score the following values: importance-unknown, backcompat-unknown, and backcompat-medium, as these values are effecting impacting data analysis. Secondary goal is to score the four new issues that have come in since the last scoring meeting. The updated scoring values will be reflected in the presentation given in NETMOD session #1 in Prague. Details: https://github.com/netmod-wg/yang-next/issues. Wednesday, March 20, 2019 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs Meeting number (access code): 645 314 928 Meeting password: Cx2n5J6N https://ietf.webex.com/ietf/j.php?MTID=m9798c92a3f7fb0589e77eccd1fc9cd42 Information about remote participation: Webex information below. From nobody Thu Mar 7 15:24:57 2019 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 4BDF612DF71; Thu, 7 Mar 2019 15:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=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 K35e5uskap4v; Thu, 7 Mar 2019 15:24:36 -0800 (PST) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (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 A3BB112D4F3; Thu, 7 Mar 2019 15:24:35 -0800 (PST) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[192.168.0.132]) by a-painless.mh.aa.net.uk with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.89) (envelope-from ) id 1h21sJ-0001fP-E4; Thu, 07 Mar 2019 22:52:28 +0000 SavedFromEmail: elwynd@dial.pipex.com Date: Thu, 07 Mar 2019 22:50:50 +0000 Message-ID: Importance: normal From: Elwyn Davies To: Christian Hopps , Elwyn Davies Cc: gen-art@ietf.org, draft-ietf-netmod-module-tags.all@ietf.org, "" , netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_4795178868632860" Archived-At: Subject: Re: [netmod] [Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 23:24:40 -0000 ----_com.samsung.android.email_4795178868632860 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIENocmlzdGlhbi5UaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS5JIHVuZGVyc3RhbmQg eW91ciBpbnRlbnQsIGJ1dCB0aGUgaW50ZW50IGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBhcHBlYXIg dG8gYmUgaW4gY29uZmxpY3QuVGhlIHBhdHRlcm4gZm9yIHRhZ3MgaXMJwqDCoMKgwqDCoMKgwqDC oCBwYXR0ZXJuICdbYS16QS1aX11bYS16QS1aMC05LV9dKjpbUyBdKyc7wqDCoFRoaXMgUkVRVUlS RVMgdHdvIGNoYXJhY3RlciBzdHJpbmdzIHNlcGFyYXRlZCBieSBhIGNvbG9uIHVubGVzcyBJIGhh dmUgdG90YWxseSBmb3Jnb3R0ZW4gaG93IHRvIHJlYWQgc3VjaCBwYXR0ZXJucy4gVGh1cyBhbGwg dGFncyBoYXZlIGEgcHJlZml4IG9mIHRoZSBmb3JtIFthLXpBLVpfXVthLXpBLVowLTktX10qIGFu ZCBhIHBhcnQgYWZ0ZXIgdGhlIGNvbG9uIHRoYXQgaXMgZXNzZW50aWFsbHkgdW5jb25zdHJhaW5l ZC5TMiBsaW1pdHMgdGhlIHZhbHVlcyBvZiB0aGUgcHJlZml4ZXMgdG8gdGhvc2UgZGVmaW5lZCBp biB0aGUgSUFOQSByZWdpc3RyeSBvZiBzNy4xLi4gRnVydGhlciB0aGUgdmFsdWVzIG9mIHRoZSBz ZWNvbmQgcGFydCBhcmUgY29uc3RyYWluZWQgYnkgdGhlIHM3LjIgcmVnaXN0cnkgaWYgdGhlIHBy ZWZpeCBpcyBpZXRmOi5Tbywgd2hhdCBzaG91bGQgYSBZQU5HIHBhcnNlciBkbyB3aGVuIGJ1aWxk aW5nIGRhdGFzdG9yZXMgYXMgcGVyIFJGQyA4MzQyIGlmIGEgdGFnIHByZWZpeCBpcyBub3Qgb25l IG9mIHRoZSBvbmVzIGluIHRoZSBzNy4xIHJlZ2lzdHJ5PyBMaWtld2lzZSBpZiB0aGUgcHJlZml4 IGlzIGlldGY6IGFuZCB0aGUgd2hvbGUgdGFnIGlzIG5vdCBpbiB0aGUgczcuMiByZWdpc3RyeT9J ZiB5b3Ugd2FudCB0byBtYWtlIHRoZSBwcmVzZW5jZSBvZiB0aGUgcHJlZml4IGEgU0hPVUxEIHRo ZW4gSSB0aGluayB5b3UgbmVlZCB0byBhZGFwdCB0aGUgcGF0dGVybiB0byBtYWtlIHRoZSB3aG9s ZSBwcmVmaXggcGFydCBvcHRpb25hbC7CoCBIb3dldmVyIHRoYXQgZG9lc24ndCBnZXQgYXdheSBm cm9tIGRlc2NyaWJpbmcgd2hhdCB0aGUgcGFyc2VyIHNob3VsZCBkbyBpZiBpdCBmaW5kcyBhIHBy ZWZpeCBpdCBkb2Vzbid0IGtub3cgYWJvdXQuwqBBZGRpdGlvbmFsbHksIEkgYW0gbm90IGNsZWFy IGhvdyB0aGUgcGFyc2VyIGtub3dzIHdoaWNoIHRhZ3Mgc2hvdWxkIGJlIG1hcmtlZCBhcyAnc3lz dGVtJyBpbiB0aGUgZGF0YXN0b3JlIGFzIG1lbnRpb25lZCBpbiB0aGUgWUFORyBtb2R1bGUgY29t bWVudHMuwqBNYXliZSBpdCBpcyB0aGF0IHRoZSBpZXRmIHByZWZpeCBhbmQgczcuMiB2YWx1ZSBs ZWFkcyB0aGUgdGFncyB0byBiZSBtYXJrZWQgYXMgc3lzdGVtIHRhZ3MgYnV0IHdoYXQgc2hvdWxk IGhhcHBlbiBpZiBpdCBpc24ndCBpbiB0aGUgczcuMiBsaXN0P8KgIFNob3VsZCB0aGUgcGFyc2Vy IGlnbm9yZSBzdWNoIHRhZ3MsIHRocm93IGEgZmF1bHQgYW5kIHJlZnVzZSB0byBwYXJzZSB0aGUg bW9kdWxlIG9yIG1heWJlIHRyZWF0IHRoZW0gYXMgdXNlciB0YWdzIGV2ZW4gaWYgdGhleSBhcmUg aWV0ZiBwcmVmaXhlZD/CoMKgQWxzbyBpZiBuZXcgcHJlZml4ZXMgYXJlIGRlZmluZWQgYnkgb3Ro ZXIgU0RPcywgYXMgZW52aXNhZ2VkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBzNy4xLCBjb3Vs ZCBvciB3b3VsZCB0aGVzZSBhbHNvIGJlIHN5c3RlbSB0YWdzP8KgIFNob3VsZCB0aGVyZSB0aGVu IGJlIGEgZmxhZyBvciB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkgdG8gZmxhZyB0aGF0IHRhZ3Mgd2l0 aCB0aGlzIHByZWZpeCBzaG91bGQgYmUgbWFya2VkIGFzIHN5c3RlbSBvciBvdGhlcndpc2U/VGh1 cyBhbHNvIGJyaW5ncyB1cCBhbm90aGVyIGlzc3VlIGZvciB0aGUgczcuMSByZWdpc3RyeS7CoCBJ ZiBhbm90aGVyIG9yZ2FuaXNhdGlvbiBpcyBkZWZpbmluZyBhIHByZWZpeCB0aGVyZSByZWFsbHkg bmVlZCB0byBiZSBjb250YWN0IGFuZCByZWZlcmVuY2UgZmllbGRzIGluIHRoZSByZWdpc3RyeSB0 byBzcGVjaWZ5IHRoZSBvcmdhbmlzYXRpb24gbWFpbnRhaW5pbmcgdGhpcyBwcmVmaXgsIGVzcGVj aWFsbHkgaWYgc3VjaCBhIHByZWZpeCBoYWQgaXRzIG93biBlcXVpdmFsZW50IG9mIHRoZSBzNy4y IHJlZ2lzdHJ5LCBhbmQgdGhlIGRvY3VtZW50IHRoYXQgaW50cm9kdWNlcyB0aGUgcHJlZml4Lkkg c3VnZ2VzdCB0aGUgYXV0aG9ycyBkaXNjdXNzIHRoZSBhcHByb3ByaWF0ZSBzdGF0dXMgZm9yIHRo ZSB0aHJlZSBSRkNzIHRoYXQgSSBzdWdnZXN0ZWQgc2hvdWxkIGJlIG5vcm1hdGl2ZSBhbmQgeW91 IGRpc2FncmVlZCB3aXRoIHlvdXIgQUQuwqAgSXQgaXMgYSByYXRoZXIgb2RkIHNpdHVhdGlvbiB3 aGVyZSBhIHN0YW5kYXJkcyBsdHJhY2sgZG9jdW1lbnQgaXMgdXBkYXRpbmcgYW4gaW5mb3JtYXRp b25hbCBvciBCQ1AgZG9jdW1lbnQsIGFuZCBhbHNvIG5lZWRpbmcga25vd2xlZGdlIG9mIGl0ZW1z IGRlc2NyaWJlZCBpbiBCQ1BzLsKgIFdpdGggdGhlIHJldmlzZWQgcG9saWN5IG9uIGRvd25yZWZz LCB0aGlzIGNhbiBiZSBoYW5kbGVkIEkgYmVsaWV2ZS5DaGVlcnMsRWx3eW5TZW50IGZyb20gU2Ft c3VuZyB0YWJsZXQuCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBDaHJp c3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPiBEYXRlOiAwNi8wMy8yMDE5ICAyMjo1NSAg KEdNVCswMDowMCkgVG86IEVsd3luIERhdmllcyA8ZWx3eW5kQGRpYWwucGlwZXguY29tPiBDYzog Z2VuLWFydEBpZXRmLm9yZywgQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz4sIGRy YWZ0LWlldGYtbmV0bW9kLW1vZHVsZS10YWdzLmFsbEBpZXRmLm9yZywgIjxpZXRmQGlldGYub3Jn PiIgPGlldGZAaWV0Zi5vcmc+LCBuZXRtb2RAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtHZW4tYXJ0 XSBbbmV0bW9kXSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldG1vZC1t b2R1bGUtdGFncy0wNiBbSSBjb3ZlcmVkIHRoaXMgaW4gdGhlIHByZXZpb3VzIHJlcGx5IEkganVz dCBzZW50LCBhbmQgdXBkYXRlZCB0aGUgbW9kZWwgdGV4dCBpbiByZXNwb25zZSB0b28uLl1UaGUg aW50ZW50IGhlcmUgaXMgdG8gbm90IHJlc3RyaWN0IHVzZXJzIG9mIHRhZ3Mgd2hlcmUgd2UgZG9u J3QgaGF2ZSB0by4gVGhlIHByZWZpeCBpcyBvbmx5IGludGVuZGVkIHRvIGF2b2lkIGNvbGxpc2lv biBiZXR3ZWVuIGRpc2Nvbm5lY3RlZCBncm91cHMgKGRlc2lnbmVycywgaW1wbGVtZW50ZXJzIGFu ZCB1c2VycyksIHNpbmNlIHVzZXJzIGFyZSB0aGUgZmluYWwgZ3JvdXAgdG8gYWRkL21vZGlmeS91 c2UgdGhlIHRhZ3Mgd2UgZG9uJ3QgbmVlZCB0byByZXN0cmljdCB0aGVtIChhbmQgc28gd2Ugc2hv dWxkbid0KS5UaGFua3MsQ2hyaXMuPiBPbiBNYXIgNiwgMjAxOSwgYXQgMjozOSBQTSwgRWx3eW4g RGF2aWVzIDxlbHd5bmRAZGlhbC5waXBleC5jb20+IHdyb3RlOj4gPiBIaS4+ID4gQWZ0ZXIgY29t cGxldGluZyBteSByZXZpZXcsIEkgcmVhbGl6ZWQgdGhhdCB0aGVyZSB3YXMgYSBmdXJ0aGVyIG1p bm9yIGlzc3VlIHJlbGF0ZWQgdG8gdGhlIHBvc3NpYmxlIHZhbHVlcyBvZiB0YWcgcHJlZml4ZXMs IHBvc3NpYmxlIHZhbHVlcyBvZiBzdGFuZGFyZGl6ZWQgcHJlZml4ZXMgYW5kIGJlaGF2aW91ciBv ZiBpbXBsZW1lbnRhdGlvbnMgaW4gdGhlIGZhY2Ugb2YgdGFnIHByZWZpeGVzIG9yIHZhbHVlcyB0 aGF0IGFyZSBub3QgaW4gdGhlIHJlbGV2YW50IHJlZ2lzdHJpZXMuPiA+IEkgdGhpbmsgdGhhdCB0 aGUgdGV4dCBpbiBzMiBzaG91bGQgYmUgcmVpbmZvcmNlZCB0byBlbXBoYXNpc2UgdGhhdCB0aGUg b25seSBwcmVmaXhlcyB0aGF0IHNob3VsZCBiZSBleHBlY3RlZCBhcmUgdGhvc2UgaW4gdGhlIElB TkEgcmVnaXN0cnkgZGVmaW5lZCBpbiBzNy4xLj4gPiBFaXRoZXIgYSBuZXcgc2VjdGlvbiBvciBw b3NzaWJseSBpbiBzMyB0ZXh0IHNob3VsZCBiZSBhZGRlZCB0byBkZWZpbmUgdGhlIGJlaGF2aW91 ciBvZiBZQU5HIGltcGxlbWVudGF0aW9ucyB0aGF0IGVuY291bnRlciB0YWdzIHdpdGggcHJlZml4 ZXMgdGhhdCBhcmUgbm90IGluIHRoZSBzNy4xIHJlZ2lzdHJ5IGFuZCB0YWdzIHdpdGggcHJlZml4 IGlldGY6IHRoYXQgYXJlIG5vdCBpbiB0aGUgczcuMiByZWdpc3RyeS4+ID4gUmVnYXJkcyw+IEVs d3luIERhdmllcz4gPiA+ID4gPiA+IFNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC4+ID4gLS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLT4gRnJvbTogRGF0YXRyYWNrZXIgb24gYmVoYWxm IG9mIEVsd3luIERhdmllcyA8aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZz4+IERhdGU6 IDA2LzAzLzIwMTkgMDA6MjYgKEdNVCswMDowMCk+IFRvOiBnZW4tYXJ0QGlldGYub3JnPiBDYzog ZHJhZnQtaWV0Zi1uZXRtb2QtbW9kdWxlLXRhZ3MuYWxsQGlldGYub3JnLCBpZXRmQGlldGYub3Jn LCBuZXRtb2RAaWV0Zi5vcmc+IFN1YmplY3Q6IFtHZW4tYXJ0XSBHZW5hcnQgbGFzdCBjYWxsIHJl dmlldyBvZsKgwqAgZHJhZnQtaWV0Zi1uZXRtb2QtbW9kdWxlLXRhZ3MtMDY+ID4gUmV2aWV3ZXI6 IEVsd3luIERhdmllcz4gUmV2aWV3IHJlc3VsdDogQWxtb3N0IFJlYWR5PiA+IEkgYW0gdGhlIGFz c2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWE+ IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBw cm9jZXNzZWQ+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci7CoCBQbGVhc2UgdHJlYXQg dGhlc2UgY29tbWVudHMganVzdD4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLj4g PiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0PiA+IDxodHRwczov L3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lj4gPiBEb2N1bWVudDogZHJh ZnQtaWV0Zi1uZXRtb2QtbW9kdWxlLXRhZ3MtMDY+IFJldmlld2VyOiBFbHd5biBEYXZpZXM+IFJl dmlldyBEYXRlOiAyMDE5LTAzLTA1PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTAzLTAzPiBJRVNH IFRlbGVjaGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQ+ID4gU3VtbWFyeTo+ IEFsbW9zdCByZWFkeS7CoCBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgbWlub3IgaXNzdWVzIGFuZCBh IHNtYWxsIG51bWJlciBvZiBuaXRzLj4gQXBvbG9naWVzIGZvciB0aGUgc2xpZ2h0bHkgbGF0ZSBk ZWxpdmVyeSBvZiB0aGUgcmV2aWV3Lj4gPiBNYWpvciBpc3N1ZXM6PiBOb25lPiA+IE1pbm9yIGlz c3Vlczo+IEFic3RyYWN0L3MxOiBJIHdvdWxkIGp1ZGdlIHRoYXQgUkZDIDg0MDcgb3VnaHQgdG8g YmUgbm9ybWF0aXZlIHNpbmNlIGl0IGlzPiB1cGRhdGVkLj4gPiBTNC4yOiB1c2luZyB0aGUgTmV0 bW9kIHdvcmtpbmcgZ3JvdXAgYXMgY29udGFjdCBwb2ludCBmb3IgdGhlIG1vZHVsZSBpcyBub3Q+ IGZ1dHVyZSBwcm9vZi7CoCBJIGFtwqAgbm90IHN1cmUgd2hhdCB0aGUgY29ycmVjdCBjb250YWN0 IG91Z2h0IHRvIGJlOiBJRVNHPz4gPiBTNy4yOiBbVGhpcyBpcyBhIHRob3VnaHQgdGhhdCBvY2N1 cnJlZCB0byBtZS4uLl0gb3VnaHQgdGhlcmUgdG8gYmUgYW4gaWV0Zjo+IHNlY3VyaXR5IHRhZz8+ ID4gUzk6IEkgd291bGQgY29uc2lkZXIgUkZDcyA4MTk5LCA4MzQwLCA4MzQyIGFuZCA4NDA3IHRv IGJlIG5vcm1hdGl2ZT4gPiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czo+IEFic3RyYWN0OiBzL21v ZHVsZXMvbW9kdWxlJ3MvPiA+IEFic3RyYWN0Oj4gT0xEOj4gVGhpcyBkb2N1bWVudCBhbHNvIHBy b3ZpZGVzIGd1aWRhbmNlIHRvIGZ1dHVyZSBtb2RlbCB3cml0ZXJzLCBhcyBzdWNoLCB0aGlzPiBk b2N1bWVudCB1cGRhdGVzIFJGQzg0MDcuPiA+IE5FVzo+IFRoaXMgZG9jdW1lbnQgYWxzbyBwcm92 aWRlcyBndWlkYW5jZSB0byBmdXR1cmUgbW9kZWwgd3JpdGVyczsgYXMgc3VjaCwgdGhpcz4gZG9j dW1lbnQgdXBkYXRlcyBSRkM4NDA3Lj4gPiBFTkRTPiA+IFMxLjEsIHRpdGxlOiBzL3VzZSBjYXNl cyBvZi91c2UgY2FzZXMgZm9yLz4gPiBTMS4xLCBwYXJhIDE6IHMvZG9jdW1lbnRzIHByb2dyZXNz aW9uL2RvY3VtZW50J3MgZGV2ZWxvcG1lbnQvPiA+IFMxLjEsIHBhcmFzIDIsIDMgYW5kIDU6IFN1 Z2dlc3Qgcy9FLmcuL0ZvciBleGFtcGxlLz4gPiBTMS4xLCBwYXJhIDQ6IHMvZS5nLi9lLmcuLC8+ ID4gUzIsIHBhcmEgMTo+wqDCoMKgID4gQWxsIHRhZ3MgU0hPVUxEIGJlZ2luIHdpdGggYSBwcmVm aXggaW5kaWNhdGluZyB3aG8gb3ducyB0aGVpciBkZWZpbml0aW9uLj4gPiBJZiBJIHJlYWQgY29y cmVjdGx5LCB0aGUgWUFORyBkZWZpbml0aW9uIGluIHM0LjIgUkVRVUlSRVMgdGhhdCBhbGwgdGFn cyBoYXZlIGE+IHByZWZpeC7CoCBGb3IgY2xhcml0eSwgaXQgd291bGQgYmV0dGVyIGlmIHRoaXMg cmVhZDo+wqDCoMKgIEFsbCB0YWdzIE1VU1QgYmVnaW4gd2l0aCBhIHByZWZpeDsgaXQgaXMgaW50 ZW5kZWQgdGhhdCB0aGlzIHByZWZpeCBTSE9VTEQ+wqDCoMKgIFtvciBtYXliZSAnc2hvdWxkJ10g aW5kaWNhdGU+wqAgdGhlIG93bmVyc2hpcCBvciBvcmlnaW5hdGlvbiBvZiB0aGUgZGVmaW5pdGlv bi4+ID4gUzIsIHBhcmEgMTogcy95YW5nIHR5cGUvWUFORyB0eXBlLyAoSSB0aGluayk+ID4gUzIu Mjogcy9mb2xsd2luZy9mb2xsb3dpbmcvPiA+IFMzLjEsIHBhcmEgMjo+IE9MRDo+IElmIHRoZSBt b2R1bGUgZGVmaW5pdGlvbiBpcyBJRVRGIHN0YW5kYXJkcyB0cmFjaywgdGhlIHRhZ3MgTVVTVCBh bHNvIGJlIFNlY3Rpb24+IDIuMS4gVGh1cywgbmV3IG1vZHVsZXMgY2FuIGRyaXZlIHRoZSBhZGRp dGlvbiBvZiBuZXcgc3RhbmRhcmQgdGFncyB0byB0aGUgSUFOQT4gcmVnaXN0cnksIGFuZCB0aGUg SUFOQSByZWdpc3RyeSBjYW4gc2VydmUgYXMgYSBjaGVjayBhZ2FpbnN0IGR1cGxpY2F0aW9uLj4g PiBORVc6PiBJZiB0aGUgbW9kdWxlIGlzIGRlZmluZWQgaW4gYW4gSUVURiBzdGFuZGFyZHMgdHJh Y2sgZG9jdW1lbnQsIHRoZSB0YWdzIE1VU1QgdXNlPiB0aGUgcHJlZml4IGRlZmluZWQgaW4gU2Vj dGlvbiAyLjEuIFRodXMsIGRlZmluaXRpb25zIG9mIG5ldyBtb2R1bGVzIGNhbiBkcml2ZT4gdGhl IGFkZGl0aW9uIG9mIG5ldyBzdGFuZGFyZCB0YWdzIHRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGRlZmlu ZWQgaW4gU2VjdGlvbiA3LjIsPiBhbmQgdGhlIElBTkEgcmVnaXN0cnkgY2FuIHNlcnZlIGFzIGEg Y2hlY2sgYWdhaW5zdCBkdXBsaWNhdGlvbi4+ID4gRU5EUz4gPiBTMy4yOiBzL3N0YW5kYXJkL0lF VEYgU3RhbmRhcmQvPiA+IFMzLjM6IEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBpbnRyb2R1Y2UgdGhl IHRlcm0gJ21hc2tpbmcnIHVzZWQgbGF0ZXIgaW4gdGhlIFlBTkc+IG1vZHVsZSBkZWZpbml0aW9u Lj4gPiBTNC4xOiBJIHRoaW5rIHRoaXMgdXNhZ2Ugb2YgUkZDIDgzNDAgbWFrZXMgaXQgbm9ybWF0 aXZlLj4gPiBTNC4yLCBleHRlbnNpb24gbW9kdWxlLXRhZyBkZWZpbml0aW9uOiBUaGlzIHNob3Vs ZCBjb250YWluIGEgcG9pbnRlciB0byBSRkM+IDgzNDIgd2hpY2ggZGlzY3Vzc2VzIHRoZSBzeXN0 ZW0gb3JpZ2luIGNvbmNlcHQuPiA+IE1ham9yIGlzc3Vlczo+ID4gTWlub3IgaXNzdWVzOj4gPiBO aXRzL2VkaXRvcmlhbCBjb21tZW50czo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXz4gR2VuLWFydCBtYWlsaW5nIGxpc3Q+IEdlbi1hcnRAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydD4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18+IG5ldG1vZCBtYWlsaW5n IGxpc3Q+IG5ldG1vZEBpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2RfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X0dlbi1hcnQgbWFpbGluZyBsaXN0R2VuLWFydEBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZ2VuLWFydA== ----_com.samsung.android.email_4795178868632860 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkhpLCBDaHJpc3RpYW4uPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgdW5kZXJzdGFuZCB5b3VyIGludGVudCwgYnV0IHRoZSBp bnRlbnQgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIGFwcGVhciB0byBiZSBpbiBjb25mbGljdC48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBwYXR0ZXJuIGZvciB0YWdzIGlzPC9kaXY+PGRpdj4J Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdHRlcm4g J1thLXpBLVpfXVthLXpBLVowLTktX10qOltTIF0rJzsmbmJzcDsmbmJzcDs8YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGlzIFJFUVVJUkVTIHR3byBjaGFyYWN0ZXIgc3RyaW5ncyBzZXBh cmF0ZWQgYnkgYSBjb2xvbiB1bmxlc3MgSSBoYXZlIHRvdGFsbHkgZm9yZ290dGVuIGhvdyB0byBy ZWFkIHN1Y2ggcGF0dGVybnMuIFRodXMgYWxsIHRhZ3MgaGF2ZSBhIHByZWZpeCBvZiB0aGUgZm9y bSBbYS16QS1aX11bYS16QS1aMC05LV9dKiBhbmQgYSBwYXJ0IGFmdGVyIHRoZSBjb2xvbiB0aGF0 IGlzIGVzc2VudGlhbGx5IHVuY29uc3RyYWluZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5T MiBsaW1pdHMgdGhlIHZhbHVlcyBvZiB0aGUgcHJlZml4ZXMgdG8gdGhvc2UgZGVmaW5lZCBpbiB0 aGUgSUFOQSByZWdpc3RyeSBvZiBzNy4xLi4gRnVydGhlciB0aGUgdmFsdWVzIG9mIHRoZSBzZWNv bmQgcGFydCBhcmUgY29uc3RyYWluZWQgYnkgdGhlIHM3LjIgcmVnaXN0cnkgaWYgdGhlIHByZWZp eCBpcyBpZXRmOi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNvLCB3aGF0IHNob3VsZCBhIFlB TkcgcGFyc2VyIGRvIHdoZW4gYnVpbGRpbmcgZGF0YXN0b3JlcyBhcyBwZXIgUkZDIDgzNDIgaWYg YSB0YWcgcHJlZml4IGlzIG5vdCBvbmUgb2YgdGhlIG9uZXMgaW4gdGhlIHM3LjEgcmVnaXN0cnk/ IExpa2V3aXNlIGlmIHRoZSBwcmVmaXggaXMgaWV0ZjogYW5kIHRoZSB3aG9sZSB0YWcgaXMgbm90 IGluIHRoZSBzNy4yIHJlZ2lzdHJ5PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SWYgeW91IHdh bnQgdG8gbWFrZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIHByZWZpeCBhIFNIT1VMRCB0aGVuIEkgdGhp bmsgeW91IG5lZWQgdG8gYWRhcHQgdGhlIHBhdHRlcm4gdG8gbWFrZSB0aGUgd2hvbGUgcHJlZml4 IHBhcnQgb3B0aW9uYWwuJm5ic3A7IEhvd2V2ZXIgdGhhdCBkb2Vzbid0IGdldCBhd2F5IGZyb20g ZGVzY3JpYmluZyB3aGF0IHRoZSBwYXJzZXIgc2hvdWxkIGRvIGlmIGl0IGZpbmRzIGEgcHJlZml4 IGl0IGRvZXNuJ3Qga25vdyBhYm91dC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFk ZGl0aW9uYWxseSwgSSBhbSBub3QgY2xlYXIgaG93IHRoZSBwYXJzZXIga25vd3Mgd2hpY2ggdGFn cyBzaG91bGQgYmUgbWFya2VkIGFzICdzeXN0ZW0nIGluIHRoZSBkYXRhc3RvcmUgYXMgbWVudGlv bmVkIGluIHRoZSBZQU5HIG1vZHVsZSBjb21tZW50cy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pk1heWJlIGl0IGlzIHRoYXQgdGhlIGlldGYgcHJlZml4IGFuZCBzNy4yIHZhbHVlIGxl YWRzIHRoZSB0YWdzIHRvIGJlIG1hcmtlZCBhcyBzeXN0ZW0gdGFncyBidXQgd2hhdCBzaG91bGQg aGFwcGVuIGlmIGl0IGlzbid0IGluIHRoZSBzNy4yIGxpc3Q/Jm5ic3A7IFNob3VsZCB0aGUgcGFy c2VyIGlnbm9yZSBzdWNoIHRhZ3MsIHRocm93IGEgZmF1bHQgYW5kIHJlZnVzZSB0byBwYXJzZSB0 aGUgbW9kdWxlIG9yIG1heWJlIHRyZWF0IHRoZW0gYXMgdXNlciB0YWdzIGV2ZW4gaWYgdGhleSBh cmUgaWV0ZiBwcmVmaXhlZD8mbmJzcDsmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFs c28gaWYgbmV3IHByZWZpeGVzIGFyZSBkZWZpbmVkIGJ5IG90aGVyIFNET3MsIGFzIGVudmlzYWdl ZCBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgczcuMSwgY291bGQgb3Igd291bGQgdGhlc2UgYWxz byBiZSBzeXN0ZW0gdGFncz8mbmJzcDsgU2hvdWxkIHRoZXJlIHRoZW4gYmUgYSBmbGFnIG9yIHZh bHVlIGluIHRoZSByZWdpc3RyeSB0byBmbGFnIHRoYXQgdGFncyB3aXRoIHRoaXMgcHJlZml4IHNo b3VsZCBiZSBtYXJrZWQgYXMgc3lzdGVtIG9yIG90aGVyd2lzZT88L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PlRodXMgYWxzbyBicmluZ3MgdXAgYW5vdGhlciBpc3N1ZSBmb3IgdGhlIHM3LjEgcmVn aXN0cnkuJm5ic3A7IElmIGFub3RoZXIgb3JnYW5pc2F0aW9uIGlzIGRlZmluaW5nIGEgcHJlZml4 IHRoZXJlIHJlYWxseSBuZWVkIHRvIGJlIGNvbnRhY3QgYW5kIHJlZmVyZW5jZSBmaWVsZHMgaW4g dGhlIHJlZ2lzdHJ5IHRvIHNwZWNpZnkgdGhlIG9yZ2FuaXNhdGlvbiBtYWludGFpbmluZyB0aGlz IHByZWZpeCwgZXNwZWNpYWxseSBpZiBzdWNoIGEgcHJlZml4IGhhZCBpdHMgb3duIGVxdWl2YWxl bnQgb2YgdGhlIHM3LjIgcmVnaXN0cnksIGFuZCB0aGUgZG9jdW1lbnQgdGhhdCBpbnRyb2R1Y2Vz IHRoZSBwcmVmaXguPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHN1Z2dlc3QgdGhlIGF1dGhv cnMgZGlzY3VzcyB0aGUgYXBwcm9wcmlhdGUgc3RhdHVzIGZvciB0aGUgdGhyZWUgUkZDcyB0aGF0 IEkgc3VnZ2VzdGVkIHNob3VsZCBiZSBub3JtYXRpdmUgYW5kIHlvdSBkaXNhZ3JlZWQgd2l0aCB5 b3VyIEFELiZuYnNwOyBJdCBpcyBhIHJhdGhlciBvZGQgc2l0dWF0aW9uIHdoZXJlIGEgc3RhbmRh cmRzIGx0cmFjayBkb2N1bWVudCBpcyB1cGRhdGluZyBhbiBpbmZvcm1hdGlvbmFsIG9yIEJDUCBk b2N1bWVudCwgYW5kIGFsc28gbmVlZGluZyBrbm93bGVkZ2Ugb2YgaXRlbXMgZGVzY3JpYmVkIGlu IEJDUHMuJm5ic3A7IFdpdGggdGhlIHJldmlzZWQgcG9saWN5IG9uIGRvd25yZWZzLCB0aGlzIGNh biBiZSBoYW5kbGVkIEkgYmVsaWV2ZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNoZWVycyw8 L2Rpdj48ZGl2PkVsd3luPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2ln bmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0 byI+U2VudCBmcm9tIFNhbXN1bmcgdGFibGV0LjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxk aXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogQ2hy aXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDsgPC9kaXY+PGRpdj5EYXRlOiAw Ni8wMy8yMDE5ICAyMjo1NSAgKEdNVCswMDowMCkgPC9kaXY+PGRpdj5UbzogRWx3eW4gRGF2aWVz ICZsdDtlbHd5bmRAZGlhbC5waXBleC5jb20mZ3Q7IDwvZGl2PjxkaXY+Q2M6IGdlbi1hcnRAaWV0 Zi5vcmcsIENocmlzdGlhbiBIb3BwcyAmbHQ7Y2hvcHBzQGNob3Bwcy5vcmcmZ3Q7LCBkcmFmdC1p ZXRmLW5ldG1vZC1tb2R1bGUtdGFncy5hbGxAaWV0Zi5vcmcsICImbHQ7aWV0ZkBpZXRmLm9yZyZn dDsiICZsdDtpZXRmQGlldGYub3JnJmd0OywgbmV0bW9kQGlldGYub3JnIDwvZGl2PjxkaXY+U3Vi amVjdDogUmU6IFtHZW4tYXJ0XSBbbmV0bW9kXSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBk cmFmdC1pZXRmLW5ldG1vZC1tb2R1bGUtdGFncy0wNiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj5bSSBjb3ZlcmVkIHRoaXMgaW4gdGhlIHByZXZpb3VzIHJlcGx5IEkganVzdCBzZW50LCBhbmQg dXBkYXRlZCB0aGUgbW9kZWwgdGV4dCBpbiByZXNwb25zZSB0b28uLl08YnI+PGJyPlRoZSBpbnRl bnQgaGVyZSBpcyB0byBub3QgcmVzdHJpY3QgdXNlcnMgb2YgdGFncyB3aGVyZSB3ZSBkb24ndCBo YXZlIHRvLiBUaGUgcHJlZml4IGlzIG9ubHkgaW50ZW5kZWQgdG8gYXZvaWQgY29sbGlzaW9uIGJl dHdlZW4gZGlzY29ubmVjdGVkIGdyb3VwcyAoZGVzaWduZXJzLCBpbXBsZW1lbnRlcnMgYW5kIHVz ZXJzKSwgc2luY2UgdXNlcnMgYXJlIHRoZSBmaW5hbCBncm91cCB0byBhZGQvbW9kaWZ5L3VzZSB0 aGUgdGFncyB3ZSBkb24ndCBuZWVkIHRvIHJlc3RyaWN0IHRoZW0gKGFuZCBzbyB3ZSBzaG91bGRu J3QpLjxicj48YnI+VGhhbmtzLDxicj5DaHJpcy48YnI+PGJyPiZndDsgT24gTWFyIDYsIDIwMTks IGF0IDI6MzkgUE0sIEVsd3luIERhdmllcyAmbHQ7ZWx3eW5kQGRpYWwucGlwZXguY29tJmd0OyB3 cm90ZTo8YnI+Jmd0OyA8YnI+Jmd0OyBIaS48YnI+Jmd0OyA8YnI+Jmd0OyBBZnRlciBjb21wbGV0 aW5nIG15IHJldmlldywgSSByZWFsaXplZCB0aGF0IHRoZXJlIHdhcyBhIGZ1cnRoZXIgbWlub3Ig aXNzdWUgcmVsYXRlZCB0byB0aGUgcG9zc2libGUgdmFsdWVzIG9mIHRhZyBwcmVmaXhlcywgcG9z c2libGUgdmFsdWVzIG9mIHN0YW5kYXJkaXplZCBwcmVmaXhlcyBhbmQgYmVoYXZpb3VyIG9mIGlt cGxlbWVudGF0aW9ucyBpbiB0aGUgZmFjZSBvZiB0YWcgcHJlZml4ZXMgb3IgdmFsdWVzIHRoYXQg YXJlIG5vdCBpbiB0aGUgcmVsZXZhbnQgcmVnaXN0cmllcy48YnI+Jmd0OyA8YnI+Jmd0OyBJIHRo aW5rIHRoYXQgdGhlIHRleHQgaW4gczIgc2hvdWxkIGJlIHJlaW5mb3JjZWQgdG8gZW1waGFzaXNl IHRoYXQgdGhlIG9ubHkgcHJlZml4ZXMgdGhhdCBzaG91bGQgYmUgZXhwZWN0ZWQgYXJlIHRob3Nl IGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGRlZmluZWQgaW4gczcuMS48YnI+Jmd0OyA8YnI+Jmd0OyBF aXRoZXIgYSBuZXcgc2VjdGlvbiBvciBwb3NzaWJseSBpbiBzMyB0ZXh0IHNob3VsZCBiZSBhZGRl ZCB0byBkZWZpbmUgdGhlIGJlaGF2aW91ciBvZiBZQU5HIGltcGxlbWVudGF0aW9ucyB0aGF0IGVu Y291bnRlciB0YWdzIHdpdGggcHJlZml4ZXMgdGhhdCBhcmUgbm90IGluIHRoZSBzNy4xIHJlZ2lz dHJ5IGFuZCB0YWdzIHdpdGggcHJlZml4IGlldGY6IHRoYXQgYXJlIG5vdCBpbiB0aGUgczcuMiBy ZWdpc3RyeS48YnI+Jmd0OyA8YnI+Jmd0OyBSZWdhcmRzLDxicj4mZ3Q7IEVsd3luIERhdmllczxi cj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IFNlbnQg ZnJvbSBTYW1zdW5nIHRhYmxldC48YnI+Jmd0OyA8YnI+Jmd0OyAtLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tPGJyPiZndDsgRnJvbTogRGF0YXRyYWNrZXIgb24gYmVoYWxmIG9mIEVs d3luIERhdmllcyAmbHQ7aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZyZndDs8YnI+Jmd0 OyBEYXRlOiAwNi8wMy8yMDE5IDAwOjI2IChHTVQrMDA6MDApPGJyPiZndDsgVG86IGdlbi1hcnRA aWV0Zi5vcmc8YnI+Jmd0OyBDYzogZHJhZnQtaWV0Zi1uZXRtb2QtbW9kdWxlLXRhZ3MuYWxsQGll dGYub3JnLCBpZXRmQGlldGYub3JnLCBuZXRtb2RAaWV0Zi5vcmc8YnI+Jmd0OyBTdWJqZWN0OiBb R2VuLWFydF0gR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YmbmJzcDsmbmJzcDsgZHJhZnQtaWV0 Zi1uZXRtb2QtbW9kdWxlLXRhZ3MtMDY8YnI+Jmd0OyA8YnI+Jmd0OyBSZXZpZXdlcjogRWx3eW4g RGF2aWVzPGJyPiZndDsgUmV2aWV3IHJlc3VsdDogQWxtb3N0IFJlYWR5PGJyPiZndDsgPGJyPiZn dDsgSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhl IEdlbmVyYWwgQXJlYTxicj4mZ3Q7IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQ8YnI+Jmd0OyBieSB0aGUgSUVTRyBmb3IgdGhl IElFVEYgQ2hhaXIuJm5ic3A7IFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0PGJyPiZn dDsgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxicj4mZ3Q7IDxicj4mZ3Q7IEZv ciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQ8YnI+Jmd0OyA8YnI+Jmd0 OyAmbHQ7aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxJmd0Oy48 YnI+Jmd0OyA8YnI+Jmd0OyBEb2N1bWVudDogZHJhZnQtaWV0Zi1uZXRtb2QtbW9kdWxlLXRhZ3Mt MDY8YnI+Jmd0OyBSZXZpZXdlcjogRWx3eW4gRGF2aWVzPGJyPiZndDsgUmV2aWV3IERhdGU6IDIw MTktMDMtMDU8YnI+Jmd0OyBJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTAzLTAzPGJyPiZndDsgSUVT RyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0PGJyPiZndDsgPGJy PiZndDsgU3VtbWFyeTo8YnI+Jmd0OyBBbG1vc3QgcmVhZHkuJm5ic3A7IFRoZXJlIGFyZSBhIGNv dXBsZSBvZiBtaW5vciBpc3N1ZXMgYW5kIGEgc21hbGwgbnVtYmVyIG9mIG5pdHMuPGJyPiZndDsg QXBvbG9naWVzIGZvciB0aGUgc2xpZ2h0bHkgbGF0ZSBkZWxpdmVyeSBvZiB0aGUgcmV2aWV3Ljxi cj4mZ3Q7IDxicj4mZ3Q7IE1ham9yIGlzc3Vlczo8YnI+Jmd0OyBOb25lPGJyPiZndDsgPGJyPiZn dDsgTWlub3IgaXNzdWVzOjxicj4mZ3Q7IEFic3RyYWN0L3MxOiBJIHdvdWxkIGp1ZGdlIHRoYXQg UkZDIDg0MDcgb3VnaHQgdG8gYmUgbm9ybWF0aXZlIHNpbmNlIGl0IGlzPGJyPiZndDsgdXBkYXRl ZC48YnI+Jmd0OyA8YnI+Jmd0OyBTNC4yOiB1c2luZyB0aGUgTmV0bW9kIHdvcmtpbmcgZ3JvdXAg YXMgY29udGFjdCBwb2ludCBmb3IgdGhlIG1vZHVsZSBpcyBub3Q8YnI+Jmd0OyBmdXR1cmUgcHJv b2YuJm5ic3A7IEkgYW0mbmJzcDsgbm90IHN1cmUgd2hhdCB0aGUgY29ycmVjdCBjb250YWN0IG91 Z2h0IHRvIGJlOiBJRVNHPzxicj4mZ3Q7IDxicj4mZ3Q7IFM3LjI6IFtUaGlzIGlzIGEgdGhvdWdo dCB0aGF0IG9jY3VycmVkIHRvIG1lLi4uXSBvdWdodCB0aGVyZSB0byBiZSBhbiBpZXRmOjxicj4m Z3Q7IHNlY3VyaXR5IHRhZz88YnI+Jmd0OyA8YnI+Jmd0OyBTOTogSSB3b3VsZCBjb25zaWRlciBS RkNzIDgxOTksIDgzNDAsIDgzNDIgYW5kIDg0MDcgdG8gYmUgbm9ybWF0aXZlPGJyPiZndDsgPGJy PiZndDsgTml0cy9lZGl0b3JpYWwgY29tbWVudHM6PGJyPiZndDsgQWJzdHJhY3Q6IHMvbW9kdWxl cy9tb2R1bGUncy88YnI+Jmd0OyA8YnI+Jmd0OyBBYnN0cmFjdDo8YnI+Jmd0OyBPTEQ6PGJyPiZn dDsgVGhpcyBkb2N1bWVudCBhbHNvIHByb3ZpZGVzIGd1aWRhbmNlIHRvIGZ1dHVyZSBtb2RlbCB3 cml0ZXJzLCBhcyBzdWNoLCB0aGlzPGJyPiZndDsgZG9jdW1lbnQgdXBkYXRlcyBSRkM4NDA3Ljxi cj4mZ3Q7IDxicj4mZ3Q7IE5FVzo8YnI+Jmd0OyBUaGlzIGRvY3VtZW50IGFsc28gcHJvdmlkZXMg Z3VpZGFuY2UgdG8gZnV0dXJlIG1vZGVsIHdyaXRlcnM7IGFzIHN1Y2gsIHRoaXM8YnI+Jmd0OyBk b2N1bWVudCB1cGRhdGVzIFJGQzg0MDcuPGJyPiZndDsgPGJyPiZndDsgRU5EUzxicj4mZ3Q7IDxi cj4mZ3Q7IFMxLjEsIHRpdGxlOiBzL3VzZSBjYXNlcyBvZi91c2UgY2FzZXMgZm9yLzxicj4mZ3Q7 IDxicj4mZ3Q7IFMxLjEsIHBhcmEgMTogcy9kb2N1bWVudHMgcHJvZ3Jlc3Npb24vZG9jdW1lbnQn cyBkZXZlbG9wbWVudC88YnI+Jmd0OyA8YnI+Jmd0OyBTMS4xLCBwYXJhcyAyLCAzIGFuZCA1OiBT dWdnZXN0IHMvRS5nLi9Gb3IgZXhhbXBsZS88YnI+Jmd0OyA8YnI+Jmd0OyBTMS4xLCBwYXJhIDQ6 IHMvZS5nLi9lLmcuLC88YnI+Jmd0OyA8YnI+Jmd0OyBTMiwgcGFyYSAxOjxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgQWxsIHRhZ3MgU0hPVUxEIGJlZ2luIHdpdGggYSBwcmVmaXggaW5k aWNhdGluZyB3aG8gb3ducyB0aGVpciBkZWZpbml0aW9uLjxicj4mZ3Q7IDxicj4mZ3Q7IElmIEkg cmVhZCBjb3JyZWN0bHksIHRoZSBZQU5HIGRlZmluaXRpb24gaW4gczQuMiBSRVFVSVJFUyB0aGF0 IGFsbCB0YWdzIGhhdmUgYTxicj4mZ3Q7IHByZWZpeC4mbmJzcDsgRm9yIGNsYXJpdHksIGl0IHdv dWxkIGJldHRlciBpZiB0aGlzIHJlYWQ6PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQWxsIHRh Z3MgTVVTVCBiZWdpbiB3aXRoIGEgcHJlZml4OyBpdCBpcyBpbnRlbmRlZCB0aGF0IHRoaXMgcHJl Zml4IFNIT1VMRDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtvciBtYXliZSAnc2hvdWxkJ10g aW5kaWNhdGU8YnI+Jmd0OyZuYnNwOyB0aGUgb3duZXJzaGlwIG9yIG9yaWdpbmF0aW9uIG9mIHRo ZSBkZWZpbml0aW9uLjxicj4mZ3Q7IDxicj4mZ3Q7IFMyLCBwYXJhIDE6IHMveWFuZyB0eXBlL1lB TkcgdHlwZS8gKEkgdGhpbmspPGJyPiZndDsgPGJyPiZndDsgUzIuMjogcy9mb2xsd2luZy9mb2xs b3dpbmcvPGJyPiZndDsgPGJyPiZndDsgUzMuMSwgcGFyYSAyOjxicj4mZ3Q7IE9MRDo8YnI+Jmd0 OyBJZiB0aGUgbW9kdWxlIGRlZmluaXRpb24gaXMgSUVURiBzdGFuZGFyZHMgdHJhY2ssIHRoZSB0 YWdzIE1VU1QgYWxzbyBiZSBTZWN0aW9uPGJyPiZndDsgMi4xLiBUaHVzLCBuZXcgbW9kdWxlcyBj YW4gZHJpdmUgdGhlIGFkZGl0aW9uIG9mIG5ldyBzdGFuZGFyZCB0YWdzIHRvIHRoZSBJQU5BPGJy PiZndDsgcmVnaXN0cnksIGFuZCB0aGUgSUFOQSByZWdpc3RyeSBjYW4gc2VydmUgYXMgYSBjaGVj ayBhZ2FpbnN0IGR1cGxpY2F0aW9uLjxicj4mZ3Q7IDxicj4mZ3Q7IE5FVzo8YnI+Jmd0OyBJZiB0 aGUgbW9kdWxlIGlzIGRlZmluZWQgaW4gYW4gSUVURiBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQs IHRoZSB0YWdzIE1VU1QgdXNlPGJyPiZndDsgdGhlIHByZWZpeCBkZWZpbmVkIGluIFNlY3Rpb24g Mi4xLiBUaHVzLCBkZWZpbml0aW9ucyBvZiBuZXcgbW9kdWxlcyBjYW4gZHJpdmU8YnI+Jmd0OyB0 aGUgYWRkaXRpb24gb2YgbmV3IHN0YW5kYXJkIHRhZ3MgdG8gdGhlIElBTkEgcmVnaXN0cnkgZGVm aW5lZCBpbiBTZWN0aW9uIDcuMiw8YnI+Jmd0OyBhbmQgdGhlIElBTkEgcmVnaXN0cnkgY2FuIHNl cnZlIGFzIGEgY2hlY2sgYWdhaW5zdCBkdXBsaWNhdGlvbi48YnI+Jmd0OyA8YnI+Jmd0OyBFTkRT PGJyPiZndDsgPGJyPiZndDsgUzMuMjogcy9zdGFuZGFyZC9JRVRGIFN0YW5kYXJkLzxicj4mZ3Q7 IDxicj4mZ3Q7IFMzLjM6IEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBpbnRyb2R1Y2UgdGhlIHRlcm0g J21hc2tpbmcnIHVzZWQgbGF0ZXIgaW4gdGhlIFlBTkc8YnI+Jmd0OyBtb2R1bGUgZGVmaW5pdGlv bi48YnI+Jmd0OyA8YnI+Jmd0OyBTNC4xOiBJIHRoaW5rIHRoaXMgdXNhZ2Ugb2YgUkZDIDgzNDAg bWFrZXMgaXQgbm9ybWF0aXZlLjxicj4mZ3Q7IDxicj4mZ3Q7IFM0LjIsIGV4dGVuc2lvbiBtb2R1 bGUtdGFnIGRlZmluaXRpb246IFRoaXMgc2hvdWxkIGNvbnRhaW4gYSBwb2ludGVyIHRvIFJGQzxi cj4mZ3Q7IDgzNDIgd2hpY2ggZGlzY3Vzc2VzIHRoZSBzeXN0ZW0gb3JpZ2luIGNvbmNlcHQuPGJy PiZndDsgPGJyPiZndDsgTWFqb3IgaXNzdWVzOjxicj4mZ3Q7IDxicj4mZ3Q7IE1pbm9yIGlzc3Vl czo8YnI+Jmd0OyA8YnI+Jmd0OyBOaXRzL2VkaXRvcmlhbCBjb21tZW50czo8YnI+Jmd0OyA8YnI+ Jmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4mZ3Q7IEdlbi1hcnQgbWFpbGluZyBsaXN0PGJyPiZndDsgR2VuLWFydEBpZXRmLm9y Zzxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydDxi cj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy PiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4mZ3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4mZ3Q7 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGJyPjxicj48YnI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+R2VuLWFy dCBtYWlsaW5nIGxpc3Q8YnI+R2VuLWFydEBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2dlbi1hcnQ8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_4795178868632860-- From nobody Thu Mar 7 15:40:54 2019 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 88452131017; Thu, 7 Mar 2019 15:40:41 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 cdX70M-PXygC; Thu, 7 Mar 2019 15:40:37 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810059.outbound.protection.outlook.com [40.107.81.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E793130FB8; Thu, 7 Mar 2019 15:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aPkhIfak5uyjCI4ZI3xaHyd7/5shsS3m0Qo/pV6Hxck=; b=Zw4ycvEgMYc8xI9iTdWZV0FmEkzc4mMy2RFsDjcC3vbUB5Sdd2OJ0XgnEdDZKUXnwEEmuVHHqIz/O0eF3s4Oxro5k/YYyURp35JI2za1qfMzkhwYv0r0rKEgXrQjlxOHn//G4/QSFv6R00NUDRK1hHAEoqk7JwL2ulq9dbmpZ4U= Received: from CY4PR2201CA0005.namprd22.prod.outlook.com (2603:10b6:910:5f::15) by CY4PR22MB0597.namprd22.prod.outlook.com (2603:10b6:903:e0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Thu, 7 Mar 2019 23:40:35 +0000 Received: from DM3NAM03FT015.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by CY4PR2201CA0005.outlook.office365.com (2603:10b6:910:5f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.16 via Frontend Transport; Thu, 7 Mar 2019 23:40:35 +0000 Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com; Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.52; helo=mail-send.aviatnet.com; Received: from mail-send.aviatnet.com (192.147.115.52) by DM3NAM03FT015.mail.protection.outlook.com (10.152.82.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Thu, 7 Mar 2019 23:40:33 +0000 From: Alex Campbell To: William Lupton , Andy Bierman CC: Datatracker on behalf of Elwyn Davies , IETF discussion list , NetMod WG , "General Area Review Team" , "draft-ietf-netmod-module-tags.all@ietf.org" Thread-Topic: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 Thread-Index: AQHU1T8nb8i+TYPV90KSfkw71s2JFg== Date: Thu, 7 Mar 2019 23:40:32 +0000 Message-ID: <1552002032265.43670@Aviatnet.com> References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> , In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: multipart/alternative; boundary="_000_155200203226543670Aviatnetcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(136003)(39850400004)(346002)(396003)(2980300002)(199004)(189003)(51914003)(8676002)(4546004)(30436002)(11346002)(81156014)(126002)(36756003)(6486002)(81166006)(5660300002)(446003)(336012)(956004)(486006)(53416004)(117636001)(476003)(8936002)(54906003)(2616005)(229853002)(7736002)(97736004)(102836004)(7696005)(53546011)(86362001)(71190400001)(106002)(53936002)(54896002)(356004)(236005)(6306002)(14444005)(72206003)(93886005)(69596002)(966005)(76176011)(478600001)(4326008)(6246003)(36736006)(3846002)(6116002)(606006)(186003)(110136005)(106466001)(316002)(97876018)(26005)(118246002)(19627405001)(84326002)(2906002)(25786009)(16586007); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR22MB0597; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:ErrorRetry; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 01289b02-54bf-4deb-53c4-08d6a3564b33 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0597; X-MS-TrafficTypeDiagnostic: CY4PR22MB0597: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0597; 20:a1dV7CO38/lOTLSk6y6n5vNzsjJ6Ma0GJkSq8/txwYF+R/Gj1kKGZy+EZGw8aggRdmP5aCWmEOPywflqGQdZtQSRB+tLBiCVcBvK15czgUYryL/C9prsV5rsjvJn9dnXFx1d0oW2LEPbVCcistM8ijQFgWy0IPdK8OGoBT7S7ZlJk1XOQOYdBQY7pnVNpZVg9PELasP2cUBLESVIFM2OWpsLtwh0isvUKkDD7jmcGGcMg1dO9VaWIt8KgAiz5JpzLMVXJB6Sdhh/6JUGMtKad45u8emw2BCP5r7aI/vgjophsNxrSUnMFMPctxVKXYaRcwyo5M+TCAUMLB63wXUqd28r2s8DAXkkuzTAmRXhbAZXWloyLIgoDQY1D5K/qR/63loiPic9Afb5UXQqTAH+Gz0hKAy4OEUOO4IPa0VXUoy3+GISxcU8TuILsoqGU7pOwiA92l7sfpS2ffnJUcjle9S8kbydayBBQ0aRV+wry4z8vvJdVRXIPl/zmhno/aNt X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 096943F07A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR22MB0597; 23:WYzpLg6bnOeWCrUSIhiJw+wVsVMrd0IquPQ5ArEn4?= =?us-ascii?Q?z8Pe3UurWbiSQrvR4MZy+bYjYFHPmOcsJeam+I+J0W094QBTTTkCw6JPSk7N?= =?us-ascii?Q?5AYgORXjIMk9QmWEd4I9zVXtL1gMQ0s7NPjc7d1lmTMay8DL9H3dKScj8liQ?= =?us-ascii?Q?1X7bmdb3arukm5gV0nBzQv6HtmbK+9orlDITnUHzsdLSp2kX288H6M4DtVf8?= =?us-ascii?Q?i4WoqbYkDHtl4bxD2lenTRtdnPTgr9vFEnNXOgYIe2QLXf1QDk+oyF55DcjU?= =?us-ascii?Q?csChrFqjORh0SUbESrNwrcMJuFC1E21YPleSyzTkNKGbfeF+YrgOqdSCFuIJ?= =?us-ascii?Q?4f7ozrbb072h52P2Uyc1tklt9V+5FBjxwntAlfTrastO0SaxdanGGbhZln/R?= =?us-ascii?Q?/2Vzg7pOwCXWqWNAE4y6CADMR9qaKQnzvOxWND63XVHMPstDqX0Qhp/FSAG6?= =?us-ascii?Q?Y9CmmTv7k2G8Jk0B1EAe5Y946YufqMZY9akxO0tXuyaLrnQNGZiboc3AbUkw?= =?us-ascii?Q?PMPI7fCoTs7YqmACYWhIZtNyZrSVCG61B/KSaA7Z69Hk0nptZz5ZxeAMtz5t?= =?us-ascii?Q?ksvS4bBFRTIyg7FO8r4bdfCH7sNbvZiIQ2TrBRCXGzHZN7JAxSe+j3LpXz+k?= =?us-ascii?Q?32rlyLILB3weyVmXLh4Kq/fFeq2CO3Ho6WYv9gHC3Wuhj4ShCGuWeNHLmwit?= =?us-ascii?Q?iconQBL6OgCGhIW0IcfCF1Kib6qMBdrB4qGn8kcOmRGPXGG4Wz9pRKfG9cG9?= =?us-ascii?Q?JVcyqpTn2nxZCjSgFJoV9JEUfa+9Zu+N/Ugx74u/2C5iFqz1M4Q5gN+DPOQq?= =?us-ascii?Q?bKILsEKdEo0Aky0huRYZoaJKwRTzBkjj00UpPbM9dhk0KHGLvBkMnP8ZotG5?= =?us-ascii?Q?sX5Vjp/VbwPMqoGNSRnjVSuc6uOPAFd/rHqfhVX8xzuegGaic7RznMGPoV3c?= =?us-ascii?Q?WPUVDIjINvgrRLxbhRypCOOaYzApPjiAG03QuUlS6ljrF+bOYwnr/BFlUhCr?= =?us-ascii?Q?TnNAMgXbJxFQcIJe5eXzRiGsAEGS0eJneie7wmqYXKRjsds1IOtcgGyN0fZq?= =?us-ascii?Q?4vMsf1fn3m06bFUIjKqaPWI2yYHwjvMAxnvexLa36DCeFLzhw40V05keRenR?= =?us-ascii?Q?ajHlSQw6ZyWtVGX3CF/0OpDzThQnE4nO1S1OlEjvELNehgYymLTrnqZnUKd4?= =?us-ascii?Q?n0ikZx4u/uACYDqqmqapWO4VwCftXNHL0A1+NLRDeU2NtJn3+oAiSOVsjbLj?= =?us-ascii?Q?DYVEUgkgItI2etBhp8dvX/gxTfXA/PuIfDVxSUYjyZlY4LPbrkl4pO2g/4jO?= =?us-ascii?Q?6FuXmDDpqTbyeq+M4YdQibBq/2rJeL/M1DRRkpwJkiFaR/ShKCr8WaR7W04J?= =?us-ascii?Q?Tuu165gX56etKh9n3Wb0EVq2wXRU1LIitnvZ++UdMwxsPt0sqA1EUzgW1/Fg?= =?us-ascii?Q?Zmq25CplBaJHAlYRv9l+aw7t07xyypslhd8J7VjFIm1+TW5IQza8uR4U6Ecu?= =?us-ascii?Q?hAnrUGjobSdrA=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: fE9ZJap73jktDeJu8zsCaUib6aWitkwUwiVZT3I8mShRbGrgOHpLhl4v6e1diPI4niF+uVe8UgCFPY3Vu/XGERPDy7+1RkddivDDZnDNzachhv25WXT1CPAfkKVq5mr2aEUpMFkcUVy+IP06vNcUcOh65rdv/lsE2+vmiY/ujsrxpFboFrn7T6PHiF2qZGQJFtBufi5qjfUEL3qbTczsxn8D7UIK/1Y8f+vh34DRFwuFK+CEY5E87PDc5OwyQmQ6GyWYnGLxNIzRz/D56h3SM7Otyu1GkUjLe89dKUChGbUdc7uuD5e1vj6Gvbi5v7bDqxRXJHnRV0DfizJPghyoOGxL7ucmFA+g6J6ZTFnuKafvW9OiCST8R1nERMEaCD+skQU5bOdYFgVEj8SdthLovqZDL3uvriYBQvtb+QQSZWg= X-OriginatorOrg: aviatnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2019 23:40:33.8699 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 01289b02-54bf-4deb-53c4-08d6a3564b33 X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52]; Helo=[mail-send.aviatnet.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0597 Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 23:40:42 -0000 --_000_155200203226543670Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In that case, why not make it so the tags are actually valid URIs, similar = to XML namespaces? ________________________________ From: netmod on behalf of William Lupton Sent: Friday, 8 March 2019 7:37 a.m. To: Andy Bierman Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod WG;= General Area Review Team; draft-ietf-netmod-module-tags.all@ietf.org Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-t= ags-06 This remark might be out of context (I haven't been following the details) = but this reference to prefixes makes me wonder whether there's any way that= registered URN namespaces could be regarded as valid prefixes. https://www= .iana.org/assignments/urn-namespaces/urn-namespaces.xhtml On Thu, 7 Mar 2019 at 18:28, Andy Bierman > wrote: On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps > wrote: Thanks for the review! Comments inline. > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies > wrote: > > Reviewer: Elwyn Davies > Review result: Almost Ready > .... > If I read correctly, the YANG definition in s4.2 REQUIRES that all tags h= ave a > prefix. For clarity, it would better if this read: > All tags MUST begin with a prefix; it is intended that this prefix SHO= ULD > [or maybe 'should'] indicate > the ownership or origination of the definition. The intent was to not put the MUST on users. As the final arbiters of tags,= users should be free to do whatever they want and not have implementations= or standards superfluously block them from doing so. How about we carry th= e SHOULD into the typedef in the YANG model as well? That seems reasonable = to me, i.e., typedef tag { type string { length "1..max"; pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; } description "A tag is a type 'string' value that does not include carriage return, newline or tab characters. It SHOULD begin with a standard prefix."; I strongly agree that a prefix SHOULD be present, not MUST be present. I also think the 3 standard prefixes will be insufficient over time. (Having every organization on the planet except IETF share the prefix "vend= or:" seems a bit short-sighted) Andy > S2, para 1: s/yang type/YANG type/ (I think) > > S2.2: s/follwing/following/ > > S3.1, para 2: > OLD: > If the module definition is IETF standards track, the tags MUST also be S= ection > 2.1. Thus, new modules can drive the addition of new standard tags to the= IANA > registry, and the IANA registry can serve as a check against duplication. > > NEW: > If the module is defined in an IETF standards track document, the tags MU= ST use > the prefix defined in Section 2.1. Thus, definitions of new modules can d= rive > the addition of new standard tags to the IANA registry defined in Section= 7.2, > and the IANA registry can serve as a check against duplication. > > ENDS > > S3.2: s/standard/IETF Standard/ > > S3.3: It would be useful to introduce the term 'masking' used later in th= e YANG > module definition. How about: "Tags of any kind can be assigned and removed by the user using normal configuration mechanisms. In order to remove a tag from the operational datastore the user adds a matching =3Dmasked-tag=3D entry for a given module." > S4.1: I think this usage of RFC 8340 makes it normative. Covered earlier (BCP). > S4.2, extension module-tag definition: This should contain a pointer to R= FC > 8342 which discusses the system origin concept. Added. Thanks, Chris. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_155200203226543670Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In that case, why not make it so the tags are actually valid URIs, simil= ar to XML namespaces?


From: netmod <netmod-b= ounces@ietf.org> on behalf of William Lupton <wlupton@broadband-forum= .org>
Sent: Friday, 8 March 2019 7:37 a.m.
To: Andy Bierman
Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; Net= Mod WG; General Area Review Team; draft-ietf-netmod-module-tags.all@ietf.or= g
Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-m= odule-tags-06
 
This remark might be out of context (I haven't been follow= ing the details) but this reference to prefixes makes me wonder whether the= re's any way that registered URN namespaces could be regarded as valid pref= ixes. https://www.iana.org/assignments/urn-namespaces/urn-namesp= aces.xhtml

On Thu, 7 Mar 2019 at 18:28, Andy Bie= rman <andy@yumaworks.com> w= rote:


On Wed, Mar 6, 2019 at 2:51 PM Christ= ian Hopps <chopps= @chopps.org> wrote:
Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <= ietf-s= ecretariat-reply@ietf.org> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
....
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tag= s have a
> prefix.  For clarity, it would better if this read:
>    All tags MUST begin with a prefix; it is intended that th= is prefix SHOULD
>   [or maybe 'should'] indicate
>  the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags,= users should be free to do whatever they want and not have implementations= or standards superfluously block them from doing so. How about we carry th= e SHOULD into the typedef in the YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
    type string {
      length "1..max";
      pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
    }
    description
      "A tag is a type 'string' value that does not inc= lude carriage
       return, newline or tab characters. It SHOULD beg= in with a
       standard prefix.";




I strongly agree that a prefix SHOULD be present, not MUST be present.=
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix = "vendor:"
seems a bit short-sighted)


Andy

> S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also b= e Section
> 2.1. Thus, new modules can drive the addition of new standard tags to = the IANA
> registry, and the IANA registry can serve as a check against duplicati= on.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags= MUST use
> the prefix defined in Section 2.1. Thus, definitions of new modules ca= n drive
> the addition of new standard tags to the IANA registry defined in Sect= ion 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used later in= the YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal=
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =3Dmasked-tag=3D entry for a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer t= o RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--_000_155200203226543670Aviatnetcom_-- From nobody Thu Mar 7 16:17:07 2019 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 12B5F12D7EA; Thu, 7 Mar 2019 16:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 I1EshFgbGgB1; Thu, 7 Mar 2019 16:16:51 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 07DDC1294FA; Thu, 7 Mar 2019 16:16:51 -0800 (PST) Received: from dex.int.chopps.org (172-222-100-236.dhcp.chtrptr.net [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id AA51560465; Thu, 7 Mar 2019 19:16:49 -0500 (EST) From: Christian Hopps Message-Id: <46318F6A-3169-49BF-B205-5FBAC3D0467C@chopps.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9F7B6E75-583E-4CB2-9160-42D9A48216D4" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 7 Mar 2019 19:16:48 -0500 In-Reply-To: <1552002032265.43670@Aviatnet.com> Cc: Christian Hopps , William Lupton , Andy Bierman , "draft-ietf-netmod-module-tags.all@ietf.org" , General Area Review Team , Datatracker on behalf of Elwyn Davies , IETF discussion list , NetMod WG To: Alex Campbell References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> <1552002032265.43670@Aviatnet.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 00:16:54 -0000 --Apple-Mail=_9F7B6E75-583E-4CB2-9160-42D9A48216D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [to this thread in general, not anyone in particular] We have done this work over 2 years in the working group. It has been = presented multiple times with multiple revisions etc. We have arrived at = a solution that works, and has cleared WG LC, and IETF LC. We have a process we need to follow it. Yes if something is truly broken = and has somehow escaped all the previous checks it needs to be = addressed. But general musings about how one might do things a little = different or a little better are not appropriate at this very late = stage, otherwise we never get anything done. Not getting things done in a timely manner has been a problem = highlighted at least with the work in netmod if not the IETF in general, = and has been the subject during many meetings at this point, on how to = fix it. Endless revisionism is one of the major factors identified as a = problem. Can we please restrict discussions on this document to editorial/minor = corrections or changes that have to be made b/c otherwise the solution = will not work? Thanks, Chris. > On Mar 7, 2019, at 18:40, Alex Campbell = wrote: >=20 > In that case, why not make it so the tags are actually valid URIs, = similar to XML namespaces? >=20 > From: netmod on behalf of William Lupton = > Sent: Friday, 8 March 2019 7:37 a.m. > To: Andy Bierman > Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; = NetMod WG; General Area Review Team; = draft-ietf-netmod-module-tags.all@ietf.org > Subject: Re: [netmod] Genart last call review of = draft-ietf-netmod-module-tags-06 > =20 > This remark might be out of context (I haven't been following the = details) but this reference to prefixes makes me wonder whether there's = any way that registered URN namespaces could be regarded as valid = prefixes. = https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml = > On Thu, 7 Mar 2019 at 18:28, Andy Bierman > wrote: >=20 >=20 > On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps > wrote: > Thanks for the review! Comments inline. >=20 > > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies = > wrote: > >=20 > > Reviewer: Elwyn Davies > > Review result: Almost Ready > >=20 > ..... > > If I read correctly, the YANG definition in s4.2 REQUIRES that all = tags have a > > prefix. For clarity, it would better if this read: > > All tags MUST begin with a prefix; it is intended that this = prefix SHOULD > > [or maybe 'should'] indicate > > the ownership or origination of the definition. >=20 > The intent was to not put the MUST on users. As the final arbiters of = tags, users should be free to do whatever they want and not have = implementations or standards superfluously block them from doing so. How = about we carry the SHOULD into the typedef in the YANG model as well? = That seems reasonable to me, i.e., >=20 > typedef tag { > type string { > length "1..max"; > pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; > } > description > "A tag is a type 'string' value that does not include carriage > return, newline or tab characters. It SHOULD begin with a > standard prefix."; >=20 >=20 >=20 >=20 > I strongly agree that a prefix SHOULD be present, not MUST be present. > I also think the 3 standard prefixes will be insufficient over time. > (Having every organization on the planet except IETF share the prefix = "vendor:" > seems a bit short-sighted) >=20 >=20 > Andy >=20 > > S2, para 1: s/yang type/YANG type/ (I think) > >=20 > > S2.2: s/follwing/following/ > >=20 > > S3.1, para 2: > > OLD: > > If the module definition is IETF standards track, the tags MUST also = be Section > > 2.1. Thus, new modules can drive the addition of new standard tags = to the IANA > > registry, and the IANA registry can serve as a check against = duplication. > >=20 > > NEW: > > If the module is defined in an IETF standards track document, the = tags MUST use > > the prefix defined in Section 2.1. Thus, definitions of new modules = can drive > > the addition of new standard tags to the IANA registry defined in = Section 7.2, > > and the IANA registry can serve as a check against duplication. > >=20 > > ENDS > >=20 > > S3.2: s/standard/IETF Standard/ > >=20 > > S3.3: It would be useful to introduce the term 'masking' used later = in the YANG > > module definition. >=20 > How about: >=20 > "Tags of any kind can be assigned and removed by the user using normal > configuration mechanisms. In order to remove a tag from the > operational datastore the user adds a matching =3Dmasked-tag=3D entry = for > a given module." >=20 > > S4.1: I think this usage of RFC 8340 makes it normative. >=20 > Covered earlier (BCP). >=20 > > S4.2, extension module-tag definition: This should contain a pointer = to RFC > > 8342 which discusses the system origin concept. >=20 > Added. >=20 > Thanks, > Chris. >=20 > >=20 > > Major issues: > >=20 > > Minor issues: > >=20 > > Nits/editorial comments: > >=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 = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_9F7B6E75-583E-4CB2-9160-42D9A48216D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[to this thread in general, not anyone in = particular]

We = have done this work over 2 years in the working group. It has been = presented multiple times with multiple revisions etc. We have arrived at = a solution that works, and has cleared WG LC, and IETF LC.

We have a process we = need to follow it. Yes if something is truly broken and has somehow = escaped all the previous checks it needs to be addressed. But general = musings about how one might do things a little different or a little = better are not appropriate at this very late stage, otherwise we never = get anything done.

Not getting things done in a timely manner has been a problem = highlighted at least with the work in netmod if not the IETF in general, = and has been the subject during many meetings at this point, on how to = fix it. Endless revisionism is one of the major factors identified as a = problem.

Can = we please restrict discussions on this document to editorial/minor = corrections or changes that have to be made b/c otherwise the solution = will not work?

Thanks,
Chris.

On Mar 7, 2019, at 18:40, Alex Campbell = <Alex.Campbell@Aviatnet.com> wrote:

In that case, why not make it so the = tags are actually valid URIs, similar to XML namespaces?

From: netmod <netmod-bounces@ietf.org> on behalf of William Lupton = <wlupton@broadband-forum..org>
Sent: Friday, 8 March 2019 7:37 = a.m.
To: Andy Bierman
Cc: Datatracker on behalf of = Elwyn Davies; IETF discussion list; NetMod WG; General Area Review Team; = draft-ietf-netmod-module-tags.all@ietf.org
Subject: Re: [netmod] Genart last = call review of draft-ietf-netmod-module-tags-06
 
This remark might be out of = context (I haven't been following the details) but this reference to = prefixes makes me wonder whether there's any way that registered URN = namespaces could be regarded as valid prefixes. https://www.iana.org/assignments/urn-namespaces/urn-namespaces.= xhtml

On Thu, 7 Mar 2019 at 18:28, Andy = Bierman <andy@yumaworks.com> wrote:


On Wed, Mar 6, 2019 at 2:51 PM = Christian Hopps <chopps@chopps.org> wrote:
Thanks for = the review! Comments inline.

> On Mar 5, = 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <ietf-secretariat-reply@ietf.org> wrote:
> 
> Reviewer: Elwyn Davies
> Review result: = Almost Ready
> 
.....
> If I read correctly, the YANG definition in s4.2 = REQUIRES that all tags have a
> prefix.  For = clarity, it would better if this read:
>    = All tags MUST begin with a prefix; it is intended that this prefix = SHOULD
>   [or maybe 'should'] indicate
>  the ownership or origination of the definition.

The intent was to not put the MUST on users. = As the final arbiters of tags, users should be free to do whatever they = want and not have implementations or standards superfluously block them = from doing so. How about we carry the SHOULD into the typedef in the = YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
    type string = {
      length "1..max";
 =     pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
    }
    description
      "A tag is a type 'string' value that = does not include carriage
      =  return, newline or tab characters. It SHOULD begin with a
       standard prefix.";



I strongly agree that a prefix SHOULD be present, not MUST be = present.
I also think the 3 standard prefixes will = be insufficient over time.
(Having every = organization on the planet except IETF share the prefix = "vendor:"
seems a bit short-sighted)


Andy

> S2, para 1: s/yang = type/YANG type/ (I think)
> 
> S2.2: = s/follwing/following/
> 
> S3.1, = para 2:
> OLD:
> If the module = definition is IETF standards track, the tags MUST also be Section
> 2.1. Thus, new modules can drive the addition of new = standard tags to the IANA
> registry, and the IANA = registry can serve as a check against duplication.
> 
> = NEW:
> If the module is defined in an IETF standards = track document, the tags MUST use
> the prefix defined = in Section 2.1. Thus, definitions of new modules can drive
> the addition of new standard tags to the IANA registry = defined in Section 7.2,
> and the IANA registry can = serve as a check against duplication.
> 
> ENDS
> 
> S3.2: s/standard/IETF Standard/
> 
> S3.3: = It would be useful to introduce the term 'masking' used later in the = YANG
> module definition.

How about:

"Tags of any kind can = be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from = the
operational datastore the user adds a matching = =3Dmasked-tag=3D entry for
a given module."

> S4.1: I think this usage of RFC 8340 = makes it normative.

Covered earlier = (BCP).

> S4.2, extension module-tag = definition: This should contain a pointer to RFC
> 8342 = which discusses the system origin concept.

Added.

Thanks,
Chris.

> 
> Major = issues:
> 
> Minor = issues:
> 
> = Nits/editorial comments:
> 
> 
> = _______________________________________________
> = 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

= --Apple-Mail=_9F7B6E75-583E-4CB2-9160-42D9A48216D4-- From nobody Thu Mar 7 17:03:07 2019 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 0E9EE1310E8; Thu, 7 Mar 2019 17:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 TaXKg8fDSFwI; Thu, 7 Mar 2019 17:02:49 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2AA12008A; Thu, 7 Mar 2019 17:02:49 -0800 (PST) Received: from dex.int.chopps.org (172-222-100-236.dhcp.chtrptr.net [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5281F60511; Thu, 7 Mar 2019 20:02:48 -0500 (EST) From: Christian Hopps Message-Id: <1E9621CA-6215-42D9-8A0B-E5A3CDAE9E84@chopps.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_08F0DA5A-B177-472B-AB3F-E9E483196659" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 7 Mar 2019 20:02:47 -0500 In-Reply-To: Cc: Christian Hopps , gen-art@ietf.org, draft-ietf-netmod-module-tags.all@ietf.org, "" , netmod@ietf.org To: Elwyn Davies References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [netmod] [Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 01:02:53 -0000 --Apple-Mail=_08F0DA5A-B177-472B-AB3F-E9E483196659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 7, 2019, at 17:50, Elwyn Davies wrote: >=20 > Hi, Christian. >=20 > Thanks for the quick response. >=20 > I understand your intent, but the intent and the specification appear = to be in conflict. >=20 > The pattern for tags is > pattern '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+'; =20 >=20 > This REQUIRES two character strings separated by a colon unless I have = totally forgotten how to read such patterns. Thus all tags have a prefix = of the form [a-zA-Z_][a-zA-Z0-9-_]* and a part after the colon that is = essentially unconstrained. Your right the pattern was wrong and needs to be fixed. > S2 limits the values of the prefixes to those defined in the IANA = registry of s7.1.. Further the values of the second part are constrained = by the s7.2 registry if the prefix is ietf:. >=20 > So, what should a YANG parser do when building datastores as per RFC = 8342 if a tag prefix is not one of the ones in the s7.1 registry? = Likewise if the prefix is ietf: and the whole tag is not in the s7.2 = registry? A YANG server should never place any restrictions on the tag values. = There=E2=80=99s need for this limiting and well known justification not = to (applying Postel=E2=80=99s Law/Robustness principle here). > If you want to make the presence of the prefix a SHOULD then I think = you need to adapt the pattern to make the whole prefix part optional. = However that doesn't get away from describing what the parser should do = if it finds a prefix it doesn't know about.=20 Assuming the pattern is fixed, do we really have to call out the fact = that something marked as a SHOULD should not be treated as a MUST? That = seems like what your asking for, perhaps I=E2=80=99m missing the point = though. Are you just asking for a blurb saying parsers must not restrict = tag values? That seems like restating but if it moves things forward = I=E2=80=99m amiable. :) > Additionally, I am not clear how the parser knows which tags should be = marked as 'system' in the datastore as mentioned in the YANG module = comments.=20 B/c it (the server) put them there, not the user. > Maybe it is that the ietf prefix and s7.2 value leads the tags to be = marked as system tags but what should happen if it isn't in the s7.2 = list? Should the parser ignore such tags, throw a fault and refuse to = parse the module or maybe treat them as user tags even if they are ietf = prefixed? =20 >=20 > Also if new prefixes are defined by other SDOs, as envisaged in the = last paragraph of s7.1, could or would these also be system tags? = Should there then be a flag or value in the registry to flag that tags = with this prefix should be marked as system or otherwise? >=20 > Thus also brings up another issue for the s7.1 registry. If another = organisation is defining a prefix there really need to be contact and = reference fields in the registry to specify the organisation maintaining = this prefix, especially if such a prefix had its own equivalent of the = s7.2 registry, and the document that introduces the prefix. >=20 > I suggest the authors discuss the appropriate status for the three = RFCs that I suggested should be normative and you disagreed with your = AD. It is a rather odd situation where a standards ltrack document is = updating an informational or BCP document, and also needing knowledge of = items described in BCPs. With the revised policy on downrefs, this can = be handled I believe. We are updating the BCP guidelines (RFC8407) , but nothing is relying on = them that I see. I would have thought text that updates informative text = is treated as informative, this could be my ignorance showing. RFC8340 being informative is what all the other yang documents = (including RFCs) I=E2=80=99ve seen do as well. RFC8199 is informative, the values themselves are normative only in the = sense that they are being reserved. Again, maybe I=E2=80=99m wrong. = I=E2=80=99d prefer to be told so and then I=E2=80=99ll just move the = reference. I guess I don=E2=80=99t understand things well enough is all. Can you be = specific about the objections with each of the 3 references? Thanks, Chris. >=20 > Cheers, > Elwyn >=20 > Sent from Samsung tablet. >=20 > -------- Original message -------- > From: Christian Hopps > Date: 06/03/2019 22:55 (GMT+00:00) > To: Elwyn Davies > Cc: gen-art@ietf.org, Christian Hopps , = draft-ietf-netmod-module-tags.all@ietf.org, "" = , netmod@ietf.org > Subject: Re: [Gen-art] [netmod] Genart last call review of = draft-ietf-netmod-module-tags-06 >=20 > [I covered this in the previous reply I just sent, and updated the = model text in response too..] >=20 > The intent here is to not restrict users of tags where we don't have = to. The prefix is only intended to avoid collision between disconnected = groups (designers, implementers and users), since users are the final = group to add/modify/use the tags we don't need to restrict them (and so = we shouldn't). >=20 > Thanks, > Chris. >=20 > > On Mar 6, 2019, at 2:39 PM, Elwyn Davies = wrote: > >=20 > > Hi. > >=20 > > After completing my review, I realized that there was a further = minor issue related to the possible values of tag prefixes, possible = values of standardized prefixes and behaviour of implementations in the = face of tag prefixes or values that are not in the relevant registries. > >=20 > > I think that the text in s2 should be reinforced to emphasise that = the only prefixes that should be expected are those in the IANA registry = defined in s7.1. > >=20 > > Either a new section or possibly in s3 text should be added to = define the behaviour of YANG implementations that encounter tags with = prefixes that are not in the s7.1 registry and tags with prefix ietf: = that are not in the s7.2 registry. > >=20 > > Regards, > > Elwyn Davies > >=20 > >=20 > >=20 > >=20 > >=20 > > Sent from Samsung tablet. > >=20 > > -------- Original message -------- > > From: Datatracker on behalf of Elwyn Davies = > > Date: 06/03/2019 00:26 (GMT+00:00) > > To: gen-art@ietf.org > > Cc: draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, = netmod@ietf.org > > Subject: [Gen-art] Genart last call review of = draft-ietf-netmod-module-tags-06 > >=20 > > Reviewer: Elwyn Davies > > Review result: Almost Ready > >=20 > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > >=20 > > For more information, please see the FAQ at > >=20 > > . > >=20 > > Document: draft-ietf-netmod-module-tags-06 > > Reviewer: Elwyn Davies > > Review Date: 2019-03-05 > > IETF LC End Date: 2019-03-03 > > IESG Telechat date: Not scheduled for a telechat > >=20 > > Summary: > > Almost ready. There are a couple of minor issues and a small number = of nits. > > Apologies for the slightly late delivery of the review. > >=20 > > Major issues: > > None > >=20 > > Minor issues: > > Abstract/s1: I would judge that RFC 8407 ought to be normative since = it is > > updated. > >=20 > > S4.2: using the Netmod working group as contact point for the module = is not > > future proof. I am not sure what the correct contact ought to be: = IESG? > >=20 > > S7.2: [This is a thought that occurred to me...] ought there to be = an ietf: > > security tag? > >=20 > > S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative > >=20 > > Nits/editorial comments: > > Abstract: s/modules/module's/ > >=20 > > Abstract: > > OLD: > > This document also provides guidance to future model writers, as = such, this > > document updates RFC8407. > >=20 > > NEW: > > This document also provides guidance to future model writers; as = such, this > > document updates RFC8407. > >=20 > > ENDS > >=20 > > S1.1, title: s/use cases of/use cases for/ > >=20 > > S1.1, para 1: s/documents progression/document's development/ > >=20 > > S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/ > >=20 > > S1.1, para 4: s/e.g./e.g.,/ > >=20 > > S2, para 1: > > > All tags SHOULD begin with a prefix indicating who owns their = definition. > >=20 > > If I read correctly, the YANG definition in s4.2 REQUIRES that all = tags have a > > prefix. For clarity, it would better if this read: > > All tags MUST begin with a prefix; it is intended that this = prefix SHOULD > > [or maybe 'should'] indicate > > the ownership or origination of the definition. > >=20 > > S2, para 1: s/yang type/YANG type/ (I think) > >=20 > > S2.2: s/follwing/following/ > >=20 > > S3.1, para 2: > > OLD: > > If the module definition is IETF standards track, the tags MUST also = be Section > > 2.1. Thus, new modules can drive the addition of new standard tags = to the IANA > > registry, and the IANA registry can serve as a check against = duplication. > >=20 > > NEW: > > If the module is defined in an IETF standards track document, the = tags MUST use > > the prefix defined in Section 2.1. Thus, definitions of new modules = can drive > > the addition of new standard tags to the IANA registry defined in = Section 7.2, > > and the IANA registry can serve as a check against duplication. > >=20 > > ENDS > >=20 > > S3.2: s/standard/IETF Standard/ > >=20 > > S3.3: It would be useful to introduce the term 'masking' used later = in the YANG > > module definition. > >=20 > > S4.1: I think this usage of RFC 8340 makes it normative. > >=20 > > S4.2, extension module-tag definition: This should contain a pointer = to RFC > > 8342 which discusses the system origin concept. > >=20 > > Major issues: > >=20 > > Minor issues: > >=20 > > Nits/editorial comments: > >=20 > >=20 > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_08F0DA5A-B177-472B-AB3F-E9E483196659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 7, 2019, at 17:50, Elwyn Davies <elwynd@dial.pipex.com> wrote:

Hi, Christian.

Thanks for the quick = response.

I = understand your intent, but the intent and the specification appear to = be in conflict.

The pattern for tags is
=          pattern = '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+';  

This REQUIRES two = character strings separated by a colon unless I have totally forgotten = how to read such patterns. Thus all tags have a prefix of the form = [a-zA-Z_][a-zA-Z0-9-_]* and a part after the colon that is essentially = unconstrained.

Your right the pattern was wrong and needs to be = fixed.

S2 limits the values of the prefixes to those = defined in the IANA registry of s7.1.. Further the values of the second = part are constrained by the s7.2 registry if the prefix is = ietf:.

So, = what should a YANG parser do when building datastores as per RFC 8342 if = a tag prefix is not one of the ones in the s7.1 registry? Likewise if = the prefix is ietf: and the whole tag is not in the s7.2 = registry?

A YANG = server should never place any restrictions on the tag values. There=E2=80=99= s need for this limiting and well known justification not to (applying = Postel=E2=80=99s Law/Robustness principle here).

If you want to make the presence of the prefix a SHOULD then = I think you need to adapt the pattern to make the whole prefix part = optional.  However that doesn't get away from describing what the = parser should do if it finds a prefix it doesn't know = about. 

Assuming the pattern is fixed, do we really have = to call out the fact that something marked as a SHOULD should not be = treated as a MUST? That seems like what your asking for, perhaps I=E2=80=99= m missing the point though. Are you just asking for a blurb saying = parsers must not restrict tag values? That seems like restating but if = it moves things forward I=E2=80=99m amiable. :)

Additionally, I am not clear how the parser knows which tags = should be marked as 'system' in the datastore as mentioned in the YANG = module comments. 

B/c it (the server) put them there, not the = user.

Maybe it is that the ietf prefix and s7.2 = value leads the tags to be marked as system tags but what should happen = if it isn't in the s7.2 list?  Should the parser ignore such tags, = throw a fault and refuse to parse the module or maybe treat them as user = tags even if they are ietf prefixed?  

Also if new prefixes are defined by = other SDOs, as envisaged in the last paragraph of s7.1, could or would = these also be system tags?  Should there then be a flag or value in = the registry to flag that tags with this prefix should be marked as = system or otherwise?

Thus also brings up another issue for the s7.1 = registry.  If another organisation is defining a prefix there = really need to be contact and reference fields in the registry to = specify the organisation maintaining this prefix, especially if such a = prefix had its own equivalent of the s7.2 registry, and the document = that introduces the prefix.

I suggest the authors discuss the appropriate status for the = three RFCs that I suggested should be normative and you disagreed with = your AD.  It is a rather odd situation where a standards ltrack = document is updating an informational or BCP document, and also needing = knowledge of items described in BCPs.  With the revised policy on = downrefs, this can be handled I = believe.

We = are updating the BCP guidelines (RFC8407) , but nothing is relying on = them that I see. I would have thought text that updates informative text = is treated as informative, this could be my ignorance showing.

RFC8340 being informative is = what all the other yang documents (including RFCs) I=E2=80=99ve seen do = as well.

RFC8199 is informative, the = values themselves are normative only in the sense that they are being = reserved. Again, maybe I=E2=80=99m wrong. I=E2=80=99d prefer to be told = so and then I=E2=80=99ll just move the reference.

I guess I don=E2=80=99t understand things well = enough is all. Can you be specific about the objections with each of the = 3 references?

Thanks,
Chris.


Cheers,
Elwyn

Sent from = Samsung tablet.

-------- = Original message --------
From: Christian Hopps = <chopps@chopps.org>
Date: = 06/03/2019 22:55 (GMT+00:00)
To: Elwyn Davies = <elwynd@dial.pipex.com>
Cc: gen-art@ietf.org, = Christian Hopps <chopps@chopps.org>, draft-ietf-netmod-module-tags.all@ietf.org, "<ietf@ietf.org>" <ietf@ietf.org>, netmod@ietf.org =
Subject: Re: [Gen-art] [netmod] Genart last call = review of draft-ietf-netmod-module-tags-06

[I covered this in the previous reply I just = sent, and updated the model text in response too..]

The intent here is to not restrict users of tags where we = don't have to. The prefix is only intended to avoid collision between = disconnected groups (designers, implementers and users), since users are = the final group to add/modify/use the tags we don't need to restrict = them (and so we shouldn't).

Thanks,
Chris.

> On Mar 6, 2019, at = 2:39 PM, Elwyn Davies <elwynd@dial.pipex.com> wrote:
>
> Hi.
>
> After = completing my review, I realized that there was a further minor issue = related to the possible values of tag prefixes, possible values of = standardized prefixes and behaviour of implementations in the face of = tag prefixes or values that are not in the relevant registries.
>
> I think that the text in s2 should = be reinforced to emphasise that the only prefixes that should be = expected are those in the IANA registry defined in s7.1.
>
> Either a new section or possibly in = s3 text should be added to define the behaviour of YANG implementations = that encounter tags with prefixes that are not in the s7.1 registry and = tags with prefix ietf: that are not in the s7.2 registry.
>
> Regards,
> Elwyn = Davies
>
>
>
>
>
> Sent from = Samsung tablet.
>
> -------- Original = message --------
> From: Datatracker on behalf of Elwyn = Davies <ietf-secretariat-reply@ietf.org>
> = Date: 06/03/2019 00:26 (GMT+00:00)
> To: gen-art@ietf.org
> Cc: draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, netmod@ietf.org
> Subject: [Gen-art] Genart last call review = of   draft-ietf-netmod-module-tags-06
>
> Reviewer: Elwyn Davies
> Review result: = Almost Ready
>
> I am the assigned = Gen-ART reviewer for this draft. The General Area
> = Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these = comments just
> like any other last call comments.
>
> For more information, please see the = FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: = draft-ietf-netmod-module-tags-06
> Reviewer: Elwyn = Davies
> Review Date: 2019-03-05
> = IETF LC End Date: 2019-03-03
> IESG Telechat date: Not = scheduled for a telechat
>
> = Summary:
> Almost ready.  There are a couple of = minor issues and a small number of nits.
> Apologies = for the slightly late delivery of the review.
>
> Major issues:
> None
> =
> Minor issues:
> Abstract/s1: I = would judge that RFC 8407 ought to be normative since it is
> updated.
>
> S4.2: = using the Netmod working group as contact point for the module is not
> future proof.  I am  not sure what the correct = contact ought to be: IESG?
>
> S7.2: = [This is a thought that occurred to me...] ought there to be an ietf:
> security tag?
>
> S9: = I would consider RFCs 8199, 8340, 8342 and 8407 to be normative
>
> Nits/editorial comments:
> Abstract: s/modules/module's/
>
> Abstract:
> OLD:
> = This document also provides guidance to future model writers, as such, = this
> document updates RFC8407.
>
> NEW:
> This document also provides = guidance to future model writers; as such, this
> = document updates RFC8407.
>
> ENDS
>
> S1.1, title: s/use cases of/use = cases for/
>
> S1.1, para 1: = s/documents progression/document's development/
>
> S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/
>
> S1.1, para 4: s/e.g./e.g.,/
>
> S2, para 1:
>    > All tags SHOULD begin with a = prefix indicating who owns their definition.
>
> If I read correctly, the YANG definition in s4.2 = REQUIRES that all tags have a
> prefix.  For = clarity, it would better if this read:
>    All tags MUST begin with a prefix; it = is intended that this prefix SHOULD
>    = [or maybe 'should'] indicate
>  the ownership or = origination of the definition.
>
> = S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> = If the module definition is IETF standards track, the tags MUST also be = Section
> 2.1. Thus, new modules can drive the addition = of new standard tags to the IANA
> registry, and the = IANA registry can serve as a check against duplication.
>=
> NEW:
> If the module is defined in = an IETF standards track document, the tags MUST use
> = the prefix defined in Section 2.1. Thus, definitions of new modules can = drive
> the addition of new standard tags to the IANA = registry defined in Section 7.2,
> and the IANA = registry can serve as a check against duplication.
> =
> ENDS
>
> S3.2: = s/standard/IETF Standard/
>
> S3.3: = It would be useful to introduce the term 'masking' used later in the = YANG
> module definition.
>
> S4.1: I think this usage of RFC 8340 makes it = normative.
>
> S4.2, extension = module-tag definition: This should contain a pointer to RFC
> 8342 which discusses the system origin concept.
>
> Major issues:
>
> Minor issues:
>
> = Nits/editorial comments:
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_08F0DA5A-B177-472B-AB3F-E9E483196659-- From nobody Thu Mar 7 21:28:45 2019 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 A67E6130E13; Thu, 7 Mar 2019 21:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 niuWTQFYtB3V; Thu, 7 Mar 2019 21:28:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D1363127133; Thu, 7 Mar 2019 21:28:41 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E9D45E8129FAEF5CCAF3; Fri, 8 Mar 2019 05:28:39 +0000 (GMT) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 05:28:39 +0000 Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 8 Mar 2019 05:28:39 +0000 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 8 Mar 2019 05:28:39 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Fri, 8 Mar 2019 13:28:30 +0800 From: Rohit R Ranade To: Christian Hopps CC: Joel Jaeggli , "ibagdona@gmail.com" , "netmod-chairs@ietf.org" , "iesg-secretary@ietf.org" , "netmod@ietf.org" Thread-Topic: Comments on draft-ietf-netmod-module-tags-06//RE: [netmod] Few Comments ////RE: Publication has been requested for draft-ietf-netmod-module-tags-04 Thread-Index: AdTVb6XPNLD0t3WYRcatsCQZ2M4tBw== Date: Fri, 8 Mar 2019 05:28:30 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BD088C6@dggeml510-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.150.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Comments on draft-ietf-netmod-module-tags-06//RE: Few Comments ////RE: Publication has been requested for draft-ietf-netmod-module-tags-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 05:28:45 -0000 Hi, While looking at Section 3.1, it looks like this document does not mandate = that all IETF drafts in future MUST have atleast one module-tag. Is this co= rrect ? Or whether it is better that future IETF draft MUST/SHOULD have at = least one IETF tag ? =20 Consider modules like "ietf-yang-types" and similar which provide common de= finitions, what will be the tags for such modules ?=20 Editorial: ------------ Section 4.1 "If the module definition is IETF standards track, the tags MUST also be Section 2.1. " =3D=3D> s/ MUST also be Section 2.1. / MUST also adher= e to Section 2.1./ ? With Regards, Rohit -----Original Message----- From: Rohit R Ranade=20 Sent: 21 February 2019 14:14 To: 'Christian Hopps' Cc: Joel Jaeggli ; ibagdona@gmail.com; netmod-chairs@ietf= .org; iesg-secretary@ietf.org; netmod@ietf.org Subject: RE: [netmod] Few Comments //RE: Publication has been requested for= draft-ietf-netmod-module-tags-04 Hi, Please find inline. -----Original Message----- From: Christian Hopps [mailto:chopps@chopps.org]=20 Sent: 21 February 2019 13:54 To: Rohit R Ranade Cc: Christian Hopps ; Joel Jaeggli ; i= bagdona@gmail.com; netmod-chairs@ietf.org; iesg-secretary@ietf.org; netmod@= ietf.org Subject: Re: [netmod] Few Comments //RE: Publication has been requested for= draft-ietf-netmod-module-tags-04 > On Feb 20, 2019, at 10:40 PM, Rohit R Ranade wr= ote: >=20 > Hi Christian, >=20 > 2 points are missing from the IANA registry, "Updates to the IETF XML Reg= istry" and "Updates to the YANG Module Names Registry", you can refer to RF= C 8342 section 8 for registering the new module and namespace. Will add, thanks. > Also w.r.t "ietf:", whether we can make it "sdo:" and ask ietf modules to= start their tags as "sdo:ietf:xxxx" , because all the other SDO will need = to register their organization prefixes once with IANA. This will also kee= p it at the same level where each vendor will also define his tags as "vend= or:vendor-name:xxxxx" etc. Since this isn't fixing something that's broken, and in fact is going again= st what was talked about and agreed to in the WG during the document develo= pment time, it's not an appropriate change to consider at this very late st= age in the process. [Rohit R Ranade] OK, If the WG has decided then I concede on this point. Thanks, Chris. >=20 > With Regards, > Rohit >=20 > -----Original Message----- > From: Christian Hopps [mailto:chopps@chopps.org] > Sent: 18 February 2019 14:57 > To: Rohit R Ranade > Cc: Christian Hopps ; Joel Jaeggli=20 > ; ibagdona@gmail.com; netmod-chairs@ietf.org;=20 > iesg-secretary@ietf.org; netmod@ietf.org > Subject: Re: [netmod] Few Comments //RE: Publication has been=20 > requested for draft-ietf-netmod-module-tags-04 >=20 >=20 > Rohit R Ranade writes: >=20 >> Hi, >>=20 >> Thank you for accepting the comments. Few more comments from my side. >>=20 >> Technical: >> 1. Section 8.1, " could allocate a top level prefix ", I think there is = no concept of top-level prefix now. I think this is a remnant of the versio= ns posted earlier where you had examples of multiple prefixes in a tag. Can= be removed now I think. >=20 > Indeed! I'll remove "top level", as there are no levels. >=20 >> 2. Why should the prefix contain ietf: , vendor:, user: ? I think the s= econd part of the prefix is more important for classification because most = of the vendors / sdo already define their own prefixes for their module-nam= e based on RFC7950 guideline in Section 5.1. By adding the prefix, I feel i= t will reduce the re-usability by other SDO / vendors. >=20 > Well the second part of the tag is the tag itself, the prefix is simply t= here to avoid collision between the module authors in various SDOs, the mod= ule implementers, and the module users. >=20 >> 3. Consider we have defined a module example-bgp which is similar to iet= f-bgp. >> If we need to add tags to example-bgp, then we need to define new "vendo= r:" prefixes for this even if it uses some IETF protocols ? >=20 > "ietf:" tags are allocated with IETF documents which is what the registry= policy "IETF Review" indicates. >=20 > However, this is an allocation policy not a USE policy. As module designe= r you get to pick whatever tags you think apply (which is what section 4.1 = says). >=20 >> I think we need to add more clarity in this document as to when the "iet= f:" prefix can be used by a module ? Whether a vendor module can/cannot use= standard tags ? >> Consider a module which has some part of vendor and some part of IETF pr= otocol , whether vendor can use "ietf:" tags then ? >> I suggest adding one more example in this document which may indicate/cl= arify your stand regarding this point. >=20 > Again, if you are creating your own module then you can choose whatever t= ags you want to add to it (section 4.1). >=20 > I've changed the headings under section 4 to: >=20 > 4.1 "Module Definition Tagging" > 4.2 "Implementation Tagging" > 4.3 "User Tagging" >=20 > and split 4.1 into 2 paragraphs (at "If the") to better separate the IETF= part away from the anyone part. >=20 >> 4. By defining a module tag as an extension, there is no way to validate= this extension's argument during YANG compilation (even though a pattern i= s defined). The existing YANG compiler tools will be forced to do hard-codi= ng for this. Whether there should be a note to Yang Compiler Developers in = this document for clarity ? >=20 > Well the WG wanted the extension, originally it was just part of a=20 > comment in the module definition. I think yang compiler developers (a=20 > very small group compared to the other users of this document) can=20 > probably figure this out without extra text. :) >=20 >> Please not that all these points originated in my mind, by thinking as t= o how I will use these tags. On the whole, I like the idea and thank you an= d the co-authors for documenting this. >=20 > Thanks! > Chris. >=20 >>=20 >> With Regards, >> Rohit R >>=20 >> -----Original Message----- >> From: Christian Hopps [mailto:chopps@chopps.org] >> Sent: 16 February 2019 00:27 >> To: Rohit R Ranade >> Cc: Christian Hopps ; Joel Jaeggli=20 >> ; ibagdona@gmail.com; netmod-chairs@ietf.org;=20 >> iesg-secretary@ietf.org; netmod@ietf.org >> Subject: Re: [netmod] Few Comments //RE: Publication has been=20 >> requested for draft-ietf-netmod-module-tags-04 >>=20 >>=20 >>=20 >>> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade w= rote: >>>=20 >>> Editorial Comments: >>> 1. Section 1, refers to RFC6020 for Yang Module, but since this=20 >>> document uses Yang Version 1.1, I feel it should refer to RFC7950 2. S= ection 4.3, " removed with using normal configuration", can use "removed by= using normal configuration" >>=20 >> Done >>=20 >>> 3. Description of statement "leaf-list tag", in the Step 1), " System = added tags are added" can be replaced with "tags of 'system' origin are add= ed" as it associates System with "system" origin in a better way. >>=20 >> Adopted with modification. Trying to keep things more readable but still= well specified. >>=20 >> 1) System tags (i.e., tags of 'system' origin) are added. >> 2) User configured tags (i.e., tags of 'intended' origin) >> are added. >> 3) Any tag that is equal to a masked-tag is removed."; >>=20 >>> 4. Description of statement "leaf-list tag", " The operational view of= this list", can be replaced with "The applied configuration of this list",= as it uses is a well-known term from RFC 8342. >>=20 >> NEW: >> The 'operational' state [RFC8342] view of this list is >> constructed using the following steps: >>=20 >>=20 >>> 5. Description of statement "leaf-list tag", " User configured tags" >>> can be replaced with "tags of 'intended' origin" as it uses a=20 >>> well-known NMDA term from RFC8342 >>=20 >> Adopted with mod, See above. >>=20 >>> Technical: >>> 1. Section 4.2, "These tags may be standard or vendor specific tags". = Does this statement exclude other tags from being added by implementations = ? If it does not exclude, I feel this statement can be removed. >>=20 >> Going to leave this, standard tags and vendor tags are tags with a speci= fic prefix. >>=20 >>> 2. In the description of Yang statement "leaf-list tag", is there any r= eason why System tags should be added first and then User configured tags ?= Not clear. >>=20 >> This is just the way it worked out on the mailing list. Doesn't hurt to = specify an order. >>=20 >>> 3. Description of statement "leaf-list masked-tag", " This user can rem= ove (mask) tags", I think we need to clarify that it will not "apply" the t= ags which have been configured as "masked-tags", because they are not "remo= ved" from any configuration datastore. >>> The tags which have been masked will be present in , but will= not be present in . >>> Suggested description >>> " The list of tags that will not be applied to this module. By=20 >>> adding tags to this list, the user can prevent such tags from being app= lied. >>> It is not an error to add tags to this list that are not associated=20 >>> with the module." >>=20 >> I'm not sure about making these changes. I think the current text (with = the modification below) is pretty clear in what is meant, and delving so de= eply into NMDA gets distracting, and could in fact end up being wrong (e.g.= , I think of tags being associated with a module not applied to them). >>=20 >> I did make the change to the enumerated list to show what is meant by "S= ystem" and "User", and in the spirit of your suggestion, I did change it to= be more specific about operational state datastore. >>=20 >> "The list of tags that should not be associated with this >> module. The user can remove (mask) tags from the >> operational state datastore [RFC8342] by adding them to >> this list. It is not an error to add tags to this list >> that are not associated with the module, but they have no >> operational effect."; >>=20 >> Thanks for the review! >>=20 >> Chris. >>=20 >>=20 >>>=20 >>>=20 >>> With Regards, >>> Rohit R >>>=20 >>>=20 >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Joel=20 >>> Jaeggli >>> Sent: 13 February 2019 05:20 >>> To: ibagdona@gmail.com >>> Cc: netmod-chairs@ietf.org; Joel Jaeggli ;=20 >>> iesg-secretary@ietf.org; netmod@ietf.org >>> Subject: [netmod] Publication has been requested for >>> draft-ietf-netmod-module-tags-04 >>>=20 >>> Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags= -04 as Proposed Standard on behalf of the NETMOD working group. >>>=20 >>> Please verify the document's state at=20 >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ >>>=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 From nobody Thu Mar 7 23:11:30 2019 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 88970130E09; Thu, 7 Mar 2019 23:11:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155202908349.5373.15205929918149184901@ietfa.amsl.com> Date: Thu, 07 Mar 2019 23:11:23 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:11:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Data Structure Extensions Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netmod-yang-data-ext-02.txt Pages : 14 Date : 2019-03-07 Abstract: This document describes YANG mechanisms for defining abstract data structures with YANG. It is intended to replace and extend the "yang-data" extension statement defined in RFC 8040. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-data-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-data-ext-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 8 04:01:00 2019 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 992A01279A1; Fri, 8 Mar 2019 04:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 2DeXBvCfe-uy; Fri, 8 Mar 2019 04:00:56 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 076D6127983; Fri, 8 Mar 2019 04:00:56 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id E24AD60519; Fri, 8 Mar 2019 07:00:54 -0500 (EST) References: <991B70D8B4112A4699D5C00DDBBF878A6BD088C6@dggeml510-mbx.china.huawei.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Rohit R Ranade Cc: Christian Hopps , Joel Jaeggli , "ibagdona\@gmail.com" , "netmod-chairs\@ietf.org" , "iesg-secretary\@ietf.org" , "netmod\@ietf.org" In-reply-to: <991B70D8B4112A4699D5C00DDBBF878A6BD088C6@dggeml510-mbx.china.huawei.com> Date: Fri, 08 Mar 2019 07:00:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Comments on draft-ietf-netmod-module-tags-06//RE: Few Comments ////RE: Publication has been requested for draft-ietf-netmod-module-tags-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:00:59 -0000 --=-=-= Content-Type: text/plain; format=flowed Rohit R Ranade writes: > Hi, > > While looking at Section 3.1, it looks like this document does not mandate that all IETF drafts in future MUST have atleast one module-tag. Is this correct ? Or whether it is better that future IETF draft MUST/SHOULD have at least one IETF tag ? Correct, we aren't mandating tag use. > Consider modules like "ietf-yang-types" and similar which provide common definitions, what will be the tags for such modules ? > > Editorial: > ------------ > Section 4.1 > "If the module definition is IETF standards track, the tags MUST also > be Section 2.1. " ==> s/ MUST also be Section 2.1. / MUST also adhere to Section 2.1./ ? I corrected this based on the GenART review (the odd text was a tool use error on my part). "... If the module is defined in an IETF standards track document, the tags MUST be IETF Standard Tags (2.1). ..." I've been waiting to publish corrections until after the GenART review is done. Thanks, Chris. > > With Regards, > Rohit > > -----Original Message----- > From: Rohit R Ranade > Sent: 21 February 2019 14:14 > To: 'Christian Hopps' > Cc: Joel Jaeggli ; ibagdona@gmail.com; netmod-chairs@ietf.org; iesg-secretary@ietf.org; netmod@ietf.org > Subject: RE: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 > > Hi, > > Please find inline. > > > -----Original Message----- > From: Christian Hopps [mailto:chopps@chopps.org] > Sent: 21 February 2019 13:54 > To: Rohit R Ranade > Cc: Christian Hopps ; Joel Jaeggli ; ibagdona@gmail.com; netmod-chairs@ietf.org; iesg-secretary@ietf.org; netmod@ietf.org > Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 > > > >> On Feb 20, 2019, at 10:40 PM, Rohit R Ranade wrote: >> >> Hi Christian, >> >> 2 points are missing from the IANA registry, "Updates to the IETF XML Registry" and "Updates to the YANG Module Names Registry", you can refer to RFC 8342 section 8 for registering the new module and namespace. > > Will add, thanks. > >> Also w.r.t "ietf:", whether we can make it "sdo:" and ask ietf modules to start their tags as "sdo:ietf:xxxx" , because all the other SDO will need to register their organization prefixes once with IANA. This will also keep it at the same level where each vendor will also define his tags as "vendor:vendor-name:xxxxx" etc. > > Since this isn't fixing something that's broken, and in fact is going against what was talked about and agreed to in the WG during the document development time, it's not an appropriate change to consider at this very late stage in the process. > [Rohit R Ranade] OK, If the WG has decided then I concede on this point. > > Thanks, > Chris. > >> >> With Regards, >> Rohit >> >> -----Original Message----- >> From: Christian Hopps [mailto:chopps@chopps.org] >> Sent: 18 February 2019 14:57 >> To: Rohit R Ranade >> Cc: Christian Hopps ; Joel Jaeggli >> ; ibagdona@gmail.com; netmod-chairs@ietf.org; >> iesg-secretary@ietf.org; netmod@ietf.org >> Subject: Re: [netmod] Few Comments //RE: Publication has been >> requested for draft-ietf-netmod-module-tags-04 >> >> >> Rohit R Ranade writes: >> >>> Hi, >>> >>> Thank you for accepting the comments. Few more comments from my side. >>> >>> Technical: >>> 1. Section 8.1, " could allocate a top level prefix ", I think there is no concept of top-level prefix now. I think this is a remnant of the versions posted earlier where you had examples of multiple prefixes in a tag. Can be removed now I think. >> >> Indeed! I'll remove "top level", as there are no levels. >> >>> 2. Why should the prefix contain ietf: , vendor:, user: ? I think the second part of the prefix is more important for classification because most of the vendors / sdo already define their own prefixes for their module-name based on RFC7950 guideline in Section 5.1. By adding the prefix, I feel it will reduce the re-usability by other SDO / vendors. >> >> Well the second part of the tag is the tag itself, the prefix is simply there to avoid collision between the module authors in various SDOs, the module implementers, and the module users. >> >>> 3. Consider we have defined a module example-bgp which is similar to ietf-bgp. >>> If we need to add tags to example-bgp, then we need to define new "vendor:" prefixes for this even if it uses some IETF protocols ? >> >> "ietf:" tags are allocated with IETF documents which is what the registry policy "IETF Review" indicates. >> >> However, this is an allocation policy not a USE policy. As module designer you get to pick whatever tags you think apply (which is what section 4.1 says). >> >>> I think we need to add more clarity in this document as to when the "ietf:" prefix can be used by a module ? Whether a vendor module can/cannot use standard tags ? >>> Consider a module which has some part of vendor and some part of IETF protocol , whether vendor can use "ietf:" tags then ? >>> I suggest adding one more example in this document which may indicate/clarify your stand regarding this point. >> >> Again, if you are creating your own module then you can choose whatever tags you want to add to it (section 4.1). >> >> I've changed the headings under section 4 to: >> >> 4.1 "Module Definition Tagging" >> 4.2 "Implementation Tagging" >> 4.3 "User Tagging" >> >> and split 4.1 into 2 paragraphs (at "If the") to better separate the IETF part away from the anyone part. >> >>> 4. By defining a module tag as an extension, there is no way to validate this extension's argument during YANG compilation (even though a pattern is defined). The existing YANG compiler tools will be forced to do hard-coding for this. Whether there should be a note to Yang Compiler Developers in this document for clarity ? >> >> Well the WG wanted the extension, originally it was just part of a >> comment in the module definition. I think yang compiler developers (a >> very small group compared to the other users of this document) can >> probably figure this out without extra text. :) >> >>> Please not that all these points originated in my mind, by thinking as to how I will use these tags. On the whole, I like the idea and thank you and the co-authors for documenting this. >> >> Thanks! >> Chris. >> >>> >>> With Regards, >>> Rohit R >>> >>> -----Original Message----- >>> From: Christian Hopps [mailto:chopps@chopps.org] >>> Sent: 16 February 2019 00:27 >>> To: Rohit R Ranade >>> Cc: Christian Hopps ; Joel Jaeggli >>> ; ibagdona@gmail.com; netmod-chairs@ietf.org; >>> iesg-secretary@ietf.org; netmod@ietf.org >>> Subject: Re: [netmod] Few Comments //RE: Publication has been >>> requested for draft-ietf-netmod-module-tags-04 >>> >>> >>> >>>> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade wrote: >>>> >>>> Editorial Comments: >>>> 1. Section 1, refers to RFC6020 for Yang Module, but since this >>>> document uses Yang Version 1.1, I feel it should refer to RFC7950 2. Section 4.3, " removed with using normal configuration", can use "removed by using normal configuration" >>> >>> Done >>> >>>> 3. Description of statement "leaf-list tag", in the Step 1), " System added tags are added" can be replaced with "tags of 'system' origin are added" as it associates System with "system" origin in a better way. >>> >>> Adopted with modification. Trying to keep things more readable but still well specified. >>> >>> 1) System tags (i.e., tags of 'system' origin) are added. >>> 2) User configured tags (i.e., tags of 'intended' origin) >>> are added. >>> 3) Any tag that is equal to a masked-tag is removed."; >>> >>>> 4. Description of statement "leaf-list tag", " The operational view of this list", can be replaced with "The applied configuration of this list", as it uses is a well-known term from RFC 8342. >>> >>> NEW: >>> The 'operational' state [RFC8342] view of this list is >>> constructed using the following steps: >>> >>> >>>> 5. Description of statement "leaf-list tag", " User configured tags" >>>> can be replaced with "tags of 'intended' origin" as it uses a >>>> well-known NMDA term from RFC8342 >>> >>> Adopted with mod, See above. >>> >>>> Technical: >>>> 1. Section 4.2, "These tags may be standard or vendor specific tags". Does this statement exclude other tags from being added by implementations ? If it does not exclude, I feel this statement can be removed. >>> >>> Going to leave this, standard tags and vendor tags are tags with a specific prefix. >>> >>>> 2. In the description of Yang statement "leaf-list tag", is there any reason why System tags should be added first and then User configured tags ? Not clear. >>> >>> This is just the way it worked out on the mailing list. Doesn't hurt to specify an order. >>> >>>> 3. Description of statement "leaf-list masked-tag", " This user can remove (mask) tags", I think we need to clarify that it will not "apply" the tags which have been configured as "masked-tags", because they are not "removed" from any configuration datastore. >>>> The tags which have been masked will be present in , but will not be present in . >>>> Suggested description >>>> " The list of tags that will not be applied to this module. By >>>> adding tags to this list, the user can prevent such tags from being applied. >>>> It is not an error to add tags to this list that are not associated >>>> with the module." >>> >>> I'm not sure about making these changes. I think the current text (with the modification below) is pretty clear in what is meant, and delving so deeply into NMDA gets distracting, and could in fact end up being wrong (e.g., I think of tags being associated with a module not applied to them). >>> >>> I did make the change to the enumerated list to show what is meant by "System" and "User", and in the spirit of your suggestion, I did change it to be more specific about operational state datastore. >>> >>> "The list of tags that should not be associated with this >>> module. The user can remove (mask) tags from the >>> operational state datastore [RFC8342] by adding them to >>> this list. It is not an error to add tags to this list >>> that are not associated with the module, but they have no >>> operational effect."; >>> >>> Thanks for the review! >>> >>> Chris. >>> >>> >>>> >>>> >>>> With Regards, >>>> Rohit R >>>> >>>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Joel >>>> Jaeggli >>>> Sent: 13 February 2019 05:20 >>>> To: ibagdona@gmail.com >>>> Cc: netmod-chairs@ietf.org; Joel Jaeggli ; >>>> iesg-secretary@ietf.org; netmod@ietf.org >>>> Subject: [netmod] Publication has been requested for >>>> draft-ietf-netmod-module-tags-04 >>>> >>>> Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as Proposed Standard on behalf of the NETMOD working group. >>>> >>>> Please verify the document's state at >>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ >>>> >>>> _______________________________________________ >>>> 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 >>>> >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyCWXUACgkQLh2DDte4 MCUwJg//cynkwDLi5TcjZdydeZTBL42TvOfQ/r6oIQ+TEI/DyVrRVnh4UEEsVztb NhynPscxZRu02bledGlknjV9faLaMiIO6sIY5resq9VyBFpVy4sdDKn//e8uxFEQ WTH70Zh4aMuOxrFKP+sVuqZNlXalVBzif4E43OryU8er1CPpW2gR56sDqUvP34y9 KVUCju0Tnfc8ThzyDq42QJXYSuZ/34Q8m1co5ayB3uH5y0CT2O2noZHnKHMSMQPG zCk9jHh2VvSunu1ZUL5GJw8qsTDI+vNmlslGljM1ITKHRoATAqpP4KpTWsm8CHM6 L3w3/flgrQLJ+9wrUjuP+yb6snU5TpdxNWkLpl2pfe0XQVwALdQrGa/4wfJ059B3 zCaglsm5GLMMXk9JcHMys0Sk/cIakkE6lNUj9DfKFH/oatdv3uxf8Mlo7R99fpWQ +inOrYdMAUmItBQJr6+N9ChnwmiwNLtVoIAMpavQ7VpYaq2UAI6kGgfiWjLEE7OE JYHKitseAGcPY/hb+IGNia1Jw1ZeGbBg306HyemMY6q6f5wKp/FDWdb2u4ZAjrTs +B9wGC+U6dynblBveLViIV/a4Qmw+M+6sNPE1v7ytSqpVAdr7ea23ri53xiJ7Il2 6r8E+dytad8WIZMZl+FGYAsAwLyQfv4zKvyOe7WOQ31oBPplHZg= =DN6Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 8 04:24:07 2019 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 D5F3F1279A9 for ; Fri, 8 Mar 2019 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 YyXTAnA8iEGa for ; Fri, 8 Mar 2019 04:24:03 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 45E521279A1 for ; Fri, 8 Mar 2019 04:24:03 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 3CFE2182049A; Fri, 8 Mar 2019 13:23:47 +0100 (CET) Received: from localhost (unknown [172.29.2.111]) by trail.lhotka.name (Postfix) with ESMTPSA id B59791820047; Fri, 8 Mar 2019 13:23:42 +0100 (CET) From: Ladislav Lhotka To: Robert Varga , netmod@ietf.org In-Reply-To: <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> References: <20190307035909.4D3ACB824FD@rfc-editor.org> <32f9bf4f-8002-0d22-1291-7db9661d33e4@hq.sk> Mail-Followup-To: Robert Varga , netmod@ietf.org Date: Fri, 08 Mar 2019 13:23:56 +0100 Message-ID: <87tvgdd06b.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] RFC 8528 on YANG Schema Mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:24:06 -0000 Hi Robert, Robert Varga writes: > On 07/03/2019 04:59, rfc-editor@rfc-editor.org wrote: >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 8528 >> >> Title: YANG Schema Mount > > Awesome, congrats :) I have mixed feelings this time, really. > > One quick question: what are the sub-statements allowed under a > 'yangmnt:mount-point "foo"' ? I see RFC8529 is using 'description', but > could not find a definitive list. > > Can I assume it's only config/description/reference/status, or is it a > larger set? The yangmnt:mount-point extension is intended just as a label, so there is really no need for substatements, perhaps except description. Other information regarding the mount point should be in the state data under "schema-mounts/mount-point". For one, "config" is there. Lada > > Thanks, > Robert > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 8 12:27:12 2019 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 B2CBE1277CE; Fri, 8 Mar 2019 12:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJbm7p0KwxBq; Fri, 8 Mar 2019 12:26:53 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780119.outbound.protection.outlook.com [40.107.78.119]) (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 2007A124BA8; Fri, 8 Mar 2019 12:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XkKdezCRnZHHc56JR269fMuI/1LzDNCoO687EvOF/JE=; b=OLXOqzOb07UyBfHhBsAQV/9dBnToVgTWj5l2XaQ0NwHBCjkWFdVjR0LP8yHGzhvApvVxmPKowK3dl8WH1z3W8Sw5GDSgokISo+qntweBFeaufClUtDbXgYofaexWebcJkEPtl+4eKphv9cWGgPfFPj9RiVH/bRCfEjxih6EOKNU= Received: from SN2PR01CA0020.prod.exchangelabs.com (2603:10b6:804:2::30) by SN6PR0102MB3600.prod.exchangelabs.com (2603:10b6:805:5::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Fri, 8 Mar 2019 20:26:51 +0000 Received: from BY2NAM03FT006.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::208) by SN2PR01CA0020.outlook.office365.com (2603:10b6:804:2::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.17 via Frontend Transport; Fri, 8 Mar 2019 20:26:51 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT006.mail.protection.outlook.com (10.152.84.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Fri, 8 Mar 2019 20:26:51 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x28KQkDg004536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Mar 2019 15:26:48 -0500 Date: Fri, 8 Mar 2019 14:26:46 -0600 From: Benjamin Kaduk To: Christian Hopps CC: , , , Message-ID: <20190308202645.GY9824@kduck.mit.edu> References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(51914003)(189003)(199004)(55016002)(246002)(305945005)(1076003)(53416004)(6246003)(76176011)(33656002)(7696005)(478600001)(26005)(26826003)(53546011)(229853002)(186003)(75432002)(14444005)(50466002)(97756001)(316002)(58126008)(54906003)(786003)(88552002)(16586007)(8676002)(46406003)(106002)(2906002)(8936002)(356004)(36906005)(956004)(126002)(486006)(476003)(104016004)(336012)(23726003)(5660300002)(6916009)(47776003)(4326008)(86362001)(426003)(106466001)(11346002)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0102MB3600; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c8eed988-0026-4090-c285-08d6a40465cc X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:SN6PR0102MB3600; X-MS-TrafficTypeDiagnostic: SN6PR0102MB3600: X-Microsoft-Exchange-Diagnostics: 1; SN6PR0102MB3600; 20:RaBjkuT+MCMXZVaNR4cTKljlf43/pr08qhtLLtmq/AzRSJg+o+XiT2xsxP8Km0qv1IJDg9PDDjWrwR6ZNcQhMATPIhe/PvWYk+BvBPcp9XXqTo3miP/zIxLg9vKQQ5Q/4nhgW4cnIwhvGIPFsvfUkglRKFYTZ3BIMwVX7j4joRMdNHGWqt6gE5C4/HroU89DJhOpzLG1vbozu8Vc1cdIYoMk873hAWMf97URh0HPpZymTKXBI1rjD8l3HYCAcIrXwvZS+tkS/K2+CNSCW1OS4qVb4a0XYZSkRKbBVL6tJpGNTtcWmdoepn+nOn28FpHmqAB7MxC9DZx9YkVej/OcemTZoLzGXmZb8nbqhtuGbJ/b7PSyW8jQ9/BA/iXxTVqZWFg3YEzFHdPkywJpeBrzP/nkvnrJb+WlOK1jDsfF0h4pRKy6JeSWolY1Im5vntn8WEckHQrhJGZ/PDCxjJn6vbvt1OLAdQuClJnRsweh5ZzoQH6/Eo//jW168vhZiOtEEqJc265t24NYwOSkxyPT/eZ6cJBC7TV4Tb3tBk0IAA2a4Cb+R017pxX0Izl0kNTJvb06Ak3exhws3J2j3SRiR0dxMsx+li8r2lm+s2SQIF4= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0970508454 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR0102MB3600; 23:1oqmf0auX6h8Ssp2bKkPqPm9Zp8hpSeIwcNib1f?= =?us-ascii?Q?s/pa+W+DAeIF+7QvLv+YorncRpm6SO9gGgUamcpJaSotjDnj9WfbYKNTbYLF?= =?us-ascii?Q?1da7FJNZD7yHzEzod6wSFiVRCvotWdzowjkVvn/NItB92F5Sjl56qifo/H1w?= =?us-ascii?Q?OlTzEmN41AIRDAb9x+bSM8SIhYpPZsoVaE0kjAf0vunwlnHPUH9Eagb24sz0?= =?us-ascii?Q?u31Hz7pJ40VMM4Onxls2hJweiS6JfB7jRcBIu507bfIecbyowY84pNozZ+Kb?= =?us-ascii?Q?n5bQ539LMNmWR/djer2iOk7O2DpmM+xxwzLRy+OZ51GSXYxidyl4VaFKReKy?= =?us-ascii?Q?sN81C8XWOcvCY59g7tD4xyU7kHUa8lBlTw660lOEpUOr3UlYEk2QWl7/Lo3f?= =?us-ascii?Q?3ef+vh4a2PZPjPvhCMShyFdWiqBKgYALq6GrDYSJztM/GNv/e2fDHxp9lhn5?= =?us-ascii?Q?r14FyEjUMx778XYnAQpbhZlNbhg2OXYIoNuISJc6ApNnc5ZOK0iqFm+F1UJv?= =?us-ascii?Q?ZKYEqZtFCh63twM+qIIA94lPvFW0HErgeCuTSbUzIWvgY3KOeRaHQr8s7Bk7?= =?us-ascii?Q?HYfEU1LZryBpQmtMrX+BoVdOHJOPL6wjG0ukaI7/hd+fQdHp6+6HYMyItV/O?= =?us-ascii?Q?LfDhmo9PnT3qTSX2HIJcQU+TJ991yDa8vP5ypDVJxpWqsN4inEYjNmhXCnu3?= =?us-ascii?Q?7CcAVktto0SP9OsSkafz/2hbwT8QxfxRsI3hM7xYTQzNguobC3iHQc1R1dxD?= =?us-ascii?Q?ZQ6xHiJixuCejCLfJeL4hvH8TN1ifm8jtAzVPyLtR7grRnVUELaq5c6TCDTM?= =?us-ascii?Q?mNDJcyyxSi0bGLiRxjFaUD/rwSNedXLK3NW84S6AdfKtKzId8dGSLP6v2s9F?= =?us-ascii?Q?tT8/hTNSAfcDqIEtbqa9L5bT/Vzmn4uB/cz/0B3W/QHglGEe4V3Wv2bjpLR3?= =?us-ascii?Q?4j0vUkN9jW9W9kblOJ/gb8efpVghLXkjp11F5rgj/lf9ilT0NMZfo1m1T3F/?= =?us-ascii?Q?VUb/Z2RIhAw3Fakcp0CLQUj+T2W0Nk3lFNb9xuXywDccO3Pa02V+galrlpnu?= =?us-ascii?Q?K6JD3E6xAykY8BZCPDwrqCknYMldMSuGGoMKgMBQaswyBKa7V5JUPejmBpEX?= =?us-ascii?Q?y9Ke3ewg68VzzcidBd9sRD+cspbWDxPyFUeFE1lMOyv1oa/c2tnL+7qM2lqk?= =?us-ascii?Q?bt7oK2FbGXzQDLQVoG6OwXVtqXOA14IQIlsfJdZ4FLmQ+pUxUiw2Z9QA3pOi?= =?us-ascii?Q?7coZ5/BZz7tZgWVV3ICo=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: PHj/u6nCpYP+m8NW1DKL79ekaOVTPGPEyegyP7PJyIouAvzckV3gS3vA9A9C687lJLz379h6WB9kt57+5OLuB/C1jsZJZt4sLnnGbOGp0UjLGTrjtwgOvuO8U55r01X1uy22qMUdXUspptdhnXVhsMFRg2vqSU7SXWnty03oVjW13TxQDz5Hf+yVKnT4zNm3p3Ki/quedvjDspcmy54M7Kxyq4YpU+1cVpqyGsLUc5GkXZMNOOzEvVcXriHiYAsYS9HxU425XBDM1qnqphD6/f0fS0WVPWy4t5HZeWLuRCqPox+MaEG9dsH0p+2k/Xs1Fw3HeaRSoYDwpX4A2JZrokkV038TQg4TbglQ+0AqCd4Fgz6wGxY7eGkUY+nVjd+DhhL8zQQss0uzSdYZU6wbYjXnkkxL3DijwqfYbpF6kqs= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2019 20:26:51.0323 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c8eed988-0026-4090-c285-08d6a40465cc X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0102MB3600 Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 20:26:56 -0000 Going up to a more general topic (and ignoring the particulars here): On Wed, Mar 06, 2019 at 05:50:00PM -0500, Christian Hopps wrote: > Thanks for the review! Comments inline. > > > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies wrote: > > > > > > Minor issues: > > Abstract/s1: I would judge that RFC 8407 ought to be normative since it is > > updated. > > RFC8407 is a BCP not a Standard though so I don't think it's appropriate to make it normative. I'm confused by this statement. BCPs are considered to be standards-track, and a reference from a PS document to a BCP is not considered a downref. Is the objection that "best current practices" are just that (practices) and not part of a mandatory protocol specification? We do have BCP 195 (RFC 7525), "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", which are indeed recommendations and best practices for use of TLS in general, and as such can apply to anything using TLS, even existing deployed systems and protocols. But we can also have new protocols that say "it is mandatory to comply with the behavior described in RFC 7525", and to me that is a normative part of the spec. So I'd like a better understanding of your stance here. Thanks, Ben From nobody Sat Mar 9 04:26:42 2019 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 44522127817; Sat, 9 Mar 2019 04:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 sl-DVvbXx4W3; Sat, 9 Mar 2019 04:26:25 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2B1277DE; Sat, 9 Mar 2019 04:26:25 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 3759860504; Sat, 9 Mar 2019 07:26:24 -0500 (EST) References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> <20190308202645.GY9824@kduck.mit.edu> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Benjamin Kaduk Cc: Christian Hopps , gen-art@ietf.org, draft-ietf-netmod-module-tags.all@ietf.org, ietf@ietf.org, netmod@ietf.org In-reply-to: <20190308202645.GY9824@kduck.mit.edu> Date: Sat, 09 Mar 2019 07:26:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 12:26:26 -0000 --=-=-= Content-Type: text/plain; format=flowed I will move this reference to normative, I was confused. Thanks, Chris. Benjamin Kaduk writes: > Going up to a more general topic (and ignoring the particulars here): > > On Wed, Mar 06, 2019 at 05:50:00PM -0500, Christian Hopps wrote: >> Thanks for the review! Comments inline. >> >> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies wrote: >> > >> > >> > Minor issues: >> > Abstract/s1: I would judge that RFC 8407 ought to be normative since it is >> > updated. >> >> RFC8407 is a BCP not a Standard though so I don't think it's appropriate to make it normative. > > I'm confused by this statement. BCPs are considered to be standards-track, > and a reference from a PS document to a BCP is not considered a downref. > Is the objection that "best current practices" are just that (practices) > and not part of a mandatory protocol specification? > > We do have BCP 195 (RFC 7525), "Recommendations for Secure Use of Transport > Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", which > are indeed recommendations and best practices for use of TLS in general, > and as such can apply to anything using TLS, even existing deployed systems > and protocols. But we can also have new protocols that say "it is > mandatory to comply with the behavior described in RFC 7525", and to me > that is a normative part of the spec. > > So I'd like a better understanding of your stance here. > > Thanks, > > Ben --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyDsO8ACgkQLh2DDte4 MCVU0Q//QZpnWPkBgBXtICl1o24mcW9JmfZ4UNPekfrzoj1sEVxJLUvr9sd8JkJp c+Ak/stYbk953/+nYV8rhc2JWy5yVX3ic1DQwZb7rvrYWbrvWDG/oV+S0svdY9vM q1vNmAfZzPDoFdpayIYw9XIruuMz1EWkaHQDABzZBtLiiv19wMpcXMoFCrjxTGvd alHv6MS7llyWJlLzSy4BztAkPOjWRSHAsMS2snYGsPctS+OZJ5qtG61Q0aH7H+YG EBatiWyVoexAT/UcUz4ZJ3GA785SFQwNy02TRzpBWvrOiyc6wd3Mo3X0KuA1stDX HrP0YedFKa36bJKvNYEXEB3277s4qX9YXMe09cia0gh0ocjjkPp2HtORM6AsG+NC kKDxQJpeFviz15S99xPJEkBpT6K7ws0rAYs2lSJKcoktAqMxkPVtaYlnGvPewiqG PyJpbIphG2N4nli3ksnnm+Uonx6VHAOrE/ZSSHCqcg85ly2Y0E203Yspg7HSfMr0 SkvbvRBxv+jqQc3WvAbcxq/wmrPPX0M+4rHkXbjnSuFcEuAJhO/DhiATpRrT2f86 2Inwme/XWbxuHLCHqhE0L2xmkQKRqEYSzXSASrYXZObcEqPlf6a2H/nw73tZ3vht DznGTOM2V9muJYIXdSWzlLUWq3cGqDgbn1sah/W8sVg5Uu9czCk= =RWga -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 9 05:06:44 2019 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 E9ED012787D; Sat, 9 Mar 2019 05:06:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155213680293.28714.15804907588911277021@ietfa.amsl.com> Date: Sat, 09 Mar 2019 05:06:42 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-module-tags-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 13:06:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Module Tags Authors : Christian Hopps Lou Berger Dean Bogdanovic Filename : draft-ietf-netmod-module-tags-07.txt Pages : 16 Date : 2019-03-09 Abstract: This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be standardized and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC8407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-module-tags-07 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 10 11:55:24 2019 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 29460124B16; Sun, 10 Mar 2019 11:55:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155224411610.31073.4897051106295757328@ietfa.amsl.com> Date: Sun, 10 Mar 2019 11:55:16 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 18:55:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Handling Long Lines in Inclusions in Internet-Drafts and RFCs Authors : Kent Watsen Qin Wu Adrian Farrel Benoît Claise Filename : draft-ietf-netmod-artwork-folding-01.txt Pages : 20 Date : 2019-03-10 Abstract: This document introduces a simple and yet time-proven strategy for handling long lines in inclusions in drafts using a backslash ('\') character where line-folding has occurred. The strategy works on any text-based content, but is primarily intended for a structured sequence of lines, such as would be referenced by the element defined in Section 2.48 of RFC 7991, rather than for two- dimensional imagery, such as would be referenced by the element defined in Section 2.5 of RFC 7991. The approach produces consistent results, regardless of the content, that is both self- documenting and enables automated reconstitution of the original content. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-01 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-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 Mar 11 10:10:15 2019 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 5B52A1311DA for ; Mon, 11 Mar 2019 10:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 UERtSEe4E4Y0 for ; Mon, 11 Mar 2019 10:04:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5DE1311AA for ; Mon, 11 Mar 2019 10:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27930; q=dns/txt; s=iport; t=1552323877; x=1553533477; h=from:to:subject:date:message-id:mime-version; bh=XL93Olnw7SA8qpMqByInu8lryZFqvl3lLAzy8h/DvR0=; b=b5omxSreohCQ8WSiHW78CIknV9hA4jF+BZEjWecKXeodwjz0c1tAmpDb OTlvGPlk+fMexsJPZlqox/SaWG+RHKr489QhiN+Xp+6Q5uYPpi5MukZEF NOJN1b2XGY5OmIkHOYZij7iF8dSfp+AMuVJuC8TriuDiiRQOBZc+AIt3M 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAACTlIZc/5JdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDYECaIEDJwqDf4gaizOCDZgmgXsLAQElhEc?= =?us-ascii?q?CF4QjIjQJDQEBAwEBBwEDAm0cAQuFSgEBKApYBgEZBAEBIQoCBDAdCQEEEwg?= =?us-ascii?q?TgwiBEWQPsBSBL4Q0Ag5BhSmBLwGLLBeBQD+HQQEBAgEBgTYRgyCCVwOKFy+?= =?us-ascii?q?CBIQIHocMjCUJAodPizMhgXlYhQ6LW4p4gRKEU4xiAhEVgSgfOCiBLnAVGoM?= =?us-ascii?q?NCYVvhRSFP0ExAY1ygS6BHwEB?= X-IronPort-AV: E=Sophos;i="5.58,468,1544486400"; d="scan'208,217";a="523392506" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2019 17:04:11 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2BH4AS0023683 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Mar 2019 17:04:11 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 12:04:10 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 11 Mar 2019 12:04:10 -0500 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" Thread-Topic: YANG Semantic Versioning for Modules: draft-verdt-netmod-yang-semver-00.txt Thread-Index: AdTYLG//RyaQ5EdBSGq1wBR3Yth+4Q== Date: Mon, 11 Mar 2019 17:04:10 +0000 Message-ID: <3100c80d4d59419e9e115903298661a1@XCH-RCD-007.cisco.com> 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.61.162.185] Content-Type: multipart/alternative; boundary="_000_3100c80d4d59419e9e115903298661a1XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: [netmod] YANG Semantic Versioning for Modules: draft-verdt-netmod-yang-semver-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:04:51 -0000 --_000_3100c80d4d59419e9e115903298661a1XCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpUaGlzIGRyYWZ0IHJlcHJlc2VudHMgdGhlIFlBTkcgdmVyc2lvbmluZyBkZXNp Z24gdGVhbSdzIHByb3Bvc2VkIHNvbHV0aW9uIGZvciB1c2luZyBzZW1hbnRpYyB2ZXJzaW9uIG51 bWJlcnMgZm9yIG1vZHVsZXMuICBJdCBpcyBkZXJpdmVkIGZyb20gZHJhZnQtY2xhY2xhLW5ldG1v ZC15YW5nLW1vZGVsLXVwZGF0ZS0wNSAoc29ycnkgLSBJIG5lZWQgdG8gdXBkYXRlIHRoZSBkcmFm dCBtZXRhLWRhdGEgdG8gcmVmbGVjdCB0aGlzKS4NCg0KDQoNCknigJl2ZSBpbmNsdWRlIHRoZSBh YnN0cmFjdCwgYW5kIHN0YXJ0IG9mIHRoZSBpbnRyb2R1Y3Rpb24gZm9yIGNvbnZlbmllbmNlLg0K DQoNCg0KV2UgaG9wZSB0byBwcmVzZW50IG9uIHRoaXMgdG9waWMgaW4gUHJhZ3VlLCBidXQgb2J2 aW91c2x5IHdlbGNvbWUgZmVlZGJhY2sgb24gdGhlIFdHIGFsaWFzIGFzIHdlbGwuDQoNCg0KDQpB YnN0cmFjdA0KDQoNCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgWUFORyBtb2R1 bGUgdXBkYXRlIHByb2NlZHVyZSB1c2luZw0KDQogICBzZW1hbnRpYyB2ZXJzaW9uIG51bWJlcnMs IHRvIGFsbG93IGZvciBsaW1pdGVkIG5vbi1iYWNrd2FyZHMtDQoNCiAgIGNvbXBhdGlibGUgY2hh bmdlcywgYXMgYW4gYWx0ZXJuYXRpdmUgcHJvcG9zYWwgdG8gbW9kdWxlIHVwZGF0ZSBydWxlcw0K DQogICBpbiB0aGUgWUFORyAxLjEgc3BlY2lmaWNhdGlvbnMuICBUaGlzIGRvY3VtZW50IHVwZGF0 ZXMgUkZDIDc5NTAsIFJGQw0KDQogICA4NDA3IGFuZCBSRkMgODUyNS4NCg0KDQoNCjEuICBJbnRy b2R1Y3Rpb24NCg0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNvbHV0aW9uIHRvIHRo ZSBZQU5HIG1vZHVsZSBsaWZlY3ljbGUNCg0KICAgcHJvYmxlbXMgZGVzY3JpYmVkIGluIFtJLUQu dmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmluZy1yZXFzXSwNCg0KICAgY292ZXJpbmcgYWxsIG9m IHRoZSBzcGVjaWZpZWQgcmVxdWlyZW1lbnRzIGV4Y2VwdCBmb3IgcmVxdWlyZW1lbnRzOg0KDQog ICAyLjIsIDMuMSwgYW5kIDMuMi4NCg0KDQoNCiAgIFNwZWNpZmljYWxseSwgdGhpcyBkb2N1bWVu dCByZWNvZ25pc2VzIGEgbmVlZCB0byBzb21ldGltZXMgYWxsb3cgWUFORw0KDQogICBtb2R1bGVz IHRvIGV2b2x2ZSB3aXRoIG5vbi1iYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2VzLCB3aGljaCBt aWdodA0KDQogICBlbmQgdXAgYnJlYWtpbmcgY2xpZW50cy4gIFRoZSBzb2x1dGlvbiBtYWtlcyB1 c2Ugb2Ygc2VtYW50aWMgdmVyc2lvbg0KDQogICBudW1iZXJzIHRvIGhlbHAgbWFuYWdlIHRoZSBs aWZlY3ljbGUgb2YgWUFORyBtb2R1bGVzLg0KDQoNCg0KICAgVGhlIHNvbHV0aW9uIGlzIGNvbXBy aXNlZCBvZiB0aGUgZm9sbG93aW5nIHNldmVuIHBhcnRzOg0KDQoNCg0KICAgICAgQSBkZWZpbml0 aW9uIGZvciB0aGUgWUFORyBzZW1hbnRpYyB2ZXJzaW9uaW5nIHNjaGVtZSBmb3IgbW9kdWxlcywN Cg0KICAgICAgYW5kIGFuIGV4cGxhbmF0aW9uIG9mIGhvdyB0aGUgc2VtdmVyIGV4dGVuc2lvbiBj YW4gYmUgdXNlZCB0bw0KDQogICAgICBhbm5vdGF0ZSBtb2R1bGVzIHdpdGggdGhlaXIgc2VtYW50 aWMgdmVyc2lvbiBudW1iZXIuDQoNCg0KDQogICAgICBBIFlBTkcgZXh0ZW5zaW9uIHRvIGFsbG93 IFlBTkcgbW9kdWxlIGltcG9ydHMgdG8gYmUgcmVzdHJpY3RlZCB0bw0KDQogICAgICBtb2R1bGVz IHdpdGggcGFydGljdWxhciBzZW1hbnRpYyB2ZXJzaW9ucywgYWxsb3dpbmcgaW50ZXItbW9kdWxl DQoNCiAgICAgIHZlcnNpb24gZGVwZW5kZW5jaWVzIHRvIGJlIGNhcHR1cmVkIHdpdGhpbiBZQU5H IG1vZHVsZQ0KDQogICAgICBkZWZpbml0aW9ucy4NCg0KDQoNCiAgICAgIFVwZGF0ZXMgdG8gdGhl IFlBTkcgMS4xIG1vZHVsZSB1cGRhdGUgcnVsZXMgdG8gYWNjb21tb2RhdGUgdGhlDQoNCiAgICAg IHNlbWFudGljIHZlcnNpb25pbmcgc2NoZW1lLg0KDQoNCg0KICAgICAgVXBkYXRlcyBhbmQgYXVn bWVudGF0aW9ucyB0byBpZXRmLXlhbmctbGlicmFyeSB0byBpbmNsdWRlIHRoZSBZQU5HDQoNCiAg ICAgIHNlbWFudGljIHZlcnNpb24gbnVtYmVyIGluIHRoZSBtb2R1bGUgZGVzY3JpcHRpb25zLCB0 byByZXBvcnQgaG93DQoNCiAgICAgICdkZXByZWNhdGVkJyBhbmQgJ29ic29sZXRlJyBub2RlcyBh cmUgaGFuZGxlZCBieSBhIHNlcnZlciwgYW5kIHRvDQoNCiAgICAgIGNsYXJpZnkgaG93IG1vZHVs ZSBpbXBvcnRzIGFyZSByZXNvbHZlZCB3aGVuIG11bHRpcGxlIHZlcnNpb25zDQoNCiAgICAgIGNv dWxkIG90aGVyd2lzZSBiZSBjaG9zZW4uDQoNCg0KDQogICAgICBBIFlBTkcgZXh0ZW5zaW9uIHRv IGFkZCBhICdkZXNjcmlwdGlvbicgc3RhdGVtZW50IHRvIHRoZSBZQU5HDQoNCiAgICAgICdzdGF0 dXMnIHN0YXRlbWVudCB0byBhbGxvdyBhZGRpdGlvbmFsIGRvY3VtZW50YXRpb24gYXMgdG8gd2h5 IGENCg0KICAgICAgbm9kZSBpcyBiZWluZyBkZXByZWNhdGVkLCBhbmQgd2hhdCBhbHRlcm5hdGl2 ZXMgbWF5IGJlIGF2YWlsYWJsZS4NCg0KDQoNCiAgICAgIEEgZGVzY3JpcHRpb24gb2YgaG93IFlB Tkcgc2VtYW50aWMgdmVyc2lvbmluZyBhcHBsaWVzIHRvIFlBTkcNCg0KICAgICAgaW5zdGFuY2Ug ZGF0YS4NCg0KDQoNCiAgICAgIEd1aWRlbGluZXMgdG8gWUFORyBtb2R1bGUgYXV0aG9ycyBvbiBo b3cgdGhlIFlBTkcgc2VtYW50aWMNCg0KICAgICAgdmVyc2lvbmluZyBydWxlcyBzaG91bGQgYmUg dXNlZCwgYWxvbmcgd2l0aCBleGFtcGxlcy4NCg0KDQoNCiAgIE9wZW4gaXNzdWVzIGFyZSBsaXN0 ZWQgYXQgQXBwZW5kaXggQS4xLCBhbmQgdHJhY2tlZCBhdA0KDQogICA8aHR0cHM6Ly9naXRodWIu Y29tL25ldG1vZC13Zy95YW5nLXZlci1kdC9pc3N1ZXM+Lg0KDQoNCg0KDQoNClJlZ2FyZHMsDQpS b2INCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiAxMSBNYXJj aCAyMDE5IDE2OjUwDQpUbzogSmFzb24gU3Rlcm5lIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPjsg UmVzaGFkIFJhaG1hbiAocnJhaG1hbikgPHJyYWhtYW5AY2lzY28uY29tPjsgUm9iIFdpbHRvbiAo cndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgQmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5n eWVsQGVyaWNzc29uLmNvbT47IEtldmluIEQnU291emEgPGtkNjkxM0BhdHQuY29tPjsgQmVub2l0 IENsYWlzZSAoYmNsYWlzZSkgPGJjbGFpc2VAY2lzY28uY29tPjsgSm9lIENsYXJrZSAoamNsYXJr ZSkgPGpjbGFya2VAY2lzY28uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDAudHh0DQoNCg0KDQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlci0wMC50eHQN Cg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2JlcnQgV2lsdG9uIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KDQoNCk5hbWU6ICAgICAgICAgICAgICAg ICAgZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctc2VtdmVyDQoNClJldmlzaW9uOiAgICAgICAgICAg ICAgMDANCg0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgWUFORyBTZW1hbnRpYyBWZXJzaW9u aW5nIGZvciBNb2R1bGVzDQoNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAgMjAxOS0wMy0x MQ0KDQpHcm91cDogICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFn ZXM6ICAgICAgICAgICAgICAgICAgMzcNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDAu dHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXIvDQoNCkh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctc2VtdmVyLTAwDQoN Ckh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlcg0KDQoNCg0KDQoNCkFic3RyYWN0Og0KDQogICBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBZQU5HIG1vZHVsZSB1cGRhdGUgcHJvY2VkdXJl IHVzaW5nDQoNCiAgIHNlbWFudGljIHZlcnNpb24gbnVtYmVycywgdG8gYWxsb3cgZm9yIGxpbWl0 ZWQgbm9uLWJhY2t3YXJkcy0NCg0KICAgY29tcGF0aWJsZSBjaGFuZ2VzLCBhcyBhbiBhbHRlcm5h dGl2ZSBwcm9wb3NhbCB0byBtb2R1bGUgdXBkYXRlIHJ1bGVzDQoNCiAgIGluIHRoZSBZQU5HIDEu MSBzcGVjaWZpY2F0aW9ucy4gIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzk1MCwgUkZDDQoN CiAgIDg0MDcgYW5kIFJGQyA4NTI1Lg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_3100c80d4d59419e9e115903298661a1XCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBkcmFmdCByZXByZXNlbnRzIHRoZSBZQU5H IHZlcnNpb25pbmcgZGVzaWduIHRlYW0ncyBwcm9wb3NlZCBzb2x1dGlvbiBmb3IgdXNpbmcgc2Vt YW50aWMgdmVyc2lvbiBudW1iZXJzIGZvciBtb2R1bGVzLiZuYnNwOyBJdCBpcyBkZXJpdmVkIGZy b20gZHJhZnQtY2xhY2xhLW5ldG1vZC15YW5nLW1vZGVsLXVwZGF0ZS0wNSAoc29ycnkgLSBJIG5l ZWQgdG8gdXBkYXRlIHRoZSBkcmFmdCBtZXRhLWRhdGEgdG8gcmVmbGVjdA0KIHRoaXMpLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J4oCZdmUgaW5jbHVkZSB0aGUgYWJzdHJhY3QsIGFu ZCBzdGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIGZvciBjb252ZW5pZW5jZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+V2UgaG9wZSB0byBwcmVzZW50IG9uIHRoaXMgdG9waWMgaW4gUHJh Z3VlLCBidXQgb2J2aW91c2x5IHdlbGNvbWUgZmVlZGJhY2sgb24gdGhlIFdHIGFsaWFzIGFzIHdl bGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb25zb2xhcyI+QWJzdHJhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IGEgbmV3IFlBTkcgbW9kdWxlIHVwZGF0ZSBwcm9jZWR1cmUgdXNpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q29uc29sYXMiPiZuYnNwOyZuYnNwOyBzZW1hbnRpYyB2ZXJzaW9uIG51bWJlcnMsIHRvIGFsbG93 IGZvciBsaW1pdGVkIG5vbi1iYWNrd2FyZHMtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz cDsmbmJzcDsgY29tcGF0aWJsZSBjaGFuZ2VzLCBhcyBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCB0 byBtb2R1bGUgdXBkYXRlIHJ1bGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJz cDsgaW4gdGhlIFlBTkcgMS4xIHNwZWNpZmljYXRpb25zLiZuYnNwOyBUaGlzIGRvY3VtZW50IHVw ZGF0ZXMgUkZDIDc5NTAsIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7 IDg0MDcgYW5kIFJGQyA4NTI1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvbnNvbGFzIj4xLiZuYnNwOyBJbnRyb2R1Y3Rpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q29uc29sYXMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNvbHV0aW9uIHRvIHRoZSBZQU5HIG1vZHVsZSBsaWZlY3lj bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyBwcm9ibGVtcyBkZXNjcmli ZWQgaW4gW0ktRC52ZXJkdC1uZXRtb2QteWFuZy12ZXJzaW9uaW5nLXJlcXNdLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IGNvdmVyaW5nIGFsbCBvZiB0aGUgc3BlY2lmaWVk IHJlcXVpcmVtZW50cyBleGNlcHQgZm9yIHJlcXVpcmVtZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXMiPiZuYnNwOyZuYnNwOyAyLjIsIDMuMSwgYW5kIDMuMi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IFNwZWNp ZmljYWxseSwgdGhpcyBkb2N1bWVudCByZWNvZ25pc2VzIGEgbmVlZCB0byBzb21ldGltZXMgYWxs b3cgWUFORzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IG1vZHVsZXMgdG8g ZXZvbHZlIHdpdGggbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZXMsIHdoaWNoIG1pZ2h0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsgZW5kIHVwIGJyZWFraW5nIGNs aWVudHMuJm5ic3A7IFRoZSBzb2x1dGlvbiBtYWtlcyB1c2Ugb2Ygc2VtYW50aWMgdmVyc2lvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IG51bWJlcnMgdG8gaGVscCBtYW5h Z2UgdGhlIGxpZmVjeWNsZSBvZiBZQU5HIG1vZHVsZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyBUaGUgc29sdXRp b24gaXMgY29tcHJpc2VkIG9mIHRoZSBmb2xsb3dpbmcgc2V2ZW4gcGFydHM6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNvbnNvbGFzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBIGRlZmluaXRpb24gZm9yIHRoZSBZQU5HIHNlbWFudGljIHZl cnNpb25pbmcgc2NoZW1lIGZvciBtb2R1bGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBhbiBleHBsYW5hdGlvbiBvZiBob3cgdGhl IHNlbXZlciBleHRlbnNpb24gY2FuIGJlIHVzZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbm5vdGF0ZSBtb2R1bGVzIHdpdGggdGhl aXIgc2VtYW50aWMgdmVyc2lvbiBudW1iZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBIFlBTkcgZXh0ZW5zaW9uIHRvIGFsbG93IFlBTkcgbW9kdWxlIGltcG9ydHMgdG8gYmUgcmVz dHJpY3RlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG1vZHVsZXMgd2l0aCBwYXJ0aWN1bGFyIHNlbWFudGljIHZlcnNpb25zLCBhbGxv d2luZyBpbnRlci1tb2R1bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB2ZXJzaW9uIGRlcGVuZGVuY2llcyB0byBiZSBjYXB0dXJlZCB3aXRo aW4gWUFORyBtb2R1bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkZWZpbml0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFVwZGF0ZXMgdG8gdGhlIFlBTkcgMS4xIG1vZHVsZSB1cGRhdGUgcnVsZXMgdG8gYWNjb21tb2Rh dGUgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc2VtYW50aWMgdmVyc2lvbmluZyBzY2hlbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBVcGRhdGVzIGFuZCBhdWdtZW50YXRpb25zIHRvIGlldGYteWFuZy1saWJyYXJ5IHRv IGluY2x1ZGUgdGhlIFlBTkc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzZW1hbnRpYyB2ZXJzaW9uIG51bWJlciBpbiB0aGUgbW9kdWxlIGRl c2NyaXB0aW9ucywgdG8gcmVwb3J0IGhvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdkZXByZWNhdGVkJyBhbmQgJ29ic29sZXRlJyBub2Rl cyBhcmUgaGFuZGxlZCBieSBhIHNlcnZlciwgYW5kIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xhcmlmeSBob3cgbW9kdWxlIGltcG9y dHMgYXJlIHJlc29sdmVkIHdoZW4gbXVsdGlwbGUgdmVyc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb3VsZCBvdGhlcndpc2UgYmUg Y2hvc2VuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv bnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBZQU5HIGV4dGVuc2lvbiB0 byBhZGQgYSAnZGVzY3JpcHRpb24nIHN0YXRlbWVudCB0byB0aGUgWUFORzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdzdGF0dXMnIHN0YXRl bWVudCB0byBhbGxvdyBhZGRpdGlvbmFsIGRvY3VtZW50YXRpb24gYXMgdG8gd2h5IGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub2RlIGlz IGJlaW5nIGRlcHJlY2F0ZWQsIGFuZCB3aGF0IGFsdGVybmF0aXZlcyBtYXkgYmUgYXZhaWxhYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBkZXNjcmlwdGlvbiBvZiBob3cgWUFO RyBzZW1hbnRpYyB2ZXJzaW9uaW5nIGFwcGxpZXMgdG8gWUFORzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25z b2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluc3RhbmNlIGRhdGEuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHdWlkZWxpbmVzIHRvIFlBTkcgbW9kdWxlIGF1dGhv cnMgb24gaG93IHRoZSBZQU5HIHNlbWFudGljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmVyc2lvbmluZyBydWxlcyBzaG91bGQgYmUgdXNl ZCwgYWxvbmcgd2l0aCBleGFtcGxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7IE9wZW4gaXNzdWVzIGFyZSBsaXN0 ZWQgYXQgQXBwZW5kaXggQS4xLCBhbmQgdHJhY2tlZCBhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xh cyI+Jm5ic3A7Jm5ic3A7ICZsdDtodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctdmVy LWR0L2lzc3VlcyZndDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q29uc29sYXMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlJlZ2FyZHMsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgJmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZndDsg PGJyPg0KU2VudDogMTEgTWFyY2ggMjAxOSAxNjo1MDxicj4NClRvOiBKYXNvbiBTdGVybmUgJmx0 O2phc29uLnN0ZXJuZUBub2tpYS5jb20mZ3Q7OyBSZXNoYWQgUmFobWFuIChycmFobWFuKSAmbHQ7 cnJhaG1hbkBjaXNjby5jb20mZ3Q7OyBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndpbHRvbkBj aXNjby5jb20mZ3Q7OyBCYWxhenMgTGVuZ3llbCAmbHQ7YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24u Y29tJmd0OzsgS2V2aW4gRCdTb3V6YSAmbHQ7a2Q2OTEzQGF0dC5jb20mZ3Q7OyBCZW5vaXQgQ2xh aXNlIChiY2xhaXNlKSAmbHQ7YmNsYWlzZUBjaXNjby5jb20mZ3Q7OyBKb2UNCiBDbGFya2UgKGpj bGFya2UpICZsdDtqY2xhcmtlQGNpc2NvLmNvbSZndDs8YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlci0wMC50eHQ8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12ZXJkdC1uZXRtb2Qt eWFuZy1zZW12ZXItMDAudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJvYmVydCBXaWx0b24gYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFm dC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlBTkcgU2VtYW50aWMgVmVy c2lvbmluZyBmb3IgTW9kdWxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxOS0wMy0xMTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R3JvdXA6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFnZXM6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM3PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDAu dHh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdmVyZHQtbmV0bW9k LXlhbmctc2VtdmVyLTAwLnR4dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlci8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlci88L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDAiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctc2VtdmVyIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlcjwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBu ZXcgWUFORyBtb2R1bGUgdXBkYXRlIHByb2NlZHVyZSB1c2luZzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNlbWFudGljIHZlcnNpb24gbnVtYmVy cywgdG8gYWxsb3cgZm9yIGxpbWl0ZWQgbm9uLWJhY2t3YXJkcy08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBjb21wYXRpYmxlIGNoYW5nZXMsIGFz IGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIHRvIG1vZHVsZSB1cGRhdGUgcnVsZXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbiB0aGUgWUFORyAx LjEgc3BlY2lmaWNhdGlvbnMuJm5ic3A7IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzk1MCwg UkZDPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg ODQwNyBhbmQgUkZDIDg1MjUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBJRVRG IFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3100c80d4d59419e9e115903298661a1XCHRCD007ciscocom_-- From nobody Tue Mar 12 05:11:20 2019 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 E8B66130F24 for ; Tue, 12 Mar 2019 05:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 cEx5zuErJro5 for ; Tue, 12 Mar 2019 05:11:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22165126C01 for ; Tue, 12 Mar 2019 05:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14169; q=dns/txt; s=iport; t=1552392676; x=1553602276; h=from:to:subject:date:message-id:mime-version; bh=Ux8zhG6j09fo+7FvWKDuWZ5poAdE0HMKHvSHDNqOf2g=; b=LT/cRPi4/pd3K4P9NqzpgwN/UEhRz/M0+DSwdGzJANuhCdEuQEdttQRv Y+CuAgiTUikARBVuLOiH6PoWoj7g1QTPm3R1vlHqhV2Y2Te+2TKJmWexF sNDIkOZMZlCIozjJzoaRFN+DkOxP6cEF5VIdSDhX5KAPJ7cAgjhEggllk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAAB9oIdc/5tdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ1TBSpogQMxjBqLN5RDhXWBewsBASWIfyI0CQ0BAQMBAQk?= =?us-ascii?q?BAwJtHAELhX5eAYEAJgEEGxODCIERZA+xPoREQYU5BYEvAYssF4FAP4dBAgM?= =?us-ascii?q?BgUeFdwOKSoYOk1YJAodTizghkzyKeoVqjGkCERWBKB84KIEucBWDKIMsAQi?= =?us-ascii?q?HVoU/QZBngR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,471,1544486400"; d="scan'208,217";a="316263292" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 12:11:15 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2CCBFKG032549 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Mar 2019 12:11:15 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Mar 2019 07:11:14 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 12 Mar 2019 07:11:14 -0500 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Design Team Status Thread-Index: AdTYxqm2/iQBzzA0SU6dM5BGU4Q0oA== Date: Tue, 12 Mar 2019 12:11:14 +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.61.204.183] Content-Type: multipart/alternative; boundary="_000_b7e1ceb29fe64406bbec1609afcdfe37XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: [netmod] YANG Versioning Design Team Status X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 12:11:19 -0000 --_000_b7e1ceb29fe64406bbec1609afcdfe37XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I thought that it might be useful to give a short status on the work that t= he NETMOD versioning design team have been doing since IETF 103, and also t= o give a quick summary of how the various drafts that been published are re= lated. The majority of the design team work since IETF 103 has been focussed on: (1) Updating the requirements draft to address the comments raised at 103= : draft-verdt-netmod-yang-versioning-reqs-02 (2) Producing a solution draft that covers module scoped versioning: draf= t-verdt-netmod-yang-semver-00 The "module scoped versioning" solution draft does not address all requirem= ents. So in addition to that solution draft, I have posted two individual = drafts as potential starting points to discuss the other parts of the solut= ion space. Although the underlying ideas in these drafts have been discuss= ed amongst the design team members, these drafts do not necessarily represe= nt any kind of consensus of the design team members at this time: (1) Managing sets of YANG modules as a versioned schema draft-rwilton-net= mod-yang-packages-01 (2) Allowing clients to choose which versioned schema to use for client/s= erver interactions: draft-wilton-netmod-yang-ver-selection-00 There is one part of the versioning puzzle that hasn't yet been explored in= any detail by the design team which is a tooling approach that can robustl= y compare two schema and then report and classify the differences. Finally, there is also another versioning related individual draft: draft-w= ang-netmod-module-revision-management-01 I would like to thank all of the current members of the YANG versioning des= ign team who have given up their time on a weekly basis to help with this w= ork. Thanks, Rob --_000_b7e1ceb29fe64406bbec1609afcdfe37XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I thought that it might be useful to give a short st= atus on the work that the NETMOD versioning design team have been doing sin= ce IETF 103, and also to give a quick summary of how the various drafts tha= t been published are related.

 

The majority of the design team work since IETF 103 = has been focussed on:

(1)   Updating the requirements draft to address t= he comments raised at 103: draft-verdt-netmod-yang-versioning-reqs-0= 2

(2)   Producing a solution draft that covers modul= e scoped versioning: dr= aft-verdt-netmod-yang-semver-00 

The “module scoped versioning” solut= ion draft does not address all requirements.  So in addition to that s= olution draft, I have posted two individual drafts as potential starting points to discuss the other parts of the solution space.  Al= though the underlying ideas in these drafts have been discussed amongst the= design team members, these drafts do not necessarily represent any kind of= consensus of the design team members at this time:

(1)   Managing sets of YANG modules as a versioned schema draft-rwilton-netmod-yang-packages-01

(2)   Allowing clients to choose which versioned schema to = use for client/server interactions:  draft-wilton-netmod-yang-ver-= selection-00 

There is one part of the versioning puzzle that = hasn’t yet been explored in any detail by the design team which is a = tooling approach that can robustly compare two schema and then report and classify the differences.

Finally, there is also another versioning relate= d individual draft: draft-wang-netmod-module-revision-manage= ment-01 <= /o:p>

I would like to thank all of the current members= of the YANG versioning design team who have given up their time on a weekl= y basis to help with this work.

Thanks,
Rob

--_000_b7e1ceb29fe64406bbec1609afcdfe37XCHRCD007ciscocom_-- From nobody Tue Mar 12 19:56:40 2019 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 9C1A212796D; Tue, 12 Mar 2019 19:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 012rGNCltA0z; Tue, 12 Mar 2019 19:56:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B594E12705F; Tue, 12 Mar 2019 19:56:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 53223B8241A; Tue, 12 Mar 2019 19:56:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netmod@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190313025628.53223B8241A@rfc-editor.org> Date: Tue, 12 Mar 2019 19:56:28 -0700 (PDT) Archived-At: Subject: [netmod] =?utf-8?q?RFC_8519_on_YANG_Data_Model_for_Network_Acces?= =?utf-8?q?s_Control_Lists_=28ACLs=29?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 02:56:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8519 Title: YANG Data Model for Network Access Control Lists (ACLs) Author: M. Jethanandani, S. Agarwal, L. Huang, D. Blair Status: Standards Track Stream: IETF Date: March 2019 Mailbox: mjethanandani@gmail.com, sagarwal12@gmail.com, huangyi_99@yahoo.com, dana@blairhome.com Pages: 60 Characters: 105566 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-acl-model-21.txt URL: https://www.rfc-editor.org/info/rfc8519 DOI: 10.17487/RFC8519 This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. This document is a product of the Network Modeling Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Mar 13 12:09:40 2019 Return-Path: <010001697875bbf2-41b4ba53-c312-4284-bf85-aad5d48257f1-000000@amazonses.watsen.net> 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 27C4F1310FB for ; Wed, 13 Mar 2019 12:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 l49vEXBwpYdO for ; Wed, 13 Mar 2019 12:09:37 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64151310EA for ; Wed, 13 Mar 2019 12:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552504175; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=tOCG4dHYmjWKgtQzUaJXMKymSdIXPkOipXs7wf+o9+s=; b=Xo3s9zIdQNo9Uqxv778mE70f/47CwSzDdikaP8AGAgrpE1jC2ZEIwauXszmI0oJH 9fileEUsBHKBbYRUnahJvt6ipZ6EMweAk8mLiIoR70GFoyuRZ268NB2VRz0Tnk+QyRl 77Qe1MjU7Yfo3+wccmMFbMfS+uQ8tZWvTpbletyI= From: Kent Watsen Message-ID: <010001697875bbf2-41b4ba53-c312-4284-bf85-aad5d48257f1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_455E0EA6-FFA6-4BC1-9574-916429D5D614" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 13 Mar 2019 19:09:35 +0000 In-Reply-To: <3100c80d4d59419e9e115903298661a1@XCH-RCD-007.cisco.com> Cc: "netmod@ietf.org" To: "Rob Wilton (rwilton)" References: <3100c80d4d59419e9e115903298661a1@XCH-RCD-007.cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.13-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] YANG Semantic Versioning for Modules: draft-verdt-netmod-yang-semver-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 19:09:39 -0000 --Apple-Mail=_455E0EA6-FFA6-4BC1-9574-916429D5D614 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > It is derived from draft-clacla-netmod-yang-model-update-05 (sorry - I = need to update the draft meta-data to reflect this).=20 I'm not able to set this metadata now, as neither the "Replaces" or = "Replaced-by" options are available. This may be due to one draft being = an I-D and the other draft expired. I'll ask the IETF Secretariat. Kent= --Apple-Mail=_455E0EA6-FFA6-4BC1-9574-916429D5D614 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
It is = derived from draft-clacla-netmod-yang-model-update-05 (sorry - I need to = update the draft meta-data to reflect this). 

I'm not able to set this metadata now, as neither = the "Replaces" or "Replaced-by" options are available.  This may be = due to one draft being an I-D and the other draft expired.  I'll = ask the IETF Secretariat.

Kent
= --Apple-Mail=_455E0EA6-FFA6-4BC1-9574-916429D5D614-- From nobody Wed Mar 13 12:43:20 2019 Return-Path: <01000169789490b6-5e18250c-9328-48c6-90b6-775c81b2a2d5-000000@amazonses.watsen.net> 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 D4B61130E6B for ; Wed, 13 Mar 2019 12:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 0txwsjZglonU for ; Wed, 13 Mar 2019 12:43:17 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F39A1200B3 for ; Wed, 13 Mar 2019 12:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552506196; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LsKdjAIcaAsTSClgbSPIux5b/ktip1QRVHmBmuX+A04=; b=PK0hJr/E9tzNobRhRcCcl57WQET6F187IkRa4V5agKWctc52A3m2B8RaKymTDrRK NX+SSZdL6GrPnVqcZeSEcHC3/C6blhtFjXglfGcRQwUg83Jc1ueiU7+V+BARMZW1yTz 7zTRjcfOqs/fuDUom0rco72E1Qom+udsRIRHbZyI= From: Kent Watsen Message-ID: <01000169789490b6-5e18250c-9328-48c6-90b6-775c81b2a2d5-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C8752FE-A6D1-4596-AEAF-A22958744F8A" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 13 Mar 2019 19:43:16 +0000 In-Reply-To: <010001697875bbf2-41b4ba53-c312-4284-bf85-aad5d48257f1-000000@email.amazonses.com> Cc: "netmod@ietf.org" To: "Rob Wilton (rwilton)" References: <3100c80d4d59419e9e115903298661a1@XCH-RCD-007.cisco.com> <010001697875bbf2-41b4ba53-c312-4284-bf85-aad5d48257f1-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.13-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] YANG Semantic Versioning for Modules: draft-verdt-netmod-yang-semver-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 19:43:19 -0000 --Apple-Mail=_7C8752FE-A6D1-4596-AEAF-A22958744F8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> It is derived from draft-clacla-netmod-yang-model-update-05 (sorry - = I need to update the draft meta-data to reflect this).=20 >=20 > I'm not able to set this metadata now, as neither the "Replaces" or = "Replaced-by" options are available. This may be due to one draft being = an I-D and the other draft expired. I'll ask the IETF Secretariat. Set now. Kent --Apple-Mail=_7C8752FE-A6D1-4596-AEAF-A22958744F8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
It is derived from = draft-clacla-netmod-yang-model-update-05 (sorry - I need to update the = draft meta-data to reflect this). 

I'm not able to set this metadata now, as neither the = "Replaces" or "Replaced-by" options are available.  This may be due = to one draft being an I-D and the other draft expired.  I'll ask = the IETF Secretariat.

Set now.

Kent


= --Apple-Mail=_7C8752FE-A6D1-4596-AEAF-A22958744F8A-- From nobody Wed Mar 13 13:22:07 2019 Return-Path: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@amazonses.watsen.net> 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 B1A56130F04 for ; Wed, 13 Mar 2019 13:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Tpvbj-xRSHAq for ; Wed, 13 Mar 2019 13:22:03 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F31E124D68 for ; Wed, 13 Mar 2019 13:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552508522; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=6WtGit6QmwRl5Bnnf3fdPwEAN/CPT+8w2fPGsINGfI8=; b=KkBoDk4eueGqKX9wUmXAl987rIyXzMBoLp+uE1ktduIb9XCqDmHyRp/UWAB7GqEN buf0jLoD/+MRqO19FGuO2lTKhs3ew8Bf4kvytH6J2YGtOw6Qp16/vpoMuGToJaehzyA On6124CYLG+0812+PYWwRHV25PHkg40oD6e7OVtU= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E914A8-EEBD-4FD8-8FC5-FA29ACC0CF8D" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> Date: Wed, 13 Mar 2019 20:22:02 +0000 To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.13-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 20:22:06 -0000 --Apple-Mail=_E6E914A8-EEBD-4FD8-8FC5-FA29ACC0CF8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seeing as how we all need to read this draft anyways, in preparation for = our meeting in Prague, it seems like a good time for this poll. Thusly, = this email begins a 1-week adoption poll for: = https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 = Please voice your support or objections before March 20. Note that this draft defines *requirements* and its intended status is = "Informational." I believe that it is good for WGs to formalize = requirements, even taking such drafts thru Last Call, in order to ensure = consensus on the requirements. This is the "adoption" call, to = ascertain if the WG agrees with that statement; if adopted, a separate = "last call" will be issued to ensure to correctness of the draft's = content. Kent (and Lou and Joel) --Apple-Mail=_E6E914A8-EEBD-4FD8-8FC5-FA29ACC0CF8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Seeing as how we all need to read this draft anyways, in = preparation for our meeting in Prague, it seems like a good time for = this poll.  Thusly, this email begins a 1-week adoption poll = for:

    https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-= reqs-02

Please voice your support or objections before March = 20.

Note that = this draft defines *requirements* and its intended status is = "Informational."   I believe that it is good for WGs to formalize = requirements, even taking such drafts thru Last Call, in order to ensure = consensus on the requirements.  This is the "adoption" call, to = ascertain if the WG agrees with that statement; if adopted, a separate = "last call" will be issued to ensure to correctness of the draft's = content.

Kent = (and Lou and Joel)


= --Apple-Mail=_E6E914A8-EEBD-4FD8-8FC5-FA29ACC0CF8D-- From nobody Wed Mar 13 13:57:08 2019 Return-Path: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@amazonses.watsen.net> 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 68D1F1311AA for ; Wed, 13 Mar 2019 13:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 rKNYP9jVg9xn for ; Wed, 13 Mar 2019 13:29:59 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22B9131153 for ; Wed, 13 Mar 2019 13:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552508997; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=2hVlX9oaTapOag5coZiN2D702wPVo86cZXQnXkaoYjg=; b=W357JSDbJnTXwVhSnfvEvHseDqh5Iz3XysufHUsdqCwdDIogLYTMWFQiSqe6w89A ++eMHoKZ+raxo/FUwbO/OvupT8+q1+WrnBfsK3Xusp/pEV/YmiBB82xynl/HZuHY+SK M5Jzpekf8CPrXF6Hz94tKdufpW5gW9eOvJ/rQsG0= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_7D4C4ACA-1ED5-4ADD-ADCC-C5937958E632" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> Date: Wed, 13 Mar 2019 20:29:57 +0000 Cc: netmod@ietf.org To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , Benoit Claise , Ebben Aries , Jason Sterne , Juergen Schoenwaelder , Mahesh Jethanandani , "Michael (Wangzitao)" , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.13-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: X-Mailman-Approved-At: Wed, 13 Mar 2019 13:57:07 -0700 Subject: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 20:30:07 -0000 --Apple-Mail=_7D4C4ACA-1ED5-4ADD-ADCC-C5937958E632 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To each author and contributor listed on the "To" line. In order to complete the Adoption poll, are you aware of any IPR that = applies to yang-versioning-reqs-02? Please Reply-All to *this* email and state = either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think = appropriate. If you are listed as a document author or contributor please answer the = above by responding to this email regardless of whether or not you are aware of = any relevant IPR. This document will not advance to the next stage until a response = has been received from each author and listed contributor. NOTE: THIS APPLIES TO = ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed = as an author or contributor, we remind you of your obligations under the IETF IPR = rules which encourages you to notify the IETF if you are aware of IPR of others on = an IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please see the RFCs = listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . Thank you, Kent // as co-Chair --Apple-Mail=_7D4C4ACA-1ED5-4ADD-ADCC-C5937958E632 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii To = each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any = IPR that applies
to yang-versioning-reqs-02?  Please = Reply-All to *this* email and state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this = draft"

If "yes", has this IPR been = disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = "yes" again, please state either:

"Yes, the = IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think appropriate.

If = you are listed as a document author or contributor please answer the = above by
responding to this email regardless of whether or = not you are aware of any relevant
IPR.  This document = will not advance to the next stage until a response has been
received from each author and listed contributor.  NOTE: = THIS APPLIES TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO = LINES.

If you are on the WG email list or = attend WG meetings but are not listed as an author
or = contributor, we remind you of your obligations under the IETF IPR rules = which
encourages you to notify the IETF if you are aware = of IPR of others on an IETF
contribution, or to refrain = from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the = RFCs listed above
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

Thank you,
Kent // = as co-Chair

= --Apple-Mail=_7D4C4ACA-1ED5-4ADD-ADCC-C5937958E632-- From nobody Wed Mar 13 13:57:14 2019 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 4D324131105 for ; Wed, 13 Mar 2019 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu8himRu5kVW for ; Wed, 13 Mar 2019 13:48:16 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E572C1311A5 for ; Wed, 13 Mar 2019 13:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tHT4ZUEV5shMh/L8zF2+rw94uGWA3QGnoSrXrJVrZX4=; b=Fo04YNL4O24DUeMtTn1kT6OQrx9l//uVucI4aURf/PRN5Q4XVihjvZJm0M+gt1A37EeO3mL4Hy5GsIUSey2JjUcPHMioMA83dGtueTkr3keXMGh1pZOqhWpI99VcZsGndRYg4lvlC1J/8Ipioo6coys4esZmU1lExtZK7/j8kvg= Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB6191.eurprd07.prod.outlook.com (20.178.9.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.10; Wed, 13 Mar 2019 20:48:12 +0000 Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::d02b:d3a8:32de:3b73]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::d02b:d3a8:32de:3b73%2]) with mapi id 15.20.1709.011; Wed, 13 Mar 2019 20:48:12 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Kent Watsen , Joe Clarke , =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , Benoit Claise , Ebben Aries , Juergen Schoenwaelder , Mahesh Jethanandani , "Michael (Wangzitao)" , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton CC: "netmod@ietf.org" Thread-Topic: IPR poll on yang-versioning-reqs-02 Thread-Index: AQHU2duHzOsuHdR1tU+EasZrkEy5tKYKCFEw Date: Wed, 13 Mar 2019 20:48:11 +0000 Message-ID: References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; x-originating-ip: [45.72.216.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67a990e1-a507-4bf1-464d-08d6a7f53539 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:VI1PR07MB6191; x-ms-traffictypediagnostic: VI1PR07MB6191: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(346002)(396003)(189003)(199004)(316002)(74316002)(606006)(7696005)(6246003)(86362001)(52536013)(1941001)(102836004)(7736002)(486006)(110136005)(97736004)(76176011)(106356001)(8936002)(68736007)(476003)(54896002)(11346002)(6506007)(53546011)(6306002)(14454004)(105586002)(55016002)(8676002)(236005)(9686003)(53936002)(71200400001)(186003)(6116002)(5660300002)(3846002)(71190400001)(14444005)(256004)(229853002)(6436002)(26005)(66574012)(81156014)(81166006)(790700001)(446003)(2906002)(478600001)(7416002)(966005)(33656002)(66066001)(25786009)(99286004)(4326008)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6191; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iVhOgshehyNf0v7X14XaGM4B4zgWO5yOKc7rzAxu3PgPE5fpIe1gyurZbc3yzRECqS9XutMZOdW9Kfj1sVF/4/eYf7pPS6we5wWq13iyqTiSxaLJ67InRGUvjeCAMq4GTaK4NatMfijs9IN+HupjF2yXEeCfs9zY2PSZie8kJKZDe47k78MU+oP9jmjWHVchyUimCOTK7HcPCUn6yQAC+AI2yryy5y3WQwYdY7yUNtxOefWJrE+akWkZkmppuO2opp5VlbZM4K/GtZt+yJbtHMORDP9I7AzU682o0X/cw7mJyJEZddKp6bjzX/N9AHfXLXcq6NbLUbrzyOurhrhbPJHwOQk0nJGepLfpcl3kiNhsp/HC2lvZCPyK0U53+zh/WrL6Zrdt2gqBJ34KZDQ7OYwdB47BCwxCCQ2WhM2XHSg= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB39816D3973F4D09C9BB9043B9B4A0VI1PR07MB3981eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 67a990e1-a507-4bf1-464d-08d6a7f53539 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2019 20:48:11.9794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6191 Archived-At: X-Mailman-Approved-At: Wed, 13 Mar 2019 13:57:07 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 20:48:19 -0000 --_000_VI1PR07MB39816D3973F4D09C9BB9043B9B4A0VI1PR07MB3981eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Jason Sterne From: Kent Watsen Sent: Wednesday, March 13, 2019 4:30 PM To: Joe Clarke ; Bal=E1zs Lengyel ; Benoit Claise ; Ebben Aries ; = Sterne, Jason (Nokia - CA/Ottawa) ; Juergen Schoenw= aelder ; Mahesh Jethanandani ; Michael (Wangzitao) ; Qin Wu ; Reshad Rahman (rrahman) ; Rob Wilton Cc: netmod@ietf.org Subject: IPR poll on yang-versioning-reqs-02 To each author and contributor listed on the "To" line. In order to complete the Adoption poll, are you aware of any IPR that appli= es to yang-versioning-reqs-02? Please Reply-All to *this* email and state eit= her: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware of any = relevant IPR. This document will not advance to the next stage until a response has= been received from each author and listed contributor. NOTE: THIS APPLIES TO AL= L OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF IPR rules = which encourages you to notify the IETF if you are aware of IPR of others on an I= ETF contribution, or to refrain from participating in any contribution or discu= ssion related to your undisclosed IPR. For more information, please see the RFCs listed a= bove and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, Kent // as co-Chair --_000_VI1PR07MB39816D3973F4D09C9BB9043B9B4A0VI1PR07MB3981eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR that applies to this dr= aft.

Jason Ste= rne

&nbs= p;

From: Kent Watsen <kent+ietf@watsen.net>
Sent: Wednesday, March 13, 2019 4:30 PM
To: Joe Clarke <jclarke@cisco.com>; Bal=E1zs Lengyel <balaz= s.lengyel@ericsson.com>; Benoit Claise <bclaise@cisco.com>; Ebben = Aries <exa@juniper.net>; Sterne, Jason (Nokia - CA/Ottawa) <jason.= sterne@nokia.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-univ= ersity.de>; Mahesh Jethanandani <mjethanandani@gmail.com>; Michael (Wangzitao) &= lt;wangzitao@huawei.com>; Qin Wu <bill.wu@huawei.com>; Reshad Rahm= an (rrahman) <rrahman@cisco.com>; Rob Wilton <rwilton@cisco.com>= ;
Cc: netmod@ietf.org
Subject: IPR poll on yang-versioning-reqs-02

 

To each author and co= ntributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that appli= es
to yang-versioning-reqs-02?  Please Reply-All to *this* email and stat= e either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR= rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by
responding to this email regardless of whether or not you are aware of any = relevant
IPR.  This document will not advance to the next stage until a respons= e has been
received from each author and listed contributor.  NOTE: THIS APPLIES = TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author
or contributor, we remind you of your obligations under the IETF IPR rules = which
encourages you to notify the IETF if you are aware of IPR of others on an I= ETF
contribution, or to refrain from participating in any contribution or discu= ssion related
to your undisclosed IPR. For more information, please see the RFCs listed a= bove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellectual= Property.

Thank you,
Kent // as co-Chair

--_000_VI1PR07MB39816D3973F4D09C9BB9043B9B4A0VI1PR07MB3981eurp_-- From nobody Wed Mar 13 13:57:22 2019 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 DB7AD131153 for ; Wed, 13 Mar 2019 13:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6LT-9naig240 for ; Wed, 13 Mar 2019 13:50:11 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E864B131105 for ; Wed, 13 Mar 2019 13:50:10 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id h99so3491374wrh.12 for ; Wed, 13 Mar 2019 13:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=I52WpXWblQusjsy19avRMzIGYhVynbqXkpH/irajdJ0=; b=i033Hcr+eIZ68hWg3XyDuDQSE8Tpy1/zPzVyq0ltHbEgwLems8t9XPeduV19aaK8ye /F+HDdw+TiLDfcPXKmJxz21KdGIc845jdZNK1JVHG//S5emxD0quyBG1QfKFUmCRJlEs Jm0KFAogpxq1wDcGYk8gKIoHylhNWF6S9FLKilbzusx9u5tUvK5uT+pn31SvRQBoxdw/ tyyJbOSaZW4b7v3z5P27w69vuruCK9JR/HQpaQTbEQHkIW/qbCUbvDDBClByyIg6pNkY JO8jmz/ZdBYb4XhziYRDRGKJEi0fN7DG/05hiM0CmqtUcLSudbk11N0Bz2NE/AVdJi0c A1jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=I52WpXWblQusjsy19avRMzIGYhVynbqXkpH/irajdJ0=; b=qi6b5FkP+DbQeO9Cf0wSGCTR16QKucMTCLKr6IAryle2/0ZlbP8jKF8dbZ8Cj5UqDb keAQ8hdSXcPx763dB5/toZ1CuliT6LLvhhcAMzBryfYxTPPPO0W52zlWyDo84T5RJnxe xJF7F9+yCortLg2qqAQYFfOPddwehPtU6FbeAw2hG75HookOaWVTZjrz2uo5E/CNyI1l n7q3uBH2YSGhyxInzvhxG23Fi2HugDcP9Ka9z0Pv2aAZzTfnlchCmMGFtYX/jv2e/BbE xHPYU9a2/LUkFQBsBaVDyEmRtn9JG5bOA1wkgR80bqxskVhTqU49TUNcL5sPECQsguR2 VRkA== X-Gm-Message-State: APjAAAX57vRd8knMpHma79sFjm7IAY7mtNYpDHPOlfuFunXhsUgkJea+ DhiX9wT4PWKvk192Lv7tTNk= X-Google-Smtp-Source: APXvYqz3yZAjWTHjLi/K3ZodonLM4f0O+WM8WzArtmCY1L1a3s3Km8F7O6y037Owqk9ehdawt3wjsQ== X-Received: by 2002:adf:e5cc:: with SMTP id a12mr31114920wrn.130.1552510209241; Wed, 13 Mar 2019 13:50:09 -0700 (PDT) Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id c18sm42865wml.37.2019.03.13.13.50.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 13:50:08 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <44A23210-23A8-4EA0-BA42-42019600A030@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A18FF48C-6ADA-4C14-B399-7C9C1D39E663" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 13 Mar 2019 13:50:03 -0700 In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> Cc: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , Benoit Claise , Ebben Aries , Jason Sterne , Juergen Schoenwaelder , "Michael (Wangzitao)" , Qin Wu , Reshad Rehman , Robert Wilton , netmod@ietf.org To: Kent Watsen References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-Mailman-Approved-At: Wed, 13 Mar 2019 13:57:06 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 20:50:14 -0000 --Apple-Mail=_A18FF48C-6ADA-4C14-B399-7C9C1D39E663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not aware of any IPR that applies to this draft. > On Mar 13, 2019, at 1:29 PM, Kent Watsen wrote: >=20 > To each author and contributor listed on the "To" line. >=20 > In order to complete the Adoption poll, are you aware of any IPR that = applies > to yang-versioning-reqs-02? Please Reply-All to *this* email and = state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If "yes", has this IPR been disclosed in compliance with IETF IPR = rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If "yes" again, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think = appropriate. >=20 > If you are listed as a document author or contributor please answer = the above by > responding to this email regardless of whether or not you are aware of = any relevant > IPR. This document will not advance to the next stage until a = response has been > received from each author and listed contributor. NOTE: THIS APPLIES = TO ALL > OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed as an author > or contributor, we remind you of your obligations under the IETF IPR = rules which > encourages you to notify the IETF if you are aware of IPR of others on = an IETF > contribution, or to refrain from participating in any contribution or = discussion related > to your undisclosed IPR. For more information, please see the RFCs = listed above > and = http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty = . >=20 > Thank you, > Kent // as co-Chair >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A18FF48C-6ADA-4C14-B399-7C9C1D39E663 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = am not aware of any IPR that applies to this draft.
On Mar = 13, 2019, at 1:29 PM, Kent Watsen <kent+ietf@watsen.net> wrote:

To each author and = contributor listed on the "To" line.

In = order to complete the Adoption poll, are you aware of any IPR that = applies
to yang-versioning-reqs-02?  Please Reply-All = to *this* email and state either:

"No, I'm = not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in = compliance with IETF IPR rules
(see RFCs 3669, 5378 and = 8179 for more details)?

If "yes" again, = please state either:

"Yes, the IPR has been = disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you = think appropriate.

If you are listed as a = document author or contributor please answer the above by
responding to this email regardless of whether or not you are = aware of any relevant
IPR.  This document will not = advance to the next stage until a response has been
received= from each author and listed contributor.  NOTE: THIS APPLIES TO = ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG = meetings but are not listed as an author
or contributor, = we remind you of your obligations under the IETF IPR rules which
encourages you to notify the IETF if you are aware of IPR of = others on an IETF
contribution, or to refrain from = participating in any contribution or discussion related
to = your undisclosed IPR. For more information, please see the RFCs listed = above
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro= perty.

Thank you,
Kent // = as co-Chair


Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_A18FF48C-6ADA-4C14-B399-7C9C1D39E663-- From nobody Wed Mar 13 17:22:04 2019 Return-Path: <010001697993a08b-0a38677e-ce2f-445e-90f3-482610c46507-000000@amazonses.watsen.net> 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 984C01200D7 for ; Wed, 13 Mar 2019 17:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 3LueSSukoYDA for ; Wed, 13 Mar 2019 17:21:54 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1680C124B16 for ; Wed, 13 Mar 2019 17:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552522912; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=l5qmnnvVcn+lgCHtFTnUPnbNvsk45QzivX8FXxej8Qk=; b=SSAkxuzuUJxHzmfd8Xe9Jiav8zwCCs527OYjwncphA8dehc4qAX1UuCgRfDpEWfq iQezVbfKmQ/TGJJ2lsIj+3JBzyNOjMeoz7UxCq7WfQF3h7tIwao2uLTJuPXyznOVHFL 7dmIQ/aAMs9Aav6nfrf1P2FqW8mKJuMZvHEHz3dA= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E15843-E955-43DF-90F2-E30CC8B2B8F4" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <010001697993a08b-0a38677e-ce2f-445e-90f3-482610c46507-000000@email.amazonses.com> Date: Thu, 14 Mar 2019 00:21:51 +0000 To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.14-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] NETMOD 104 Draft Agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 00:21:57 -0000 --Apple-Mail=_E8E15843-E955-43DF-90F2-E30CC8B2B8F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft agenda below (also posted here: = https://datatracker.ietf.org/doc/agenda-104-netmod = ). Please send any comments and/or concerns to the chairs. ALERT: Due to a large number of folks not being present for NETMOD = Session-2 on=20 Friday, and an unusually low NETCONF agenda, the NETCONF = Chairs agreed to let NETMOD use some of its scheduled time, thus enabling = NETMOD to CANCEL its originally scheduled second session. Agenda for the NETMOD WG Session in IETF 104 -------------------------------------------- Sessions: - MONDAY, 10:00-11:00, Grand Ballroom (2nd-half of NETCONF's session) - MONDAY, 13:50-15:50, Congress Hall 1 - FRIDAY, 10:50-12:50, Congress Hall 3 (CANCELLED) WG Chairs: Lou Berger (lberger at labn dot net) Kent Watsen (kwatsen at juniper dot net) Joel Jaeggli (joelja at bogus dot com Available During Session: Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-104-netmod Slides: https://datatracker.ietf.org/meeting/104/session/netmod Meetecho: http://www.meetecho.com/ietf104/netmod/ Jabber: xmpp:netmod@jabber.ietf.org?join Available Post Session: Recording: https://www.ietf.org/audio/ietf104/ YouTube: https://www.youtube.com/user/ietf/playlists Session 1: *** 2nd-half of NETCONF Session *** When: MONDAY, March 25, 2019 10:00-11:00 Where: Grand Ballroom Audio: http://mp3.conf.meetecho.com/ietf/ietf1046.m3u Chairs (5 minutes) Introduction Rob Wilton and Company (45 min) YANG Versioning Design Team Update https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00 Rob Wilton (10 min) YANG Packages https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01 Session 2: When: MONDAY, March 25, 2019 13:50-15:50 Where: Grand Ballroom Audio: http://mp3.conf.meetecho.com/ietf/ietf1043.m3u Introduction Chairs (10 minutes) Session Intro & WG Status WG documents items: Balazs Lengyel (10 min) YANG Instance Data File Format = https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02= Martin or Andy (10 min) YANG Data Structure Extensions https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02 Kent Watsen (10 min) Handling Long Lines in Inclusions in Internet-Drafts and RFCs https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-01 Non-Chartered items: Kent Watsen (15 min) YANG Next Analysis Qin Wu (10 min) Factory default Setting https://tools.ietf.org/html/draft-wu-netmod-factory-default-02 Qin Wu (10 min) NMDA Base Notification for Applied Intended Configuration = https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-01 Christian Hopps (10 min) YANG Geographic Location https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01 Juergen Schoenwaelder (15 min) Update of Common YANG Data Types (RFC 6991) https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00 Michale Wang / Chongfeng Xie (10 min) A YANG Data model for Policy based Event Management https://tools.ietf.org/html/draft-wwx-netmod-event-yang-01 Session - 3: CANCELLED When: MONDAY, March 25, 2019 09:00-11:00 Where: Grand Ballroom Audio: http://mp3.conf.meetecho.com/ietf/ietf1045.m3u CANCELLED --Apple-Mail=_E8E15843-E955-43DF-90F2-E30CC8B2B8F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Draft agenda below (also posted = here: https://datatracker.ietf.org/doc/agenda-104-netmod).
Please send any comments and/or concerns to the = chairs.

ALERT: = Due to a large number of folks not being present for NETMOD Session-2 = on 
            =  Friday, and an unusually low NETCONF agenda, the NETCONF Chairs = agreed
             to = let NETMOD use some of its scheduled time, thus enabling NETMOD to
             CANCEL its = originally scheduled second session.

Agenda for the NETMOD WG =
Session in IETF 104
--------------------------------------------

Sessions:
 - MONDAY, 10:00-11:00, Grand Ballroom   (2nd-half of NETCONF's session)
 - MONDAY, 13:50-15:50, Congress Hall 1
 - FRIDAY, 10:50-12:50, Congress Hall 3  (CANCELLED)


WG Chairs:
  Lou Berger (lberger at labn dot net)
  Kent Watsen (kwatsen at juniper dot net)
  Joel Jaeggli (joelja at bogus dot com

Available During Session:
  Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-104-netmod
  Slides: https://datatracker.ietf.org/meeting/104/session/netmod
  Meetecho:      http://www.meetecho.com/ietf104/netmod/
  Jabber:        xmpp:netmod@jabber.ietf.org?join

Available Post Session:
  Recording:     https://www.ietf.org/audio/ietf104/
  YouTube:       https://www.youtube.com/user/ietf/playlists



Session 1:  *** 2nd-half of NETCONF Session ***

  When:  MONDAY, March 25, 2019 10:00-11:00
  Where: Grand Ballroom
  Audio: http://mp3.conf.meetecho.com/ietf/ietf1046.m3u

  Chairs (5 minutes)
  Introduction

  Rob Wilton and Company (45 min)
  YANG Versioning Design Team Update
  https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-=
reqs-02
  https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00

  Rob Wilton (10 min)
  YANG Packages
  https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-=
01



Session 2:

  When:  MONDAY, March 25, 2019 13:50-15:50
  Where: Grand Ballroom
  Audio: http://mp3.conf.meetecho.com/ietf/ietf1043.m3u


  Introduction

    Chairs (10 minutes)
    Session Intro & WG Status

  WG documents items:

    Balazs Lengyel (10 min)
    YANG Instance Data File Format
    https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-fil=
e-format-02

    Martin or Andy (10 min)
    YANG Data Structure Extensions
    https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02<=
/a>

    Kent Watsen (10 min)
    Handling Long Lines in Inclusions in Internet-Drafts and RFCs
    https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-0=
1

  Non-Chartered items:

    Kent Watsen (15 min)
    YANG Next Analysis
    <no associated draft>

    Qin Wu (10 min)
    Factory default Setting
    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02<=
/a>

    Qin Wu (10 min)
    NMDA Base Notification for Applied Intended Configuration
    https://tools.ietf.org/html/draft-wu-netmod-base-notification-n=
mda-01

    Christian Hopps (10 min)
    YANG Geographic Location
    https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01=


    Juergen Schoenwaelder (15 min)
    Update of Common YANG Data Types (RFC 6991)
    https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00=


    Michale Wang / Chongfeng Xie (10 min)
    A YANG Data model for Policy based Event Management
    https://tools.ietf.org/html/draft-wwx-netmod-event-yang-01=




Session - 3:  CANCELLED

  When:  MONDAY, March 25, 2019 09:00-11:00
  Where: Grand Ballroom
  Audio: http://mp3.conf.meetecho.com/ietf/ietf1045.m3u

  CANCELLED
= --Apple-Mail=_E8E15843-E955-43DF-90F2-E30CC8B2B8F4-- From nobody Wed Mar 13 17:22:49 2019 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 A81BE1228B7 for ; Wed, 13 Mar 2019 17:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 EcO6PD5x_HN5 for ; Wed, 13 Mar 2019 17:04:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 40B0D131249 for ; Wed, 13 Mar 2019 17:04:08 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 730FEC80DDC2E1E1DDEF; Thu, 14 Mar 2019 00:04:06 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Mar 2019 00:04:05 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Thu, 14 Mar 2019 08:03:55 +0800 From: Qin Wu To: "Sterne, Jason (Nokia - CA/Ottawa)" , Kent Watsen , Joe Clarke , =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= , "Benoit Claise" , Ebben Aries , "Juergen Schoenwaelder" , Mahesh Jethanandani , wangzitao , "Reshad Rahman (rrahman)" , Rob Wilton CC: netmod Thread-Topic: IPR poll on yang-versioning-reqs-02 Thread-Index: AQHU2duOD6QFEQoNd0il0jgFub9VN6YJglCAgAC8y3U= Date: Thu, 14 Mar 2019 00:03:54 +0000 Message-ID: References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B2E9C47nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Wed, 13 Mar 2019 17:22:48 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 00:04:12 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9B2E9C47nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Tm8sIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgYXBwbGljYWJsZSB0byB0aGlzIGRyYWZ0Lg0K DQq3orz+yMujuiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkNCsrVvP7Iy6O6IEtl bnQgV2F0c2VuPGtlbnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50K2lldGZAd2F0c2VuLm5l dD4+O0pvZSBDbGFya2U8amNsYXJrZUBjaXNjby5jb208bWFpbHRvOmpjbGFya2VAY2lzY28uY29t Pj47QmFsqKJ6cyBMZW5neWVsPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86YmFs YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPj47QmVub2l0IENsYWlzZTxiY2xhaXNlQGNpc2NvLmNv bTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PjtFYmJlbiBBcmllczxleGFAanVuaXBlci5uZXQ8 bWFpbHRvOmV4YUBqdW5pcGVyLm5ldD4+O0p1ZXJnZW4gU2Nob2Vud2FlbGRlcjxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZT4+O01haGVzaCBKZXRoYW5hbmRhbmk8bWpldGhhbmFuZGFuaUBnbWFpbC5j b208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj47d2FuZ3ppdGFvPHdhbmd6aXRhb0Bo dWF3ZWkuY29tPG1haWx0bzp3YW5neml0YW9AaHVhd2VpLmNvbT4+O1FpbiBXdTxiaWxsLnd1QGh1 YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+O1Jlc2hhZCBSYWhtYW4gKHJyYWht YW4pPHJyYWhtYW5AY2lzY28uY29tPG1haWx0bzpycmFobWFuQGNpc2NvLmNvbT4+O1JvYiBXaWx0 b248cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4NCrOty82juiBu ZXRtb2Q8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0K1vfM4qO6IFJF OiBJUFIgcG9sbCBvbiB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KyrG85KO6IDIwMTktMDMtMTQg MDQ6NDg6MjANCg0KTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdC4NCkphc29uIFN0ZXJuZQ0KDQpGcm9tOiBLZW50IFdhdHNlbiA8a2VudCtpZXRm QHdhdHNlbi5uZXQ+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDEzLCAyMDE5IDQ6MzAgUE0NClRv OiBKb2UgQ2xhcmtlIDxqY2xhcmtlQGNpc2NvLmNvbT47IEJhbKiienMgTGVuZ3llbCA8YmFsYXpz Lmxlbmd5ZWxAZXJpY3Nzb24uY29tPjsgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+ OyBFYmJlbiBBcmllcyA8ZXhhQGp1bmlwZXIubmV0PjsgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBD QS9PdHRhd2EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPjsgSnVlcmdlbiBTY2hvZW53YWVsZGVy IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyBNYWhlc2ggSmV0aGFuYW5k YW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT47IE1pY2hhZWwgKFdhbmd6aXRhbykgPHdhbmd6 aXRhb0BodWF3ZWkuY29tPjsgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBSZXNoYWQgUmFo bWFuIChycmFobWFuKSA8cnJhaG1hbkBjaXNjby5jb20+OyBSb2IgV2lsdG9uIDxyd2lsdG9uQGNp c2NvLmNvbT4NCkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBwb2xsIG9uIHlhbmct dmVyc2lvbmluZy1yZXFzLTAyDQoNClRvIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvciBsaXN0 ZWQgb24gdGhlICJUbyIgbGluZS4NCg0KSW4gb3JkZXIgdG8gY29tcGxldGUgdGhlIEFkb3B0aW9u IHBvbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMNCnRvIHlhbmctdmVy c2lvbmluZy1yZXFzLTAyPyAgUGxlYXNlIFJlcGx5LUFsbCB0byAqdGhpcyogZW1haWwgYW5kIHN0 YXRlIGVpdGhlcjoNCg0KIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz IHRvIHRoaXMgZHJhZnQiDQpvcg0KIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCINCg0KSWYgInllcyIsIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzNjY5LCA1Mzc4IGFu ZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiAieWVzIiBhZ2FpbiwgcGxlYXNlIHN0YXRl IGVpdGhlcjoNCg0KIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlz Y2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25h bCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMg YSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUg YnkNCnJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90 IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQpJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwg bm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbg0K cmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiAgTk9URTog VEhJUyBBUFBMSUVTIFRPIEFMTA0KT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUyBUTyBM SU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVl dGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcg0Kb3IgY29udHJpYnV0b3IsIHdl IHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMg d2hpY2gNCmVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJl IG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURg0KY29udHJpYnV0aW9uLCBvciB0byByZWZyYWlu IGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVs YXRlZA0KdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVh c2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZQ0KYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5 b3UsDQpLZW50IC8vIGFzIGNvLUNoYWlyDQo= --_000_B8F9A780D330094D99AF023C5877DABA9B2E9C47nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
No, I am not aware o= f any IPR applicable to this draft.

=B7=A2=BC=FE=C8=CB=A3=BA Sterne, Jason (Nokia - CA/Ottawa)
=CA=D5=BC=FE=C8=CB=A3=BA Kent Watsen<kent+ietf@watsen.net>;Joe Clarke<jclarke@cisco.com>;Bal=A8=A2zs Lengyel= <balazs.lengyel@ericsson.= com>;Benoit Claise<bclaise@cisco.com>;E= bben Aries<exa@juniper.net>;Ju= ergen Schoenwaelder<j.schoenwaelder@jacobs-university.de>;Mahesh Jethanandani<mjethanandani@g= mail.com>;wangzitao<wangz= itao@huawei.com>;Qin Wu<bil= l.wu@huawei.com>;Reshad Rahman (rrahman)<rrahman@cisco.com>;Rob Wilton<rwilton@cisco.com>
=B3=AD=CB=CD=A3=BA netmod<netmod@ietf.org>
=D6=F7=CC=E2=A3=BA RE: IPR poll on yang-versioning-reqs-02
=CA=B1=BC=E4=A3=BA 2019-03-14 04:48:20

No, I'm not aware of any IPR that applies to this dr= aft.

Jason Sterne

 

From: Kent Watsen <kent+ietf@watsen.net>
Sent: Wednesday, March 13, 2019 4:30 PM
To: Joe Clarke <jclarke@cisco.com>; Bal=A8=A2zs Lengyel <ba= lazs.lengyel@ericsson.com>; Benoit Claise <bclaise@cisco.com>; Ebb= en Aries <exa@juniper.net>; Sterne, Jason (Nokia - CA/Ottawa) <jas= on.sterne@nokia.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-u= niversity.de>; Mahesh Jethanandani <mjethanandani@gmail.com>; Michael (Wangzitao) &= lt;wangzitao@huawei.com>; Qin Wu <bill.wu@huawei.com>; Reshad Rahm= an (rrahman) <rrahman@cisco.com>; Rob Wilton <rwilton@cisco.com>= ;
Cc: netmod@ietf.org
Subject: IPR poll on yang-versioning-reqs-02

 

To each author and co= ntributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that appli= es
to yang-versioning-reqs-02?  Please Reply-All to *this* email and stat= e either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR= rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by
responding to this email regardless of whether or not you are aware of any = relevant
IPR.  This document will not advance to the next stage until a respons= e has been
received from each author and listed contributor.  NOTE: THIS APPLIES = TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author
or contributor, we remind you of your obligations under the IETF IPR rules = which
encourages you to notify the IETF if you are aware of IPR of others on an I= ETF
contribution, or to refrain from participating in any contribution or discu= ssion related
to your undisclosed IPR. For more information, please see the RFCs listed a= bove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellectual= Property.

Thank you,
Kent // as co-Chair

--_000_B8F9A780D330094D99AF023C5877DABA9B2E9C47nkgeml513mbxchi_-- From nobody Wed Mar 13 19:06:10 2019 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 5CA821310D4 for ; Wed, 13 Mar 2019 18:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 21a95rUf8koz for ; Wed, 13 Mar 2019 18:36:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 ACB10129524 for ; Wed, 13 Mar 2019 18:36:32 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8785E52B9B6F0C011995; Thu, 14 Mar 2019 01:36:30 +0000 (GMT) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Mar 2019 01:36:29 +0000 Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 14 Mar 2019 01:36:29 +0000 Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Thu, 14 Mar 2019 01:36:29 +0000 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.77]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Thu, 14 Mar 2019 09:36:19 +0800 From: wangzitao To: Kent Watsen , Joe Clarke , =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= , "Benoit Claise" , Ebben Aries , Jason Sterne , Juergen Schoenwaelder , Mahesh Jethanandani , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton CC: "netmod@ietf.org" Thread-Topic: IPR poll on yang-versioning-reqs-02 Thread-Index: AdTaBj+EQ8+R3jDIQNaTJtiNwE4/bg== Date: Thu, 14 Mar 2019 01:36:19 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2D96FE5FDGGEMM527MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Wed, 13 Mar 2019 19:06:08 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 01:36:37 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2D96FE5FDGGEMM527MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0K Qi5SLg0KLU1pY2hhZWwNCg0Kt6K8/sjLOiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQraWV0ZkB3 YXRzZW4ubmV0XQ0Kt6LLzcqxvOQ6IDIwMTnE6jPUwjE0yNUgNDozMA0KytW8/sjLOiBKb2UgQ2xh cmtlIDxqY2xhcmtlQGNpc2NvLmNvbT47IEJhbKiienMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxA ZXJpY3Nzb24uY29tPjsgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+OyBFYmJlbiBB cmllcyA8ZXhhQGp1bmlwZXIubmV0PjsgSmFzb24gU3Rlcm5lIDxqYXNvbi5zdGVybmVAbm9raWEu Y29tPjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+OyBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT47 IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+OyBRaW4gV3UgPGJpbGwud3VAaHVhd2Vp LmNvbT47IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFuQGNpc2NvLmNvbT47IFJvYiBX aWx0b24gPHJ3aWx0b25AY2lzY28uY29tPg0Ks63LzTogbmV0bW9kQGlldGYub3JnDQrW98ziOiBJ UFIgcG9sbCBvbiB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQpUbyBlYWNoIGF1dGhvciBhbmQg Y29udHJpYnV0b3IgbGlzdGVkIG9uIHRoZSAiVG8iIGxpbmUuDQoNCkluIG9yZGVyIHRvIGNvbXBs ZXRlIHRoZSBBZG9wdGlvbiBwb2xsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBs aWVzDQp0byB5YW5nLXZlcnNpb25pbmctcmVxcy0wMj8gIFBsZWFzZSBSZXBseS1BbGwgdG8gKnRo aXMqIGVtYWlsIGFuZCBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJ UFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmICJ5ZXMiLCBoYXMgdGhpcyBJUFIg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJG Q3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgInllcyIgYWdh aW4sIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xv c2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCm9yDQoiTm8sIHRoZSBJUFIg aGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3Zp ZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuDQoNCklmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBh bnN3ZXIgdGhlIGFib3ZlIGJ5DQpyZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBv ZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudA0KSVBSLiAgVGhp cyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVz cG9uc2UgaGFzIGJlZW4NCnJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250 cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwNCk9GIFlPVSBMSVNURUQgSU4gVEhJ UyBNRVNTQUdFJ1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qg b3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3INCm9y IGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhl IElFVEYgSVBSIHJ1bGVzIHdoaWNoDQplbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYg aWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYNCmNvbnRyaWJ1dGlv biwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBv ciBkaXNjdXNzaW9uIHJlbGF0ZWQNCnRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUNCmFuZCBodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9w ZXJ0eS4NCg0KVGhhbmsgeW91LA0KS2VudCAvLyBhcyBjby1DaGFpcg0K --_000_E6BC9BBCBCACC246846FC685F9FF41EA2D96FE5FDGGEMM527MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR that = applies to this draft.

 

B.R.

-Michael

 

=B7=A2=BC=FE=C8=CB: Kent Watsen [m= ailto:kent+ietf@watsen.net]
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2019=C4=EA3=D4=C214=C8=D5 4:30
=CA=D5=BC=FE=C8=CB: Joe Clarke <jclarke@cisco.com>; Bal=A8=A2zs Lengyel <balazs.lengyel@ericsson.com>; Benoit Claise <b= claise@cisco.com>; Ebben Aries <exa@juniper.net>; Jason Sterne <= ;jason.sterne@nokia.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Mahesh= Jethanandani <mjethanandani@gmail.com>; wangzitao <wangzitao@huaw= ei.com>; Qin Wu <bill.wu@huawei.com>; Reshad Rahman (rrahman) <= rrahman@cisco.com>; Rob Wilton <rwilton@cisco.com>
=B3=AD=CB=CD: netmod@ietf.org
=D6=F7=CC=E2: IPR poll on yang-versioning-reqs-02

 

= To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that appli= es
to yang-versioning-reqs-02?  Please Reply-All to *this* email and stat= e either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR= rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by
responding to this email regardless of whether or not you are aware of any = relevant
IPR.  This document will not advance to the next stage until a respons= e has been
received from each author and listed contributor.  NOTE: THIS APPLIES = TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author
or contributor, we remind you of your obligations under the IETF IPR rules = which
encourages you to notify the IETF if you are aware of IPR of others on an I= ETF
contribution, or to refrain from participating in any contribution or discu= ssion related
to your undisclosed IPR. For more information, please see the RFCs listed a= bove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellectual= Property.

Thank you,
Kent // as co-Chair

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2D96FE5FDGGEMM527MBXchi_-- From nobody Thu Mar 14 07:23:36 2019 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 AF6751200D7 for ; Wed, 13 Mar 2019 23:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 6waHXHeHeSW0 for ; Wed, 13 Mar 2019 23:40:43 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D488127916 for ; Wed, 13 Mar 2019 23:40:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 19241A8F; Thu, 14 Mar 2019 07:40:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 8jadH5O52W_N; Thu, 14 Mar 2019 07:40:40 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 14 Mar 2019 07:40:40 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id A41BA20086; Thu, 14 Mar 2019 07:40:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id YlS2cqnMdxGJ; Thu, 14 Mar 2019 07:40:40 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1B40B20082; Thu, 14 Mar 2019 07:40:40 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 14 Mar 2019 07:40:38 +0100 Received: by anna.localdomain (Postfix, from userid 501) id EB13B300733C82; Thu, 14 Mar 2019 07:40:37 +0100 (CET) Date: Thu, 14 Mar 2019 07:40:37 +0100 From: Juergen Schoenwaelder To: Kent Watsen CC: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Benoit Claise , Ebben Aries , Jason Sterne , Mahesh Jethanandani , "Michael (Wangzitao)" , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton , Message-ID: <20190314064037.3gbv3mvwbfcn7lbr@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Benoit Claise , Ebben Aries , Jason Sterne , Mahesh Jethanandani , "Michael (Wangzitao)" , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton , netmod@ietf.org References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> User-Agent: NeoMutt/20180716 X-Originating-IP: [10.50.218.117] X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) Archived-At: X-Mailman-Approved-At: Thu, 14 Mar 2019 07:23:34 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 06:40:47 -0000 I'm not aware of any IPR that applies to this draft. /js On Wed, Mar 13, 2019 at 08:29:57PM +0000, Kent Watsen wrote: > To each author and contributor listed on the "To" line. > > In order to complete the Adoption poll, are you aware of any IPR that applies > to yang-versioning-reqs-02? Please Reply-All to *this* email and state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If "yes", has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If "yes" again, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think appropriate. > > If you are listed as a document author or contributor please answer the above by > responding to this email regardless of whether or not you are aware of any relevant > IPR. This document will not advance to the next stage until a response has been > received from each author and listed contributor. NOTE: THIS APPLIES TO ALL > OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed as an author > or contributor, we remind you of your obligations under the IETF IPR rules which > encourages you to notify the IETF if you are aware of IPR of others on an IETF > contribution, or to refrain from participating in any contribution or discussion related > to your undisclosed IPR. For more information, please see the RFCs listed above > and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty . > > Thank you, > Kent // as co-Chair > -- 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 Mar 14 07:23:44 2019 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 551651277C9 for ; Thu, 14 Mar 2019 02:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 SpKvGon_e8oW for ; Thu, 14 Mar 2019 02:08:22 -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 09B9F1200D7 for ; Thu, 14 Mar 2019 02:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1780; q=dns/txt; s=iport; t=1552554502; x=1553764102; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zP6JFcc5i3frHf8CUS7eUPNq96RRbUEfURfBT/fWv6M=; b=fWvJi0zrZS8j7B8O3K/C4xzse7DLyCAEUBd4Ar3RjAApVa9s0mE4A0D+ FxaJ4iJmmrP4O710a1CGk39PYrO/XTBYuykyOLA0akbRFY8Tvfw7psYKw JP+sikHF//mNGwJly/5Y10cgAjtnFhVbUjF0sER8neIF4lhPPDtF96EKW Q=; X-IronPort-AV: E=Sophos;i="5.58,477,1544486400"; d="scan'208";a="10677527" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 09:08:20 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2E98JSY017113; Thu, 14 Mar 2019 09:08:19 GMT To: Kent Watsen , Joe Clarke , =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Ebben Aries , Jason Sterne , Juergen Schoenwaelder , Mahesh Jethanandani , "Michael (Wangzitao)" , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton Cc: netmod@ietf.org References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> From: Benoit Claise Message-ID: <09c5fb5e-8d42-8f82-2a1a-6c97df65c329@cisco.com> Date: Thu, 14 Mar 2019 10:08:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.55.221.36, ams-bclaise-nitro3.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 14 Mar 2019 07:23:34 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 09:08:24 -0000 No, I'm not aware of any IPR that applies to this draft. Benoit > To each author and contributor listed on the "To" line. > > In order to complete the Adoption poll, are you aware of any IPR that > applies > to yang-versioning-reqs-02?  Please Reply-All to *this* email and > state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If "yes", has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If "yes" again, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer > the above by > responding to this email regardless of whether or not you are aware of > any relevant > IPR.  This document will not advance to the next stage until a > response has been > received from each author and listed contributor.  NOTE: THIS APPLIES > TO ALL > OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not > listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which > encourages you to notify the IETF if you are aware of IPR of others on > an IETF > contribution, or to refrain from participating in any contribution or > discussion related > to your undisclosed IPR. For more information, please see the RFCs > listed above > and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > Kent // as co-Chair > From nobody Thu Mar 14 07:23:50 2019 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 2E72D128B36 for ; Thu, 14 Mar 2019 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 rVY2lFVyTpIa for ; Thu, 14 Mar 2019 02:37:16 -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 B93B7128BCC for ; Thu, 14 Mar 2019 02:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8453; q=dns/txt; s=iport; t=1552556235; x=1553765835; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=g6dC46gEUkcbpno+pPSFec93AdENlGNw0B3fgZAoKcY=; b=F+Vwt1OlHEX6ldKVHVSEJdqAz/CJpfaFcuzYGlmoqE4IB71dS5jtriXQ 816qgc3Q8DkYehTSTKOeExEwDi8oSALQ50cnqCSnqRQolwQdAY4/37T7s IcIS6ea4RKGYKthRKNPUtufN9hOf5irIVUdYCDnIyI1hCSlhszUQRgj/8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB8H4pc/5tdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1TL2iBAycKjB2NLIkxiQmFdhSBZws?= =?us-ascii?q?BASOESQKETiI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQtRwUQAgEIEAEEAQEvIRE?= =?us-ascii?q?dCAIEAQ0FCIMbgRFMAxUPrzaEBAGEBg2CH4EvAYssF4FAP4ERgxKCVzwLAoE?= =?us-ascii?q?uARIBhgADig+GT2mSRDUJAodWg3+ECYM3IYF7WoUQi2aKf4VzgTKLQgIRFYE?= =?us-ascii?q?oDRI4ZXFwFTuCbAmLA4UIATZBMQGNaIEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,478,1544486400"; d="scan'208,217";a="245417986" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 09:37:14 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2E9bEnj020347 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Mar 2019 09:37:14 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Mar 2019 04:37:14 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 14 Mar 2019 04:37:14 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen , "Joe Clarke (jclarke)" , =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "Benoit Claise (bclaise)" , Ebben Aries , Jason Sterne , "Juergen Schoenwaelder" , Mahesh Jethanandani , "Michael (Wangzitao)" , "Qin Wu" , "Reshad Rahman (rrahman)" CC: "netmod@ietf.org" Thread-Topic: IPR poll on yang-versioning-reqs-02 Thread-Index: AQHU2duJzXEipOU2+0iwjlJwZAzOMaYK3x1g Date: Thu, 14 Mar 2019 09:37:13 +0000 Message-ID: <639bbd3e42a249a0a18caf0ef9ef5006@XCH-RCD-007.cisco.com> References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> 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.63.23.135] Content-Type: multipart/alternative; boundary="_000_639bbd3e42a249a0a18caf0ef9ef5006XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 14 Mar 2019 07:23:34 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 09:37:20 -0000 --_000_639bbd3e42a249a0a18caf0ef9ef5006XCHRCD007ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Thanks, Rob From: Kent Watsen Sent: 13 March 2019 20:30 To: Joe Clarke (jclarke) ; Bal=E1zs Lengyel ; Benoit Claise (bclaise) ; Ebben Aries= ; Jason Sterne ; Juergen Schoenwa= elder ; Mahesh Jethanandani ; Michael (Wangzitao) ; Qin Wu ; Reshad Rahman (rrahman) ; Rob Wilton (rw= ilton) Cc: netmod@ietf.org Subject: IPR poll on yang-versioning-reqs-02 To each author and contributor listed on the "To" line. In order to complete the Adoption poll, are you aware of any IPR that appli= es to yang-versioning-reqs-02? Please Reply-All to *this* email and state eit= her: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If "yes", has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If "yes" again, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware of any = relevant IPR. This document will not advance to the next stage until a response has= been received from each author and listed contributor. NOTE: THIS APPLIES TO AL= L OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF IPR rules = which encourages you to notify the IETF if you are aware of IPR of others on an I= ETF contribution, or to refrain from participating in any contribution or discu= ssion related to your undisclosed IPR. For more information, please see the RFCs listed a= bove and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, Kent // as co-Chair --_000_639bbd3e42a249a0a18caf0ef9ef5006XCHRCD007ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No, I'm not aware of any IPR that applies to this dr= aft.

 

Thanks,

Rob

 = ;

From= : Kent Watsen <kent+ietf@watsen.net>
Sent: 13 March 2019 20:30
To: Joe Clarke (jclarke) <jclarke@cisco.com>; Bal=E1zs Lengyel= <balazs.lengyel@ericsson.com>; Benoit Claise (bclaise) <bclaise@c= isco.com>; Ebben Aries <exa@juniper.net>; Jason Sterne <jason.s= terne@nokia.com>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-unive= rsity.de>; Mahesh Jethanandani <mjethanandani@gmail.com>; Michael (Wangzitao) &= lt;wangzitao@huawei.com>; Qin Wu <bill.wu@huawei.com>; Reshad Rahm= an (rrahman) <rrahman@cisco.com>; Rob Wilton (rwilton) <rwilton@ci= sco.com>
Cc: netmod@ietf.org
Subject: IPR poll on yang-versioning-reqs-02

 

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that appli= es
to yang-versioning-reqs-02?  Please Reply-All to *this* email and stat= e either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR= rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by
responding to this email regardless of whether or not you are aware of any = relevant
IPR.  This document will not advance to the next stage until a respons= e has been
received from each author and listed contributor.  NOTE: THIS APPLIES = TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author
or contributor, we remind you of your obligations under the IETF IPR rules = which
encourages you to notify the IETF if you are aware of IPR of others on an I= ETF
contribution, or to refrain from participating in any contribution or discu= ssion related
to your undisclosed IPR. For more information, please see the RFCs listed a= bove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellectual= Property.

Thank you,
Kent // as co-Chair

--_000_639bbd3e42a249a0a18caf0ef9ef5006XCHRCD007ciscocom_-- From nobody Thu Mar 14 07:23:58 2019 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 352CC130EA1 for ; Thu, 14 Mar 2019 06:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 EioRL4v_OSmQ for ; Thu, 14 Mar 2019 06:20:38 -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 2E806130E9F for ; Thu, 14 Mar 2019 06:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=404; q=dns/txt; s=iport; t=1552569638; x=1553779238; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/bdPccFy829JWLQm9ZttR2kOELgLVk4HGEFX8gpSSfU=; b=VDSstl7Yl5V6KUj47e+8Fhbrxyu30rYquyDFl7B5IzBVF3IPw2vXsGDn 2GWTYycjHrzVfKy84/IxXbVh6wBoc2tIE3TuCnH0JJTuEVcOxpM5dw95f 2QCKyJwyFSyfi2vtfKlZq4u6yL4UQK7RPxamdLlJuBeaLPO2B1NW8lVq6 c=; X-IronPort-AV: E=Sophos;i="5.58,478,1544486400"; d="scan'208";a="535242720" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 13:20:37 +0000 Received: from [192.168.10.214] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id x2EDKanU007973; Thu, 14 Mar 2019 13:20:36 GMT To: Kent Watsen , =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Benoit Claise , Ebben Aries , Jason Sterne , Juergen Schoenwaelder , Mahesh Jethanandani , "Michael (Wangzitao)" , Qin Wu , "Reshad Rahman (rrahman)" , Rob Wilton Cc: netmod@ietf.org References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA== Organization: Cisco Message-ID: <6af7cdf4-b13d-04f9-4ae9-982181206c0c@cisco.com> Date: Thu, 14 Mar 2019 09:20:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 14 Mar 2019 07:23:34 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:20:49 -0000 On 3/13/19 16:29, Kent Watsen wrote: > To each author and contributor listed on the "To" line. > > In order to complete the Adoption poll, are you aware of any IPR that > applies > to yang-versioning-reqs-02?  Please Reply-All to *this* email and state > either: > > "No, I'm not aware of any IPR that applies to this draft" No, I am not aware of any IPR that applies to this draft. Joe From nobody Thu Mar 14 07:41:52 2019 Return-Path: <010001697ca6e297-3643b2b8-bc9c-4088-80bf-4f329b04e260-000000@amazonses.watsen.net> 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 7F78F130E99 for ; Thu, 14 Mar 2019 07:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 6OQcQXl3NZsF for ; Thu, 14 Mar 2019 07:41:47 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712A4130E95 for ; Thu, 14 Mar 2019 07:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552574505; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=/9r3y16yQTLpgx/N0tS5rcNtR0UCwZP4EwEDjMBIdZs=; b=RhPUD4Qr0HW9ghQI/KhhaCZOOh73yNhyrqtVG+JkJkU/Rw9uKOVu/yHkcdpGNs+M JVv3jrm8zWMWN3MXWqLx1+FCt4OW2BaCBM47D0Pc23Encb7rHbFQ27DmRHT+4rJl5eu GCbxbMFKMP8U0ju+yfRKB/uiZdyxbfbMS+fn8a3Y= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_D46F305D-A4EF-4446-832F-F3D1ED01CED3" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 14 Mar 2019 14:41:45 +0000 References: <010001697993a08b-0a38677e-ce2f-445e-90f3-482610c46507-000000@email.amazonses.com> To: NETMOD Working Group In-Reply-To: <010001697993a08b-0a38677e-ce2f-445e-90f3-482610c46507-000000@email.amazonses.com> Message-ID: <010001697ca6e297-3643b2b8-bc9c-4088-80bf-4f329b04e260-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.14-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] NETMOD 104 Draft Agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 14:41:51 -0000 --Apple-Mail=_D46F305D-A4EF-4446-832F-F3D1ED01CED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Draft agenda has been updated (also posted here: = https://datatracker.ietf.org/doc/agenda-104-netmod) Please send any comments and/or concerns to the chairs. Agenda for the NETMOD WG Session in IETF 104 -------------------------------------------- Sessions: - MONDAY, 10:00-11:00, Grand Ballroom (2nd-half of NETCONF's session) - MONDAY, 13:50-15:50, Congress Hall 1 - FRIDAY, 10:50-12:50, Congress Hall 3 (CANCELLED) WG Chairs: Lou Berger (lberger at labn dot net) Kent Watsen (kent+ietf at watsen dot net) Joel Jaeggli (joelja at bogus dot com Available During Session: Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-104-netmod Slides: https://datatracker.ietf.org/meeting/104/session/netmod Meetecho: http://www.meetecho.com/ietf104/netmod/ Jabber: xmpp:netmod@jabber.ietf.org?join Available Post Session: Recording: https://www.ietf.org/audio/ietf104/ YouTube: https://www.youtube.com/user/ietf/playlists Session 1: *** 2nd-half of NETCONF Session *** When: MONDAY, March 25, 2019 10:00-11:00 Where: Grand Ballroom Audio: http://mp3.conf.meetecho.com/ietf/ietf1046.m3u Chairs (5 minutes) Introduction Rob Wilton and Company (55 min) YANG Versioning Design Team Update https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00 https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01 https://tools.ietf.org/html/draft-wilton-netmod-yang-ver-selection-00 Session 2: When: MONDAY, March 25, 2019 13:50-15:50 Where: Grand Ballroom Audio: http://mp3.conf.meetecho.com/ietf/ietf1043.m3u Introduction Chairs (10 minutes) Session Intro & WG Status WG documents items: Balazs Lengyel (10 min) YANG Instance Data File Format = https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02= Martin or Andy (10 min) YANG Data Structure Extensions https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02 Kent Watsen (10 min) Handling Long Lines in Inclusions in Internet-Drafts and RFCs https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-01 Non-Chartered items: Kent Watsen (15 min) YANG Next Analysis Qin Wu (10 min) Factory default Setting https://tools.ietf.org/html/draft-wu-netmod-factory-default-02 Qin Wu (10 min) NMDA Base Notification for Applied Intended Configuration = https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-01 Christian Hopps (10 min) YANG Geographic Location https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01 Juergen Schoenwaelder (15 min) Update of Common YANG Data Types (RFC 6991) https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00 Michale Wang / Chongfeng Xie (10 min) A YANG Data model for Policy based Event Management https://tools.ietf.org/html/draft-wwx-netmod-event-yang-01 Session - 3: CANCELLED When: FRIDAY, March 29, 2019 10:50-12:50 Where: Congress Hall 3 Audio: http://mp3.conf.meetecho.com/ietf/ietf1045.m3u CANCELLED --Apple-Mail=_D46F305D-A4EF-4446-832F-F3D1ED01CED3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Draft agenda has been updated (also posted here: https://datatracker.ietf.org/doc/agenda-104-netmod)
Please send any comments and/or concerns to the chairs.


Agenda for the NETMOD WG Session in IETF 104
--------------------------------------------

Sessions:
 - MONDAY, 10:00-11:00, Grand Ballroom   (2nd-half of NETCONF's session)
 - MONDAY, 13:50-15:50, Congress Hall 1
 - FRIDAY, 10:50-12:50, Congress Hall 3  (CANCELLED)


WG Chairs:
  Lou Berger (lberger at labn dot net)
  Kent Watsen (kent+ietf at watsen dot net)
  Joel Jaeggli (joelja at bogus dot com

Available During Session:
  Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-104-netmod
  Slides: https://datatracker.ietf.org/meeting/104/session/netmod
  Meetecho:      http://www.meetecho.com/ietf104/netmod/
  Jabber:        xmpp:netmod@jabber.ietf.org?join

Available Post Session:
  Recording:     https://www.ietf.org/audio/ietf104/
  YouTube:       https://www.youtube.com/user/ietf/playlists



Session 1:  *** 2nd-half of NETCONF Session ***

  When:  MONDAY, March 25, 2019 10:00-11:00
  Where: Grand Ballroom
  Audio: http://mp3.conf.meetecho.com/ietf/ietf1046.m3u

  Chairs (5 minutes)
  Introduction

  Rob Wilton and Company (55 min)
  YANG Versioning Design Team Update
  https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02
  https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00
  https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01
  https://tools.ietf.org/html/draft-wilton-netmod-yang-ver-selection-00



Session 2:

  When:  MONDAY, March 25, 2019 13:50-15:50
  Where: Grand Ballroom
  Audio: http://mp3.conf.meetecho.com/ietf/ietf1043.m3u


  Introduction

    Chairs (10 minutes)
    Session Intro & WG Status

  WG documents items:

    Balazs Lengyel (10 min)
    YANG Instance Data File Format
    https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02

    Martin or Andy (10 min)
    YANG Data Structure Extensions
    https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02

    Kent Watsen (10 min)
    Handling Long Lines in Inclusions in Internet-Drafts and RFCs
    https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-01

  Non-Chartered items:

    Kent Watsen (15 min)
    YANG Next Analysis
    <no associated draft>

    Qin Wu (10 min)
    Factory default Setting
    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02

    Qin Wu (10 min)
    NMDA Base Notification for Applied Intended Configuration
    https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-01

    Christian Hopps (10 min)
    YANG Geographic Location
    https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01

    Juergen Schoenwaelder (15 min)
    Update of Common YANG Data Types (RFC 6991)
    https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00

    Michale Wang / Chongfeng Xie (10 min)
    A YANG Data model for Policy based Event Management
    https://tools.ietf.org/html/draft-wwx-netmod-event-yang-01



Session - 3:  CANCELLED

  When:  FRIDAY, March 29, 2019 10:50-12:50
  Where: Congress Hall 3
  Audio: http://mp3.conf.meetecho.com/ietf/ietf1045.m3u

  CANCELLED
--Apple-Mail=_D46F305D-A4EF-4446-832F-F3D1ED01CED3-- From nobody Thu Mar 14 08:18:13 2019 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 A67101311C2 for ; Thu, 14 Mar 2019 08:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ciDr26Rp; dkim=pass (1024-bit key) header.d=ericsson.com header.b=KcuVtkI1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjzX-F6uwdEU for ; Thu, 14 Mar 2019 08:17:59 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 A40BF130EDF for ; Thu, 14 Mar 2019 08:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552576674; x=1555168674; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VHIk1quM9W5TiEqVwgFczpKlZSPVw4PsUGQZlYXAowg=; b=ciDr26RpBFtacrhnAjjODl16kQxcnKHa7x0WkT5wxtKlFh+662XeHoAa0h+mpk6z /eTJAerALhoowAV3Y64118xoUpvBttW/hDlQwcbNJJ/M3m3B+jYtK7FGqOsI/huQ uWPC0wTwdneCrShzLTqH8pBieoLKDeYety0WUV3eNKs=; X-AuditID: c1b4fb2d-d9dff7000000062f-e4-5c8a70a2078c Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.17.01583.2A07A8C5; Thu, 14 Mar 2019 16:17:54 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Mar 2019 16:17:54 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 14 Mar 2019 16:17:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VHIk1quM9W5TiEqVwgFczpKlZSPVw4PsUGQZlYXAowg=; b=KcuVtkI1lZlaLWj7IpvfckWNgxAAUcSlMCSflQLKhtzs9SSDIX5GT5G2wM3BVxgV06RSTr/DYL1QYuAx+y5Fv0PyKfadRxRcpl83xh3S5bD7NHcfSqVrfi6kk6IZch0ptZWRnAMqzaTaFySC2YtME7FOJz1h9plSheU9w90vdJQ= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB4449.eurprd07.prod.outlook.com (52.135.149.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Thu, 14 Mar 2019 15:17:50 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::a9da:dfdf:2aab:8d5e]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::a9da:dfdf:2aab:8d5e%4]) with mapi id 15.20.1686.021; Thu, 14 Mar 2019 15:17:50 +0000 From: =?Windows-1252?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2nkWhsWz4a2SB0O3/IV6GxqqIA== Date: Thu, 14 Mar 2019 15:17:50 +0000 Message-ID: <7c645f38-0be4-ec2c-c706-233c8e5d47fd@ericsson.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 x-clientproxiedby: HE1P18901CA0002.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::12) To AM0PR07MB3841.eurprd07.prod.outlook.com (2603:10a6:208:45::16) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 263e7fc4-da1c-49df-e3f7-08d6a89038e3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM0PR07MB4449; x-ms-traffictypediagnostic: AM0PR07MB4449: x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(199004)(189003)(54896002)(186003)(110136005)(11346002)(8676002)(966005)(81156014)(31686004)(606006)(65826007)(81166006)(476003)(25786009)(99936001)(36756003)(2616005)(7736002)(14454004)(8936002)(105586002)(106356001)(498600001)(486006)(446003)(6486002)(65806001)(66066001)(65956001)(2906002)(58126008)(6436002)(99286004)(6506007)(76176011)(386003)(6346003)(97736004)(102836004)(256004)(2501003)(64126003)(26005)(68736007)(5660300002)(52116002)(6246003)(229853002)(6116002)(3846002)(31696002)(53936002)(6512007)(14444005)(236005)(86362001)(6306002)(71200400001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4449; H:AM0PR07MB3841.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: W+ywpwyq21bSCXmifFeyQ97rofK8BgIoZ9+B+zaYX2ZQZQoBSGAve4fa+QXzJ4oUqPCzXhQXq5630LwMyqd47hO6Wd6MizUSfz1FG5LrCd8J8fPm8WzLMmaAUEUm9lJwUt7VHeQOOH5k6B5Vew3k1wYO66n2eV8h4vgxj4HvUTdWuUzpx6Axb7rn8bQ6Kj9Lfqo3zzRlluL2FPsS2lO/vfJ1UzifIMaAeLq/nKMdAcq+ug/bzyzKZrrTkueoAIN+Rdyrfi8ULYLg1xoQLuHoBbIdmabNJejpE10PAgybIpT/qoja6Q8HGRjNBca4E9X7tQbnJVXC1ep00PhQkEsGBfOU53xNyXqi6rrqRVGKL2lx58jPgvMhwJEOLikA6bPDmp7sxoRmRZ2a6hcij8026vwnbQ8qi3pa0ISL8bvzPwE= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080109040402010208000808" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 263e7fc4-da1c-49df-e3f7-08d6a89038e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 15:17:50.4851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4449 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0hTcRTH/d3dXedqcZ0uD6ugRlFpmuYDqSgjMEnsRZDkq6E3HepcuyZq /yj0cmqYWfhK3ZhmmqUSZiGVj4HT1BxK06ycE/JBRaZpqdW234Kg/z7nnA+H84XD4wiNXDFP Jk9llHJpkoTikyXhT1hPjUIV6d23tDPw8+RvFFg5mM0NIkK02h9EiLlb5XiCOMvfH8ckydIY 5e4D5/gJqzPDhGIuOP2LbhhloctBKuTEA9oPNCvNhJWFdBcC8ydHFeJb+DuCpe46Li60BKjz xihrQdIFHBhvrrBPCgkYnyshcDGBoKWrCVmXUfQRuPl+kbSyKx0Kz+avO1rZhT4I3zoHOSrE s/SD4G6nXfGCofl5ysokvQ36G8psusCiG6fUCN8XDbXVS1wrO9ExoFuesvURvR4Wex7YMnBo NxidrCRwNlcwDfZSmEUwbf7FxSyB4plRG4voKNBPvbKFAfoOguniVbu0C/reTCLMm8BQmYus NwMdBvnvUrBvRtBbXk7hvjvcVsuxngg3jEP2NRsh21TBwX4WBQuNcxQOw8C9hiuoAHmW/nM3 5hwEI/rDpbb8zqAvmSRx3xM0LbWO//seUKOe5WDeB8U/2ynMW6Ao12T3/WFW9xVh9oWah6tU FeLXIRHLsGxy/B5fL0Ypi2XZFLmXnEltRpYfa3+87NmK6mcPdSCahyRrBYtRqkghV5rGZiR3 oK2WPRON9a+RmJSnyBmJq6DtpGUsiJNmZDLKlBjlxSSG7UAbeKTETbAidI4U0vHSVCaRYRSM 8u+U4DmJs9DxkbIeeMlQx3Jk5u0F4c+vXXU4r6jyGVINGGRrzrgRmanqABf9tEO3qa0zfHbs Uo5HyK04fmF0wLpqo7zfLdZF8SIuwWAY0AUHhOZXaaMMTeli0uj+tLhrh3uSZuG0INA7Iu+R aHOaobn1rXivOLLoPrrg533U/6N++FRYxAcJySZIfdw5Slb6B6vWDCZrAwAA Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 15:18:12 -0000 --------------ms080109040402010208000808 Content-Type: text/html; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

I support the draft. (Contributor)

regards Balazs

On 2019. 03. 13. 21:22, Kent Watsen wrote:
Seeing as how we all need to read this draft anyways, in preparation for our meeting in Prague, it seems like a good time for this poll. =A0Thusly, this email begins a 1-week adoption poll for:

=A0 =A0 https://tools.ietf.org/ht= ml/draft-verdt-netmod-yang-versioning-reqs-02

Please voice your support or objections before March 20.

Note that this draft defines *requirements* and its intended status is "Informational." =A0 I believe that it i= s good for WGs to formalize requirements, even taking such drafts thru Last Call, in order to ensure consensus on the requirements. =A0This is the "adoption" call, to ascertain if the WG agrees with that statement; if adopted, a separate "last call" will be issued to ensure to correctness of the draft's content.

Kent (and Lou and Joel)



____________________________=
___________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms080109040402010208000808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMxNDE1MTc0N1ow LwYJKoZIhvcNAQkEMSIEIPyw7WlmxF+Lb9wezCrHYmQgBANS1+Z7xNtfjbaIg5kKMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAMr28kSivHHBHMx2DljtHa9hM+MCwlh6RxnXhIndDx4oVgO/ 16W5gYymsGDb782ceTAquscjwOIQAeJekMgmkD6Yn0HgLO384Emj8bdQYnJY/7ucVOK6QZ9Z lZftiq1l5vfAv4P6SVfc+zMYzzpdrj8+1p4fy63b0Bn8Jw7kFB11QGTrKj1ygGW3955nmzxG Abg9hZM+YC8KL7ovL1T66cidTqPYpJrj51WYoNcJBTYkzoJ5uRqQxIV5w2tLIEGftmX1FjB7 KFeguoLBc5TYEUfAZojMzr/V2+M7jJt2IPrdBxFN35kDVWp2z5u7jFQCYzzzplYDWB6S4SSJ Dhg0+pIAAAAAAAA= --------------ms080109040402010208000808-- From nobody Thu Mar 14 08:55:24 2019 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 33004130E79 for ; Thu, 14 Mar 2019 08:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dnGmcv8+; dkim=pass (1024-bit key) header.d=ericsson.com header.b=M5XWiA7C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTMFhmg6e-rt for ; Thu, 14 Mar 2019 08:16:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5331512F18C for ; Thu, 14 Mar 2019 08:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552576568; x=1555168568; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iZgN+zGgZLb3dxyfynxVzsv5fspa26KykQEiPS378SM=; b=dnGmcv8+ax1pf1xUQUQfo3+ovJiVyswz4DfJizkRDChGxQIShEqAUAHw6IOdLxx9 4ra4nktx8MBIxG9tPH38do25bcCVFAaLXoUliKk7poO13njbv4lDYb91h3kDA07J 8CGjSepjPmVFT2COUsVlmonC1yWY08RXqIP4ELSRquo=; X-AuditID: c1b4fb30-fabff7000000355c-7b-5c8a70374cd4 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.E2.13660.7307A8C5; Thu, 14 Mar 2019 16:16:07 +0100 (CET) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Mar 2019 16:16:07 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Mar 2019 16:16:07 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 14 Mar 2019 16:16:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iZgN+zGgZLb3dxyfynxVzsv5fspa26KykQEiPS378SM=; b=M5XWiA7CJzdYRV9x+AIWJaAfyIBymBmlO0j4DGckChL6TI8sdLi9dyOgNb70WlLa3eYxrUaDPvLM5+wcs020eb9CI1iFC9DbmeaUbzEcQ/T/tt/z8JuI3IrevmW/CmAhQFQ3IA2VF4j0KiwL47jm4kcczUpqg163e64iAj8aAm8= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB3923.eurprd07.prod.outlook.com (52.134.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 14 Mar 2019 15:16:05 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::a9da:dfdf:2aab:8d5e]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::a9da:dfdf:2aab:8d5e%4]) with mapi id 15.20.1686.021; Thu, 14 Mar 2019 15:16:05 +0000 From: =?Windows-1252?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , Joe Clarke , Benoit Claise , Ebben Aries , "Jason Sterne" , Juergen Schoenwaelder , Mahesh Jethanandani , "Michael (Wangzitao)" , "Qin Wu" , "Reshad Rahman (rrahman)" , "Rob Wilton" CC: "netmod@ietf.org" Thread-Topic: IPR poll on yang-versioning-reqs-02 Thread-Index: AQHU2njY7LMmJyRRNUGMEt9JOqRF1Q== Date: Thu, 14 Mar 2019 15:16:05 +0000 Message-ID: References: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> In-Reply-To: <0100016978bf4dca-d79bb929-31d1-4ed5-bdcc-b536d5aecdf0-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 x-clientproxiedby: HE1PR1001CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::16) To AM0PR07MB3841.eurprd07.prod.outlook.com (2603:10a6:208:45::16) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 133a95f0-1247-4f89-0253-08d6a88ffa83 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM0PR07MB3923; x-ms-traffictypediagnostic: AM0PR07MB3923: x-microsoft-antispam-prvs: x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(366004)(396003)(346002)(189003)(199004)(105586002)(11346002)(316002)(25786009)(446003)(36756003)(2616005)(5660300002)(7416002)(97736004)(31686004)(229853002)(31696002)(6246003)(1941001)(58126008)(6436002)(65806001)(186003)(65956001)(66066001)(68736007)(86362001)(71190400001)(71200400001)(110136005)(7736002)(102836004)(6512007)(14454004)(53936002)(64126003)(2906002)(6306002)(6346003)(8676002)(106356001)(81156014)(305945005)(76176011)(8936002)(99286004)(478600001)(99936001)(52116002)(6486002)(65826007)(486006)(476003)(256004)(14444005)(386003)(4326008)(6506007)(3846002)(6116002)(966005)(26005)(81166006)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3923; H:AM0PR07MB3841.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Y6DblTUEF8FZCBdqAP6MJi7oMcwPWScfIjw2MguxpWJd6jtEHBi58et8og/omIAXhR46hW8fTIDPXncbNOIGAAd9YQvAr3Qgo1ygoc+vxi0DLVKmh18uAwdOW1OGvY1u3T3aMfRPmxgyaeAsql1ZwuKbNd7dOVyr8W2YeVPdPvI5PYiKKTQHTovhni/r1kLiPCAPkjvBtazPnB1rYesNMJn4Rq1B6glN51NKAcY7OKj9KOODCy1mYjNT1ljsMghNmAFkKHvGAAYVyGfi/uuNQzR4lrQekFgSSmjlGxQsofgnk5hx322BLpOyfPSCde24Fy69bCLDzHnZHIzzoyOcGnK2X/F+C4lgksYN6NMypeb3SGr2rUR+FoKJSjFUj7D4jLLgtLZxWZdZijrR23ZbmeilqaHkDkV2ZFIqU3nqTic= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080805010200060901040408" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 133a95f0-1247-4f89-0253-08d6a88ffa83 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2019 15:16:05.8745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3923 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHec85OzuOBm9L88GKaiiBlqkVHbKLReQpMgr80MWyNQ8m2mbb spI+qF2ozWKJoQ6ahReslWym2bqILi01iwrMGmqsDXKald3EtMu2s6K+/f7P/3me//PCy5Ay Cx3BZKl0vEalyJHTEqpie3P+ouW5+rQ4x/AKtsMNrPviJRHrtTRRbK9tArEN5nsk29I7hdj3 nl+IffSunmYrnxWK2Bd1J8Vs55NzJFs0UkQlTeNKJ20izm4aEHMn2kdFXHX1BMFZWzdyfUW9 Ym7A+Zzg3J168VZmp2RlBp+TlcdrFq/eK9lvv22kc01JR6w946gAFSfqUQgDeCnU1ZxCeiRh ZLgdQX1tOSmIbwgsrk/0XzFlcARFNQF3rxjFfkFhIwlPLldRgnOegBtjQ8EFbxC8M90k/DE0 Tobzg+OBrlDcScK9oTLSb5B4AfR3u2k/z8Bx0F5ylvJzKI6HL98KaIFj4YK9O1CncBQYh50B luI1UFP82nc740vbA5bBY/5yCE4Hl/l6YD3CM2G8+xohRIWD01NJCM8OBdezR7TAYeB1/xQJ LIfyYWeAw/Bu6BrqEflvBlyGoPh2AyU0LYTHfR4k8Bx4XmkIcgp8mPhECgNuBA+fTooFIxoe 2hqCydlg6jME67Oh0GUmjWix6Z8DTb55Ep9BMPxAT5gCD50OXRUeSmhaBf0X75ACx0Dt5RHy /2E/J0L59zZa4PlQanCJBV4GIx1jSOAlUFv/g76EJFdRmJbX7juQmZAQy2uylFqtWhWr4nUN yPdt2xon424h79u1DoQZJJ8mbU3Tp8lEijzt0QMOFOnb88ZqeYoiKJVaxctDpXe3+WxphuJo Pq9Rp2sO5fBaB5rFUPJw6ZRsepoMZyp0fDbP5/KaPy7BhEQUoMQxq7qv/db6yJRW3YKz35tt hem7ouzHP8yzN++0Zs55laAkzhRuvtlRcnC0pS7k61RmYs1LSapZGZVD7J6HwiLKGptiOuCw IZvbUmQ7kvRjW6pTeW7DjtddyWrl6GSVx5uR681fUTV33fGWvM+9908v66/YlNL2sSdGrjOL PevMckq7XxEfTWq0it8flRNTvgMAAA== Archived-At: X-Mailman-Approved-At: Thu, 14 Mar 2019 08:55:24 -0700 Subject: Re: [netmod] IPR poll on yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 15:16:13 -0000 --------------ms080805010200060901040408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US No, I'm not aware of any IPR that applies to this draft Balazs On 2019. 03. 13. 21:29, Kent Watsen wrote: > To each author and contributor listed on the "To" line. > > In order to complete the Adoption poll, are you aware of any IPR that=20 > applies > to yang-versioning-reqs-02? =A0Please Reply-All to *this* email and=20 > state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If "yes", has this IPR been disclosed in compliance with IETF IPR rules= > (see RFCs 3669, 5378 and 8179 for more details)? > > If "yes" again, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think=20 > appropriate. > > If you are listed as a document author or contributor please answer=20 > the above by > responding to this email regardless of whether or not you are aware of = > any relevant > IPR. =A0This document will not advance to the next stage until a=20 > response has been > received from each author and listed contributor. =A0NOTE: THIS APPLIES= =20 > TO ALL > OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not=20 > listed as an author > or contributor, we remind you of your obligations under the IETF IPR=20 > rules which > encourages you to notify the IETF if you are aware of IPR of others on = > an IETF > contribution, or to refrain from participating in any contribution or=20 > discussion related > to your undisclosed IPR. For more information, please see the RFCs=20 > listed above > and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPropert= y. > > Thank you, > Kent // as co-Chair > --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms080805010200060901040408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMxNDE1MTU1OVow LwYJKoZIhvcNAQkEMSIEII2qZVfm9wnTF+j+ZyyJEx3xKR7Z20DMcseW2WHIPl3tMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAAscXgVmjQgwbphNWUNG38k1dfQr5rk9OHp6cP2tSDrbbiVQ ow83QlOa3hthD21ZWNoACYZGS4p3OWHZWRoV+PKgqOQ1dY+Zhk3O/WgoRS6ep6H5/SKTToJm zZ31zPe0mQj/Am9gnNsh4ZAM5QLRMOAnmH5fDiHpuahqzsuwkckQol35b3ij/wA38Y9eFD1u geWqlqDrMOII9eWeIIEb9CpRnjP/GWtGUE93zv5mLuP4D6XjW+3UqVpUMdX49ZrvWFQPdXUO q9AD8Pn6PQwcqxS81mnWEOrewORmSq+yN8TMp+i5zzak3dG9hMARNImvZExsl5WtgyWaVlek 58gcPUwAAAAAAAA= --------------ms080805010200060901040408-- From nobody Thu Mar 14 09:57:34 2019 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 F07DB130EA2 for ; Thu, 14 Mar 2019 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 IJIrmMtai7uB for ; Thu, 14 Mar 2019 09:57:30 -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 E7360130E16 for ; Thu, 14 Mar 2019 09:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=463; q=dns/txt; s=iport; t=1552582649; x=1553792249; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=hcIfkKnmZVpeUiCOw8B+wBJpJB7otXj2662roxU1Z3o=; b=GGnS5bDQPsZJEZ9pSrJEgqFhIJgzQ8FmYN+joxty1tnfsZbqjQqFRcX5 s2vMsP5PdVTQgezYvNCmaebB13RqeKjmNTIGPDAbD1oGaL9ZzkeFA7f1n wGOvbIjfVl2uSxE7O8btRA9df/U9ErAe+BDHiBMHl8utRSadDZXxG1BHs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAACihopc/49dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIQaANNM5dvgWAtmESBZw0jhD8KAoRQIjgSAQEDAQE?= =?us-ascii?q?JAQMCbRwMhUsBBTIBVgsYLlcGAQwIAQGDHgGBdQ+vJ4Q0AoV9BYEvAYssF4F?= =?us-ascii?q?AP4E4gmuDHgEBA4ErARIBhgADpEAJh1iLQQYZgWsBD4VrgyQmiByKf4VzjR2?= =?us-ascii?q?BXiFlcU0jFYMoiwuFWyMDjhCCPgEB?= X-IronPort-AV: E=Sophos;i="5.58,478,1544486400"; d="scan'208";a="535405236" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 16:57:28 +0000 Received: from [192.168.10.214] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTP id x2EGvSwx016178; Thu, 14 Mar 2019 16:57:28 GMT To: Kent Watsen , netmod@ietf.org References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA== Organization: Cisco Message-ID: <8ed720b9-3d15-5e20-91d7-97653e57fd73@cisco.com> Date: Thu, 14 Mar 2019 12:57:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 16:57:32 -0000 On 3/13/19 16:22, Kent Watsen wrote: > Seeing as how we all need to read this draft anyways, in preparation for > our meeting in Prague, it seems like a good time for this poll.  Thusly, > this email begins a 1-week adoption poll for: > >     https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 > > Please voice your support or objections before March 20. As a contributor to the document, I support adoption of this draft. Joe From nobody Thu Mar 14 10:19:11 2019 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 3D855130E70 for ; Thu, 14 Mar 2019 10:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 I6Bs-Xyzlifd for ; Thu, 14 Mar 2019 10:19:07 -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 2AB1D130EA9 for ; Thu, 14 Mar 2019 10:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6606; q=dns/txt; s=iport; t=1552583947; x=1553793547; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TVtZ82/7iKPYWEB3bl3iZOdKREX4zr+9ecN8Zc29WuQ=; b=I1PWAjVOfR7N5SR85wcG2UnXoMWA7v/A73JzIK3BntGiWj8hJVz99ZWD KGnX32a49zQ4VfnEbFsZKpDO/U5ADaclIHTkQ8m2AA0X79TRPLCyXtlTI rXAI7I5zQhvFbPt73Ar8c0SpYyxm8iLvYv97kDZoxLajwqs/jt3v2uxx3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAHjIpc/5FdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ2BAmiBAycKjB2LIYINkjqFdhSBZws?= =?us-ascii?q?BASOESQKEUCI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQtXAIBCBEEAQEvMh0IAgQ?= =?us-ascii?q?BEgiDG4ERZA+vFIQ0AoV9BYEvAYssF4FAP4Qjgx4BAQOBKwESAYYAA5Bek2I?= =?us-ascii?q?JAodWg3+HQCGBe4Vrg0qIHIp/hXOMdQIRFYEoHzhlcXAVgyeLDIU/QTGNYIE?= =?us-ascii?q?fgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,478,1544486400"; d="scan'208,217";a="535532822" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 17:19:06 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2EHJ5rS017675 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Mar 2019 17:19:06 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Mar 2019 12:19:05 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 14 Mar 2019 12:19:05 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYLX92A Date: Thu, 14 Mar 2019 17:19:05 +0000 Message-ID: <88b72028c44a4cc8b84b7909f3379e3a@XCH-RCD-007.cisco.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> 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.63.23.135] Content-Type: multipart/alternative; boundary="_000_88b72028c44a4cc8b84b7909f3379e3aXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 17:19:09 -0000 --_000_88b72028c44a4cc8b84b7909f3379e3aXCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a contributor, I support WG adoption of this draft. Thanks, Rob From: netmod On Behalf Of Kent Watsen Sent: 13 March 2019 20:22 To: netmod@ietf.org Subject: [netmod] adoption poll for yang-versioning-reqs-02 Seeing as how we all need to read this draft anyways, in preparation for ou= r meeting in Prague, it seems like a good time for this poll. Thusly, this= email begins a 1-week adoption poll for: https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 Please voice your support or objections before March 20. Note that this draft defines *requirements* and its intended status is "Inf= ormational." I believe that it is good for WGs to formalize requirements,= even taking such drafts thru Last Call, in order to ensure consensus on th= e requirements. This is the "adoption" call, to ascertain if the WG agrees= with that statement; if adopted, a separate "last call" will be issued to = ensure to correctness of the draft's content. Kent (and Lou and Joel) --_000_88b72028c44a4cc8b84b7909f3379e3aXCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a contributor, I support WG adoption of this draft.

Thanks,
Rob

 = ;

 = ;

From= : netmod <netmod-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 13 March 2019 20:22
To: netmod@ietf.org
Subject: [netmod] adoption poll for yang-versioning-reqs-02

 

Seeing as how we all ne= ed to read this draft anyways, in preparation for our meeting in Prague, it= seems like a good time for this poll.  Thusly, this email begins a 1-= week adoption poll for:

 

 

Please voice your suppo= rt or objections before March 20.

 

Note that this draft de= fines *requirements* and its intended status is "Informational." =   I believe that it is good for WGs to formalize requirements, even ta= king such drafts thru Last Call, in order to ensure consensus on the requirements.  This is the "adoption" call= , to ascertain if the WG agrees with that statement; if adopted, a separate= "last call" will be issued to ensure to correctness of the draft= 's content.

 

Kent (and Lou and Joel)=

 

 

--_000_88b72028c44a4cc8b84b7909f3379e3aXCHRCD007ciscocom_-- From nobody Fri Mar 15 07:16:18 2019 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 C25AE130DC4; Fri, 15 Mar 2019 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 JKINgOpyIGcE; Fri, 15 Mar 2019 07:16:13 -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 BECF2130DE3; Fri, 15 Mar 2019 07:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2180; q=dns/txt; s=iport; t=1552659372; x=1553868972; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=e1PwcPItKElYinBpBikXehtvfqCevDc50Qzu+X5Xe2k=; b=Q5LidB4DuDk0Y3w5UvJxoQXqPVHw0wMfQMqM6TsJFIfulmwTauwhQ89U NIgCXX0XJQSgRht7Nlf/NLuccUXJjNEOiNGX0EXD2osPuhXGVUHz/WIK6 8FPmwBjfOaCoDJQKXVjLSTtLVlBxnK0lGcACeZO/lNZWUzkYaFqwJGGUN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB/sotc/4ENJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgg9ogQMnCowdjS6YMYF7CwEBGA2EAUY?= =?us-ascii?q?ChFAiNAkNAQEDAQEJAQMCbRwMhUoBAQEEAQE4NBcEAgEIEQQBAR8QJwsdCAI?= =?us-ascii?q?EARIIgxuBdQ+tHIQ0Ag5BhTGBLwGLMheBQD+EI4MeAQECAQEWhygDijKaGAk?= =?us-ascii?q?Ch1mLQCGBe1uFEotoiwWFdY0AAhEVgSgfOIFWcBUaIYJsCYINF4hfhT9BMY1?= =?us-ascii?q?fgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,482,1544486400"; d="scan'208";a="532601717" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 14:16:11 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2FEGBde024035 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Mar 2019 14:16:11 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Mar 2019 09:16:10 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 15 Mar 2019 09:16:10 -0500 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" , "draft-ietf-netmod-yang-data-ext@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-02.txt Thread-Index: AQHU1X5Mvw0yNWuVtE+FzljNoIudc6YMeqRw Date: Fri, 15 Mar 2019 14:16:10 +0000 Message-ID: <0a47394551e445c6a5cf37eac17f3a66@XCH-RCD-007.cisco.com> References: <155202908349.5373.15205929918149184901@ietfa.amsl.com> In-Reply-To: <155202908349.5373.15205929918149184901@ietfa.amsl.com> 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.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 14:16:16 -0000 Hi,=20 Two minor questions on this draft. (1) In the definition of the structure and augment-structure extensions, sh= ould the draft explicitly state what the canonical statement ordering is? = Although TBH, the ordering is pretty intuitive. (2) Probably beyond the scope of this draft, but does there need to be any = thought about how SIDs (draft-ietf-core-sid-05) are allocated to YANG data = extensions? Thanks, Rob -----Original Message----- From: netmod On Behalf Of internet-drafts@ietf.or= g Sent: 08 March 2019 07:11 To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Data Structure Extensions Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netmod-yang-data-ext-02.txt Pages : 14 Date : 2019-03-07 Abstract: This document describes YANG mechanisms for defining abstract data structures with YANG. It is intended to replace and extend the "yang-data" extension statement defined in RFC 8040. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-02 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-data-ext-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-data-ext-02 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/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Mar 17 14:23:30 2019 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 DD33B126E5C for ; Sun, 17 Mar 2019 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=AysuB3IQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BgzP9+jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-E7OhXNN2kH for ; Sun, 17 Mar 2019 14:23:26 -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 959111277D7 for ; Sun, 17 Mar 2019 14:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7567; q=dns/txt; s=iport; t=1552857806; x=1554067406; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3gU5Ps1FWukUB/Qiy94pOTizboBtPvCnYrN+I04mGWM=; b=AysuB3IQWmDlLsbJN/addIoBFlulmqRK246kC2u233MfmPpmQQwRYQE/ uhiYndnKRRtTF/HMNw8JUvYtBINxUyPVlRcDXPnhLcCn4KTVjLA8BxSIs BdWXUqJ3JSTAAb7XQFsswYuKGdMe/F3LsPBVnsdmM2EvIhCGE9zceyop2 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AGXgupRD5H4omhffM/jDeUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuTjbykzGuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAABfuY5c/5RdJa1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEOL1ADaHQECycKhAGDRwOEUopXSoFoJZI7hEiBLhS?= =?us-ascii?q?BEANUCwEBIwmEQAIXhDkiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIx0BATgPAgE?= =?us-ascii?q?IEQMBAisCAgIwHQgCBAESgyIBgRFMAxUBAgyeSgKKFHGBL4J4AQEFgTUCgRC?= =?us-ascii?q?CMxiCDAMFgS8Biy8XgUA/gTgME4JMgx4BAQOBKwESAT8Ngl0xgiaMW4QPhzq?= =?us-ascii?q?MNAkCh1mEAodIGYF8hW+DS4ghiweFeI0DAgQCBAUCDgEBBYFHOGVxcBVlAYJ?= =?us-ascii?q?BggqDboUUhT9ygSiLSoEfAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.58,491,1544486400"; d="scan'208,217";a="245607534" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2019 21:23:25 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2HLNPTq017252 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 17 Mar 2019 21:23:25 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Mar 2019 16:23:25 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Mar 2019 16:23:24 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 17 Mar 2019 17:23:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3gU5Ps1FWukUB/Qiy94pOTizboBtPvCnYrN+I04mGWM=; b=BgzP9+jp0T+UtbHHXsHQ06u84ufI5jtmaJs9Zonvn1cR+pECG+GAABdUMsW6T2yjzJQedkoZO/tE2vuzZXOq4HdeTIDeqNZxwW5WClLCtgRkYyZ0zWCnT6TcGqpSmZ7ImaF5X3Zd3gvesD8hSp5bT4tIDRtsxTRSzSzv9+HBVzc= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3581.namprd11.prod.outlook.com (20.178.251.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Sun, 17 Mar 2019 21:23:23 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1709.015; Sun, 17 Mar 2019 21:23:23 +0000 From: "Reshad Rahman (rrahman)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp7YypUbX6X+USrpPO25GlQu6YQGIeA Date: Sun, 17 Mar 2019 21:23:22 +0000 Message-ID: References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.93] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f62ff508-2aa0-4c01-05bf-08d6ab1ec919 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3581; x-ms-traffictypediagnostic: MN2PR11MB3581: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(346002)(396003)(366004)(199004)(189003)(33656002)(81156014)(81166006)(8676002)(105586002)(478600001)(36756003)(7736002)(106356001)(25786009)(82746002)(476003)(68736007)(606006)(8936002)(2501003)(58126008)(110136005)(316002)(446003)(97736004)(14454004)(2616005)(11346002)(99286004)(486006)(2906002)(966005)(6506007)(5660300002)(102836004)(53546011)(26005)(76176011)(6116002)(3846002)(6246003)(53936002)(229853002)(236005)(71190400001)(71200400001)(6436002)(6486002)(6512007)(6306002)(54896002)(186003)(14444005)(256004)(66066001)(83716004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3581; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TxoEXT5qpGalA4ISL804QS4PCnPH1Ylgxd7CVpFlr0u1bPCPcqmLF/svyHgqv7O/hCe557WNovDW+0sFAwouzSb7T+dhz69Or/2wMX9t+dkeAY30OJScgQ8F02C5JZHaiAWaNeHhGDqVDRfQZLoz5vKRoB028Yl3sQlaEoGA34W7yCgku06bhJg4cAZkS/337j5T19oT0TXU0x1SfMFe+tqotdcoXnGTJl+D2oN3+1m81JLoUBIwyuMnLIMZj2vltal4F0sdtcPr/VWsj+7wUcZIAy51G9rEmywQNqd5Yqm8kkPsPo0CdjQfystjTCPNFC4lz04SWT1du1DtXQH/WiROQq6rwvdsQw7YnIhZarlaKrTn0Z1SQWYj2wBNK9zgliVcntjpaOEo150S+txKtKTMY0jPakCsHMu82jtB0FM= Content-Type: multipart/alternative; boundary="_000_C22DBA1F6683403581EE6C8754FA9193ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f62ff508-2aa0-4c01-05bf-08d6ab1ec919 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2019 21:23:22.8991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3581 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 21:23:29 -0000 --_000_C22DBA1F6683403581EE6C8754FA9193ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgY29udHJpYnV0b3IsIEkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGJ5IHRo ZSBXRy4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5l dD4NCkRhdGU6IFdlZG5lc2RheSwgTWFyY2ggMTMsIDIwMTkgYXQgNDoyMiBQTQ0KVG86ICJuZXRt b2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbmV0bW9kXSBhZG9wdGlv biBwb2xsIGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQpTZWVpbmcgYXMgaG93IHdlIGFs bCBuZWVkIHRvIHJlYWQgdGhpcyBkcmFmdCBhbnl3YXlzLCBpbiBwcmVwYXJhdGlvbiBmb3Igb3Vy IG1lZXRpbmcgaW4gUHJhZ3VlLCBpdCBzZWVtcyBsaWtlIGEgZ29vZCB0aW1lIGZvciB0aGlzIHBv bGwuICBUaHVzbHksIHRoaXMgZW1haWwgYmVnaW5zIGEgMS13ZWVrIGFkb3B0aW9uIHBvbGwgZm9y Og0KDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15 YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQpQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9i amVjdGlvbnMgYmVmb3JlIE1hcmNoIDIwLg0KDQpOb3RlIHRoYXQgdGhpcyBkcmFmdCBkZWZpbmVz ICpyZXF1aXJlbWVudHMqIGFuZCBpdHMgaW50ZW5kZWQgc3RhdHVzIGlzICJJbmZvcm1hdGlvbmFs LiIgICBJIGJlbGlldmUgdGhhdCBpdCBpcyBnb29kIGZvciBXR3MgdG8gZm9ybWFsaXplIHJlcXVp cmVtZW50cywgZXZlbiB0YWtpbmcgc3VjaCBkcmFmdHMgdGhydSBMYXN0IENhbGwsIGluIG9yZGVy IHRvIGVuc3VyZSBjb25zZW5zdXMgb24gdGhlIHJlcXVpcmVtZW50cy4gIFRoaXMgaXMgdGhlICJh ZG9wdGlvbiIgY2FsbCwgdG8gYXNjZXJ0YWluIGlmIHRoZSBXRyBhZ3JlZXMgd2l0aCB0aGF0IHN0 YXRlbWVudDsgaWYgYWRvcHRlZCwgYSBzZXBhcmF0ZSAibGFzdCBjYWxsIiB3aWxsIGJlIGlzc3Vl ZCB0byBlbnN1cmUgdG8gY29ycmVjdG5lc3Mgb2YgdGhlIGRyYWZ0J3MgY29udGVudC4NCg0KS2Vu dCAoYW5kIExvdSBhbmQgSm9lbCkNCg0KDQo= --_000_C22DBA1F6683403581EE6C8754FA9193ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9C3AB9FC8B53D947965104C95034C15D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGNvbnRyaWJ1dG9yLCBJIHN1cHBvcnQgYWRvcHRpb24gb2Yg dGhpcyBkb2N1bWVudCBieSB0aGUgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGll dGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0 c2VuLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXJjaCAxMywgMjAxOSBh dCA0OjIyIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0 O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W25ldG1vZF0gYWRvcHRp b24gcG9sbCBmb3IgeWFuZy12ZXJzaW9uaW5nLXJlcXMtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlaW5nIGFzIGhvdyB3ZSBhbGwgbmVl ZCB0byByZWFkIHRoaXMgZHJhZnQgYW55d2F5cywgaW4gcHJlcGFyYXRpb24gZm9yIG91ciBtZWV0 aW5nIGluIFByYWd1ZSwgaXQgc2VlbXMgbGlrZSBhIGdvb2QgdGltZSBmb3IgdGhpcyBwb2xsLiAm bmJzcDtUaHVzbHksIHRoaXMgZW1haWwgYmVnaW5zIGEgMS13ZWVrIGFkb3B0aW9uIHBvbGwgZm9y Og0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmluZy1yZXFzLTAyIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy12ZXJzaW9uaW5nLXJlcXMtMDI8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBs ZWFzZSB2b2ljZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgTWFyY2ggMjAuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUg dGhhdCB0aGlzIGRyYWZ0IGRlZmluZXMgKnJlcXVpcmVtZW50cyogYW5kIGl0cyBpbnRlbmRlZCBz dGF0dXMgaXMgJnF1b3Q7SW5mb3JtYXRpb25hbC4mcXVvdDsgJm5ic3A7IEkgYmVsaWV2ZSB0aGF0 IGl0IGlzIGdvb2QgZm9yIFdHcyB0byBmb3JtYWxpemUgcmVxdWlyZW1lbnRzLCBldmVuIHRha2lu ZyBzdWNoIGRyYWZ0cyB0aHJ1IExhc3QgQ2FsbCwgaW4gb3JkZXIgdG8gZW5zdXJlIGNvbnNlbnN1 cyBvbiB0aGUgcmVxdWlyZW1lbnRzLg0KICZuYnNwO1RoaXMgaXMgdGhlICZxdW90O2Fkb3B0aW9u JnF1b3Q7IGNhbGwsIHRvIGFzY2VydGFpbiBpZiB0aGUgV0cgYWdyZWVzIHdpdGggdGhhdCBzdGF0 ZW1lbnQ7IGlmIGFkb3B0ZWQsIGEgc2VwYXJhdGUgJnF1b3Q7bGFzdCBjYWxsJnF1b3Q7IHdpbGwg YmUgaXNzdWVkIHRvIGVuc3VyZSB0byBjb3JyZWN0bmVzcyBvZiB0aGUgZHJhZnQncyBjb250ZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5L ZW50IChhbmQgTG91IGFuZCBKb2VsKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C22DBA1F6683403581EE6C8754FA9193ciscocom_-- From nobody Mon Mar 18 11:15:57 2019 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 3F63C13127D for ; Mon, 18 Mar 2019 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 H5OkYkwapvYg for ; Mon, 18 Mar 2019 11:15:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE881311D2 for ; Mon, 18 Mar 2019 11:15:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0F0ABB826EA; Mon, 18 Mar 2019 11:15:42 -0700 (PDT) To: mbj@tail-f.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: exa@arrcus.com, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190318181542.0F0ABB826EA@rfc-editor.org> Date: Mon, 18 Mar 2019 11:15:42 -0700 (PDT) Archived-At: Subject: [netmod] [Technical Errata Reported] RFC7950 (5663) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 18:15:56 -0000 The following errata report has been submitted for RFC7950, "The YANG 1.1 Data Modeling Language". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5663 -------------------------------------- Type: Technical Reported by: Ebben Aries Section: 14 Original Text ------------- deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt] *must-stmt *unique-stmt *default-stmt "}") stmtsep Corrected Text -------------- deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt] *must-stmt *unique-stmt *default-stmt [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt] "}") stmtsep Notes ----- Section 7.20.3.2 specifies all permitted substatements for the "deviate" statement however the ABNF grammar specifies different valid substatements per deviate argument. The "delete" argument is one such that only contains a subset of what is defined in the substatement table in this section. The errata mentioned at: https://www.rfc-editor.org/errata/eid5489 is meant to correct the following statement """ The argument "delete" deletes properties from the target node. The properties to delete are identified by substatements to the "delete" statement. """ However this either needs to be a per argument table or ABNF correction Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7950 (draft-ietf-netmod-rfc6020bis-14) -------------------------------------- Title : The YANG 1.1 Data Modeling Language Publication Date : August 2016 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Mar 18 15:15:10 2019 Return-Path: <0100016992df4bae-aba0289a-d720-4721-9f70-de37141a983d-000000@amazonses.watsen.net> 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 75848124B91; Mon, 18 Mar 2019 15:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 38ieji8M2Oke; Mon, 18 Mar 2019 15:15:02 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F8F129A85; Mon, 18 Mar 2019 15:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552947301; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=WObu7FuKfv1KfTL79Jadf5ZAxRnlYdkSuKq1QOLQbQg=; b=LTgy0W9OeHhlQCg8i2OFYuLgMLZFWE7ou+AK75ZvFQtlX5HjXLSr2kS7nTJxY/Yg gxZPK1A5tdNoFKuSJM/oA/tRVoPvfUyMTCJJfczXUjVHHBndzP+lv8nRC93wD/f0PjD /lCvAYn5AgYdH59vCBvcFJjRXRW1tRmfDjVzWshE= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016992df4bae-aba0289a-d720-4721-9f70-de37141a983d-000000@email.amazonses.com> Date: Mon, 18 Mar 2019 22:15:01 +0000 Cc: netmod-chairs@ietf.org To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.18-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] 104 Presenters: please send your slides X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 22:15:09 -0000 Dear NETCONF 104 Presenters, Please send your slides to the chairs alias (CC-ed) by this Friday. Thanks you! Kent and Mahesh From nobody Mon Mar 18 15:28:07 2019 Return-Path: <0100016992eb39d4-c5feb968-87df-45fb-b3da-abc74ae7f233-000000@amazonses.watsen.net> 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 E844E124B91; Mon, 18 Mar 2019 15:28:05 -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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 L6_7Ak5XPeQn; Mon, 18 Mar 2019 15:28:04 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68DC12008F; Mon, 18 Mar 2019 15:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1552948083; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=2oMXOU6HEznbR0oet8l2RQ+k1dwTYFMOfuHdB864K90=; b=fDZnBenRuOtKugCIeEt2qtGrbii3/HVE/zvfBSHLd3QkR8dWxBctpVIgj/4bZwkG n5F7O6isLHfOpnH0EZTOmrtCLWBSo8SzflcYptV+42+UNR6vVzF5ikZu/ZzN6rPC/CY 1NQSj0CyG93TliUa/rwfKtZyLAfKZSGakXLzpmBo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Kent Watsen In-Reply-To: <0100016992df4bae-aba0289a-d720-4721-9f70-de37141a983d-000000@email.amazonses.com> Date: Mon, 18 Mar 2019 22:28:03 +0000 Cc: netmod-chairs@ietf.org Content-Transfer-Encoding: 7bit Message-ID: <0100016992eb39d4-c5feb968-87df-45fb-b3da-abc74ae7f233-000000@email.amazonses.com> References: <0100016992df4bae-aba0289a-d720-4721-9f70-de37141a983d-000000@email.amazonses.com> To: NETMOD Working Group X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.18-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] 104 Presenters: please send your slides X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 22:28:06 -0000 [fixing copy/paste issues] Dear NETMOD 104 Presenters, Please send your slides to the chairs alias (CC-ed) by this Friday. Thanks you! Kent (and Lou and Joel) From nobody Tue Mar 19 08:12:42 2019 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 786B2131409 for ; Tue, 19 Mar 2019 08:12:33 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 LSblhhHZf2Jw for ; Tue, 19 Mar 2019 08:12: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 70CA31313F9 for ; Tue, 19 Mar 2019 08:12:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 74D301AE00A0; Tue, 19 Mar 2019 16:12:28 +0100 (CET) Date: Tue, 19 Mar 2019 16:12:29 +0100 (CET) Message-Id: <20190319.161229.1910835285804688041.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 15:12:41 -0000 Hi, I have read this document, and I do not think it should be adopted. I object to the idea that we should allow non-backwards-compatible changes to published YANG modules. The draft motivates this idea with: we must recognize that many YANG modules are actually generated YANG modules (for example, from internal databases) I do not agree that we should change what we allow in published modules b/c of this. It also motivates this idea with: The points made above lead to the logical conclusion that the standardized YANG modules have to be perfect on day one (at least the structure and meaning), which in turn might explain why IETF YANG modules take so long to standardize. I disagree with this. First of all, we have already published revision two of several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that "standardized YANG modules have to be perfect on day one" is simply not true. Second, I don't think the upgrade rules are the reason it takes a long time to standardize IETF models (I think it has to do with the process itself, including the fact that models get reviews from many different people with different background.) [BTW, is it true that drafts with YANG models take longer time from wg -00 to published RFC than other drafts?] This said, I think there are some important points that the draft raises, and that I think we should continue to work on; specifically 2.3, 2.5, 2.6, 2.7. But I don't think that these areas require changes to the versioning scheme, and I think it is a mistake to include these areas in this draft. Some comments on section 4, The Problem Statement: o Any non-backwards-compatible change of a definition requires either a new module name or a new path. This has been found costly to support in implementations, in particular on the client side. Yes I agree there is a cost associated with this. But I have come across vendor modules that make NBC changes w/o introducing a new path, and this is also costly to handle. o Since non-backwards-compatible changes require either a new module name or a new path, such changes will impact other modules that import definitions. In fact, with the current module versioning scheme other modules have to opt-in in order to use the new version. This essentially leads to a ripple effect where a non- backwards-compatible change of a core module causes updates on a potentially large number of dependent modules. This is by design. We cannot have a situation where a legal modification to a module leads to other modules becoming invalid. o YANG has a mechanism to mark definitions deprecated but it leaves it open whether implementations are expected to implement deprecated definitions and there is no way (other than trial and error) for a client to find out whether deprecated definitions are supported by a given implementation. As I wrote above, I agree that this is a problem that should be solved. But this is not a motivation for changing YANG versioning. o YANG does not have a robust mechanism to document which data definitions have changed and to provide guidance how implementations should deal with the change. While it is possible to have this described in general description statements, having these details embedded in general description statements does not make this information accessible to tools. This might also be worth exploring, but this is not a motivation for changing YANG versioning. /martin Kent Watsen wrote: > Seeing as how we all need to read this draft anyways, in preparation for our meeting in Prague, it seems like a good time for this poll. Thusly, this email begins a 1-week adoption poll for: > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 > > Please voice your support or objections before March 20. > > Note that this draft defines *requirements* and its intended status is "Informational." I believe that it is good for WGs to formalize requirements, even taking such drafts thru Last Call, in order to ensure consensus on the requirements. This is the "adoption" call, to ascertain if the WG agrees with that statement; if adopted, a separate "last call" will be issued to ensure to correctness of the draft's content. > > Kent (and Lou and Joel) > > From nobody Tue Mar 19 09:37:54 2019 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 59541131071 for ; Tue, 19 Mar 2019 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 62niy888Za-D for ; Tue, 19 Mar 2019 09:37:50 -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 B84FE1200B3 for ; Tue, 19 Mar 2019 09:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7188; q=dns/txt; s=iport; t=1553013469; x=1554223069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OhaWsuI22oxSOL28D6/mBkCdjMU9CqnttBOpUeBIdRs=; b=kNr0vrJWH2JEEPv+GyOjmSsz7ZR2s3L27qvuU4EgBDtc5ZjVsNfufycd EOrYuhFpzgE0eyHBln41R0r2SW5v/CqSus5Si0W8vyxKnyk7kLmZCCBXw 8RQGGSejnDZXMlPI6u806nGJelMNOuV6rv49fmN38vkqc8zN//7Hx3Ua9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAA9GpFc/40NJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgWEvaIEDJwqZVJgyFIFnCwEBGAuEA0Y?= =?us-ascii?q?ChGsiNQgNAQEDAQEJAQMCbRwMhUoBAQEEAQElEzQLDAQCAQgOAwQBAQEeECc?= =?us-ascii?q?LHQgCBAENBQgTgwiBdQ+rDzOENAKFdgWBLwGLMReBQD+DJX6DHgEBA4ErARI?= =?us-ascii?q?BCYV3A4ocDjMChjWSdWAJAodbhAeHQCGBfIVyg0uIJYsMhXuNCAIRFYEoIAE?= =?us-ascii?q?2KD1xcBU7gmyCFheIX4U/QTGNI4EfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208";a="247366647" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 16:37:48 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JGblQT019821 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 16:37:48 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 11:37:47 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 19 Mar 2019 11:37:47 -0500 From: "Rob Wilton (rwilton)" To: Martin Bjorklund , "kent+ietf@watsen.net" CC: "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SA= Date: Tue, 19 Mar 2019 16:37:46 +0000 Message-ID: References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> In-Reply-To: <20190319.161229.1910835285804688041.mbj@tail-f.com> 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.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 16:37:52 -0000 Hi Martin, Thanks for the review and comments. A couple of points: =20 1) Lots of models outside those published in SDOs are already not following= the RFC 7950 revision rules. I think that it is better to have a versioni= ng scheme that reflects how YANG models are actually evolving rather than h= ave all vendor and OC YANG modules either just ignoring the rules, or using= clever tricks that strictly conform with the rules but go against the spir= it of them (e.g. just publish an entirely new set of YANG modules for each = release). Also noting that having a scheme that allows non-backwards-compa= tible changes does not require that everyone uses them - IETF could continu= e to always publish backwards compatible modules. The obvious alternative = here is that each vendor comes up with their own versioning extension and i= gnores the RFC 7950 section 11 rules anyway, but I'm not sure how that real= ly helps client<->server interop. 2) I don't understand how the RFC 7950 approach of "deprecate a buggy node,= and replace with a working node" really works in practice, particularly fo= r configuration data nodes where you have two clients interacting with a se= rver, one interacting with the old path, and another using the new path. P= erhaps there is a robust scheme that works in all cases, but it isn't obvio= us to me. Historically, for CLI we just translate the CLI from old to new = format and then return the new format when the running config is requested.= But that will still break an old client that doesn't understand how to re= ad the new CLI, even if the server supports them writing via the old CLI. Even if there is a workable solution for this simple case, I suspect that t= here are many slightly more complicated cases that don't work (e.g. rekeyin= g a list, changing defaults, incompatible types). In short, I don't agree with the premise that the current YANG versioning s= chema using revision dates is working just fine, and no changes are needed. Thanks, Rob -----Original Message----- From: netmod On Behalf Of Martin Bjorklund Sent: 19 March 2019 15:12 To: kent+ietf@watsen.net Cc: netmod@ietf.org Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 Hi, I have read this document, and I do not think it should be adopted. I object to the idea that we should allow non-backwards-compatible changes = to published YANG modules. The draft motivates this idea with: we must recognize that many YANG modules are actually generated YANG modules (for example, from internal databases) I do not agree that we should change what we allow in published modules b/c= of this. It also motivates this idea with: The points made above lead to the logical conclusion that the standardized YANG modules have to be perfect on day one (at least the structure and meaning), which in turn might explain why IETF YANG modules take so long to standardize. I disagree with this. First of all, we have already published revision two= of several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interfaces,= ietf-ip, ietf-routing, ...), so the statement that "standardized YANG modu= les have to be perfect on day one" is simply not true. Second, I don't think the upgrade rules are the reason it takes a long time= to standardize IETF models (I think it has to do with the process itself, = including the fact that models get reviews from many different people with = different background.) [BTW, is it true that drafts with YANG models take = longer time from wg -00 to published RFC than other drafts?] This said, I think there are some important points that the draft raises, a= nd that I think we should continue to work on; specifically 2.3, 2.5, 2.6, = 2.7. But I don't think that these areas require changes to the versioning = scheme, and I think it is a mistake to include these areas in this draft. Some comments on section 4, The Problem Statement: o Any non-backwards-compatible change of a definition requires either a new module name or a new path. This has been found costly to support in implementations, in particular on the client side. Yes I agree there is a cost associated with this. But I have come across v= endor modules that make NBC changes w/o introducing a new path, and this is= also costly to handle. o Since non-backwards-compatible changes require either a new module name or a new path, such changes will impact other modules that import definitions. In fact, with the current module versioning scheme other modules have to opt-in in order to use the new version. This essentially leads to a ripple effect where a non- backwards-compatible change of a core module causes updates on a potentially large number of dependent modules. This is by design. We cannot have a situation where a legal modification t= o a module leads to other modules becoming invalid. o YANG has a mechanism to mark definitions deprecated but it leaves it open whether implementations are expected to implement deprecated definitions and there is no way (other than trial and error) for a client to find out whether deprecated definitions are supported by a given implementation. As I wrote above, I agree that this is a problem that should be solved. Bu= t this is not a motivation for changing YANG versioning. o YANG does not have a robust mechanism to document which data definitions have changed and to provide guidance how implementations should deal with the change. While it is possible to have this described in general description statements, having these details embedded in general description statements does not make this information accessible to tools. This might also be worth exploring, but this is not a motivation for changi= ng YANG versioning. /martin Kent Watsen wrote: > Seeing as how we all need to read this draft anyways, in preparation for = our meeting in Prague, it seems like a good time for this poll. Thusly, th= is email begins a 1-week adoption poll for: >=20 > =20 > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02=20 > 2> >=20 > Please voice your support or objections before March 20. >=20 > Note that this draft defines *requirements* and its intended status is "I= nformational." I believe that it is good for WGs to formalize requirement= s, even taking such drafts thru Last Call, in order to ensure consensus on = the requirements. This is the "adoption" call, to ascertain if the WG agre= es with that statement; if adopted, a separate "last call" will be issued t= o ensure to correctness of the draft's content. >=20 > Kent (and Lou and Joel) >=20 >=20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 19 10:17:39 2019 Return-Path: <0100016996f53cc3-63d3e646-1236-4efd-bcd0-c37d2e13a51d-000000@amazonses.watsen.net> 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 98C3013152D for ; Tue, 19 Mar 2019 10:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 DQK2_QHXiK-s for ; Tue, 19 Mar 2019 10:17:34 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A142413152E for ; Tue, 19 Mar 2019 10:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553015848; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=7ioxwUjtN1shYHrKs6RRbZ3HvuJmgujV/IxLoEwQOrM=; b=CdJGZZCnb+QvuxKR7ndoNWMhqVKR6sD6i6ls+FWGItr3+/E0U3bcsCWogf/L9UuE FgLN7jXT8/ke2UCysdtpkZLKcDQngXnoBwQ9eCvLhDrRrHwZaOR90ce8b718GMMMzC/ E65l4bpQ7gRiVuJ/W1BXvK5RptaQQ+H2x5Qe/fgs= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 19 Mar 2019 17:17:28 +0000 References: <155199275919.5534.4091583576716041337@ietfa.amsl.com> To: NETMOD Working Group In-Reply-To: <155199275919.5534.4091583576716041337@ietfa.amsl.com> Message-ID: <0100016996f53cc3-63d3e646-1236-4efd-bcd0-c37d2e13a51d-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.19-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2019-03-20 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 17:17:37 -0000 YANG-Next Reminders:=20 TOMORROW: Virtual Interim scheduled (see invite below) Also: Monday: 10-15 minute presentation during the afternoon NETMOD session Wednesday: 2-hour deep dive in Karlin 3 starting at 15:00 (please mark = your calendars) Kent > On Mar 7, 2019, at 4:05 PM, IESG Secretary = wrote: >=20 > The Network Modeling (netmod) Working Group will hold > a virtual interim meeting on 2019-03-20 from 10:00 to 12:00 = America/New_York. >=20 > Agenda: > Agenda: YANG Next Scoring (cont.) >=20 > The primary goal of this meeting is to attempt to better score the = following values: importance-unknown, backcompat-unknown, and = backcompat-medium, as these values are effecting impacting data = analysis. Secondary goal is to score the four new issues that have come = in since the last scoring meeting. The updated scoring values will be = reflected in the presentation given in NETMOD session #1 in Prague. = Details: https://github.com/netmod-wg/yang-next/issues. >=20 > Wednesday, March 20, 2019 > 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs > Meeting number (access code): 645 314 928 > Meeting password: Cx2n5J6N > = https://ietf.webex.com/ietf/j.php?MTID=3Dm9798c92a3f7fb0589e77eccd1fc9cd42= >=20 > Information about remote participation: > Webex information below. >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 19 11:13:10 2019 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 1658713121D for ; Tue, 19 Mar 2019 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 DvI9aqguFQDj for ; Tue, 19 Mar 2019 11:12:59 -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 40EFB1315B5 for ; Tue, 19 Mar 2019 11:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3720; q=dns/txt; s=iport; t=1553019179; x=1554228779; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L9DUSaLszPxhSwoeFVB5yUM1TgVliCdtMEmIumjqHsA=; b=Et/3E78HxblvhbM0L7GRkFBy8qSl6zEDl7mZWE7Nd18k2KWyRHY7GlN9 wIc41FRFmlReUbvAVSmHpeAt5uBBNdGMISOVVrtT7zfGQKWm2/DOMlE97 k9tcVc+yZgQuZ/T32HzTs1d0XnF8gqCUDUvptGAJ6bwEIrwwR5+s+VEDE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABvMJFc/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBghBogQMnCplVfIg3jn+BewsBARgLhAN?= =?us-ascii?q?GAoRrIjUIDQEBAwEBCQEDAm0cDIVKAQEBBAEBODQLDAQCAQgRBAEBHxAhBgs?= =?us-ascii?q?dCAIEAQ0FCIMbgV0DFQ+rYIQDAQGEAQ2CH4EvAYsxF4FAP4ERgl01gUGBFkc?= =?us-ascii?q?BAYdCA4ouJognkTg2CQKHW4QHhAmDNyGBfIVyi3CLDIV7gTaIeYJZAhEVgSg?= =?us-ascii?q?gATaBVnAVGiGCbAmFb4UUhQgBNkExjkKBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,245,1549929600"; d="scan'208";a="247411934" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 18:12:58 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JICwbU021338 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 18:12:58 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 13:12:57 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 19 Mar 2019 13:12:57 -0500 From: "Rob Wilton (rwilton)" To: RFC Errata System , "mbj@tail-f.com" , "ibagdona@gmail.com" , "warren@kumari.net" , "joelja@bogus.com" , "kent+ietf@watsen.net" , "lberger@labn.net" CC: "netmod@ietf.org" Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (5663) Thread-Index: AQHU3baq5+XMwB0tmk2hiGstPWcLO6YTQbfA Date: Tue, 19 Mar 2019 18:12:57 +0000 Message-ID: References: <20190318181542.0F0ABB826EA@rfc-editor.org> In-Reply-To: <20190318181542.0F0ABB826EA@rfc-editor.org> 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.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5663) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:13:09 -0000 Hi Ebben, I've always taken the ABNF to list the definitive sub-statements that are a= llowed for the various deviate "add", "replace", or "delete" options. Perh= aps the RFC could state this more explicitly. Perhaps raise an issue on th= e YANG Next issue tracker to clarify this (https://github.com/netmod-wg/yan= g-next/issues) and it might get discussed tomorrow. Thanks, Rob -----Original Message----- From: netmod On Behalf Of RFC Errata System Sent: 18 March 2019 18:16 To: mbj@tail-f.com; ibagdona@gmail.com; warren@kumari.net; joelja@bogus.com= ; kent+ietf@watsen.net; lberger@labn.net Cc: rfc-editor@rfc-editor.org; netmod@ietf.org Subject: [netmod] [Technical Errata Reported] RFC7950 (5663) The following errata report has been submitted for RFC7950, "The YANG 1.1 D= ata Modeling Language". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5663 -------------------------------------- Type: Technical Reported by: Ebben Aries Section: 14 Original Text ------------- deviate-delete-stmt =3D deviate-keyword sep delete-keyword-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt] *must-stmt *unique-stmt *default-stmt "}") stmtsep Corrected Text -------------- deviate-delete-stmt =3D deviate-keyword sep delete-keyword-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt] *must-stmt *unique-stmt *default-stmt [config-stmt] [mandatory-stmt] [min-elements-stmt] [max-elements-stmt] "}") stmtsep Notes ----- Section 7.20.3.2 specifies all permitted substatements for the "deviate" st= atement however the ABNF grammar specifies different valid substatements pe= r deviate argument. The "delete" argument is one such that only contains a= subset of what is defined in the substatement table in this section. The errata mentioned at: https://www.rfc-editor.org/errata/eid5489 is meant= to correct the following statement """ The argument "delete" deletes properties from the target node. The propert= ies to delete are identified by substatements to the "delete" statement. """ However this either needs to be a per argument table or ABNF correction Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party can log in to change the status and ed= it the report, if necessary.=20 -------------------------------------- RFC7950 (draft-ietf-netmod-rfc6020bis-14) -------------------------------------- Title : The YANG 1.1 Data Modeling Language Publication Date : August 2016 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 19 11:35:40 2019 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 7AC0C130F25 for ; Tue, 19 Mar 2019 11:35: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qqXZ4pa2UJPi for ; Tue, 19 Mar 2019 11:35:35 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 E91E812D4EA for ; Tue, 19 Mar 2019 11:35:34 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id l7so8496638ljg.6 for ; Tue, 19 Mar 2019 11:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HT2HqBuKBIQ+6RDwlGLYtcIHrVZ/io54ImGZlsMc18Y=; b=Q7TjCHcpKDC6t5Ink94WLgx1AwyT14IKtUGtW9oBT7KDadI89dboIGIGnJRyRGag2V LJ6pD8e/59QhsmwSy1Ty3vmWAH5OnqrDo860yFEzmtKr5XAXzI9amNtQ+1dn0kD86S2u mo4UoddluhJ8Xm0p/gRPKKza/B8F1kWW6b8MB0E27o+TaDcYZ0qEK7CpDAxtuu45aqSX PbAwIp+HAyQYfCoyfgTMnX2WEhk7cSc0mxdDeGc23MoaN5wqIpzbM0TNYlwqrDp8hw/c swKUbn++GS1HDvtUhfMsVBXMT/OeKFSoA9QTHQ8dD198KQSa0rPlI07SuDmgFkBpampr TREA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HT2HqBuKBIQ+6RDwlGLYtcIHrVZ/io54ImGZlsMc18Y=; b=ahG90H74/RulESv6/z4RfsKz+Bwb3oBPXMnSp/RLbReCJfOmiYeulRhvmH/C/SbhNs i4bl7kOMd7TOG8loACs+Cvs1QsJYlw0U2mCGJo1yV+TXU6oEe3mo6Y477H07fWuGZLud Qekr7ZmgNlIPrqjkdCf7+LH3DO+lPzdqmot0nwhudtYfNnhmOmivItI17HWSHm8s1KMD GDEtLqSoLQBS+7l2K8+okvt1+Kv/YxVwQITUMWlAwexj4IkigvnK3fo02cmbM/aaEza7 gFSApKfIuxPvImZ9CvoEYuPhSt21ArjZ8Rf65oI9KRldK1mnqbxeKoKPv1KJ07nr42FI kB4g== X-Gm-Message-State: APjAAAXx3F+dpLOXw0bAz7UXXmAzoZ5e0Bkg/QSbW9yE+t67gzrx0jtR pDLE4wBnYPOsoHRiFkezNozhgRNdA6XQuuAE1fvHQg== X-Google-Smtp-Source: APXvYqwEtdDymuGHTjlv/dL+4/lJyfslOj5GOslV2qYj7uR9qicevLSRtDxvP21tUolmvPKbC0hf8DUxITBk9qiXiU8= X-Received: by 2002:a2e:85d2:: with SMTP id h18mr8675830ljj.128.1553020532905; Tue, 19 Mar 2019 11:35:32 -0700 (PDT) MIME-Version: 1.0 References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> In-Reply-To: From: Andy Bierman Date: Tue, 19 Mar 2019 11:35:21 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Martin Bjorklund , "kent+ietf@watsen.net" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000316b91058476c514" Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:35:40 -0000 --000000000000316b91058476c514 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) wrote: > Hi Martin, > > Thanks for the review and comments. > > A couple of points: > > 1) Lots of models outside those published in SDOs are already not > following the RFC 7950 revision rules. I think that it is better to have a > versioning scheme that reflects how YANG models are actually evolving > rather than have all vendor and OC YANG modules either just ignoring the > rules, or using clever tricks that strictly conform with the rules but go > against the spirit of them (e.g. just publish an entirely new set of YANG > modules for each release). Also noting that having a scheme that allows > non-backwards-compatible changes does not require that everyone uses them - > IETF could continue to always publish backwards compatible modules. The > obvious alternative here is that each vendor comes up with their own > versioning extension and ignores the RFC 7950 section 11 rules anyway, but > I'm not sure how that really helps client<->server interop. > > I do not support branching for YANG models so I do not supported modified SEMVER. Adding a special character to the version string doesn't help the deployed client code that stops working when the server code is upgraded. This is a quality issue that each organization has to deal with the best they can. I do not object to the addition of a SEMVER field to a YANG module because these version strings are familiar to users. It is possible to express import ranges such as 1.2.* (any 1.2.x release) which are not possible with date strings. 2) I don't understand how the RFC 7950 approach of "deprecate a buggy node, > and replace with a working node" really works in practice, particularly for > configuration data nodes where you have two clients interacting with a > server, one interacting with the old path, and another using the new path. > Perhaps there is a robust scheme that works in all cases, but it isn't > obvious to me. Historically, for CLI we just translate the CLI from old to > new format and then return the new format when the running config is > requested. But that will still break an old client that doesn't understand > how to read the new CLI, even if the server supports them writing via the > old CLI. > > SEMVER does not reduce the number of paths to the underlying configuration object. That problem does not change whether a new XPath absolute-path-expr is used or whether the same path is overloaded with semantics derived from additional protocol parameters (e.g., versioning of each data node). I prefer the existing XPath solution because it is explicit so the YANG reader can easily see the multiple paths, and no new protocol work needed to support it. If there is an NBC change to an object then all XPath and leafref references to it will probably break. That seems like a harder problem to solve than the original path duplication problem. Even if there is a workable solution for this simple case, I suspect that > there are many slightly more complicated cases that don't work (e.g. > rekeying a list, changing defaults, incompatible types). > > In short, I don't agree with the premise that the current YANG versioning > schema using revision dates is working just fine, and no changes are needed. > > Thanks, > Rob > > Andy > > -----Original Message----- > From: netmod On Behalf Of Martin Bjorklund > Sent: 19 March 2019 15:12 > To: kent+ietf@watsen.net > Cc: netmod@ietf.org > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > Hi, > > I have read this document, and I do not think it should be adopted. > > I object to the idea that we should allow non-backwards-compatible changes > to published YANG modules. > > The draft motivates this idea with: > > we must recognize that many YANG > modules are actually generated YANG modules (for example, from > internal databases) > > I do not agree that we should change what we allow in published modules > b/c of this. > > It also motivates this idea with: > > The points made above lead to the logical conclusion that the > standardized YANG modules have to be perfect on day one (at least the > structure and meaning), which in turn might explain why IETF YANG > modules take so long to standardize. > > I disagree with this. First of all, we have already published revision > two of several YANG modules (ietf-inet-types, ietf-yang-type, > ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that > "standardized YANG modules have to be perfect on day one" is simply not > true. > > Second, I don't think the upgrade rules are the reason it takes a long > time to standardize IETF models (I think it has to do with the process > itself, including the fact that models get reviews from many different > people with different background.) [BTW, is it true that drafts with YANG > models take longer time from wg -00 to published RFC than other drafts?] > > > This said, I think there are some important points that the draft raises, > and that I think we should continue to work on; specifically 2.3, 2.5, 2.6, > 2.7. But I don't think that these areas require changes to the versioning > scheme, and I think it is a mistake to include these areas in this draft. > > Some comments on section 4, The Problem Statement: > > o Any non-backwards-compatible change of a definition requires > either a new module name or a new path. This has been found > costly to support in implementations, in particular on the client > side. > > Yes I agree there is a cost associated with this. But I have come across > vendor modules that make NBC changes w/o introducing a new path, and this > is also costly to handle. > > o Since non-backwards-compatible changes require either a new module > name or a new path, such changes will impact other modules that > import definitions. In fact, with the current module versioning > scheme other modules have to opt-in in order to use the new > version. This essentially leads to a ripple effect where a non- > backwards-compatible change of a core module causes updates on a > potentially large number of dependent modules. > > This is by design. We cannot have a situation where a legal modification > to a module leads to other modules becoming invalid. > > o YANG has a mechanism to mark definitions deprecated but it leaves > it open whether implementations are expected to implement > deprecated definitions and there is no way (other than trial and > error) for a client to find out whether deprecated definitions are > supported by a given implementation. > > As I wrote above, I agree that this is a problem that should be solved. > But this is not a motivation for changing YANG versioning. > > o YANG does not have a robust mechanism to document which data > definitions have changed and to provide guidance how > implementations should deal with the change. While it is possible > to have this described in general description statements, having > these details embedded in general description statements does not > make this information accessible to tools. > > This might also be worth exploring, but this is not a motivation for > changing YANG versioning. > > > > /martin > > > > Kent Watsen wrote: > > Seeing as how we all need to read this draft anyways, in preparation for > our meeting in Prague, it seems like a good time for this poll. Thusly, > this email begins a 1-week adoption poll for: > > > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 > > > 2> > > > > Please voice your support or objections before March 20. > > > > Note that this draft defines *requirements* and its intended status is > "Informational." I believe that it is good for WGs to formalize > requirements, even taking such drafts thru Last Call, in order to ensure > consensus on the requirements. This is the "adoption" call, to ascertain > if the WG agrees with that statement; if adopted, a separate "last call" > will be issued to ensure to correctness of the draft's content. > > > > Kent (and Lou and Joel) > > > > > > _______________________________________________ > 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 > --000000000000316b91058476c514 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 19, 2019 at 9:38 AM Rob W= ilton (rwilton) <rwilton@cisco.com<= /a>> wrote:
H= i Martin,

Thanks for the review and comments.

A couple of points:

1) Lots of models outside those published in SDOs are already not following= the RFC 7950 revision rules.=C2=A0 I think that it is better to have a ver= sioning scheme that reflects how YANG models are actually evolving rather t= han have all vendor and OC YANG modules either just ignoring the rules, or = using clever tricks that strictly conform with the rules but go against the= spirit of them (e.g. just publish an entirely new set of YANG modules for = each release).=C2=A0 Also noting that having a scheme that allows non-backw= ards-compatible changes does not require that everyone uses them - IETF cou= ld continue to always publish backwards compatible modules.=C2=A0 The obvio= us alternative here is that each vendor comes up with their own versioning = extension and ignores the RFC 7950 section 11 rules anyway, but I'm not= sure how that really helps client<->server interop.






2) I don't understand how the RFC 7950 approach of "deprecate a bu= ggy node, and replace with a working node" really works in practice, p= articularly for configuration data nodes where you have two clients interac= ting with a server, one interacting with the old path, and another using th= e new path.=C2=A0 Perhaps there is a robust scheme that works in all cases,= but it isn't obvious to me.=C2=A0 Historically, for CLI we just transl= ate the CLI from old to new format and then return the new format when the = running config is requested.=C2=A0 But that will still break an old client = that doesn't understand how to read the new CLI, even if the server sup= ports them writing via the old CLI.


That seems l= ike a harder problem to solve than the original path duplication problem.


Even if there is a workable solution for this simple case, I suspect that t= here are many slightly more complicated cases that don't work (e.g. rek= eying a list, changing defaults, incompatible types).

In short, I don't agree with the premise that the current YANG versioni= ng schema using revision dates is working just fine, and no changes are nee= ded.

Thanks,
Rob


Andy
=C2=A0

-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: kent+ietf@w= atsen.net
Cc: netmod@ietf.org
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi,

I have read this document, and I do not think it should be adopted.

I object to the idea that we should allow non-backwards-compatible changes = to published YANG modules.

The draft motivates this idea with:

=C2=A0 =C2=A0we must recognize that many YANG
=C2=A0 =C2=A0modules are actually generated YANG modules (for example, from=
=C2=A0 =C2=A0internal databases)

I do not agree that we should change what we allow in published modules b/c= of this.

It also motivates this idea with:

=C2=A0 =C2=A0The points made above lead to the logical conclusion that the<= br> =C2=A0 =C2=A0standardized YANG modules have to be perfect on day one (at le= ast the
=C2=A0 =C2=A0structure and meaning), which in turn might explain why IETF Y= ANG
=C2=A0 =C2=A0modules take so long to standardize.

I disagree with this.=C2=A0 First of all, we have already published revisio= n two of several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interf= aces, ietf-ip, ietf-routing, ...), so the statement that "standardized= YANG modules have to be perfect on day one" is simply not true.

Second, I don't think the upgrade rules are the reason it takes a long = time to standardize IETF models (I think it has to do with the process itse= lf, including the fact that models get reviews from many different people w= ith different background.)=C2=A0 [BTW, is it true that drafts with YANG mod= els take longer time from wg -00 to published RFC than other drafts?]


This said, I think there are some important points that the draft raises, a= nd that I think we should continue to work on; specifically 2.3, 2.5, 2.6, = 2.7.=C2=A0 But I don't think that these areas require changes to the ve= rsioning scheme, and I think it is a mistake to include these areas in this= draft.

Some comments on section 4, The Problem Statement:

=C2=A0 =C2=A0o=C2=A0 Any non-backwards-compatible change of a definition re= quires
=C2=A0 =C2=A0 =C2=A0 either a new module name or a new path.=C2=A0 This has= been found
=C2=A0 =C2=A0 =C2=A0 costly to support in implementations, in particular on= the client
=C2=A0 =C2=A0 =C2=A0 side.

Yes I agree there is a cost associated with this.=C2=A0 But I have come acr= oss vendor modules that make NBC changes w/o introducing a new path, and th= is is also costly to handle.

=C2=A0 =C2=A0o=C2=A0 Since non-backwards-compatible changes require either = a new module
=C2=A0 =C2=A0 =C2=A0 name or a new path, such changes will impact other mod= ules that
=C2=A0 =C2=A0 =C2=A0 import definitions.=C2=A0 In fact, with the current mo= dule versioning
=C2=A0 =C2=A0 =C2=A0 scheme other modules have to opt-in in order to use th= e new
=C2=A0 =C2=A0 =C2=A0 version.=C2=A0 This essentially leads to a ripple effe= ct where a non-
=C2=A0 =C2=A0 =C2=A0 backwards-compatible change of a core module causes up= dates on a
=C2=A0 =C2=A0 =C2=A0 potentially large number of dependent modules.

This is by design.=C2=A0 We cannot have a situation where a legal modificat= ion to a module leads to other modules becoming invalid.

=C2=A0 =C2=A0o=C2=A0 YANG has a mechanism to mark definitions deprecated bu= t it leaves
=C2=A0 =C2=A0 =C2=A0 it open whether implementations are expected to implem= ent
=C2=A0 =C2=A0 =C2=A0 deprecated definitions and there is no way (other than= trial and
=C2=A0 =C2=A0 =C2=A0 error) for a client to find out whether deprecated def= initions are
=C2=A0 =C2=A0 =C2=A0 supported by a given implementation.

As I wrote above, I agree that this is a problem that should be solved.=C2= =A0 But this is not a motivation for changing YANG versioning.

=C2=A0 =C2=A0o=C2=A0 YANG does not have a robust mechanism to document whic= h data
=C2=A0 =C2=A0 =C2=A0 definitions have changed and to provide guidance how =C2=A0 =C2=A0 =C2=A0 implementations should deal with the change.=C2=A0 Whi= le it is possible
=C2=A0 =C2=A0 =C2=A0 to have this described in general description statemen= ts, having
=C2=A0 =C2=A0 =C2=A0 these details embedded in general description statemen= ts does not
=C2=A0 =C2=A0 =C2=A0 make this information accessible to tools.

This might also be worth exploring, but this is not a motivation for changi= ng YANG versioning.



/martin



Kent Watsen <kent+ietf@watsen.net> wrote:
> Seeing as how we all need to read this draft anyways, in preparation f= or our meeting in Prague, it seems like a good time for this poll.=C2=A0 Th= usly, this email begins a 1-week adoption poll for:
>
>=C2=A0 =C2=A0 =C2=A0
> https://tools.ietf.org/ht= ml/draft-verdt-netmod-yang-versioning-reqs-02
> <https://tools.ietf.org= /html/draft-verdt-netmod-yang-versioning-reqs-0
> 2>
>
> Please voice your support or objections before March 20.
>
> Note that this draft defines *requirements* and its intended status is= "Informational."=C2=A0 =C2=A0I believe that it is good for WGs t= o formalize requirements, even taking such drafts thru Last Call, in order = to ensure consensus on the requirements.=C2=A0 This is the "adoption&q= uot; call, to ascertain if the WG agrees with that statement; if adopted, a= separate "last call" will be issued to ensure to correctness of = the draft's content.
>
> Kent (and Lou and Joel)
>
>

_______________________________________________
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
--000000000000316b91058476c514-- From nobody Tue Mar 19 15:28:08 2019 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 D9B2C129A86 for ; Tue, 19 Mar 2019 15:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x58aS_FkH7Co for ; Tue, 19 Mar 2019 15:28:03 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428311277E5 for ; Tue, 19 Mar 2019 15:28:02 -0700 (PDT) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id EFD4C241860; Tue, 19 Mar 2019 23:27:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1553034480; bh=46UFpF0wcafKYKeRjozoMsPEC/u2DOoZIiOSrDsHwrM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=FsPsLS+z6HfgOAy9Us6mQVCg9KPNioDj9kMVguIJI7IfiEYAioESIGNcEo05gy2cd /37E2OeY6hOQbipZGic47YLzvVKX3Avc9SMDf7jPZoguGz30Q+JG6WNicCJZiXY5X2 a6eydBQxezpL4Llrfy8usx/asnzgt83sIwtebYdk= To: "Rob Wilton (rwilton)" , RFC Errata System , "mbj@tail-f.com" , "ibagdona@gmail.com" , "warren@kumari.net" , "joelja@bogus.com" , "kent+ietf@watsen.net" , "lberger@labn.net" Cc: "netmod@ietf.org" References: <20190318181542.0F0ABB826EA@rfc-editor.org> From: Robert Varga Openpgp: preference=signencrypt Message-ID: Date: Tue, 19 Mar 2019 23:27:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5663) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 22:28:06 -0000 On 19/03/2019 19:12, Rob Wilton (rwilton) wrote: > Hi Ebben, > > I've always taken the ABNF to list the definitive sub-statements that are allowed for the various deviate "add", "replace", or "delete" options. Perhaps the RFC could state this more explicitly. Perhaps raise an issue on the YANG Next issue tracker to clarify this (https://github.com/netmod-wg/yang-next/issues) and it might get discussed tomorrow. I agree. Proposed statements are simple cases, for which 'deviate replace' can be used to specify the correct value -- for example remove 'min-elements' by replacing it with 'min-elements 0'. Regards, Robert From nobody Wed Mar 20 00:30:27 2019 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 6787E130EFA for ; Wed, 20 Mar 2019 00:30:26 -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 iMMc6-SzzL6H for ; Wed, 20 Mar 2019 00:30:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 807E31277CE for ; Wed, 20 Mar 2019 00:30:23 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 3CB631AE018A; Wed, 20 Mar 2019 08:30:21 +0100 (CET) Date: Wed, 20 Mar 2019 08:30:22 +0100 (CET) Message-Id: <20190320.083022.2046737837256499330.mbj@tail-f.com> To: rwilton@cisco.com Cc: kent+ietf@watsen.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 07:30:26 -0000 Hi, "Rob Wilton (rwilton)" wrote: > Hi Martin, > > Thanks for the review and comments. > > A couple of points: > > 1) Lots of models outside those published in SDOs are already not > following the RFC 7950 revision rules. Right, and I think that is ok. If vendors want to break backwards compatibility it is up to them. With the current rules you can have tool that detect this and flags it. You can then fix the problem or release the new NBC module anyway, but you have been warned. Customers will accept this or not. > I think that it is better to > have a versioning scheme that reflects how YANG models are actually > evolving rather than have all vendor and OC YANG modules either just > ignoring the rules, or using clever tricks that strictly conform with > the rules but go against the spirit of them (e.g. just publish an > entirely new set of YANG modules for each release). Also noting that > having a scheme that allows non-backwards-compatible changes does not > require that everyone uses them - IETF could continue to always > publish backwards compatible modules. The obvious alternative here is > that each vendor comes up with their own versioning extension and > ignores the RFC 7950 section 11 rules anyway, but I'm not sure how > that really helps client<->server interop. The client<->server interop will not magically work better if we allow NBC changes. > 2) I don't understand how the RFC 7950 approach of "deprecate a buggy > node, and replace with a working node" really works in practice, > particularly for configuration data nodes where you have two clients > interacting with a server, one interacting with the old path, and > another using the new path. Perhaps there is a robust scheme that > works in all cases, but it isn't obvious to me. Historically, for CLI > we just translate the CLI from old to new format and then return the > new format when the running config is requested. But that will still > break an old client that doesn't understand how to read the new CLI, > even if the server supports them writing via the old CLI. > > Even if there is a workable solution for this simple case, I suspect > that there are many slightly more complicated cases that don't work > (e.g. rekeying a list, changing defaults, incompatible types). I fully agree. This is difficult in the general case. In the worst case you'll have to give up on backwards compatibility and only implement the new version of the module (I believe this is possible both with the current versioning rules, and with the proposed rules). > In short, I don't agree with the premise that the current YANG > versioning schema using revision dates is working just fine, and no > changes are needed. But this is not what the draft is about! There is nothing in the draft that talks about problems introduced by using the revision dates. /martin > > Thanks, > Rob > > > -----Original Message----- > From: netmod On Behalf Of Martin Bjorklund > Sent: 19 March 2019 15:12 > To: kent+ietf@watsen.net > Cc: netmod@ietf.org > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > Hi, > > I have read this document, and I do not think it should be adopted. > > I object to the idea that we should allow non-backwards-compatible > changes to published YANG modules. > > The draft motivates this idea with: > > we must recognize that many YANG > modules are actually generated YANG modules (for example, from > internal databases) > > I do not agree that we should change what we allow in published > modules b/c of this. > > It also motivates this idea with: > > The points made above lead to the logical conclusion that the > standardized YANG modules have to be perfect on day one (at least the > structure and meaning), which in turn might explain why IETF YANG > modules take so long to standardize. > > I disagree with this. First of all, we have already published > revision two of several YANG modules (ietf-inet-types, ietf-yang-type, > ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that > "standardized YANG modules have to be perfect on day one" is simply > not true. > > Second, I don't think the upgrade rules are the reason it takes a long > time to standardize IETF models (I think it has to do with the process > itself, including the fact that models get reviews from many different > people with different background.) [BTW, is it true that drafts with > YANG models take longer time from wg -00 to published RFC than other > drafts?] > > > This said, I think there are some important points that the draft > raises, and that I think we should continue to work on; specifically > 2.3, 2.5, 2.6, 2.7. But I don't think that these areas require > changes to the versioning scheme, and I think it is a mistake to > include these areas in this draft. > > Some comments on section 4, The Problem Statement: > > o Any non-backwards-compatible change of a definition requires > either a new module name or a new path. This has been found > costly to support in implementations, in particular on the client > side. > > Yes I agree there is a cost associated with this. But I have come > across vendor modules that make NBC changes w/o introducing a new > path, and this is also costly to handle. > > o Since non-backwards-compatible changes require either a new module > name or a new path, such changes will impact other modules that > import definitions. In fact, with the current module versioning > scheme other modules have to opt-in in order to use the new > version. This essentially leads to a ripple effect where a non- > backwards-compatible change of a core module causes updates on a > potentially large number of dependent modules. > > This is by design. We cannot have a situation where a legal > modification to a module leads to other modules becoming invalid. > > o YANG has a mechanism to mark definitions deprecated but it leaves > it open whether implementations are expected to implement > deprecated definitions and there is no way (other than trial and > error) for a client to find out whether deprecated definitions are > supported by a given implementation. > > As I wrote above, I agree that this is a problem that should be > solved. But this is not a motivation for changing YANG versioning. > > o YANG does not have a robust mechanism to document which data > definitions have changed and to provide guidance how > implementations should deal with the change. While it is possible > to have this described in general description statements, having > these details embedded in general description statements does not > make this information accessible to tools. > > This might also be worth exploring, but this is not a motivation for > changing YANG versioning. > > > > /martin > > > > Kent Watsen wrote: > > Seeing as how we all need to read this draft anyways, in preparation > > for our meeting in Prague, it seems like a good time for this poll. > > Thusly, this email begins a 1-week adoption poll for: > > > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 > > > 2> > > > > Please voice your support or objections before March 20. > > > > Note that this draft defines *requirements* and its intended status is > > "Informational." I believe that it is good for WGs to formalize > > requirements, even taking such drafts thru Last Call, in order to > > ensure consensus on the requirements. This is the "adoption" call, to > > ascertain if the WG agrees with that statement; if adopted, a separate > > "last call" will be issued to ensure to correctness of the draft's > > content. > > > > Kent (and Lou and Joel) > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Mar 20 04:54:28 2019 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 07343130ED1 for ; Wed, 20 Mar 2019 04:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 GhRObyCodUud for ; Wed, 20 Mar 2019 04:54:22 -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 80F9E130E78 for ; Wed, 20 Mar 2019 04:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50564; q=dns/txt; s=iport; t=1553082861; x=1554292461; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RlCXWT990jyG7zTARzWzG4Z8/E0HruvV6Ax5ib/wsYk=; b=VxTGS9R3E+oJMSbnmYV9vCPkjXsJ9ZA3B+3FfgD4o52QkAEyAUsBg3Wt GX2Gt9g92YcGxopQLchsJMkFdrdAnVKtbH/cfsVnGXHkn0BOJzCiA/iTV evVaOfoVSPCkzj7oRNHCQTK5DxhHjPBtbPNSYsFaELYtvpCFsERg1P27J 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADIKJJc/5xdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ5TL2iBAycKg0NAiByNLJg0FIFjBAs?= =?us-ascii?q?BARgBCoFUgi9GAheETSI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQBAQoOCQQGQQs?= =?us-ascii?q?MBAIBBgIRBAEBASABBgMCAgIlCxQJCAIEDgUIE4MIgRFkD45km2Z8M4QwAQM?= =?us-ascii?q?ChXkFgS8BizEXgUA/gyV+gx4BAQIBgSsBCwcBCQlDglSCVwOKHg4zAoIDhBg?= =?us-ascii?q?ehx6LWWAJAoddhAeHQCGBfIVzg0uIJ4wmhGaNCQIRFYEtHzgoPXFwFTuCbII?= =?us-ascii?q?WF4NLhRSFP0ExijwCDReBCIEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,248,1549929600"; d="scan'208,217";a="452643287" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 11:54:19 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KBsJjG023233 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 11:54:19 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 06:54:18 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 20 Mar 2019 06:54:18 -0500 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: Martin Bjorklund , "kent+ietf@watsen.net" , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SCAAIXFgIAAwkJw Date: Wed, 20 Mar 2019 11:54:18 +0000 Message-ID: <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> In-Reply-To: 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.63.23.135] Content-Type: multipart/alternative; boundary="_000_8871415dce7343a28afa25faf6080d8cXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 11:54:26 -0000 --_000_8871415dce7343a28afa25faf6080d8cXCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQoNCjEuIFJlZ3VsYXIgU2VtdmVy IDIuMC4wIChhcyBwZXIgc2VtdmVyLm9yZykgYWxsb3dzIHNvbWUgYnJhbmNoaW5nLiAgSS5lLiB5 b3UgY2FuIGNyZWF0ZSB2ZXJzaW9uIDIuMC4wIGJhc2VkIG9mIHZlcnNpb24gMS4xLjAsIGFuZCB0 aGVuIHN1YnNlcXVlbnRseSBjcmVhdGUgdmVyc2lvbiAxLjIuMCBiYXNlZCBvZiAxLjEuMC4gIFNv IHN0cnVjdHVyZSB3aXNlIHRoaXMgd291bGQgbG9naWNhbGx5IGxvb2sgbGlrZToNCg0KICAgMS4w LjANCiAgICAgIHwgXA0KICAgICAgfCAgIDEuMS4wIOKAkyAxLjIuMCAtIOKApg0KICAgICAgfA0K ICAgMi4wLjANCiAgICAgIHwNCg0KSSBhbHNvIHJhaXNlZCBodHRwczovL2dpdGh1Yi5jb20vc2Vt dmVyL3NlbXZlci9pc3N1ZXMvNTA0ICBvbiB0aGUgc2VtdmVyIDIuMC4wIGdpdGh1YiB0byBjb25m aXJtIHRoYXQgbXkgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdCwgYW5kIG5vIG9uZSBoYXMgZGlz cHV0ZWQgaXQgeWV0Lg0KDQoNCjIuIFZlbmRvciBzb2Z0d2FyZSByZWxlYXNlcyBjYW4gaGF2ZSBh IHZlcnkgbG9uZyBzdXBwb3J0IHRpbWUgKGUuZy4gZWFzaWx5IDUrIHllYXJzKSwgd2l0aCBhbiBl eHBlY3RhdGlvbiB0aGF0IGJ1Z3MgZ2V0IGZpeGVkLiAgUmVxdWlyaW5nIHRoYXQgY3VzdG9tZXJz IHVwZ3JhZGUgdGhlaXIgc29mdHdhcmUgKG9yIHBlcmhhcHMgaGFyZHdhcmUpIHRvIHRoZSB2ZXJ5 IGxhdGVzdCBzb2Z0d2FyZSB2ZXJzaW9uIHRvIHBpY2sgdXAgYSBzbWFsbCBidWcgZml4IGlzIG5v dCByZWFsaXN0aWMuICBUaGlzIGlzIHByaW1hcmlseSB3aHkgSSB0aGluayB0aGF0IHRoZSDigJht 4oCZIGFuZCDigJhN4oCZIGFyZSBzbyBpbXBvcnRhbnQuICBUaGV5IGFsbG93IGZvciBidWcgZml4 ZXMgaW4gYSB3YXkgdGhhdCBTZW12ZXIgMi4wLjAgc2ltcGx5IGRvZXMgbm90Lg0KDQpTZW12ZXIg Mi4wLjAgb25seSBhbGxvd3MgZm9yIGJ1Z2ZpeGVzIGluIHRoZSBpbXBsZW1lbnRhdGlvbiAoYnkg dXBkYXRpbmcgdGhlIHBhdGNoIHZlcnNpb24gbnVtYmVyKSwgYnV0IGhhcyB0aGUgZXhwZWN0YXRp b24gdGhhdCB0aGVyZSBhcmUgKm5ldmVyKiBhbnkgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNo YW5nZXMgaW4gdGhlIEFQSSwgbm90IGV2ZW4gdG8gZml4IGEgYnVnLCBleGNlcHQgYXQgdGhlIHRp cCBvZiB0aGUgZGV2ZWxvcG1lbnQgdHJlZS4NCg0KSW4gc2hvcnQsIEkgdGhpbmsgdGhhdCB2YW5p bGxhIFNlbXZlciAyLjAuMCBpcyBhIGdvb2QgZml0IGZvciBvcGVuIHNvdXJjZSBwcm9qZWN0cyB3 aGVyZSB5b3UgY2FuIGp1c3QgdGVsbCB0aGUgY2xpZW50IHRvIHVwZGF0ZSB0byB0aGUgbGF0ZXN0 IHZlcnNpb24gdG8gcGljayB1cCB0aGUgZml4LiAgSSBkb27igJl0IHRoaW5rIHRoYXQgU2VtdmVy IDIuMC4wIGlzIHNvIHdlbGwgYWxpZ25lZCB0byBBUElzIHRoYXQgYXJlIHJlcXVpcmVkIHRvIGJl IG1haW50YWluZWQgZm9yIGxvbmcgcGVyaW9kcyBvZiB0aW1lLg0KDQpUaGUgYWx0ZXJuYXRpdmUg dGhhdCBSb2IgU2hha2lyIG1lbnRpb25lZCBhdCBJRVRGIDEwMyBpbiB0aGUgY29udGV4dCBvZiBP cGVuQ29uZmlnLCB3aGljaCB1c2VzIHN0cmljdCBTZW12ZXIgMi4wLjAsIGlzIHRvIGhhbmRsZSB0 aGVzZSBidWcgZml4ZXMgdXNpbmcgZGV2aWF0aW9ucy4gIEJ1dCBpdCBzZWVtcyB0byBiZSBzaWdu aWZpY2FudGx5IG1vcmUgY29tcGxleCB0byBtYW5hZ2UgYnVnIGZpeGVzIHVzaW5nIGV4dHJhIGRl dmlhdGlvbiBtb2R1bGVzIHJhdGhlciB0aGFuIGFsbG93aW5nIHRoZSDigJht4oCZIHwg4oCYTeKA mSBtb2RpZmllcnMuICBWZXJzaW9uaW5nIHdvdWxkIG5vIGxvbmdlciBsaW1pdGVkIHRvIGEgbW9k dWxlIHZlcnNpb24gbnVtYmVyLCBidXQgcmVxdWlyZSBrbm93bGVkZ2Ugb2YgdGhlIG1vZHVsZSB2 ZXJzaW9uIGFuZCBzZXQgb2YgZGV2aWF0aW9ucyB0aGF0IGFyZSBhcHBsaWVkIHRvIGl0LiAgSSB3 b3VsZCByYXRoZXIgZGV2aWF0aW9ucyBhcmUgcmVzZXJ2ZWQgdG8gaW5kaWNhdGUgd2hldGhlciBh biBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgbWF0Y2ggdGhlIG1vZHVsZSBzcGVjaWZpY2F0aW9u IHJhdGhlciB0aGFuIHVzZSB0aGVtIGFzIGEgd2F5IG9mIGZpeGluZyBidWdzIGluIHRoZSBzcGVj aWZpY2F0aW9uIGl0c2VsZi4NCg0KDQozLiBJIGFncmVlIHRoYXQgdGhlIHVzZSBvZiBTZW12ZXIg KyBwYWNrYWdlcyArIHZlcnNpb24gc2VsZWN0aW9uIGRvZXMgbm90IHJlZHVjZSB0aGUgb3ZlcmFs bCBudW1iZXIgb2YgcGF0aHMgdG8gYSBjb25maWd1cmFibGUgcHJvcGVydHksIGJ1dCBpdCBkb2Vz IGVuc3VyZSB0aGF0IHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgcGF0aCB0byBhIGNvbmZpZ3VyYWJs ZSBwcm9wZXJ0eSB3aXRoaW4gYSBZQU5HIGRhdGFzdG9yZSBzY2hlbWEuICAgU28gd2hpY2hldmVy IHZlcnNpb24gZWFjaCBjbGllbnQgaXMgdXNpbmcsIHRoZXkgb25seSB1c2UgYSBzaW5nbGUgcGF0 aC4gIEkuZS4gbWlycm9yaW5nIHRoZSB3YXkgdGhhdCBhIGNsYXNzaWMgcHJvZ3JhbW1pbmcgQVBJ IG1pZ2h0IGJlIHZlcnNpb25lZC4NCg0KU2VydmVycyB0aGF0IHdpc2ggdG8gc3VwcG9ydCB0aGlz IHdvdWxkIGhhdmUgdG8gbWFwIHRoZSBkYXRhIGJldHdlZW4gZGlmZmVyZW50IFlBTkcgZGF0YXN0 b3JlIHNjaGVtYSB2ZXJzaW9ucy4gIE5vdCBhbGwgbWFwcGluZ3MgYXJlIHBvc3NpYmxlLCBidXQg YXQgbGVhc3QgYW55IGNhc2VzIHdoZXJlIGl0IGlzIG5vdCBwb3NzaWJsZSBjYW4gYmUgZGV0ZWN0 ZWQgYW5kIHJlcG9ydGVkIHRvIHRoZSBjbGllbnQgdmlhIGFuIG91dCBvZiBiYW5kIG1lY2hhbmlz bS4NCg0KSWYgdGhlIG1vZHVsZSBjb250ZW50IGNoYW5nZXMgc2lnbmlmaWNhbnRseSBiZXR3ZWVu IG1vZHVsZSB2ZXJzaW9ucyB0aGF0IG1hcHBpbmcgd2lsbCBiZSBtdWNoIGhhcmRlciB0aGFuIGlm IHRoZSBjaGFuZ2VzIGFyZSBtaW5pbWFsIG9yIGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgU28gdGhl cmUgaXMgc3RpbGwgYSBzdHJvbmcgaW5jZW50aXZlIGZvciBtb2RlbCB3cml0ZXJzIHRvIG1pbmlt aXplIGNodXJuIHRvIHRoZSBZQU5HIG1vZGVscy4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KRnJvbTog QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50OiAxOSBNYXJjaCAyMDE5IDE4 OjM1DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KQ2M6IE1h cnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsga2VudCtpZXRmQHdhdHNlbi5uZXQ7IG5l dG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGFkb3B0aW9uIHBvbGwgZm9yIHlh bmctdmVyc2lvbmluZy1yZXFzLTAyDQoNCg0KDQpPbiBUdWUsIE1hciAxOSwgMjAxOSBhdCA5OjM4 IEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRv bkBjaXNjby5jb20+PiB3cm90ZToNCkhpIE1hcnRpbiwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3 IGFuZCBjb21tZW50cy4NCg0KQSBjb3VwbGUgb2YgcG9pbnRzOg0KDQoxKSBMb3RzIG9mIG1vZGVs cyBvdXRzaWRlIHRob3NlIHB1Ymxpc2hlZCBpbiBTRE9zIGFyZSBhbHJlYWR5IG5vdCBmb2xsb3dp bmcgdGhlIFJGQyA3OTUwIHJldmlzaW9uIHJ1bGVzLiAgSSB0aGluayB0aGF0IGl0IGlzIGJldHRl ciB0byBoYXZlIGEgdmVyc2lvbmluZyBzY2hlbWUgdGhhdCByZWZsZWN0cyBob3cgWUFORyBtb2Rl bHMgYXJlIGFjdHVhbGx5IGV2b2x2aW5nIHJhdGhlciB0aGFuIGhhdmUgYWxsIHZlbmRvciBhbmQg T0MgWUFORyBtb2R1bGVzIGVpdGhlciBqdXN0IGlnbm9yaW5nIHRoZSBydWxlcywgb3IgdXNpbmcg Y2xldmVyIHRyaWNrcyB0aGF0IHN0cmljdGx5IGNvbmZvcm0gd2l0aCB0aGUgcnVsZXMgYnV0IGdv IGFnYWluc3QgdGhlIHNwaXJpdCBvZiB0aGVtIChlLmcuIGp1c3QgcHVibGlzaCBhbiBlbnRpcmVs eSBuZXcgc2V0IG9mIFlBTkcgbW9kdWxlcyBmb3IgZWFjaCByZWxlYXNlKS4gIEFsc28gbm90aW5n IHRoYXQgaGF2aW5nIGEgc2NoZW1lIHRoYXQgYWxsb3dzIG5vbi1iYWNrd2FyZHMtY29tcGF0aWJs ZSBjaGFuZ2VzIGRvZXMgbm90IHJlcXVpcmUgdGhhdCBldmVyeW9uZSB1c2VzIHRoZW0gLSBJRVRG IGNvdWxkIGNvbnRpbnVlIHRvIGFsd2F5cyBwdWJsaXNoIGJhY2t3YXJkcyBjb21wYXRpYmxlIG1v ZHVsZXMuICBUaGUgb2J2aW91cyBhbHRlcm5hdGl2ZSBoZXJlIGlzIHRoYXQgZWFjaCB2ZW5kb3Ig Y29tZXMgdXAgd2l0aCB0aGVpciBvd24gdmVyc2lvbmluZyBleHRlbnNpb24gYW5kIGlnbm9yZXMg dGhlIFJGQyA3OTUwIHNlY3Rpb24gMTEgcnVsZXMgYW55d2F5LCBidXQgSSdtIG5vdCBzdXJlIGhv dyB0aGF0IHJlYWxseSBoZWxwcyBjbGllbnQ8LT5zZXJ2ZXIgaW50ZXJvcC4NCg0KDQpJIGRvIG5v dCBzdXBwb3J0IGJyYW5jaGluZyBmb3IgWUFORyBtb2RlbHMgc28gSSBkbyBub3Qgc3VwcG9ydGVk IG1vZGlmaWVkIFNFTVZFUi4NCkFkZGluZyBhIHNwZWNpYWwgY2hhcmFjdGVyIHRvIHRoZSB2ZXJz aW9uIHN0cmluZyBkb2Vzbid0IGhlbHAgdGhlIGRlcGxveWVkIGNsaWVudCBjb2RlDQp0aGF0IHN0 b3BzIHdvcmtpbmcgd2hlbiB0aGUgc2VydmVyIGNvZGUgaXMgdXBncmFkZWQuICBUaGlzIGlzIGEg cXVhbGl0eSBpc3N1ZSB0aGF0DQplYWNoIG9yZ2FuaXphdGlvbiBoYXMgdG8gZGVhbCB3aXRoIHRo ZSBiZXN0IHRoZXkgY2FuLg0KDQpJIGRvIG5vdCBvYmplY3QgdG8gdGhlIGFkZGl0aW9uIG9mIGEg U0VNVkVSIGZpZWxkIHRvIGEgWUFORyBtb2R1bGUgYmVjYXVzZSB0aGVzZSB2ZXJzaW9uDQpzdHJp bmdzIGFyZSBmYW1pbGlhciB0byB1c2Vycy4gIEl0IGlzIHBvc3NpYmxlIHRvIGV4cHJlc3MgaW1w b3J0IHJhbmdlcyBzdWNoIGFzIDEuMi4qIChhbnkgMS4yLnggcmVsZWFzZSkNCndoaWNoIGFyZSBu b3QgcG9zc2libGUgd2l0aCBkYXRlIHN0cmluZ3MuDQoNCg0KMikgSSBkb24ndCB1bmRlcnN0YW5k IGhvdyB0aGUgUkZDIDc5NTAgYXBwcm9hY2ggb2YgImRlcHJlY2F0ZSBhIGJ1Z2d5IG5vZGUsIGFu ZCByZXBsYWNlIHdpdGggYSB3b3JraW5nIG5vZGUiIHJlYWxseSB3b3JrcyBpbiBwcmFjdGljZSwg cGFydGljdWxhcmx5IGZvciBjb25maWd1cmF0aW9uIGRhdGEgbm9kZXMgd2hlcmUgeW91IGhhdmUg dHdvIGNsaWVudHMgaW50ZXJhY3Rpbmcgd2l0aCBhIHNlcnZlciwgb25lIGludGVyYWN0aW5nIHdp dGggdGhlIG9sZCBwYXRoLCBhbmQgYW5vdGhlciB1c2luZyB0aGUgbmV3IHBhdGguICBQZXJoYXBz IHRoZXJlIGlzIGEgcm9idXN0IHNjaGVtZSB0aGF0IHdvcmtzIGluIGFsbCBjYXNlcywgYnV0IGl0 IGlzbid0IG9idmlvdXMgdG8gbWUuICBIaXN0b3JpY2FsbHksIGZvciBDTEkgd2UganVzdCB0cmFu c2xhdGUgdGhlIENMSSBmcm9tIG9sZCB0byBuZXcgZm9ybWF0IGFuZCB0aGVuIHJldHVybiB0aGUg bmV3IGZvcm1hdCB3aGVuIHRoZSBydW5uaW5nIGNvbmZpZyBpcyByZXF1ZXN0ZWQuICBCdXQgdGhh dCB3aWxsIHN0aWxsIGJyZWFrIGFuIG9sZCBjbGllbnQgdGhhdCBkb2Vzbid0IHVuZGVyc3RhbmQg aG93IHRvIHJlYWQgdGhlIG5ldyBDTEksIGV2ZW4gaWYgdGhlIHNlcnZlciBzdXBwb3J0cyB0aGVt IHdyaXRpbmcgdmlhIHRoZSBvbGQgQ0xJLg0KDQpTRU1WRVIgZG9lcyBub3QgcmVkdWNlIHRoZSBu dW1iZXIgb2YgcGF0aHMgdG8gdGhlIHVuZGVybHlpbmcgY29uZmlndXJhdGlvbiBvYmplY3QuDQpU aGF0IHByb2JsZW0gZG9lcyBub3QgY2hhbmdlIHdoZXRoZXIgYSBuZXcgWFBhdGggYWJzb2x1dGUt cGF0aC1leHByIGlzIHVzZWQNCm9yIHdoZXRoZXIgdGhlIHNhbWUgcGF0aCBpcyBvdmVybG9hZGVk IHdpdGggc2VtYW50aWNzIGRlcml2ZWQgZnJvbSBhZGRpdGlvbmFsIHByb3RvY29sIHBhcmFtZXRl cnMNCihlLmcuLCB2ZXJzaW9uaW5nIG9mIGVhY2ggZGF0YSBub2RlKS4gSSBwcmVmZXIgdGhlIGV4 aXN0aW5nIFhQYXRoIHNvbHV0aW9uIGJlY2F1c2UgaXQgaXMgZXhwbGljaXQNCnNvIHRoZSBZQU5H IHJlYWRlciBjYW4gZWFzaWx5IHNlZSB0aGUgbXVsdGlwbGUgcGF0aHMsIGFuZCBubyBuZXcgcHJv dG9jb2wgd29yayBuZWVkZWQgdG8gc3VwcG9ydCBpdC4NCklmIHRoZXJlIGlzIGFuIE5CQyBjaGFu Z2UgdG8gYW4gb2JqZWN0IHRoZW4gYWxsIFhQYXRoIGFuZCBsZWFmcmVmIHJlZmVyZW5jZXMgdG8g aXQgd2lsbCBwcm9iYWJseSBicmVhay4NClRoYXQgc2VlbXMgbGlrZSBhIGhhcmRlciBwcm9ibGVt IHRvIHNvbHZlIHRoYW4gdGhlIG9yaWdpbmFsIHBhdGggZHVwbGljYXRpb24gcHJvYmxlbS4NCg0K DQpFdmVuIGlmIHRoZXJlIGlzIGEgd29ya2FibGUgc29sdXRpb24gZm9yIHRoaXMgc2ltcGxlIGNh c2UsIEkgc3VzcGVjdCB0aGF0IHRoZXJlIGFyZSBtYW55IHNsaWdodGx5IG1vcmUgY29tcGxpY2F0 ZWQgY2FzZXMgdGhhdCBkb24ndCB3b3JrIChlLmcuIHJla2V5aW5nIGEgbGlzdCwgY2hhbmdpbmcg ZGVmYXVsdHMsIGluY29tcGF0aWJsZSB0eXBlcykuDQoNCkluIHNob3J0LCBJIGRvbid0IGFncmVl IHdpdGggdGhlIHByZW1pc2UgdGhhdCB0aGUgY3VycmVudCBZQU5HIHZlcnNpb25pbmcgc2NoZW1h IHVzaW5nIHJldmlzaW9uIGRhdGVzIGlzIHdvcmtpbmcganVzdCBmaW5lLCBhbmQgbm8gY2hhbmdl cyBhcmUgbmVlZGVkLg0KDQpUaGFua3MsDQpSb2INCg0KQW5keQ0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNYXJ0aW4gQmpvcmtsdW5k DQpTZW50OiAxOSBNYXJjaCAyMDE5IDE1OjEyDQpUbzoga2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFp bHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+DQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gYWRvcHRpb24gcG9sbCBmb3Ig eWFuZy12ZXJzaW9uaW5nLXJlcXMtMDINCg0KSGksDQoNCkkgaGF2ZSByZWFkIHRoaXMgZG9jdW1l bnQsIGFuZCBJIGRvIG5vdCB0aGluayBpdCBzaG91bGQgYmUgYWRvcHRlZC4NCg0KSSBvYmplY3Qg dG8gdGhlIGlkZWEgdGhhdCB3ZSBzaG91bGQgYWxsb3cgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxl IGNoYW5nZXMgdG8gcHVibGlzaGVkIFlBTkcgbW9kdWxlcy4NCg0KVGhlIGRyYWZ0IG1vdGl2YXRl cyB0aGlzIGlkZWEgd2l0aDoNCg0KICAgd2UgbXVzdCByZWNvZ25pemUgdGhhdCBtYW55IFlBTkcN CiAgIG1vZHVsZXMgYXJlIGFjdHVhbGx5IGdlbmVyYXRlZCBZQU5HIG1vZHVsZXMgKGZvciBleGFt cGxlLCBmcm9tDQogICBpbnRlcm5hbCBkYXRhYmFzZXMpDQoNCkkgZG8gbm90IGFncmVlIHRoYXQg d2Ugc2hvdWxkIGNoYW5nZSB3aGF0IHdlIGFsbG93IGluIHB1Ymxpc2hlZCBtb2R1bGVzIGIvYyBv ZiB0aGlzLg0KDQpJdCBhbHNvIG1vdGl2YXRlcyB0aGlzIGlkZWEgd2l0aDoNCg0KICAgVGhlIHBv aW50cyBtYWRlIGFib3ZlIGxlYWQgdG8gdGhlIGxvZ2ljYWwgY29uY2x1c2lvbiB0aGF0IHRoZQ0K ICAgc3RhbmRhcmRpemVkIFlBTkcgbW9kdWxlcyBoYXZlIHRvIGJlIHBlcmZlY3Qgb24gZGF5IG9u ZSAoYXQgbGVhc3QgdGhlDQogICBzdHJ1Y3R1cmUgYW5kIG1lYW5pbmcpLCB3aGljaCBpbiB0dXJu IG1pZ2h0IGV4cGxhaW4gd2h5IElFVEYgWUFORw0KICAgbW9kdWxlcyB0YWtlIHNvIGxvbmcgdG8g c3RhbmRhcmRpemUuDQoNCkkgZGlzYWdyZWUgd2l0aCB0aGlzLiAgRmlyc3Qgb2YgYWxsLCB3ZSBo YXZlIGFscmVhZHkgcHVibGlzaGVkIHJldmlzaW9uIHR3byBvZiBzZXZlcmFsIFlBTkcgbW9kdWxl cyAoaWV0Zi1pbmV0LXR5cGVzLCBpZXRmLXlhbmctdHlwZSwgaWV0Zi1pbnRlcmZhY2VzLCBpZXRm LWlwLCBpZXRmLXJvdXRpbmcsIC4uLiksIHNvIHRoZSBzdGF0ZW1lbnQgdGhhdCAic3RhbmRhcmRp emVkIFlBTkcgbW9kdWxlcyBoYXZlIHRvIGJlIHBlcmZlY3Qgb24gZGF5IG9uZSIgaXMgc2ltcGx5 IG5vdCB0cnVlLg0KDQpTZWNvbmQsIEkgZG9uJ3QgdGhpbmsgdGhlIHVwZ3JhZGUgcnVsZXMgYXJl IHRoZSByZWFzb24gaXQgdGFrZXMgYSBsb25nIHRpbWUgdG8gc3RhbmRhcmRpemUgSUVURiBtb2Rl bHMgKEkgdGhpbmsgaXQgaGFzIHRvIGRvIHdpdGggdGhlIHByb2Nlc3MgaXRzZWxmLCBpbmNsdWRp bmcgdGhlIGZhY3QgdGhhdCBtb2RlbHMgZ2V0IHJldmlld3MgZnJvbSBtYW55IGRpZmZlcmVudCBw ZW9wbGUgd2l0aCBkaWZmZXJlbnQgYmFja2dyb3VuZC4pICBbQlRXLCBpcyBpdCB0cnVlIHRoYXQg ZHJhZnRzIHdpdGggWUFORyBtb2RlbHMgdGFrZSBsb25nZXIgdGltZSBmcm9tIHdnIC0wMCB0byBw dWJsaXNoZWQgUkZDIHRoYW4gb3RoZXIgZHJhZnRzP10NCg0KDQpUaGlzIHNhaWQsIEkgdGhpbmsg dGhlcmUgYXJlIHNvbWUgaW1wb3J0YW50IHBvaW50cyB0aGF0IHRoZSBkcmFmdCByYWlzZXMsIGFu ZCB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnRpbnVlIHRvIHdvcmsgb247IHNwZWNpZmljYWxs eSAyLjMsIDIuNSwgMi42LCAyLjcuICBCdXQgSSBkb24ndCB0aGluayB0aGF0IHRoZXNlIGFyZWFz IHJlcXVpcmUgY2hhbmdlcyB0byB0aGUgdmVyc2lvbmluZyBzY2hlbWUsIGFuZCBJIHRoaW5rIGl0 IGlzIGEgbWlzdGFrZSB0byBpbmNsdWRlIHRoZXNlIGFyZWFzIGluIHRoaXMgZHJhZnQuDQoNClNv bWUgY29tbWVudHMgb24gc2VjdGlvbiA0LCBUaGUgUHJvYmxlbSBTdGF0ZW1lbnQ6DQoNCiAgIG8g IEFueSBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlIG9mIGEgZGVmaW5pdGlvbiByZXF1 aXJlcw0KICAgICAgZWl0aGVyIGEgbmV3IG1vZHVsZSBuYW1lIG9yIGEgbmV3IHBhdGguICBUaGlz IGhhcyBiZWVuIGZvdW5kDQogICAgICBjb3N0bHkgdG8gc3VwcG9ydCBpbiBpbXBsZW1lbnRhdGlv bnMsIGluIHBhcnRpY3VsYXIgb24gdGhlIGNsaWVudA0KICAgICAgc2lkZS4NCg0KWWVzIEkgYWdy ZWUgdGhlcmUgaXMgYSBjb3N0IGFzc29jaWF0ZWQgd2l0aCB0aGlzLiAgQnV0IEkgaGF2ZSBjb21l IGFjcm9zcyB2ZW5kb3IgbW9kdWxlcyB0aGF0IG1ha2UgTkJDIGNoYW5nZXMgdy9vIGludHJvZHVj aW5nIGEgbmV3IHBhdGgsIGFuZCB0aGlzIGlzIGFsc28gY29zdGx5IHRvIGhhbmRsZS4NCg0KICAg byAgU2luY2Ugbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZXMgcmVxdWlyZSBlaXRoZXIg YSBuZXcgbW9kdWxlDQogICAgICBuYW1lIG9yIGEgbmV3IHBhdGgsIHN1Y2ggY2hhbmdlcyB3aWxs IGltcGFjdCBvdGhlciBtb2R1bGVzIHRoYXQNCiAgICAgIGltcG9ydCBkZWZpbml0aW9ucy4gIElu IGZhY3QsIHdpdGggdGhlIGN1cnJlbnQgbW9kdWxlIHZlcnNpb25pbmcNCiAgICAgIHNjaGVtZSBv dGhlciBtb2R1bGVzIGhhdmUgdG8gb3B0LWluIGluIG9yZGVyIHRvIHVzZSB0aGUgbmV3DQogICAg ICB2ZXJzaW9uLiAgVGhpcyBlc3NlbnRpYWxseSBsZWFkcyB0byBhIHJpcHBsZSBlZmZlY3Qgd2hl cmUgYSBub24tDQogICAgICBiYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2Ugb2YgYSBjb3JlIG1v ZHVsZSBjYXVzZXMgdXBkYXRlcyBvbiBhDQogICAgICBwb3RlbnRpYWxseSBsYXJnZSBudW1iZXIg b2YgZGVwZW5kZW50IG1vZHVsZXMuDQoNClRoaXMgaXMgYnkgZGVzaWduLiAgV2UgY2Fubm90IGhh dmUgYSBzaXR1YXRpb24gd2hlcmUgYSBsZWdhbCBtb2RpZmljYXRpb24gdG8gYSBtb2R1bGUgbGVh ZHMgdG8gb3RoZXIgbW9kdWxlcyBiZWNvbWluZyBpbnZhbGlkLg0KDQogICBvICBZQU5HIGhhcyBh IG1lY2hhbmlzbSB0byBtYXJrIGRlZmluaXRpb25zIGRlcHJlY2F0ZWQgYnV0IGl0IGxlYXZlcw0K ICAgICAgaXQgb3BlbiB3aGV0aGVyIGltcGxlbWVudGF0aW9ucyBhcmUgZXhwZWN0ZWQgdG8gaW1w bGVtZW50DQogICAgICBkZXByZWNhdGVkIGRlZmluaXRpb25zIGFuZCB0aGVyZSBpcyBubyB3YXkg KG90aGVyIHRoYW4gdHJpYWwgYW5kDQogICAgICBlcnJvcikgZm9yIGEgY2xpZW50IHRvIGZpbmQg b3V0IHdoZXRoZXIgZGVwcmVjYXRlZCBkZWZpbml0aW9ucyBhcmUNCiAgICAgIHN1cHBvcnRlZCBi eSBhIGdpdmVuIGltcGxlbWVudGF0aW9uLg0KDQpBcyBJIHdyb3RlIGFib3ZlLCBJIGFncmVlIHRo YXQgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCBzaG91bGQgYmUgc29sdmVkLiAgQnV0IHRoaXMgaXMg bm90IGEgbW90aXZhdGlvbiBmb3IgY2hhbmdpbmcgWUFORyB2ZXJzaW9uaW5nLg0KDQogICBvICBZ QU5HIGRvZXMgbm90IGhhdmUgYSByb2J1c3QgbWVjaGFuaXNtIHRvIGRvY3VtZW50IHdoaWNoIGRh dGENCiAgICAgIGRlZmluaXRpb25zIGhhdmUgY2hhbmdlZCBhbmQgdG8gcHJvdmlkZSBndWlkYW5j ZSBob3cNCiAgICAgIGltcGxlbWVudGF0aW9ucyBzaG91bGQgZGVhbCB3aXRoIHRoZSBjaGFuZ2Uu ICBXaGlsZSBpdCBpcyBwb3NzaWJsZQ0KICAgICAgdG8gaGF2ZSB0aGlzIGRlc2NyaWJlZCBpbiBn ZW5lcmFsIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMsIGhhdmluZw0KICAgICAgdGhlc2UgZGV0YWls cyBlbWJlZGRlZCBpbiBnZW5lcmFsIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgZG9lcyBub3QNCiAg ICAgIG1ha2UgdGhpcyBpbmZvcm1hdGlvbiBhY2Nlc3NpYmxlIHRvIHRvb2xzLg0KDQpUaGlzIG1p Z2h0IGFsc28gYmUgd29ydGggZXhwbG9yaW5nLCBidXQgdGhpcyBpcyBub3QgYSBtb3RpdmF0aW9u IGZvciBjaGFuZ2luZyBZQU5HIHZlcnNpb25pbmcuDQoNCg0KDQovbWFydGluDQoNCg0KDQpLZW50 IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5u ZXQ+PiB3cm90ZToNCj4gU2VlaW5nIGFzIGhvdyB3ZSBhbGwgbmVlZCB0byByZWFkIHRoaXMgZHJh ZnQgYW55d2F5cywgaW4gcHJlcGFyYXRpb24gZm9yIG91ciBtZWV0aW5nIGluIFByYWd1ZSwgaXQg c2VlbXMgbGlrZSBhIGdvb2QgdGltZSBmb3IgdGhpcyBwb2xsLiAgVGh1c2x5LCB0aGlzIGVtYWls IGJlZ2lucyBhIDEtd2VlayBhZG9wdGlvbiBwb2xsIGZvcjoNCj4NCj4NCj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNpb25pbmctcmVxcy0w Mg0KPiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5n LXZlcnNpb25pbmctcmVxcy0wDQo+IDI+DQo+DQo+IFBsZWFzZSB2b2ljZSB5b3VyIHN1cHBvcnQg b3Igb2JqZWN0aW9ucyBiZWZvcmUgTWFyY2ggMjAuDQo+DQo+IE5vdGUgdGhhdCB0aGlzIGRyYWZ0 IGRlZmluZXMgKnJlcXVpcmVtZW50cyogYW5kIGl0cyBpbnRlbmRlZCBzdGF0dXMgaXMgIkluZm9y bWF0aW9uYWwuIiAgIEkgYmVsaWV2ZSB0aGF0IGl0IGlzIGdvb2QgZm9yIFdHcyB0byBmb3JtYWxp emUgcmVxdWlyZW1lbnRzLCBldmVuIHRha2luZyBzdWNoIGRyYWZ0cyB0aHJ1IExhc3QgQ2FsbCwg aW4gb3JkZXIgdG8gZW5zdXJlIGNvbnNlbnN1cyBvbiB0aGUgcmVxdWlyZW1lbnRzLiAgVGhpcyBp cyB0aGUgImFkb3B0aW9uIiBjYWxsLCB0byBhc2NlcnRhaW4gaWYgdGhlIFdHIGFncmVlcyB3aXRo IHRoYXQgc3RhdGVtZW50OyBpZiBhZG9wdGVkLCBhIHNlcGFyYXRlICJsYXN0IGNhbGwiIHdpbGwg YmUgaXNzdWVkIHRvIGVuc3VyZSB0byBjb3JyZWN0bmVzcyBvZiB0aGUgZHJhZnQncyBjb250ZW50 Lg0KPg0KPiBLZW50IChhbmQgTG91IGFuZCBKb2VsKQ0KPg0KPg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0K --_000_8871415dce7343a28afa25faf6080d8cXCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+MS4gUmVndWxhciBTZW12ZXIgMi4wLjAgKGFz IHBlciBzZW12ZXIub3JnKSBhbGxvd3Mgc29tZSBicmFuY2hpbmcuJm5ic3A7IEkuZS4geW91IGNh biBjcmVhdGUgdmVyc2lvbiAyLjAuMCBiYXNlZCBvZiB2ZXJzaW9uIDEuMS4wLCBhbmQgdGhlbg0K IHN1YnNlcXVlbnRseSBjcmVhdGUgdmVyc2lvbiAxLjIuMCBiYXNlZCBvZiAxLjEuMC4mbmJzcDsg U28gc3RydWN0dXJlIHdpc2UgdGhpcyB3b3VsZCBsb2dpY2FsbHkgbG9vayBsaWtlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IDEuMC4wPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IFwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7ICZuYnNw OzEuMS4wIOKAkyAxLjIuMCAtIOKApg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IDIuMC4w PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JIGFsc28gcmFpc2VkDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vc2VtdmVyL3Nl bXZlci9pc3N1ZXMvNTA0Ij5odHRwczovL2dpdGh1Yi5jb20vc2VtdmVyL3NlbXZlci9pc3N1ZXMv NTA0PC9hPiZuYnNwOyBvbiB0aGUgc2VtdmVyIDIuMC4wIGdpdGh1YiB0byBjb25maXJtIHRoYXQg bXkgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdCwgYW5kIG5vIG9uZSBoYXMgZGlzcHV0ZWQgaXQg eWV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjIuIFZlbmRvciBzb2Z0d2Fy ZSByZWxlYXNlcyBjYW4gaGF2ZSBhIHZlcnkgbG9uZyBzdXBwb3J0IHRpbWUgKGUuZy4gZWFzaWx5 IDUmIzQzOyB5ZWFycyksIHdpdGggYW4gZXhwZWN0YXRpb24gdGhhdCBidWdzIGdldCBmaXhlZC4m bmJzcDsgUmVxdWlyaW5nDQogdGhhdCBjdXN0b21lcnMgdXBncmFkZSB0aGVpciBzb2Z0d2FyZSAo b3IgcGVyaGFwcyBoYXJkd2FyZSkgdG8gdGhlIHZlcnkgbGF0ZXN0IHNvZnR3YXJlIHZlcnNpb24g dG8gcGljayB1cCBhIHNtYWxsIGJ1ZyBmaXggaXMgbm90IHJlYWxpc3RpYy4mbmJzcDsgVGhpcyBp cyBwcmltYXJpbHkgd2h5IEkgdGhpbmsgdGhhdCB0aGUg4oCYbeKAmSBhbmQg4oCYTeKAmSBhcmUg c28gaW1wb3J0YW50LiZuYnNwOyBUaGV5IGFsbG93IGZvciBidWcgZml4ZXMgaW4gYSB3YXkgdGhh dCBTZW12ZXINCiAyLjAuMCBzaW1wbHkgZG9lcyBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5TZW12ZXIgMi4wLjAgb25seSBhbGxvd3MgZm9yIGJ1Z2ZpeGVzIGlu IHRoZSBpbXBsZW1lbnRhdGlvbiAoYnkgdXBkYXRpbmcgdGhlIHBhdGNoIHZlcnNpb24gbnVtYmVy KSwgYnV0IGhhcyB0aGUgZXhwZWN0YXRpb24gdGhhdCB0aGVyZQ0KIGFyZSAqPGI+bmV2ZXI8L2I+ KiBhbnkgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZXMgaW4gdGhlIEFQSSwgbm90IGV2 ZW4gdG8gZml4IGEgYnVnLCBleGNlcHQgYXQgdGhlIHRpcCBvZiB0aGUgZGV2ZWxvcG1lbnQgdHJl ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIHNob3J0LCBJIHRo aW5rIHRoYXQgdmFuaWxsYSBTZW12ZXIgMi4wLjAgaXMgYSBnb29kIGZpdCBmb3Igb3BlbiBzb3Vy Y2UgcHJvamVjdHMgd2hlcmUgeW91IGNhbiBqdXN0IHRlbGwgdGhlIGNsaWVudCB0byB1cGRhdGUg dG8NCiB0aGUgbGF0ZXN0IHZlcnNpb24gdG8gcGljayB1cCB0aGUgZml4LiZuYnNwOyBJIGRvbuKA mXQgdGhpbmsgdGhhdCBTZW12ZXIgMi4wLjAgaXMgc28gd2VsbCBhbGlnbmVkIHRvIEFQSXMgdGhh dCBhcmUgcmVxdWlyZWQgdG8gYmUgbWFpbnRhaW5lZCBmb3IgbG9uZyBwZXJpb2RzIG9mIHRpbWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgYWx0ZXJuYXRpdmUg dGhhdCBSb2IgU2hha2lyIG1lbnRpb25lZCBhdCBJRVRGIDEwMyBpbiB0aGUgY29udGV4dCBvZiBP cGVuQ29uZmlnLCB3aGljaCB1c2VzIHN0cmljdCBTZW12ZXIgMi4wLjAsIGlzIHRvIGhhbmRsZSB0 aGVzZQ0KIGJ1ZyBmaXhlcyB1c2luZyBkZXZpYXRpb25zLiZuYnNwOyBCdXQgaXQgc2VlbXMgdG8g YmUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXggdG8gbWFuYWdlIGJ1ZyBmaXhlcyB1c2luZyBl eHRyYSBkZXZpYXRpb24gbW9kdWxlcyByYXRoZXIgdGhhbiBhbGxvd2luZyB0aGUg4oCYbeKAmSB8 IOKAmE3igJkgbW9kaWZpZXJzLiZuYnNwOyBWZXJzaW9uaW5nIHdvdWxkIG5vIGxvbmdlciBsaW1p dGVkIHRvIGEgbW9kdWxlIHZlcnNpb24gbnVtYmVyLCBidXQgcmVxdWlyZSBrbm93bGVkZ2UNCiBv ZiB0aGUgbW9kdWxlIHZlcnNpb24gYW5kIHNldCBvZiBkZXZpYXRpb25zIHRoYXQgYXJlIGFwcGxp ZWQgdG8gaXQuJm5ic3A7IEkgd291bGQgcmF0aGVyIGRldmlhdGlvbnMgYXJlIHJlc2VydmVkIHRv IGluZGljYXRlIHdoZXRoZXIgYW4gaW1wbGVtZW50YXRpb24gZG9lc27igJl0IG1hdGNoIHRoZSBt b2R1bGUgc3BlY2lmaWNhdGlvbiByYXRoZXIgdGhhbiB1c2UgdGhlbSBhcyBhIHdheSBvZiBmaXhp bmcgYnVncyBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+My4gSSBhZ3JlZSB0aGF0IHRoZSB1c2Ugb2YgU2VtdmVyICYjNDM7IHBh Y2thZ2VzICYjNDM7IHZlcnNpb24gc2VsZWN0aW9uIGRvZXMgbm90IHJlZHVjZSB0aGUgb3ZlcmFs bCBudW1iZXIgb2YgcGF0aHMgdG8gYSBjb25maWd1cmFibGUgcHJvcGVydHksDQogYnV0IGl0IGRv ZXMgZW5zdXJlIHRoYXQgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBwYXRoIHRvIGEgY29uZmlndXJh YmxlIHByb3BlcnR5IHdpdGhpbiBhIFlBTkcgZGF0YXN0b3JlIHNjaGVtYS4gJm5ic3A7Jm5ic3A7 U28gd2hpY2hldmVyIHZlcnNpb24gZWFjaCBjbGllbnQgaXMgdXNpbmcsIHRoZXkgb25seSB1c2Ug YSBzaW5nbGUgcGF0aC4mbmJzcDsgSS5lLiBtaXJyb3JpbmcgdGhlIHdheSB0aGF0IGEgY2xhc3Np YyBwcm9ncmFtbWluZyBBUEkgbWlnaHQgYmUgdmVyc2lvbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VydmVycyB0aGF0IHdpc2ggdG8gc3VwcG9ydCB0aGlzIHdv dWxkIGhhdmUgdG8gbWFwIHRoZSBkYXRhIGJldHdlZW4gZGlmZmVyZW50IFlBTkcgZGF0YXN0b3Jl IHNjaGVtYSB2ZXJzaW9ucy4mbmJzcDsgTm90IGFsbCBtYXBwaW5ncyBhcmUNCiBwb3NzaWJsZSwg YnV0IGF0IGxlYXN0IGFueSBjYXNlcyB3aGVyZSBpdCBpcyBub3QgcG9zc2libGUgY2FuIGJlIGRl dGVjdGVkIGFuZCByZXBvcnRlZCB0byB0aGUgY2xpZW50IHZpYSBhbiBvdXQgb2YgYmFuZCBtZWNo YW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JZiB0aGUgbW9k dWxlIGNvbnRlbnQgY2hhbmdlcyBzaWduaWZpY2FudGx5IGJldHdlZW4gbW9kdWxlIHZlcnNpb25z IHRoYXQgbWFwcGluZyB3aWxsIGJlIG11Y2ggaGFyZGVyIHRoYW4gaWYgdGhlIGNoYW5nZXMgYXJl IG1pbmltYWwNCiBvciBiYWNrd2FyZHMgY29tcGF0aWJsZS4mbmJzcDsgU28gdGhlcmUgaXMgc3Rp bGwgYSBzdHJvbmcgaW5jZW50aXZlIGZvciBtb2RlbCB3cml0ZXJzIHRvIG1pbmltaXplIGNodXJu IHRvIHRoZSBZQU5HIG1vZGVscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNv bSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxOSBNYXJjaCAyMDE5IDE4OjM1PGJyPg0KPGI+VG86 PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBNYXJ0aW4gQmpvcmtsdW5kICZsdDttYmpAdGFpbC1mLmNvbSZndDs7IGtlbnQm IzQzO2lldGZAd2F0c2VuLm5ldDsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbbmV0bW9kXSBhZG9wdGlvbiBwb2xsIGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUdWUsIE1hciAxOSwgMjAxOSBhdCA5OjM4IEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8 YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5IaSBNYXJ0aW4sPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB0aGUg cmV2aWV3IGFuZCBjb21tZW50cy48YnI+DQo8YnI+DQpBIGNvdXBsZSBvZiBwb2ludHM6PGJyPg0K PGJyPg0KMSkgTG90cyBvZiBtb2RlbHMgb3V0c2lkZSB0aG9zZSBwdWJsaXNoZWQgaW4gU0RPcyBh cmUgYWxyZWFkeSBub3QgZm9sbG93aW5nIHRoZSBSRkMgNzk1MCByZXZpc2lvbiBydWxlcy4mbmJz cDsgSSB0aGluayB0aGF0IGl0IGlzIGJldHRlciB0byBoYXZlIGEgdmVyc2lvbmluZyBzY2hlbWUg dGhhdCByZWZsZWN0cyBob3cgWUFORyBtb2RlbHMgYXJlIGFjdHVhbGx5IGV2b2x2aW5nIHJhdGhl ciB0aGFuIGhhdmUgYWxsIHZlbmRvciBhbmQgT0MgWUFORyBtb2R1bGVzDQogZWl0aGVyIGp1c3Qg aWdub3JpbmcgdGhlIHJ1bGVzLCBvciB1c2luZyBjbGV2ZXIgdHJpY2tzIHRoYXQgc3RyaWN0bHkg Y29uZm9ybSB3aXRoIHRoZSBydWxlcyBidXQgZ28gYWdhaW5zdCB0aGUgc3Bpcml0IG9mIHRoZW0g KGUuZy4ganVzdCBwdWJsaXNoIGFuIGVudGlyZWx5IG5ldyBzZXQgb2YgWUFORyBtb2R1bGVzIGZv ciBlYWNoIHJlbGVhc2UpLiZuYnNwOyBBbHNvIG5vdGluZyB0aGF0IGhhdmluZyBhIHNjaGVtZSB0 aGF0IGFsbG93cyBub24tYmFja3dhcmRzLWNvbXBhdGlibGUNCiBjaGFuZ2VzIGRvZXMgbm90IHJl cXVpcmUgdGhhdCBldmVyeW9uZSB1c2VzIHRoZW0gLSBJRVRGIGNvdWxkIGNvbnRpbnVlIHRvIGFs d2F5cyBwdWJsaXNoIGJhY2t3YXJkcyBjb21wYXRpYmxlIG1vZHVsZXMuJm5ic3A7IFRoZSBvYnZp b3VzIGFsdGVybmF0aXZlIGhlcmUgaXMgdGhhdCBlYWNoIHZlbmRvciBjb21lcyB1cCB3aXRoIHRo ZWlyIG93biB2ZXJzaW9uaW5nIGV4dGVuc2lvbiBhbmQgaWdub3JlcyB0aGUgUkZDIDc5NTAgc2Vj dGlvbiAxMSBydWxlcw0KIGFueXdheSwgYnV0IEknbSBub3Qgc3VyZSBob3cgdGhhdCByZWFsbHkg aGVscHMgY2xpZW50Jmx0Oy0mZ3Q7c2VydmVyIGludGVyb3AuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHN1cHBv cnQgYnJhbmNoaW5nIGZvciBZQU5HIG1vZGVscyBzbyBJIGRvIG5vdCBzdXBwb3J0ZWQgbW9kaWZp ZWQgU0VNVkVSLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWRkaW5nIGEgc3BlY2lhbCBjaGFyYWN0ZXIgdG8gdGhlIHZlcnNpb24gc3RyaW5nIGRv ZXNuJ3QgaGVscCB0aGUgZGVwbG95ZWQgY2xpZW50IGNvZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgc3RvcHMgd29ya2luZyB3aGVuIHRo ZSBzZXJ2ZXIgY29kZSBpcyB1cGdyYWRlZC4mbmJzcDsgVGhpcyBpcyBhIHF1YWxpdHkgaXNzdWUg dGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZWFjaCBvcmdhbml6YXRpb24gaGFzIHRvIGRlYWwgd2l0aCB0aGUgYmVzdCB0aGV5IGNhbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBu b3Qgb2JqZWN0IHRvIHRoZSBhZGRpdGlvbiBvZiBhIFNFTVZFUiBmaWVsZCB0byBhIFlBTkcgbW9k dWxlIGJlY2F1c2UgdGhlc2UgdmVyc2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+c3RyaW5ncyBhcmUgZmFtaWxpYXIgdG8gdXNlcnMuJm5ic3A7 IEl0IGlzIHBvc3NpYmxlIHRvIGV4cHJlc3MgaW1wb3J0IHJhbmdlcyBzdWNoIGFzIDEuMi4qIChh bnkgMS4yLnggcmVsZWFzZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndoaWNoIGFyZSBub3QgcG9zc2libGUgd2l0aCBkYXRlIHN0cmluZ3MuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+MikgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGUgUkZDIDc5NTAgYXBwcm9h Y2ggb2YgJnF1b3Q7ZGVwcmVjYXRlIGEgYnVnZ3kgbm9kZSwgYW5kIHJlcGxhY2Ugd2l0aCBhIHdv cmtpbmcgbm9kZSZxdW90OyByZWFsbHkgd29ya3MgaW4gcHJhY3RpY2UsIHBhcnRpY3VsYXJseSBm b3IgY29uZmlndXJhdGlvbiBkYXRhIG5vZGVzIHdoZXJlIHlvdSBoYXZlIHR3byBjbGllbnRzIGlu dGVyYWN0aW5nDQogd2l0aCBhIHNlcnZlciwgb25lIGludGVyYWN0aW5nIHdpdGggdGhlIG9sZCBw YXRoLCBhbmQgYW5vdGhlciB1c2luZyB0aGUgbmV3IHBhdGguJm5ic3A7IFBlcmhhcHMgdGhlcmUg aXMgYSByb2J1c3Qgc2NoZW1lIHRoYXQgd29ya3MgaW4gYWxsIGNhc2VzLCBidXQgaXQgaXNuJ3Qg b2J2aW91cyB0byBtZS4mbmJzcDsgSGlzdG9yaWNhbGx5LCBmb3IgQ0xJIHdlIGp1c3QgdHJhbnNs YXRlIHRoZSBDTEkgZnJvbSBvbGQgdG8gbmV3IGZvcm1hdCBhbmQgdGhlbiByZXR1cm4NCiB0aGUg bmV3IGZvcm1hdCB3aGVuIHRoZSBydW5uaW5nIGNvbmZpZyBpcyByZXF1ZXN0ZWQuJm5ic3A7IEJ1 dCB0aGF0IHdpbGwgc3RpbGwgYnJlYWsgYW4gb2xkIGNsaWVudCB0aGF0IGRvZXNuJ3QgdW5kZXJz dGFuZCBob3cgdG8gcmVhZCB0aGUgbmV3IENMSSwgZXZlbiBpZiB0aGUgc2VydmVyIHN1cHBvcnRz IHRoZW0gd3JpdGluZyB2aWEgdGhlIG9sZCBDTEkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TRU1WRVIgZG9lcyBub3QgcmVkdWNl IHRoZSBudW1iZXIgb2YgcGF0aHMgdG8gdGhlIHVuZGVybHlpbmcgY29uZmlndXJhdGlvbiBvYmpl Y3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGF0IHByb2JsZW0gZG9lcyBub3QgY2hhbmdlIHdoZXRoZXIgYSBuZXcgWFBhdGggYWJzb2x1dGUt cGF0aC1leHByIGlzIHVzZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPm9yIHdoZXRoZXIgdGhlIHNhbWUgcGF0aCBpcyBvdmVybG9hZGVkIHdpdGgg c2VtYW50aWNzIGRlcml2ZWQgZnJvbSBhZGRpdGlvbmFsIHByb3RvY29sIHBhcmFtZXRlcnMmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihl LmcuLCB2ZXJzaW9uaW5nIG9mIGVhY2ggZGF0YSBub2RlKS4gSSBwcmVmZXIgdGhlIGV4aXN0aW5n IFhQYXRoIHNvbHV0aW9uIGJlY2F1c2UgaXQgaXMgZXhwbGljaXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNvIHRoZSBZQU5HIHJlYWRlciBjYW4g ZWFzaWx5IHNlZSB0aGUgbXVsdGlwbGUgcGF0aHMsIGFuZCBubyBuZXcgcHJvdG9jb2wgd29yayBu ZWVkZWQgdG8gc3VwcG9ydCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHRoZXJlIGlzIGFuIE5CQyBjaGFuZ2UgdG8gYW4gb2JqZWN0IHRo ZW4gYWxsIFhQYXRoIGFuZCBsZWFmcmVmIHJlZmVyZW5jZXMgdG8gaXQgd2lsbCBwcm9iYWJseSBi cmVhay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYXQgc2VlbXMgbGlrZSBhIGhhcmRlciBwcm9ibGVtIHRvIHNvbHZlIHRoYW4gdGhlIG9yaWdp bmFsIHBhdGggZHVwbGljYXRpb24gcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5FdmVuIGlmIHRoZXJl IGlzIGEgd29ya2FibGUgc29sdXRpb24gZm9yIHRoaXMgc2ltcGxlIGNhc2UsIEkgc3VzcGVjdCB0 aGF0IHRoZXJlIGFyZSBtYW55IHNsaWdodGx5IG1vcmUgY29tcGxpY2F0ZWQgY2FzZXMgdGhhdCBk b24ndCB3b3JrIChlLmcuIHJla2V5aW5nIGEgbGlzdCwgY2hhbmdpbmcgZGVmYXVsdHMsIGluY29t cGF0aWJsZSB0eXBlcykuPGJyPg0KPGJyPg0KSW4gc2hvcnQsIEkgZG9uJ3QgYWdyZWUgd2l0aCB0 aGUgcHJlbWlzZSB0aGF0IHRoZSBjdXJyZW50IFlBTkcgdmVyc2lvbmluZyBzY2hlbWEgdXNpbmcg cmV2aXNpb24gZGF0ZXMgaXMgd29ya2luZyBqdXN0IGZpbmUsIGFuZCBubyBjaGFuZ2VzIGFyZSBu ZWVkZWQuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQpGcm9tOiBuZXRtb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg T24gQmVoYWxmIE9mIE1hcnRpbiBCam9ya2x1bmQ8YnI+DQpTZW50OiAxOSBNYXJjaCAyMDE5IDE1 OjEyPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0IiB0YXJn ZXQ9Il9ibGFuayI+a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0PC9hPjxicj4NCkNjOiA8YSBocmVm PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3Jn PC9hPjxicj4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhZG9wdGlvbiBwb2xsIGZvciB5YW5nLXZl cnNpb25pbmctcmVxcy0wMjxicj4NCjxicj4NCkhpLDxicj4NCjxicj4NCkkgaGF2ZSByZWFkIHRo aXMgZG9jdW1lbnQsIGFuZCBJIGRvIG5vdCB0aGluayBpdCBzaG91bGQgYmUgYWRvcHRlZC48YnI+ DQo8YnI+DQpJIG9iamVjdCB0byB0aGUgaWRlYSB0aGF0IHdlIHNob3VsZCBhbGxvdyBub24tYmFj a3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlcyB0byBwdWJsaXNoZWQgWUFORyBtb2R1bGVzLjxicj4N Cjxicj4NClRoZSBkcmFmdCBtb3RpdmF0ZXMgdGhpcyBpZGVhIHdpdGg6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO3dlIG11c3QgcmVjb2duaXplIHRoYXQgbWFueSBZQU5HPGJyPg0KJm5ic3A7ICZu YnNwO21vZHVsZXMgYXJlIGFjdHVhbGx5IGdlbmVyYXRlZCBZQU5HIG1vZHVsZXMgKGZvciBleGFt cGxlLCBmcm9tPGJyPg0KJm5ic3A7ICZuYnNwO2ludGVybmFsIGRhdGFiYXNlcyk8YnI+DQo8YnI+ DQpJIGRvIG5vdCBhZ3JlZSB0aGF0IHdlIHNob3VsZCBjaGFuZ2Ugd2hhdCB3ZSBhbGxvdyBpbiBw dWJsaXNoZWQgbW9kdWxlcyBiL2Mgb2YgdGhpcy48YnI+DQo8YnI+DQpJdCBhbHNvIG1vdGl2YXRl cyB0aGlzIGlkZWEgd2l0aDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIHBvaW50cyBtYWRl IGFib3ZlIGxlYWQgdG8gdGhlIGxvZ2ljYWwgY29uY2x1c2lvbiB0aGF0IHRoZTxicj4NCiZuYnNw OyAmbmJzcDtzdGFuZGFyZGl6ZWQgWUFORyBtb2R1bGVzIGhhdmUgdG8gYmUgcGVyZmVjdCBvbiBk YXkgb25lIChhdCBsZWFzdCB0aGU8YnI+DQombmJzcDsgJm5ic3A7c3RydWN0dXJlIGFuZCBtZWFu aW5nKSwgd2hpY2ggaW4gdHVybiBtaWdodCBleHBsYWluIHdoeSBJRVRGIFlBTkc8YnI+DQombmJz cDsgJm5ic3A7bW9kdWxlcyB0YWtlIHNvIGxvbmcgdG8gc3RhbmRhcmRpemUuPGJyPg0KPGJyPg0K SSBkaXNhZ3JlZSB3aXRoIHRoaXMuJm5ic3A7IEZpcnN0IG9mIGFsbCwgd2UgaGF2ZSBhbHJlYWR5 IHB1Ymxpc2hlZCByZXZpc2lvbiB0d28gb2Ygc2V2ZXJhbCBZQU5HIG1vZHVsZXMgKGlldGYtaW5l dC10eXBlcywgaWV0Zi15YW5nLXR5cGUsIGlldGYtaW50ZXJmYWNlcywgaWV0Zi1pcCwgaWV0Zi1y b3V0aW5nLCAuLi4pLCBzbyB0aGUgc3RhdGVtZW50IHRoYXQgJnF1b3Q7c3RhbmRhcmRpemVkIFlB TkcgbW9kdWxlcyBoYXZlIHRvIGJlIHBlcmZlY3Qgb24gZGF5IG9uZSZxdW90Ow0KIGlzIHNpbXBs eSBub3QgdHJ1ZS48YnI+DQo8YnI+DQpTZWNvbmQsIEkgZG9uJ3QgdGhpbmsgdGhlIHVwZ3JhZGUg cnVsZXMgYXJlIHRoZSByZWFzb24gaXQgdGFrZXMgYSBsb25nIHRpbWUgdG8gc3RhbmRhcmRpemUg SUVURiBtb2RlbHMgKEkgdGhpbmsgaXQgaGFzIHRvIGRvIHdpdGggdGhlIHByb2Nlc3MgaXRzZWxm LCBpbmNsdWRpbmcgdGhlIGZhY3QgdGhhdCBtb2RlbHMgZ2V0IHJldmlld3MgZnJvbSBtYW55IGRp ZmZlcmVudCBwZW9wbGUgd2l0aCBkaWZmZXJlbnQgYmFja2dyb3VuZC4pJm5ic3A7IFtCVFcsIGlz DQogaXQgdHJ1ZSB0aGF0IGRyYWZ0cyB3aXRoIFlBTkcgbW9kZWxzIHRha2UgbG9uZ2VyIHRpbWUg ZnJvbSB3ZyAtMDAgdG8gcHVibGlzaGVkIFJGQyB0aGFuIG90aGVyIGRyYWZ0cz9dPGJyPg0KPGJy Pg0KPGJyPg0KVGhpcyBzYWlkLCBJIHRoaW5rIHRoZXJlIGFyZSBzb21lIGltcG9ydGFudCBwb2lu dHMgdGhhdCB0aGUgZHJhZnQgcmFpc2VzLCBhbmQgdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBjb250 aW51ZSB0byB3b3JrIG9uOyBzcGVjaWZpY2FsbHkgMi4zLCAyLjUsIDIuNiwgMi43LiZuYnNwOyBC dXQgSSBkb24ndCB0aGluayB0aGF0IHRoZXNlIGFyZWFzIHJlcXVpcmUgY2hhbmdlcyB0byB0aGUg dmVyc2lvbmluZyBzY2hlbWUsIGFuZCBJIHRoaW5rIGl0IGlzIGEgbWlzdGFrZQ0KIHRvIGluY2x1 ZGUgdGhlc2UgYXJlYXMgaW4gdGhpcyBkcmFmdC48YnI+DQo8YnI+DQpTb21lIGNvbW1lbnRzIG9u IHNlY3Rpb24gNCwgVGhlIFByb2JsZW0gU3RhdGVtZW50Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtvJm5ic3A7IEFueSBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlIG9mIGEgZGVmaW5p dGlvbiByZXF1aXJlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVpdGhlciBhIG5ldyBtb2R1 bGUgbmFtZSBvciBhIG5ldyBwYXRoLiZuYnNwOyBUaGlzIGhhcyBiZWVuIGZvdW5kPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgY29zdGx5IHRvIHN1cHBvcnQgaW4gaW1wbGVtZW50YXRpb25zLCBp biBwYXJ0aWN1bGFyIG9uIHRoZSBjbGllbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzaWRl Ljxicj4NCjxicj4NClllcyBJIGFncmVlIHRoZXJlIGlzIGEgY29zdCBhc3NvY2lhdGVkIHdpdGgg dGhpcy4mbmJzcDsgQnV0IEkgaGF2ZSBjb21lIGFjcm9zcyB2ZW5kb3IgbW9kdWxlcyB0aGF0IG1h a2UgTkJDIGNoYW5nZXMgdy9vIGludHJvZHVjaW5nIGEgbmV3IHBhdGgsIGFuZCB0aGlzIGlzIGFs c28gY29zdGx5IHRvIGhhbmRsZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyBTaW5j ZSBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlcyByZXF1aXJlIGVpdGhlciBhIG5ldyBt b2R1bGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBuYW1lIG9yIGEgbmV3IHBhdGgsIHN1Y2gg Y2hhbmdlcyB3aWxsIGltcGFjdCBvdGhlciBtb2R1bGVzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBpbXBvcnQgZGVmaW5pdGlvbnMuJm5ic3A7IEluIGZhY3QsIHdpdGggdGhlIGN1cnJl bnQgbW9kdWxlIHZlcnNpb25pbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzY2hlbWUgb3Ro ZXIgbW9kdWxlcyBoYXZlIHRvIG9wdC1pbiBpbiBvcmRlciB0byB1c2UgdGhlIG5ldzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IHZlcnNpb24uJm5ic3A7IFRoaXMgZXNzZW50aWFsbHkgbGVhZHMg dG8gYSByaXBwbGUgZWZmZWN0IHdoZXJlIGEgbm9uLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZSBvZiBhIGNvcmUgbW9kdWxlIGNhdXNlcyB1cGRh dGVzIG9uIGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBwb3RlbnRpYWxseSBsYXJnZSBudW1i ZXIgb2YgZGVwZW5kZW50IG1vZHVsZXMuPGJyPg0KPGJyPg0KVGhpcyBpcyBieSBkZXNpZ24uJm5i c3A7IFdlIGNhbm5vdCBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIGEgbGVnYWwgbW9kaWZpY2F0aW9u IHRvIGEgbW9kdWxlIGxlYWRzIHRvIG90aGVyIG1vZHVsZXMgYmVjb21pbmcgaW52YWxpZC48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyBZQU5HIGhhcyBhIG1lY2hhbmlzbSB0byBtYXJr IGRlZmluaXRpb25zIGRlcHJlY2F0ZWQgYnV0IGl0IGxlYXZlczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IGl0IG9wZW4gd2hldGhlciBpbXBsZW1lbnRhdGlvbnMgYXJlIGV4cGVjdGVkIHRvIGlt cGxlbWVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlcHJlY2F0ZWQgZGVmaW5pdGlvbnMg YW5kIHRoZXJlIGlzIG5vIHdheSAob3RoZXIgdGhhbiB0cmlhbCBhbmQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBlcnJvcikgZm9yIGEgY2xpZW50IHRvIGZpbmQgb3V0IHdoZXRoZXIgZGVwcmVj YXRlZCBkZWZpbml0aW9ucyBhcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdXBwb3J0ZWQg YnkgYSBnaXZlbiBpbXBsZW1lbnRhdGlvbi48YnI+DQo8YnI+DQpBcyBJIHdyb3RlIGFib3ZlLCBJ IGFncmVlIHRoYXQgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCBzaG91bGQgYmUgc29sdmVkLiZuYnNw OyBCdXQgdGhpcyBpcyBub3QgYSBtb3RpdmF0aW9uIGZvciBjaGFuZ2luZyBZQU5HIHZlcnNpb25p bmcuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO28mbmJzcDsgWUFORyBkb2VzIG5vdCBoYXZlIGEg cm9idXN0IG1lY2hhbmlzbSB0byBkb2N1bWVudCB3aGljaCBkYXRhPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgZGVmaW5pdGlvbnMgaGF2ZSBjaGFuZ2VkIGFuZCB0byBwcm92aWRlIGd1aWRhbmNl IGhvdzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGltcGxlbWVudGF0aW9ucyBzaG91bGQgZGVh bCB3aXRoIHRoZSBjaGFuZ2UuJm5ic3A7IFdoaWxlIGl0IGlzIHBvc3NpYmxlPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdG8gaGF2ZSB0aGlzIGRlc2NyaWJlZCBpbiBnZW5lcmFsIGRlc2NyaXB0 aW9uIHN0YXRlbWVudHMsIGhhdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZXNlIGRl dGFpbHMgZW1iZWRkZWQgaW4gZ2VuZXJhbCBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRzIGRvZXMgbm90 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWFrZSB0aGlzIGluZm9ybWF0aW9uIGFjY2Vzc2li bGUgdG8gdG9vbHMuPGJyPg0KPGJyPg0KVGhpcyBtaWdodCBhbHNvIGJlIHdvcnRoIGV4cGxvcmlu ZywgYnV0IHRoaXMgaXMgbm90IGEgbW90aXZhdGlvbiBmb3IgY2hhbmdpbmcgWUFORyB2ZXJzaW9u aW5nLjxicj4NCjxicj4NCjxicj4NCjxicj4NCi9tYXJ0aW48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQi IHRhcmdldD0iX2JsYW5rIj5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7IFNlZWluZyBhcyBob3cgd2UgYWxsIG5lZWQgdG8gcmVhZCB0aGlzIGRyYWZ0IGFu eXdheXMsIGluIHByZXBhcmF0aW9uIGZvciBvdXIgbWVldGluZyBpbiBQcmFndWUsIGl0IHNlZW1z IGxpa2UgYSBnb29kIHRpbWUgZm9yIHRoaXMgcG9sbC4mbmJzcDsgVGh1c2x5LCB0aGlzIGVtYWls IGJlZ2lucyBhIDEtd2VlayBhZG9wdGlvbiBwb2xsIGZvcjo8YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNpb25pbmctcmVxcy0wMiIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5l dG1vZC15YW5nLXZlcnNpb25pbmctcmVxcy0wMjwvYT4gPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNp b25pbmctcmVxcy0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNpb25pbmctcmVxcy0wPC9hPjxicj4NCiZndDsg MiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBv YmplY3Rpb25zIGJlZm9yZSBNYXJjaCAyMC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTm90ZSB0aGF0 IHRoaXMgZHJhZnQgZGVmaW5lcyAqcmVxdWlyZW1lbnRzKiBhbmQgaXRzIGludGVuZGVkIHN0YXR1 cyBpcyAmcXVvdDtJbmZvcm1hdGlvbmFsLiZxdW90OyZuYnNwOyAmbmJzcDtJIGJlbGlldmUgdGhh dCBpdCBpcyBnb29kIGZvciBXR3MgdG8gZm9ybWFsaXplIHJlcXVpcmVtZW50cywgZXZlbiB0YWtp bmcgc3VjaCBkcmFmdHMgdGhydSBMYXN0IENhbGwsIGluIG9yZGVyIHRvIGVuc3VyZSBjb25zZW5z dXMgb24gdGhlIHJlcXVpcmVtZW50cy4mbmJzcDsgVGhpcyBpcyB0aGUgJnF1b3Q7YWRvcHRpb24m cXVvdDsNCiBjYWxsLCB0byBhc2NlcnRhaW4gaWYgdGhlIFdHIGFncmVlcyB3aXRoIHRoYXQgc3Rh dGVtZW50OyBpZiBhZG9wdGVkLCBhIHNlcGFyYXRlICZxdW90O2xhc3QgY2FsbCZxdW90OyB3aWxs IGJlIGlzc3VlZCB0byBlbnN1cmUgdG8gY29ycmVjdG5lc3Mgb2YgdGhlIGRyYWZ0J3MgY29udGVu dC48YnI+DQomZ3Q7IDxicj4NCiZndDsgS2VudCAoYW5kIExvdSBhbmQgSm9lbCk8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Qi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8871415dce7343a28afa25faf6080d8cXCHRCD007ciscocom_-- From nobody Wed Mar 20 05:22:00 2019 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 7F693128B36 for ; Wed, 20 Mar 2019 05:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 jcTbGSIaD7k1 for ; Wed, 20 Mar 2019 05:21:54 -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 AE3CC126D00 for ; Wed, 20 Mar 2019 05:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11583; q=dns/txt; s=iport; t=1553084514; x=1554294114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Kf1kwyFJllgOVDzu/I3rFzs3RhXgRSNNyHirdB+vkYE=; b=iLwmXq9ZGWv53veydzKAsZ7EpPrCSrPcTdX5/LRB1Z8EhuIcr3yjvIjA wQIfMw/ddP1d8WYFbzj1G+7Upr4stMsv/BRC8ZTUhL44ZAXvRVd51yq0v dbHeWQr9MWXErFp5t1hTCUffJLsRDdJnwkXnpu8oUMyujKGrJJPZ9teBS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAADXL5Jc/4YNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBghBogQMnCplLmDQUgWcLAQEYC4FUgi9?= =?us-ascii?q?GAoRlIjUIDQEBAwEBCQEDAm0cDIVKAQEBAwEBASUTNAsMBAIBCA4DBAEBAR4?= =?us-ascii?q?QJwsdCAIEDgUIE4MIgW0ID6tLM4ovBYEvAYsiDxeBQD+DJX6DHgEBA4ErARI?= =?us-ascii?q?BCYV3A4oeDjMChjmSd2AJAoddhAeHQCGBfIVzg0uIJ4wmhGaNCQIRFYEtIQM?= =?us-ascii?q?zZXFwFTuCbIIWF4hfhT9BMYpLgR+BHwEB?= X-IronPort-AV: E=Sophos;i="5.60,248,1549929600"; d="scan'208";a="535562421" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 12:21:52 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KCLqK0016283 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 12:21:52 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 07:21:51 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 20 Mar 2019 07:21:51 -0500 From: "Rob Wilton (rwilton)" To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SCAAV5PAP//9h1Q Date: Wed, 20 Mar 2019 12:21:51 +0000 Message-ID: <96f475459f6049bfa20c66412983f4a2@XCH-RCD-007.cisco.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <20190320.083022.2046737837256499330.mbj@tail-f.com> In-Reply-To: <20190320.083022.2046737837256499330.mbj@tail-f.com> 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.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 12:21:58 -0000 Hi Martin, > -----Original Message----- > From: Martin Bjorklund > Sent: 20 March 2019 07:30 > To: Rob Wilton (rwilton) > Cc: kent+ietf@watsen.net; netmod@ietf.org > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 >=20 > Hi, >=20 > "Rob Wilton (rwilton)" wrote: > > Hi Martin, > > > > Thanks for the review and comments. > > > > A couple of points: > > > > 1) Lots of models outside those published in SDOs are already not > > following the RFC 7950 revision rules. >=20 > Right, and I think that is ok. If vendors want to break backwards compat= ibility it > is up to them. With the current rules you can have tool that detect this= and flags > it. You can then fix the problem or release the new NBC module anyway, b= ut > you have been warned. > Customers will accept this or not. [RW]=20 Revision-dates don't help here, and are not sufficient to indicate the true= version history of a module when it is not chronologically ordered. Vendors want a way to accurately communicate to clients how the module is a= ctually being changed, in a way that is easier for them to understand. >=20 >=20 > > I think that it is better to > > have a versioning scheme that reflects how YANG models are actually > > evolving rather than have all vendor and OC YANG modules either just > > ignoring the rules, or using clever tricks that strictly conform with > > the rules but go against the spirit of them (e.g. just publish an > > entirely new set of YANG modules for each release). Also noting that > > having a scheme that allows non-backwards-compatible changes does not > > require that everyone uses them - IETF could continue to always > > publish backwards compatible modules. The obvious alternative here is > > that each vendor comes up with their own versioning extension and > > ignores the RFC 7950 section 11 rules anyway, but I'm not sure how > > that really helps client<->server interop. >=20 > The client<->server interop will not magically work better if we allow NB= C > changes. [RW]=20 It helps clients understand the nature of the changes. I don't believe that vendors are making NBC changes to make client lives ha= rder, they are trying to fix bugs and make their software better. I obviou= sly agree that it would be better to put more effort into producing higher = quality models in the first place, but there will always be mistakes, parti= cularly for vendor models that have much less peer review than YANG modules= produced by SDOs. >=20 > > 2) I don't understand how the RFC 7950 approach of "deprecate a buggy > > node, and replace with a working node" really works in practice, > > particularly for configuration data nodes where you have two clients > > interacting with a server, one interacting with the old path, and > > another using the new path. Perhaps there is a robust scheme that > > works in all cases, but it isn't obvious to me. Historically, for CLI > > we just translate the CLI from old to new format and then return the > > new format when the running config is requested. But that will still > > break an old client that doesn't understand how to read the new CLI, > > even if the server supports them writing via the old CLI. > > > > Even if there is a workable solution for this simple case, I suspect > > that there are many slightly more complicated cases that don't work > > (e.g. rekeying a list, changing defaults, incompatible types). >=20 > I fully agree. This is difficult in the general case. In the worst case= you'll have to > give up on backwards compatibility and only implement the new version of = the > module (I believe this is possible both with the current versioning rules= , and with > the proposed rules). [RW]=20 Implementing a new module and not supporting the old to fix one leaf has a = massive impact: - it breaks all clients using that module (regardless of whether they were= using the leaf) - it forces updates to all modules that augment or depend on the old modul= e. Say we hypothetically decide that "link-up-down-trap-enable" in RFC 8343 is= wrong should be mandatory true. Is the right solution here really to defi= ne a new "ietf-interfaces-2" YANG module and require all 50 or so YANG modu= les that augment IETF interfaces to be updated? It seems that this would be a much more impactful change than allowing an N= BC change to that module, and documenting that as version 2.0.0. I am sure that if YANG allows NBC changes then some folks will use them for= purposes that they should not. But I also believe that those same folk wi= ll make those same changes regardless of what an RFC states. But I also th= ink that many vendors will try and use NBC changes as a way to make their m= odels better, improve the quality of YANG data models. >=20 > > In short, I don't agree with the premise that the current YANG > > versioning schema using revision dates is working just fine, and no > > changes are needed. >=20 > But this is not what the draft is about! There is nothing in the draft t= hat talks > about problems introduced by using the revision dates. [RW]=20 I think that "revision-date" and RFC 7950 section 11 module update rules go= hand in hand. If your objection is that we don't quite describe the problem clearly enoug= h then that can be fixed. My interpretation is that your objection is more fundamental than that. I= .e. you don't think that we should be using semantic versioning at all, and= we should keep RFC 7950 section 11 rules and revision dates for versioning= YANG models. But I think that the overwhelming evidence is that the curre= nt scheme does not work for everyone, even if it might be sufficient for YA= NG modules produced in the IETF. Thanks, Rob >=20 >=20 > /martin >=20 >=20 >=20 > > > > Thanks, > > Rob > > > > > > -----Original Message----- > > From: netmod On Behalf Of Martin Bjorklund > > Sent: 19 March 2019 15:12 > > To: kent+ietf@watsen.net > > Cc: netmod@ietf.org > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > Hi, > > > > I have read this document, and I do not think it should be adopted. > > > > I object to the idea that we should allow non-backwards-compatible > > changes to published YANG modules. > > > > The draft motivates this idea with: > > > > we must recognize that many YANG > > modules are actually generated YANG modules (for example, from > > internal databases) > > > > I do not agree that we should change what we allow in published > > modules b/c of this. > > > > It also motivates this idea with: > > > > The points made above lead to the logical conclusion that the > > standardized YANG modules have to be perfect on day one (at least th= e > > structure and meaning), which in turn might explain why IETF YANG > > modules take so long to standardize. > > > > I disagree with this. First of all, we have already published > > revision two of several YANG modules (ietf-inet-types, ietf-yang-type, > > ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that > > "standardized YANG modules have to be perfect on day one" is simply > > not true. > > > > Second, I don't think the upgrade rules are the reason it takes a long > > time to standardize IETF models (I think it has to do with the process > > itself, including the fact that models get reviews from many different > > people with different background.) [BTW, is it true that drafts with > > YANG models take longer time from wg -00 to published RFC than other > > drafts?] > > > > > > This said, I think there are some important points that the draft > > raises, and that I think we should continue to work on; specifically > > 2.3, 2.5, 2.6, 2.7. But I don't think that these areas require > > changes to the versioning scheme, and I think it is a mistake to > > include these areas in this draft. > > > > Some comments on section 4, The Problem Statement: > > > > o Any non-backwards-compatible change of a definition requires > > either a new module name or a new path. This has been found > > costly to support in implementations, in particular on the client > > side. > > > > Yes I agree there is a cost associated with this. But I have come > > across vendor modules that make NBC changes w/o introducing a new > > path, and this is also costly to handle. > > > > o Since non-backwards-compatible changes require either a new modul= e > > name or a new path, such changes will impact other modules that > > import definitions. In fact, with the current module versioning > > scheme other modules have to opt-in in order to use the new > > version. This essentially leads to a ripple effect where a non- > > backwards-compatible change of a core module causes updates on a > > potentially large number of dependent modules. > > > > This is by design. We cannot have a situation where a legal > > modification to a module leads to other modules becoming invalid. > > > > o YANG has a mechanism to mark definitions deprecated but it leaves > > it open whether implementations are expected to implement > > deprecated definitions and there is no way (other than trial and > > error) for a client to find out whether deprecated definitions ar= e > > supported by a given implementation. > > > > As I wrote above, I agree that this is a problem that should be > > solved. But this is not a motivation for changing YANG versioning. > > > > o YANG does not have a robust mechanism to document which data > > definitions have changed and to provide guidance how > > implementations should deal with the change. While it is possibl= e > > to have this described in general description statements, having > > these details embedded in general description statements does not > > make this information accessible to tools. > > > > This might also be worth exploring, but this is not a motivation for > > changing YANG versioning. > > > > > > > > /martin > > > > > > > > Kent Watsen wrote: > > > Seeing as how we all need to read this draft anyways, in preparation > > > for our meeting in Prague, it seems like a good time for this poll. > > > Thusly, this email begins a 1-week adoption poll for: > > > > > > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs- > > > 02 > > > > > -0 > > > 2> > > > > > > Please voice your support or objections before March 20. > > > > > > Note that this draft defines *requirements* and its intended status > > > is "Informational." I believe that it is good for WGs to formalize > > > requirements, even taking such drafts thru Last Call, in order to > > > ensure consensus on the requirements. This is the "adoption" call, > > > to ascertain if the WG agrees with that statement; if adopted, a > > > separate "last call" will be issued to ensure to correctness of the > > > draft's content. > > > > > > Kent (and Lou and Joel) > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Wed Mar 20 06:48:41 2019 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 AB4F612867A for ; Wed, 20 Mar 2019 06:48:39 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mpXtEqyfg54R for ; Wed, 20 Mar 2019 06:48:34 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 008A312782C for ; Wed, 20 Mar 2019 06:48:33 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id y18so1963992lfe.1 for ; Wed, 20 Mar 2019 06:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g4xV9ubUyoOSkFnD+rOi+LBH/2SmPSIRfpHsQZHTOmQ=; b=hIZnLZH3pPV3XxP2Yubjbysd6CTLtl26pUiLOYfNfi2VDFtaM+XIrxmycNAJdB8QAo yhvsjRLYqFgfpyFxJ5JwM8cP/n6dyZnqDGXo46ZcjI78+7M3fN8L7T3VgmCoM5s5rz+m slscMAqwuoXTObzjnd7abkl5L5ti+AOa13Osxpf1jOYJ8xRAYYJrIht791ZxX2NfPezZ Fv+4kiAdvxOjorjcC0U1MPWHXdb4RZdZ5BFUAFh31M8iXCnFW/7Cy3DpWVZ9r4dGnV7m yZ1uHT0wvnAPziS9xDawuOdLWYDkitJOlss8s5KL/xJeMdwtQ4+PjZB63e2xdrDuASeL GI1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g4xV9ubUyoOSkFnD+rOi+LBH/2SmPSIRfpHsQZHTOmQ=; b=k3trrQkb5cJbUrX60m9m+5/xT0VOuJBAxb5YDOoqoxqqquBTbfx0B0QQOLXmk/S9xZ zkvihI0jF3hIJr/J0nFv6ve+qclF2++IAsotATqYdcCN8z7peSMZH6LnGw+EavlXqcU2 psZ3uETjXj/0OugDbcn6rscua7kY/43J0IyFi1ZTpzJQSU+iWN7LO99uF6uVdLxxq54f bgrYFdgTss4sDptpK1xkN3T35nerzcVNreI/K5ru06Ve/je3A7T8YbS3I6BQZXAppuHv 3RiSu1AGRhInGl3Y94Yt1eyFV1pUHEgQLktGEZHxPlpwTCVL95H1wPo5CRwg4UOKUrJ2 d1Qw== X-Gm-Message-State: APjAAAXGA7z046ouJyuMXfq+rdIwEWa99us5WnenW8bvxlitn3x2WcGn +dwCMiPvMq6dumQnHesibjvRnGgN7fUNy9tDCtsUVA== X-Google-Smtp-Source: APXvYqzwEppUZNhfMDpNcNB0OdtfepM5B7fzSt0BARvZyFFo+O7nXCEDnfSH8UtgbOkS+Uthyt4hRhVH+kznY0oH4Rc= X-Received: by 2002:ac2:569b:: with SMTP id 27mr17224494lfr.24.1553089711523; Wed, 20 Mar 2019 06:48:31 -0700 (PDT) MIME-Version: 1.0 References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> In-Reply-To: <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> From: Andy Bierman Date: Wed, 20 Mar 2019 06:48:20 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Martin Bjorklund , "kent+ietf@watsen.net" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008f5fc9058486e07b" Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 13:48:40 -0000 --0000000000008f5fc9058486e07b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2019 at 4:54 AM Rob Wilton (rwilton) wrote: > Hi Andy, > > > > Thanks for the comments. > > > > 1. Regular Semver 2.0.0 (as per semver.org) allows some branching. I.e. > you can create version 2.0.0 based of version 1.1.0, and then subsequentl= y > create version 1.2.0 based of 1.1.0. So structure wise this would > logically look like: > > > > 1.0.0 > > | \ > > | 1.1.0 =E2=80=93 1.2.0 - =E2=80=A6 > > | > > 2.0.0 > > | > > > > I also raised https://github.com/semver/semver/issues/504 on the semver > 2.0.0 github to confirm that my interpretation is correct, and no one has > disputed it yet. > > > The numbering may allow it, but it is not really being used that way. I don't think the YANG standard needs to support branching in this way. > > > 2. Vendor software releases can have a very long support time (e.g. easil= y > 5+ years), with an expectation that bugs get fixed. Requiring that > customers upgrade their software (or perhaps hardware) to the very latest > software version to pick up a small bug fix is not realistic. This is > primarily why I think that the =E2=80=98m=E2=80=99 and =E2=80=98M=E2=80= =99 are so important. They allow > for bug fixes in a way that Semver 2.0.0 simply does not. > > > > Semver 2.0.0 only allows for bugfixes in the implementation (by updating > the patch version number), but has the expectation that there are **never= ** > any non-backwards-compatible changes in the API, not even to fix a bug, > except at the tip of the development tree. > > > > In short, I think that vanilla Semver 2.0.0 is a good fit for open source > projects where you can just tell the client to update to the latest versi= on > to pick up the fix. I don=E2=80=99t think that Semver 2.0.0 is so well a= ligned to > APIs that are required to be maintained for long periods of time. > > > > The alternative that Rob Shakir mentioned at IETF 103 in the context of > OpenConfig, which uses strict Semver 2.0.0, is to handle these bug fixes > using deviations. But it seems to be significantly more complex to manag= e > bug fixes using extra deviation modules rather than allowing the =E2=80= =98m=E2=80=99 | =E2=80=98M=E2=80=99 > modifiers. Versioning would no longer limited to a module version number= , > but require knowledge of the module version and set of deviations that ar= e > applied to it. I would rather deviations are reserved to indicate whethe= r > an implementation doesn=E2=80=99t match the module specification rather t= han use > them as a way of fixing bugs in the specification itself. > > > I agree that deviations should be used instead of branching. You can cherry-pick features from the latest very easily with deviations. IMO it is more accurate to say the implementation supports version X minus some features, rather than assigning some version string to mean the same thing. This approach can get out of control very quickly if multiple independent release trains exist. I prefer a linear development progression, and each implementation will identity its functionality the same way. > > 3. I agree that the use of Semver + packages + version selection does not > reduce the overall number of paths to a configurable property, but it doe= s > ensure that there is only a single path to a configurable property within= a > YANG datastore schema. So whichever version each client is using, they > only use a single path. I.e. mirroring the way that a classic programmin= g > API might be versioned. > > > > Servers that wish to support this would have to map the data between > different YANG datastore schema versions. Not all mappings are possible, > but at least any cases where it is not possible can be detected and > reported to the client via an out of band mechanism. > > > > If the module content changes significantly between module versions that > mapping will be much harder than if the changes are minimal or backwards > compatible. So there is still a strong incentive for model writers to > minimize churn to the YANG models. > > > I don't think the versioning data nodes is a good idea. I have seen entire REST APIs be versioned, but not individual parameters within the API. How do you version the must/when/path references from other objects that point at the data node? Sounds way too complex to manage. > Thanks, > Rob > > > Andy > > > *From:* Andy Bierman > *Sent:* 19 March 2019 18:35 > *To:* Rob Wilton (rwilton) > *Cc:* Martin Bjorklund ; kent+ietf@watsen.net; > netmod@ietf.org > *Subject:* Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > > > > > On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) > wrote: > > Hi Martin, > > Thanks for the review and comments. > > A couple of points: > > 1) Lots of models outside those published in SDOs are already not > following the RFC 7950 revision rules. I think that it is better to have= a > versioning scheme that reflects how YANG models are actually evolving > rather than have all vendor and OC YANG modules either just ignoring the > rules, or using clever tricks that strictly conform with the rules but go > against the spirit of them (e.g. just publish an entirely new set of YANG > modules for each release). Also noting that having a scheme that allows > non-backwards-compatible changes does not require that everyone uses them= - > IETF could continue to always publish backwards compatible modules. The > obvious alternative here is that each vendor comes up with their own > versioning extension and ignores the RFC 7950 section 11 rules anyway, bu= t > I'm not sure how that really helps client<->server interop. > > > > > > I do not support branching for YANG models so I do not supported modified > SEMVER. > > Adding a special character to the version string doesn't help the deploye= d > client code > > that stops working when the server code is upgraded. This is a quality > issue that > > each organization has to deal with the best they can. > > > > I do not object to the addition of a SEMVER field to a YANG module becaus= e > these version > > strings are familiar to users. It is possible to express import ranges > such as 1.2.* (any 1.2.x release) > > which are not possible with date strings. > > > > > > 2) I don't understand how the RFC 7950 approach of "deprecate a buggy > node, and replace with a working node" really works in practice, > particularly for configuration data nodes where you have two clients > interacting with a server, one interacting with the old path, and another > using the new path. Perhaps there is a robust scheme that works in all > cases, but it isn't obvious to me. Historically, for CLI we just transla= te > the CLI from old to new format and then return the new format when the > running config is requested. But that will still break an old client tha= t > doesn't understand how to read the new CLI, even if the server supports > them writing via the old CLI. > > > > SEMVER does not reduce the number of paths to the underlying configuratio= n > object. > > That problem does not change whether a new XPath absolute-path-expr is us= ed > > or whether the same path is overloaded with semantics derived from > additional protocol parameters > > (e.g., versioning of each data node). I prefer the existing XPath solutio= n > because it is explicit > > so the YANG reader can easily see the multiple paths, and no new protocol > work needed to support it. > > If there is an NBC change to an object then all XPath and leafref > references to it will probably break. > > That seems like a harder problem to solve than the original path > duplication problem. > > > > > > Even if there is a workable solution for this simple case, I suspect that > there are many slightly more complicated cases that don't work (e.g. > rekeying a list, changing defaults, incompatible types). > > In short, I don't agree with the premise that the current YANG versioning > schema using revision dates is working just fine, and no changes are need= ed. > > Thanks, > Rob > > > > Andy > > > > > -----Original Message----- > From: netmod On Behalf Of Martin Bjorklund > Sent: 19 March 2019 15:12 > To: kent+ietf@watsen.net > Cc: netmod@ietf.org > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > Hi, > > I have read this document, and I do not think it should be adopted. > > I object to the idea that we should allow non-backwards-compatible change= s > to published YANG modules. > > The draft motivates this idea with: > > we must recognize that many YANG > modules are actually generated YANG modules (for example, from > internal databases) > > I do not agree that we should change what we allow in published modules > b/c of this. > > It also motivates this idea with: > > The points made above lead to the logical conclusion that the > standardized YANG modules have to be perfect on day one (at least the > structure and meaning), which in turn might explain why IETF YANG > modules take so long to standardize. > > I disagree with this. First of all, we have already published revision > two of several YANG modules (ietf-inet-types, ietf-yang-type, > ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that > "standardized YANG modules have to be perfect on day one" is simply not > true. > > Second, I don't think the upgrade rules are the reason it takes a long > time to standardize IETF models (I think it has to do with the process > itself, including the fact that models get reviews from many different > people with different background.) [BTW, is it true that drafts with YAN= G > models take longer time from wg -00 to published RFC than other drafts?] > > > This said, I think there are some important points that the draft raises, > and that I think we should continue to work on; specifically 2.3, 2.5, 2.= 6, > 2.7. But I don't think that these areas require changes to the versionin= g > scheme, and I think it is a mistake to include these areas in this draft. > > Some comments on section 4, The Problem Statement: > > o Any non-backwards-compatible change of a definition requires > either a new module name or a new path. This has been found > costly to support in implementations, in particular on the client > side. > > Yes I agree there is a cost associated with this. But I have come across > vendor modules that make NBC changes w/o introducing a new path, and this > is also costly to handle. > > o Since non-backwards-compatible changes require either a new module > name or a new path, such changes will impact other modules that > import definitions. In fact, with the current module versioning > scheme other modules have to opt-in in order to use the new > version. This essentially leads to a ripple effect where a non- > backwards-compatible change of a core module causes updates on a > potentially large number of dependent modules. > > This is by design. We cannot have a situation where a legal modification > to a module leads to other modules becoming invalid. > > o YANG has a mechanism to mark definitions deprecated but it leaves > it open whether implementations are expected to implement > deprecated definitions and there is no way (other than trial and > error) for a client to find out whether deprecated definitions are > supported by a given implementation. > > As I wrote above, I agree that this is a problem that should be solved. > But this is not a motivation for changing YANG versioning. > > o YANG does not have a robust mechanism to document which data > definitions have changed and to provide guidance how > implementations should deal with the change. While it is possible > to have this described in general description statements, having > these details embedded in general description statements does not > make this information accessible to tools. > > This might also be worth exploring, but this is not a motivation for > changing YANG versioning. > > > > /martin > > > > Kent Watsen wrote: > > Seeing as how we all need to read this draft anyways, in preparation fo= r > our meeting in Prague, it seems like a good time for this poll. Thusly, > this email begins a 1-week adoption poll for: > > > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 > > > 2> > > > > Please voice your support or objections before March 20. > > > > Note that this draft defines *requirements* and its intended status is > "Informational." I believe that it is good for WGs to formalize > requirements, even taking such drafts thru Last Call, in order to ensure > consensus on the requirements. This is the "adoption" call, to ascertain > if the WG agrees with that statement; if adopted, a separate "last call" > will be issued to ensure to correctness of the draft's content. > > > > Kent (and Lou and Joel) > > > > > > _______________________________________________ > 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 > > --0000000000008f5fc9058486e07b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 20, 2019 at 4:54 AM Rob W= ilton (rwilton) <rwilton@cisco.com<= /a>> wrote:

Hi Andy,

=C2=A0

Thanks for the comments.

=C2=A0

1. Regular Semver 2.0.0 (as per semver.org) allows some branching.= =C2=A0 I.e. you can create version 2.0.0 based of version 1.1.0, and then subsequently create version 1.2.0 based of 1.1.0.=C2=A0 So structure wise = this would logically look like:

=C2=A0

=C2=A0=C2=A0 1.0.0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | \

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0 = =C2=A01.1.0 =E2=80=93 1.2.0 - =E2=80=A6

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=

=C2=A0=C2=A0 2.0.0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0

I also raised h= ttps://github.com/semver/semver/issues/504=C2=A0 on the semver 2.0.0 gi= thub to confirm that my interpretation is correct, and no one has disputed = it yet.

=C2=A0


The numbering may allow it, but it is not really b= eing used that way.
I don't think the YANG standard needs to = support branching in this way.
=C2=A0

=C2=A0

2. Vendor software releases can have a very = long support time (e.g. easily 5+ years), with an expectation that bugs get= fixed.=C2=A0 Requiring that customers upgrade their software (or perhaps hardware) to the very la= test software version to pick up a small bug fix is not realistic.=C2=A0 Th= is is primarily why I think that the =E2=80=98m=E2=80=99 and =E2=80=98M=E2= =80=99 are so important.=C2=A0 They allow for bug fixes in a way that Semve= r 2.0.0 simply does not.

=C2=A0

Semver 2.0.0 only allows for bugfixes in the= implementation (by updating the patch version number), but has the expecta= tion that there are *never* any non-backwards-compatible changes in the API, not ev= en to fix a bug, except at the tip of the development tree.

=C2=A0

In short, I think that vanilla Semver 2.0.0 = is a good fit for open source projects where you can just tell the client t= o update to the latest version to pick up the fix.=C2=A0 I don=E2=80=99t think that Se= mver 2.0.0 is so well aligned to APIs that are required to be maintained fo= r long periods of time.

=C2=A0

The alternative that Rob Shakir mentioned at= IETF 103 in the context of OpenConfig, which uses strict Semver 2.0.0, is = to handle these bug fixes using deviations.=C2=A0 But it seems to be significantly more co= mplex to manage bug fixes using extra deviation modules rather than allowin= g the =E2=80=98m=E2=80=99 | =E2=80=98M=E2=80=99 modifiers.=C2=A0 Versioning= would no longer limited to a module version number, but require knowledge of the module version and set of deviations that are applied to it.=C2=A0 = I would rather deviations are reserved to indicate whether an implementatio= n doesn=E2=80=99t match the module specification rather than use them as a = way of fixing bugs in the specification itself.

=C2=A0



I agree that deviations should be u= sed instead of branching.
You can cherry-pick features from the l= atest very easily with deviations.
IMO it is more accurate to say= the implementation supports version X minus some features,
rathe= r than assigning some version string to mean the same thing.=C2=A0 This app= roach can get
out of control very quickly if multiple independent= release trains exist. I prefer a linear
development progression,= and each implementation will identity its functionality the same way.


=C2=A0

3. I agree that the use of Semver + packages= + version selection does not reduce the overall number of paths to a confi= gurable property, but it does ensure that there is only a single path to a configurable prop= erty within a YANG datastore schema. =C2=A0=C2=A0So whichever version each = client is using, they only use a single path.=C2=A0 I.e. mirroring the way = that a classic programming API might be versioned.

=C2=A0

Servers that wish to support this would have= to map the data between different YANG datastore schema versions.=C2=A0 No= t all mappings are possible, but at least any cases where it is not possible can be detected = and reported to the client via an out of band mechanism.

=C2=A0

If the module content changes significantly = between module versions that mapping will be much harder than if the change= s are minimal or backwards compatible.=C2=A0 So there is still a strong incentive for mo= del writers to minimize churn to the YANG models.

=C2=A0


I don't think the versioning data nodes is a g= ood idea.
I have seen entire REST APIs be versioned, but not indi= vidual parameters within the API.
How do you version the must/whe= n/path references from other objects that point at the data node?
Sounds way too complex to manage.
=C2=A0

Thanks,
Rob

=C2=A0


Andy
=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 19 March 2019 18:35
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; kent+ietf@watsen.net; netmod@ietf.org
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

=C2=A0

=C2=A0

=C2=A0

On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi Martin,

Thanks for the review and comments.

A couple of points:

1) Lots of models outside those published in SDOs are already not following= the RFC 7950 revision rules.=C2=A0 I think that it is better to have a ver= sioning scheme that reflects how YANG models are actually evolving rather t= han have all vendor and OC YANG modules either just ignoring the rules, or using clever tricks that strictly confo= rm with the rules but go against the spirit of them (e.g. just publish an e= ntirely new set of YANG modules for each release).=C2=A0 Also noting that h= aving a scheme that allows non-backwards-compatible changes does not require that everyone uses them - IETF could continue to = always publish backwards compatible modules.=C2=A0 The obvious alternative = here is that each vendor comes up with their own versioning extension and i= gnores the RFC 7950 section 11 rules anyway, but I'm not sure how that really helps client<->server i= nterop.

=C2=A0

=C2=A0

I do not support branching for YANG models so I do n= ot supported modified SEMVER.

Adding a special character to the version string doe= sn't help the deployed client code

that stops working when the server code is upgraded.= =C2=A0 This is a quality issue that

each organization has to deal with the best they can= .

=C2=A0

I do not object to the addition of a SEMVER field to= a YANG module because these version

strings are familiar to users.=C2=A0 It is possible = to express import ranges such as 1.2.* (any 1.2.x release)

which are not possible with date strings.<= /u>

=C2=A0

=C2=A0

2) I don't understa= nd how the RFC 7950 approach of "deprecate a buggy node, and replace w= ith a working node" really works in practice, particularly for configu= ration data nodes where you have two clients interacting with a server, one interacting with the old path, and another using the ne= w path.=C2=A0 Perhaps there is a robust scheme that works in all cases, but= it isn't obvious to me.=C2=A0 Historically, for CLI we just translate = the CLI from old to new format and then return the new format when the running config is requested.=C2=A0 But that will s= till break an old client that doesn't understand how to read the new CL= I, even if the server supports them writing via the old CLI.<= /p>

=C2=A0

SEMVER does not reduce the number of paths to the un= derlying configuration object.

That problem does not change whether a new XPath abs= olute-path-expr is used

or whether the same path is overloaded with semantic= s derived from additional protocol parameters=C2=A0

(e.g., versioning of each data node). I prefer the e= xisting XPath solution because it is explicit

so the YANG reader can easily see the multiple paths= , and no new protocol work needed to support it.

If there is an NBC change to an object then all XPat= h and leafref references to it will probably break.

That seems like a harder problem to solve than the o= riginal path duplication problem.

=C2=A0

=C2=A0

Even if there is a work= able solution for this simple case, I suspect that there are many slightly = more complicated cases that don't work (e.g. rekeying a list, changing = defaults, incompatible types).

In short, I don't agree with the premise that the current YANG versioni= ng schema using revision dates is working just fine, and no changes are nee= ded.

Thanks,
Rob

=C2=A0

Andy

=C2=A0


-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: kent+ietf@w= atsen.net
Cc: netmod@ietf.org
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi,

I have read this document, and I do not think it should be adopted.

I object to the idea that we should allow non-backwards-compatible changes = to published YANG modules.

The draft motivates this idea with:

=C2=A0 =C2=A0we must recognize that many YANG
=C2=A0 =C2=A0modules are actually generated YANG modules (for example, from=
=C2=A0 =C2=A0internal databases)

I do not agree that we should change what we allow in published modules b/c= of this.

It also motivates this idea with:

=C2=A0 =C2=A0The points made above lead to the logical conclusion that the<= br> =C2=A0 =C2=A0standardized YANG modules have to be perfect on day one (at le= ast the
=C2=A0 =C2=A0structure and meaning), which in turn might explain why IETF Y= ANG
=C2=A0 =C2=A0modules take so long to standardize.

I disagree with this.=C2=A0 First of all, we have already published revisio= n two of several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interf= aces, ietf-ip, ietf-routing, ...), so the statement that "standardized= YANG modules have to be perfect on day one" is simply not true.

Second, I don't think the upgrade rules are the reason it takes a long = time to standardize IETF models (I think it has to do with the process itse= lf, including the fact that models get reviews from many different people w= ith different background.)=C2=A0 [BTW, is it true that drafts with YANG models take longer time from wg -00 to publi= shed RFC than other drafts?]


This said, I think there are some important points that the draft raises, a= nd that I think we should continue to work on; specifically 2.3, 2.5, 2.6, = 2.7.=C2=A0 But I don't think that these areas require changes to the ve= rsioning scheme, and I think it is a mistake to include these areas in this draft.

Some comments on section 4, The Problem Statement:

=C2=A0 =C2=A0o=C2=A0 Any non-backwards-compatible change of a definition re= quires
=C2=A0 =C2=A0 =C2=A0 either a new module name or a new path.=C2=A0 This has= been found
=C2=A0 =C2=A0 =C2=A0 costly to support in implementations, in particular on= the client
=C2=A0 =C2=A0 =C2=A0 side.

Yes I agree there is a cost associated with this.=C2=A0 But I have come acr= oss vendor modules that make NBC changes w/o introducing a new path, and th= is is also costly to handle.

=C2=A0 =C2=A0o=C2=A0 Since non-backwards-compatible changes require either = a new module
=C2=A0 =C2=A0 =C2=A0 name or a new path, such changes will impact other mod= ules that
=C2=A0 =C2=A0 =C2=A0 import definitions.=C2=A0 In fact, with the current mo= dule versioning
=C2=A0 =C2=A0 =C2=A0 scheme other modules have to opt-in in order to use th= e new
=C2=A0 =C2=A0 =C2=A0 version.=C2=A0 This essentially leads to a ripple effe= ct where a non-
=C2=A0 =C2=A0 =C2=A0 backwards-compatible change of a core module causes up= dates on a
=C2=A0 =C2=A0 =C2=A0 potentially large number of dependent modules.

This is by design.=C2=A0 We cannot have a situation where a legal modificat= ion to a module leads to other modules becoming invalid.

=C2=A0 =C2=A0o=C2=A0 YANG has a mechanism to mark definitions deprecated bu= t it leaves
=C2=A0 =C2=A0 =C2=A0 it open whether implementations are expected to implem= ent
=C2=A0 =C2=A0 =C2=A0 deprecated definitions and there is no way (other than= trial and
=C2=A0 =C2=A0 =C2=A0 error) for a client to find out whether deprecated def= initions are
=C2=A0 =C2=A0 =C2=A0 supported by a given implementation.

As I wrote above, I agree that this is a problem that should be solved.=C2= =A0 But this is not a motivation for changing YANG versioning.

=C2=A0 =C2=A0o=C2=A0 YANG does not have a robust mechanism to document whic= h data
=C2=A0 =C2=A0 =C2=A0 definitions have changed and to provide guidance how =C2=A0 =C2=A0 =C2=A0 implementations should deal with the change.=C2=A0 Whi= le it is possible
=C2=A0 =C2=A0 =C2=A0 to have this described in general description statemen= ts, having
=C2=A0 =C2=A0 =C2=A0 these details embedded in general description statemen= ts does not
=C2=A0 =C2=A0 =C2=A0 make this information accessible to tools.

This might also be worth exploring, but this is not a motivation for changi= ng YANG versioning.



/martin



Kent Watsen <kent+ietf@watsen.net> wrote:
> Seeing as how we all need to read this draft anyways, in preparation f= or our meeting in Prague, it seems like a good time for this poll.=C2=A0 Th= usly, this email begins a 1-week adoption poll for:
>
>=C2=A0 =C2=A0 =C2=A0
> https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 =
> <https://tools.ietf.org/html/draft-verdt-n= etmod-yang-versioning-reqs-0
> 2>
>
> Please voice your support or objections before March 20.
>
> Note that this draft defines *requirements* and its intended status is= "Informational."=C2=A0 =C2=A0I believe that it is good for WGs t= o formalize requirements, even taking such drafts thru Last Call, in order = to ensure consensus on the requirements.=C2=A0 This is the "adoption&q= uot; call, to ascertain if the WG agrees with that statement; if adopted, a sep= arate "last call" will be issued to ensure to correctness of the = draft's content.
>
> Kent (and Lou and Joel)
>
>

_______________________________________________
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

--0000000000008f5fc9058486e07b-- From nobody Wed Mar 20 06:54:46 2019 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 5427612787F for ; Wed, 20 Mar 2019 06:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kLD3-1mVKuJ0 for ; Wed, 20 Mar 2019 06:54:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3D112782C for ; Wed, 20 Mar 2019 06:54:41 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D26171AE039A; Wed, 20 Mar 2019 14:54:39 +0100 (CET) Date: Wed, 20 Mar 2019 14:54:39 +0100 (CET) Message-Id: <20190320.145439.1107389062091531440.mbj@tail-f.com> To: rwilton@cisco.com Cc: kent+ietf@watsen.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <96f475459f6049bfa20c66412983f4a2@XCH-RCD-007.cisco.com> References: <20190320.083022.2046737837256499330.mbj@tail-f.com> <96f475459f6049bfa20c66412983f4a2@XCH-RCD-007.cisco.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 13:54:45 -0000 "Rob Wilton (rwilton)" wrote: > Hi Martin, > > > -----Original Message----- > > From: Martin Bjorklund > > Sent: 20 March 2019 07:30 > > To: Rob Wilton (rwilton) > > Cc: kent+ietf@watsen.net; netmod@ietf.org > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > Hi, > > > > "Rob Wilton (rwilton)" wrote: > > > Hi Martin, > > > > > > Thanks for the review and comments. > > > > > > A couple of points: > > > > > > 1) Lots of models outside those published in SDOs are already not > > > following the RFC 7950 revision rules. > > > > Right, and I think that is ok. If vendors want to break backwards > > compatibility it > > is up to them. With the current rules you can have tool that detect > > this and flags > > it. You can then fix the problem or release the new NBC module > > anyway, but > > you have been warned. > > Customers will accept this or not. > > [RW] > Revision-dates don't help here, and are not sufficient to indicate the > true version history of a module when it is not chronologically > ordered. > > Vendors want a way to accurately communicate to clients how the module > is actually being changed, in a way that is easier for them to > understand. If I'm at 1.0.1M and see 1.0.2M it doesn't help me much. > > > I think that it is better to > > > have a versioning scheme that reflects how YANG models are actually > > > evolving rather than have all vendor and OC YANG modules either just > > > ignoring the rules, or using clever tricks that strictly conform with > > > the rules but go against the spirit of them (e.g. just publish an > > > entirely new set of YANG modules for each release). Also noting that > > > having a scheme that allows non-backwards-compatible changes does not > > > require that everyone uses them - IETF could continue to always > > > publish backwards compatible modules. The obvious alternative here is > > > that each vendor comes up with their own versioning extension and > > > ignores the RFC 7950 section 11 rules anyway, but I'm not sure how > > > that really helps client<->server interop. > > > > The client<->server interop will not magically work better if we allow > > NBC > > changes. > [RW] > It helps clients understand the nature of the changes. The draft we talk about does not mention anything about helping clients understand the diffs, BC or not. > I don't believe that vendors are making NBC changes to make client > lives harder, they are trying to fix bugs and make their software > better. I obviously agree that it would be better to put more effort > into producing higher quality models in the first place, but there > will always be mistakes, particularly for vendor models that have much > less peer review than YANG modules produced by SDOs. > > > > > > > 2) I don't understand how the RFC 7950 approach of "deprecate a buggy > > > node, and replace with a working node" really works in practice, > > > particularly for configuration data nodes where you have two clients > > > interacting with a server, one interacting with the old path, and > > > another using the new path. Perhaps there is a robust scheme that > > > works in all cases, but it isn't obvious to me. Historically, for CLI > > > we just translate the CLI from old to new format and then return the > > > new format when the running config is requested. But that will still > > > break an old client that doesn't understand how to read the new CLI, > > > even if the server supports them writing via the old CLI. > > > > > > Even if there is a workable solution for this simple case, I suspect > > > that there are many slightly more complicated cases that don't work > > > (e.g. rekeying a list, changing defaults, incompatible types). > > > > I fully agree. This is difficult in the general case. In the worst > > case you'll have to > > give up on backwards compatibility and only implement the new version > > of the > > module (I believe this is possible both with the current versioning > > rules, and with > > the proposed rules). > [RW] > Implementing a new module and not supporting the old to fix one leaf This is a strawman; I never recommended changing an entire module to fix one leaf. > has a massive impact: > - it breaks all clients using that module (regardless of whether they > were using the leaf) > - it forces updates to all modules that augment or depend on the old > module. > > Say we hypothetically decide that "link-up-down-trap-enable" in RFC > 8343 is wrong should be mandatory true. Is the right solution here > really to define a new "ietf-interfaces-2" YANG module and require all > 50 or so YANG modules that augment IETF interfaces to be updated? > > It seems that this would be a much more impactful change than allowing > an NBC change to that module, and documenting that as version 2.0.0. > > I am sure that if YANG allows NBC changes then some folks will use > them for purposes that they should not. But I also believe that those > same folk will make those same changes regardless of what an RFC > states. But I also think that many vendors will try and use NBC > changes as a way to make their models better, improve the quality of > YANG data models. > > > > > > > In short, I don't agree with the premise that the current YANG > > > versioning schema using revision dates is working just fine, and no > > > changes are needed. > > > > But this is not what the draft is about! There is nothing in the > > draft that talks > > about problems introduced by using the revision dates. > [RW] > > I think that "revision-date" and RFC 7950 section 11 module update > rules go hand in hand. > > If your objection is that we don't quite describe the problem clearly > enough then that can be fixed. > > My interpretation is that your objection is more fundamental than > that. Yes. > I.e. you don't think that we should be using semantic > versioning at all My objection is that I don't agree with the problem statement and I don't think that we should allow NBC in published modules. /martin > , and we should keep RFC 7950 section 11 rules and > revision dates for versioning YANG models. But I think that the > overwhelming evidence is that the current scheme does not work for > everyone, even if it might be sufficient for YANG modules produced in > the IETF. > > Thanks, > Rob > > > > > > > > /martin > > > > > > > > > > > > Thanks, > > > Rob > > > > > > > > > -----Original Message----- > > > From: netmod On Behalf Of Martin Bjorklund > > > Sent: 19 March 2019 15:12 > > > To: kent+ietf@watsen.net > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > > > Hi, > > > > > > I have read this document, and I do not think it should be adopted. > > > > > > I object to the idea that we should allow non-backwards-compatible > > > changes to published YANG modules. > > > > > > The draft motivates this idea with: > > > > > > we must recognize that many YANG > > > modules are actually generated YANG modules (for example, from > > > internal databases) > > > > > > I do not agree that we should change what we allow in published > > > modules b/c of this. > > > > > > It also motivates this idea with: > > > > > > The points made above lead to the logical conclusion that the > > > standardized YANG modules have to be perfect on day one (at least the > > > structure and meaning), which in turn might explain why IETF YANG > > > modules take so long to standardize. > > > > > > I disagree with this. First of all, we have already published > > > revision two of several YANG modules (ietf-inet-types, ietf-yang-type, > > > ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that > > > "standardized YANG modules have to be perfect on day one" is simply > > > not true. > > > > > > Second, I don't think the upgrade rules are the reason it takes a long > > > time to standardize IETF models (I think it has to do with the process > > > itself, including the fact that models get reviews from many different > > > people with different background.) [BTW, is it true that drafts with > > > YANG models take longer time from wg -00 to published RFC than other > > > drafts?] > > > > > > > > > This said, I think there are some important points that the draft > > > raises, and that I think we should continue to work on; specifically > > > 2.3, 2.5, 2.6, 2.7. But I don't think that these areas require > > > changes to the versioning scheme, and I think it is a mistake to > > > include these areas in this draft. > > > > > > Some comments on section 4, The Problem Statement: > > > > > > o Any non-backwards-compatible change of a definition requires > > > either a new module name or a new path. This has been found > > > costly to support in implementations, in particular on the client > > > side. > > > > > > Yes I agree there is a cost associated with this. But I have come > > > across vendor modules that make NBC changes w/o introducing a new > > > path, and this is also costly to handle. > > > > > > o Since non-backwards-compatible changes require either a new module > > > name or a new path, such changes will impact other modules that > > > import definitions. In fact, with the current module versioning > > > scheme other modules have to opt-in in order to use the new > > > version. This essentially leads to a ripple effect where a non- > > > backwards-compatible change of a core module causes updates on a > > > potentially large number of dependent modules. > > > > > > This is by design. We cannot have a situation where a legal > > > modification to a module leads to other modules becoming invalid. > > > > > > o YANG has a mechanism to mark definitions deprecated but it leaves > > > it open whether implementations are expected to implement > > > deprecated definitions and there is no way (other than trial and > > > error) for a client to find out whether deprecated definitions are > > > supported by a given implementation. > > > > > > As I wrote above, I agree that this is a problem that should be > > > solved. But this is not a motivation for changing YANG versioning. > > > > > > o YANG does not have a robust mechanism to document which data > > > definitions have changed and to provide guidance how > > > implementations should deal with the change. While it is possible > > > to have this described in general description statements, having > > > these details embedded in general description statements does not > > > make this information accessible to tools. > > > > > > This might also be worth exploring, but this is not a motivation for > > > changing YANG versioning. > > > > > > > > > > > > /martin > > > > > > > > > > > > Kent Watsen wrote: > > > > Seeing as how we all need to read this draft anyways, in preparation > > > > for our meeting in Prague, it seems like a good time for this poll. > > > > Thusly, this email begins a 1-week adoption poll for: > > > > > > > > > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs- > > > > 02 > > > > > > > -0 > > > > 2> > > > > > > > > Please voice your support or objections before March 20. > > > > > > > > Note that this draft defines *requirements* and its intended status > > > > is "Informational." I believe that it is good for WGs to formalize > > > > requirements, even taking such drafts thru Last Call, in order to > > > > ensure consensus on the requirements. This is the "adoption" call, > > > > to ascertain if the WG agrees with that statement; if adopted, a > > > > separate "last call" will be issued to ensure to correctness of the > > > > draft's content. > > > > > > > > Kent (and Lou and Joel) > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > From nobody Wed Mar 20 09:44:32 2019 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 129F412426A for ; Wed, 20 Mar 2019 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 EEpPwfoyplp3 for ; Wed, 20 Mar 2019 09:44:25 -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 CB65712AF7F for ; Wed, 20 Mar 2019 09:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66710; q=dns/txt; s=iport; t=1553100264; x=1554309864; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XPSbUy7E2wpH5H20kAbnPjJLL53VTTieJsVqYOJL+NI=; b=FH5xumd+R1EQq38BMooYlM+3ZMQexiLXv44vb459dGJF/LzGv1MjLqWw RTMO8rQqRD++8wccFiAEnozNi/3ZC3DU7LPxTxnFCvN/EPw6+eA7m2tcs gDpeK3mWLVcE802Ridn+X7p+fQ3q/PJl18wyRF4vwiAWdSxTRAX3fs3je g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABQbZJc/4gNJK1aCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYEOUwUqaIEDJwqDQ0CVR5g1FIFjBAs?= =?us-ascii?q?BARgBCoFUgi9GAheEUCI1CA0BAQMBAQkBAwJtHAyFSgEBAQMBAQEKDgkEBkE?= =?us-ascii?q?LBQcEAgEGAhEEAQEBIAEGAwICAiULFAkIAgQOBQgTgwiBEVwID48Fm2Z8M4Q?= =?us-ascii?q?wAQMChgKBLwGLMReBQD+DJX6DHgEBAgGBKwEIAwcBCQlDCIJMglcDiiAOMwK?= =?us-ascii?q?CA4QaHocii1xgCQKHXoQHh0EhgX1bhRiDS4gqjCmEZo0RAhEVgS0hAzMoPXF?= =?us-ascii?q?wFTuCbAmCDReBAAEJgkGFFIU/QTGKPwINF4EIgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208,217";a="247569602" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 16:44:23 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KGiNLM009960 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 16:44:23 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 11:44:22 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 20 Mar 2019 11:44:22 -0500 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: Martin Bjorklund , "kent+ietf@watsen.net" , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SCAAIXFgIAAwkJwgAB/4gD//9xAwA== Date: Wed, 20 Mar 2019 16:44:22 +0000 Message-ID: <2398c4d424274b1ea5dd9db649bef95f@XCH-RCD-007.cisco.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> In-Reply-To: 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.63.23.135] Content-Type: multipart/alternative; boundary="_000_2398c4d424274b1ea5dd9db649bef95fXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 16:44:30 -0000 --_000_2398c4d424274b1ea5dd9db649bef95fXCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KUmVnYXJkaW5nOg0KPiBJIGRvbid0IHRoaW5rIHRoZSB2ZXJzaW9uaW5nIGRh dGEgbm9kZXMgaXMgYSBnb29kIGlkZWEuDQo+IEkgaGF2ZSBzZWVuIGVudGlyZSBSRVNUIEFQSXMg YmUgdmVyc2lvbmVkLCBidXQgbm90IGluZGl2aWR1YWwgcGFyYW1ldGVycyB3aXRoaW4gdGhlIEFQ SS4NCj4gSG93IGRvIHlvdSB2ZXJzaW9uIHRoZSBtdXN0L3doZW4vcGF0aCByZWZlcmVuY2VzIGZy b20gb3RoZXIgb2JqZWN0cyB0aGF0IHBvaW50IGF0IHRoZSBkYXRhIG5vZGU/DQo+IFNvdW5kcyB3 YXkgdG9vIGNvbXBsZXggdG8gbWFuYWdlLg0KDQpUaGUgWUFORyBwYWNrYWdlcyBhbmQgdmVyc2lv biBzZWxlY3Rpb24gZHJhZnRzIGJvdGggcHJvcG9zZSB0aGF0IHRoZSBlbnRpcmUgQVBJIGlzIHZl cnNpb25lZC4gIEluIGZhY3QgaXQgcmVnYXJkcyBJRVRGIG1vZGVscywgdnMgT3BlbkNvbmZpZyBt b2RlbHMsIHZzIE5hdGl2ZSB2ZW5kb3IgbW9kZWxzIGFzIHNlcGFyYXRlIEFQSXMuDQoNClRoYW5r cywNClJvYg0KDQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KU2Vu dDogMjAgTWFyY2ggMjAxOSAxMzo0OA0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9u QGNpc2NvLmNvbT4NCkNjOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47IGtlbnQr aWV0ZkB3YXRzZW4ubmV0OyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBh ZG9wdGlvbiBwb2xsIGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQoNCg0KT24gV2VkLCBN YXIgMjAsIDIwMTkgYXQgNDo1NCBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNj by5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQpIaSBBbmR5LA0KDQpUaGFu a3MgZm9yIHRoZSBjb21tZW50cy4NCg0KMS4gUmVndWxhciBTZW12ZXIgMi4wLjAgKGFzIHBlciBz ZW12ZXIub3JnPGh0dHA6Ly9zZW12ZXIub3JnPikgYWxsb3dzIHNvbWUgYnJhbmNoaW5nLiAgSS5l LiB5b3UgY2FuIGNyZWF0ZSB2ZXJzaW9uIDIuMC4wIGJhc2VkIG9mIHZlcnNpb24gMS4xLjAsIGFu ZCB0aGVuIHN1YnNlcXVlbnRseSBjcmVhdGUgdmVyc2lvbiAxLjIuMCBiYXNlZCBvZiAxLjEuMC4g IFNvIHN0cnVjdHVyZSB3aXNlIHRoaXMgd291bGQgbG9naWNhbGx5IGxvb2sgbGlrZToNCg0KICAg MS4wLjANCiAgICAgIHwgXA0KICAgICAgfCAgIDEuMS4wIOKAkyAxLjIuMCAtIOKApg0KICAgICAg fA0KICAgMi4wLjANCiAgICAgIHwNCg0KSSBhbHNvIHJhaXNlZCBodHRwczovL2dpdGh1Yi5jb20v c2VtdmVyL3NlbXZlci9pc3N1ZXMvNTA0ICBvbiB0aGUgc2VtdmVyIDIuMC4wIGdpdGh1YiB0byBj b25maXJtIHRoYXQgbXkgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdCwgYW5kIG5vIG9uZSBoYXMg ZGlzcHV0ZWQgaXQgeWV0Lg0KDQoNClRoZSBudW1iZXJpbmcgbWF5IGFsbG93IGl0LCBidXQgaXQg aXMgbm90IHJlYWxseSBiZWluZyB1c2VkIHRoYXQgd2F5Lg0KSSBkb24ndCB0aGluayB0aGUgWUFO RyBzdGFuZGFyZCBuZWVkcyB0byBzdXBwb3J0IGJyYW5jaGluZyBpbiB0aGlzIHdheS4NCg0KDQoy LiBWZW5kb3Igc29mdHdhcmUgcmVsZWFzZXMgY2FuIGhhdmUgYSB2ZXJ5IGxvbmcgc3VwcG9ydCB0 aW1lIChlLmcuIGVhc2lseSA1KyB5ZWFycyksIHdpdGggYW4gZXhwZWN0YXRpb24gdGhhdCBidWdz IGdldCBmaXhlZC4gIFJlcXVpcmluZyB0aGF0IGN1c3RvbWVycyB1cGdyYWRlIHRoZWlyIHNvZnR3 YXJlIChvciBwZXJoYXBzIGhhcmR3YXJlKSB0byB0aGUgdmVyeSBsYXRlc3Qgc29mdHdhcmUgdmVy c2lvbiB0byBwaWNrIHVwIGEgc21hbGwgYnVnIGZpeCBpcyBub3QgcmVhbGlzdGljLiAgVGhpcyBp cyBwcmltYXJpbHkgd2h5IEkgdGhpbmsgdGhhdCB0aGUg4oCYbeKAmSBhbmQg4oCYTeKAmSBhcmUg c28gaW1wb3J0YW50LiAgVGhleSBhbGxvdyBmb3IgYnVnIGZpeGVzIGluIGEgd2F5IHRoYXQgU2Vt dmVyIDIuMC4wIHNpbXBseSBkb2VzIG5vdC4NCg0KU2VtdmVyIDIuMC4wIG9ubHkgYWxsb3dzIGZv ciBidWdmaXhlcyBpbiB0aGUgaW1wbGVtZW50YXRpb24gKGJ5IHVwZGF0aW5nIHRoZSBwYXRjaCB2 ZXJzaW9uIG51bWJlciksIGJ1dCBoYXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhlcmUgYXJlICpu ZXZlciogYW55IG5vbi1iYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2VzIGluIHRoZSBBUEksIG5v dCBldmVuIHRvIGZpeCBhIGJ1ZywgZXhjZXB0IGF0IHRoZSB0aXAgb2YgdGhlIGRldmVsb3BtZW50 IHRyZWUuDQoNCkluIHNob3J0LCBJIHRoaW5rIHRoYXQgdmFuaWxsYSBTZW12ZXIgMi4wLjAgaXMg YSBnb29kIGZpdCBmb3Igb3BlbiBzb3VyY2UgcHJvamVjdHMgd2hlcmUgeW91IGNhbiBqdXN0IHRl bGwgdGhlIGNsaWVudCB0byB1cGRhdGUgdG8gdGhlIGxhdGVzdCB2ZXJzaW9uIHRvIHBpY2sgdXAg dGhlIGZpeC4gIEkgZG9u4oCZdCB0aGluayB0aGF0IFNlbXZlciAyLjAuMCBpcyBzbyB3ZWxsIGFs aWduZWQgdG8gQVBJcyB0aGF0IGFyZSByZXF1aXJlZCB0byBiZSBtYWludGFpbmVkIGZvciBsb25n IHBlcmlvZHMgb2YgdGltZS4NCg0KVGhlIGFsdGVybmF0aXZlIHRoYXQgUm9iIFNoYWtpciBtZW50 aW9uZWQgYXQgSUVURiAxMDMgaW4gdGhlIGNvbnRleHQgb2YgT3BlbkNvbmZpZywgd2hpY2ggdXNl cyBzdHJpY3QgU2VtdmVyIDIuMC4wLCBpcyB0byBoYW5kbGUgdGhlc2UgYnVnIGZpeGVzIHVzaW5n IGRldmlhdGlvbnMuICBCdXQgaXQgc2VlbXMgdG8gYmUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBs ZXggdG8gbWFuYWdlIGJ1ZyBmaXhlcyB1c2luZyBleHRyYSBkZXZpYXRpb24gbW9kdWxlcyByYXRo ZXIgdGhhbiBhbGxvd2luZyB0aGUg4oCYbeKAmSB8IOKAmE3igJkgbW9kaWZpZXJzLiAgVmVyc2lv bmluZyB3b3VsZCBubyBsb25nZXIgbGltaXRlZCB0byBhIG1vZHVsZSB2ZXJzaW9uIG51bWJlciwg YnV0IHJlcXVpcmUga25vd2xlZGdlIG9mIHRoZSBtb2R1bGUgdmVyc2lvbiBhbmQgc2V0IG9mIGRl dmlhdGlvbnMgdGhhdCBhcmUgYXBwbGllZCB0byBpdC4gIEkgd291bGQgcmF0aGVyIGRldmlhdGlv bnMgYXJlIHJlc2VydmVkIHRvIGluZGljYXRlIHdoZXRoZXIgYW4gaW1wbGVtZW50YXRpb24gZG9l c27igJl0IG1hdGNoIHRoZSBtb2R1bGUgc3BlY2lmaWNhdGlvbiByYXRoZXIgdGhhbiB1c2UgdGhl bSBhcyBhIHdheSBvZiBmaXhpbmcgYnVncyBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpdHNlbGYuDQoN Cg0KDQpJIGFncmVlIHRoYXQgZGV2aWF0aW9ucyBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIG9mIGJy YW5jaGluZy4NCllvdSBjYW4gY2hlcnJ5LXBpY2sgZmVhdHVyZXMgZnJvbSB0aGUgbGF0ZXN0IHZl cnkgZWFzaWx5IHdpdGggZGV2aWF0aW9ucy4NCklNTyBpdCBpcyBtb3JlIGFjY3VyYXRlIHRvIHNh eSB0aGUgaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgdmVyc2lvbiBYIG1pbnVzIHNvbWUgZmVhdHVy ZXMsDQpyYXRoZXIgdGhhbiBhc3NpZ25pbmcgc29tZSB2ZXJzaW9uIHN0cmluZyB0byBtZWFuIHRo ZSBzYW1lIHRoaW5nLiAgVGhpcyBhcHByb2FjaCBjYW4gZ2V0DQpvdXQgb2YgY29udHJvbCB2ZXJ5 IHF1aWNrbHkgaWYgbXVsdGlwbGUgaW5kZXBlbmRlbnQgcmVsZWFzZSB0cmFpbnMgZXhpc3QuIEkg cHJlZmVyIGEgbGluZWFyDQpkZXZlbG9wbWVudCBwcm9ncmVzc2lvbiwgYW5kIGVhY2ggaW1wbGVt ZW50YXRpb24gd2lsbCBpZGVudGl0eSBpdHMgZnVuY3Rpb25hbGl0eSB0aGUgc2FtZSB3YXkuDQoN Cg0KDQozLiBJIGFncmVlIHRoYXQgdGhlIHVzZSBvZiBTZW12ZXIgKyBwYWNrYWdlcyArIHZlcnNp b24gc2VsZWN0aW9uIGRvZXMgbm90IHJlZHVjZSB0aGUgb3ZlcmFsbCBudW1iZXIgb2YgcGF0aHMg dG8gYSBjb25maWd1cmFibGUgcHJvcGVydHksIGJ1dCBpdCBkb2VzIGVuc3VyZSB0aGF0IHRoZXJl IGlzIG9ubHkgYSBzaW5nbGUgcGF0aCB0byBhIGNvbmZpZ3VyYWJsZSBwcm9wZXJ0eSB3aXRoaW4g YSBZQU5HIGRhdGFzdG9yZSBzY2hlbWEuICAgU28gd2hpY2hldmVyIHZlcnNpb24gZWFjaCBjbGll bnQgaXMgdXNpbmcsIHRoZXkgb25seSB1c2UgYSBzaW5nbGUgcGF0aC4gIEkuZS4gbWlycm9yaW5n IHRoZSB3YXkgdGhhdCBhIGNsYXNzaWMgcHJvZ3JhbW1pbmcgQVBJIG1pZ2h0IGJlIHZlcnNpb25l ZC4NCg0KU2VydmVycyB0aGF0IHdpc2ggdG8gc3VwcG9ydCB0aGlzIHdvdWxkIGhhdmUgdG8gbWFw IHRoZSBkYXRhIGJldHdlZW4gZGlmZmVyZW50IFlBTkcgZGF0YXN0b3JlIHNjaGVtYSB2ZXJzaW9u cy4gIE5vdCBhbGwgbWFwcGluZ3MgYXJlIHBvc3NpYmxlLCBidXQgYXQgbGVhc3QgYW55IGNhc2Vz IHdoZXJlIGl0IGlzIG5vdCBwb3NzaWJsZSBjYW4gYmUgZGV0ZWN0ZWQgYW5kIHJlcG9ydGVkIHRv IHRoZSBjbGllbnQgdmlhIGFuIG91dCBvZiBiYW5kIG1lY2hhbmlzbS4NCg0KSWYgdGhlIG1vZHVs ZSBjb250ZW50IGNoYW5nZXMgc2lnbmlmaWNhbnRseSBiZXR3ZWVuIG1vZHVsZSB2ZXJzaW9ucyB0 aGF0IG1hcHBpbmcgd2lsbCBiZSBtdWNoIGhhcmRlciB0aGFuIGlmIHRoZSBjaGFuZ2VzIGFyZSBt aW5pbWFsIG9yIGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgU28gdGhlcmUgaXMgc3RpbGwgYSBzdHJv bmcgaW5jZW50aXZlIGZvciBtb2RlbCB3cml0ZXJzIHRvIG1pbmltaXplIGNodXJuIHRvIHRoZSBZ QU5HIG1vZGVscy4NCg0KDQpJIGRvbid0IHRoaW5rIHRoZSB2ZXJzaW9uaW5nIGRhdGEgbm9kZXMg aXMgYSBnb29kIGlkZWEuDQpJIGhhdmUgc2VlbiBlbnRpcmUgUkVTVCBBUElzIGJlIHZlcnNpb25l ZCwgYnV0IG5vdCBpbmRpdmlkdWFsIHBhcmFtZXRlcnMgd2l0aGluIHRoZSBBUEkuDQpIb3cgZG8g eW91IHZlcnNpb24gdGhlIG11c3Qvd2hlbi9wYXRoIHJlZmVyZW5jZXMgZnJvbSBvdGhlciBvYmpl Y3RzIHRoYXQgcG9pbnQgYXQgdGhlIGRhdGEgbm9kZT8NClNvdW5kcyB3YXkgdG9vIGNvbXBsZXgg dG8gbWFuYWdlLg0KDQpUaGFua3MsDQpSb2INCg0KDQpBbmR5DQoNCg0KRnJvbTogQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpTZW50 OiAxOSBNYXJjaCAyMDE5IDE4OjM1DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+DQpDYzogTWFydGluIEJqb3JrbHVu ZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj47IGtlbnQraWV0ZkB3YXRz ZW4ubmV0PG1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0PjsgbmV0bW9kQGlldGYub3JnPG1h aWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gYWRvcHRpb24gcG9s bCBmb3IgeWFuZy12ZXJzaW9uaW5nLXJlcXMtMDINCg0KDQoNCk9uIFR1ZSwgTWFyIDE5LCAyMDE5 IGF0IDk6MzggQU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0 bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHRo ZSByZXZpZXcgYW5kIGNvbW1lbnRzLg0KDQpBIGNvdXBsZSBvZiBwb2ludHM6DQoNCjEpIExvdHMg b2YgbW9kZWxzIG91dHNpZGUgdGhvc2UgcHVibGlzaGVkIGluIFNET3MgYXJlIGFscmVhZHkgbm90 IGZvbGxvd2luZyB0aGUgUkZDIDc5NTAgcmV2aXNpb24gcnVsZXMuICBJIHRoaW5rIHRoYXQgaXQg aXMgYmV0dGVyIHRvIGhhdmUgYSB2ZXJzaW9uaW5nIHNjaGVtZSB0aGF0IHJlZmxlY3RzIGhvdyBZ QU5HIG1vZGVscyBhcmUgYWN0dWFsbHkgZXZvbHZpbmcgcmF0aGVyIHRoYW4gaGF2ZSBhbGwgdmVu ZG9yIGFuZCBPQyBZQU5HIG1vZHVsZXMgZWl0aGVyIGp1c3QgaWdub3JpbmcgdGhlIHJ1bGVzLCBv ciB1c2luZyBjbGV2ZXIgdHJpY2tzIHRoYXQgc3RyaWN0bHkgY29uZm9ybSB3aXRoIHRoZSBydWxl cyBidXQgZ28gYWdhaW5zdCB0aGUgc3Bpcml0IG9mIHRoZW0gKGUuZy4ganVzdCBwdWJsaXNoIGFu IGVudGlyZWx5IG5ldyBzZXQgb2YgWUFORyBtb2R1bGVzIGZvciBlYWNoIHJlbGVhc2UpLiAgQWxz byBub3RpbmcgdGhhdCBoYXZpbmcgYSBzY2hlbWUgdGhhdCBhbGxvd3Mgbm9uLWJhY2t3YXJkcy1j b21wYXRpYmxlIGNoYW5nZXMgZG9lcyBub3QgcmVxdWlyZSB0aGF0IGV2ZXJ5b25lIHVzZXMgdGhl bSAtIElFVEYgY291bGQgY29udGludWUgdG8gYWx3YXlzIHB1Ymxpc2ggYmFja3dhcmRzIGNvbXBh dGlibGUgbW9kdWxlcy4gIFRoZSBvYnZpb3VzIGFsdGVybmF0aXZlIGhlcmUgaXMgdGhhdCBlYWNo IHZlbmRvciBjb21lcyB1cCB3aXRoIHRoZWlyIG93biB2ZXJzaW9uaW5nIGV4dGVuc2lvbiBhbmQg aWdub3JlcyB0aGUgUkZDIDc5NTAgc2VjdGlvbiAxMSBydWxlcyBhbnl3YXksIGJ1dCBJJ20gbm90 IHN1cmUgaG93IHRoYXQgcmVhbGx5IGhlbHBzIGNsaWVudDwtPnNlcnZlciBpbnRlcm9wLg0KDQoN CkkgZG8gbm90IHN1cHBvcnQgYnJhbmNoaW5nIGZvciBZQU5HIG1vZGVscyBzbyBJIGRvIG5vdCBz dXBwb3J0ZWQgbW9kaWZpZWQgU0VNVkVSLg0KQWRkaW5nIGEgc3BlY2lhbCBjaGFyYWN0ZXIgdG8g dGhlIHZlcnNpb24gc3RyaW5nIGRvZXNuJ3QgaGVscCB0aGUgZGVwbG95ZWQgY2xpZW50IGNvZGUN CnRoYXQgc3RvcHMgd29ya2luZyB3aGVuIHRoZSBzZXJ2ZXIgY29kZSBpcyB1cGdyYWRlZC4gIFRo aXMgaXMgYSBxdWFsaXR5IGlzc3VlIHRoYXQNCmVhY2ggb3JnYW5pemF0aW9uIGhhcyB0byBkZWFs IHdpdGggdGhlIGJlc3QgdGhleSBjYW4uDQoNCkkgZG8gbm90IG9iamVjdCB0byB0aGUgYWRkaXRp b24gb2YgYSBTRU1WRVIgZmllbGQgdG8gYSBZQU5HIG1vZHVsZSBiZWNhdXNlIHRoZXNlIHZlcnNp b24NCnN0cmluZ3MgYXJlIGZhbWlsaWFyIHRvIHVzZXJzLiAgSXQgaXMgcG9zc2libGUgdG8gZXhw cmVzcyBpbXBvcnQgcmFuZ2VzIHN1Y2ggYXMgMS4yLiogKGFueSAxLjIueCByZWxlYXNlKQ0Kd2hp Y2ggYXJlIG5vdCBwb3NzaWJsZSB3aXRoIGRhdGUgc3RyaW5ncy4NCg0KDQoyKSBJIGRvbid0IHVu ZGVyc3RhbmQgaG93IHRoZSBSRkMgNzk1MCBhcHByb2FjaCBvZiAiZGVwcmVjYXRlIGEgYnVnZ3kg bm9kZSwgYW5kIHJlcGxhY2Ugd2l0aCBhIHdvcmtpbmcgbm9kZSIgcmVhbGx5IHdvcmtzIGluIHBy YWN0aWNlLCBwYXJ0aWN1bGFybHkgZm9yIGNvbmZpZ3VyYXRpb24gZGF0YSBub2RlcyB3aGVyZSB5 b3UgaGF2ZSB0d28gY2xpZW50cyBpbnRlcmFjdGluZyB3aXRoIGEgc2VydmVyLCBvbmUgaW50ZXJh Y3Rpbmcgd2l0aCB0aGUgb2xkIHBhdGgsIGFuZCBhbm90aGVyIHVzaW5nIHRoZSBuZXcgcGF0aC4g IFBlcmhhcHMgdGhlcmUgaXMgYSByb2J1c3Qgc2NoZW1lIHRoYXQgd29ya3MgaW4gYWxsIGNhc2Vz LCBidXQgaXQgaXNuJ3Qgb2J2aW91cyB0byBtZS4gIEhpc3RvcmljYWxseSwgZm9yIENMSSB3ZSBq dXN0IHRyYW5zbGF0ZSB0aGUgQ0xJIGZyb20gb2xkIHRvIG5ldyBmb3JtYXQgYW5kIHRoZW4gcmV0 dXJuIHRoZSBuZXcgZm9ybWF0IHdoZW4gdGhlIHJ1bm5pbmcgY29uZmlnIGlzIHJlcXVlc3RlZC4g IEJ1dCB0aGF0IHdpbGwgc3RpbGwgYnJlYWsgYW4gb2xkIGNsaWVudCB0aGF0IGRvZXNuJ3QgdW5k ZXJzdGFuZCBob3cgdG8gcmVhZCB0aGUgbmV3IENMSSwgZXZlbiBpZiB0aGUgc2VydmVyIHN1cHBv cnRzIHRoZW0gd3JpdGluZyB2aWEgdGhlIG9sZCBDTEkuDQoNClNFTVZFUiBkb2VzIG5vdCByZWR1 Y2UgdGhlIG51bWJlciBvZiBwYXRocyB0byB0aGUgdW5kZXJseWluZyBjb25maWd1cmF0aW9uIG9i amVjdC4NClRoYXQgcHJvYmxlbSBkb2VzIG5vdCBjaGFuZ2Ugd2hldGhlciBhIG5ldyBYUGF0aCBh YnNvbHV0ZS1wYXRoLWV4cHIgaXMgdXNlZA0Kb3Igd2hldGhlciB0aGUgc2FtZSBwYXRoIGlzIG92 ZXJsb2FkZWQgd2l0aCBzZW1hbnRpY3MgZGVyaXZlZCBmcm9tIGFkZGl0aW9uYWwgcHJvdG9jb2wg cGFyYW1ldGVycw0KKGUuZy4sIHZlcnNpb25pbmcgb2YgZWFjaCBkYXRhIG5vZGUpLiBJIHByZWZl ciB0aGUgZXhpc3RpbmcgWFBhdGggc29sdXRpb24gYmVjYXVzZSBpdCBpcyBleHBsaWNpdA0Kc28g dGhlIFlBTkcgcmVhZGVyIGNhbiBlYXNpbHkgc2VlIHRoZSBtdWx0aXBsZSBwYXRocywgYW5kIG5v IG5ldyBwcm90b2NvbCB3b3JrIG5lZWRlZCB0byBzdXBwb3J0IGl0Lg0KSWYgdGhlcmUgaXMgYW4g TkJDIGNoYW5nZSB0byBhbiBvYmplY3QgdGhlbiBhbGwgWFBhdGggYW5kIGxlYWZyZWYgcmVmZXJl bmNlcyB0byBpdCB3aWxsIHByb2JhYmx5IGJyZWFrLg0KVGhhdCBzZWVtcyBsaWtlIGEgaGFyZGVy IHByb2JsZW0gdG8gc29sdmUgdGhhbiB0aGUgb3JpZ2luYWwgcGF0aCBkdXBsaWNhdGlvbiBwcm9i bGVtLg0KDQoNCkV2ZW4gaWYgdGhlcmUgaXMgYSB3b3JrYWJsZSBzb2x1dGlvbiBmb3IgdGhpcyBz aW1wbGUgY2FzZSwgSSBzdXNwZWN0IHRoYXQgdGhlcmUgYXJlIG1hbnkgc2xpZ2h0bHkgbW9yZSBj b21wbGljYXRlZCBjYXNlcyB0aGF0IGRvbid0IHdvcmsgKGUuZy4gcmVrZXlpbmcgYSBsaXN0LCBj aGFuZ2luZyBkZWZhdWx0cywgaW5jb21wYXRpYmxlIHR5cGVzKS4NCg0KSW4gc2hvcnQsIEkgZG9u J3QgYWdyZWUgd2l0aCB0aGUgcHJlbWlzZSB0aGF0IHRoZSBjdXJyZW50IFlBTkcgdmVyc2lvbmlu ZyBzY2hlbWEgdXNpbmcgcmV2aXNpb24gZGF0ZXMgaXMgd29ya2luZyBqdXN0IGZpbmUsIGFuZCBu byBjaGFuZ2VzIGFyZSBuZWVkZWQuDQoNClRoYW5rcywNClJvYg0KDQpBbmR5DQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1hcnRpbiBC am9ya2x1bmQNClNlbnQ6IDE5IE1hcmNoIDIwMTkgMTU6MTINClRvOiBrZW50K2lldGZAd2F0c2Vu Lm5ldDxtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLm5ldD4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8 bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhZG9wdGlvbiBw b2xsIGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQpIaSwNCg0KSSBoYXZlIHJlYWQgdGhp cyBkb2N1bWVudCwgYW5kIEkgZG8gbm90IHRoaW5rIGl0IHNob3VsZCBiZSBhZG9wdGVkLg0KDQpJ IG9iamVjdCB0byB0aGUgaWRlYSB0aGF0IHdlIHNob3VsZCBhbGxvdyBub24tYmFja3dhcmRzLWNv bXBhdGlibGUgY2hhbmdlcyB0byBwdWJsaXNoZWQgWUFORyBtb2R1bGVzLg0KDQpUaGUgZHJhZnQg bW90aXZhdGVzIHRoaXMgaWRlYSB3aXRoOg0KDQogICB3ZSBtdXN0IHJlY29nbml6ZSB0aGF0IG1h bnkgWUFORw0KICAgbW9kdWxlcyBhcmUgYWN0dWFsbHkgZ2VuZXJhdGVkIFlBTkcgbW9kdWxlcyAo Zm9yIGV4YW1wbGUsIGZyb20NCiAgIGludGVybmFsIGRhdGFiYXNlcykNCg0KSSBkbyBub3QgYWdy ZWUgdGhhdCB3ZSBzaG91bGQgY2hhbmdlIHdoYXQgd2UgYWxsb3cgaW4gcHVibGlzaGVkIG1vZHVs ZXMgYi9jIG9mIHRoaXMuDQoNCkl0IGFsc28gbW90aXZhdGVzIHRoaXMgaWRlYSB3aXRoOg0KDQog ICBUaGUgcG9pbnRzIG1hZGUgYWJvdmUgbGVhZCB0byB0aGUgbG9naWNhbCBjb25jbHVzaW9uIHRo YXQgdGhlDQogICBzdGFuZGFyZGl6ZWQgWUFORyBtb2R1bGVzIGhhdmUgdG8gYmUgcGVyZmVjdCBv biBkYXkgb25lIChhdCBsZWFzdCB0aGUNCiAgIHN0cnVjdHVyZSBhbmQgbWVhbmluZyksIHdoaWNo IGluIHR1cm4gbWlnaHQgZXhwbGFpbiB3aHkgSUVURiBZQU5HDQogICBtb2R1bGVzIHRha2Ugc28g bG9uZyB0byBzdGFuZGFyZGl6ZS4NCg0KSSBkaXNhZ3JlZSB3aXRoIHRoaXMuICBGaXJzdCBvZiBh bGwsIHdlIGhhdmUgYWxyZWFkeSBwdWJsaXNoZWQgcmV2aXNpb24gdHdvIG9mIHNldmVyYWwgWUFO RyBtb2R1bGVzIChpZXRmLWluZXQtdHlwZXMsIGlldGYteWFuZy10eXBlLCBpZXRmLWludGVyZmFj ZXMsIGlldGYtaXAsIGlldGYtcm91dGluZywgLi4uKSwgc28gdGhlIHN0YXRlbWVudCB0aGF0ICJz dGFuZGFyZGl6ZWQgWUFORyBtb2R1bGVzIGhhdmUgdG8gYmUgcGVyZmVjdCBvbiBkYXkgb25lIiBp cyBzaW1wbHkgbm90IHRydWUuDQoNClNlY29uZCwgSSBkb24ndCB0aGluayB0aGUgdXBncmFkZSBy dWxlcyBhcmUgdGhlIHJlYXNvbiBpdCB0YWtlcyBhIGxvbmcgdGltZSB0byBzdGFuZGFyZGl6ZSBJ RVRGIG1vZGVscyAoSSB0aGluayBpdCBoYXMgdG8gZG8gd2l0aCB0aGUgcHJvY2VzcyBpdHNlbGYs IGluY2x1ZGluZyB0aGUgZmFjdCB0aGF0IG1vZGVscyBnZXQgcmV2aWV3cyBmcm9tIG1hbnkgZGlm ZmVyZW50IHBlb3BsZSB3aXRoIGRpZmZlcmVudCBiYWNrZ3JvdW5kLikgIFtCVFcsIGlzIGl0IHRy dWUgdGhhdCBkcmFmdHMgd2l0aCBZQU5HIG1vZGVscyB0YWtlIGxvbmdlciB0aW1lIGZyb20gd2cg LTAwIHRvIHB1Ymxpc2hlZCBSRkMgdGhhbiBvdGhlciBkcmFmdHM/XQ0KDQoNClRoaXMgc2FpZCwg SSB0aGluayB0aGVyZSBhcmUgc29tZSBpbXBvcnRhbnQgcG9pbnRzIHRoYXQgdGhlIGRyYWZ0IHJh aXNlcywgYW5kIHRoYXQgSSB0aGluayB3ZSBzaG91bGQgY29udGludWUgdG8gd29yayBvbjsgc3Bl Y2lmaWNhbGx5IDIuMywgMi41LCAyLjYsIDIuNy4gIEJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgdGhl c2UgYXJlYXMgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSB2ZXJzaW9uaW5nIHNjaGVtZSwgYW5kIEkg dGhpbmsgaXQgaXMgYSBtaXN0YWtlIHRvIGluY2x1ZGUgdGhlc2UgYXJlYXMgaW4gdGhpcyBkcmFm dC4NCg0KU29tZSBjb21tZW50cyBvbiBzZWN0aW9uIDQsIFRoZSBQcm9ibGVtIFN0YXRlbWVudDoN Cg0KICAgbyAgQW55IG5vbi1iYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2Ugb2YgYSBkZWZpbml0 aW9uIHJlcXVpcmVzDQogICAgICBlaXRoZXIgYSBuZXcgbW9kdWxlIG5hbWUgb3IgYSBuZXcgcGF0 aC4gIFRoaXMgaGFzIGJlZW4gZm91bmQNCiAgICAgIGNvc3RseSB0byBzdXBwb3J0IGluIGltcGxl bWVudGF0aW9ucywgaW4gcGFydGljdWxhciBvbiB0aGUgY2xpZW50DQogICAgICBzaWRlLg0KDQpZ ZXMgSSBhZ3JlZSB0aGVyZSBpcyBhIGNvc3QgYXNzb2NpYXRlZCB3aXRoIHRoaXMuICBCdXQgSSBo YXZlIGNvbWUgYWNyb3NzIHZlbmRvciBtb2R1bGVzIHRoYXQgbWFrZSBOQkMgY2hhbmdlcyB3L28g aW50cm9kdWNpbmcgYSBuZXcgcGF0aCwgYW5kIHRoaXMgaXMgYWxzbyBjb3N0bHkgdG8gaGFuZGxl Lg0KDQogICBvICBTaW5jZSBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlcyByZXF1aXJl IGVpdGhlciBhIG5ldyBtb2R1bGUNCiAgICAgIG5hbWUgb3IgYSBuZXcgcGF0aCwgc3VjaCBjaGFu Z2VzIHdpbGwgaW1wYWN0IG90aGVyIG1vZHVsZXMgdGhhdA0KICAgICAgaW1wb3J0IGRlZmluaXRp b25zLiAgSW4gZmFjdCwgd2l0aCB0aGUgY3VycmVudCBtb2R1bGUgdmVyc2lvbmluZw0KICAgICAg c2NoZW1lIG90aGVyIG1vZHVsZXMgaGF2ZSB0byBvcHQtaW4gaW4gb3JkZXIgdG8gdXNlIHRoZSBu ZXcNCiAgICAgIHZlcnNpb24uICBUaGlzIGVzc2VudGlhbGx5IGxlYWRzIHRvIGEgcmlwcGxlIGVm ZmVjdCB3aGVyZSBhIG5vbi0NCiAgICAgIGJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZSBvZiBh IGNvcmUgbW9kdWxlIGNhdXNlcyB1cGRhdGVzIG9uIGENCiAgICAgIHBvdGVudGlhbGx5IGxhcmdl IG51bWJlciBvZiBkZXBlbmRlbnQgbW9kdWxlcy4NCg0KVGhpcyBpcyBieSBkZXNpZ24uICBXZSBj YW5ub3QgaGF2ZSBhIHNpdHVhdGlvbiB3aGVyZSBhIGxlZ2FsIG1vZGlmaWNhdGlvbiB0byBhIG1v ZHVsZSBsZWFkcyB0byBvdGhlciBtb2R1bGVzIGJlY29taW5nIGludmFsaWQuDQoNCiAgIG8gIFlB TkcgaGFzIGEgbWVjaGFuaXNtIHRvIG1hcmsgZGVmaW5pdGlvbnMgZGVwcmVjYXRlZCBidXQgaXQg bGVhdmVzDQogICAgICBpdCBvcGVuIHdoZXRoZXIgaW1wbGVtZW50YXRpb25zIGFyZSBleHBlY3Rl ZCB0byBpbXBsZW1lbnQNCiAgICAgIGRlcHJlY2F0ZWQgZGVmaW5pdGlvbnMgYW5kIHRoZXJlIGlz IG5vIHdheSAob3RoZXIgdGhhbiB0cmlhbCBhbmQNCiAgICAgIGVycm9yKSBmb3IgYSBjbGllbnQg dG8gZmluZCBvdXQgd2hldGhlciBkZXByZWNhdGVkIGRlZmluaXRpb25zIGFyZQ0KICAgICAgc3Vw cG9ydGVkIGJ5IGEgZ2l2ZW4gaW1wbGVtZW50YXRpb24uDQoNCkFzIEkgd3JvdGUgYWJvdmUsIEkg YWdyZWUgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbSB0aGF0IHNob3VsZCBiZSBzb2x2ZWQuICBCdXQg dGhpcyBpcyBub3QgYSBtb3RpdmF0aW9uIGZvciBjaGFuZ2luZyBZQU5HIHZlcnNpb25pbmcuDQoN CiAgIG8gIFlBTkcgZG9lcyBub3QgaGF2ZSBhIHJvYnVzdCBtZWNoYW5pc20gdG8gZG9jdW1lbnQg d2hpY2ggZGF0YQ0KICAgICAgZGVmaW5pdGlvbnMgaGF2ZSBjaGFuZ2VkIGFuZCB0byBwcm92aWRl IGd1aWRhbmNlIGhvdw0KICAgICAgaW1wbGVtZW50YXRpb25zIHNob3VsZCBkZWFsIHdpdGggdGhl IGNoYW5nZS4gIFdoaWxlIGl0IGlzIHBvc3NpYmxlDQogICAgICB0byBoYXZlIHRoaXMgZGVzY3Jp YmVkIGluIGdlbmVyYWwgZGVzY3JpcHRpb24gc3RhdGVtZW50cywgaGF2aW5nDQogICAgICB0aGVz ZSBkZXRhaWxzIGVtYmVkZGVkIGluIGdlbmVyYWwgZGVzY3JpcHRpb24gc3RhdGVtZW50cyBkb2Vz IG5vdA0KICAgICAgbWFrZSB0aGlzIGluZm9ybWF0aW9uIGFjY2Vzc2libGUgdG8gdG9vbHMuDQoN ClRoaXMgbWlnaHQgYWxzbyBiZSB3b3J0aCBleHBsb3JpbmcsIGJ1dCB0aGlzIGlzIG5vdCBhIG1v dGl2YXRpb24gZm9yIGNoYW5naW5nIFlBTkcgdmVyc2lvbmluZy4NCg0KDQoNCi9tYXJ0aW4NCg0K DQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCUyQmlldGZA d2F0c2VuLm5ldD4+IHdyb3RlOg0KPiBTZWVpbmcgYXMgaG93IHdlIGFsbCBuZWVkIHRvIHJlYWQg dGhpcyBkcmFmdCBhbnl3YXlzLCBpbiBwcmVwYXJhdGlvbiBmb3Igb3VyIG1lZXRpbmcgaW4gUHJh Z3VlLCBpdCBzZWVtcyBsaWtlIGEgZ29vZCB0aW1lIGZvciB0aGlzIHBvbGwuICBUaHVzbHksIHRo aXMgZW1haWwgYmVnaW5zIGEgMS13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KPg0KPg0KPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmlu Zy1yZXFzLTAyDQo+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0 bW9kLXlhbmctdmVyc2lvbmluZy1yZXFzLTANCj4gMj4NCj4NCj4gUGxlYXNlIHZvaWNlIHlvdXIg c3VwcG9ydCBvciBvYmplY3Rpb25zIGJlZm9yZSBNYXJjaCAyMC4NCj4NCj4gTm90ZSB0aGF0IHRo aXMgZHJhZnQgZGVmaW5lcyAqcmVxdWlyZW1lbnRzKiBhbmQgaXRzIGludGVuZGVkIHN0YXR1cyBp cyAiSW5mb3JtYXRpb25hbC4iICAgSSBiZWxpZXZlIHRoYXQgaXQgaXMgZ29vZCBmb3IgV0dzIHRv IGZvcm1hbGl6ZSByZXF1aXJlbWVudHMsIGV2ZW4gdGFraW5nIHN1Y2ggZHJhZnRzIHRocnUgTGFz dCBDYWxsLCBpbiBvcmRlciB0byBlbnN1cmUgY29uc2Vuc3VzIG9uIHRoZSByZXF1aXJlbWVudHMu ICBUaGlzIGlzIHRoZSAiYWRvcHRpb24iIGNhbGwsIHRvIGFzY2VydGFpbiBpZiB0aGUgV0cgYWdy ZWVzIHdpdGggdGhhdCBzdGF0ZW1lbnQ7IGlmIGFkb3B0ZWQsIGEgc2VwYXJhdGUgImxhc3QgY2Fs bCIgd2lsbCBiZSBpc3N1ZWQgdG8gZW5zdXJlIHRvIGNvcnJlY3RuZXNzIG9mIHRoZSBkcmFmdCdz IGNvbnRlbnQuDQo+DQo+IEtlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQo+DQo+DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBs aXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_2398c4d424274b1ea5dd9db649bef95fXCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5SZWdhcmRpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBJIGRvbid0IHRoaW5rIHRoZSB2ZXJzaW9uaW5nIGRhdGEgbm9kZXMgaXMgYSBnb29kIGlk ZWEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEkgaGF2ZSBzZWVu IGVudGlyZSBSRVNUIEFQSXMgYmUgdmVyc2lvbmVkLCBidXQgbm90IGluZGl2aWR1YWwgcGFyYW1l dGVycyB3aXRoaW4gdGhlIEFQSS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgSG93IGRvIHlvdSB2ZXJzaW9uIHRoZSBtdXN0L3doZW4vcGF0aCByZWZlcmVuY2VzIGZy b20gb3RoZXIgb2JqZWN0cyB0aGF0IHBvaW50IGF0IHRoZSBkYXRhIG5vZGU/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFNvdW5kcyB3YXkgdG9vIGNvbXBsZXggdG8g bWFuYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgWUFORyBwYWNrYWdl cyBhbmQgdmVyc2lvbiBzZWxlY3Rpb24gZHJhZnRzIGJvdGggcHJvcG9zZSB0aGF0IHRoZSBlbnRp cmUgQVBJIGlzIHZlcnNpb25lZC4mbmJzcDsgSW4gZmFjdCBpdCByZWdhcmRzIElFVEYgbW9kZWxz LCB2cyBPcGVuQ29uZmlnDQogbW9kZWxzLCB2cyBOYXRpdmUgdmVuZG9yIG1vZGVscyBhcyBzZXBh cmF0ZSBBUElzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Sb2I8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5 IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAy MCBNYXJjaCAyMDE5IDEzOjQ4PGJyPg0KPGI+VG86PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAm bHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gQmpvcmtsdW5k ICZsdDttYmpAdGFpbC1mLmNvbSZndDs7IGtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDsgbmV0bW9k QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBhZG9wdGlvbiBwb2xs IGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAyMCwgMjAxOSBhdCA0OjU0 IEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNj by5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MS4gUmVndWxhciBT ZW12ZXIgMi4wLjAgKGFzIHBlcg0KPGEgaHJlZj0iaHR0cDovL3NlbXZlci5vcmciIHRhcmdldD0i X2JsYW5rIj5zZW12ZXIub3JnPC9hPikgYWxsb3dzIHNvbWUgYnJhbmNoaW5nLiZuYnNwOyBJLmUu IHlvdSBjYW4gY3JlYXRlIHZlcnNpb24gMi4wLjAgYmFzZWQgb2YgdmVyc2lvbiAxLjEuMCwgYW5k IHRoZW4gc3Vic2VxdWVudGx5IGNyZWF0ZSB2ZXJzaW9uIDEuMi4wIGJhc2VkIG9mIDEuMS4wLiZu YnNwOyBTbyBzdHJ1Y3R1cmUgd2lzZSB0aGlzIHdvdWxkIGxvZ2ljYWxseSBsb29rIGxpa2U6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IDEuMC4wPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgXA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fCZuYnNwOyAmbmJzcDsxLjEuMCDigJMgMS4yLjAgLSDigKYNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgMi4wLjA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkkgYWxzbyByYWlzZWQNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9z ZW12ZXIvc2VtdmVyL2lzc3Vlcy81MDQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5j b20vc2VtdmVyL3NlbXZlci9pc3N1ZXMvNTA0PC9hPiZuYnNwOyBvbiB0aGUgc2VtdmVyIDIuMC4w IGdpdGh1YiB0byBjb25maXJtIHRoYXQgbXkgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdCwgYW5k IG5vIG9uZSBoYXMgZGlzcHV0ZWQgaXQgeWV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbnVtYmVyaW5nIG1heSBhbGxvdyBpdCwgYnV0 IGl0IGlzIG5vdCByZWFsbHkgYmVpbmcgdXNlZCB0aGF0IHdheS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgdGhlIFlBTkcg c3RhbmRhcmQgbmVlZHMgdG8gc3VwcG9ydCBicmFuY2hpbmcgaW4gdGhpcyB3YXkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Mi4gVmVuZG9yIHNvZnR3YXJlIHJlbGVhc2VzIGNhbiBoYXZlIGEgdmVyeSBs b25nIHN1cHBvcnQgdGltZSAoZS5nLiBlYXNpbHkgNSYjNDM7IHllYXJzKSwgd2l0aCBhbiBleHBl Y3RhdGlvbg0KIHRoYXQgYnVncyBnZXQgZml4ZWQuJm5ic3A7IFJlcXVpcmluZyB0aGF0IGN1c3Rv bWVycyB1cGdyYWRlIHRoZWlyIHNvZnR3YXJlIChvciBwZXJoYXBzIGhhcmR3YXJlKSB0byB0aGUg dmVyeSBsYXRlc3Qgc29mdHdhcmUgdmVyc2lvbiB0byBwaWNrIHVwIGEgc21hbGwgYnVnIGZpeCBp cyBub3QgcmVhbGlzdGljLiZuYnNwOyBUaGlzIGlzIHByaW1hcmlseSB3aHkgSSB0aGluayB0aGF0 IHRoZSDigJht4oCZIGFuZCDigJhN4oCZIGFyZSBzbyBpbXBvcnRhbnQuJm5ic3A7IFRoZXkgYWxs b3cgZm9yDQogYnVnIGZpeGVzIGluIGEgd2F5IHRoYXQgU2VtdmVyIDIuMC4wIHNpbXBseSBkb2Vz IG5vdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZW12 ZXIgMi4wLjAgb25seSBhbGxvd3MgZm9yIGJ1Z2ZpeGVzIGluIHRoZSBpbXBsZW1lbnRhdGlvbiAo YnkgdXBkYXRpbmcgdGhlIHBhdGNoIHZlcnNpb24gbnVtYmVyKSwNCiBidXQgaGFzIHRoZSBleHBl Y3RhdGlvbiB0aGF0IHRoZXJlIGFyZSAqPGI+bmV2ZXI8L2I+KiBhbnkgbm9uLWJhY2t3YXJkcy1j b21wYXRpYmxlIGNoYW5nZXMgaW4gdGhlIEFQSSwgbm90IGV2ZW4gdG8gZml4IGEgYnVnLCBleGNl cHQgYXQgdGhlIHRpcCBvZiB0aGUgZGV2ZWxvcG1lbnQgdHJlZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBzaG9ydCwgSSB0aGluayB0aGF0IHZhbmls bGEgU2VtdmVyIDIuMC4wIGlzIGEgZ29vZCBmaXQgZm9yIG9wZW4gc291cmNlIHByb2plY3RzIHdo ZXJlIHlvdSBjYW4ganVzdA0KIHRlbGwgdGhlIGNsaWVudCB0byB1cGRhdGUgdG8gdGhlIGxhdGVz dCB2ZXJzaW9uIHRvIHBpY2sgdXAgdGhlIGZpeC4mbmJzcDsgSSBkb27igJl0IHRoaW5rIHRoYXQg U2VtdmVyIDIuMC4wIGlzIHNvIHdlbGwgYWxpZ25lZCB0byBBUElzIHRoYXQgYXJlIHJlcXVpcmVk IHRvIGJlIG1haW50YWluZWQgZm9yIGxvbmcgcGVyaW9kcyBvZiB0aW1lLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBhbHRlcm5hdGl2ZSB0aGF0IFJv YiBTaGFraXIgbWVudGlvbmVkIGF0IElFVEYgMTAzIGluIHRoZSBjb250ZXh0IG9mIE9wZW5Db25m aWcsIHdoaWNoIHVzZXMgc3RyaWN0DQogU2VtdmVyIDIuMC4wLCBpcyB0byBoYW5kbGUgdGhlc2Ug YnVnIGZpeGVzIHVzaW5nIGRldmlhdGlvbnMuJm5ic3A7IEJ1dCBpdCBzZWVtcyB0byBiZSBzaWdu aWZpY2FudGx5IG1vcmUgY29tcGxleCB0byBtYW5hZ2UgYnVnIGZpeGVzIHVzaW5nIGV4dHJhIGRl dmlhdGlvbiBtb2R1bGVzIHJhdGhlciB0aGFuIGFsbG93aW5nIHRoZSDigJht4oCZIHwg4oCYTeKA mSBtb2RpZmllcnMuJm5ic3A7IFZlcnNpb25pbmcgd291bGQgbm8gbG9uZ2VyIGxpbWl0ZWQgdG8g YSBtb2R1bGUgdmVyc2lvbg0KIG51bWJlciwgYnV0IHJlcXVpcmUga25vd2xlZGdlIG9mIHRoZSBt b2R1bGUgdmVyc2lvbiBhbmQgc2V0IG9mIGRldmlhdGlvbnMgdGhhdCBhcmUgYXBwbGllZCB0byBp dC4mbmJzcDsgSSB3b3VsZCByYXRoZXIgZGV2aWF0aW9ucyBhcmUgcmVzZXJ2ZWQgdG8gaW5kaWNh dGUgd2hldGhlciBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzbuKAmXQgbWF0Y2ggdGhlIG1vZHVsZSBz cGVjaWZpY2F0aW9uIHJhdGhlciB0aGFuIHVzZSB0aGVtIGFzIGEgd2F5IG9mIGZpeGluZyBidWdz DQogaW4gdGhlIHNwZWNpZmljYXRpb24gaXRzZWxmLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCBkZXZpYXRpb25zIHNo b3VsZCBiZSB1c2VkIGluc3RlYWQgb2YgYnJhbmNoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNhbiBjaGVycnktcGljayBmZWF0dXJl cyBmcm9tIHRoZSBsYXRlc3QgdmVyeSBlYXNpbHkgd2l0aCBkZXZpYXRpb25zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PIGl0IGlzIG1vcmUg YWNjdXJhdGUgdG8gc2F5IHRoZSBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyB2ZXJzaW9uIFggbWlu dXMgc29tZSBmZWF0dXJlcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnJhdGhlciB0aGFuIGFzc2lnbmluZyBzb21lIHZlcnNpb24gc3RyaW5nIHRv IG1lYW4gdGhlIHNhbWUgdGhpbmcuJm5ic3A7IFRoaXMgYXBwcm9hY2ggY2FuIGdldDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3V0IG9mIGNvbnRy b2wgdmVyeSBxdWlja2x5IGlmIG11bHRpcGxlIGluZGVwZW5kZW50IHJlbGVhc2UgdHJhaW5zIGV4 aXN0LiBJIHByZWZlciBhIGxpbmVhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+ZGV2ZWxvcG1lbnQgcHJvZ3Jlc3Npb24sIGFuZCBlYWNoIGltcGxl bWVudGF0aW9uIHdpbGwgaWRlbnRpdHkgaXRzIGZ1bmN0aW9uYWxpdHkgdGhlIHNhbWUgd2F5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+My4gSSBhZ3JlZSB0aGF0IHRoZSB1c2Ugb2YgU2VtdmVyICYj NDM7IHBhY2thZ2VzICYjNDM7IHZlcnNpb24gc2VsZWN0aW9uIGRvZXMgbm90IHJlZHVjZSB0aGUg b3ZlcmFsbCBudW1iZXINCiBvZiBwYXRocyB0byBhIGNvbmZpZ3VyYWJsZSBwcm9wZXJ0eSwgYnV0 IGl0IGRvZXMgZW5zdXJlIHRoYXQgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBwYXRoIHRvIGEgY29u ZmlndXJhYmxlIHByb3BlcnR5IHdpdGhpbiBhIFlBTkcgZGF0YXN0b3JlIHNjaGVtYS4gJm5ic3A7 Jm5ic3A7U28gd2hpY2hldmVyIHZlcnNpb24gZWFjaCBjbGllbnQgaXMgdXNpbmcsIHRoZXkgb25s eSB1c2UgYSBzaW5nbGUgcGF0aC4mbmJzcDsgSS5lLiBtaXJyb3JpbmcgdGhlIHdheSB0aGF0IGEg Y2xhc3NpYw0KIHByb2dyYW1taW5nIEFQSSBtaWdodCBiZSB2ZXJzaW9uZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VydmVycyB0aGF0IHdpc2ggdG8g c3VwcG9ydCB0aGlzIHdvdWxkIGhhdmUgdG8gbWFwIHRoZSBkYXRhIGJldHdlZW4gZGlmZmVyZW50 IFlBTkcgZGF0YXN0b3JlIHNjaGVtYQ0KIHZlcnNpb25zLiZuYnNwOyBOb3QgYWxsIG1hcHBpbmdz IGFyZSBwb3NzaWJsZSwgYnV0IGF0IGxlYXN0IGFueSBjYXNlcyB3aGVyZSBpdCBpcyBub3QgcG9z c2libGUgY2FuIGJlIGRldGVjdGVkIGFuZCByZXBvcnRlZCB0byB0aGUgY2xpZW50IHZpYSBhbiBv dXQgb2YgYmFuZCBtZWNoYW5pc20uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SWYgdGhlIG1vZHVsZSBjb250ZW50IGNoYW5nZXMgc2lnbmlmaWNhbnRseSBi ZXR3ZWVuIG1vZHVsZSB2ZXJzaW9ucyB0aGF0IG1hcHBpbmcgd2lsbCBiZSBtdWNoIGhhcmRlcg0K IHRoYW4gaWYgdGhlIGNoYW5nZXMgYXJlIG1pbmltYWwgb3IgYmFja3dhcmRzIGNvbXBhdGlibGUu Jm5ic3A7IFNvIHRoZXJlIGlzIHN0aWxsIGEgc3Ryb25nIGluY2VudGl2ZSBmb3IgbW9kZWwgd3Jp dGVycyB0byBtaW5pbWl6ZSBjaHVybiB0byB0aGUgWUFORyBtb2RlbHMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgdGhl IHZlcnNpb25pbmcgZGF0YSBub2RlcyBpcyBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzZWVuIGVudGlyZSBSRVNU IEFQSXMgYmUgdmVyc2lvbmVkLCBidXQgbm90IGluZGl2aWR1YWwgcGFyYW1ldGVycyB3aXRoaW4g dGhlIEFQSS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhvdyBkbyB5b3UgdmVyc2lvbiB0aGUgbXVzdC93aGVuL3BhdGggcmVmZXJlbmNlcyBmcm9t IG90aGVyIG9iamVjdHMgdGhhdCBwb2ludCBhdCB0aGUgZGF0YSBub2RlPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U291bmRzIHdheSB0b28gY29t cGxleCB0byBtYW5hZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzLDxicj4NClJvYjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keQ0KIEJpZXJtYW4g Jmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5h bmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE5IE1hcmNoIDIw MTkgMTg6MzU8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVm PSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5yd2lsdG9uQGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVm PSJtYWlsdG86bWJqQHRhaWwtZi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwv YT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQiIHRhcmdldD0i X2JsYW5rIj5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIGFkb3B0aW9uIHBvbGwgZm9yIHlhbmctdmVyc2lv bmluZy1yZXFzLTAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBNYXIgMTksIDIwMTkgYXQgOTozOCBBTSBSb2Ig V2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIE1hcnRpbiw8YnI+DQo8YnI+DQpUaGFua3MgZm9y IHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzLjxicj4NCjxicj4NCkEgY291cGxlIG9mIHBvaW50czo8 YnI+DQo8YnI+DQoxKSBMb3RzIG9mIG1vZGVscyBvdXRzaWRlIHRob3NlIHB1Ymxpc2hlZCBpbiBT RE9zIGFyZSBhbHJlYWR5IG5vdCBmb2xsb3dpbmcgdGhlIFJGQyA3OTUwIHJldmlzaW9uIHJ1bGVz LiZuYnNwOyBJIHRoaW5rIHRoYXQgaXQgaXMgYmV0dGVyIHRvIGhhdmUgYSB2ZXJzaW9uaW5nIHNj aGVtZSB0aGF0IHJlZmxlY3RzIGhvdyBZQU5HIG1vZGVscyBhcmUgYWN0dWFsbHkgZXZvbHZpbmcg cmF0aGVyIHRoYW4gaGF2ZSBhbGwgdmVuZG9yIGFuZCBPQyBZQU5HIG1vZHVsZXMNCiBlaXRoZXIg anVzdCBpZ25vcmluZyB0aGUgcnVsZXMsIG9yIHVzaW5nIGNsZXZlciB0cmlja3MgdGhhdCBzdHJp Y3RseSBjb25mb3JtIHdpdGggdGhlIHJ1bGVzIGJ1dCBnbyBhZ2FpbnN0IHRoZSBzcGlyaXQgb2Yg dGhlbSAoZS5nLiBqdXN0IHB1Ymxpc2ggYW4gZW50aXJlbHkgbmV3IHNldCBvZiBZQU5HIG1vZHVs ZXMgZm9yIGVhY2ggcmVsZWFzZSkuJm5ic3A7IEFsc28gbm90aW5nIHRoYXQgaGF2aW5nIGEgc2No ZW1lIHRoYXQgYWxsb3dzIG5vbi1iYWNrd2FyZHMtY29tcGF0aWJsZQ0KIGNoYW5nZXMgZG9lcyBu b3QgcmVxdWlyZSB0aGF0IGV2ZXJ5b25lIHVzZXMgdGhlbSAtIElFVEYgY291bGQgY29udGludWUg dG8gYWx3YXlzIHB1Ymxpc2ggYmFja3dhcmRzIGNvbXBhdGlibGUgbW9kdWxlcy4mbmJzcDsgVGhl IG9idmlvdXMgYWx0ZXJuYXRpdmUgaGVyZSBpcyB0aGF0IGVhY2ggdmVuZG9yIGNvbWVzIHVwIHdp dGggdGhlaXIgb3duIHZlcnNpb25pbmcgZXh0ZW5zaW9uIGFuZCBpZ25vcmVzIHRoZSBSRkMgNzk1 MCBzZWN0aW9uIDExIHJ1bGVzDQogYW55d2F5LCBidXQgSSdtIG5vdCBzdXJlIGhvdyB0aGF0IHJl YWxseSBoZWxwcyBjbGllbnQmbHQ7LSZndDtzZXJ2ZXIgaW50ZXJvcC48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBk byBub3Qgc3VwcG9ydCBicmFuY2hpbmcgZm9yIFlBTkcgbW9kZWxzIHNvIEkgZG8gbm90IHN1cHBv cnRlZCBtb2RpZmllZCBTRU1WRVIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFkZGluZyBhIHNwZWNpYWwgY2hhcmFjdGVyIHRvIHRoZSB2ZXJz aW9uIHN0cmluZyBkb2Vzbid0IGhlbHAgdGhlIGRlcGxveWVkIGNsaWVudCBjb2RlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoYXQgc3RvcHMg d29ya2luZyB3aGVuIHRoZSBzZXJ2ZXIgY29kZSBpcyB1cGdyYWRlZC4mbmJzcDsgVGhpcyBpcyBh IHF1YWxpdHkgaXNzdWUgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5lYWNoIG9yZ2FuaXphdGlvbiBoYXMgdG8gZGVhbCB3aXRoIHRoZSBi ZXN0IHRoZXkgY2FuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBkbyBub3Qgb2JqZWN0IHRvIHRoZSBhZGRpdGlvbiBvZiBhIFNFTVZF UiBmaWVsZCB0byBhIFlBTkcgbW9kdWxlIGJlY2F1c2UgdGhlc2UgdmVyc2lvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdHJpbmdzIGFyZSBm YW1pbGlhciB0byB1c2Vycy4mbmJzcDsgSXQgaXMgcG9zc2libGUgdG8gZXhwcmVzcyBpbXBvcnQg cmFuZ2VzIHN1Y2ggYXMgMS4yLiogKGFueSAxLjIueCByZWxlYXNlKTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj53aGljaCBhcmUgbm90IHBvc3Np YmxlIHdpdGggZGF0ZSBzdHJpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij4yKSBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBSRkMgNzk1MCBhcHByb2FjaCBv ZiAmcXVvdDtkZXByZWNhdGUgYSBidWdneSBub2RlLCBhbmQgcmVwbGFjZSB3aXRoIGEgd29ya2lu ZyBub2RlJnF1b3Q7IHJlYWxseSB3b3JrcyBpbiBwcmFjdGljZSwgcGFydGljdWxhcmx5IGZvciBj b25maWd1cmF0aW9uIGRhdGEgbm9kZXMgd2hlcmUNCiB5b3UgaGF2ZSB0d28gY2xpZW50cyBpbnRl cmFjdGluZyB3aXRoIGEgc2VydmVyLCBvbmUgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgb2xkIHBhdGgs IGFuZCBhbm90aGVyIHVzaW5nIHRoZSBuZXcgcGF0aC4mbmJzcDsgUGVyaGFwcyB0aGVyZSBpcyBh IHJvYnVzdCBzY2hlbWUgdGhhdCB3b3JrcyBpbiBhbGwgY2FzZXMsIGJ1dCBpdCBpc24ndCBvYnZp b3VzIHRvIG1lLiZuYnNwOyBIaXN0b3JpY2FsbHksIGZvciBDTEkgd2UganVzdCB0cmFuc2xhdGUg dGhlIENMSSBmcm9tDQogb2xkIHRvIG5ldyBmb3JtYXQgYW5kIHRoZW4gcmV0dXJuIHRoZSBuZXcg Zm9ybWF0IHdoZW4gdGhlIHJ1bm5pbmcgY29uZmlnIGlzIHJlcXVlc3RlZC4mbmJzcDsgQnV0IHRo YXQgd2lsbCBzdGlsbCBicmVhayBhbiBvbGQgY2xpZW50IHRoYXQgZG9lc24ndCB1bmRlcnN0YW5k IGhvdyB0byByZWFkIHRoZSBuZXcgQ0xJLCBldmVuIGlmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgdGhl bSB3cml0aW5nIHZpYSB0aGUgb2xkIENMSS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TRU1WRVIgZG9lcyBub3QgcmVkdWNl IHRoZSBudW1iZXIgb2YgcGF0aHMgdG8gdGhlIHVuZGVybHlpbmcgY29uZmlndXJhdGlvbiBvYmpl Y3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoYXQgcHJvYmxlbSBkb2VzIG5vdCBjaGFuZ2Ugd2hldGhlciBhIG5ldyBYUGF0aCBhYnNvbHV0 ZS1wYXRoLWV4cHIgaXMgdXNlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5vciB3aGV0aGVyIHRoZSBzYW1lIHBhdGggaXMgb3ZlcmxvYWRlZCB3 aXRoIHNlbWFudGljcyBkZXJpdmVkIGZyb20gYWRkaXRpb25hbCBwcm90b2NvbCBwYXJhbWV0ZXJz Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPihlLmcuLCB2ZXJzaW9uaW5nIG9mIGVhY2ggZGF0YSBub2RlKS4gSSBwcmVmZXIgdGhlIGV4 aXN0aW5nIFhQYXRoIHNvbHV0aW9uIGJlY2F1c2UgaXQgaXMgZXhwbGljaXQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c28gdGhlIFlBTkcgcmVh ZGVyIGNhbiBlYXNpbHkgc2VlIHRoZSBtdWx0aXBsZSBwYXRocywgYW5kIG5vIG5ldyBwcm90b2Nv bCB3b3JrIG5lZWRlZCB0byBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB0aGVyZSBpcyBhbiBOQkMgY2hhbmdlIHRvIGFu IG9iamVjdCB0aGVuIGFsbCBYUGF0aCBhbmQgbGVhZnJlZiByZWZlcmVuY2VzIHRvIGl0IHdpbGwg cHJvYmFibHkgYnJlYWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoYXQgc2VlbXMgbGlrZSBhIGhhcmRlciBwcm9ibGVtIHRvIHNvbHZlIHRo YW4gdGhlIG9yaWdpbmFsIHBhdGggZHVwbGljYXRpb24gcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+RXZlbiBpZiB0aGVyZSBpcyBhIHdvcmthYmxlIHNv bHV0aW9uIGZvciB0aGlzIHNpbXBsZSBjYXNlLCBJIHN1c3BlY3QgdGhhdCB0aGVyZSBhcmUgbWFu eSBzbGlnaHRseSBtb3JlIGNvbXBsaWNhdGVkIGNhc2VzIHRoYXQgZG9uJ3Qgd29yayAoZS5nLiBy ZWtleWluZyBhIGxpc3QsIGNoYW5naW5nIGRlZmF1bHRzLCBpbmNvbXBhdGlibGUNCiB0eXBlcyku PGJyPg0KPGJyPg0KSW4gc2hvcnQsIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUgcHJlbWlzZSB0aGF0 IHRoZSBjdXJyZW50IFlBTkcgdmVyc2lvbmluZyBzY2hlbWEgdXNpbmcgcmV2aXNpb24gZGF0ZXMg aXMgd29ya2luZyBqdXN0IGZpbmUsIGFuZCBubyBjaGFuZ2VzIGFyZSBuZWVkZWQuPGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IG5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhh bGYgT2YgTWFydGluIEJqb3JrbHVuZDxicj4NClNlbnQ6IDE5IE1hcmNoIDIwMTkgMTU6MTI8YnI+ DQpUbzogPGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQiIHRhcmdldD0iX2Js YW5rIj5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0 bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJy Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGFkb3B0aW9uIHBvbGwgZm9yIHlhbmctdmVyc2lvbmlu Zy1yZXFzLTAyPGJyPg0KPGJyPg0KSGksPGJyPg0KPGJyPg0KSSBoYXZlIHJlYWQgdGhpcyBkb2N1 bWVudCwgYW5kIEkgZG8gbm90IHRoaW5rIGl0IHNob3VsZCBiZSBhZG9wdGVkLjxicj4NCjxicj4N Ckkgb2JqZWN0IHRvIHRoZSBpZGVhIHRoYXQgd2Ugc2hvdWxkIGFsbG93IG5vbi1iYWNrd2FyZHMt Y29tcGF0aWJsZSBjaGFuZ2VzIHRvIHB1Ymxpc2hlZCBZQU5HIG1vZHVsZXMuPGJyPg0KPGJyPg0K VGhlIGRyYWZ0IG1vdGl2YXRlcyB0aGlzIGlkZWEgd2l0aDo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7d2UgbXVzdCByZWNvZ25pemUgdGhhdCBtYW55IFlBTkc8YnI+DQombmJzcDsgJm5ic3A7bW9k dWxlcyBhcmUgYWN0dWFsbHkgZ2VuZXJhdGVkIFlBTkcgbW9kdWxlcyAoZm9yIGV4YW1wbGUsIGZy b208YnI+DQombmJzcDsgJm5ic3A7aW50ZXJuYWwgZGF0YWJhc2VzKTxicj4NCjxicj4NCkkgZG8g bm90IGFncmVlIHRoYXQgd2Ugc2hvdWxkIGNoYW5nZSB3aGF0IHdlIGFsbG93IGluIHB1Ymxpc2hl ZCBtb2R1bGVzIGIvYyBvZiB0aGlzLjxicj4NCjxicj4NCkl0IGFsc28gbW90aXZhdGVzIHRoaXMg aWRlYSB3aXRoOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgcG9pbnRzIG1hZGUgYWJvdmUg bGVhZCB0byB0aGUgbG9naWNhbCBjb25jbHVzaW9uIHRoYXQgdGhlPGJyPg0KJm5ic3A7ICZuYnNw O3N0YW5kYXJkaXplZCBZQU5HIG1vZHVsZXMgaGF2ZSB0byBiZSBwZXJmZWN0IG9uIGRheSBvbmUg KGF0IGxlYXN0IHRoZTxicj4NCiZuYnNwOyAmbmJzcDtzdHJ1Y3R1cmUgYW5kIG1lYW5pbmcpLCB3 aGljaCBpbiB0dXJuIG1pZ2h0IGV4cGxhaW4gd2h5IElFVEYgWUFORzxicj4NCiZuYnNwOyAmbmJz cDttb2R1bGVzIHRha2Ugc28gbG9uZyB0byBzdGFuZGFyZGl6ZS48YnI+DQo8YnI+DQpJIGRpc2Fn cmVlIHdpdGggdGhpcy4mbmJzcDsgRmlyc3Qgb2YgYWxsLCB3ZSBoYXZlIGFscmVhZHkgcHVibGlz aGVkIHJldmlzaW9uIHR3byBvZiBzZXZlcmFsIFlBTkcgbW9kdWxlcyAoaWV0Zi1pbmV0LXR5cGVz LCBpZXRmLXlhbmctdHlwZSwgaWV0Zi1pbnRlcmZhY2VzLCBpZXRmLWlwLCBpZXRmLXJvdXRpbmcs IC4uLiksIHNvIHRoZSBzdGF0ZW1lbnQgdGhhdCAmcXVvdDtzdGFuZGFyZGl6ZWQgWUFORyBtb2R1 bGVzIGhhdmUgdG8gYmUgcGVyZmVjdCBvbiBkYXkgb25lJnF1b3Q7DQogaXMgc2ltcGx5IG5vdCB0 cnVlLjxicj4NCjxicj4NClNlY29uZCwgSSBkb24ndCB0aGluayB0aGUgdXBncmFkZSBydWxlcyBh cmUgdGhlIHJlYXNvbiBpdCB0YWtlcyBhIGxvbmcgdGltZSB0byBzdGFuZGFyZGl6ZSBJRVRGIG1v ZGVscyAoSSB0aGluayBpdCBoYXMgdG8gZG8gd2l0aCB0aGUgcHJvY2VzcyBpdHNlbGYsIGluY2x1 ZGluZyB0aGUgZmFjdCB0aGF0IG1vZGVscyBnZXQgcmV2aWV3cyBmcm9tIG1hbnkgZGlmZmVyZW50 IHBlb3BsZSB3aXRoIGRpZmZlcmVudCBiYWNrZ3JvdW5kLikmbmJzcDsgW0JUVywgaXMNCiBpdCB0 cnVlIHRoYXQgZHJhZnRzIHdpdGggWUFORyBtb2RlbHMgdGFrZSBsb25nZXIgdGltZSBmcm9tIHdn IC0wMCB0byBwdWJsaXNoZWQgUkZDIHRoYW4gb3RoZXIgZHJhZnRzP108YnI+DQo8YnI+DQo8YnI+ DQpUaGlzIHNhaWQsIEkgdGhpbmsgdGhlcmUgYXJlIHNvbWUgaW1wb3J0YW50IHBvaW50cyB0aGF0 IHRoZSBkcmFmdCByYWlzZXMsIGFuZCB0aGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnRpbnVlIHRv IHdvcmsgb247IHNwZWNpZmljYWxseSAyLjMsIDIuNSwgMi42LCAyLjcuJm5ic3A7IEJ1dCBJIGRv bid0IHRoaW5rIHRoYXQgdGhlc2UgYXJlYXMgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSB2ZXJzaW9u aW5nIHNjaGVtZSwgYW5kIEkgdGhpbmsgaXQgaXMgYSBtaXN0YWtlDQogdG8gaW5jbHVkZSB0aGVz ZSBhcmVhcyBpbiB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NClNvbWUgY29tbWVudHMgb24gc2VjdGlv biA0LCBUaGUgUHJvYmxlbSBTdGF0ZW1lbnQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO28mbmJz cDsgQW55IG5vbi1iYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2Ugb2YgYSBkZWZpbml0aW9uIHJl cXVpcmVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZWl0aGVyIGEgbmV3IG1vZHVsZSBuYW1l IG9yIGEgbmV3IHBhdGguJm5ic3A7IFRoaXMgaGFzIGJlZW4gZm91bmQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBjb3N0bHkgdG8gc3VwcG9ydCBpbiBpbXBsZW1lbnRhdGlvbnMsIGluIHBhcnRp Y3VsYXIgb24gdGhlIGNsaWVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNpZGUuPGJyPg0K PGJyPg0KWWVzIEkgYWdyZWUgdGhlcmUgaXMgYSBjb3N0IGFzc29jaWF0ZWQgd2l0aCB0aGlzLiZu YnNwOyBCdXQgSSBoYXZlIGNvbWUgYWNyb3NzIHZlbmRvciBtb2R1bGVzIHRoYXQgbWFrZSBOQkMg Y2hhbmdlcyB3L28gaW50cm9kdWNpbmcgYSBuZXcgcGF0aCwgYW5kIHRoaXMgaXMgYWxzbyBjb3N0 bHkgdG8gaGFuZGxlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvJm5ic3A7IFNpbmNlIG5vbi1i YWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2VzIHJlcXVpcmUgZWl0aGVyIGEgbmV3IG1vZHVsZTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IG5hbWUgb3IgYSBuZXcgcGF0aCwgc3VjaCBjaGFuZ2Vz IHdpbGwgaW1wYWN0IG90aGVyIG1vZHVsZXMgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGltcG9ydCBkZWZpbml0aW9ucy4mbmJzcDsgSW4gZmFjdCwgd2l0aCB0aGUgY3VycmVudCBtb2R1 bGUgdmVyc2lvbmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHNjaGVtZSBvdGhlciBtb2R1 bGVzIGhhdmUgdG8gb3B0LWluIGluIG9yZGVyIHRvIHVzZSB0aGUgbmV3PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgdmVyc2lvbi4mbmJzcDsgVGhpcyBlc3NlbnRpYWxseSBsZWFkcyB0byBhIHJp cHBsZSBlZmZlY3Qgd2hlcmUgYSBub24tPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmFja3dh cmRzLWNvbXBhdGlibGUgY2hhbmdlIG9mIGEgY29yZSBtb2R1bGUgY2F1c2VzIHVwZGF0ZXMgb24g YTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHBvdGVudGlhbGx5IGxhcmdlIG51bWJlciBvZiBk ZXBlbmRlbnQgbW9kdWxlcy48YnI+DQo8YnI+DQpUaGlzIGlzIGJ5IGRlc2lnbi4mbmJzcDsgV2Ug Y2Fubm90IGhhdmUgYSBzaXR1YXRpb24gd2hlcmUgYSBsZWdhbCBtb2RpZmljYXRpb24gdG8gYSBt b2R1bGUgbGVhZHMgdG8gb3RoZXIgbW9kdWxlcyBiZWNvbWluZyBpbnZhbGlkLjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDtvJm5ic3A7IFlBTkcgaGFzIGEgbWVjaGFuaXNtIHRvIG1hcmsgZGVmaW5p dGlvbnMgZGVwcmVjYXRlZCBidXQgaXQgbGVhdmVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg aXQgb3BlbiB3aGV0aGVyIGltcGxlbWVudGF0aW9ucyBhcmUgZXhwZWN0ZWQgdG8gaW1wbGVtZW50 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVwcmVjYXRlZCBkZWZpbml0aW9ucyBhbmQgdGhl cmUgaXMgbm8gd2F5IChvdGhlciB0aGFuIHRyaWFsIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGVycm9yKSBmb3IgYSBjbGllbnQgdG8gZmluZCBvdXQgd2hldGhlciBkZXByZWNhdGVkIGRl ZmluaXRpb25zIGFyZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1cHBvcnRlZCBieSBhIGdp dmVuIGltcGxlbWVudGF0aW9uLjxicj4NCjxicj4NCkFzIEkgd3JvdGUgYWJvdmUsIEkgYWdyZWUg dGhhdCB0aGlzIGlzIGEgcHJvYmxlbSB0aGF0IHNob3VsZCBiZSBzb2x2ZWQuJm5ic3A7IEJ1dCB0 aGlzIGlzIG5vdCBhIG1vdGl2YXRpb24gZm9yIGNoYW5naW5nIFlBTkcgdmVyc2lvbmluZy48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyBZQU5HIGRvZXMgbm90IGhhdmUgYSByb2J1c3Qg bWVjaGFuaXNtIHRvIGRvY3VtZW50IHdoaWNoIGRhdGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBkZWZpbml0aW9ucyBoYXZlIGNoYW5nZWQgYW5kIHRvIHByb3ZpZGUgZ3VpZGFuY2UgaG93PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW1wbGVtZW50YXRpb25zIHNob3VsZCBkZWFsIHdpdGgg dGhlIGNoYW5nZS4mbmJzcDsgV2hpbGUgaXQgaXMgcG9zc2libGU8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyB0byBoYXZlIHRoaXMgZGVzY3JpYmVkIGluIGdlbmVyYWwgZGVzY3JpcHRpb24gc3Rh dGVtZW50cywgaGF2aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlc2UgZGV0YWlscyBl bWJlZGRlZCBpbiBnZW5lcmFsIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgZG9lcyBub3Q8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBtYWtlIHRoaXMgaW5mb3JtYXRpb24gYWNjZXNzaWJsZSB0byB0 b29scy48YnI+DQo8YnI+DQpUaGlzIG1pZ2h0IGFsc28gYmUgd29ydGggZXhwbG9yaW5nLCBidXQg dGhpcyBpcyBub3QgYSBtb3RpdmF0aW9uIGZvciBjaGFuZ2luZyBZQU5HIHZlcnNpb25pbmcuPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KL21hcnRpbjxicj4NCjxicj4NCjxicj4NCjxicj4NCktlbnQg V2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a2VudCUyQmlldGZAd2F0c2VuLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsgU2VlaW5nIGFzIGhvdyB3ZSBhbGwgbmVlZCB0byByZWFkIHRoaXMgZHJhZnQgYW55d2F5cywg aW4gcHJlcGFyYXRpb24gZm9yIG91ciBtZWV0aW5nIGluIFByYWd1ZSwgaXQgc2VlbXMgbGlrZSBh IGdvb2QgdGltZSBmb3IgdGhpcyBwb2xsLiZuYnNwOyBUaHVzbHksIHRoaXMgZW1haWwgYmVnaW5z IGEgMS13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmluZy1yZXFzLTAyIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlh bmctdmVyc2lvbmluZy1yZXFzLTAyPC9hPiA8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmluZy1y ZXFzLTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmluZy1yZXFzLTA8L2E+PGJyPg0KJmd0OyAyJmd0Ozxi cj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlv bnMgYmVmb3JlIE1hcmNoIDIwLjxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3RlIHRoYXQgdGhpcyBk cmFmdCBkZWZpbmVzICpyZXF1aXJlbWVudHMqIGFuZCBpdHMgaW50ZW5kZWQgc3RhdHVzIGlzICZx dW90O0luZm9ybWF0aW9uYWwuJnF1b3Q7Jm5ic3A7ICZuYnNwO0kgYmVsaWV2ZSB0aGF0IGl0IGlz IGdvb2QgZm9yIFdHcyB0byBmb3JtYWxpemUgcmVxdWlyZW1lbnRzLCBldmVuIHRha2luZyBzdWNo IGRyYWZ0cyB0aHJ1IExhc3QgQ2FsbCwgaW4gb3JkZXIgdG8gZW5zdXJlIGNvbnNlbnN1cyBvbiB0 aGUgcmVxdWlyZW1lbnRzLiZuYnNwOyBUaGlzIGlzIHRoZSAmcXVvdDthZG9wdGlvbiZxdW90Ow0K IGNhbGwsIHRvIGFzY2VydGFpbiBpZiB0aGUgV0cgYWdyZWVzIHdpdGggdGhhdCBzdGF0ZW1lbnQ7 IGlmIGFkb3B0ZWQsIGEgc2VwYXJhdGUgJnF1b3Q7bGFzdCBjYWxsJnF1b3Q7IHdpbGwgYmUgaXNz dWVkIHRvIGVuc3VyZSB0byBjb3JyZWN0bmVzcyBvZiB0aGUgZHJhZnQncyBjb250ZW50Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBLZW50IChhbmQgTG91IGFuZCBKb2VsKTxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0 bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8 L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2398c4d424274b1ea5dd9db649bef95fXCHRCD007ciscocom_-- From nobody Wed Mar 20 11:10:21 2019 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 14BCB12AF7A for ; Wed, 20 Mar 2019 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 FS0jVG_N-8BM for ; Wed, 20 Mar 2019 11:10:06 -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 BF349131202 for ; Wed, 20 Mar 2019 11:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15817; q=dns/txt; s=iport; t=1553105404; x=1554315004; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=363w53kvgVrsoamSIPA53cilkZ9JUdvVsHU6lUoLqfI=; b=MxHffWKOkM0/6zwVVnzMPCTAJUcSAHpGwbbz6A4zmVGbBSmxTtBqVlWt +crTi3cyyKyrPQ3mwqvXZvFOMMVGO4koyurmZF9xPGA8fNwzIbH4hgryn zbXMZpeKgT7jv4pfnVDxDKPA+ik0rZ7Xul4uAhtwLqmwplzQrpJk062IP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAD3gJJc/40NJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBghBogQMnCplLmDUUgWcLAQEYC4FUgi9?= =?us-ascii?q?GAoRnIjYHDQEBAwEBCQEDAm0cDIVKAQEBAwEBASUTNAsMBAIBCA4DBAEBAR4?= =?us-ascii?q?QJwsdCAIEDgUIE4MIgW0ID6wGM4ovBYEvAYsiDxeBQD+BEYIUfoMeAQEDgSs?= =?us-ascii?q?BEgEJhXcDiiAOMwKGO5J+YAkCh16EB4dBIYF9hXODS4gqjCmEZo0RAhEVgS0?= =?us-ascii?q?mAi9lcXAVO4JsghYXiF+FP0Exik6BH4EfAQE?= X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208";a="452778125" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 18:10:03 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KIA35F032649 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 18:10:03 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 13:10:02 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 20 Mar 2019 13:10:02 -0500 From: "Rob Wilton (rwilton)" To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SCAAV5PAP//9h1QgAB1QYD//9ucoA== Date: Wed, 20 Mar 2019 18:10:02 +0000 Message-ID: <7bcc505f43154c80b6d57529ce429228@XCH-RCD-007.cisco.com> References: <20190320.083022.2046737837256499330.mbj@tail-f.com> <96f475459f6049bfa20c66412983f4a2@XCH-RCD-007.cisco.com> <20190320.145439.1107389062091531440.mbj@tail-f.com> In-Reply-To: <20190320.145439.1107389062091531440.mbj@tail-f.com> 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.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 18:10:20 -0000 Hi Martin, > -----Original Message----- > From: Martin Bjorklund > Sent: 20 March 2019 13:55 > To: Rob Wilton (rwilton) > Cc: kent+ietf@watsen.net; netmod@ietf.org > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 >=20 > "Rob Wilton (rwilton)" wrote: > > Hi Martin, > > > > > -----Original Message----- > > > From: Martin Bjorklund > > > Sent: 20 March 2019 07:30 > > > To: Rob Wilton (rwilton) > > > Cc: kent+ietf@watsen.net; netmod@ietf.org > > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > > > Hi, > > > > > > "Rob Wilton (rwilton)" wrote: > > > > Hi Martin, > > > > > > > > Thanks for the review and comments. > > > > > > > > A couple of points: > > > > > > > > 1) Lots of models outside those published in SDOs are already not > > > > following the RFC 7950 revision rules. > > > > > > Right, and I think that is ok. If vendors want to break backwards > > > compatibility it is up to them. With the current rules you can have > > > tool that detect this and flags it. You can then fix the problem or > > > release the new NBC module anyway, but you have been warned. > > > Customers will accept this or not. > > > > [RW] > > Revision-dates don't help here, and are not sufficient to indicate the > > true version history of a module when it is not chronologically > > ordered. > > > > Vendors want a way to accurately communicate to clients how the module > > is actually being changed, in a way that is easier for them to > > understand. >=20 > If I'm at 1.0.1M and see 1.0.2M it doesn't help me much. [RW]=20 In this case the client has to diff the YANG modules. This is the same as = going from 1.0.0 to 2.0.0. The aim of the 'm'|'M' is to *allow* models to be fixed with NBC changes if= required, it is not intended to encourage models to have lots of NBC chang= es. I.e. the scheme is deliberately restricted in the information that it = conveys as a means to prevent model authors from having carte blanche when = updating models. It is meant to be used as a last resort, and that is what= draft-verdt-netmod-yang-semver-00 tries to express. I argue that it is better to indicate an NBC bug fix to a client than to ei= ther (i) make the NBC bug fix but be unable to indicate it, or (ii) not be = able to fix an obvious bug in the model in case it might break a client. A= t least with semantic versioning a client is able to check whether they mig= ht get broken. >=20 > > > > I think that it is better to > > > > have a versioning scheme that reflects how YANG models are > > > > actually evolving rather than have all vendor and OC YANG modules > > > > either just ignoring the rules, or using clever tricks that > > > > strictly conform with the rules but go against the spirit of them > > > > (e.g. just publish an entirely new set of YANG modules for each > > > > release). Also noting that having a scheme that allows > > > > non-backwards-compatible changes does not require that everyone > > > > uses them - IETF could continue to always publish backwards > > > > compatible modules. The obvious alternative here is that each > > > > vendor comes up with their own versioning extension and ignores > > > > the RFC 7950 section 11 rules anyway, but I'm not sure how that rea= lly > helps client<->server interop. > > > > > > The client<->server interop will not magically work better if we > > > allow NBC changes. > > [RW] > > It helps clients understand the nature of the changes. >=20 > The draft we talk about does not mention anything about helping clients > understand the diffs, BC or not. That part of the work is still TBD. Section 1.2 of draft draft-verdt-netmo= d-yang-semver-00 talks about this. I still think that a tooling based module and schema comparison tool is imp= ortant, but it probably will require additional module annotations to be pr= operly useful. But I also still believe that having a semantic version number can greatly = help a module reader, in conjunction with the revision history, understand = the nature of the changes. >=20 > > I don't believe that vendors are making NBC changes to make client > > lives harder, they are trying to fix bugs and make their software > > better. I obviously agree that it would be better to put more effort > > into producing higher quality models in the first place, but there > > will always be mistakes, particularly for vendor models that have much > > less peer review than YANG modules produced by SDOs. > > > > > > > > > > > 2) I don't understand how the RFC 7950 approach of "deprecate a > > > > buggy node, and replace with a working node" really works in > > > > practice, particularly for configuration data nodes where you have > > > > two clients interacting with a server, one interacting with the > > > > old path, and another using the new path. Perhaps there is a > > > > robust scheme that works in all cases, but it isn't obvious to me. > > > > Historically, for CLI we just translate the CLI from old to new > > > > format and then return the new format when the running config is > > > > requested. But that will still break an old client that doesn't > > > > understand how to read the new CLI, even if the server supports the= m > writing via the old CLI. > > > > > > > > Even if there is a workable solution for this simple case, I > > > > suspect that there are many slightly more complicated cases that > > > > don't work (e.g. rekeying a list, changing defaults, incompatible t= ypes). > > > > > > I fully agree. This is difficult in the general case. In the worst > > > case you'll have to give up on backwards compatibility and only > > > implement the new version of the module (I believe this is possible > > > both with the current versioning rules, and with the proposed > > > rules). > > [RW] > > Implementing a new module and not supporting the old to fix one leaf >=20 > This is a strawman; I never recommended changing an entire module to fix = one > leaf. This is not intended as a strawman. How would you propose handling this change whilst keeping within the RFC 79= 50 rules? My understanding is that if this change was required then the on= ly option within the RFC 7950 rules would be to create an entirely new modu= le, with the massive impact that I describe. I.e. I don't think that the existing rules have a viable solution for this = sort of problem. For config false nodes, adding duplicate nodes & deprecat= ing is fine. For config true nodes, I'm just not convinced that the curren= t scheme works of adding a second configurable leaf works in a robust way. = =20 In particular, within a YANG schema I think that there should only be a sin= gle path for configuring a property (putting aside hierarchical config whic= h is OK). >=20 >=20 > > has a massive impact: > > - it breaks all clients using that module (regardless of whether they > > were using the leaf) > > - it forces updates to all modules that augment or depend on the old > > module. > > > > Say we hypothetically decide that "link-up-down-trap-enable" in RFC > > 8343 is wrong should be mandatory true. Is the right solution here > > really to define a new "ietf-interfaces-2" YANG module and require all > > 50 or so YANG modules that augment IETF interfaces to be updated? > > > > It seems that this would be a much more impactful change than allowing > > an NBC change to that module, and documenting that as version 2.0.0. > > > > I am sure that if YANG allows NBC changes then some folks will use > > them for purposes that they should not. But I also believe that those > > same folk will make those same changes regardless of what an RFC > > states. But I also think that many vendors will try and use NBC > > changes as a way to make their models better, improve the quality of > > YANG data models. > > > > > > > > > > > In short, I don't agree with the premise that the current YANG > > > > versioning schema using revision dates is working just fine, and > > > > no changes are needed. > > > > > > But this is not what the draft is about! There is nothing in the > > > draft that talks about problems introduced by using the revision > > > dates. > > [RW] > > > > I think that "revision-date" and RFC 7950 section 11 module update > > rules go hand in hand. > > > > If your objection is that we don't quite describe the problem clearly > > enough then that can be fixed. > > > > My interpretation is that your objection is more fundamental than > > that. >=20 > Yes. >=20 > > I.e. you don't think that we should be using semantic versioning at > > all >=20 > My objection is that I don't agree with the problem statement and I don't= think > that we should allow NBC in published modules. But on a practical level this seems to be the same as stating: "Published YANG modules MUST never have any bugs in any config true nodes." Thanks, Rob >=20 >=20 > /martin >=20 >=20 > > , and we should keep RFC 7950 section 11 rules and revision dates for > > versioning YANG models. But I think that the overwhelming evidence > > is that the current scheme does not work for everyone, even if it > > might be sufficient for YANG modules produced in the IETF. > > > > Thanks, > > Rob > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > -----Original Message----- > > > > From: netmod On Behalf Of Martin > > > > Bjorklund > > > > Sent: 19 March 2019 15:12 > > > > To: kent+ietf@watsen.net > > > > Cc: netmod@ietf.org > > > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > > > > > Hi, > > > > > > > > I have read this document, and I do not think it should be adopted. > > > > > > > > I object to the idea that we should allow non-backwards-compatible > > > > changes to published YANG modules. > > > > > > > > The draft motivates this idea with: > > > > > > > > we must recognize that many YANG > > > > modules are actually generated YANG modules (for example, from > > > > internal databases) > > > > > > > > I do not agree that we should change what we allow in published > > > > modules b/c of this. > > > > > > > > It also motivates this idea with: > > > > > > > > The points made above lead to the logical conclusion that the > > > > standardized YANG modules have to be perfect on day one (at leas= t the > > > > structure and meaning), which in turn might explain why IETF YAN= G > > > > modules take so long to standardize. > > > > > > > > I disagree with this. First of all, we have already published > > > > revision two of several YANG modules (ietf-inet-types, > > > > ietf-yang-type, ietf-interfaces, ietf-ip, ietf-routing, ...), so > > > > the statement that "standardized YANG modules have to be perfect > > > > on day one" is simply not true. > > > > > > > > Second, I don't think the upgrade rules are the reason it takes a > > > > long time to standardize IETF models (I think it has to do with > > > > the process itself, including the fact that models get reviews > > > > from many different people with different background.) [BTW, is > > > > it true that drafts with YANG models take longer time from wg -00 > > > > to published RFC than other drafts?] > > > > > > > > > > > > This said, I think there are some important points that the draft > > > > raises, and that I think we should continue to work on; > > > > specifically 2.3, 2.5, 2.6, 2.7. But I don't think that these > > > > areas require changes to the versioning scheme, and I think it is > > > > a mistake to include these areas in this draft. > > > > > > > > Some comments on section 4, The Problem Statement: > > > > > > > > o Any non-backwards-compatible change of a definition requires > > > > either a new module name or a new path. This has been found > > > > costly to support in implementations, in particular on the cl= ient > > > > side. > > > > > > > > Yes I agree there is a cost associated with this. But I have come > > > > across vendor modules that make NBC changes w/o introducing a new > > > > path, and this is also costly to handle. > > > > > > > > o Since non-backwards-compatible changes require either a new m= odule > > > > name or a new path, such changes will impact other modules th= at > > > > import definitions. In fact, with the current module version= ing > > > > scheme other modules have to opt-in in order to use the new > > > > version. This essentially leads to a ripple effect where a n= on- > > > > backwards-compatible change of a core module causes updates o= n a > > > > potentially large number of dependent modules. > > > > > > > > This is by design. We cannot have a situation where a legal > > > > modification to a module leads to other modules becoming invalid. > > > > > > > > o YANG has a mechanism to mark definitions deprecated but it le= aves > > > > it open whether implementations are expected to implement > > > > deprecated definitions and there is no way (other than trial = and > > > > error) for a client to find out whether deprecated definition= s are > > > > supported by a given implementation. > > > > > > > > As I wrote above, I agree that this is a problem that should be > > > > solved. But this is not a motivation for changing YANG versioning. > > > > > > > > o YANG does not have a robust mechanism to document which data > > > > definitions have changed and to provide guidance how > > > > implementations should deal with the change. While it is pos= sible > > > > to have this described in general description statements, hav= ing > > > > these details embedded in general description statements does= not > > > > make this information accessible to tools. > > > > > > > > This might also be worth exploring, but this is not a motivation > > > > for changing YANG versioning. > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > Seeing as how we all need to read this draft anyways, in > > > > > preparation for our meeting in Prague, it seems like a good time = for this > poll. > > > > > Thusly, this email begins a 1-week adoption poll for: > > > > > > > > > > > > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-r > > > > > eqs- > > > > > 02 > > > > > > > > > reqs > > > > > -0 > > > > > 2> > > > > > > > > > > Please voice your support or objections before March 20. > > > > > > > > > > Note that this draft defines *requirements* and its intended > > > > > status is "Informational." I believe that it is good for WGs to > > > > > formalize requirements, even taking such drafts thru Last Call, > > > > > in order to ensure consensus on the requirements. This is the > > > > > "adoption" call, to ascertain if the WG agrees with that > > > > > statement; if adopted, a separate "last call" will be issued to > > > > > ensure to correctness of the draft's content. > > > > > > > > > > Kent (and Lou and Joel) > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > From nobody Wed Mar 20 12:01:33 2019 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 9CC88131200 for ; Wed, 20 Mar 2019 12:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=OKb3JoZZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gvnu/H8/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36WOU6zHOCpw for ; Wed, 20 Mar 2019 12:01:22 -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 B544B131228 for ; Wed, 20 Mar 2019 12:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1184; q=dns/txt; s=iport; t=1553108478; x=1554318078; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6CsF4uEPPCmuFORdkH75otAJrs6EdOAEq2ujO72z3jc=; b=OKb3JoZZ7k+oSjZ5tTktCw0oN47kEBUWqQ/NmEktRupcEk/zYn10YumG Fd6ThZ89zNigTOe2SmKAJtRdsdyYUjlVeRZ31PfW6mX9dTygy9CCb1D+F imy6tQZveW6R5iX/Tv/E9qDq2H81tk79iZSijvv2i9fEqOzk2nSys7F90 o=; IronPort-PHdr: =?us-ascii?q?9a23=3AKiqytB3mAHzMgaYgsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACZjZJc/5pdJa1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9UAOBXAQLJ4QNg0cDhFKKVZlegS6BJANUCwEBLIR?= =?us-ascii?q?AAheEUCI0CQ0BAQMBAQkBAwJtHAyFSwYjEQwBATcBDwIBCBoCJgICAjAVEAI?= =?us-ascii?q?EAQ0FgyKBXgMVAQKgGQKKFHGBL4J4AQEFgkeCQxiCDAiBCyQBizEXgUA/gRE?= =?us-ascii?q?nH4JMhQEXgnMxgiaMaZgWCQKTLhmTZYsSkw4CBAIEBQIOAQEFgUw4KIEucBV?= =?us-ascii?q?lAYJBggqDbopTcoEoi2UBAQ?= X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208";a="537615377" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 19:01:17 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KJ1GYi031772 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 19:01:17 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 14:01:14 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 14:01:14 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Mar 2019 14:01:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6CsF4uEPPCmuFORdkH75otAJrs6EdOAEq2ujO72z3jc=; b=gvnu/H8/JhhiAe4TPZHicDR7ImwApPfKpMDfSUmmXCOkNCv1C4NkaGbw+DoQTOtV3Y/tXHA4BUmUPqpPTn0lcC3qNwcnS/pjoArWC+2PQ3GoQ+bXORFbzh3SLnjTSJY+VY6vcGw7tPHVvEcMISFs07eZPEzaDHkEggQIai4fT08= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB4111.namprd11.prod.outlook.com (20.179.150.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Wed, 20 Mar 2019 19:01:13 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1709.015; Wed, 20 Mar 2019 19:01:13 +0000 From: "Reshad Rahman (rrahman)" To: "Rob Wilton (rwilton)" , Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp7YypUbX6X+USrpPO25GlQu6YTGKGAgAAX0wCAAPlkAIAAUXGAgAAZ7YCAAEdbAP//yzyA Date: Wed, 20 Mar 2019 19:01:12 +0000 Message-ID: <2676EE99-AA69-4F46-B2FB-3B98C2BECB72@cisco.com> References: <20190320.083022.2046737837256499330.mbj@tail-f.com> <96f475459f6049bfa20c66412983f4a2@XCH-RCD-007.cisco.com> <20190320.145439.1107389062091531440.mbj@tail-f.com> <7bcc505f43154c80b6d57529ce429228@XCH-RCD-007.cisco.com> In-Reply-To: <7bcc505f43154c80b6d57529ce429228@XCH-RCD-007.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fcb934da-16e6-495a-2ac4-08d6ad666c28 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB4111; x-ms-traffictypediagnostic: MN2PR11MB4111: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-antispam-prvs: x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(136003)(376002)(39860400002)(189003)(199004)(105586002)(486006)(4326008)(82746002)(71200400001)(476003)(83716004)(2616005)(11346002)(7736002)(305945005)(6116002)(81166006)(68736007)(81156014)(5660300002)(446003)(186003)(46003)(71190400001)(8936002)(256004)(93886005)(6486002)(6436002)(6246003)(14454004)(8676002)(478600001)(229853002)(86362001)(4744005)(2906002)(6512007)(33656002)(316002)(53936002)(99286004)(6506007)(76176011)(25786009)(36756003)(106356001)(102836004)(97736004)(110136005)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4111; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VQqfvljnAMu2kZryVSS2FJrfKRpbTUQEqu3v5Jxa0Lu51MgMu7IddQdLleQXJhv9uKby/NjupXNxu555CNinzPUqPD+fA5g3n4XVZorCikazxe5Szcy7gPdEJC73hwHGRmxdNUyye+nWVD0VDVoNLpbeHM/y1h1J11nDI9jkvXgv3SDil5fCvhGISL8Z7K4NxwCtOLoIUTswvCDicYtzPYP9JhZsl/NhDmJpMu9nCteCGcXsVqCRvRJ5asBgtMrJBZWLw1uGCA5Zi64e08hnZ21gjYtvuDSMaWUKIT31XtMclGvzfWxcvjwDA9pDBUmY7gEF/zMmyonAY7s5ponCNGfXABA4VMW37q7sDcP+dLCfG/0uias1mJzeWXdwmesPF64OPM9uDOTTbGhYNyLoYT5zge6fGgGP2UwLXUyiuNg= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fcb934da-16e6-495a-2ac4-08d6ad666c28 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 19:01:12.9863 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4111 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 19:01:32 -0000 SGksDQoNCu+7v09uIDIwMTktMDMtMjAsIDI6MTIgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIFJv YiBXaWx0b24gKHJ3aWx0b24pIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhpIE1hcnRpbiwNCiAgICANCjxzbmlw Pg0KICAgID4gDQogICAgPiA+ICBJLmUuIHlvdSBkb24ndCB0aGluayB0aGF0IHdlIHNob3VsZCBi ZSB1c2luZyBzZW1hbnRpYyAgdmVyc2lvbmluZyBhdA0KICAgID4gPiBhbGwNCiAgICA+IA0KICAg ID4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBwcm9ibGVtIHN0 YXRlbWVudCBhbmQgSSBkb24ndCB0aGluaw0KICAgID4gdGhhdCB3ZSBzaG91bGQgYWxsb3cgTkJD IGluIHB1Ymxpc2hlZCBtb2R1bGVzLg0KICAgIA0KICAgIEJ1dCBvbiBhIHByYWN0aWNhbCBsZXZl bCB0aGlzIHNlZW1zIHRvIGJlIHRoZSBzYW1lIGFzIHN0YXRpbmc6DQogICAgDQogICAgIlB1Ymxp c2hlZCBZQU5HIG1vZHVsZXMgTVVTVCBuZXZlciBoYXZlIGFueSBidWdzIGluIGFueSBjb25maWcg dHJ1ZSBub2Rlcy4iDQogICAgDQogICAgVGhhbmtzLA0KICAgIFJvYg0KDQorMQ0KTXkgcmVjb2xs ZWN0aW9uL3VuZGVyc3RhbmRpbmcgb2YgaG93IHRoaXMgd29yayBzdGFydGVkIGlzIHRoYXQgc29t ZSBtZW1iZXJzIG9mIHRoZSBXRyBmZWx0IHRoYXQgdGhlcmUgYXJlIGFuZCB3aWxsIGJlIGNhc2Vz IHdoZXJlIHB1Ymxpc2hlZCBZQU5HIG1vZHVsZXMgKFNET3Mgb3IgbmF0aXZlKSBoYXZlIGJ1Z3Mg YW5kIGhhdmUgdG8gYmUgdXBkYXRlZCBpbiBhbiBOQkMgd2F5Lg0KDQpSZWdhcmRzLA0KUmVzaGFk Lg0KIA0KDQo= From nobody Wed Mar 20 12:24:48 2019 Return-Path: <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@amazonses.watsen.net> 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 D7F9E131132 for ; Wed, 20 Mar 2019 12:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 PhsEtwH4nQFc for ; Wed, 20 Mar 2019 12:24:45 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E081288AB for ; Wed, 20 Mar 2019 12:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553109883; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xxIo3/x5Xhh7b/oUiNhUbY9hYAfhIJTOhVx090ixveI=; b=EBW9vAnoseIciDc9CbT9ahnv8/DpT9x7xtrOALfC7dKRXrM5RRsa9rRE6hpiQK3v zz5lce4J0/EWe3eYh+rXRoTokqll2+pA8S9w6QniofWMPrzEUIWfYzGIDnychIIgLfq FolWbl5e8wAj98sQm0A9dizzZMzOSijsQj92IPiU= From: Kent Watsen Message-ID: <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B6985765-CD21-4127-A62D-B5BBA01D1729" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Mar 2019 19:24:43 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , Martin Bjorklund , "netmod@ietf.org" To: Andy Bierman References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.20-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 19:24:47 -0000 --Apple-Mail=_B6985765-CD21-4127-A62D-B5BBA01D1729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I don't think the versioning data nodes is a good idea. > I have seen entire REST APIs be versioned, but not individual = parameters within the API. FWIW, I have seen individual resources versioned within a REST API, in = lieu of a version number in the beginning of the URL. The REST API = presented resources for versioned "objects", each having a distinct = media type for content negotiation (e.g., = application/vnd..+[xml/json];v=3D2). Clients asked for what they could support (including older versions, in = case the server didn't support the latest). Server's up/down-converted = objects through a chain of converters. Each release only had converters = to/from the previous release, but only for the objects that changed. =20 It worked well. The API was stable. Clients did not have to support all = the new object versions in one go. Incremental transition was common. Kent=20 --Apple-Mail=_B6985765-CD21-4127-A62D-B5BBA01D1729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


I don't think the versioning data nodes is a good = idea.
I have seen entire REST APIs be versioned, but not = individual parameters within the = API.

FWIW, I have seen individual resources = versioned within a REST API, in lieu of a version number in the = beginning of the URL.  The REST API presented resources for = versioned "objects", each having a distinct media type for content = negotiation = (e.g., application/vnd.<company>.<object>+[xml/json];v=3D= 2).

Clients = asked for what they could support (including older versions, in case the = server didn't support the latest).  Server's up/down-converted = objects through a chain of converters.  Each release only had = converters to/from the previous release, but only for the objects that = changed.  

It worked well.  The API was stable. Clients did not = have to support all the new object versions in one go.  Incremental = transition was common.

Kent 

= --Apple-Mail=_B6985765-CD21-4127-A62D-B5BBA01D1729-- From nobody Wed Mar 20 13:11:16 2019 Return-Path: <010001699cba8e31-76b1967c-1823-4d72-a9e2-e80ad22509c3-000000@amazonses.watsen.net> 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 8F7501311DB for ; Wed, 20 Mar 2019 13:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 zirYPavSL9We for ; Wed, 20 Mar 2019 13:11:07 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B1013121D for ; Wed, 20 Mar 2019 13:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553112665; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=1uMPH3K/r10j+YYhxSCv6PcEmnEkRr8RUyAx/q97DY0=; b=nUViWPTHS4SQwMKI6fseruJu0mYwoJrD6x/j2SWok/g6jZaac0MIFkIim/wYNa2P Mklis/ZabXl8tQPpJ8c/gcJWhd2n8gXApj1+eztdLs7UchG0LSSorUJCP6P3+/ju+z4 sltB5vXG3f8dhwPB2+rFpWHXD6JKWbHeHdQ3OatU= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_83305ACF-774C-4104-A6A3-D22C9450F3B5" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <010001699cba8e31-76b1967c-1823-4d72-a9e2-e80ad22509c3-000000@email.amazonses.com> Date: Wed, 20 Mar 2019 20:11:05 +0000 To: NETMOD Working Group X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.20-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] Meeting minutes for virtual interim on Mar 20 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 20:11:14 -0000 --Apple-Mail=_83305ACF-774C-4104-A6A3-D22C9450F3B5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Meeting Minutes =============== NETMOD Virtual Interim March 20th, 2019 Agenda: The purpose of this meeting was to continue scoring the YANG Next feature requests, to review current data analysis, and discuss the Monday's presentation and Wednesday's deep dive. Attendees: - Acee Lindem - Andy Bierman - Balazs Lengyel - Kent Watsen - Mahesh Jethanandani - Martin Bjorklund - Reshad Rahman - Robert Wilton - Juergen Schoenwaelder Results: - The few recently entered unsecured issues were scored, though two more issues were entered after the meeting ended. So now there are a total of 48 issues open, with 46 scored and 2 unscored. For details, please see https://github.com/netmod-wg/yang-next/issues. - The importance==high and backwards-compatibility==(unknown or medium) issues were reviewed to see if a better backwards-compatibility value could be given (only 1 out of 3 issues could be improved) - Kent presented scatter graphs rendered for data pulled from GitHub. The same graphs will be presented to the WG on Monday. Kent --Apple-Mail=_83305ACF-774C-4104-A6A3-D22C9450F3B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Meeting Minutes
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

NETMOD Virtual = Interim
March 20th, 2019

Agenda:

The purpose of this = meeting was to continue scoring the YANG Next
feature requests, to review current data analysis, and = discuss the
Monday's presentation and Wednesday's deep = dive.

Attendees:

  - Acee = Lindem
  - Andy Bierman
  - Balazs = Lengyel
  - Kent Watsen
  - Mahesh = Jethanandani
  - Martin Bjorklund
  = - Reshad Rahman
  - Robert Wilton
  = - Juergen Schoenwaelder

Results:

- The few recently entered unsecured = issues were scored, though two more
  issues were entered after the meeting ended. =  So now there are a total
  of 48 issues open, = with 46 = scored and 2 unscored. =  For details, please
  see https://github.com/netmod-wg/yang-next/issues.
=

- The importance=3D=3Dhigh and = backwards-compatibility=3D=3D(unknown or medium)
  issues were reviewed = to see if a better backwards-compatibility value
  could be given (only 1 = out of 3 issues could be improved)
 
- Kent presented scatter = graphs rendered for data pulled from GitHub.
  The same graphs = will be presented to the WG on Monday.


Kent

= --Apple-Mail=_83305ACF-774C-4104-A6A3-D22C9450F3B5-- From nobody Wed Mar 20 13:59:39 2019 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 F3E5212796D for ; Wed, 20 Mar 2019 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V5N1xgOAEkzf for ; Wed, 20 Mar 2019 13:59:36 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 ACBEF124BF6 for ; Wed, 20 Mar 2019 13:59:35 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id m13so2988167lfb.6 for ; Wed, 20 Mar 2019 13:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j9yZOIU30SvWF2dzpCsgIOAqB4VcatFz8N3qIMlWDEo=; b=kxNA0M8gcW2z+6HllbujavQvyW1jCh9F33K1Xf8/HufgsAXK9gHZRAbQUYX3gyVSbl L3YfFCVjB7UXj1qLyZyWafmQhR1sXrVR+iCUJHwknmcLQ5MMFX+9+fq512pVnuo4ER2q 9Lv9mOsHz5iV6PAX4j/Pg611jwL1pnPAecd/TLTrPqFTUgM0HDtc26EpfWwr957EQjYP XoOyBHGsQCP4zdLvDejlrtNfUkZCvO44hwXJUpmAVS8Kcng/9rtG348euCf94WxSTMES wlTZrVkYXJ03Cdqqpe65phhPp1df+jvwXOau9uC1iXg8HifohhmegwUN4om/XEv7AYxQ /3ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j9yZOIU30SvWF2dzpCsgIOAqB4VcatFz8N3qIMlWDEo=; b=Ijj7tspTgNxJC+H9WVaHMAa4LcwO2TRCz8e4wFrItw+ZyMkA6QCeshedmHFS8llQbA WIt4TMogOCFSbudKEB2YKA+Vyrj10WkdzIT6d7Gd2vlhjpFdyEqH0ec4aIW9HAuhNvER kDnExRKiu44wtAhWBeT1SfERllReCS/PAS/xHIznxaB3sLcwC79J2/Dre/FPyNgYXNMn 5EBH2wyvGheQeUl1EtdAOO+t3EMGTCkZOSaWXZ6xo5tV/gnjKFFoVftVmqU2S1nr7enR rFBn2T3dmrd5x3ffVfyA0yROixUdZnqEu2XDbFR6BXn42zT9GkNejNuHmINnDm9pQwkc 7U8w== X-Gm-Message-State: APjAAAUsFqMvstfoNCKR6g8EqNUxAlz4+TuM+hQzw+r/YSLSTYn1wh7W +7sySxArjd2oidPgmihtxiuImWQiLfm6EBGFr/aUhw== X-Google-Smtp-Source: APXvYqxXKTiv1WD3Tz8nSnuf0bJ54Ea3I5SasJbEsiDAYBJnVKktKD76iu+V9peGJ7sWtdSBNY1UNVj6u2m/8QVGgGI= X-Received: by 2002:ac2:569b:: with SMTP id 27mr18344714lfr.24.1553115573681; Wed, 20 Mar 2019 13:59:33 -0700 (PDT) MIME-Version: 1.0 References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@email.amazonses.com> In-Reply-To: <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 20 Mar 2019 13:59:22 -0700 Message-ID: To: Kent Watsen Cc: "Rob Wilton (rwilton)" , Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001091c805848ce621" Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 20:59:38 -0000 --0000000000001091c805848ce621 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 20, 2019 at 12:24 PM Kent Watsen wrote: > > > I don't think the versioning data nodes is a good idea. > I have seen entire REST APIs be versioned, but not individual parameters > within the API. > > > FWIW, I have seen individual resources versioned within a REST API, in > lieu of a version number in the beginning of the URL. The REST API > presented resources for versioned "objects", each having a distinct media > type for content negotiation > (e.g., application/vnd..+[xml/json];v=2). > > Clients asked for what they could support (including older versions, in > case the server didn't support the latest). Server's up/down-converted > objects through a chain of converters. Each release only had converters > to/from the previous release, but only for the objects that changed. > > It worked well. The API was stable. Clients did not have to support all > the new object versions in one go. Incremental transition was common. > > This is much simpler because the REST APIs are like RPC operations in YANG -- they do not interact with each other. In fact, it is impossible in YANG to have the XPath/leafref cross-references in 1 RPC access another RPC. It is easy to support many revisions of an RPC operation. Not so easy for the contents of a YANG datastore. Changing the data type, config-stmt, or data definition type are drastic changes that will affect cross-references. These might be the only NBC changes that really matter. Anything else you could call a bugfix and it would be better to fix than replace (e.g., add/modify/delete must/when/mandatory) I agree with Martin that NBC changes cannot be allowed and a new definition is required to replace the broken one. Perhaps Lada is right that the YANG update rules are too strict. There are many things that could be considered a bugfix that are not allowed. But I don't think a version string format fixes any of the hard problems. More YANG statements, extensions, and annotations (in NETCONF) are needed to really address the problem, (E.g., where is the 301 Redirect for NETCONF/YANG?) Kent > > Andy --0000000000001091c805848ce621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable






--0000000000001091c805848ce621-- From nobody Wed Mar 20 16:25:02 2019 Return-Path: <010001699d6c0b6a-3ff01ba1-35e2-4bf0-aecf-8e276e2ac8c8-000000@amazonses.watsen.net> 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 9EB0E12AF7B for ; Wed, 20 Mar 2019 16:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 zBzXCAvoUOo1 for ; Wed, 20 Mar 2019 16:24:59 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA101277E5 for ; Wed, 20 Mar 2019 16:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553124297; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Zw7xezusJuN9dKCBXrildzJqarKx484E55AO91KfUBA=; b=KK3O4Gw+Rn3ucPqlaaGDoCAZTk6nh3Vchcxj0PUuBWg9sjUMjzuLPqGC6h7V25ao kjoGo83ZdZ+4fq8cEsdKLX3yT7wts9amttu5Ia8+HvvMasaXeG0Vdu1+0twHs9PxcLN 2bbDJog3C4Gz5scdd0XNlvU72kZ5InKxFimW5Nn0= From: Kent Watsen Message-ID: <010001699d6c0b6a-3ff01ba1-35e2-4bf0-aecf-8e276e2ac8c8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4FD86B2C-BCA8-4240-8AF0-9BBB8D054019" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Mar 2019 23:24:57 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , Martin Bjorklund , "netmod@ietf.org" To: Andy Bierman References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.03.20-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 23:25:01 -0000 --Apple-Mail=_4FD86B2C-BCA8-4240-8AF0-9BBB8D054019 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > This is much simpler because the REST APIs are like RPC operations in = YANG -- they do not interact with each other. > In fact, it is impossible in YANG to have the XPath/leafref = cross-references in 1 RPC access another RPC. >=20 > It is easy to support many revisions of an RPC operation. > Not so easy for the contents of a YANG datastore. The REST API was modeled using YANG, but each "object" was effectively = yang-data. This was for an NMS, so the objects were large. For = example, each NE device was an object, as was each application-level = abstraction built on top of the device native models. K. --Apple-Mail=_4FD86B2C-BCA8-4240-8AF0-9BBB8D054019 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This is much simpler because the REST APIs are = like RPC operations in YANG -- they do not interact with each = other.
In fact, it is impossible in YANG to have = the XPath/leafref cross-references in 1 RPC access another = RPC.

It is = easy to support many revisions of an RPC operation.
Not so easy for the contents of a YANG = datastore.


The REST API was modeled = using YANG, but each "object" was effectively yang-data.   This was = for an NMS, so the objects were large.  For example, each NE device = was an object, as was each application-level abstraction built on top of = the device native models.

K.

= --Apple-Mail=_4FD86B2C-BCA8-4240-8AF0-9BBB8D054019-- From nobody Fri Mar 22 02:24:06 2019 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 465F8130EC2 for ; Fri, 22 Mar 2019 02:24:04 -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 rpRc4OcDgXic for ; Fri, 22 Mar 2019 02:24: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 83308130EC9 for ; Fri, 22 Mar 2019 02:24:02 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 994ED1AE00A0 for ; Fri, 22 Mar 2019 10:24:00 +0100 (CET) Date: Fri, 22 Mar 2019 10:24:00 +0100 (CET) Message-Id: <20190322.102400.1417118397166044745.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] guidelines for top-level nodes in RFC 8407 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 09:24:04 -0000 Hi, RFC 8407, section 4.10 says: A mandatory database data definition is defined as a node that a client must provide for the database to be valid. The server is not required to provide a value. Top-level database data definitions MUST NOT be mandatory. The objective for this rule is to avoid a situation where a module cannot be loaded w/o providing additional config, or a situation where you can't boot a server w/o additional config. Consider this snippet: container top { leaf foo { type int32; default 0; } leaf bar { when '../foo = 42'; mandatory true; type int32; } } Is /top/bar considered a mandatory top level node? IMO it doesn't violate the spirit of the rule. So the question is; is this allowed? /martin P.S. the real data model is a potential solution to a problem with ietf-alarms from draft-ietf-ccamp-alarm-module: leaf notify-status-changes { type enumeration { enum all-state-changes { ... } enum raise-and-clear { ... } enum severity-level { ... } } default "all-state-changes"; description ... } leaf notify-severity-level { when '../notify-status-changes = "severity-level"'; type severity; mandatory true; ... } pyang complains that this violates the cited rule. D.S. From nobody Fri Mar 22 03:12:25 2019 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 E15D1126C01 for ; Fri, 22 Mar 2019 03:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 3UfJ8nw1S-Ws for ; Fri, 22 Mar 2019 03:12:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 142CC1277CE for ; Fri, 22 Mar 2019 03:12:19 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:bcc9:97ff:fe48:2ab0]) by mail.nic.cz (Postfix) with ESMTPSA id BB96C607AD for ; Fri, 22 Mar 2019 11:12:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553249536; bh=gCuLtdUxjlErH4rOaiaZATAQssLnTQUOG0WAjhgXBxo=; h=From:To:Date; b=lhLkmsb2SdxQQ+rlA7IO6dkGEQe5SBMtqaeR7MXsLHWOaxdyG6CDt/y21DF9YvpAs jPg3FPZZVHhf/l+tYTyFn+MZGOrEN9iK1cL2YQVPcyyMXe0RmBHHleuv81MH37fCyW W3y5oVj5cCb4XCxXF5YO92aMvWbibfMrHw+7BOyY= Message-ID: <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 22 Mar 2019 11:12:16 +0100 In-Reply-To: <20190322.102400.1417118397166044745.mbj@tail-f.com> References: <20190322.102400.1417118397166044745.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] guidelines for top-level nodes in RFC 8407 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 10:12:24 -0000 On Fri, 2019-03-22 at 10:24 +0100, Martin Bjorklund wrote: > Hi, > > RFC 8407, section 4.10 says: > > A mandatory database data definition is defined as a node that a > client must provide for the database to be valid. The server is not > required to provide a value. > > Top-level database data definitions MUST NOT be mandatory. The term "database" is somewhat unclear. Other documents use "datastore". > > The objective for this rule is to avoid a situation where a module cannot > be loaded w/o providing additional config, or a situation where you > can't boot a server w/o additional config. In fact, this issue is related to the semantics of a particular datastore. For example, mandatory top-level nodes make a very good sense in . If I remember correctly, the NACM module has some. > > > Consider this snippet: > > container top { > leaf foo { > type int32; > default 0; > } > leaf bar { > when '../foo = 42'; > mandatory true; > type int32; > } > } > > > Is /top/bar considered a mandatory top level node? Of course it is, as well as the /top, per definition in RFC 7950: o mandatory node: A mandatory node is one of: * A leaf, choice, anydata, or anyxml node with a "mandatory" statement with the value "true". * A list or leaf-list node with a "min-elements" statement with a value greater than zero. * A container node without a "presence" statement and that has at least one mandatory node as a child. > > IMO it doesn't violate the spirit of the rule. So the question is; is > this allowed? My answer is that the mandatory property is a syntactic/schema constraint whereas "when" should be treated as a semantic rule because its expression has to be evaluated on a particular instance. As such, it should not interfere with schema constraints including mandatory. If the when expression is more complicated (e.g. involves data from other modules), it may not be possible to determine just by looking at a single module whether an empty datastore is valid or not. Even in your trivial example, what if an implementation adds a deviation module changing the default for /top/foo to 42? Lada > > > /martin > > P.S. the real data model is a potential solution to a problem with > ietf-alarms from draft-ietf-ccamp-alarm-module: > > leaf notify-status-changes { > type enumeration { > enum all-state-changes { > ... > } > enum raise-and-clear { > ... > } > enum severity-level { > ... > } > } > default "all-state-changes"; > description > ... > } > leaf notify-severity-level { > when '../notify-status-changes = "severity-level"'; > type severity; > mandatory true; > ... > } > > > pyang complains that this violates the cited rule. > > D.S. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 22 05:34:03 2019 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 DB50C12797D for ; Fri, 22 Mar 2019 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 h93BMUpFnDCm for ; Fri, 22 Mar 2019 05:34:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C612787F for ; Fri, 22 Mar 2019 05:33:59 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id BEC771AE00A0; Fri, 22 Mar 2019 13:33:56 +0100 (CET) Date: Fri, 22 Mar 2019 13:33:46 +0100 (CET) Message-Id: <20190322.133346.1421769722882415136.mbj@tail-f.com> To: lhotka@nic.cz Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz> References: <20190322.102400.1417118397166044745.mbj@tail-f.com> <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] guidelines for top-level nodes in RFC 8407 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 12:34:02 -0000 Ladislav Lhotka wrote: > On Fri, 2019-03-22 at 10:24 +0100, Martin Bjorklund wrote: > > Hi, > > > > RFC 8407, section 4.10 says: > > > > A mandatory database data definition is defined as a node that a > > client must provide for the database to be valid. The server is not > > required to provide a value. > > > > Top-level database data definitions MUST NOT be mandatory. > > The term "database" is somewhat unclear. Other documents use "datastore". > > > > > The objective for this rule is to avoid a situation where a module cannot > > be loaded w/o providing additional config, or a situation where you > > can't boot a server w/o additional config. > > In fact, this issue is related to the semantics of a particular datastore. For > example, mandatory top-level nodes make a very good sense in > . If I > remember correctly, the NACM module has some. Yes I agree. > > Consider this snippet: > > > > container top { > > leaf foo { > > type int32; > > default 0; > > } > > leaf bar { > > when '../foo = 42'; > > mandatory true; > > type int32; > > } > > } > > > > > > Is /top/bar considered a mandatory top level node? > > Of course it is, as well as the /top, per definition in RFC 7950: > > o mandatory node: A mandatory node is one of: > > * A leaf, choice, anydata, or anyxml node with a "mandatory" > statement with the value "true". > > * A list or leaf-list node with a "min-elements" statement with a > value greater than zero. > > * A container node without a "presence" statement and that has at > least one mandatory node as a child. Ok. So in this case I suppose I can do: container top { leaf foo { type int32; default 0; must '. != 42 or ../bar' { description "If foo is 42, then bar must be be set"; } } leaf bar { when '../foo = 42'; type int32; } } It accomplishes the same thing, but it is less clear. /martin > > IMO it doesn't violate the spirit of the rule. So the question is; is > > this allowed? > > My answer is that the mandatory property is a syntactic/schema constraint > whereas "when" should be treated as a semantic rule because its expression has > to be evaluated on a particular instance. As such, it should not interfere with > schema constraints including mandatory. > > If the when expression is more complicated (e.g. involves data from > other modules), it may not be possible to determine just by looking > at a single module whether an empty datastore is valid or not. > > Even in your trivial example, what if an implementation adds a deviation module > changing the default for /top/foo to 42? > > Lada > > > > > > > /martin > > > > P.S. the real data model is a potential solution to a problem with > > ietf-alarms from draft-ietf-ccamp-alarm-module: > > > > leaf notify-status-changes { > > type enumeration { > > enum all-state-changes { > > ... > > } > > enum raise-and-clear { > > ... > > } > > enum severity-level { > > ... > > } > > } > > default "all-state-changes"; > > description > > ... > > } > > leaf notify-severity-level { > > when '../notify-status-changes = "severity-level"'; > > type severity; > > mandatory true; > > ... > > } > > > > > > pyang complains that this violates the cited rule. > > > > D.S. > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Mar 22 06:46:07 2019 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 CE5A6130EC2 for ; Fri, 22 Mar 2019 06:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 nEgki7FVGnpE for ; Fri, 22 Mar 2019 06:46:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 10D58130EBB for ; Fri, 22 Mar 2019 06:46:01 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 6549F18204B4; Fri, 22 Mar 2019 14:45:55 +0100 (CET) Received: from localhost (unknown [195.113.220.123]) by trail.lhotka.name (Postfix) with ESMTPSA id E22E71820047; Fri, 22 Mar 2019 14:45:38 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund Cc: netmod@ietf.org In-Reply-To: <20190322.133346.1421769722882415136.mbj@tail-f.com> References: <20190322.102400.1417118397166044745.mbj@tail-f.com> <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz> <20190322.133346.1421769722882415136.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Fri, 22 Mar 2019 14:45:42 +0100 Message-ID: <87tvfvxbsp.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] guidelines for top-level nodes in RFC 8407 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 13:46:06 -0000 Martin Bjorklund writes: ... > Ok. So in this case I suppose I can do: > > container top { > leaf foo { > type int32; > default 0; > must '. != 42 or ../bar' { > description > "If foo is 42, then bar must be be set"; > } > } > leaf bar { > when '../foo = 42'; > type int32; > } > } Or just container top { must 'foo != 42 and not(bar) or foo = 42 and bar'; ... } It also depends on whether you want to let automatically nuke bar if foo is changed from 42 to something else. I prefer to keep it and report a semantic error during validation. > > It accomplishes the same thing, but it is less clear. Well, the interaction between mandatory and when has already caused a lot of confusion. Some people even thought it was clear but their interpretation was wrong. :-) Lada > > > /martin > > >> > IMO it doesn't violate the spirit of the rule. So the question is; is >> > this allowed? >> >> My answer is that the mandatory property is a syntactic/schema constraint >> whereas "when" should be treated as a semantic rule because its expression has >> to be evaluated on a particular instance. As such, it should not interfere with >> schema constraints including mandatory. >> >> If the when expression is more complicated (e.g. involves data from >> other modules), it may not be possible to determine just by looking >> at a single module whether an empty datastore is valid or not. >> >> Even in your trivial example, what if an implementation adds a deviation module >> changing the default for /top/foo to 42? >> >> Lada >> >> > >> > >> > /martin >> > >> > P.S. the real data model is a potential solution to a problem with >> > ietf-alarms from draft-ietf-ccamp-alarm-module: >> > >> > leaf notify-status-changes { >> > type enumeration { >> > enum all-state-changes { >> > ... >> > } >> > enum raise-and-clear { >> > ... >> > } >> > enum severity-level { >> > ... >> > } >> > } >> > default "all-state-changes"; >> > description >> > ... >> > } >> > leaf notify-severity-level { >> > when '../notify-status-changes = "severity-level"'; >> > type severity; >> > mandatory true; >> > ... >> > } >> > >> > >> > pyang complains that this violates the cited rule. >> > >> > D.S. >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 22 10:09:29 2019 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 867571312DA for ; Fri, 22 Mar 2019 10:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laq825RF35tn for ; Fri, 22 Mar 2019 10:09:27 -0700 (PDT) Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (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 DC5F01279AA for ; Fri, 22 Mar 2019 10:09:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553274564; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Z4U0SkC8FbipxJDPoiNPNM96AAidrGMe7s9xLmDJ1TjvDKQboGBXRpY0cPgN5oCnotZ8VBhJAzW/a TXGETqtAYd7XL2mL5UEB+SHFb7SenZ335/OOoAjiSqG+BI2wvq8L//oz+BSrQPUU6Ekxx3+0aA3Qb1 MHdLA3Ym2VhFKRjYDaIiKq/vrLqW8QHpsxPvzGdW6h3+ZGI6r1in0nwjckzy4q/05LzeqaAuVJwch6 V6pmFC4vQByBv/Ip18nsANOpo7hrWbA1pD9hM+zC3/8AZM1wLfP7FuXS0ZFigdHBe4BbhJBmXEIBXD 8Yae4tBkACart8+wRCZTvZYsNvU3r2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:dkim-signature:from; bh=CJXJeDfaG3vZn/snurxNPcTCpZ/3ULKGkzi63NpYU9Y=; b=OvoE7lXCB+OWhgP52ZoYQBlORlj2VVJ+TO8sY2WBQ9v/AQCwLIneFTtlRMeCZPRas3qQKn8t95kAL IrCLEaDc/QtXCSqM90lIUmRD8IKKoP6ETUGJesg3rS1rC95vOj4oiILfe1VaRwTHMHySc3k0/kn/8v yZaFcAFRm5EEoGt/0CXzTET1teeQ8ID9WMyhtxGLLlb7XCNGOIzpwKolH+5xbpRQrHwIL5k7RQQ7fW qp6kTFTuJc93WhGCiTGvXnlQ6wBLNiXAE5ahSDhonIXWYDouFRs1puS0hyh1IemRAuq/TPe3dRVV8w tfmt9PoBm4mHwndwDxy8f7JbkhYCGEg== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.155.78; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:from; bh=CJXJeDfaG3vZn/snurxNPcTCpZ/3ULKGkzi63NpYU9Y=; b=sM3vCyD+xqnEXxoOevUVDpgQY0WCgKHvP9aKf+OErLeKG4ZcielDBac7CmmRjh7uJmuN2uHzMciRq JaWe2zwBQflzWaSnZAs67YeT4tjXAFzsuu9MsES4yFFIbjRMINKPLVgYKjdzTYETZepMr8ur1IKGbk 3viYYGmZkHJEgU3L8h3OetHOcxZlBN9nRiws/SOFjUMu09QEY4l+5G82cpj+FaFs3Bmscdb9f2pc66 5D9dOd8Jfa4mOKnrOwdnGtXzTLw2XOHLHGiGH9EDMIVzMwHGWE6E0wXbihgvWBE1zsHm5IB/afFuAC 0FY2nZ7O+yvNlyYZwwC/l18QoIT6lXw== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 3c0451f1-4cc5-11e9-908b-352056dbf2de X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.155.78 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.155.78]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 3c0451f1-4cc5-11e9-908b-352056dbf2de; Fri, 22 Mar 2019 17:09:22 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x2MH9KMx025908 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Mar 2019 18:09:20 +0100 (CET) (envelope-from per@hedeland.org) To: Martin Bjorklund References: <20190322.102400.1417118397166044745.mbj@tail-f.com> <64219162d7fbcea83796e37f01f4cf9648b5573b.camel@nic.cz> <20190322.133346.1421769722882415136.mbj@tail-f.com> <87tvfvxbsp.fsf@nic.cz> Cc: netmod@ietf.org From: Per Hedeland Message-ID: <69468f04-86f2-9923-5b36-278d4f90dc9b@hedeland.org> Date: Fri, 22 Mar 2019 18:09:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <87tvfvxbsp.fsf@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] guidelines for top-level nodes in RFC 8407 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 17:09:29 -0000 On 2019-03-22 14:45, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >>>> IMO it doesn't violate the spirit of the rule. So the question is; is >>>> this allowed? It seems to me that it would make sense to apply the same logic as for "remote" augments to this rule - from RFC 7950: If the augmentation adds mandatory nodes (see Section 3) that represent configuration to a target node in another module, the augmentation MUST be made conditional with a "when" statement. Care must be taken when defining the "when" expression [...] I.e. the answer to your (original) question would in that case be "yes" (at least for YANG 1.1 modules...). --Per Hedeland From nobody Fri Mar 22 12:07:58 2019 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 076791314C7 for ; Fri, 22 Mar 2019 12:07:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2pc_0bYHVLKE for ; Fri, 22 Mar 2019 12:07:48 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 5FADC1314CC for ; Fri, 22 Mar 2019 12:07:48 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 4854A175C2E for ; Fri, 22 Mar 2019 13:07:44 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 7PW3hhy55XFO57PW3hOBZi; Fri, 22 Mar 2019 13:07:44 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc: References:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NmFVa2MJxqTrFu3G0errPKM4cuXo05a7+yXbzfPotd4=; b=zS7WLBPSq3hT9nQU7Y78T7J555 0oal0+2t96AHGAlszFwu9NqZmhmsGYzQ5bFD92pflX9FZqoiaaiFw3ChKMeL+A55aGUPLxi51hWLK BKsHYnVQKiAaO5MCQZhQdPZ+h; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:36160 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h7PW3-003HYW-7p; Fri, 22 Mar 2019 13:07:43 -0600 To: netmod@ietf.org References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> Cc: Kent Watsen , "netmod-ver-dt@ietf.org" From: Lou Berger Message-ID: <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> Date: Fri, 22 Mar 2019 15:07:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------DC8779A5CF9FD61E823ED321" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1h7PW3-003HYW-7p X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:36160 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 19:07:50 -0000 This is a multi-part message in MIME format. --------------DC8779A5CF9FD61E823ED321 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, Thank you all for the good input on this thread. With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic. It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution. Authors, Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.  The -01 version should focus on resolving issues raised during adoption.  Of course the document is subject to normal WG input and processing. Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently. Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues. Thank you, Lou (and Kent and Joel) On 3/13/2019 4:22 PM, Kent Watsen wrote: > Seeing as how we all need to read this draft anyways, in preparation > for our meeting in Prague, it seems like a good time for this poll. >  Thusly, this email begins a 1-week adoption poll for: > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 > > Please voice your support or objections before March 20. > > Note that this draft defines *requirements* and its intended status is > "Informational."   I believe that it is good for WGs to formalize > requirements, even taking such drafts thru Last Call, in order to > ensure consensus on the requirements.  This is the "adoption" call, to > ascertain if the WG agrees with that statement; if adopted, a separate > "last call" will be issued to ensure to correctness of the draft's > content. > > Kent (and Lou and Joel) > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------DC8779A5CF9FD61E823ED321 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,

Thank you all for the good input on this thread.

With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.

It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.

Authors,

Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.  The -01 version should focus on resolving issues raised during adoption.  Of course the document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.

Thank you,

Lou (and Kent and Joel)

On 3/13/2019 4:22 PM, Kent Watsen wrote:
Seeing as how we all need to read this draft anyways, in preparation for our meeting in Prague, it seems like a good time for this poll.  Thusly, this email begins a 1-week adoption poll for:


Please voice your support or objections before March 20.

Note that this draft defines *requirements* and its intended status is "Informational."   I believe that it is good for WGs to formalize requirements, even taking such drafts thru Last Call, in order to ensure consensus on the requirements.  This is the "adoption" call, to ascertain if the WG agrees with that statement; if adopted, a separate "last call" will be issued to ensure to correctness of the draft's content.

Kent (and Lou and Joel)



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------DC8779A5CF9FD61E823ED321-- From nobody Fri Mar 22 14:43:32 2019 Return-Path: <01000169a75bd9aa-8ae4d091-6f9f-4e4a-90ec-453b026510d1-000000@amazonses.watsen.net> 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 E6672131585 for ; Fri, 22 Mar 2019 14:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 v4uoPoRDtIIQ for ; Fri, 22 Mar 2019 14:43:30 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCBE130E85 for ; Fri, 22 Mar 2019 14:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553291008; h=From:Subject:To:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=8YCe92SRyMNOdfZ2IimyU/7QwksDCTKz09/gR+jUcQw=; b=FEE8pEDAaR/5rvhSVob+HUZBJanmO2OQIHqavF3bBfG1yYdmiLfhvqm4xnsOT8v7 jWUc27bXoSnimnE4im/pOG4HIbneycVYk/srhsxJsEmukFqoWT6KAb2irhuI/wHPY6u E8xkVDwbPf4Y8NP71+4EiCoLAbgkQVUrY6umswKI= From: Kent Watsen To: netmod@ietf.org Message-ID: <01000169a75bd9aa-8ae4d091-6f9f-4e4a-90ec-453b026510d1-000000@email.amazonses.com> Date: Fri, 22 Mar 2019 21:43:28 +0000 User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-SES-Outgoing: 2019.03.22-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] kw review of draft-verdt-netmod-yang-semver-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 21:43:31 -0000 I understand that this draft is shaking fundamentals that is making some folks nervous.  The concern is appreciated, but I also understand well issues vendors are facing and don't believe that maintaining status quo is realistic. The requirements are, for the most part, correct (IMO), especially regarding support for NBCs.  At least, the way I see it, that is the reality of native models for products that have multiple simultaneous release trains. Maybe deviations could be used but 1) it's kind of strange for a vendor to deviate from its own native model and 2) it seems complicated to swap the compiled native model with a standard native model + some dynamically generated deviations, using some TBD tooling.  To be clear, my assumption is that the underlying NC/RC interface is unchanged, only the modules the server reports would vary.  But why haven't vendors done this already? I don't yet see a downside to embracing the sem-ver proposal, while OpenConfig alignment seems like goodness.  We should analyse the tradeoffs more. For the following review, I assume that Sem-Ver is good, and the added 'M' and 'm' suffixes are useful.  Whether these things pan out in time is TBD. == Beginning of Section 1.2:     OLD: This section is to aid the WG understand how the full set     NEW: This section is to aid the WG understanding in how the full set End of Section 2.1     OLD: and those changes do not follow the rules     NEW: and at least one change does not follow the rules Just before Section 2.2.1:     OLD: There MUST NOT be multiple versions of a YANG module     NEW: There MUST NOT be multiple published versions of a YANG module     Actually, it might be more helpful to have a clarification note near the top     that the draft only regards published modules and specifically does not     apply to the various revisions of a draft. In Section 2.2.1:      The line “0.2.0 - second beta module version (with NBC changes)†SHOULD    point to rule 4 in Section 2.3 In Section 2.3:     For rule 4, why not peg the semver to “0.0.0†for beta modules?  Already the     Interpretation is off, so no semantic meaning comes through.  Going back to     my earlier comment about having general statement regarding unpublished     modules, it seems that “beta†modules fall into this category and hence okay     to reuse the same semver value. In Section 3:    There are two numbered lists in this section, each containing three entries: 1,    2, and 3.   First, please change one of the lists to a different format (e.g., i, I, iii).    Next, it would be helpful to explain which parts belong to which.  E.g., 1–>i, 2–>ii,    3 —> ii and iii. Section 3.1:     OLD: that is hypothetically available in the following versions:     NEW: that is published in the following versions: Section 4.2:     OLD: The document update these rules     NEW: This document updates these rules     Also: s/chanage/change/ Section 5.2:     OLD: but one of more modules NEW: but one or more modules Section 5.3:     The augmentation in the YANG module indicates the intention is to enable a     server to express its conformance at the “server†level, but it seems that it     should be at the module-level.  As support across modules may vary.     Also, this section has a nice wrap up paragraph where it states     “implementations MUST set the 'deprecated-nodes-implemented' leaf,     But it fails to say anything about the obsolete-nodes-absent leaf?  It seems that     It should be required as well but, if not, then the text should state why not. Section 6:     Says “this extension can contain freeform textâ€, but it seems that a node that     tools could act on would be better.  Is it we think that the deprecation warning     message should be sufficient to guide the developer to look at the description? Section 7:     Not specific to this draft, but is it an omission in yang-instance-file-format doesn’t specify schema compatibility for instance data? Kent // contributor From nobody Sat Mar 23 12:01:06 2019 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 67D33130E46 for ; Sat, 23 Mar 2019 12:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DEKampTSRmM6 for ; Sat, 23 Mar 2019 12:00:56 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B53DB130EC5 for ; Sat, 23 Mar 2019 12:00:55 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id 5so3449870lft.12 for ; Sat, 23 Mar 2019 12:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mHHdw7dzhJpjOcuovxigFMfkhfYrhh5f4SQgjIZfIC0=; b=w9FJxKRgX4JS1ZJKxH68ybe+pfuAGvqTfXmWjSk9gEwwOZV92iwQ3AoH+TDXeHLeiC wrsfWi8m7S7MENr2DW2Dik8EhsK29Rc3YrlCILN98fktUfyKmu/+Mnb6txQukOMz6hP8 lDLSjttb0DuqrBTmdK8pmGlnlkhGDFSiQ+R3yy9nJVvAronmqNJw61Y0P+DmS1CIYx7Z nBgfDKHHMfIcG+cTr/ZTSQrSjOvMr3aJXkijH9h+6Fo1+ren1YZqxWXDHWq45po+v6sR RUCR7wfmyISFIJEsLa+C/zW4owsN8SYSCD390h//3JsK40RC2wFiKCjDJxYKBazEWXe7 O0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mHHdw7dzhJpjOcuovxigFMfkhfYrhh5f4SQgjIZfIC0=; b=EQ4aKN4fizYmIPpEHXSIRj/nl8WauhUEhJZ+QRiKfyUKDED8MZy/ecv+IhDb8hzjpD Vz/Qja9kl+65i7CoqNifjN7lxMYPXNcmNKGRLCUSeh8vxVQyJLlC6Qf2i3TrNrWQ3rEI iOu7L4RMXxqIOg2dKPzdEBzYI9OHlhc/awkI1xTglm1BJ8fw8ueCHZTVG4sCSE4zAUBe Xmra6t0SsPO83xdZFx0l6ZLyvTSRLGaXnhkeIkzcVlGfO2iwSW0NXwtqBKwBfsEqEV6i SuIawgtZ3gnOeMJMRMVwWp6hEHAkWPgc+aQsNLzjDjaUL8jm9kp6i/03t8t8fw1UieZj 96eg== X-Gm-Message-State: APjAAAVh4/Kq4XLy9Y7GPZo59FqG8yHMSBcmrl6CuQABLn955EEeCOu5 OwB1fUqGbhJByNUeBu1jEtORo9hIBr9QXU7AIS9ljhb9M0o= X-Google-Smtp-Source: APXvYqwB2lBTK5cNjkUL3yL/hUHf5C8XVgcfH5PPfa56ul47fbygc4eaWIp9sECHibYcv2Qs3tjIi0VevRUHGW/xhYU= X-Received: by 2002:ac2:42da:: with SMTP id n26mr7408400lfl.91.1553367653510; Sat, 23 Mar 2019 12:00:53 -0700 (PDT) MIME-Version: 1.0 From: Andy Bierman Date: Sat, 23 Mar 2019 12:00:42 -0700 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary="000000000000318b0c0584c7972c" Archived-At: Subject: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 19:01:05 -0000 --000000000000318b0c0584c7972c Content-Type: text/plain; charset="UTF-8" Hi, I am wondering if there are implementations of this draft: https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00 Specifically, implementation of the 'version' extension https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00#section-3 IMO it is a really bad idea to put the semantics of how to import modules in one of the modules that is imported. Your example shows ietf-semver imported first with no extension, but it could be last with a version extension. // all other imports, then last.... import ietf-semver { prefix "semver"; semver:version 1.1.2; } Translation unit parsing is something that needs to be built into the compiler. This should be part of YANG 1.2 if it is done. import example-module { prefix exmod; version 1.2.0+; } To a compiler writer, the difference is huge. (ietf-semver extensions need to be built-in statements in YANG, at least 'version') BTW, all the import examples are missing the mandatory prefix-stmt Andy --000000000000318b0c0584c7972c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am wondering if there are impleme= ntations of this draft:



Specifically, implementation of the=C2=A0 'version' extensi= on=C2=A0


IMO it is a really bad idea to put the semantics of how to imp= ort modules
in one of the modules that is imported.=C2=A0 Your ex= ample shows ietf-semver
imported first with no extension, but it = could be last with a version extension.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 // all other imports, then last....

= 
    import i=
etf-semver { 
    =
  prefix "semver";
      semver:version 1.1.2;
    }

Translation unit parsing is something t= hat needs to be built into the compiler.=C2=A0
This should be par= t of YANG 1.2 if it is done.

  import example-module {
     prefix exmod;
     version 1.2.0+;
   }

To a compiler wri= ter, the difference is huge. (ietf-semver extensions need to
be b= uilt-in statements in YANG, at least 'version')

BTW, all the import examples = are missing the mandatory prefix-stmt


Andy

--000000000000318b0c0584c7972c-- From nobody Sun Mar 24 02:40:09 2019 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 9487F130E79 for ; Sun, 24 Mar 2019 02:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 iSz0u8DbFLHQ for ; Sun, 24 Mar 2019 02:40: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 55C29130E7F for ; Sun, 24 Mar 2019 02:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21120; q=dns/txt; s=iport; t=1553420403; x=1554630003; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=K7BBJQcC5hQboJaRgUgfmZFPR2zIvaTlngvcMhqfshk=; b=DNxHTaLLk9ksMaQMjIB7m0H3iIBThAkuwAxLa/1tKOJCDOeAyZo7TRdC copx2lHgL12qNpMt3sCs7Bmx7SYLMyKWoE++c/0ZR/GybPKesC6Bvx/pC +5a+mtcD/a5sYGyf561XzZGv995F5xK4OE86UTV+iy9iy4R78dNq+DAXA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAAAlUJdc/4ENJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYEPgQJogQMnCoQEkzuCDZo1DQEBI4RJAheEZSI4EgE?= =?us-ascii?q?BAwEBCQEDAm0cDIVKAQEBBCMKXAIBCBEEAQErAgICMB0IAgQBEggTgwiBEWQ?= =?us-ascii?q?Pq1CBL4Q0AoVpBYEvizIXgUA/hCM+gmEBAQIBhGiCVwOMcIQflAcJAodhi04?= =?us-ascii?q?hk36LHIYFjSUCERWBLjYhKIEucBWDJ4sMhT9BMY5wgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="538929163" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 09:39:43 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2O9dhYs010118 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 09:39:43 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 04:39:42 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Sun, 24 Mar 2019 04:39:42 -0500 From: "Rob Wilton (rwilton)" To: Andy Bierman , NetMod WG Thread-Topic: [netmod] import-by-semver issue Thread-Index: AQHU4arYjIn8/1YI30euxcwhgGMsT6YahbWg Date: Sun, 24 Mar 2019 09:39:41 +0000 Message-ID: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> References: In-Reply-To: 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.61.79.96] Content-Type: multipart/alternative; boundary="_000_892d5ab4649549698808a6150067f840XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 09:40:07 -0000 --_000_892d5ab4649549698808a6150067f840XCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KWWVzIHdlIGFyZSBjdXJyZW50bHkgaW1wbGVtZW50aW5nIHRoZSBtb2R1bGUg dmVyc2lvbiBmaWVsZCwgYWx0aG91Z2ggdGhhdCBtYXkgY2hhbmdlIGRlcGVuZGluZyBvbiB3aGF0 IGRpZmZlcmVudCB0aGUgZmluYWwgc29sdXRpb24gZW5kcyB1cCBiZWluZy4NCg0KU3VwcG9ydCBm b3IgaW1wb3J0LWJ5LXZlcnNpb24gaXMgbGVzcyBjcml0aWNhbCBmb3IgdXMsIGFuZCBoZW5jZSBp bXBsZW1lbnRhdGlvbiB3b3VsZCBsYWcuDQoNCkluIHRlcm1zIG9mIHRoZSBpc3N1ZSB0aGF0IHlv dSByYWlzZToNCg0KLSAgICAgICAgSSB3b3VsZCBleHBlY3QgdGhhdCBhIGNvbXBpbGVyIHRoYXQg dW5kZXJzdGFuZHMgc2VtdmVyIHRvIHByZWxvYWQgdGhlIHNlbXZlciBleHRlbnNpb24sIHBvc3Np Ymx5IGFsbG93IHdpdGggb3RoZXIgY29tbW9uIFlBTkcgdHlwZSBmaWxlcywgZXh0ZW5zaW9ucyku DQoNCi0gICAgICAgIEZvciBhIGNvbXBpbGUgdGhhdCBkb2VzbuKAmXQgdW5kZXJzdGFuZCBzZW12 ZXIgdGhlbiBpdCB3b3VsZCBqdXN0IGlnbm9yZSB0aGUgZXh0ZW5zaW9uLCB3aGljaCBzaG91bGQg YmUgZmluZS4NCg0KSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGJlIG5pY2UgaWYgdGhpcyBleHRlbnNp b24gd2FzIHBhcnQgb2YgdGhlIGNvcmUgWUFORyBsYW5ndWFnZSwgYnV0IEkgZG9u4oCZdCB0aGlu ayB0aGF0IGlzIG5lY2Vzc2FyaWx5IHJlcXVpcmVkLg0KDQpUaGFua3MsDQpSb2INCg0KDQpGcm9t OiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQW5keSBCaWVy bWFuDQpTZW50OiAyMyBNYXJjaCAyMDE5IDE5OjAxDQpUbzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbbmV0bW9kXSBpbXBvcnQtYnktc2VtdmVyIGlzc3VlDQoNCkhpLA0K DQpJIGFtIHdvbmRlcmluZyBpZiB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgZHJh ZnQ6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFu Zy1zZW12ZXItMDANCg0KDQpTcGVjaWZpY2FsbHksIGltcGxlbWVudGF0aW9uIG9mIHRoZSAgJ3Zl cnNpb24nIGV4dGVuc2lvbg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVy ZHQtbmV0bW9kLXlhbmctc2VtdmVyLTAwI3NlY3Rpb24tMw0KDQoNCklNTyBpdCBpcyBhIHJlYWxs eSBiYWQgaWRlYSB0byBwdXQgdGhlIHNlbWFudGljcyBvZiBob3cgdG8gaW1wb3J0IG1vZHVsZXMN CmluIG9uZSBvZiB0aGUgbW9kdWxlcyB0aGF0IGlzIGltcG9ydGVkLiAgWW91ciBleGFtcGxlIHNo b3dzIGlldGYtc2VtdmVyDQppbXBvcnRlZCBmaXJzdCB3aXRoIG5vIGV4dGVuc2lvbiwgYnV0IGl0 IGNvdWxkIGJlIGxhc3Qgd2l0aCBhIHZlcnNpb24gZXh0ZW5zaW9uLg0KDQogICAgICAgICAgLy8g YWxsIG90aGVyIGltcG9ydHMsIHRoZW4gbGFzdC4uLi4NCg0KDQogICAgaW1wb3J0IGlldGYtc2Vt dmVyIHsNCg0KICAgICAgcHJlZml4ICJzZW12ZXIiOw0KDQogICAgICBzZW12ZXI6dmVyc2lvbiAx LjEuMjsNCg0KICAgIH0NCg0KVHJhbnNsYXRpb24gdW5pdCBwYXJzaW5nIGlzIHNvbWV0aGluZyB0 aGF0IG5lZWRzIHRvIGJlIGJ1aWx0IGludG8gdGhlIGNvbXBpbGVyLg0KVGhpcyBzaG91bGQgYmUg cGFydCBvZiBZQU5HIDEuMiBpZiBpdCBpcyBkb25lLg0KDQoNCg0KICBpbXBvcnQgZXhhbXBsZS1t b2R1bGUgew0KDQogICAgIHByZWZpeCBleG1vZDsNCg0KICAgICB2ZXJzaW9uIDEuMi4wKzsNCg0K ICAgfQ0KDQoNClRvIGEgY29tcGlsZXIgd3JpdGVyLCB0aGUgZGlmZmVyZW5jZSBpcyBodWdlLiAo aWV0Zi1zZW12ZXIgZXh0ZW5zaW9ucyBuZWVkIHRvDQpiZSBidWlsdC1pbiBzdGF0ZW1lbnRzIGlu IFlBTkcsIGF0IGxlYXN0ICd2ZXJzaW9uJykNCg0KDQoNCkJUVywgYWxsIHRoZSBpbXBvcnQgZXhh bXBsZXMgYXJlIG1pc3NpbmcgdGhlIG1hbmRhdG9yeSBwcmVmaXgtc3RtdA0KDQoNCkFuZHkNCg0K --_000_892d5ab4649549698808a6150067f840XCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdp bi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0MjM4NDE5MDc7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNTA1NjE1MjQg LTE0NjEyNTgxNjIgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgw NzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIwLjRwdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDo1Ni40cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5Mi40cHQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEyOC40cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjQuNHB0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAwLjRwdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjM2LjRwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3Mi40cHQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDguNHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlllcyB3ZSBhcmUgY3VycmVudGx5IGltcGxlbWVudGluZyB0aGUgbW9kdWxl IHZlcnNpb24gZmllbGQsIGFsdGhvdWdoIHRoYXQgbWF5IGNoYW5nZSBkZXBlbmRpbmcgb24gd2hh dCBkaWZmZXJlbnQgdGhlIGZpbmFsIHNvbHV0aW9uDQogZW5kcyB1cCBiZWluZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlN1cHBvcnQgZm9yIGltcG9ydC1ieS12ZXJz aW9uIGlzIGxlc3MgY3JpdGljYWwgZm9yIHVzLCBhbmQgaGVuY2UgaW1wbGVtZW50YXRpb24gd291 bGQgbGFnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gdGVybXMg b2YgdGhlIGlzc3VlIHRoYXQgeW91IHJhaXNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuNHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHdvdWxk IGV4cGVjdCB0aGF0IGEgY29tcGlsZXIgdGhhdCB1bmRlcnN0YW5kcyBzZW12ZXIgdG8gcHJlbG9h ZCB0aGUgc2VtdmVyIGV4dGVuc2lvbiwgcG9zc2libHkgYWxsb3cgd2l0aCBvdGhlciBjb21tb24N CiBZQU5HIHR5cGUgZmlsZXMsIGV4dGVuc2lvbnMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuNHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Gb3Ig YSBjb21waWxlIHRoYXQgZG9lc27igJl0IHVuZGVyc3RhbmQgc2VtdmVyIHRoZW4gaXQgd291bGQg anVzdCBpZ25vcmUgdGhlIGV4dGVuc2lvbiwgd2hpY2ggc2hvdWxkIGJlIGZpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFncmVlIHRoYXQgaXQgd291bGQgYmUg bmljZSBpZiB0aGlzIGV4dGVuc2lvbiB3YXMgcGFydCBvZiB0aGUgY29yZSBZQU5HIGxhbmd1YWdl LCBidXQgSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgbmVjZXNzYXJpbHkgcmVxdWlyZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJvYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5ldG1vZCAmbHQ7bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4N CjxiPlNlbnQ6PC9iPiAyMyBNYXJjaCAyMDE5IDE5OjAxPGJyPg0KPGI+VG86PC9iPiBOZXRNb2Qg V0cgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW25ldG1vZF0g aW1wb3J0LWJ5LXNlbXZlciBpc3N1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYW0gd29uZGVyaW5nIGlmIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMg b2YgdGhpcyBkcmFmdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZl cmR0LW5ldG1vZC15YW5nLXNlbXZlci0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlci0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVjaWZpY2FsbHksIGltcGxlbWVu dGF0aW9uIG9mIHRoZSZuYnNwOyAndmVyc2lvbicgZXh0ZW5zaW9uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDAj c2VjdGlvbi0zIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9k LXlhbmctc2VtdmVyLTAwI3NlY3Rpb24tMzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gaXQgaXMgYSByZWFsbHkgYmFkIGlkZWEg dG8gcHV0IHRoZSBzZW1hbnRpY3Mgb2YgaG93IHRvIGltcG9ydCBtb2R1bGVzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbiBvbmUgb2YgdGhlIG1v ZHVsZXMgdGhhdCBpcyBpbXBvcnRlZC4mbmJzcDsgWW91ciBleGFtcGxlIHNob3dzIGlldGYtc2Vt dmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5p bXBvcnRlZCBmaXJzdCB3aXRoIG5vIGV4dGVuc2lvbiwgYnV0IGl0IGNvdWxkIGJlIGxhc3Qgd2l0 aCBhIHZlcnNpb24gZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8v IGFsbCBvdGhlciBpbXBvcnRzLCB0aGVuIGxhc3QuLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyBpbXBvcnQgaWV0Zi1zZW12ZXIgeyA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3By ZWZpeCAmcXVvdDtzZW12ZXImcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VtdmVyOnZlcnNpb24gMS4xLjI7PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVHJhbnNsYXRpb24gdW5pdCBwYXJzaW5nIGlz IHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGJ1aWx0IGludG8gdGhlIGNvbXBpbGVyLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBzaG91bGQgYmUgcGFydCBvZiBZQU5HIDEuMiBpZiBpdCBpcyBkb25lLjxvOnA+PC9vOnA+PC9w Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7IGltcG9ydCBleGFtcGxlLW1vZHVsZSB7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlZml4IGV4bW9kOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB2ZXJzaW9uIDEuMi4wJiM0Mzs7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIGEgY29tcGlsZXIg d3JpdGVyLCB0aGUgZGlmZmVyZW5jZSBpcyBodWdlLiAoaWV0Zi1zZW12ZXIgZXh0ZW5zaW9ucyBu ZWVkIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5iZSBidWlsdC1pbiBzdGF0ZW1lbnRzIGluIFlBTkcsIGF0IGxlYXN0ICd2ZXJzaW9uJyk8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJUVywg YWxsIHRoZSBpbXBvcnQgZXhhbXBsZXMgYXJlIG1pc3NpbmcgdGhlIG1hbmRhdG9yeSBwcmVmaXgt c3RtdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_892d5ab4649549698808a6150067f840XCHRCD007ciscocom_-- From nobody Sun Mar 24 04:07:18 2019 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 425CB1310AE for ; Sun, 24 Mar 2019 04:07: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HFknmmEGptQd for ; Sun, 24 Mar 2019 04:07:08 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 80336130EFC for ; Sun, 24 Mar 2019 04:07:07 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v22so5384991lje.9 for ; Sun, 24 Mar 2019 04:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bxo9PjkqVzC0nQjkOe2EsyepSufWd5vxei6EFdI+FpA=; b=Bp5j8Js0/O2xT6nodGJUUwST2Urd7/HJNVAo+f4zAbr8DGeAaWlr/woNW355vrTVkV 8BJjaAcmtz/R3YPhISFcYquxbCjFNlief7LhN+yJ/f9cY0ftngGQCgP1FyNFlcF/7oCC Q7CiPN4RTblI7N0Bc4ETZq6ek4JKJkCo4RXUcv4OajpaCRwcCy10/Km8Vz/CNbQ8JcGt RZjl5F8tCZ5pyPWgfQPj+F8uz9+zPGeqxnEGc1HqMCJ+g9dc6OrV+YolgU4SEFNTblrY Zha6rN7eaul6IPup/M/Ehsb8+S4w8Vb+4KSxAeXn4fZNM+qPD/3y+S+zkPxgKq0M1b48 M9BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bxo9PjkqVzC0nQjkOe2EsyepSufWd5vxei6EFdI+FpA=; b=AFOY/dRpPvGMHQ4Mz3wmsEOx2iDF2bN/ilJavoYD4IVgGMcxmvBE7oeBmgOckkRGj/ BKKboutp3HwKsdhxVrKlCsUjKUf9ez3xTKrnZdDJ4SD11YU2NgM5d75ynvt8lYXyVvDs xCq6e4caliLh7bDtUCudh1U1XzA1YTUkH5Ocppbbh5U8wDxDzQSS2aiqR9ILpS4K+WbU AbtYrUhAA3peWrBk1cJ305QMLXwzRUJx962HRLXIGvT5LxoaCZP+NSZZT69lZ0z+kZoa 7pcIj9pCVQeRxCUsTrGl2I6mNZEFaUs/ZijZmV8Sesxuf7JIFyimyvwlJuQekgKOegq2 T4tQ== X-Gm-Message-State: APjAAAV/FPf/2UQ8tksi9ttB+UvNOe8qBEUMfCCMkuSPmt6sVt8zMYnb VR3d4Cb5Kfknha2XoD3Heq8Hf3IMf2B7IpZeprJxBQ== X-Google-Smtp-Source: APXvYqxM+wAF/TF4FVCAXgHRCGW4hA9eUHEoQO7F/jqe/b4xhGB1r1L6Rni/hM6QamHt4229OE/HlnIVtkzk6nDQhoA= X-Received: by 2002:a2e:551d:: with SMTP id j29mr8159764ljb.180.1553425625492; Sun, 24 Mar 2019 04:07:05 -0700 (PDT) MIME-Version: 1.0 References: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> In-Reply-To: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> From: Andy Bierman Date: Sun, 24 Mar 2019 04:06:54 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: NetMod WG Content-Type: multipart/alternative; boundary="00000000000097c4bb0584d516d9" Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 11:07:17 -0000 --00000000000097c4bb0584d516d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2019 at 2:40 AM Rob Wilton (rwilton) wrote: > Hi Andy, > > > > Yes we are currently implementing the module version field, although that > may change depending on what different the final solution ends up being. > > > > Support for import-by-version is less critical for us, and hence > implementation would lag. > > > > In terms of the issue that you raise: > > - I would expect that a compiler that understands semver to > preload the semver extension, possibly allow with other common YANG type > files, extensions). > > - For a compile that doesn=E2=80=99t understand semver then it wou= ld just > ignore the extension, which should be fine. > > > Try to find even 1 compiler in the world that works this way. Yes you can specially hack the extension implementation as if it were a built-in keyword. I agree that it would be nice if this extension was part of the core YANG > language, but I don=E2=80=99t think that is necessarily required. > > > I don't think any of semver is required for anything. IMO it provides a minor improvement to people familiar with the MAJOR.MINOR.PATCH numbering. This improvement is lost as soon as extra letters are added and the string is no longer familiar. Import-by-semver seems like it is part of the base module (no if-feature on the extension-stmt is even possible) so skipping the implementation of it needs a deviation (oh wait, YANG 1.1 can't do that either). Thanks, > > Rob > > Andy > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 23 March 2019 19:01 > *To:* NetMod WG > *Subject:* [netmod] import-by-semver issue > > > > Hi, > > > > I am wondering if there are implementations of this draft: > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00 > > > > > > Specifically, implementation of the 'version' extension > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00#section-3 > > > > > > IMO it is a really bad idea to put the semantics of how to import modules > > in one of the modules that is imported. Your example shows ietf-semver > > imported first with no extension, but it could be last with a version > extension. > > > > // all other imports, then last.... > > > > import ietf-semver { > > prefix "semver"; > > semver:version 1.1.2; > > } > > > Translation unit parsing is something that needs to be built into the > compiler. > > This should be part of YANG 1.2 if it is done. > > > > import example-module { > > prefix exmod; > > version 1.2.0+; > > } > > > > To a compiler writer, the difference is huge. (ietf-semver extensions nee= d > to > > be built-in statements in YANG, at least 'version') > > > > BTW, all the import examples are missing the mandatory prefix-stmt > > > > > > Andy > > > --00000000000097c4bb0584d516d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 2:40 AM Rob W= ilton (rwilton) <rwilton@cisco.com<= /a>> wrote:

Hi Andy,

=C2=A0

Yes we are currently implementing the module= version field, although that may change depending on what different the fi= nal solution ends up being.

=C2=A0

Support for import-by-version is less critic= al for us, and hence implementation would lag.

=C2=A0

In terms of the issue that you raise:=

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I would expect that a compiler that und= erstands semver to preload the semver extension, possibly allow with other = common YANG type files, extensions).

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For a compile that doesn=E2=80=99t unde= rstand semver then it would just ignore the extension, which should be fine= .

=C2=A0


Try to find even 1 compiler in the world that work= s this way.
Yes you can specially hack the extension implementati= on as if it were a built-in keyword.

I agree that it would be nice if this extens= ion was part of the core YANG language, but I don=E2=80=99t think that is n= ecessarily required.

=C2=A0


I don't think any of semver is required for an= ything.
IMO it provides a minor improvement to=C2=A0 people famil= iar with the MAJOR.MINOR.PATCH numbering.
This improvement is los= t as soon as extra letters are added and the string is no longer familiar.<= /div>

Import-by-semver seems like it is part of the base= module (no if-feature on the extension-stmt is even possible)
so= skipping the implementation of it needs a deviation (oh wait, YANG 1.1 can= 't do that either).


Thanks,

Rob

<= div>
Andy
=C2=A0

=C2=A0

=C2=A0

=C2=A0

Hi,

=C2=A0

I am wondering if there are implementations of this = draft:

=C2=A0

=C2=A0

=C2=A0

Specifically, implementation of the=C2=A0 'versi= on' extension=C2=A0

=C2=A0

=C2=A0

=C2=A0

IMO it is a really bad idea to put the semantics of = how to import modules

in one of the modules that is imported.=C2=A0 Your e= xample shows ietf-semver

imported first with no extension, but it could be la= st with a version extension.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // all other impo= rts, then last....

=C2=A0

=C2=A0=C2=A0=
=C2=A0 import ietf-semver { 
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0prefix "semver";

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 semver:version 1.1.2;


=C2=A0=C2=A0=
=C2=A0 }




Translation unit parsing is something that needs to be built into the compi=
ler.=C2=A0

This should be part of YANG 1.2 if it is done.

=C2=A0
=C2=A0 import =
example-module {
=C2=A0=C2=A0=
=C2=A0=C2=A0 prefix exmod;
=C2=A0=C2=A0=C2=A0=C2=A0 version 1.2.0+;
=C2=A0=C2=A0 }
=C2=A0

To a compiler writer, the difference is huge. (ietf-= semver extensions need to

be built-in statements in YANG, at least 'versio= n')

=C2=A0

BTW, all the import examples are missing the mandato= ry prefix-stmt

=C2=A0

=C2=A0

Andy

=C2=A0

--00000000000097c4bb0584d516d9-- From nobody Sun Mar 24 07:07:23 2019 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 395D512788C for ; Sun, 24 Mar 2019 07:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 cxfG2twZeQha for ; Sun, 24 Mar 2019 07:07:18 -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 7B88912426E for ; Sun, 24 Mar 2019 07:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30210; q=dns/txt; s=iport; t=1553436438; x=1554646038; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WEo+2IWsZngl0VwwoCMQ/t1t286NoEpYt7qdjpyW35o=; b=MjV/f1ZX16197vyhuOUU7nxMWlXWHmpAbijf6SVZZIfN3ZQtvf81wfQ4 aJPR7DQlYksxAbfhhCDuhQ9PgP+XE6gbls+dvVLPikTuiemfl7PKCaX7l i/7VD1e7XOGRnsyORYZX1qwW/zpyvmCH1P3HavRkyxeTee6a1HlM8BOwU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAACMjpdc/4YNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ6BAmiBAycKhASVSJo1DQEBI4RJAhe?= =?us-ascii?q?EZSI3Bg0BAQMBAQkBAwJtHAyFSgEBAQQjCkwQAgEIEQQBASEHAwICAjAUCQg?= =?us-ascii?q?CBA4FCBODCIERZA+sIoEvhDQChWkFgS8BizEXgUA/hCM+gmEBAQIBghSCVIJ?= =?us-ascii?q?XA4xwhB+UBwkCh2GLTiGTfpEhjSUCERWBLjUiKIEucBWDJ4sMhT9BMY50gR8?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="249629734" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 14:07:16 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2OE7GmY009454 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 14:07:16 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 09:07:16 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Sun, 24 Mar 2019 09:07:15 -0500 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: NetMod WG Thread-Topic: [netmod] import-by-semver issue Thread-Index: AQHU4arYjIn8/1YI30euxcwhgGMsT6YahbWggABuJwD//9uzgA== Date: Sun, 24 Mar 2019 14:07:15 +0000 Message-ID: <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> References: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> In-Reply-To: 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.61.79.96] Content-Type: multipart/alternative; boundary="_000_4c0a8dca338f4ca384dea933f046511eXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 14:07:21 -0000 --_000_4c0a8dca338f4ca384dea933f046511eXCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlcmUgYXJlIG1hbnkgd2F5cyB0byB3cml0ZSBhbmQgZGVzaWduIGNvbXBp bGVycy4NCg0KQ29tcGlsZXJzIHRoYXQgZG9u4oCZdCB1bmRlcnN0YW5kIGltcG9ydC1ieS1zZW12 ZXIganVzdCBpZ25vcmUgdGhlIGV4dGVuc2lvbiwgbm8gZGV2aWF0aW9uIGlzIHJlcXVpcmVkLiAg VGhleSBqdXN0IGltcG9ydCB3aGljaGV2ZXIgYXJiaXRyYXJ5IHJldmlzaW9uIHRoYXQgdGhleSB3 b3VsZCBoYXZlIGltcG9ydGVkIGFueXdheSwgYXMgc3BlY2lmaWVkIGJ5IFlBTkcgMS4xLiAgVGhl IGltcG9ydC1ieS1zZW12ZXIgc3RhdGVtZW50IGp1c3QgcmVkdWNlcyB0aGUgc2V0IG9mIHZhbGlk IG1vZHVsZXMgcmV2aXNpb25zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGltcG9ydC4NCg0KVGhhbmtz LA0KUm9iDQoNCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50 OiAyNCBNYXJjaCAyMDE5IDEyOjA3DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPg0KQ2M6IE5ldE1vZCBXRyA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtuZXRtb2RdIGltcG9ydC1ieS1zZW12ZXIgaXNzdWUNCg0KDQoNCk9uIFN1biwgTWFyIDI0LCAy MDE5IGF0IDI6NDAgQU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1h aWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwNCg0KWWVzIHdlIGFyZSBj dXJyZW50bHkgaW1wbGVtZW50aW5nIHRoZSBtb2R1bGUgdmVyc2lvbiBmaWVsZCwgYWx0aG91Z2gg dGhhdCBtYXkgY2hhbmdlIGRlcGVuZGluZyBvbiB3aGF0IGRpZmZlcmVudCB0aGUgZmluYWwgc29s dXRpb24gZW5kcyB1cCBiZWluZy4NCg0KU3VwcG9ydCBmb3IgaW1wb3J0LWJ5LXZlcnNpb24gaXMg bGVzcyBjcml0aWNhbCBmb3IgdXMsIGFuZCBoZW5jZSBpbXBsZW1lbnRhdGlvbiB3b3VsZCBsYWcu DQoNCkluIHRlcm1zIG9mIHRoZSBpc3N1ZSB0aGF0IHlvdSByYWlzZToNCg0KLSAgICAgICAgSSB3 b3VsZCBleHBlY3QgdGhhdCBhIGNvbXBpbGVyIHRoYXQgdW5kZXJzdGFuZHMgc2VtdmVyIHRvIHBy ZWxvYWQgdGhlIHNlbXZlciBleHRlbnNpb24sIHBvc3NpYmx5IGFsbG93IHdpdGggb3RoZXIgY29t bW9uIFlBTkcgdHlwZSBmaWxlcywgZXh0ZW5zaW9ucykuDQoNCi0gICAgICAgIEZvciBhIGNvbXBp bGUgdGhhdCBkb2VzbuKAmXQgdW5kZXJzdGFuZCBzZW12ZXIgdGhlbiBpdCB3b3VsZCBqdXN0IGln bm9yZSB0aGUgZXh0ZW5zaW9uLCB3aGljaCBzaG91bGQgYmUgZmluZS4NCg0KDQpUcnkgdG8gZmlu ZCBldmVuIDEgY29tcGlsZXIgaW4gdGhlIHdvcmxkIHRoYXQgd29ya3MgdGhpcyB3YXkuDQpZZXMg eW91IGNhbiBzcGVjaWFsbHkgaGFjayB0aGUgZXh0ZW5zaW9uIGltcGxlbWVudGF0aW9uIGFzIGlm IGl0IHdlcmUgYSBidWlsdC1pbiBrZXl3b3JkLg0KDQpJIGFncmVlIHRoYXQgaXQgd291bGQgYmUg bmljZSBpZiB0aGlzIGV4dGVuc2lvbiB3YXMgcGFydCBvZiB0aGUgY29yZSBZQU5HIGxhbmd1YWdl LCBidXQgSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgbmVjZXNzYXJpbHkgcmVxdWlyZWQuDQoNCg0K SSBkb24ndCB0aGluayBhbnkgb2Ygc2VtdmVyIGlzIHJlcXVpcmVkIGZvciBhbnl0aGluZy4NCklN TyBpdCBwcm92aWRlcyBhIG1pbm9yIGltcHJvdmVtZW50IHRvICBwZW9wbGUgZmFtaWxpYXIgd2l0 aCB0aGUgTUFKT1IuTUlOT1IuUEFUQ0ggbnVtYmVyaW5nLg0KVGhpcyBpbXByb3ZlbWVudCBpcyBs b3N0IGFzIHNvb24gYXMgZXh0cmEgbGV0dGVycyBhcmUgYWRkZWQgYW5kIHRoZSBzdHJpbmcgaXMg bm8gbG9uZ2VyIGZhbWlsaWFyLg0KDQpJbXBvcnQtYnktc2VtdmVyIHNlZW1zIGxpa2UgaXQgaXMg cGFydCBvZiB0aGUgYmFzZSBtb2R1bGUgKG5vIGlmLWZlYXR1cmUgb24gdGhlIGV4dGVuc2lvbi1z dG10IGlzIGV2ZW4gcG9zc2libGUpDQpzbyBza2lwcGluZyB0aGUgaW1wbGVtZW50YXRpb24gb2Yg aXQgbmVlZHMgYSBkZXZpYXRpb24gKG9oIHdhaXQsIFlBTkcgMS4xIGNhbid0IGRvIHRoYXQgZWl0 aGVyKS4NCg0KDQpUaGFua3MsDQpSb2INCg0KQW5keQ0KDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiAyMyBNYXJjaCAyMDE5IDE5OjAxDQpUbzogTmV0 TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbbmV0bW9kXSBpbXBvcnQtYnktc2VtdmVyIGlzc3VlDQoNCkhpLA0KDQpJIGFtIHdvbmRlcmlu ZyBpZiB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgZHJhZnQ6DQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDANCg0K DQpTcGVjaWZpY2FsbHksIGltcGxlbWVudGF0aW9uIG9mIHRoZSAgJ3ZlcnNpb24nIGV4dGVuc2lv bg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmct c2VtdmVyLTAwI3NlY3Rpb24tMw0KDQoNCklNTyBpdCBpcyBhIHJlYWxseSBiYWQgaWRlYSB0byBw dXQgdGhlIHNlbWFudGljcyBvZiBob3cgdG8gaW1wb3J0IG1vZHVsZXMNCmluIG9uZSBvZiB0aGUg bW9kdWxlcyB0aGF0IGlzIGltcG9ydGVkLiAgWW91ciBleGFtcGxlIHNob3dzIGlldGYtc2VtdmVy DQppbXBvcnRlZCBmaXJzdCB3aXRoIG5vIGV4dGVuc2lvbiwgYnV0IGl0IGNvdWxkIGJlIGxhc3Qg d2l0aCBhIHZlcnNpb24gZXh0ZW5zaW9uLg0KDQogICAgICAgICAgLy8gYWxsIG90aGVyIGltcG9y dHMsIHRoZW4gbGFzdC4uLi4NCg0KDQogICAgaW1wb3J0IGlldGYtc2VtdmVyIHsNCg0KICAgICAg cHJlZml4ICJzZW12ZXIiOw0KDQogICAgICBzZW12ZXI6dmVyc2lvbiAxLjEuMjsNCg0KICAgIH0N Cg0KVHJhbnNsYXRpb24gdW5pdCBwYXJzaW5nIGlzIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJl IGJ1aWx0IGludG8gdGhlIGNvbXBpbGVyLg0KVGhpcyBzaG91bGQgYmUgcGFydCBvZiBZQU5HIDEu MiBpZiBpdCBpcyBkb25lLg0KDQoNCg0KICBpbXBvcnQgZXhhbXBsZS1tb2R1bGUgew0KDQogICAg IHByZWZpeCBleG1vZDsNCg0KICAgICB2ZXJzaW9uIDEuMi4wKzsNCg0KICAgfQ0KDQoNClRvIGEg Y29tcGlsZXIgd3JpdGVyLCB0aGUgZGlmZmVyZW5jZSBpcyBodWdlLiAoaWV0Zi1zZW12ZXIgZXh0 ZW5zaW9ucyBuZWVkIHRvDQpiZSBidWlsdC1pbiBzdGF0ZW1lbnRzIGluIFlBTkcsIGF0IGxlYXN0 ICd2ZXJzaW9uJykNCg0KDQpCVFcsIGFsbCB0aGUgaW1wb3J0IGV4YW1wbGVzIGFyZSBtaXNzaW5n IHRoZSBtYW5kYXRvcnkgcHJlZml4LXN0bXQNCg0KDQpBbmR5DQoNCg== --_000_4c0a8dca338f4ca384dea933f046511eXCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnAuZ21haWwtbTcxMDExMDIzMjY5ODQ1MzA1Njhtc29saXN0cGFyYWdy YXBoLCBsaS5nbWFpbC1tNzEwMTEwMjMyNjk4NDUzMDU2OG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5n bWFpbC1tNzEwMTEwMjMyNjk4NDUzMDU2OG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5h bWU6Z21haWwtbV83MTAxMTAyMzI2OTg0NTMwNTY4bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFu ZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBhcmUgbWFu eSB3YXlzIHRvIHdyaXRlIGFuZCBkZXNpZ24gY29tcGlsZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29tcGlsZXJzIHRoYXQgZG9u4oCZdCB1bmRlcnN0YW5kIGlt cG9ydC1ieS1zZW12ZXIganVzdCBpZ25vcmUgdGhlIGV4dGVuc2lvbiwgbm8gZGV2aWF0aW9uIGlz IHJlcXVpcmVkLiZuYnNwOyBUaGV5IGp1c3QgaW1wb3J0IHdoaWNoZXZlciBhcmJpdHJhcnkNCiBy ZXZpc2lvbiB0aGF0IHRoZXkgd291bGQgaGF2ZSBpbXBvcnRlZCBhbnl3YXksIGFzIHNwZWNpZmll ZCBieSBZQU5HIDEuMS4mbmJzcDsgVGhlIGltcG9ydC1ieS1zZW12ZXIgc3RhdGVtZW50IGp1c3Qg cmVkdWNlcyB0aGUgc2V0IG9mIHZhbGlkIG1vZHVsZXMgcmV2aXNpb25zIHRoYXQgY2FuIGJlIHVz ZWQgZm9yIGltcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo YW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDsN Cjxicj4NCjxiPlNlbnQ6PC9iPiAyNCBNYXJjaCAyMDE5IDEyOjA3PGJyPg0KPGI+VG86PC9iPiBS b2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBOZXRNb2QgV0cgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtuZXRtb2RdIGltcG9ydC1ieS1zZW12ZXIgaXNzdWU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBNYXIgMjQsIDIw MTkgYXQgMjo0MCBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3 aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcyB3ZSBhcmUgY3VycmVu dGx5IGltcGxlbWVudGluZyB0aGUgbW9kdWxlIHZlcnNpb24gZmllbGQsIGFsdGhvdWdoIHRoYXQg bWF5IGNoYW5nZSBkZXBlbmRpbmcgb24gd2hhdA0KIGRpZmZlcmVudCB0aGUgZmluYWwgc29sdXRp b24gZW5kcyB1cCBiZWluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TdXBwb3J0IGZvciBpbXBvcnQtYnktdmVyc2lvbiBpcyBsZXNzIGNyaXRpY2FsIGZv ciB1cywgYW5kIGhlbmNlIGltcGxlbWVudGF0aW9uIHdvdWxkIGxhZy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0ZXJtcyBvZiB0aGUgaXNzdWUgdGhh dCB5b3UgcmFpc2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW03MTAx MTAyMzI2OTg0NTMwNTY4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIwLjRw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IHdvdWxkIGV4cGVjdCB0aGF0IGEgY29tcGlsZXIgdGhhdCB1bmRlcnN0YW5kcyBzZW12ZXIgdG8g cHJlbG9hZCB0aGUgc2VtdmVyIGV4dGVuc2lvbiwgcG9zc2libHkgYWxsb3cgd2l0aCBvdGhlciBj b21tb24gWUFORyB0eXBlIGZpbGVzLCBleHRlbnNpb25zKS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iZ21haWwtbTcxMDExMDIzMjY5ODQ1MzA1Njhtc29saXN0cGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjAuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZvciBhIGNvbXBpbGUgdGhhdCBkb2VzbuKAmXQgdW5kZXJz dGFuZCBzZW12ZXIgdGhlbiBpdCB3b3VsZCBqdXN0IGlnbm9yZSB0aGUgZXh0ZW5zaW9uLCB3aGlj aCBzaG91bGQgYmUgZmluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VHJ5IHRvIGZpbmQgZXZlbiAxIGNvbXBpbGVyIGluIHRoZSB3b3JsZCB0 aGF0IHdvcmtzIHRoaXMgd2F5LjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgeW91 IGNhbiBzcGVjaWFsbHkgaGFjayB0aGUgZXh0ZW5zaW9uIGltcGxlbWVudGF0aW9uIGFzIGlmIGl0 IHdlcmUgYSBidWlsdC1pbiBrZXl3b3JkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBuaWNlIGlmIHRoaXMg ZXh0ZW5zaW9uIHdhcyBwYXJ0IG9mIHRoZSBjb3JlIFlBTkcgbGFuZ3VhZ2UsIGJ1dCBJIGRvbuKA mXQgdGhpbmsNCiB0aGF0IGlzIG5lY2Vzc2FyaWx5IHJlcXVpcmVkLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIGFueSBv ZiBzZW12ZXIgaXMgcmVxdWlyZWQgZm9yIGFueXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1PIGl0IHByb3ZpZGVzIGEgbWlub3IgaW1w cm92ZW1lbnQgdG8mbmJzcDsgcGVvcGxlIGZhbWlsaWFyIHdpdGggdGhlIE1BSk9SLk1JTk9SLlBB VENIIG51bWJlcmluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgaW1wcm92ZW1lbnQgaXMgbG9zdCBhcyBzb29uIGFzIGV4dHJhIGxldHRl cnMgYXJlIGFkZGVkIGFuZCB0aGUgc3RyaW5nIGlzIG5vIGxvbmdlciBmYW1pbGlhci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW1wb3J0LWJ5 LXNlbXZlciBzZWVtcyBsaWtlIGl0IGlzIHBhcnQgb2YgdGhlIGJhc2UgbW9kdWxlIChubyBpZi1m ZWF0dXJlIG9uIHRoZSBleHRlbnNpb24tc3RtdCBpcyBldmVuIHBvc3NpYmxlKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28gc2tpcHBpbmcgdGhl IGltcGxlbWVudGF0aW9uIG9mIGl0IG5lZWRzIGEgZGV2aWF0aW9uIChvaCB3YWl0LCBZQU5HIDEu MSBjYW4ndCBkbyB0aGF0IGVpdGhlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9iPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBuZXRtb2QNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0K PGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gMjMgTWFy Y2ggMjAxOSAxOTowMTxicj4NCjxiPlRvOjwvYj4gTmV0TW9kIFdHICZsdDs8YSBocmVmPSJtYWls dG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW25ldG1vZF0gaW1wb3J0LWJ5LXNlbXZlciBpc3N1ZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBh bSB3b25kZXJpbmcgaWYgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGRyYWZ0Ojxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15 YW5nLXNlbXZlci0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy1zZW12ZXItMDA8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3BlY2lmaWNhbGx5 LCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUmbmJzcDsgJ3ZlcnNpb24nIGV4dGVuc2lvbiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZlcmR0LW5ldG1vZC15 YW5nLXNlbXZlci0wMCNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctc2VtdmVyLTAwI3NlY3Rpb24tMzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JTU8gaXQgaXMgYSByZWFsbHkgYmFkIGlkZWEgdG8gcHV0IHRoZSBzZW1hbnRpY3Mg b2YgaG93IHRvIGltcG9ydCBtb2R1bGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPmluIG9uZSBvZiB0aGUgbW9kdWxlcyB0aGF0IGlzIGltcG9y dGVkLiZuYnNwOyBZb3VyIGV4YW1wbGUgc2hvd3MgaWV0Zi1zZW12ZXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW1wb3J0ZWQgZmlyc3Qgd2l0 aCBubyBleHRlbnNpb24sIGJ1dCBpdCBjb3VsZCBiZSBsYXN0IHdpdGggYSB2ZXJzaW9uIGV4dGVu c2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gYWxsIG90aGVyIGlt cG9ydHMsIHRoZW4gbGFzdC4uLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsgaW1wb3J0IGlldGYtc2VtdmVyIHsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwcmVmaXggJnF1b3Q7 c2VtdmVyJnF1b3Q7Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWst YmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNlbXZlcjp2ZXJzaW9uIDEuMS4yOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGJyPg0KVHJhbnNsYXRpb24gdW5pdCBwYXJzaW5nIGlzIHNvbWV0aGlu ZyB0aGF0IG5lZWRzIHRvIGJlIGJ1aWx0IGludG8gdGhlIGNvbXBpbGVyLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHNob3Vs ZCBiZSBwYXJ0IG9mIFlBTkcgMS4yIGlmIGl0IGlzIGRvbmUuPG86cD48L286cD48L3A+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgaW1wb3J0IGV4YW1wbGUtbW9kdWxlIHs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcmVmaXggZXhtb2Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHZlcnNpb24gMS4yLjAmIzQzOzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyBhIGNvbXBpbGVyIHdyaXRl ciwgdGhlIGRpZmZlcmVuY2UgaXMgaHVnZS4gKGlldGYtc2VtdmVyIGV4dGVuc2lvbnMgbmVlZCB0 bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5iZSBidWls dC1pbiBzdGF0ZW1lbnRzIGluIFlBTkcsIGF0IGxlYXN0ICd2ZXJzaW9uJyk8bzpwPjwvbzpwPjwv cD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QlRXLCBhbGwgdGhlIGltcG9ydCBleGFt cGxlcyBhcmUgbWlzc2luZyB0aGUgbWFuZGF0b3J5IHByZWZpeC1zdG10PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4c0a8dca338f4ca384dea933f046511eXCHRCD007ciscocom_-- From nobody Sun Mar 24 07:31:31 2019 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 CFD631310ED for ; Sun, 24 Mar 2019 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 Qd5G6bsNdP4d for ; Sun, 24 Mar 2019 07:31:22 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C578130E82 for ; Sun, 24 Mar 2019 07:31:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4D27A3D; Sun, 24 Mar 2019 15:31:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 6nDSJV9hJ104; Sun, 24 Mar 2019 15:31:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 24 Mar 2019 15:31:19 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F28C200A7; Sun, 24 Mar 2019 15:31:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id SGrtwANrAxfc; Sun, 24 Mar 2019 15:31:18 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id CA3EB200A6; Sun, 24 Mar 2019 15:31:18 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sun, 24 Mar 2019 15:31:18 +0100 Received: by anna.localdomain (Postfix, from userid 501) id D6B7830077BE91; Sun, 24 Mar 2019 15:31:16 +0100 (CET) Date: Sun, 24 Mar 2019 15:31:16 +0100 From: Juergen Schoenwaelder To: "Rob Wilton (rwilton)" CC: Andy Bierman , NetMod WG Message-ID: <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Rob Wilton (rwilton)" , Andy Bierman , NetMod WG References: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 14:31:29 -0000 On Sun, Mar 24, 2019 at 02:07:15PM +0000, Rob Wilton (rwilton) wrote: > Hi Andy, >=20 > There are many ways to write and design compilers. >=20 > Compilers that don=E2=80=99t understand import-by-semver just ignore th= e extension, no deviation is required. They just import whichever arbitr= ary revision that they would have imported anyway, as specified by YANG 1= .1. The import-by-semver statement just reduces the set of valid modules= revisions that can be used for import. > If two compilers (one supporting semver, the other not) resolve imports differently, then the design is in my view somewhat broken, in particular if you allow NBC changes. /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 Sun Mar 24 08:14:26 2019 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 46263127968 for ; Sun, 24 Mar 2019 08:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 n0z7HYQxuPdj for ; Sun, 24 Mar 2019 08:14: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 DC3F812787E for ; Sun, 24 Mar 2019 08:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3018; q=dns/txt; s=iport; t=1553440460; x=1554650060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SfkAaDWZXorHSn8D4HuFmFKypv/UCvBbo6lj5+iT77s=; b=aSSw7lvv1v8um7rG7wz3k2MdsOZ6w/JiOcqmM5zI1ti7eMf+r/Xumnwq zIeLY1bTxIXyW/gy2okHhp39o0nIV9twFsrVI6NM0Z8wRHkU49MWx6xaq 0+Hb7M63H6XEcU1/A+z845Fea74UL/hAvdo4OF4OjYQa6MspibsIJltle Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADSnZdc/5hdJa1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYIQaIEDJwqEBJVImDqBew0BAR+ETQI?= =?us-ascii?q?XhGUiNgcNAQEDAQEJAQMCbRwMhUoBAQEEIxFFDAICAgEIDgIBBAEBAQICJgI?= =?us-ascii?q?CAhkXFQgIAgQOBQgTgwiBdawpgS+KHwUFgQYkAYsxF4FAP4QjPoRbCiaCQ4J?= =?us-ascii?q?XA4pqggaYJgkCky8hk36eRgIRFYEuJgMugVZwFYMnhiuKIEExjnOBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="249643024" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 15:14:19 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2OFEJGH017493 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 15:14:19 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 10:14:18 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Sun, 24 Mar 2019 10:14:18 -0500 From: "Rob Wilton (rwilton)" To: Juergen Schoenwaelder CC: Andy Bierman , NetMod WG Thread-Topic: [netmod] import-by-semver issue Thread-Index: AQHU4arYjIn8/1YI30euxcwhgGMsT6YahbWggABuJwD//9uzgIAAXWcA//+zwcA= Date: Sun, 24 Mar 2019 15:14:18 +0000 Message-ID: References: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> In-Reply-To: <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> 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.61.79.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 15:14:24 -0000 SGkgSnVlcmdlbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4N Cj4gU2VudDogMjQgTWFyY2ggMjAxOSAxNTozMQ0KPiBUbzogUm9iIFdpbHRvbiAocndpbHRvbikg PHJ3aWx0b25AY2lzY28uY29tPg0KPiBDYzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5j b20+OyBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtuZXRtb2Rd IGltcG9ydC1ieS1zZW12ZXIgaXNzdWUNCj4gDQo+IE9uIFN1biwgTWFyIDI0LCAyMDE5IGF0IDAy OjA3OjE1UE0gKzAwMDAsIFJvYiBXaWx0b24gKHJ3aWx0b24pIHdyb3RlOg0KPiA+IEhpIEFuZHks DQo+ID4NCj4gPiBUaGVyZSBhcmUgbWFueSB3YXlzIHRvIHdyaXRlIGFuZCBkZXNpZ24gY29tcGls ZXJzLg0KPiA+DQo+ID4gQ29tcGlsZXJzIHRoYXQgZG9u4oCZdCB1bmRlcnN0YW5kIGltcG9ydC1i eS1zZW12ZXIganVzdCBpZ25vcmUgdGhlIGV4dGVuc2lvbiwNCj4gbm8gZGV2aWF0aW9uIGlzIHJl cXVpcmVkLiAgVGhleSBqdXN0IGltcG9ydCB3aGljaGV2ZXIgYXJiaXRyYXJ5IHJldmlzaW9uIHRo YXQgdGhleQ0KPiB3b3VsZCBoYXZlIGltcG9ydGVkIGFueXdheSwgYXMgc3BlY2lmaWVkIGJ5IFlB TkcgMS4xLiAgVGhlIGltcG9ydC1ieS1zZW12ZXINCj4gc3RhdGVtZW50IGp1c3QgcmVkdWNlcyB0 aGUgc2V0IG9mIHZhbGlkIG1vZHVsZXMgcmV2aXNpb25zIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQo+ IGltcG9ydC4NCj4gPg0KPiANCj4gSWYgdHdvIGNvbXBpbGVycyAob25lIHN1cHBvcnRpbmcgc2Vt dmVyLCB0aGUgb3RoZXIgbm90KSByZXNvbHZlIGltcG9ydHMNCj4gZGlmZmVyZW50bHksIHRoZW4g dGhlIGRlc2lnbiBpcyBpbiBteSB2aWV3IHNvbWV3aGF0IGJyb2tlbiwgaW4gcGFydGljdWxhciBp ZiB5b3UNCj4gYWxsb3cgTkJDIGNoYW5nZXMuDQoNCkJ1dCB0aGF0IGlzIHRydWUgb2YgWUFORyBj b21waWxlcnMgdG9kYXkuICBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgcmV2aXNpb25zIG9mIGEgbW9k dWxlIHRoYXQgY291bGQgYmUgY2hvc2VuLCB0aGVuIGVhY2ggY29tcGlsZXIgaXMgYXQgbGliZXJ0 eSB0byBkZWNpZGUgd2hpY2ggcmV2aXNpb24gdG8gY2hvb3NlIChsYXN0IHBhcmFncmFwaCBvZiBz ZWN0aW9uIDUuMS4xIGluIFJGQyA3OTUwKS4NCg0KU28sIEkgd291bGQgYXJndWUgdGhhdCAiaW1w b3J0LWJ5LXZlcnNpb24iIGRvZXNuJ3QgbWFrZSBZQU5HIGNvbXBpbGVycyBhbnkgbGVzcyBjb25z aXN0ZW50IHRoYXQgdGhleSBhcmUgYWxyZWFkeSB0b2RheSwgc2luY2UgdGhhdCBpbmNvbnNpc3Rl bmN5IGFscmVhZHkgZXhpc3RzLg0KDQpJIHByZXN1bWUgdGhhdCB0aGUgcmVhbCBzb2x1dGlvbiBo ZXJlIGlzIHRvIGV4cGxpY2l0bHkgZGVmaW5lIHRoZSBmdWxsIHNldCBvZiBpbXBsZW1lbnRlZCwg aW1wb3J0LW9ubHktbW9kdWxlcyB0byB0aGUgY29tcGlsZXIgc28gdGhhdCBpdCBhbHdheXMgY29t cGlsZXMgYSBjb25zaXN0ZW50IHNjaGVtYS4gIFBlcmhhcHMgb3RoZXIgY29tcGlsZXJzIGhhdmUg ZGlmZmVyZW50IHdheXMgdG8gc29sdmUgdGhpcyBwcm9ibGVtLg0KDQpOb3RlLCBJIGFsc28gdGhp bmsgdGhhdCBZQU5HIGxpYnJhcnkgaGFzIGEgc2ltaWxhciBpbmNvbnNpc3RlbmN5LiAgSS5lLiB0 aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCB0d28gZGlmZmVyZW50IGNvbXBpbGVycyB3aWxsIGNv bnN0cnVjdCBleGFjdGx5IHRoZSBzYW1lIGRhdGFzdG9yZSBzY2hlbWEgZnJvbSB0aGUgWUFORyBs aWJyYXJ5IG91dHB1dC4gIEkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgZGVzaWduIGJ1ZywgYnV0IGFs c28gb25lIHRoYXQgd2UgYXR0ZW1wdCB0byBhZGRyZXNzIGluIGRyYWZ0LXZlcmR0LW5ldG1vZC15 YW5nLXNlbXZlci0wMC4NCg0KVGhhbmtzLA0KUm9iDQoNCj4gDQo+IC9qcw0KPiANCj4gLS0NCj4g SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4g Z0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwg Mjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAg IDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Sun Mar 24 08:21:43 2019 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 AA52C1279B3 for ; Sun, 24 Mar 2019 08:21:41 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 KuovIrqvwg6l for ; Sun, 24 Mar 2019 08:21:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41DED12787E for ; Sun, 24 Mar 2019 08:21:39 -0700 (PDT) Received: from localhost (dhcp-9104.meeting.ietf.org [31.133.145.4]) by mail.tail-f.com (Postfix) with ESMTPSA id D49831AE034E; Sun, 24 Mar 2019 16:21:36 +0100 (CET) Date: Sun, 24 Mar 2019 16:21:30 +0100 (CET) Message-Id: <20190324.162130.857835975235711028.mbj@tail-f.com> To: rwilton@cisco.com Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 15:21:42 -0000 IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBK dWVyZ2VuLA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl Pg0KPiA+IFNlbnQ6IDI0IE1hcmNoIDIwMTkgMTU6MzENCj4gPiBUbzogUm9iIFdpbHRvbiAocndp bHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KPiA+IENjOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt YXdvcmtzLmNvbT47IE5ldE1vZCBXRyA8bmV0bW9kQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJl OiBbbmV0bW9kXSBpbXBvcnQtYnktc2VtdmVyIGlzc3VlDQo+ID4gDQo+ID4gT24gU3VuLCBNYXIg MjQsIDIwMTkgYXQgMDI6MDc6MTVQTSArMDAwMCwgUm9iIFdpbHRvbiAocndpbHRvbikgd3JvdGU6 DQo+ID4gPiBIaSBBbmR5LA0KPiA+ID4NCj4gPiA+IFRoZXJlIGFyZSBtYW55IHdheXMgdG8gd3Jp dGUgYW5kIGRlc2lnbiBjb21waWxlcnMuDQo+ID4gPg0KPiA+ID4gQ29tcGlsZXJzIHRoYXQgZG9u 4oCZdCB1bmRlcnN0YW5kIGltcG9ydC1ieS1zZW12ZXIganVzdCBpZ25vcmUgdGhlDQo+ID4gPiBl eHRlbnNpb24sDQo+ID4gbm8gZGV2aWF0aW9uIGlzIHJlcXVpcmVkLiAgVGhleSBqdXN0IGltcG9y dCB3aGljaGV2ZXIgYXJiaXRyYXJ5DQo+ID4gcmV2aXNpb24gdGhhdCB0aGV5DQo+ID4gd291bGQg aGF2ZSBpbXBvcnRlZCBhbnl3YXksIGFzIHNwZWNpZmllZCBieSBZQU5HIDEuMS4gIFRoZQ0KPiA+ IGltcG9ydC1ieS1zZW12ZXINCj4gPiBzdGF0ZW1lbnQganVzdCByZWR1Y2VzIHRoZSBzZXQgb2Yg dmFsaWQgbW9kdWxlcyByZXZpc2lvbnMgdGhhdCBjYW4gYmUNCj4gPiB1c2VkIGZvcg0KPiA+IGlt cG9ydC4NCj4gPiA+DQo+ID4gDQo+ID4gSWYgdHdvIGNvbXBpbGVycyAob25lIHN1cHBvcnRpbmcg c2VtdmVyLCB0aGUgb3RoZXIgbm90KSByZXNvbHZlDQo+ID4gaW1wb3J0cw0KPiA+IGRpZmZlcmVu dGx5LCB0aGVuIHRoZSBkZXNpZ24gaXMgaW4gbXkgdmlldyBzb21ld2hhdCBicm9rZW4sIGluDQo+ ID4gcGFydGljdWxhciBpZiB5b3UNCj4gPiBhbGxvdyBOQkMgY2hhbmdlcy4NCj4gDQo+IEJ1dCB0 aGF0IGlzIHRydWUgb2YgWUFORyBjb21waWxlcnMgdG9kYXkuICBJZiB0aGVyZSBhcmUgbXVsdGlw bGUNCj4gcmV2aXNpb25zIG9mIGEgbW9kdWxlIHRoYXQgY291bGQgYmUgY2hvc2VuLCB0aGVuIGVh Y2ggY29tcGlsZXIgaXMgYXQNCj4gbGliZXJ0eSB0byBkZWNpZGUgd2hpY2ggcmV2aXNpb24gdG8g Y2hvb3NlIChsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uDQo+IDUuMS4xIGluIFJGQyA3OTUwKS4N Cg0KVGhpcyBpcyBieSBkZXNpZ24sIG9mIGNvdXJzZS4gIFdpdGggYW4gIm9wZW4iIGltcG9ydCAo bm90IGltcG9ydCBieQ0KcmV2aXNpb24pLCB0aGUgc2VydmVyIGltcGxlbWVudG9yIGlzIGZyZWUg dG8gaW1wbGVtZW50IGFueSBzZXQgb2YNCm1vZHVsZXMgdGhhdCB3b3JrIHRvZ2V0aGVyLg0KDQo+ IFNvLCBJIHdvdWxkIGFyZ3VlIHRoYXQgImltcG9ydC1ieS12ZXJzaW9uIiBkb2Vzbid0IG1ha2Ug WUFORyBjb21waWxlcnMNCj4gYW55IGxlc3MgY29uc2lzdGVudCB0aGF0IHRoZXkgYXJlIGFscmVh ZHkgdG9kYXksIHNpbmNlIHRoYXQNCj4gaW5jb25zaXN0ZW5jeSBhbHJlYWR5IGV4aXN0cy4NCg0K SSBkb24ndCB0aGluayBJIHVuZGVyc3RhbmQgQW5keSdzIG9iamVjdGlvbi4gICBJIGFsc28gdGhp bmsgdGhhdCB0aGlzDQppcyBqdXN0IGFub3RoZXIgaW1wbGVtZW50YXRpb24gZGV0YWlsLg0KDQo+ IEkgcHJlc3VtZSB0aGF0IHRoZSByZWFsIHNvbHV0aW9uIGhlcmUgaXMgdG8gZXhwbGljaXRseSBk ZWZpbmUgdGhlIGZ1bGwNCj4gc2V0IG9mIGltcGxlbWVudGVkLCBpbXBvcnQtb25seS1tb2R1bGVz IHRvIHRoZSBjb21waWxlciBzbyB0aGF0IGl0DQo+IGFsd2F5cyBjb21waWxlcyBhIGNvbnNpc3Rl bnQgc2NoZW1hLiAgUGVyaGFwcyBvdGhlciBjb21waWxlcnMgaGF2ZQ0KPiBkaWZmZXJlbnQgd2F5 cyB0byBzb2x2ZSB0aGlzIHByb2JsZW0uDQo+IA0KPiBOb3RlLCBJIGFsc28gdGhpbmsgdGhhdCBZ QU5HIGxpYnJhcnkgaGFzIGEgc2ltaWxhciBpbmNvbnNpc3RlbmN5Lg0KPiBJLmUuIHRoZXJlIGlz IG5vIGd1YXJhbnRlZSB0aGF0IHR3byBkaWZmZXJlbnQgY29tcGlsZXJzIHdpbGwgY29uc3RydWN0 DQo+IGV4YWN0bHkgdGhlIHNhbWUgZGF0YXN0b3JlIHNjaGVtYSBmcm9tIHRoZSBZQU5HIGxpYnJh cnkgb3V0cHV0Lg0KDQpDYW4geW91IGVsYWJvcmF0ZT8gIEdpdmVuIGFuIGluc3RhbmNlIG9mIFlB TkcgbGlicmFyeSwgaXQgc2hvdWxkIGJlDQpjbGVhciB3aGljaCBzZXQgb2YgbW9kdWxlcyBhcmUg dXNlZC4NCg0KDQoNCj4gSQ0KPiB0aGluayB0aGF0IHRoaXMgaXMgYSBkZXNpZ24gYnVnLCBidXQg YWxzbyBvbmUgdGhhdCB3ZSBhdHRlbXB0IHRvDQo+IGFkZHJlc3MgaW4gZHJhZnQtdmVyZHQtbmV0 bW9kLXlhbmctc2VtdmVyLTAwLg0KPiANCj4gVGhhbmtzLA0KPiBSb2INCj4gDQo+ID4gDQo+ID4g L2pzDQo+ID4gDQo+ID4gLS0NCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3 ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6 ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0 eS5kZS8+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Sun Mar 24 08:30:00 2019 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 79471130E91 for ; Sun, 24 Mar 2019 08:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 NwDgGsGowqnN for ; Sun, 24 Mar 2019 08:29:56 -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 77E70130EAA for ; Sun, 24 Mar 2019 08:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7780; q=dns/txt; s=iport; t=1553441396; x=1554650996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3OEwDhRhQAATNaP6kG9l2narFYohQneSrC3ooEk5/Nw=; b=UVtZ3zU/YKLJuu75p54tI2OrfF8+Aeg7RRhMBgVbG3pu3Op/nj7GdQd2 xbyFcREQmIYs75qbWp6jGuFHGOQ5fVDwn6TF+iDMcql/6qizN90RZnAAP E5gvWfMo7AsedfzQqPoCfZ8OUvgWmbdFhM4absp1EaSuoH+G6rvZ1Cvkp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAwoZdc/4cNJK1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYFhL2iBAycKhASVSJo1DQEBGAuEA0Y?= =?us-ascii?q?CF4RlIjcGDQEBAwEBCQEDAm0cDIVKAQEBBAEBIRE6CwwCAgIBCA4CAQQBAQE?= =?us-ascii?q?CAiYCAgIZDAsVCAgCBA4FCBODCIF1D6wfgS+KHwUFgQYkAYsxF4FAP4ERgxI?= =?us-ascii?q?+gmEBAYFLLQomgkOCVwOKaoIGmCYJApMvIZN+nkYCERWBLjUigVZwFTuCbIY?= =?us-ascii?q?rhGGFP0ExjnOBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="249230996" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 15:29:55 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2OFTtnr028216 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 15:29:55 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 10:29:54 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Sun, 24 Mar 2019 10:29:54 -0500 From: "Rob Wilton (rwilton)" To: Martin Bjorklund CC: "j.schoenwaelder@jacobs-university.de" , "netmod@ietf.org" Thread-Topic: [netmod] import-by-semver issue Thread-Index: AQHU4arYjIn8/1YI30euxcwhgGMsT6YahbWggABuJwD//9uzgIAAXWcA//+zwcCAAFpIAP//rGjA Date: Sun, 24 Mar 2019 15:29:54 +0000 Message-ID: <468413dab2794f46979abafb2cb33c43@XCH-RCD-007.cisco.com> References: <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> <20190324.162130.857835975235711028.mbj@tail-f.com> In-Reply-To: <20190324.162130.857835975235711028.mbj@tail-f.com> 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.61.79.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 15:29:58 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIEJqb3JrbHVu ZCA8bWJqQHRhaWwtZi5jb20+DQo+IFNlbnQ6IDI0IE1hcmNoIDIwMTkgMTY6MjINCj4gVG86IFJv YiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCj4gQ2M6IGouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbbmV0bW9kXSBpbXBvcnQtYnktc2VtdmVyIGlzc3VlDQo+IA0KPiAiUm9iIFdpbHRvbiAocndp bHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gSGkgSnVlcmdlbiwNCj4gPg0K PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEp1ZXJnZW4gU2No b2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiA+ID4g U2VudDogMjQgTWFyY2ggMjAxOSAxNTozMQ0KPiA+ID4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24p IDxyd2lsdG9uQGNpc2NvLmNvbT4NCj4gPiA+IENjOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT47IE5ldE1vZCBXRw0KPiA8bmV0bW9kQGlldGYub3JnPg0KPiA+ID4gU3ViamVjdDog UmU6IFtuZXRtb2RdIGltcG9ydC1ieS1zZW12ZXIgaXNzdWUNCj4gPiA+DQo+ID4gPiBPbiBTdW4s IE1hciAyNCwgMjAxOSBhdCAwMjowNzoxNVBNICswMDAwLCBSb2IgV2lsdG9uIChyd2lsdG9uKSB3 cm90ZToNCj4gPiA+ID4gSGkgQW5keSwNCj4gPiA+ID4NCj4gPiA+ID4gVGhlcmUgYXJlIG1hbnkg d2F5cyB0byB3cml0ZSBhbmQgZGVzaWduIGNvbXBpbGVycy4NCj4gPiA+ID4NCj4gPiA+ID4gQ29t cGlsZXJzIHRoYXQgZG9u4oCZdCB1bmRlcnN0YW5kIGltcG9ydC1ieS1zZW12ZXIganVzdCBpZ25v cmUgdGhlDQo+ID4gPiA+IGV4dGVuc2lvbiwNCj4gPiA+IG5vIGRldmlhdGlvbiBpcyByZXF1aXJl ZC4gIFRoZXkganVzdCBpbXBvcnQgd2hpY2hldmVyIGFyYml0cmFyeQ0KPiA+ID4gcmV2aXNpb24g dGhhdCB0aGV5IHdvdWxkIGhhdmUgaW1wb3J0ZWQgYW55d2F5LCBhcyBzcGVjaWZpZWQgYnkgWUFO Rw0KPiA+ID4gMS4xLiAgVGhlIGltcG9ydC1ieS1zZW12ZXIgc3RhdGVtZW50IGp1c3QgcmVkdWNl cyB0aGUgc2V0IG9mIHZhbGlkDQo+ID4gPiBtb2R1bGVzIHJldmlzaW9ucyB0aGF0IGNhbiBiZSB1 c2VkIGZvciBpbXBvcnQuDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gSWYgdHdvIGNvbXBpbGVycyAo b25lIHN1cHBvcnRpbmcgc2VtdmVyLCB0aGUgb3RoZXIgbm90KSByZXNvbHZlDQo+ID4gPiBpbXBv cnRzIGRpZmZlcmVudGx5LCB0aGVuIHRoZSBkZXNpZ24gaXMgaW4gbXkgdmlldyBzb21ld2hhdCBi cm9rZW4sDQo+ID4gPiBpbiBwYXJ0aWN1bGFyIGlmIHlvdSBhbGxvdyBOQkMgY2hhbmdlcy4NCj4g Pg0KPiA+IEJ1dCB0aGF0IGlzIHRydWUgb2YgWUFORyBjb21waWxlcnMgdG9kYXkuICBJZiB0aGVy ZSBhcmUgbXVsdGlwbGUNCj4gPiByZXZpc2lvbnMgb2YgYSBtb2R1bGUgdGhhdCBjb3VsZCBiZSBj aG9zZW4sIHRoZW4gZWFjaCBjb21waWxlciBpcyBhdA0KPiA+IGxpYmVydHkgdG8gZGVjaWRlIHdo aWNoIHJldmlzaW9uIHRvIGNob29zZSAobGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbg0KPiA+IDUu MS4xIGluIFJGQyA3OTUwKS4NCj4gDQo+IFRoaXMgaXMgYnkgZGVzaWduLCBvZiBjb3Vyc2UuICBX aXRoIGFuICJvcGVuIiBpbXBvcnQgKG5vdCBpbXBvcnQgYnkgcmV2aXNpb24pLCB0aGUNCj4gc2Vy dmVyIGltcGxlbWVudG9yIGlzIGZyZWUgdG8gaW1wbGVtZW50IGFueSBzZXQgb2YgbW9kdWxlcyB0 aGF0IHdvcmsgdG9nZXRoZXIuDQo+IA0KPiA+IFNvLCBJIHdvdWxkIGFyZ3VlIHRoYXQgImltcG9y dC1ieS12ZXJzaW9uIiBkb2Vzbid0IG1ha2UgWUFORyBjb21waWxlcnMNCj4gPiBhbnkgbGVzcyBj b25zaXN0ZW50IHRoYXQgdGhleSBhcmUgYWxyZWFkeSB0b2RheSwgc2luY2UgdGhhdA0KPiA+IGlu Y29uc2lzdGVuY3kgYWxyZWFkeSBleGlzdHMuDQo+IA0KPiBJIGRvbid0IHRoaW5rIEkgdW5kZXJz dGFuZCBBbmR5J3Mgb2JqZWN0aW9uLiAgIEkgYWxzbyB0aGluayB0aGF0IHRoaXMNCj4gaXMganVz dCBhbm90aGVyIGltcGxlbWVudGF0aW9uIGRldGFpbC4NCj4gDQo+ID4gSSBwcmVzdW1lIHRoYXQg dGhlIHJlYWwgc29sdXRpb24gaGVyZSBpcyB0byBleHBsaWNpdGx5IGRlZmluZSB0aGUgZnVsbA0K PiA+IHNldCBvZiBpbXBsZW1lbnRlZCwgaW1wb3J0LW9ubHktbW9kdWxlcyB0byB0aGUgY29tcGls ZXIgc28gdGhhdCBpdA0KPiA+IGFsd2F5cyBjb21waWxlcyBhIGNvbnNpc3RlbnQgc2NoZW1hLiAg UGVyaGFwcyBvdGhlciBjb21waWxlcnMgaGF2ZQ0KPiA+IGRpZmZlcmVudCB3YXlzIHRvIHNvbHZl IHRoaXMgcHJvYmxlbS4NCj4gPg0KPiA+IE5vdGUsIEkgYWxzbyB0aGluayB0aGF0IFlBTkcgbGli cmFyeSBoYXMgYSBzaW1pbGFyIGluY29uc2lzdGVuY3kuDQo+ID4gSS5lLiB0aGVyZSBpcyBubyBn dWFyYW50ZWUgdGhhdCB0d28gZGlmZmVyZW50IGNvbXBpbGVycyB3aWxsIGNvbnN0cnVjdA0KPiA+ IGV4YWN0bHkgdGhlIHNhbWUgZGF0YXN0b3JlIHNjaGVtYSBmcm9tIHRoZSBZQU5HIGxpYnJhcnkg b3V0cHV0Lg0KPiANCj4gQ2FuIHlvdSBlbGFib3JhdGU/ICBHaXZlbiBhbiBpbnN0YW5jZSBvZiBZ QU5HIGxpYnJhcnksIGl0IHNob3VsZCBiZSBjbGVhciB3aGljaA0KPiBzZXQgb2YgbW9kdWxlcyBh cmUgdXNlZC4NCg0KRm9yIG1vZHVsZXMgdGhhdCBhcmUgImltcG9ydC1vbmx5IiByYXRoZXIgdGhh biAiaW1wbGVtZW50ZWQiIHRoZW4gc29tZSBtb2R1bGVzIG1pZ2h0IHVzZSBpbXBvcnQtYnktcmV2 aXNpb24gdG8gaW1wb3J0IGEgc3BlY2lmaWMgcmV2aXNpb24sIGFuZCBvdGhlciBtb2R1bGVzIG1p Z2h0IGp1c3QgdXNlIGltcG9ydCAod2l0aG91dCByZXZpc2lvbikuICBJbiB0aGlzIGNhc2UsIHRo ZSBjb21waWxlciBjYW4gY2hvb3NlIHdoaWNoIHJldmlzaW9uIGl0IHVzZXMgdG8gc2F0aXNmeSB0 aGF0IGltcG9ydCAoZS5nLiBnZXR0aW5nIGRpZmZlcmVudCBncm91cGluZyBkZWZpbml0aW9ucyku DQoNCkluIGRyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXNlbXZlci0wMCwgd2UgYWltIHRvIHJlc29s dmUgdGhpcyBhbWJpZ3VpdHkgd2l0aCB0aGUgZm9sbG93aW5nIHRleHQgdGhhdCBpbmNvcnBvcmF0 ZXMgc2VtdmVyLCBhIHNpbWlsYXIgc29sdXRpb24gb3IganVzdCB1c2luZyB0aGUgbGF0ZXN0IHJl dmlzaW9uIGRhdGVzIGNvdWxkIGFsc28gYmUgZGV2aXNlZDoNCg0KNS4yLiAgUmVzb2x2aW5nIGFt YmlndW91cyBtb2R1bGUgaW1wb3J0cw0KDQogICBBIFlBTkcgZGF0YXN0b3JlIHNjaGVtYSwgZGVm aW5lZCBpbiBbUkZDODUyNV0sIGNhbiBzcGVjaWZ5IG11bHRpcGxlDQogICByZXZpc2lvbnMgb2Yg YSBZQU5HIG1vZHVsZSBpbiB0aGUgc2NoZW1hIHVzaW5nIHRoZSAnaW1wb3J0LW9ubHknDQogICBs aXN0LCB3aXRoIHRoZSByZXF1aXJlbWVudCBmcm9tIFtSRkM3OTUwXSB0aGF0IG9ubHkgYSBzaW5n bGUgcmV2aXNpb24NCiAgIG9mIGEgWUFORyBtb2R1bGUgbWF5IGJlIGltcGxlbWVudGVkLg0KDQog ICBJZiBhIFlBTkcgbW9kdWxlIGltcG9ydCBzdGF0ZW1lbnQgZG9lcyBub3Qgc3BlY2lmeSBhIHNw ZWNpZmljIHZlcnNpb24NCiAgIG9yIHJldmlzaW9uIHdpdGhpbiB0aGUgZGF0YXN0b3JlIHNjaGVt YSB0aGVuIGl0IGNvdWxkIGJlIGFtYmlndW91cyBhcw0KICAgdG8gd2hpY2ggbW9kdWxlIHJldmlz aW9uIHRoZSBpbXBvcnQgc3RhdGVtZW50IHNob3VsZCByZXNvbHZlIHRvLg0KICAgSGVuY2UsIGEg ZGF0YXN0b3JlIHNjaGVtYSBjb25zdHJ1Y3RlZCBieSBhIGNsaWVudCB1c2luZyB0aGUNCiAgIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBZQU5HIGxpYnJhcnkgbWF5IG5vdCBleGFjdGx5IG1hdGNo IHRoZQ0KICAgZGF0YXN0b3JlIHNjaGVtYSBhY3R1YWxseSB1c2VkIGJ5IHRoZSBzZXJ2ZXIuDQoN CiAgIFRoZSBmb2xsb3dpbmcgcnVsZXMgcmVtb3ZlIHRoZSBhbWJpZ3VpdHk6DQoNCiAgIElmIGEg bW9kdWxlIGltcG9ydCBzdGF0ZW1lbnQgY291bGQgcmVzb2x2ZSB0byBtb3JlIHRoYW4gb25lIG1v ZHVsZQ0KICAgcmV2aXNpb24gZGVmaW5lZCBpbiB0aGUgZGF0YXN0b3JlIHNjaGVtYSwgYW5kIG9u ZSBvZiB0aG9zZSByZXZpc2lvbnMNCiAgIGlzIGltcGxlbWVudGVkIChpLmUuLCBub3QgYW4gJ2lt cG9ydC1vbmx5JyBtb2R1bGUpLCB0aGVuIHRoZSBpbXBvcnQNCiAgIHN0YXRlbWVudCBNVVNUIHJl c29sdmUgdG8gdGhlIHJldmlzaW9uIG9mIHRoZSBtb2R1bGUgdGhhdCBpcyBkZWZpbmVkDQogICBh cyBiZWluZyBpbXBsZW1lbnRlZCBieSB0aGUgZGF0YXN0b3JlIHNjaGVtYS4NCg0KICAgSWYgYSBt b2R1bGUgaW1wb3J0IHN0YXRlbWVudCBjb3VsZCByZXNvbHZlIHRvIG1vcmUgdGhhbiBvbmUgbW9k dWxlDQogICByZXZpc2lvbiBkZWZpbmVkIGluIHRoZSBkYXRhc3RvcmUgc2NoZW1hLCBhbmQgbm9u ZSBvZiB0aG9zZSByZXZpc2lvbnMNCiAgIGFyZSBpbXBsZW1lbnRlZCwgYnV0IG9uZSBvZiBtb3Jl IG1vZHVsZXMgcmV2aXNpb25zIHNwZWNpZnkgYSBZQU5HDQogICBzZW1hbnRpYyB2ZXJzaW9uLCB0 aGVuIHRoZSBpbXBvcnQgTVVTVCByZXNvbHZlIHRvIHRoZSBtb2R1bGUgd2l0aCB0aGUNCiAgIGdy ZWF0ZXN0IHZlcnNpb24gbnVtYmVyLCBhY2NvcmRpbmcgdG8gdGhlIHZlcnNpb24gY29tcGFyaXNv biBydWxlcyBpbg0KICAgU2VjdGlvbiAzLg0KDQogICBJZiBhIG1vZHVsZSBpbXBvcnQgc3RhdGVt ZW50IGNvdWxkIHJlc29sdmUgdG8gbW9yZSB0aGFuIG9uZSBtb2R1bGUNCiAgIHJldmlzaW9uIGRl ZmluZWQgaW4gdGhlIGRhdGFzdG9yZSBzY2hlbWEsIG5vbmUgb2YgdGhvc2UgcmV2aXNpb25zIGFy ZQ0KICAgaW1wbGVtZW50ZWQsIGFuZCBub25lIG9mIHRoZSBtb2R1bGVzIHJldmlzaW9ucyBoYXZl IGEgWUFORyBzZW1hbnRpYw0KICAgdmVyc2lvbiBudW1iZXIsIHRoZW4gdGhlIGltcG9ydCBNVVNU IHJlc29sdmUgdG8gdGhlIG1vZHVsZSB0aGF0IGhhcw0KICAgdGhlIG1vc3QgcmVjZW50IHJldmlz aW9uIGRhdGUuDQoNClRoYW5rcywNClJvYg0KDQoNCj4gDQo+IA0KPiANCj4gPiBJDQo+ID4gdGhp bmsgdGhhdCB0aGlzIGlzIGEgZGVzaWduIGJ1ZywgYnV0IGFsc28gb25lIHRoYXQgd2UgYXR0ZW1w dCB0bw0KPiA+IGFkZHJlc3MgaW4gZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctc2VtdmVyLTAwLg0K PiA+DQo+ID4gVGhhbmtzLA0KPiA+IFJvYg0KPiA+DQo+ID4gPg0KPiA+ID4gL2pzDQo+ID4gPg0K PiA+ID4gLS0NCj4gPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg ICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+ID4gPiBGYXg6ICAg KzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5k ZS8+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Sun Mar 24 09:14:58 2019 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 DFD0812423B for ; Sun, 24 Mar 2019 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 x0Tv6e57wmuB for ; Sun, 24 Mar 2019 09:14:55 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF501200ED for ; Sun, 24 Mar 2019 09:14:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9BBC18B2; Sun, 24 Mar 2019 17:14:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id H2uGtvhiGnrO; Sun, 24 Mar 2019 17:14:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 24 Mar 2019 17:14:53 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E540200A7; Sun, 24 Mar 2019 17:14:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id GXOSx3cOZsqm; Sun, 24 Mar 2019 17:14:53 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0B0E7200A6; Sun, 24 Mar 2019 17:14:52 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sun, 24 Mar 2019 17:14:52 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 1E12030077C15A; Sun, 24 Mar 2019 17:14:51 +0100 (CET) Date: Sun, 24 Mar 2019 17:14:51 +0100 From: Juergen Schoenwaelder To: "Rob Wilton (rwilton)" CC: Andy Bierman , NetMod WG Message-ID: <20190324161451.35uus4wwjjwbgarh@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Rob Wilton (rwilton)" , Andy Bierman , NetMod WG References: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 16:14:57 -0000 On Sun, Mar 24, 2019 at 03:14:18PM +0000, Rob Wilton (rwilton) wrote: > > But that is true of YANG compilers today. If there are multiple revisions of a module that could be chosen, then each compiler is at liberty to decide which revision to choose (last paragraph of section 5.1.1 in RFC 7950). > The difference is that NBC changes are not allowed. As long as you find a certain symbol, it has fixed and predictable semantics. Sorry, but changing the way the import statement works is an NBC change of YANG and this can't be done with extensions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Mar 24 10:49:56 2019 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 40147120092 for ; Sun, 24 Mar 2019 10:49:47 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lZoTn4SfP7oT for ; Sun, 24 Mar 2019 10:49:44 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 A0E49120075 for ; Sun, 24 Mar 2019 10:49:43 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id f18so5818983lja.10 for ; Sun, 24 Mar 2019 10:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kW9dFZZ4q62+09HT+z0TRGVH0q9efYzoV9J5DqPqpk4=; b=kQzekxqMBL3WQ80JrKWuZlaJBOUjT/MjI5LsbHBR/L/97RCjCzeY9QgQD0hOmrK4Yz 5RKs7RkQe0IuNzdSY99bUqraJhgd2uOIxKQF8fweU9ybs0fRufdGXCMBDUJT2MHzs1KA E3bKSLUUjMeVT/rJGAkmPoZy5hpbemdytDFuLMW7VGlGqMla78V5fE9wnvy5VttzIPCO Ch5esFw5sptEJB7hBF1fbSkm6kBmvwBbcfpOVldolAt0Bl0/9HwrPeWQ2j71vxsndq5j +2fWMuOM4Ev85AZfKnZ9njCW/nDB+g36uRiL5wl+ZV7KQDFPwRVMtj4gw4zkmC/ZbzO8 pjOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kW9dFZZ4q62+09HT+z0TRGVH0q9efYzoV9J5DqPqpk4=; b=NIutZCDQUd3ptrIB3SzHOVjrNXXF+MAAQmNSsut3cjqWlE1DlR1wpkjmX58SOQOZ9o nMnbIKgjyAhPOwAY1K+QM1r8SaOLQwXzw9+WpgJWu6fN3+zfSmaPlPnxx/zE3zLZY4zh VgPCWn3p33fj5TdKuIoA6m7tP2F3/xsj+4fMa5w2EyhRcLWO/8/47PiDvnZExVTGGAeR WwgorkZbhw6J5OHgObfm+d5PQiBVQkVrGXPWt9SXpoQpKO5amD8qVyCJdlK2hJLVJQIo SZDtuMirRWfUFiakZSxnonrteSiFxjgcIq6Be75aWG0rJDVegiPX1Cw4Ch68kw8Z+a54 wGgA== X-Gm-Message-State: APjAAAXGHI/8Vf/5FP+Oa1CCG+F8AvLNrTDJ3p1EbJqnsmOmF/6Ji8pq Lu94/i4Zly+FLSkAB43IPsnC7oJdcKswJQZ/GN7ziQ== X-Google-Smtp-Source: APXvYqzrLKF7uD3aeqqyhRd37D/wgzqpbJpMM5hXufZQGplJ8PEXGEC3WXab8kZlzMT3pVg784yB+ZDMMUTPV1y/3ig= X-Received: by 2002:a2e:12c4:: with SMTP id 65mr10905468ljs.141.1553449781740; Sun, 24 Mar 2019 10:49:41 -0700 (PDT) MIME-Version: 1.0 References: <892d5ab4649549698808a6150067f840@XCH-RCD-007.cisco.com> <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> <20190324161451.35uus4wwjjwbgarh@anna.jacobs.jacobs-university.de> In-Reply-To: <20190324161451.35uus4wwjjwbgarh@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Sun, 24 Mar 2019 10:49:30 -0700 Message-ID: To: Juergen Schoenwaelder , "Rob Wilton (rwilton)" , Andy Bierman , NetMod WG Content-Type: multipart/alternative; boundary="0000000000006ad7560584dab6f3" Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 17:49:55 -0000 --0000000000006ad7560584dab6f3 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Mar 24, 2019 at 03:14:18PM +0000, Rob Wilton (rwilton) wrote: > > > > But that is true of YANG compilers today. If there are multiple > revisions of a module that could be chosen, then each compiler is at > liberty to decide which revision to choose (last paragraph of section 5.1.1 > in RFC 7950). > > > > The difference is that NBC changes are not allowed. As long as you > find a certain symbol, it has fixed and predictable semantics. > > Sorry, but changing the way the import statement works is an NBC > change of YANG and this can't be done with extensions. > > I strongly agree. The expected behavior for tools needs to be consistent, especially for the construction of the schema tree, which depends on the import rules. Implementation complexity should matter in the IETF, but it does not. Just keep raising the complexity up to 10 and complain that the tools have bugs, as if the two are unrelated. (Simply looking for a hardwired string "semver:version" will not work since the prefix is not required to be "semver" in the import-stmt.) > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000006ad7560584dab6f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 9:14 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Mar 24, 2019 at 03:14:18PM +0= 000, Rob Wilton (rwilton) wrote:
>
> But that is true of YANG compilers today.=C2=A0 If there are multiple = revisions of a module that could be chosen, then each compiler is at libert= y to decide which revision to choose (last paragraph of section 5.1.1 in RF= C 7950).
>

The difference is that NBC changes are not allowed. As long as you
find a certain symbol, it has fixed and predictable semantics.

Sorry, but changing the way the import statement works is an NBC
change of YANG and this can't be done with extensions.


I strongly agree.
The expect= ed behavior for tools needs to be consistent, especially for
the = construction of the schema tree, which depends on the import rules.

Implementation complexity should matter in the IETF, but = it does not.
Just keep raising the complexity up to 10 and compla= in that the tools have bugs,
as if the two are unrelated. (Simply= looking for a hardwired string "semver:version"
will n= ot work since the prefix is not required to be "semver" in the im= port-stmt.)


=C2=A0
/js

=C2=A0
Andy

--
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<https://www.jacobs-university.de/>
--0000000000006ad7560584dab6f3-- From nobody Sun Mar 24 11:39:43 2019 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 F0819120090; Sun, 24 Mar 2019 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 JTOEA2HykibX; Sun, 24 Mar 2019 11:39:24 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 C0CA7120091; Sun, 24 Mar 2019 11:39:24 -0700 (PDT) Received: from [IPv6:2601:647:4201:4561:7880:d3dd:ff74:edbf] ([IPv6:2601:647:4201:4561:7880:d3dd:ff74:edbf]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x2OIdNqt039936; Sun, 24 Mar 2019 18:39:24 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8FDE05E2-4CBC-4789-A2CD-F365489FDFE8" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 24 Mar 2019 11:39:06 -0700 In-Reply-To: <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> Cc: netmod@ietf.org, "netmod-ver-dt@ietf.org" To: Lou Berger References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 18:39:34 -0000 --Apple-Mail=_8FDE05E2-4CBC-4789-A2CD-F365489FDFE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 22, 2019, at 12:07, Lou Berger wrote: >=20 > Hi, >=20 > Thank you all for the good input on this thread. >=20 > With the understanding that a 00 working group document is a starting = point for the working group rather than a document that is ready for = last call - we believe there is sufficient support to adopt this = document as a starting point for the requirements we wish to address on = this topic. >=20 > It is clear that there is still work to be done on this document = before we can declare consensus on it and, not surprisingly, that there = is more work to be done on the solution. >=20 > Authors,=20 >=20 > Please resubmit this document as = draft-ietf-netmod-yang-revision-reqs-00 with the only change being the = name and publication date. The -01 version should focus on resolving = issues raised during adoption. Of course the document is subject to = normal WG input and processing. >=20 > Please note the 'file' name change -this is to indicate that the = requirements are not presupposing a specific solution. It is also = consistent with how versioning is defined within the document currently. >=20 > Note: we would like to try to continue the list discussion in next = week's session and ask the Authors/DT to summarize issues raised during = the adoption call and lead a discussion to help resolve these issues. >=20 I think this meeting is great opportunity to decide what steps need to = be taken to advance the document within the working group. Martin specifically objects to the presence of of = Non-Backward-Compatible changes.=20 Many modules outside the IETF are already incompatible with roc 7950 = yang 1.1 revision rules. So that cat may be out of the bag at least with = respect to the real world. the question remains what to do about that? --Apple-Mail=_8FDE05E2-4CBC-4789-A2CD-F365489FDFE8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On Mar 22, 2019, at 12:07, Lou Berger <lberger@labn.net> wrote:

Hi,

Thank you all for the good input on this thread.

With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.

It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.

Authors,

Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.  The -01 version should focus on resolving issues raised during adoption.  Of course the document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.

I think this meeting is great opportunity to decide what steps need to be taken to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible changes. 

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 revision rules. So that cat may be out of the bag at least with respect to the real world. the question remains what to do about that?




--Apple-Mail=_8FDE05E2-4CBC-4789-A2CD-F365489FDFE8-- From nobody Sun Mar 24 13:05:39 2019 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 4EB161200A3 for ; Sun, 24 Mar 2019 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yVTsEpMUBv4e for ; Sun, 24 Mar 2019 13:05:35 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 3058E12009E for ; Sun, 24 Mar 2019 13:05:35 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id l7so5975619ljg.6 for ; Sun, 24 Mar 2019 13:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sJAXk4gIQySt15zzZdbcGgVFY7ds2ogbzxt26H/nPuw=; b=nf2lewZhsvoHpVrIUKjOjYAqxEtXuI5wg0IMErDrMnzpzN60cNbYLLee0jh9ldZejd UDBJYGxcet3hLOi7W97UiKz0io6j4wLIv1oPl+hWq09p6YWV/+n+AxWGJ6qTTVrNQ0xV OH/8FAaCYyFePJSUo2J/2nyhDyKQGu1qkPHNsMQnxEd2pdxXwSMxoLzxNtVqJPb1+vI7 xSjGm9cozCom4eDJSHJItqFtvy7Q78wNnupFMEONjK6o3g6Svn3fblwttn9k2/O5TyYa 4pFYYvnfzOQFFVOBaPvXELdrBgp+01LlMR28J//zaFhcikRiq/njVqbXp1gOYFXcmLWq upFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sJAXk4gIQySt15zzZdbcGgVFY7ds2ogbzxt26H/nPuw=; b=ohCcsMfKmigmCN6zbhUdMhfAt9uLaEp28PAcjcl6hpjhl72K4c0odlGaQfG4649Ibs gQ6xfSJctZzuXEyo+LmEqVhABGByFOUE64plqsEbkAMMqyr+HCMXJYcRTCwGG2sOZ/TW Mh2iUC3tK4wa7UuiyIMX1Z4mrCFTzvL/YJraot+pYNV0LLIrleAnjExEiIKWcoG1CGa8 PuRIOhPieYv2X71XxFkHspa40BByGcXFryxT3FFbnlIcytLCECcopKthzNcl022kbNir Of29QeId+dIEy7j1ZYM48vUlfcyVxSwGRjp1jBOq6/+9gm5hwzPsdYFfrCOamD4XQd2E JRdg== X-Gm-Message-State: APjAAAW3euawwNryps/csKa2C8Z36iJzbTYdaq+49WtztoKqmssoAzbP GYt5CCG/VAjKdjRxsL7e+kGnELXMyeoPDqsZKF+xDQ== X-Google-Smtp-Source: APXvYqwa/4WXEwRHT5eRokjATU4/4yWHp966bLtErbtAo7+Y8XDu+ylr0EzfitsQLJbLXeprZyzny36kfnytahReLqc= X-Received: by 2002:a2e:85d2:: with SMTP id h18mr10752586ljj.128.1553457933237; Sun, 24 Mar 2019 13:05:33 -0700 (PDT) MIME-Version: 1.0 References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> In-Reply-To: From: Andy Bierman Date: Sun, 24 Mar 2019 13:05:21 -0700 Message-ID: To: Joel Jaeggli Cc: Lou Berger , "netmod-ver-dt@ietf.org" , NetMod WG Content-Type: multipart/alternative; boundary="00000000000048d2020584dc9cb3" Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:05:38 -0000 --00000000000048d2020584dc9cb3 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli wrote: > > > On Mar 22, 2019, at 12:07, Lou Berger wrote: > > Hi, > > Thank you all for the good input on this thread. > > With the understanding that a 00 working group document is a starting > point for the working group rather than a document that is ready for last > call - we believe there is sufficient support to adopt this document as a > starting point for the requirements we wish to address on this topic. > > It is clear that there is still work to be done on this document before we > can declare consensus on it and, not surprisingly, that there is more work > to be done on the solution. > > Authors, > > Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 > with the only change being the name and publication date. The -01 version > should focus on resolving issues raised during adoption. Of course the > document is subject to normal WG input and processing. > > Please note the 'file' name change -this is to indicate that the > requirements are not presupposing a specific solution. It is also > consistent with how versioning is defined within the document currently. > > Note: we would like to try to continue the list discussion in next week's > session and ask the Authors/DT to summarize issues raised during the > adoption call and lead a discussion to help resolve these issues. > > I think this meeting is great opportunity to decide what steps need to be > taken to advance the document within the working group. > > Martin specifically objects to the presence of of Non-Backward-Compatible > changes. > > Many modules outside the IETF are already incompatible with roc 7950 yang > 1.1 revision rules. So that cat may be out of the bag at least with respect > to the real world. the question remains what to do about that? > > I do not look at the problem as allowing NBC so much as making it clear to toolmakers what is going on, like a deviation to the versioning rules. BTW, I do not support adoption of the requirements document at all. I support the work on versioning as part of the charter, and I am happy to accept the design team solution draft as the starting point, and just work on a solution. But I think the solution is a bit flawed. 1) extensions are optional and problematic since they can be revisioned without changing the language version; the solution needs to use new YANG 1.2 statements instead of extensions 2) the version string does not have to contain all the NBC semantics. The solution draft does not show modified semver. It should be done differently than overloading the version string; Let's say a fork is done on 1.3.0. revision 2017-07-30 { description "Added leaf foo-64"; semver:module-version "1.3.0"; } start with a legal change, just not at the HEAD revision 2019-01-10 { description "Added leaf bar-64"; semver:module-version "1.3.1"; } then later, an NBC change revision 2019-02-10 { description "Changed leaf bar-64 default-stmt"; semver:module-version "1.3.2"; semver:nbc-change; } then later, a legal change revision 2019-03-10 { description "Added leaf baz-64"; semver:module-version "1.3.3"; } This is a form of an inline deviation-stmt. The YANG update rules are not changing. They are just not being followed. The NBC info belongs in the revision-stmt, not overloading the version string. Not every major revision will mean NBC changes anyway. Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000048d2020584dc9cb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 11:39 AM Joel= Jaeggli <joelja@bogus.com> w= rote:


On Mar 22, 2019, at 12:07, Lou Berger <lberger@labn.net> wrote:

=20 =20 =20

Hi,

Thank you all for the good input on= this thread.

With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.

It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.

Authors,

Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.=C2=A0 The -01 version should focus on resolving issues raised during adoption.=C2=A0 Of course the document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that = the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list disc= ussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.

I think th= is meeting is great opportunity to decide what steps need to be taken to ad= vance the document within the working group.

Marti= n specifically objects to the presence of of Non-Backward-Compatible change= s.=C2=A0

Many modules outside the IETF are already= incompatible with roc 7950 yang 1.1 revision rules. So that cat may be out= of the bag at least with respect to the real world. the question remains w= hat to do about that?


I do not look at the problem as allowing NBC so = much as making it clear to toolmakers what is going on,
like a de= viation to the versioning rules.

BTW, I do not sup= port adoption of the requirements document at all.
I support the = work on versioning as part of the charter, and I am happy to
acce= pt the design team solution draft as the starting point, and just work on a= solution.

But I think the solution is a bit flawe= d.

1) extensions are optional and problematic sinc= e they can be revisioned without changing
=C2=A0 =C2=A0 the langu= age version; the solution needs to use new YANG 1.2 statements instead of e= xtensions

2) the version string does not have to c= ontain all the NBC semantics.
The solution draft does not show mo= dified semver.
It should be done differently than overloading the= version string;

Let's say a fork is done on 1= .3.0.
      =
   revision 2017-07-30 {
           description "Added leaf foo-64";
           semver:module-version "1.3.0";
         }

start with a leg=
al change, just not at the HEAD
         revision 2019-01-10 {
           description "Added leaf bar-64";
           semver:module-version "1.3.1";
         }

then later, an NBC=
 change
        revision 2019-02-10 {
           description "Changed leaf bar-64 default-stmt";
           semver:module-version "1.3.2";
           semver:nbc-change;
    =
     }
then later, a legal change
        revision 2019-03-10 {
           description "Added leaf baz-64";
           semver:module-version "1.3.3";
         }

This is a fo=
rm of an inline deviation-stmt.
The YANG update rules are not changing. =
They are just not being followed.

The NBC info belongs in the revision-stmt, not overloading the ve=
rsion string.
Not every major revision will mean NBC changes anyway.

Andy

=C2=A0
=



__________________________= _____________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000048d2020584dc9cb3-- From nobody Sun Mar 24 13:39:55 2019 Return-Path: <01000169b16e4b59-ef36f4d2-41a1-4695-b06d-e312d90d801d-000000@amazonses.watsen.net> 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 2ACA6120071 for ; Sun, 24 Mar 2019 13:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 mBDvUHofET1k for ; Sun, 24 Mar 2019 13:39:51 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0542C120005 for ; Sun, 24 Mar 2019 13:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553459989; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=cLWbfODe7hwONwUbn/YK9pnL0ig3gidhQ1cfMkDCFLo=; b=dzT9FMm4OMCr1KWDDTLZ3+5+QV6Sx5Zo4DQrvwnkDgDUxir5697X0YVcHl/nZLaZ VAOiciwDQi0dtwJ32NgmqTUcVYz1y0633z6+CkS7/eW18QtHbrihKPB8KXeoBqWNfnm PN7vUAdjU3C9BnLZE4gM3JhW15TpzKlg/N8/UN+4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: <010001694adcb594-c4949ed4-2ea4-403c-928f-cd2da66ddfd8-000000@email.amazonses.com> Date: Sun, 24 Mar 2019 20:39:49 +0000 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <01000169b16e4b59-ef36f4d2-41a1-4695-b06d-e312d90d801d-000000@email.amazonses.com> References: <0100016949d802d6-ccf713c5-df75-4f24-b479-4bc94b4138ec-000000@email.amazonses.com> <20190304.193540.1020759172873811211.mbj@tail-f.com> <010001694a9bd6f5-87034dff-c252-4e16-8028-f38e9184d2da-000000@email.amazonses.com> <20190304.225223.810570484724895529.mbj@tail-f.com> <010001694adcb594-c4949ed4-2ea4-403c-928f-cd2da66ddfd8-000000@email.amazonses.com> To: Martin Bjorklund X-SES-Outgoing: 2019.03.24-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] artwork folding: dual support modes? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:39:53 -0000 I=E2=80=99ve been thinking about Martin=E2=80=99s desire for the pretty sing= le backslash approach. I think the discussion should be about the probabili= ty of collisions (I.e., files that cannot be folded due to false positives) Assuming 95 printable characters (127-32) plus =E2=80=98\n=E2=80=99, a total= of 96 characters, the unconditioned probability of a given of an n-characte= r string occurring on a line is (1/96)^n. Here are the 3 options being discussed (please check my math!) 1. The pretty double backslash approach in the current draft - folds only on any column and supports indents Scan the text content to ensure no existing lines already end with a backsla= sh ('\') character when the subsequent line starts with a backslash ('\') ch= aracter as the first non-space (' ') character. P(=E2=80=9C\\\n[ ]*\\=E2=80=9D) =3D sum of (1/96)^n for 3<=3Dn<69 =3D =E2=88=91((1=C3=B796)^x; x; 3; 69) =3D 0.0000011421783625730994152046783625731 ~=3D 1 / 1,000,000 2. The not pretty single backslash approach in I-D -06 - folds only on max-column with no support for indents Scan the artwork to ensure no existing lines already end with a '\' characte= r on the desired maximum column. P(=E2=80=9C.\{$maxcol-1\}\\\n=E2=80=9D) =3D P( (not =E2=80=98\n=E2=80=99 for $maxcol-1 chars), followed by a =E2= =80=9C\\\n=E2=80=9D) =3D ((1=E2=88=92(1=C3=B796))^68)=C3=97(1=C3=B796)^2 =3D 0.0000532376463396105463857306859461496 ~=3D 1 / 20,000 3. Martin=E2=80=99s pretty single backslash approach - folds only on any column and supports indents Scan the artwork to ensure no existing lines already end with a '\' characte= r OR that a white space character appears on the max column. P(=E2=80=9C\\\n=E2=80=9D) + P(=E2=80=9C.\{$maxcol\} =E2=80=9C) =3D (1/96)^2 + ((1=E2=88=92(1=C3=B796))^69)=C3=97(1=C3=B796) =3D 0.00516608334670744635108885960932866 ~=3D 1 / 200 Note that each of these assume a long-line. The number of long lines in a g= iven piece of text is small, 1/100? Thusly, while option #3 is two orders o= f magnitude more like than option #2, it may only be detected 1 / 200,000 te= xt samples, that are themselves detected as needing to be folded (1/5?), so m= aybe one in a million text samples? Maybe an automated folding algorithm could try #3 and, only if detecting the= precondition, switch to option #1? Kent // contributor=20 From nobody Sun Mar 24 13:44:50 2019 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 AF17D120145 for ; Sun, 24 Mar 2019 13:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=RVebvyp5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VTz/C0gm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V94LjvExuBXq for ; Sun, 24 Mar 2019 13:44:39 -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 71871120117 for ; Sun, 24 Mar 2019 13:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55481; q=dns/txt; s=iport; t=1553460278; x=1554669878; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VGEDV6vhXX02GH1g5W94PpG6apRv8yAoNOeXIWEwa7w=; b=RVebvyp5/FNS5ZSVno30jw7gibFcf49vAhO7ZQU62oYUqc61GRutKrpc DtjkWmQP1DmHuVkLR6wdNU0Ar4dU85SEEL9LxX2AQWjkkB+rIS5qtYixA S0qUgqj3oZKE/M28qfVLXRd9TKf2CXgKg2zaTvjhkXV2DKyF9aoYhlGKM Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AtgJq5BB4zCUiWec+wLG7UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIfXpYigxAexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAc65dc/4cNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgQ4vJCwDaHQECyeDTkCDRwOPKIJXlwy?= =?us-ascii?q?BLhSBEANQBA0BARgBCgmBS4IvRgIXhGUiNgcNAQEDAQEJAQMCbRwMhUoBAQE?= =?us-ascii?q?EAQEKDgkEGQEBLAsBCwQCAQYCEQMBAQEBIAEGAwICAiULFAkIAgQBDQUbgwc?= =?us-ascii?q?BgRFMAxUBDpFLkF8CihRxfDOCeAEBBYExAQMCgRCCNRiCDAMFgS8BizEXgX+?= =?us-ascii?q?BOB+BTn4+gmEBAQIBgSsBCwcBCQktDQmCVDGCJootDjMCggOEHx6HKIthYAk?= =?us-ascii?q?Ch2GECodMGYIChXyDTIg0ixyBF4RujSUCBAIEBQIOAQEFgVQJKCg9cXAVOyo?= =?us-ascii?q?BgkGCCgwXg0uFFIU/coEojBgCDReCJwEB?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="539046754" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 20:44:36 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2OKiaSY015016 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 20:44:36 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 15:44:35 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 16:44:34 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 24 Mar 2019 16:44:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VGEDV6vhXX02GH1g5W94PpG6apRv8yAoNOeXIWEwa7w=; b=VTz/C0gmCUXkBrf0ZqCqk7QxddV6+Q4Cz6eA83laoY5PB5kLaME6NaM/tESCVd1OknLJ69E4gjK31CIby225CGy+GWLwPrJp12gDmAApRAZ+yqNeSHscbi3eqvWmou+NarLn08j/xR7vAoOVVPR0NCPZQdq7Lyh2jd9ygFgk2fY= Received: from MWHPR11MB0031.namprd11.prod.outlook.com (10.164.204.27) by MWHPR11MB1824.namprd11.prod.outlook.com (10.175.53.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Sun, 24 Mar 2019 20:44:32 +0000 Received: from MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b]) by MWHPR11MB0031.namprd11.prod.outlook.com ([fe80::584f:10a3:3b55:67b%6]) with mapi id 15.20.1730.017; Sun, 24 Mar 2019 20:44:32 +0000 From: "Charles Eckel (eckelcu)" To: "Rob Wilton (rwilton)" , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU2dp7BkVfmO3v+kqzQQ7hBIUHi6YTGKGAgAAX0wCAACDbgIABIkcAgAbuO4A= Date: Sun, 24 Mar 2019 20:44:32 +0000 Message-ID: <5C97E942-6E9A-4AD0-B3CF-A2B60BBE4B48@cisco.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> In-Reply-To: <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=eckelcu@cisco.com; x-originating-ip: [2001:420:c0c0:1001::37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed35abf2-cdf6-4b9d-27ee-08d6b09984b0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MWHPR11MB1824; x-ms-traffictypediagnostic: MWHPR11MB1824: x-ms-exchange-purlcount: 4 x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-antispam-prvs: x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(376002)(366004)(396003)(39860400002)(52314003)(51914003)(51444003)(13464003)(199004)(189003)(105586002)(71190400001)(71200400001)(33656002)(53936002)(6486002)(6436002)(102836004)(6116002)(316002)(186003)(110136005)(93886005)(36756003)(53546011)(606006)(30864003)(83716004)(106356001)(46003)(2906002)(76176011)(81166006)(229853002)(478600001)(8676002)(966005)(4326008)(81156014)(476003)(68736007)(97736004)(82746002)(58126008)(446003)(11346002)(99286004)(86362001)(6506007)(236005)(6512007)(25786009)(7736002)(486006)(54896002)(6306002)(5660300002)(14444005)(8936002)(256004)(2616005)(14454004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1824; H:MWHPR11MB0031.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4G8Dq/tfB5pw1H7kcWyzBJUEMs5tbifQ8dhObS2rRLg/v9Gce8op3arzL7JqIPiqI9etXptHs2Iitb4jrvICNHmf+Zd6QcCdQy8QM6UqZ530B3AeWJnjlwGCUKEYx43ndObGsXJ9tkr5bJglZN3mPbRzgg/S6uAR4MUFYM6OeAwYApCqWnDUd6Gbh5LF8qw6yysWLvoIkQNI0e/W7Dc4Tghb7awsTUJ3w+jZMiPwcUeVZENsf56y5ccuxSXzm/Z7aybb6Y2vGKLW36shHyXgPaVbs6kONit8zUcRrz9rAQWTO/e8oV6a0PaIpHVE1Vq1qv+fVCMC/dsJV+nBeY8KwYD7YIm5loy4YgN5gapGD9aB35aENw73DDWGizVXdCzBSKz/37U+MBfE+RKcTnd07pQQzaZ0CBoTY+443TdF3fc= Content-Type: multipart/alternative; boundary="_000_5C97E9426E9A4AD0B3CFA2B60BBE4B48ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ed35abf2-cdf6-4b9d-27ee-08d6b09984b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2019 20:44:32.0354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1824 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:44:49 -0000 --_000_5C97E9426E9A4AD0B3CFA2B60BBE4B48ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUsIG1hcmtlZCB3aXRoIFtjdWVdLg0KDQpGcm9tOiBuZXRtb2QgPG5l dG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIlJvYiBXaWx0b24gKHJ3aWx0b24p IiA8cndpbHRvbkBjaXNjby5jb20+DQpEYXRlOiBXZWRuZXNkYXksIE1hcmNoIDIwLCAyMDE5IGF0 IDEyOjU1IFBNDQpUbzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpDYzogIm5l dG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBh ZG9wdGlvbiBwb2xsIGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQpIaSBBbmR5LA0KDQpU aGFua3MgZm9yIHRoZSBjb21tZW50cy4NCg0KMS4gUmVndWxhciBTZW12ZXIgMi4wLjAgKGFzIHBl ciBzZW12ZXIub3JnKSBhbGxvd3Mgc29tZSBicmFuY2hpbmcuICBJLmUuIHlvdSBjYW4gY3JlYXRl IHZlcnNpb24gMi4wLjAgYmFzZWQgb2YgdmVyc2lvbiAxLjEuMCwgYW5kIHRoZW4gc3Vic2VxdWVu dGx5IGNyZWF0ZSB2ZXJzaW9uIDEuMi4wIGJhc2VkIG9mIDEuMS4wLiAgU28gc3RydWN0dXJlIHdp c2UgdGhpcyB3b3VsZCBsb2dpY2FsbHkgbG9vayBsaWtlOg0KDQogICAxLjAuMA0KICAgICAgfCBc DQogICAgICB8ICAgMS4xLjAg4oCTIDEuMi4wIC0g4oCmDQogICAgICB8DQogICAyLjAuMA0KICAg ICAgfA0KDQpJIGFsc28gcmFpc2VkIGh0dHBzOi8vZ2l0aHViLmNvbS9zZW12ZXIvc2VtdmVyL2lz c3Vlcy81MDQgIG9uIHRoZSBzZW12ZXIgMi4wLjAgZ2l0aHViIHRvIGNvbmZpcm0gdGhhdCBteSBp bnRlcnByZXRhdGlvbiBpcyBjb3JyZWN0LCBhbmQgbm8gb25lIGhhcyBkaXNwdXRlZCBpdCB5ZXQu DQoNCg0KMi4gVmVuZG9yIHNvZnR3YXJlIHJlbGVhc2VzIGNhbiBoYXZlIGEgdmVyeSBsb25nIHN1 cHBvcnQgdGltZSAoZS5nLiBlYXNpbHkgNSsgeWVhcnMpLCB3aXRoIGFuIGV4cGVjdGF0aW9uIHRo YXQgYnVncyBnZXQgZml4ZWQuICBSZXF1aXJpbmcgdGhhdCBjdXN0b21lcnMgdXBncmFkZSB0aGVp ciBzb2Z0d2FyZSAob3IgcGVyaGFwcyBoYXJkd2FyZSkgdG8gdGhlIHZlcnkgbGF0ZXN0IHNvZnR3 YXJlIHZlcnNpb24gdG8gcGljayB1cCBhIHNtYWxsIGJ1ZyBmaXggaXMgbm90IHJlYWxpc3RpYy4g IFRoaXMgaXMgcHJpbWFyaWx5IHdoeSBJIHRoaW5rIHRoYXQgdGhlIOKAmG3igJkgYW5kIOKAmE3i gJkgYXJlIHNvIGltcG9ydGFudC4gIFRoZXkgYWxsb3cgZm9yIGJ1ZyBmaXhlcyBpbiBhIHdheSB0 aGF0IFNlbXZlciAyLjAuMCBzaW1wbHkgZG9lcyBub3QuDQoNClNlbXZlciAyLjAuMCBvbmx5IGFs bG93cyBmb3IgYnVnZml4ZXMgaW4gdGhlIGltcGxlbWVudGF0aW9uIChieSB1cGRhdGluZyB0aGUg cGF0Y2ggdmVyc2lvbiBudW1iZXIpLCBidXQgaGFzIHRoZSBleHBlY3RhdGlvbiB0aGF0IHRoZXJl IGFyZSAqbmV2ZXIqIGFueSBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlcyBpbiB0aGUg QVBJLCBub3QgZXZlbiB0byBmaXggYSBidWcsIGV4Y2VwdCBhdCB0aGUgdGlwIG9mIHRoZSBkZXZl bG9wbWVudCB0cmVlLg0KDQpJbiBzaG9ydCwgSSB0aGluayB0aGF0IHZhbmlsbGEgU2VtdmVyIDIu MC4wIGlzIGEgZ29vZCBmaXQgZm9yIG9wZW4gc291cmNlIHByb2plY3RzIHdoZXJlIHlvdSBjYW4g anVzdCB0ZWxsIHRoZSBjbGllbnQgdG8gdXBkYXRlIHRvIHRoZSBsYXRlc3QgdmVyc2lvbiB0byBw aWNrIHVwIHRoZSBmaXguICBJIGRvbuKAmXQgdGhpbmsgdGhhdCBTZW12ZXIgMi4wLjAgaXMgc28g d2VsbCBhbGlnbmVkIHRvIEFQSXMgdGhhdCBhcmUgcmVxdWlyZWQgdG8gYmUgbWFpbnRhaW5lZCBm b3IgbG9uZyBwZXJpb2RzIG9mIHRpbWUuDQpbY3VlXQ0KTGV0IG1lIHN0YXJ0IGJ5IGFkbWl0dGlu ZyB0aGF0IEkgYW0gYSBZQU5HIG5lb3BoeXRlLCBzbyB0YWtlIHRoaXMgYXMgYSBxdWVzdGlvbiBy YXRoZXIgdGhhbiBhIHN1Z2dlc3Rpb24sIGJ1dCB3b3VsZCBpdCBtYWtlIGFueSBzZW5zZSB0byBh cHBseSB0aGUgc2VtYW50aWNzIG9mIFNlbXZlciAyLjAuMCBmb3Igc3RhbmRhcmQgbW9kZWxzIGFu ZCBhbGxvdyB0aGUgdXNlIG9mIHNvbWV0aGluZyBtb3JlIGV4cHJlc3NpdmUsIHN1Y2ggYXMgdGhh dCBwcm9wb3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0 bW9kLXlhbmctdmVyc2lvbmluZy1yZXFzLTAyLCBmb3IgbmF0aXZlIG1vZGVscz8gTXkgZ3Vlc3Mg aXMgdGhhdCBzdGFuZGFyZCB2cy4gbmF0aXZlIG1vZGVsIGlzIGEgZGlzdGluY3Rpb24gdGhhdCB3 ZSBkaXNjdXNzIGFuZCB0aGF0IGlzIGV2aWRlbnQgYnkgWUFORyBtb2RlbCBuYW1lOyBob3dldmVy LCBhIFlBTkcgY29tcGlsZXIgaGFzIG5vIGtub3dsZWRnZSBvZiB0aGlzIGFuZCBtYWtlcyBubyBk aXN0aW5jdGlvbi4gTmV2ZXJ0aGVsZXNzLCBJIHRob3VnaHQgSeKAmWQgdGhyb3cgaXQgb3V0IHRo ZXJlLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoNCg0KVGhlIGFsdGVybmF0aXZlIHRoYXQgUm9iIFNo YWtpciBtZW50aW9uZWQgYXQgSUVURiAxMDMgaW4gdGhlIGNvbnRleHQgb2YgT3BlbkNvbmZpZywg d2hpY2ggdXNlcyBzdHJpY3QgU2VtdmVyIDIuMC4wLCBpcyB0byBoYW5kbGUgdGhlc2UgYnVnIGZp eGVzIHVzaW5nIGRldmlhdGlvbnMuICBCdXQgaXQgc2VlbXMgdG8gYmUgc2lnbmlmaWNhbnRseSBt b3JlIGNvbXBsZXggdG8gbWFuYWdlIGJ1ZyBmaXhlcyB1c2luZyBleHRyYSBkZXZpYXRpb24gbW9k dWxlcyByYXRoZXIgdGhhbiBhbGxvd2luZyB0aGUg4oCYbeKAmSB8IOKAmE3igJkgbW9kaWZpZXJz LiAgVmVyc2lvbmluZyB3b3VsZCBubyBsb25nZXIgbGltaXRlZCB0byBhIG1vZHVsZSB2ZXJzaW9u IG51bWJlciwgYnV0IHJlcXVpcmUga25vd2xlZGdlIG9mIHRoZSBtb2R1bGUgdmVyc2lvbiBhbmQg c2V0IG9mIGRldmlhdGlvbnMgdGhhdCBhcmUgYXBwbGllZCB0byBpdC4gIEkgd291bGQgcmF0aGVy IGRldmlhdGlvbnMgYXJlIHJlc2VydmVkIHRvIGluZGljYXRlIHdoZXRoZXIgYW4gaW1wbGVtZW50 YXRpb24gZG9lc27igJl0IG1hdGNoIHRoZSBtb2R1bGUgc3BlY2lmaWNhdGlvbiByYXRoZXIgdGhh biB1c2UgdGhlbSBhcyBhIHdheSBvZiBmaXhpbmcgYnVncyBpbiB0aGUgc3BlY2lmaWNhdGlvbiBp dHNlbGYuDQoNCg0KMy4gSSBhZ3JlZSB0aGF0IHRoZSB1c2Ugb2YgU2VtdmVyICsgcGFja2FnZXMg KyB2ZXJzaW9uIHNlbGVjdGlvbiBkb2VzIG5vdCByZWR1Y2UgdGhlIG92ZXJhbGwgbnVtYmVyIG9m IHBhdGhzIHRvIGEgY29uZmlndXJhYmxlIHByb3BlcnR5LCBidXQgaXQgZG9lcyBlbnN1cmUgdGhh dCB0aGVyZSBpcyBvbmx5IGEgc2luZ2xlIHBhdGggdG8gYSBjb25maWd1cmFibGUgcHJvcGVydHkg d2l0aGluIGEgWUFORyBkYXRhc3RvcmUgc2NoZW1hLiAgIFNvIHdoaWNoZXZlciB2ZXJzaW9uIGVh Y2ggY2xpZW50IGlzIHVzaW5nLCB0aGV5IG9ubHkgdXNlIGEgc2luZ2xlIHBhdGguICBJLmUuIG1p cnJvcmluZyB0aGUgd2F5IHRoYXQgYSBjbGFzc2ljIHByb2dyYW1taW5nIEFQSSBtaWdodCBiZSB2 ZXJzaW9uZWQuDQoNClNlcnZlcnMgdGhhdCB3aXNoIHRvIHN1cHBvcnQgdGhpcyB3b3VsZCBoYXZl IHRvIG1hcCB0aGUgZGF0YSBiZXR3ZWVuIGRpZmZlcmVudCBZQU5HIGRhdGFzdG9yZSBzY2hlbWEg dmVyc2lvbnMuICBOb3QgYWxsIG1hcHBpbmdzIGFyZSBwb3NzaWJsZSwgYnV0IGF0IGxlYXN0IGFu eSBjYXNlcyB3aGVyZSBpdCBpcyBub3QgcG9zc2libGUgY2FuIGJlIGRldGVjdGVkIGFuZCByZXBv cnRlZCB0byB0aGUgY2xpZW50IHZpYSBhbiBvdXQgb2YgYmFuZCBtZWNoYW5pc20uDQoNCklmIHRo ZSBtb2R1bGUgY29udGVudCBjaGFuZ2VzIHNpZ25pZmljYW50bHkgYmV0d2VlbiBtb2R1bGUgdmVy c2lvbnMgdGhhdCBtYXBwaW5nIHdpbGwgYmUgbXVjaCBoYXJkZXIgdGhhbiBpZiB0aGUgY2hhbmdl cyBhcmUgbWluaW1hbCBvciBiYWNrd2FyZHMgY29tcGF0aWJsZS4gIFNvIHRoZXJlIGlzIHN0aWxs IGEgc3Ryb25nIGluY2VudGl2ZSBmb3IgbW9kZWwgd3JpdGVycyB0byBtaW5pbWl6ZSBjaHVybiB0 byB0aGUgWUFORyBtb2RlbHMuDQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IEFuZHkgQmllcm1h biA8YW5keUB5dW1hd29ya3MuY29tPg0KU2VudDogMTkgTWFyY2ggMjAxOSAxODozNQ0KVG86IFJv YiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4NCkNjOiBNYXJ0aW4gQmpvcmts dW5kIDxtYmpAdGFpbC1mLmNvbT47IGtlbnQraWV0ZkB3YXRzZW4ubmV0OyBuZXRtb2RAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhZG9wdGlvbiBwb2xsIGZvciB5YW5nLXZlcnNpb25p bmctcmVxcy0wMg0KDQoNCg0KT24gVHVlLCBNYXIgMTksIDIwMTkgYXQgOTozOCBBTSBSb2IgV2ls dG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29t Pj4gd3JvdGU6DQpIaSBNYXJ0aW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyBhbmQgY29tbWVu dHMuDQoNCkEgY291cGxlIG9mIHBvaW50czoNCg0KMSkgTG90cyBvZiBtb2RlbHMgb3V0c2lkZSB0 aG9zZSBwdWJsaXNoZWQgaW4gU0RPcyBhcmUgYWxyZWFkeSBub3QgZm9sbG93aW5nIHRoZSBSRkMg Nzk1MCByZXZpc2lvbiBydWxlcy4gIEkgdGhpbmsgdGhhdCBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBh IHZlcnNpb25pbmcgc2NoZW1lIHRoYXQgcmVmbGVjdHMgaG93IFlBTkcgbW9kZWxzIGFyZSBhY3R1 YWxseSBldm9sdmluZyByYXRoZXIgdGhhbiBoYXZlIGFsbCB2ZW5kb3IgYW5kIE9DIFlBTkcgbW9k dWxlcyBlaXRoZXIganVzdCBpZ25vcmluZyB0aGUgcnVsZXMsIG9yIHVzaW5nIGNsZXZlciB0cmlj a3MgdGhhdCBzdHJpY3RseSBjb25mb3JtIHdpdGggdGhlIHJ1bGVzIGJ1dCBnbyBhZ2FpbnN0IHRo ZSBzcGlyaXQgb2YgdGhlbSAoZS5nLiBqdXN0IHB1Ymxpc2ggYW4gZW50aXJlbHkgbmV3IHNldCBv ZiBZQU5HIG1vZHVsZXMgZm9yIGVhY2ggcmVsZWFzZSkuICBBbHNvIG5vdGluZyB0aGF0IGhhdmlu ZyBhIHNjaGVtZSB0aGF0IGFsbG93cyBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlcyBk b2VzIG5vdCByZXF1aXJlIHRoYXQgZXZlcnlvbmUgdXNlcyB0aGVtIC0gSUVURiBjb3VsZCBjb250 aW51ZSB0byBhbHdheXMgcHVibGlzaCBiYWNrd2FyZHMgY29tcGF0aWJsZSBtb2R1bGVzLiAgVGhl IG9idmlvdXMgYWx0ZXJuYXRpdmUgaGVyZSBpcyB0aGF0IGVhY2ggdmVuZG9yIGNvbWVzIHVwIHdp dGggdGhlaXIgb3duIHZlcnNpb25pbmcgZXh0ZW5zaW9uIGFuZCBpZ25vcmVzIHRoZSBSRkMgNzk1 MCBzZWN0aW9uIDExIHJ1bGVzIGFueXdheSwgYnV0IEknbSBub3Qgc3VyZSBob3cgdGhhdCByZWFs bHkgaGVscHMgY2xpZW50PC0+c2VydmVyIGludGVyb3AuDQoNCg0KSSBkbyBub3Qgc3VwcG9ydCBi cmFuY2hpbmcgZm9yIFlBTkcgbW9kZWxzIHNvIEkgZG8gbm90IHN1cHBvcnRlZCBtb2RpZmllZCBT RU1WRVIuDQpBZGRpbmcgYSBzcGVjaWFsIGNoYXJhY3RlciB0byB0aGUgdmVyc2lvbiBzdHJpbmcg ZG9lc24ndCBoZWxwIHRoZSBkZXBsb3llZCBjbGllbnQgY29kZQ0KdGhhdCBzdG9wcyB3b3JraW5n IHdoZW4gdGhlIHNlcnZlciBjb2RlIGlzIHVwZ3JhZGVkLiAgVGhpcyBpcyBhIHF1YWxpdHkgaXNz dWUgdGhhdA0KZWFjaCBvcmdhbml6YXRpb24gaGFzIHRvIGRlYWwgd2l0aCB0aGUgYmVzdCB0aGV5 IGNhbi4NCg0KSSBkbyBub3Qgb2JqZWN0IHRvIHRoZSBhZGRpdGlvbiBvZiBhIFNFTVZFUiBmaWVs ZCB0byBhIFlBTkcgbW9kdWxlIGJlY2F1c2UgdGhlc2UgdmVyc2lvbg0Kc3RyaW5ncyBhcmUgZmFt aWxpYXIgdG8gdXNlcnMuICBJdCBpcyBwb3NzaWJsZSB0byBleHByZXNzIGltcG9ydCByYW5nZXMg c3VjaCBhcyAxLjIuKiAoYW55IDEuMi54IHJlbGVhc2UpDQp3aGljaCBhcmUgbm90IHBvc3NpYmxl IHdpdGggZGF0ZSBzdHJpbmdzLg0KDQoNCjIpIEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhlIFJG QyA3OTUwIGFwcHJvYWNoIG9mICJkZXByZWNhdGUgYSBidWdneSBub2RlLCBhbmQgcmVwbGFjZSB3 aXRoIGEgd29ya2luZyBub2RlIiByZWFsbHkgd29ya3MgaW4gcHJhY3RpY2UsIHBhcnRpY3VsYXJs eSBmb3IgY29uZmlndXJhdGlvbiBkYXRhIG5vZGVzIHdoZXJlIHlvdSBoYXZlIHR3byBjbGllbnRz IGludGVyYWN0aW5nIHdpdGggYSBzZXJ2ZXIsIG9uZSBpbnRlcmFjdGluZyB3aXRoIHRoZSBvbGQg cGF0aCwgYW5kIGFub3RoZXIgdXNpbmcgdGhlIG5ldyBwYXRoLiAgUGVyaGFwcyB0aGVyZSBpcyBh IHJvYnVzdCBzY2hlbWUgdGhhdCB3b3JrcyBpbiBhbGwgY2FzZXMsIGJ1dCBpdCBpc24ndCBvYnZp b3VzIHRvIG1lLiAgSGlzdG9yaWNhbGx5LCBmb3IgQ0xJIHdlIGp1c3QgdHJhbnNsYXRlIHRoZSBD TEkgZnJvbSBvbGQgdG8gbmV3IGZvcm1hdCBhbmQgdGhlbiByZXR1cm4gdGhlIG5ldyBmb3JtYXQg d2hlbiB0aGUgcnVubmluZyBjb25maWcgaXMgcmVxdWVzdGVkLiAgQnV0IHRoYXQgd2lsbCBzdGls bCBicmVhayBhbiBvbGQgY2xpZW50IHRoYXQgZG9lc24ndCB1bmRlcnN0YW5kIGhvdyB0byByZWFk IHRoZSBuZXcgQ0xJLCBldmVuIGlmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgdGhlbSB3cml0aW5nIHZp YSB0aGUgb2xkIENMSS4NCg0KU0VNVkVSIGRvZXMgbm90IHJlZHVjZSB0aGUgbnVtYmVyIG9mIHBh dGhzIHRvIHRoZSB1bmRlcmx5aW5nIGNvbmZpZ3VyYXRpb24gb2JqZWN0Lg0KVGhhdCBwcm9ibGVt IGRvZXMgbm90IGNoYW5nZSB3aGV0aGVyIGEgbmV3IFhQYXRoIGFic29sdXRlLXBhdGgtZXhwciBp cyB1c2VkDQpvciB3aGV0aGVyIHRoZSBzYW1lIHBhdGggaXMgb3ZlcmxvYWRlZCB3aXRoIHNlbWFu dGljcyBkZXJpdmVkIGZyb20gYWRkaXRpb25hbCBwcm90b2NvbCBwYXJhbWV0ZXJzDQooZS5nLiwg dmVyc2lvbmluZyBvZiBlYWNoIGRhdGEgbm9kZSkuIEkgcHJlZmVyIHRoZSBleGlzdGluZyBYUGF0 aCBzb2x1dGlvbiBiZWNhdXNlIGl0IGlzIGV4cGxpY2l0DQpzbyB0aGUgWUFORyByZWFkZXIgY2Fu IGVhc2lseSBzZWUgdGhlIG11bHRpcGxlIHBhdGhzLCBhbmQgbm8gbmV3IHByb3RvY29sIHdvcmsg bmVlZGVkIHRvIHN1cHBvcnQgaXQuDQpJZiB0aGVyZSBpcyBhbiBOQkMgY2hhbmdlIHRvIGFuIG9i amVjdCB0aGVuIGFsbCBYUGF0aCBhbmQgbGVhZnJlZiByZWZlcmVuY2VzIHRvIGl0IHdpbGwgcHJv YmFibHkgYnJlYWsuDQpUaGF0IHNlZW1zIGxpa2UgYSBoYXJkZXIgcHJvYmxlbSB0byBzb2x2ZSB0 aGFuIHRoZSBvcmlnaW5hbCBwYXRoIGR1cGxpY2F0aW9uIHByb2JsZW0uDQoNCg0KRXZlbiBpZiB0 aGVyZSBpcyBhIHdvcmthYmxlIHNvbHV0aW9uIGZvciB0aGlzIHNpbXBsZSBjYXNlLCBJIHN1c3Bl Y3QgdGhhdCB0aGVyZSBhcmUgbWFueSBzbGlnaHRseSBtb3JlIGNvbXBsaWNhdGVkIGNhc2VzIHRo YXQgZG9uJ3Qgd29yayAoZS5nLiByZWtleWluZyBhIGxpc3QsIGNoYW5naW5nIGRlZmF1bHRzLCBp bmNvbXBhdGlibGUgdHlwZXMpLg0KDQpJbiBzaG9ydCwgSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBw cmVtaXNlIHRoYXQgdGhlIGN1cnJlbnQgWUFORyB2ZXJzaW9uaW5nIHNjaGVtYSB1c2luZyByZXZp c2lvbiBkYXRlcyBpcyB3b3JraW5nIGp1c3QgZmluZSwgYW5kIG5vIGNoYW5nZXMgYXJlIG5lZWRl ZC4NCg0KVGhhbmtzLA0KUm9iDQoNCkFuZHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWFydGluIEJqb3JrbHVuZA0KU2VudDogMTkg TWFyY2ggMjAxOSAxNToxMg0KVG86IGtlbnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50JTJC aWV0ZkB3YXRzZW4ubmV0Pg0KQ2M6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGFkb3B0aW9uIHBvbGwgZm9yIHlhbmctdmVyc2lv bmluZy1yZXFzLTAyDQoNCkhpLA0KDQpJIGhhdmUgcmVhZCB0aGlzIGRvY3VtZW50LCBhbmQgSSBk byBub3QgdGhpbmsgaXQgc2hvdWxkIGJlIGFkb3B0ZWQuDQoNCkkgb2JqZWN0IHRvIHRoZSBpZGVh IHRoYXQgd2Ugc2hvdWxkIGFsbG93IG5vbi1iYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2VzIHRv IHB1Ymxpc2hlZCBZQU5HIG1vZHVsZXMuDQoNClRoZSBkcmFmdCBtb3RpdmF0ZXMgdGhpcyBpZGVh IHdpdGg6DQoNCiAgIHdlIG11c3QgcmVjb2duaXplIHRoYXQgbWFueSBZQU5HDQogICBtb2R1bGVz IGFyZSBhY3R1YWxseSBnZW5lcmF0ZWQgWUFORyBtb2R1bGVzIChmb3IgZXhhbXBsZSwgZnJvbQ0K ICAgaW50ZXJuYWwgZGF0YWJhc2VzKQ0KDQpJIGRvIG5vdCBhZ3JlZSB0aGF0IHdlIHNob3VsZCBj aGFuZ2Ugd2hhdCB3ZSBhbGxvdyBpbiBwdWJsaXNoZWQgbW9kdWxlcyBiL2Mgb2YgdGhpcy4NCg0K SXQgYWxzbyBtb3RpdmF0ZXMgdGhpcyBpZGVhIHdpdGg6DQoNCiAgIFRoZSBwb2ludHMgbWFkZSBh Ym92ZSBsZWFkIHRvIHRoZSBsb2dpY2FsIGNvbmNsdXNpb24gdGhhdCB0aGUNCiAgIHN0YW5kYXJk aXplZCBZQU5HIG1vZHVsZXMgaGF2ZSB0byBiZSBwZXJmZWN0IG9uIGRheSBvbmUgKGF0IGxlYXN0 IHRoZQ0KICAgc3RydWN0dXJlIGFuZCBtZWFuaW5nKSwgd2hpY2ggaW4gdHVybiBtaWdodCBleHBs YWluIHdoeSBJRVRGIFlBTkcNCiAgIG1vZHVsZXMgdGFrZSBzbyBsb25nIHRvIHN0YW5kYXJkaXpl Lg0KDQpJIGRpc2FncmVlIHdpdGggdGhpcy4gIEZpcnN0IG9mIGFsbCwgd2UgaGF2ZSBhbHJlYWR5 IHB1Ymxpc2hlZCByZXZpc2lvbiB0d28gb2Ygc2V2ZXJhbCBZQU5HIG1vZHVsZXMgKGlldGYtaW5l dC10eXBlcywgaWV0Zi15YW5nLXR5cGUsIGlldGYtaW50ZXJmYWNlcywgaWV0Zi1pcCwgaWV0Zi1y b3V0aW5nLCAuLi4pLCBzbyB0aGUgc3RhdGVtZW50IHRoYXQgInN0YW5kYXJkaXplZCBZQU5HIG1v ZHVsZXMgaGF2ZSB0byBiZSBwZXJmZWN0IG9uIGRheSBvbmUiIGlzIHNpbXBseSBub3QgdHJ1ZS4N Cg0KU2Vjb25kLCBJIGRvbid0IHRoaW5rIHRoZSB1cGdyYWRlIHJ1bGVzIGFyZSB0aGUgcmVhc29u IGl0IHRha2VzIGEgbG9uZyB0aW1lIHRvIHN0YW5kYXJkaXplIElFVEYgbW9kZWxzIChJIHRoaW5r IGl0IGhhcyB0byBkbyB3aXRoIHRoZSBwcm9jZXNzIGl0c2VsZiwgaW5jbHVkaW5nIHRoZSBmYWN0 IHRoYXQgbW9kZWxzIGdldCByZXZpZXdzIGZyb20gbWFueSBkaWZmZXJlbnQgcGVvcGxlIHdpdGgg ZGlmZmVyZW50IGJhY2tncm91bmQuKSAgW0JUVywgaXMgaXQgdHJ1ZSB0aGF0IGRyYWZ0cyB3aXRo IFlBTkcgbW9kZWxzIHRha2UgbG9uZ2VyIHRpbWUgZnJvbSB3ZyAtMDAgdG8gcHVibGlzaGVkIFJG QyB0aGFuIG90aGVyIGRyYWZ0cz9dDQoNCg0KVGhpcyBzYWlkLCBJIHRoaW5rIHRoZXJlIGFyZSBz b21lIGltcG9ydGFudCBwb2ludHMgdGhhdCB0aGUgZHJhZnQgcmFpc2VzLCBhbmQgdGhhdCBJIHRo aW5rIHdlIHNob3VsZCBjb250aW51ZSB0byB3b3JrIG9uOyBzcGVjaWZpY2FsbHkgMi4zLCAyLjUs IDIuNiwgMi43LiAgQnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVzZSBhcmVhcyByZXF1aXJlIGNo YW5nZXMgdG8gdGhlIHZlcnNpb25pbmcgc2NoZW1lLCBhbmQgSSB0aGluayBpdCBpcyBhIG1pc3Rh a2UgdG8gaW5jbHVkZSB0aGVzZSBhcmVhcyBpbiB0aGlzIGRyYWZ0Lg0KDQpTb21lIGNvbW1lbnRz IG9uIHNlY3Rpb24gNCwgVGhlIFByb2JsZW0gU3RhdGVtZW50Og0KDQogICBvICBBbnkgbm9uLWJh Y2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZSBvZiBhIGRlZmluaXRpb24gcmVxdWlyZXMNCiAgICAg IGVpdGhlciBhIG5ldyBtb2R1bGUgbmFtZSBvciBhIG5ldyBwYXRoLiAgVGhpcyBoYXMgYmVlbiBm b3VuZA0KICAgICAgY29zdGx5IHRvIHN1cHBvcnQgaW4gaW1wbGVtZW50YXRpb25zLCBpbiBwYXJ0 aWN1bGFyIG9uIHRoZSBjbGllbnQNCiAgICAgIHNpZGUuDQoNClllcyBJIGFncmVlIHRoZXJlIGlz IGEgY29zdCBhc3NvY2lhdGVkIHdpdGggdGhpcy4gIEJ1dCBJIGhhdmUgY29tZSBhY3Jvc3MgdmVu ZG9yIG1vZHVsZXMgdGhhdCBtYWtlIE5CQyBjaGFuZ2VzIHcvbyBpbnRyb2R1Y2luZyBhIG5ldyBw YXRoLCBhbmQgdGhpcyBpcyBhbHNvIGNvc3RseSB0byBoYW5kbGUuDQoNCiAgIG8gIFNpbmNlIG5v bi1iYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFuZ2VzIHJlcXVpcmUgZWl0aGVyIGEgbmV3IG1vZHVs ZQ0KICAgICAgbmFtZSBvciBhIG5ldyBwYXRoLCBzdWNoIGNoYW5nZXMgd2lsbCBpbXBhY3Qgb3Ro ZXIgbW9kdWxlcyB0aGF0DQogICAgICBpbXBvcnQgZGVmaW5pdGlvbnMuICBJbiBmYWN0LCB3aXRo IHRoZSBjdXJyZW50IG1vZHVsZSB2ZXJzaW9uaW5nDQogICAgICBzY2hlbWUgb3RoZXIgbW9kdWxl cyBoYXZlIHRvIG9wdC1pbiBpbiBvcmRlciB0byB1c2UgdGhlIG5ldw0KICAgICAgdmVyc2lvbi4g IFRoaXMgZXNzZW50aWFsbHkgbGVhZHMgdG8gYSByaXBwbGUgZWZmZWN0IHdoZXJlIGEgbm9uLQ0K ICAgICAgYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlIG9mIGEgY29yZSBtb2R1bGUgY2F1c2Vz IHVwZGF0ZXMgb24gYQ0KICAgICAgcG90ZW50aWFsbHkgbGFyZ2UgbnVtYmVyIG9mIGRlcGVuZGVu dCBtb2R1bGVzLg0KDQpUaGlzIGlzIGJ5IGRlc2lnbi4gIFdlIGNhbm5vdCBoYXZlIGEgc2l0dWF0 aW9uIHdoZXJlIGEgbGVnYWwgbW9kaWZpY2F0aW9uIHRvIGEgbW9kdWxlIGxlYWRzIHRvIG90aGVy IG1vZHVsZXMgYmVjb21pbmcgaW52YWxpZC4NCg0KICAgbyAgWUFORyBoYXMgYSBtZWNoYW5pc20g dG8gbWFyayBkZWZpbml0aW9ucyBkZXByZWNhdGVkIGJ1dCBpdCBsZWF2ZXMNCiAgICAgIGl0IG9w ZW4gd2hldGhlciBpbXBsZW1lbnRhdGlvbnMgYXJlIGV4cGVjdGVkIHRvIGltcGxlbWVudA0KICAg ICAgZGVwcmVjYXRlZCBkZWZpbml0aW9ucyBhbmQgdGhlcmUgaXMgbm8gd2F5IChvdGhlciB0aGFu IHRyaWFsIGFuZA0KICAgICAgZXJyb3IpIGZvciBhIGNsaWVudCB0byBmaW5kIG91dCB3aGV0aGVy IGRlcHJlY2F0ZWQgZGVmaW5pdGlvbnMgYXJlDQogICAgICBzdXBwb3J0ZWQgYnkgYSBnaXZlbiBp bXBsZW1lbnRhdGlvbi4NCg0KQXMgSSB3cm90ZSBhYm92ZSwgSSBhZ3JlZSB0aGF0IHRoaXMgaXMg YSBwcm9ibGVtIHRoYXQgc2hvdWxkIGJlIHNvbHZlZC4gIEJ1dCB0aGlzIGlzIG5vdCBhIG1vdGl2 YXRpb24gZm9yIGNoYW5naW5nIFlBTkcgdmVyc2lvbmluZy4NCg0KICAgbyAgWUFORyBkb2VzIG5v dCBoYXZlIGEgcm9idXN0IG1lY2hhbmlzbSB0byBkb2N1bWVudCB3aGljaCBkYXRhDQogICAgICBk ZWZpbml0aW9ucyBoYXZlIGNoYW5nZWQgYW5kIHRvIHByb3ZpZGUgZ3VpZGFuY2UgaG93DQogICAg ICBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGRlYWwgd2l0aCB0aGUgY2hhbmdlLiAgV2hpbGUgaXQg aXMgcG9zc2libGUNCiAgICAgIHRvIGhhdmUgdGhpcyBkZXNjcmliZWQgaW4gZ2VuZXJhbCBkZXNj cmlwdGlvbiBzdGF0ZW1lbnRzLCBoYXZpbmcNCiAgICAgIHRoZXNlIGRldGFpbHMgZW1iZWRkZWQg aW4gZ2VuZXJhbCBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRzIGRvZXMgbm90DQogICAgICBtYWtlIHRo aXMgaW5mb3JtYXRpb24gYWNjZXNzaWJsZSB0byB0b29scy4NCg0KVGhpcyBtaWdodCBhbHNvIGJl IHdvcnRoIGV4cGxvcmluZywgYnV0IHRoaXMgaXMgbm90IGEgbW90aXZhdGlvbiBmb3IgY2hhbmdp bmcgWUFORyB2ZXJzaW9uaW5nLg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KS2VudCBXYXRzZW4gPGtl bnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0Pj4gd3JvdGU6 DQo+IFNlZWluZyBhcyBob3cgd2UgYWxsIG5lZWQgdG8gcmVhZCB0aGlzIGRyYWZ0IGFueXdheXMs IGluIHByZXBhcmF0aW9uIGZvciBvdXIgbWVldGluZyBpbiBQcmFndWUsIGl0IHNlZW1zIGxpa2Ug YSBnb29kIHRpbWUgZm9yIHRoaXMgcG9sbC4gIFRodXNseSwgdGhpcyBlbWFpbCBiZWdpbnMgYSAx LXdlZWsgYWRvcHRpb24gcG9sbCBmb3I6DQo+DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy12ZXJzaW9uaW5nLXJlcXMtMDINCj4gPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy12ZXJzaW9uaW5n LXJlcXMtMA0KPiAyPg0KPg0KPiBQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlv bnMgYmVmb3JlIE1hcmNoIDIwLg0KPg0KPiBOb3RlIHRoYXQgdGhpcyBkcmFmdCBkZWZpbmVzICpy ZXF1aXJlbWVudHMqIGFuZCBpdHMgaW50ZW5kZWQgc3RhdHVzIGlzICJJbmZvcm1hdGlvbmFsLiIg ICBJIGJlbGlldmUgdGhhdCBpdCBpcyBnb29kIGZvciBXR3MgdG8gZm9ybWFsaXplIHJlcXVpcmVt ZW50cywgZXZlbiB0YWtpbmcgc3VjaCBkcmFmdHMgdGhydSBMYXN0IENhbGwsIGluIG9yZGVyIHRv IGVuc3VyZSBjb25zZW5zdXMgb24gdGhlIHJlcXVpcmVtZW50cy4gIFRoaXMgaXMgdGhlICJhZG9w dGlvbiIgY2FsbCwgdG8gYXNjZXJ0YWluIGlmIHRoZSBXRyBhZ3JlZXMgd2l0aCB0aGF0IHN0YXRl bWVudDsgaWYgYWRvcHRlZCwgYSBzZXBhcmF0ZSAibGFzdCBjYWxsIiB3aWxsIGJlIGlzc3VlZCB0 byBlbnN1cmUgdG8gY29ycmVjdG5lc3Mgb2YgdGhlIGRyYWZ0J3MgY29udGVudC4NCj4NCj4gS2Vu dCAoYW5kIExvdSBhbmQgSm9lbCkNCj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg== --_000_5C97E9426E9A4AD0B3CFA2B60BBE4B48ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UGxlYXNlIHNlZSBpbmxpbmUsIG1hcmtlZCB3aXRoIFtjdWVdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7Um9iIFdpbHRvbiAocndpbHRvbikmcXVvdDsgJmx0 O3J3aWx0b25AY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE1hcmNo IDIwLCAyMDE5IGF0IDEyOjU1IFBNPGJyPg0KPGI+VG86IDwvYj5BbmR5IEJpZXJtYW4gJmx0O2Fu ZHlAeXVtYXdvcmtzLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O25ldG1vZEBpZXRmLm9y ZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W25ldG1vZF0gYWRvcHRpb24gcG9sbCBmb3IgeWFuZy12ZXJzaW9uaW5nLXJlcXMtMDI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBB bmR5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBj b21tZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MS4gUmVndWxhciBT ZW12ZXIgMi4wLjAgKGFzIHBlciBzZW12ZXIub3JnKSBhbGxvd3Mgc29tZSBicmFuY2hpbmcuJm5i c3A7IEkuZS4geW91IGNhbiBjcmVhdGUgdmVyc2lvbiAyLjAuMCBiYXNlZCBvZiB2ZXJzaW9uIDEu MS4wLCBhbmQgdGhlbg0KIHN1YnNlcXVlbnRseSBjcmVhdGUgdmVyc2lvbiAxLjIuMCBiYXNlZCBv ZiAxLjEuMC4mbmJzcDsgU28gc3RydWN0dXJlIHdpc2UgdGhpcyB3b3VsZCBsb2dpY2FsbHkgbG9v ayBsaWtlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg MS4wLjA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFwNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNw OyAmbmJzcDsxLjEuMCDigJMgMS4yLjAgLSDigKYNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IDIu MC4wPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JIGFsc28gcmFpc2VkDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vc2VtdmVyL3NlbXZl ci9pc3N1ZXMvNTA0Ij5odHRwczovL2dpdGh1Yi5jb20vc2VtdmVyL3NlbXZlci9pc3N1ZXMvNTA0 PC9hPiZuYnNwOyBvbiB0aGUgc2VtdmVyIDIuMC4wIGdpdGh1YiB0byBjb25maXJtIHRoYXQgbXkg aW50ZXJwcmV0YXRpb24gaXMgY29ycmVjdCwgYW5kIG5vIG9uZSBoYXMgZGlzcHV0ZWQgaXQgeWV0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIuIFZlbmRvciBzb2Z0d2FyZSByZWxlYXNl cyBjYW4gaGF2ZSBhIHZlcnkgbG9uZyBzdXBwb3J0IHRpbWUgKGUuZy4gZWFzaWx5IDUmIzQzOyB5 ZWFycyksIHdpdGggYW4gZXhwZWN0YXRpb24gdGhhdCBidWdzIGdldCBmaXhlZC4mbmJzcDsgUmVx dWlyaW5nDQogdGhhdCBjdXN0b21lcnMgdXBncmFkZSB0aGVpciBzb2Z0d2FyZSAob3IgcGVyaGFw cyBoYXJkd2FyZSkgdG8gdGhlIHZlcnkgbGF0ZXN0IHNvZnR3YXJlIHZlcnNpb24gdG8gcGljayB1 cCBhIHNtYWxsIGJ1ZyBmaXggaXMgbm90IHJlYWxpc3RpYy4mbmJzcDsgVGhpcyBpcyBwcmltYXJp bHkgd2h5IEkgdGhpbmsgdGhhdCB0aGUg4oCYbeKAmSBhbmQg4oCYTeKAmSBhcmUgc28gaW1wb3J0 YW50LiZuYnNwOyBUaGV5IGFsbG93IGZvciBidWcgZml4ZXMgaW4gYSB3YXkgdGhhdCBTZW12ZXIN CiAyLjAuMCBzaW1wbHkgZG9lcyBub3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNlbXZlciAyLjAuMCBvbmx5IGFsbG93cyBmb3IgYnVnZml4ZXMgaW4gdGhlIGltcGxlbWVu dGF0aW9uIChieSB1cGRhdGluZyB0aGUgcGF0Y2ggdmVyc2lvbiBudW1iZXIpLCBidXQgaGFzIHRo ZSBleHBlY3RhdGlvbiB0aGF0IHRoZXJlDQogYXJlICo8Yj5uZXZlcjwvYj4qIGFueSBub24tYmFj a3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlcyBpbiB0aGUgQVBJLCBub3QgZXZlbiB0byBmaXggYSBi dWcsIGV4Y2VwdCBhdCB0aGUgdGlwIG9mIHRoZSBkZXZlbG9wbWVudCB0cmVlLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBzaG9ydCwgSSB0aGluayB0aGF0IHZhbmlsbGEg U2VtdmVyIDIuMC4wIGlzIGEgZ29vZCBmaXQgZm9yIG9wZW4gc291cmNlIHByb2plY3RzIHdoZXJl IHlvdSBjYW4ganVzdCB0ZWxsIHRoZSBjbGllbnQgdG8gdXBkYXRlIHRvIHRoZQ0KIGxhdGVzdCB2 ZXJzaW9uIHRvIHBpY2sgdXAgdGhlIGZpeC4mbmJzcDsgSSBkb27igJl0IHRoaW5rIHRoYXQgU2Vt dmVyIDIuMC4wIGlzIHNvIHdlbGwgYWxpZ25lZCB0byBBUElzIHRoYXQgYXJlIHJlcXVpcmVkIHRv IGJlIG1haW50YWluZWQgZm9yIGxvbmcgcGVyaW9kcyBvZiB0aW1lLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltjdWVd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgbWUgc3RhcnQgYnkgYWRt aXR0aW5nIHRoYXQgSSBhbSBhIFlBTkcgbmVvcGh5dGUsIHNvIHRha2UgdGhpcyBhcyBhIHF1ZXN0 aW9uIHJhdGhlciB0aGFuIGEgc3VnZ2VzdGlvbiwgYnV0IHdvdWxkIGl0IG1ha2UgYW55IHNlbnNl IHRvIGFwcGx5IHRoZSBzZW1hbnRpY3Mgb2YgU2VtdmVyIDIuMC4wIGZvciBzdGFuZGFyZCBtb2Rl bHMgYW5kIGFsbG93IHRoZSB1c2Ugb2Ygc29tZXRoaW5nIG1vcmUgZXhwcmVzc2l2ZSwNCiBzdWNo IGFzIHRoYXQgcHJvcG9zZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNpb25pbmctcmVxcy0wMiI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmVyZHQtbmV0bW9kLXlhbmctdmVyc2lvbmluZy1yZXFz LTAyPC9hPiwgZm9yIG5hdGl2ZSBtb2RlbHM/IE15IGd1ZXNzIGlzIHRoYXQgc3RhbmRhcmQgdnMu IG5hdGl2ZSBtb2RlbCBpcyBhIGRpc3RpbmN0aW9uIHRoYXQgd2UgZGlzY3VzcyBhbmQgdGhhdCBp cyBldmlkZW50IGJ5IFlBTkcgbW9kZWwgbmFtZTsgaG93ZXZlciwgYSBZQU5HIGNvbXBpbGVyIGhh cyBubyBrbm93bGVkZ2Ugb2YgdGhpcw0KIGFuZCBtYWtlcyBubyBkaXN0aW5jdGlvbi4gTmV2ZXJ0 aGVsZXNzLCBJIHRob3VnaHQgSeKAmWQgdGhyb3cgaXQgb3V0IHRoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D aGFybGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgYWx0ZXJuYXRpdmUgdGhhdCBSb2IgU2hha2lyIG1l bnRpb25lZCBhdCBJRVRGIDEwMyBpbiB0aGUgY29udGV4dCBvZiBPcGVuQ29uZmlnLCB3aGljaCB1 c2VzIHN0cmljdCBTZW12ZXIgMi4wLjAsIGlzIHRvIGhhbmRsZSB0aGVzZQ0KIGJ1ZyBmaXhlcyB1 c2luZyBkZXZpYXRpb25zLiZuYnNwOyBCdXQgaXQgc2VlbXMgdG8gYmUgc2lnbmlmaWNhbnRseSBt b3JlIGNvbXBsZXggdG8gbWFuYWdlIGJ1ZyBmaXhlcyB1c2luZyBleHRyYSBkZXZpYXRpb24gbW9k dWxlcyByYXRoZXIgdGhhbiBhbGxvd2luZyB0aGUg4oCYbeKAmSB8IOKAmE3igJkgbW9kaWZpZXJz LiZuYnNwOyBWZXJzaW9uaW5nIHdvdWxkIG5vIGxvbmdlciBsaW1pdGVkIHRvIGEgbW9kdWxlIHZl cnNpb24gbnVtYmVyLCBidXQgcmVxdWlyZSBrbm93bGVkZ2UNCiBvZiB0aGUgbW9kdWxlIHZlcnNp b24gYW5kIHNldCBvZiBkZXZpYXRpb25zIHRoYXQgYXJlIGFwcGxpZWQgdG8gaXQuJm5ic3A7IEkg d291bGQgcmF0aGVyIGRldmlhdGlvbnMgYXJlIHJlc2VydmVkIHRvIGluZGljYXRlIHdoZXRoZXIg YW4gaW1wbGVtZW50YXRpb24gZG9lc27igJl0IG1hdGNoIHRoZSBtb2R1bGUgc3BlY2lmaWNhdGlv biByYXRoZXIgdGhhbiB1c2UgdGhlbSBhcyBhIHdheSBvZiBmaXhpbmcgYnVncyBpbiB0aGUgc3Bl Y2lmaWNhdGlvbiBpdHNlbGYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+My4gSSBhZ3Jl ZSB0aGF0IHRoZSB1c2Ugb2YgU2VtdmVyICYjNDM7IHBhY2thZ2VzICYjNDM7IHZlcnNpb24gc2Vs ZWN0aW9uIGRvZXMgbm90IHJlZHVjZSB0aGUgb3ZlcmFsbCBudW1iZXIgb2YgcGF0aHMgdG8gYSBj b25maWd1cmFibGUgcHJvcGVydHksDQogYnV0IGl0IGRvZXMgZW5zdXJlIHRoYXQgdGhlcmUgaXMg b25seSBhIHNpbmdsZSBwYXRoIHRvIGEgY29uZmlndXJhYmxlIHByb3BlcnR5IHdpdGhpbiBhIFlB TkcgZGF0YXN0b3JlIHNjaGVtYS4gJm5ic3A7Jm5ic3A7U28gd2hpY2hldmVyIHZlcnNpb24gZWFj aCBjbGllbnQgaXMgdXNpbmcsIHRoZXkgb25seSB1c2UgYSBzaW5nbGUgcGF0aC4mbmJzcDsgSS5l LiBtaXJyb3JpbmcgdGhlIHdheSB0aGF0IGEgY2xhc3NpYyBwcm9ncmFtbWluZyBBUEkgbWlnaHQg YmUgdmVyc2lvbmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZXJ2ZXJz IHRoYXQgd2lzaCB0byBzdXBwb3J0IHRoaXMgd291bGQgaGF2ZSB0byBtYXAgdGhlIGRhdGEgYmV0 d2VlbiBkaWZmZXJlbnQgWUFORyBkYXRhc3RvcmUgc2NoZW1hIHZlcnNpb25zLiZuYnNwOyBOb3Qg YWxsIG1hcHBpbmdzIGFyZQ0KIHBvc3NpYmxlLCBidXQgYXQgbGVhc3QgYW55IGNhc2VzIHdoZXJl IGl0IGlzIG5vdCBwb3NzaWJsZSBjYW4gYmUgZGV0ZWN0ZWQgYW5kIHJlcG9ydGVkIHRvIHRoZSBj bGllbnQgdmlhIGFuIG91dCBvZiBiYW5kIG1lY2hhbmlzbS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SWYgdGhlIG1vZHVsZSBjb250ZW50IGNoYW5nZXMgc2lnbmlmaWNhbnRs eSBiZXR3ZWVuIG1vZHVsZSB2ZXJzaW9ucyB0aGF0IG1hcHBpbmcgd2lsbCBiZSBtdWNoIGhhcmRl ciB0aGFuIGlmIHRoZSBjaGFuZ2VzIGFyZSBtaW5pbWFsDQogb3IgYmFja3dhcmRzIGNvbXBhdGli bGUuJm5ic3A7IFNvIHRoZXJlIGlzIHN0aWxsIGEgc3Ryb25nIGluY2VudGl2ZSBmb3IgbW9kZWwg d3JpdGVycyB0byBtaW5pbWl6ZSBjaHVybiB0byB0aGUgWUFORyBtb2RlbHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8YnI+DQpSb2I8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuICZsdDth bmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTkgTWFyY2ggMjAxOSAx ODozNTxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lz Y28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwt Zi5jb20mZ3Q7OyBrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ7IG5ldG1vZEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gYWRvcHRpb24gcG9sbCBmb3IgeWFuZy12ZXJz aW9uaW5nLXJlcXMtMDI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pk9uIFR1ZSwgTWFyIDE5LCAyMDE5IGF0IDk6MzggQU0gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0 OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIu MHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KSGkgTWFydGluLDxicj4NCjxicj4NClRoYW5rcyBmb3Ig dGhlIHJldmlldyBhbmQgY29tbWVudHMuPGJyPg0KPGJyPg0KQSBjb3VwbGUgb2YgcG9pbnRzOjxi cj4NCjxicj4NCjEpIExvdHMgb2YgbW9kZWxzIG91dHNpZGUgdGhvc2UgcHVibGlzaGVkIGluIFNE T3MgYXJlIGFscmVhZHkgbm90IGZvbGxvd2luZyB0aGUgUkZDIDc5NTAgcmV2aXNpb24gcnVsZXMu Jm5ic3A7IEkgdGhpbmsgdGhhdCBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBhIHZlcnNpb25pbmcgc2No ZW1lIHRoYXQgcmVmbGVjdHMgaG93IFlBTkcgbW9kZWxzIGFyZSBhY3R1YWxseSBldm9sdmluZyBy YXRoZXIgdGhhbiBoYXZlIGFsbCB2ZW5kb3IgYW5kIE9DIFlBTkcgbW9kdWxlcw0KIGVpdGhlciBq dXN0IGlnbm9yaW5nIHRoZSBydWxlcywgb3IgdXNpbmcgY2xldmVyIHRyaWNrcyB0aGF0IHN0cmlj dGx5IGNvbmZvcm0gd2l0aCB0aGUgcnVsZXMgYnV0IGdvIGFnYWluc3QgdGhlIHNwaXJpdCBvZiB0 aGVtIChlLmcuIGp1c3QgcHVibGlzaCBhbiBlbnRpcmVseSBuZXcgc2V0IG9mIFlBTkcgbW9kdWxl cyBmb3IgZWFjaCByZWxlYXNlKS4mbmJzcDsgQWxzbyBub3RpbmcgdGhhdCBoYXZpbmcgYSBzY2hl bWUgdGhhdCBhbGxvd3Mgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlDQogY2hhbmdlcyBkb2VzIG5v dCByZXF1aXJlIHRoYXQgZXZlcnlvbmUgdXNlcyB0aGVtIC0gSUVURiBjb3VsZCBjb250aW51ZSB0 byBhbHdheXMgcHVibGlzaCBiYWNrd2FyZHMgY29tcGF0aWJsZSBtb2R1bGVzLiZuYnNwOyBUaGUg b2J2aW91cyBhbHRlcm5hdGl2ZSBoZXJlIGlzIHRoYXQgZWFjaCB2ZW5kb3IgY29tZXMgdXAgd2l0 aCB0aGVpciBvd24gdmVyc2lvbmluZyBleHRlbnNpb24gYW5kIGlnbm9yZXMgdGhlIFJGQyA3OTUw IHNlY3Rpb24gMTEgcnVsZXMNCiBhbnl3YXksIGJ1dCBJJ20gbm90IHN1cmUgaG93IHRoYXQgcmVh bGx5IGhlbHBzIGNsaWVudCZsdDstJmd0O3NlcnZlciBpbnRlcm9wLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5JIGRvIG5vdCBzdXBwb3J0IGJyYW5jaGluZyBmb3IgWUFORyBtb2RlbHMgc28gSSBk byBub3Qgc3VwcG9ydGVkIG1vZGlmaWVkIFNFTVZFUi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BZGRp bmcgYSBzcGVjaWFsIGNoYXJhY3RlciB0byB0aGUgdmVyc2lvbiBzdHJpbmcgZG9lc24ndCBoZWxw IHRoZSBkZXBsb3llZCBjbGllbnQgY29kZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRoYXQgc3RvcHMg d29ya2luZyB3aGVuIHRoZSBzZXJ2ZXIgY29kZSBpcyB1cGdyYWRlZC4mbmJzcDsgVGhpcyBpcyBh IHF1YWxpdHkgaXNzdWUgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmVhY2ggb3JnYW5pemF0aW9u IGhhcyB0byBkZWFsIHdpdGggdGhlIGJlc3QgdGhleSBjYW4uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBkbyBub3Qgb2JqZWN0IHRvIHRoZSBhZGRpdGlv biBvZiBhIFNFTVZFUiBmaWVsZCB0byBhIFlBTkcgbW9kdWxlIGJlY2F1c2UgdGhlc2UgdmVyc2lv bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnN0cmluZ3MgYXJlIGZhbWlsaWFyIHRvIHVzZXJzLiZuYnNw OyBJdCBpcyBwb3NzaWJsZSB0byBleHByZXNzIGltcG9ydCByYW5nZXMgc3VjaCBhcyAxLjIuKiAo YW55IDEuMi54IHJlbGVhc2UpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+d2hpY2ggYXJlIG5vdCBwb3Nz aWJsZSB3aXRoIGRhdGUgc3RyaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KMikgSSBkb24ndCB1bmRlcnN0YW5kIGhv dyB0aGUgUkZDIDc5NTAgYXBwcm9hY2ggb2YgJnF1b3Q7ZGVwcmVjYXRlIGEgYnVnZ3kgbm9kZSwg YW5kIHJlcGxhY2Ugd2l0aCBhIHdvcmtpbmcgbm9kZSZxdW90OyByZWFsbHkgd29ya3MgaW4gcHJh Y3RpY2UsIHBhcnRpY3VsYXJseSBmb3IgY29uZmlndXJhdGlvbiBkYXRhIG5vZGVzIHdoZXJlIHlv dSBoYXZlIHR3byBjbGllbnRzIGludGVyYWN0aW5nIHdpdGggYSBzZXJ2ZXIsIG9uZSBpbnRlcmFj dGluZyB3aXRoIHRoZSBvbGQNCiBwYXRoLCBhbmQgYW5vdGhlciB1c2luZyB0aGUgbmV3IHBhdGgu Jm5ic3A7IFBlcmhhcHMgdGhlcmUgaXMgYSByb2J1c3Qgc2NoZW1lIHRoYXQgd29ya3MgaW4gYWxs IGNhc2VzLCBidXQgaXQgaXNuJ3Qgb2J2aW91cyB0byBtZS4mbmJzcDsgSGlzdG9yaWNhbGx5LCBm b3IgQ0xJIHdlIGp1c3QgdHJhbnNsYXRlIHRoZSBDTEkgZnJvbSBvbGQgdG8gbmV3IGZvcm1hdCBh bmQgdGhlbiByZXR1cm4gdGhlIG5ldyBmb3JtYXQgd2hlbiB0aGUgcnVubmluZyBjb25maWcgaXMg cmVxdWVzdGVkLiZuYnNwOw0KIEJ1dCB0aGF0IHdpbGwgc3RpbGwgYnJlYWsgYW4gb2xkIGNsaWVu dCB0aGF0IGRvZXNuJ3QgdW5kZXJzdGFuZCBob3cgdG8gcmVhZCB0aGUgbmV3IENMSSwgZXZlbiBp ZiB0aGUgc2VydmVyIHN1cHBvcnRzIHRoZW0gd3JpdGluZyB2aWEgdGhlIG9sZCBDTEkuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNFTVZFUiBk b2VzIG5vdCByZWR1Y2UgdGhlIG51bWJlciBvZiBwYXRocyB0byB0aGUgdW5kZXJseWluZyBjb25m aWd1cmF0aW9uIG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGF0IHByb2JsZW0gZG9lcyBu b3QgY2hhbmdlIHdoZXRoZXIgYSBuZXcgWFBhdGggYWJzb2x1dGUtcGF0aC1leHByIGlzIHVzZWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5vciB3aGV0aGVyIHRoZSBzYW1lIHBhdGggaXMgb3ZlcmxvYWRl ZCB3aXRoIHNlbWFudGljcyBkZXJpdmVkIGZyb20gYWRkaXRpb25hbCBwcm90b2NvbCBwYXJhbWV0 ZXJzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KGUuZy4sIHZlcnNpb25pbmcgb2YgZWFjaCBk YXRhIG5vZGUpLiBJIHByZWZlciB0aGUgZXhpc3RpbmcgWFBhdGggc29sdXRpb24gYmVjYXVzZSBp dCBpcyBleHBsaWNpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnNvIHRoZSBZQU5HIHJlYWRlciBjYW4g ZWFzaWx5IHNlZSB0aGUgbXVsdGlwbGUgcGF0aHMsIGFuZCBubyBuZXcgcHJvdG9jb2wgd29yayBu ZWVkZWQgdG8gc3VwcG9ydCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JZiB0aGVyZSBpcyBhbiBO QkMgY2hhbmdlIHRvIGFuIG9iamVjdCB0aGVuIGFsbCBYUGF0aCBhbmQgbGVhZnJlZiByZWZlcmVu Y2VzIHRvIGl0IHdpbGwgcHJvYmFibHkgYnJlYWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhdCBz ZWVtcyBsaWtlIGEgaGFyZGVyIHByb2JsZW0gdG8gc29sdmUgdGhhbiB0aGUgb3JpZ2luYWwgcGF0 aCBkdXBsaWNhdGlvbiBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQpFdmVuIGlmIHRoZXJlIGlzIGEgd29ya2Fi bGUgc29sdXRpb24gZm9yIHRoaXMgc2ltcGxlIGNhc2UsIEkgc3VzcGVjdCB0aGF0IHRoZXJlIGFy ZSBtYW55IHNsaWdodGx5IG1vcmUgY29tcGxpY2F0ZWQgY2FzZXMgdGhhdCBkb24ndCB3b3JrIChl LmcuIHJla2V5aW5nIGEgbGlzdCwgY2hhbmdpbmcgZGVmYXVsdHMsIGluY29tcGF0aWJsZSB0eXBl cykuPGJyPg0KPGJyPg0KSW4gc2hvcnQsIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUgcHJlbWlzZSB0 aGF0IHRoZSBjdXJyZW50IFlBTkcgdmVyc2lvbmluZyBzY2hlbWEgdXNpbmcgcmV2aXNpb24gZGF0 ZXMgaXMgd29ya2luZyBqdXN0IGZpbmUsIGFuZCBubyBjaGFuZ2VzIGFyZSBuZWVkZWQuPGJyPg0K PGJyPg0KVGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbmV0bW9kICZsdDs8 YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5u ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBNYXJ0aW4gQmpvcmts dW5kPGJyPg0KU2VudDogMTkgTWFyY2ggMjAxOSAxNToxMjxicj4NClRvOiA8YSBocmVmPSJtYWls dG86a2VudCUyQmlldGZAd2F0c2VuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmtlbnQmIzQzO2lldGZA d2F0c2VuLm5ldDwvYT48YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW25l dG1vZF0gYWRvcHRpb24gcG9sbCBmb3IgeWFuZy12ZXJzaW9uaW5nLXJlcXMtMDI8YnI+DQo8YnI+ DQpIaSw8YnI+DQo8YnI+DQpJIGhhdmUgcmVhZCB0aGlzIGRvY3VtZW50LCBhbmQgSSBkbyBub3Qg dGhpbmsgaXQgc2hvdWxkIGJlIGFkb3B0ZWQuPGJyPg0KPGJyPg0KSSBvYmplY3QgdG8gdGhlIGlk ZWEgdGhhdCB3ZSBzaG91bGQgYWxsb3cgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZXMg dG8gcHVibGlzaGVkIFlBTkcgbW9kdWxlcy48YnI+DQo8YnI+DQpUaGUgZHJhZnQgbW90aXZhdGVz IHRoaXMgaWRlYSB3aXRoOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDt3ZSBtdXN0IHJlY29nbml6 ZSB0aGF0IG1hbnkgWUFORzxicj4NCiZuYnNwOyAmbmJzcDttb2R1bGVzIGFyZSBhY3R1YWxseSBn ZW5lcmF0ZWQgWUFORyBtb2R1bGVzIChmb3IgZXhhbXBsZSwgZnJvbTxicj4NCiZuYnNwOyAmbmJz cDtpbnRlcm5hbCBkYXRhYmFzZXMpPGJyPg0KPGJyPg0KSSBkbyBub3QgYWdyZWUgdGhhdCB3ZSBz aG91bGQgY2hhbmdlIHdoYXQgd2UgYWxsb3cgaW4gcHVibGlzaGVkIG1vZHVsZXMgYi9jIG9mIHRo aXMuPGJyPg0KPGJyPg0KSXQgYWxzbyBtb3RpdmF0ZXMgdGhpcyBpZGVhIHdpdGg6PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwO1RoZSBwb2ludHMgbWFkZSBhYm92ZSBsZWFkIHRvIHRoZSBsb2dpY2Fs IGNvbmNsdXNpb24gdGhhdCB0aGU8YnI+DQombmJzcDsgJm5ic3A7c3RhbmRhcmRpemVkIFlBTkcg bW9kdWxlcyBoYXZlIHRvIGJlIHBlcmZlY3Qgb24gZGF5IG9uZSAoYXQgbGVhc3QgdGhlPGJyPg0K Jm5ic3A7ICZuYnNwO3N0cnVjdHVyZSBhbmQgbWVhbmluZyksIHdoaWNoIGluIHR1cm4gbWlnaHQg ZXhwbGFpbiB3aHkgSUVURiBZQU5HPGJyPg0KJm5ic3A7ICZuYnNwO21vZHVsZXMgdGFrZSBzbyBs b25nIHRvIHN0YW5kYXJkaXplLjxicj4NCjxicj4NCkkgZGlzYWdyZWUgd2l0aCB0aGlzLiZuYnNw OyBGaXJzdCBvZiBhbGwsIHdlIGhhdmUgYWxyZWFkeSBwdWJsaXNoZWQgcmV2aXNpb24gdHdvIG9m IHNldmVyYWwgWUFORyBtb2R1bGVzIChpZXRmLWluZXQtdHlwZXMsIGlldGYteWFuZy10eXBlLCBp ZXRmLWludGVyZmFjZXMsIGlldGYtaXAsIGlldGYtcm91dGluZywgLi4uKSwgc28gdGhlIHN0YXRl bWVudCB0aGF0ICZxdW90O3N0YW5kYXJkaXplZCBZQU5HIG1vZHVsZXMgaGF2ZSB0byBiZSBwZXJm ZWN0IG9uIGRheSBvbmUmcXVvdDsNCiBpcyBzaW1wbHkgbm90IHRydWUuPGJyPg0KPGJyPg0KU2Vj b25kLCBJIGRvbid0IHRoaW5rIHRoZSB1cGdyYWRlIHJ1bGVzIGFyZSB0aGUgcmVhc29uIGl0IHRh a2VzIGEgbG9uZyB0aW1lIHRvIHN0YW5kYXJkaXplIElFVEYgbW9kZWxzIChJIHRoaW5rIGl0IGhh cyB0byBkbyB3aXRoIHRoZSBwcm9jZXNzIGl0c2VsZiwgaW5jbHVkaW5nIHRoZSBmYWN0IHRoYXQg bW9kZWxzIGdldCByZXZpZXdzIGZyb20gbWFueSBkaWZmZXJlbnQgcGVvcGxlIHdpdGggZGlmZmVy ZW50IGJhY2tncm91bmQuKSZuYnNwOyBbQlRXLCBpcw0KIGl0IHRydWUgdGhhdCBkcmFmdHMgd2l0 aCBZQU5HIG1vZGVscyB0YWtlIGxvbmdlciB0aW1lIGZyb20gd2cgLTAwIHRvIHB1Ymxpc2hlZCBS RkMgdGhhbiBvdGhlciBkcmFmdHM/XTxicj4NCjxicj4NCjxicj4NClRoaXMgc2FpZCwgSSB0aGlu ayB0aGVyZSBhcmUgc29tZSBpbXBvcnRhbnQgcG9pbnRzIHRoYXQgdGhlIGRyYWZ0IHJhaXNlcywg YW5kIHRoYXQgSSB0aGluayB3ZSBzaG91bGQgY29udGludWUgdG8gd29yayBvbjsgc3BlY2lmaWNh bGx5IDIuMywgMi41LCAyLjYsIDIuNy4mbmJzcDsgQnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVz ZSBhcmVhcyByZXF1aXJlIGNoYW5nZXMgdG8gdGhlIHZlcnNpb25pbmcgc2NoZW1lLCBhbmQgSSB0 aGluayBpdCBpcyBhIG1pc3Rha2UNCiB0byBpbmNsdWRlIHRoZXNlIGFyZWFzIGluIHRoaXMgZHJh ZnQuPGJyPg0KPGJyPg0KU29tZSBjb21tZW50cyBvbiBzZWN0aW9uIDQsIFRoZSBQcm9ibGVtIFN0 YXRlbWVudDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7byZuYnNwOyBBbnkgbm9uLWJhY2t3YXJk cy1jb21wYXRpYmxlIGNoYW5nZSBvZiBhIGRlZmluaXRpb24gcmVxdWlyZXM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBlaXRoZXIgYSBuZXcgbW9kdWxlIG5hbWUgb3IgYSBuZXcgcGF0aC4mbmJz cDsgVGhpcyBoYXMgYmVlbiBmb3VuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvc3RseSB0 byBzdXBwb3J0IGluIGltcGxlbWVudGF0aW9ucywgaW4gcGFydGljdWxhciBvbiB0aGUgY2xpZW50 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2lkZS48YnI+DQo8YnI+DQpZZXMgSSBhZ3JlZSB0 aGVyZSBpcyBhIGNvc3QgYXNzb2NpYXRlZCB3aXRoIHRoaXMuJm5ic3A7IEJ1dCBJIGhhdmUgY29t ZSBhY3Jvc3MgdmVuZG9yIG1vZHVsZXMgdGhhdCBtYWtlIE5CQyBjaGFuZ2VzIHcvbyBpbnRyb2R1 Y2luZyBhIG5ldyBwYXRoLCBhbmQgdGhpcyBpcyBhbHNvIGNvc3RseSB0byBoYW5kbGUuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwO28mbmJzcDsgU2luY2Ugbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxl IGNoYW5nZXMgcmVxdWlyZSBlaXRoZXIgYSBuZXcgbW9kdWxlPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgbmFtZSBvciBhIG5ldyBwYXRoLCBzdWNoIGNoYW5nZXMgd2lsbCBpbXBhY3Qgb3RoZXIg bW9kdWxlcyB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW1wb3J0IGRlZmluaXRpb25z LiZuYnNwOyBJbiBmYWN0LCB3aXRoIHRoZSBjdXJyZW50IG1vZHVsZSB2ZXJzaW9uaW5nPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2NoZW1lIG90aGVyIG1vZHVsZXMgaGF2ZSB0byBvcHQtaW4g aW4gb3JkZXIgdG8gdXNlIHRoZSBuZXc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB2ZXJzaW9u LiZuYnNwOyBUaGlzIGVzc2VudGlhbGx5IGxlYWRzIHRvIGEgcmlwcGxlIGVmZmVjdCB3aGVyZSBh IG5vbi08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiYWNrd2FyZHMtY29tcGF0aWJsZSBjaGFu Z2Ugb2YgYSBjb3JlIG1vZHVsZSBjYXVzZXMgdXBkYXRlcyBvbiBhPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgcG90ZW50aWFsbHkgbGFyZ2UgbnVtYmVyIG9mIGRlcGVuZGVudCBtb2R1bGVzLjxi cj4NCjxicj4NClRoaXMgaXMgYnkgZGVzaWduLiZuYnNwOyBXZSBjYW5ub3QgaGF2ZSBhIHNpdHVh dGlvbiB3aGVyZSBhIGxlZ2FsIG1vZGlmaWNhdGlvbiB0byBhIG1vZHVsZSBsZWFkcyB0byBvdGhl ciBtb2R1bGVzIGJlY29taW5nIGludmFsaWQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO28mbmJz cDsgWUFORyBoYXMgYSBtZWNoYW5pc20gdG8gbWFyayBkZWZpbml0aW9ucyBkZXByZWNhdGVkIGJ1 dCBpdCBsZWF2ZXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpdCBvcGVuIHdoZXRoZXIgaW1w bGVtZW50YXRpb25zIGFyZSBleHBlY3RlZCB0byBpbXBsZW1lbnQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBkZXByZWNhdGVkIGRlZmluaXRpb25zIGFuZCB0aGVyZSBpcyBubyB3YXkgKG90aGVy IHRoYW4gdHJpYWwgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZXJyb3IpIGZvciBhIGNs aWVudCB0byBmaW5kIG91dCB3aGV0aGVyIGRlcHJlY2F0ZWQgZGVmaW5pdGlvbnMgYXJlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc3VwcG9ydGVkIGJ5IGEgZ2l2ZW4gaW1wbGVtZW50YXRpb24u PGJyPg0KPGJyPg0KQXMgSSB3cm90ZSBhYm92ZSwgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSBwcm9i bGVtIHRoYXQgc2hvdWxkIGJlIHNvbHZlZC4mbmJzcDsgQnV0IHRoaXMgaXMgbm90IGEgbW90aXZh dGlvbiBmb3IgY2hhbmdpbmcgWUFORyB2ZXJzaW9uaW5nLjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtvJm5ic3A7IFlBTkcgZG9lcyBub3QgaGF2ZSBhIHJvYnVzdCBtZWNoYW5pc20gdG8gZG9jdW1l bnQgd2hpY2ggZGF0YTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlZmluaXRpb25zIGhhdmUg Y2hhbmdlZCBhbmQgdG8gcHJvdmlkZSBndWlkYW5jZSBob3c8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGRlYWwgd2l0aCB0aGUgY2hhbmdlLiZuYnNwOyBX aGlsZSBpdCBpcyBwb3NzaWJsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGhhdmUgdGhp cyBkZXNjcmliZWQgaW4gZ2VuZXJhbCBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRzLCBoYXZpbmc8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGVzZSBkZXRhaWxzIGVtYmVkZGVkIGluIGdlbmVyYWwg ZGVzY3JpcHRpb24gc3RhdGVtZW50cyBkb2VzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IG1ha2UgdGhpcyBpbmZvcm1hdGlvbiBhY2Nlc3NpYmxlIHRvIHRvb2xzLjxicj4NCjxicj4NClRo aXMgbWlnaHQgYWxzbyBiZSB3b3J0aCBleHBsb3JpbmcsIGJ1dCB0aGlzIGlzIG5vdCBhIG1vdGl2 YXRpb24gZm9yIGNoYW5naW5nIFlBTkcgdmVyc2lvbmluZy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQovbWFydGluPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a2VudCYjNDM7 aWV0ZkB3YXRzZW4ubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBTZWVpbmcgYXMgaG93IHdl IGFsbCBuZWVkIHRvIHJlYWQgdGhpcyBkcmFmdCBhbnl3YXlzLCBpbiBwcmVwYXJhdGlvbiBmb3Ig b3VyIG1lZXRpbmcgaW4gUHJhZ3VlLCBpdCBzZWVtcyBsaWtlIGEgZ29vZCB0aW1lIGZvciB0aGlz IHBvbGwuJm5ic3A7IFRodXNseSwgdGhpcyBlbWFpbCBiZWdpbnMgYSAxLXdlZWsgYWRvcHRpb24g cG9sbCBmb3I6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRt b2QteWFuZy12ZXJzaW9uaW5nLXJlcXMtMDIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy12ZXJzaW9uaW5nLXJlcXMt MDI8L2E+IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy12ZXJzaW9uaW5nLXJlcXMtMCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12ZXJkdC1uZXRtb2QteWFuZy12 ZXJzaW9uaW5nLXJlcXMtMDwvYT48YnI+DQomZ3Q7IDImZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFBsZWFzZSB2b2ljZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgTWFyY2ggMjAu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vdGUgdGhhdCB0aGlzIGRyYWZ0IGRlZmluZXMgKnJlcXVp cmVtZW50cyogYW5kIGl0cyBpbnRlbmRlZCBzdGF0dXMgaXMgJnF1b3Q7SW5mb3JtYXRpb25hbC4m cXVvdDsmbmJzcDsgJm5ic3A7SSBiZWxpZXZlIHRoYXQgaXQgaXMgZ29vZCBmb3IgV0dzIHRvIGZv cm1hbGl6ZSByZXF1aXJlbWVudHMsIGV2ZW4gdGFraW5nIHN1Y2ggZHJhZnRzIHRocnUgTGFzdCBD YWxsLCBpbiBvcmRlciB0byBlbnN1cmUgY29uc2Vuc3VzIG9uIHRoZSByZXF1aXJlbWVudHMuJm5i c3A7IFRoaXMgaXMgdGhlICZxdW90O2Fkb3B0aW9uJnF1b3Q7DQogY2FsbCwgdG8gYXNjZXJ0YWlu IGlmIHRoZSBXRyBhZ3JlZXMgd2l0aCB0aGF0IHN0YXRlbWVudDsgaWYgYWRvcHRlZCwgYSBzZXBh cmF0ZSAmcXVvdDtsYXN0IGNhbGwmcXVvdDsgd2lsbCBiZSBpc3N1ZWQgdG8gZW5zdXJlIHRvIGNv cnJlY3RuZXNzIG9mIHRoZSBkcmFmdCdzIGNvbnRlbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEtl bnQgKGFuZCBMb3UgYW5kIEpvZWwpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9k IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_5C97E9426E9A4AD0B3CFA2B60BBE4B48ciscocom_-- From nobody Sun Mar 24 13:45:13 2019 Return-Path: <01000169b1732722-f41ea67f-9c6e-4ec4-a6f2-90e340b4d7a4-000000@amazonses.watsen.net> 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 C5CC31200C4 for ; Sun, 24 Mar 2019 13:45: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ptDQU8bcglOl for ; Sun, 24 Mar 2019 13:45:09 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D49C120094 for ; Sun, 24 Mar 2019 13:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553460307; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=WucaHTTEMwUag0MiPF8D2AB9VRsFt9qtYkVj6AXlW3M=; b=JDBWQDwT5tjDQW9nhStv0QxGbl5MsJpj8IhAagKrRJFN3rQy6X74sP6hL54I9J8Y O51PF7vzF/1tp8ckhBfuIKOPSzBVkiVRl8UzBetdz3E2E/XcKEcLtdmTAUh8Wgk+sA7 bNWmqJhirdZYoErY8LdzmgWLfaMPv5Es9pAymyaI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kent Watsen X-Mailer: iPad Mail (16D57) In-Reply-To: Date: Sun, 24 Mar 2019 20:45:07 +0000 Cc: Joel Jaeggli , NetMod WG Content-Transfer-Encoding: quoted-printable Message-ID: <01000169b1732722-f41ea67f-9c6e-4ec4-a6f2-90e340b4d7a4-000000@email.amazonses.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> To: Andy Bierman X-SES-Outgoing: 2019.03.24-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:45:11 -0000 Hi Andy, > Andy Bierman wrote: >=20 > BTW, I do not support adoption of the requirements document at all. Can you say why? Is it a blanket statement about adopting requirements dra= fts in general, or something specific to this draft. Kent From nobody Sun Mar 24 13:54:40 2019 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 944011200F6 for ; Sun, 24 Mar 2019 13:54: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, SPF_PASS=-0.001, URIBL_BLOCKED=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 90t2n531kOvJ for ; Sun, 24 Mar 2019 13:54:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1F81200C4 for ; Sun, 24 Mar 2019 13:54:37 -0700 (PDT) Received: from localhost (dhcp-9104.meeting.ietf.org [31.133.145.4]) by mail.tail-f.com (Postfix) with ESMTPSA id 35F2E1AE034E; Sun, 24 Mar 2019 21:54:35 +0100 (CET) Date: Sun, 24 Mar 2019 21:54:33 +0100 (CET) Message-Id: <20190324.215433.23807447662347953.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190324161451.35uus4wwjjwbgarh@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] import-by-semver issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:54:40 -0000 Andy Bierman wrote: > On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Sun, Mar 24, 2019 at 03:14:18PM +0000, Rob Wilton (rwilton) wrote: > > > > > > But that is true of YANG compilers today. If there are multiple > > revisions of a module that could be chosen, then each compiler is at > > liberty to decide which revision to choose (last paragraph of section 5.1.1 > > in RFC 7950). > > > > > > > The difference is that NBC changes are not allowed. As long as you > > find a certain symbol, it has fixed and predictable semantics. > > > > Sorry, but changing the way the import statement works is an NBC > > change of YANG and this can't be done with extensions. > > > > > I strongly agree. > The expected behavior for tools needs to be consistent, especially for > the construction of the schema tree, which depends on the import rules. > > Implementation complexity should matter in the IETF, but it does not. > Just keep raising the complexity up to 10 and complain that the tools have > bugs, > as if the two are unrelated. (Simply looking for a hardwired string > "semver:version" > will not work since the prefix is not required to be "semver" in the > import-stmt.) Agreed, but it quite easy to first build a prefix map (prefix -> module name), and then instead of "xxxx:semver" you see ("ietf-semver", "semver"); and _this_ can be hardcoded in the compiler. (pyang works like this) This said, it is a bit weird with: import ietf-semver { prefix "semver"; semver:version 1.1.2; } so in order to handle the "semver:version" statement, you need to import the module that has the prefix "semver". But we can't just import it like a normal import, b/c it has the semver: statement that modifies how we do imports! /matrin From nobody Sun Mar 24 13:56:49 2019 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 F21D31200F5; Sun, 24 Mar 2019 13:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 PbRL3r8F-Ykv; Sun, 24 Mar 2019 13:56: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 95CA41200F1; Sun, 24 Mar 2019 13:56:38 -0700 (PDT) Received: from localhost (dhcp-9104.meeting.ietf.org [31.133.145.4]) by mail.tail-f.com (Postfix) with ESMTPSA id 81E411AE034E; Sun, 24 Mar 2019 21:56:37 +0100 (CET) Date: Sun, 24 Mar 2019 21:56:35 +0100 (CET) Message-Id: <20190324.215635.272162695612319338.mbj@tail-f.com> To: andy@yumaworks.com Cc: joelja@bogus.com, netmod@ietf.org, netmod-ver-dt@ietf.org From: Martin Bjorklund In-Reply-To: References: <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:56:41 -0000 Andy Bierman wrote: > On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli wrote: > > > > > > > On Mar 22, 2019, at 12:07, Lou Berger wrote: > > > > Hi, > > > > Thank you all for the good input on this thread. > > > > With the understanding that a 00 working group document is a starting > > point for the working group rather than a document that is ready for last > > call - we believe there is sufficient support to adopt this document as a > > starting point for the requirements we wish to address on this topic. > > > > It is clear that there is still work to be done on this document before we > > can declare consensus on it and, not surprisingly, that there is more work > > to be done on the solution. > > > > Authors, > > > > Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 > > with the only change being the name and publication date. The -01 version > > should focus on resolving issues raised during adoption. Of course the > > document is subject to normal WG input and processing. > > > > Please note the 'file' name change -this is to indicate that the > > requirements are not presupposing a specific solution. It is also > > consistent with how versioning is defined within the document currently. > > > > Note: we would like to try to continue the list discussion in next week's > > session and ask the Authors/DT to summarize issues raised during the > > adoption call and lead a discussion to help resolve these issues. > > > > I think this meeting is great opportunity to decide what steps need to be > > taken to advance the document within the working group. > > > > Martin specifically objects to the presence of of Non-Backward-Compatible > > changes. > > > > Many modules outside the IETF are already incompatible with roc 7950 yang > > 1.1 revision rules. So that cat may be out of the bag at least with respect > > to the real world. the question remains what to do about that? > > > > > > I do not look at the problem as allowing NBC so much as making it clear to > toolmakers what is going on, > like a deviation to the versioning rules. > > BTW, I do not support adoption of the requirements document at all. > I support the work on versioning as part of the charter, and I am happy to > accept the design team solution draft as the starting point, and just work > on a solution. > > But I think the solution is a bit flawed. > > 1) extensions are optional and problematic since they can be revisioned > without changing > the language version; the solution needs to use new YANG 1.2 statements > instead of extensions > > 2) the version string does not have to contain all the NBC semantics. > The solution draft does not show modified semver. > It should be done differently than overloading the version string; > > Let's say a fork is done on 1.3.0. > > revision 2017-07-30 { > description "Added leaf foo-64"; > semver:module-version "1.3.0"; > } > > start with a legal change, just not at the HEAD > > revision 2019-01-10 { > description "Added leaf bar-64"; > semver:module-version "1.3.1"; > } > > > then later, an NBC change > > revision 2019-02-10 { > description "Changed leaf bar-64 default-stmt"; > semver:module-version "1.3.2"; > semver:nbc-change; > > } > > then later, a legal change > > revision 2019-03-10 { > description "Added leaf baz-64"; > semver:module-version "1.3.3"; > > } +1 I have suggested something similar. > This is a form of an inline deviation-stmt. > The YANG update rules are not changing. They are just not being followed. Right! > The NBC info belongs in the revision-stmt, not overloading the version string. Agreed. > Not every major revision will mean NBC changes anyway. /martin > > > Andy > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Sun Mar 24 13:59:11 2019 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 D886C1200F5 for ; Sun, 24 Mar 2019 13:59: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 J2Zo7knhwNlV for ; Sun, 24 Mar 2019 13:59:08 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 DD0941200F1 for ; Sun, 24 Mar 2019 13:59:07 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id u21so4609304lfu.2 for ; Sun, 24 Mar 2019 13:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nKV7scbFE+QiTNcSxxUtnxsqYYgusvZ0ZpKMjyydIew=; b=2A3EV32RgVDEINyK4jR8LETv+AWnoIKRgBrNaGr5dNPqWGognUJkHDmkIlOGxFFsHT +aoE45X/pqv9EyUTFCnMFPor0DpTXHTQ0DJsahVTzsUsCDNfZiBafFd9ypJLBZGAifQ5 W5KnBBpW+iFxbliOWxnXWCKo6phg8MUj1+3L9fR832YtR11toiH+omCh0zmP+WKeR+Mh C0hqhDwEYkbuIK8X2dtLtZfmMX+KaAGUb16tXxW7VJztZ/fPgrfZdXm5qN2KBPNOyRLB U3Glms38FC04mVueaA38m+TTOfh9Xa+HxtFNvK378Hworu1D9TjvaRVDh8yfdb9yB1UR rBeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nKV7scbFE+QiTNcSxxUtnxsqYYgusvZ0ZpKMjyydIew=; b=hfzUq+dowaOyTjL8xB8/mW2nhPORGXD5OOqy6oUZf4VsLhopmX28tu+J8JfPQ4uMpa I3SeUSoiDT92k0KH/Pl7yzOKenMz8xCqaFuuKMJs1RVTXYmAJN3u3Z/ynXFkQpUnE23U QU/RlU8dsyhTTpm2m1RMZfgrj7L7uIP6xMDyOHNtaAT2yW0hlVEdxIHSY9qZQY3ToAZ7 49foJCVdv06WPiClXwCLTZLExIEUimYdHbUFPLtHVDpirZtYUuJYDHlPaGzyL1LR1ahV 3AufDnGqatdjCfBSP0RKD/QRmkzp1IcA3Xz9kiN0w9AaLxdiK6TPXEmGWNwsLqXHFNr0 jFcw== X-Gm-Message-State: APjAAAWmp/rHpxUO19/ms813cmWxRlM5VMtPrNNOoNhoIOmIWiZUOlnA Bi+3boDrSVGVNSiUT8+BJ1WFCq2T2qGo0VdqcaUhZg== X-Google-Smtp-Source: APXvYqwFjldPFK3Yn5nNCSq+dog4uj6W1uKdNGP9NiesJN/e413vFmIRNYvFmKfjs2YRcKqDDpdIF4eaA7S7bJRzOrQ= X-Received: by 2002:ac2:53ab:: with SMTP id j11mr10294777lfh.49.1553461145992; Sun, 24 Mar 2019 13:59:05 -0700 (PDT) MIME-Version: 1.0 References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> <01000169b1732722-f41ea67f-9c6e-4ec4-a6f2-90e340b4d7a4-000000@email.amazonses.com> In-Reply-To: <01000169b1732722-f41ea67f-9c6e-4ec4-a6f2-90e340b4d7a4-000000@email.amazonses.com> From: Andy Bierman Date: Sun, 24 Mar 2019 13:58:54 -0700 Message-ID: To: Kent Watsen Cc: Joel Jaeggli , NetMod WG Content-Type: multipart/alternative; boundary="000000000000c79bd40584dd5bce" Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 20:59:10 -0000 --000000000000c79bd40584dd5bce Content-Type: text/plain; charset="UTF-8" On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen wrote: > > Hi Andy, > > > Andy Bierman wrote: > > > > BTW, I do not support adoption of the requirements document at all. > > Can you say why? Is it a blanket statement about adopting requirements > drafts in general, or something specific to this draft. > > Because they just waste time. They are mostly reverse engineered from the desired solution (by the authors). We end up having the same debates twice. It is usually worse then that, since you end up debating the wording in the requirements instead of the merits of the solution-in-progress (considering all factors and readjusted requirements). > Kent > > Andy --000000000000c79bd40584dd5bce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 24, 2019 at 1:45 PM Kent = Watsen <kent+ietf@watsen.net> wrote:
Hi Andy,

> Andy Bierman wrote:
>
> BTW, I do not support adoption of the requirements document at all.
Can you say why?=C2=A0 =C2=A0Is it a blanket statement about adopting requi= rements drafts in general, or something specific to this draft.


They are mostly reverse engineered from the desired solution (by the auth= ors).
--000000000000c79bd40584dd5bce-- From nobody Sun Mar 24 14:47:06 2019 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 C161A120134 for ; Sun, 24 Mar 2019 14:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=mkNhb7fa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Vqm2FS6U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd-A9443Cjrx for ; Sun, 24 Mar 2019 14:47:02 -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 DF2A3120074 for ; Sun, 24 Mar 2019 14:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9151; q=dns/txt; s=iport; t=1553464021; x=1554673621; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2TaDSbvbEBuNTpC4brEom1W2CJUfDMxKfqLQsMT6McQ=; b=mkNhb7fa7Vxa1jz5x3jdup0MEMmsq6KJBeD09/hWR9wZxO81eU6OCMgk +hz2TEgzcbqISqQUwZM3DNL/5xV1yZjQHosxjxhBK0VhWKzXTDaly9vOE LiIeQCSIpf5nskQNtzWNyfEiA0I+geCF0vbpQRorGlZ7+uhXP0L5rSxsH 8=; IronPort-PHdr: =?us-ascii?q?9a23=3A3U64hhEFRVuTPPyDxcA4H51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeTwZiw/FcJqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABW+pdc/5RdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vUANodAQLJwqEBINHA4RSilaCV5J?= =?us-ascii?q?DhEmBLoEkA1QNAQEshEACF4RlIjQJDQEBAwEBCQEDAm0cDIVKAQEBAwEjHQE?= =?us-ascii?q?BNwEECwIBCBEDAQIBJwMCAgIwFAkIAgQBDQUbgwcBgRFMAw0IAQKiNgKKFHG?= =?us-ascii?q?BL4J4AQEFgkeCNRiCDAiBLwGLMReBQD+BOB+CTD6CYQSBfxaCVDGCJoprggi?= =?us-ascii?q?EH4dGjEEJApM3GZN+ixyTKgIEAgQFAg4BAQWBTTiBVnAVZQGCQYIKg26KU3K?= =?us-ascii?q?BKI1GAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208,217";a="539275141" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 21:47:00 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2OLl0VC005469 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 21:47:00 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 16:46:59 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 16:46:58 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 24 Mar 2019 17:46:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2TaDSbvbEBuNTpC4brEom1W2CJUfDMxKfqLQsMT6McQ=; b=Vqm2FS6UIvnQSRr1nWkAZNG4X/dzHIWZUBCwPLemqnGi9OFbcOx5eOs2b1zBxiln9AfV1MXTBGTAQS5XIIzuREAzV9Fv1bUy66iEpHVoTt/UFqC460uNsO2kwQsGXjRgSxzZQWmjweJRokGHSywFOkqOczSQw6yEYQZiERdJpzg= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3886.namprd11.prod.outlook.com (20.179.150.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Sun, 24 Mar 2019 21:46:57 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1730.017; Sun, 24 Mar 2019 21:46:57 +0000 From: "Reshad Rahman (rrahman)" To: Andy Bierman , Kent Watsen CC: NetMod WG Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU4n0Hp4WW914A9EC/TspsQ5jhtKYbP/OAgAAD2gCAAB4oAA== Date: Sun, 24 Mar 2019 21:46:56 +0000 Message-ID: <516900C0-88C2-4D91-991A-F7E9F8B824D6@cisco.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> <01000169b1732722-f41ea67f-9c6e-4ec4-a6f2-90e340b4d7a4-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91eb7a7c-97da-4595-f06c-08d6b0a23cd8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3886; x-ms-traffictypediagnostic: MN2PR11MB3886: x-microsoft-antispam-prvs: x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(136003)(366004)(199004)(189003)(256004)(8936002)(316002)(6486002)(54896002)(6306002)(2906002)(6436002)(26005)(236005)(6512007)(99286004)(25786009)(68736007)(53936002)(5660300002)(7736002)(83716004)(102836004)(8676002)(6246003)(71190400001)(81156014)(36756003)(186003)(81166006)(478600001)(110136005)(6116002)(58126008)(66066001)(6506007)(3846002)(476003)(97736004)(4326008)(53546011)(71200400001)(2616005)(86362001)(486006)(33656002)(14454004)(106356001)(105586002)(446003)(11346002)(229853002)(93886005)(82746002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3886; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: H9N60v4dhMwzT2NxEjX0IzxtMXtVCb8VX1CwdIrNyEHT754ZmASoB0Nq+biIlEv45gAEBbxuM10c53WECq+uU2nc1zYnogKeGc35KzaS3w+9iTcoIgQLiGsvPfZTdyjfPp+PKGme83rXkNza8B1KLnzMH+f6edWbW2+CPDouHOQOEutuBn+KEvbcI7S7Cu7mpq+ebDzTkmFddCajom+tem8TSxC7bLWDfTGA3VrEWFJTXUfRmpLK8SBOnE6Ijtozj/C0b3W3/NgHIQui8vE5ixiJUZ9rC1bDt+uodpU0bDf7VNV9ugmUh/ByXK/wAojepM2ScnsXL07dWlP8VqoOq5G15/zvl7aSxAqZyxh+9da9djP5JQGO1yniJTvBPWJB7JPdxzylYP/0FrBdrojUg908QTU6sCkE+e4yM1KTHjs= Content-Type: multipart/alternative; boundary="_000_516900C088C24D91991AF7E9F8B824D6ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 91eb7a7c-97da-4595-f06c-08d6b0a23cd8 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2019 21:46:56.9573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3886 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 21:47:05 -0000 --_000_516900C088C24D91991AF7E9F8B824D6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgJ0Fu ZHkgQmllcm1hbicgPGFuZHlAeXVtYXdvcmtzLmNvbT4NCkRhdGU6IFN1bmRheSwgTWFyY2ggMjQs IDIwMTkgYXQgOTo1OSBQTQ0KVG86IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4N CkNjOiBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBh ZG9wdGlvbiBwb2xsIGZvciB5YW5nLXZlcnNpb25pbmctcmVxcy0wMg0KDQoNCg0KT24gU3VuLCBN YXIgMjQsIDIwMTkgYXQgMTo0NSBQTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8 bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+PiB3cm90ZToNCg0KSGkgQW5keSwNCg0KPiBB bmR5IEJpZXJtYW4gd3JvdGU6DQo+DQo+IEJUVywgSSBkbyBub3Qgc3VwcG9ydCBhZG9wdGlvbiBv ZiB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGF0IGFsbC4NCg0KQ2FuIHlvdSBzYXkgd2h5PyAg IElzIGl0IGEgYmxhbmtldCBzdGF0ZW1lbnQgYWJvdXQgYWRvcHRpbmcgcmVxdWlyZW1lbnRzIGRy YWZ0cyBpbiBnZW5lcmFsLCBvciBzb21ldGhpbmcgc3BlY2lmaWMgdG8gdGhpcyBkcmFmdC4NCg0K QmVjYXVzZSB0aGV5IGp1c3Qgd2FzdGUgdGltZS4NClRoZXkgYXJlIG1vc3RseSByZXZlcnNlIGVu Z2luZWVyZWQgZnJvbSB0aGUgZGVzaXJlZCBzb2x1dGlvbiAoYnkgdGhlIGF1dGhvcnMpLg0KDQo8 UlI+IEkgZG9u4oCZdCB0aGluayB3ZeKAmXJlIHRpZWQgdG8gdGhlIHNvbHV0aW9uIG9mIHNlbXZl ciBvciBtb2RpZmllZCBzZW12ZXIgKHNwZWFraW5nIGZvciBteXNlbGYgYXQgbGVhc3QpLiBUaGUg bWFpbiBxdWVzdGlvbiBvbiB0aGUgcmVxdWlyZW1lbnRzIGlzIHdoZXRoZXIgTkJDIGNoYW5nZXMg c2hvdWxkIGJlIGFjY2VwdGVkLiBNYW55IHBlb3BsZSBzZWVtIHRvIHRoaW5rIHNvLCBpZiB5b3Ug ZG9u4oCZdCBhZ3JlZSB0aGF04oCZcyBmaW5lLCBidXQgSSBkaXNhZ3JlZSB3aXRoIHRoZSBjbGFp bSB0aGF0IHRoZSByZXF1aXJlbWVudHMgYXJlIHJldmVyc2UgZW5naW5lZXJlZCBmcm9tIHRoZSBz b2x1dGlvbiwgSSBiZWxpZXZlIHRoZSBkZXNpZ24gdGVhbSBoYXMgc3RyaXZlZCB0byBzZXBhcmF0 ZSB0aGUgMi4NCg0KUmVzaGFkLg0KDQpXZSBlbmQgdXAgaGF2aW5nIHRoZSBzYW1lIGRlYmF0ZXMg dHdpY2UuDQoNCkl0IGlzIHVzdWFsbHkgd29yc2UgdGhlbiB0aGF0LCBzaW5jZSB5b3UgZW5kIHVw IGRlYmF0aW5nIHRoZSB3b3JkaW5nIGluIHRoZSByZXF1aXJlbWVudHMNCmluc3RlYWQgb2YgdGhl IG1lcml0cyBvZiB0aGUgc29sdXRpb24taW4tcHJvZ3Jlc3MgKGNvbnNpZGVyaW5nIGFsbCBmYWN0 b3JzIGFuZCByZWFkanVzdGVkIHJlcXVpcmVtZW50cykuDQoNCg0KS2VudA0KDQpBbmR5DQoNCg== --_000_516900C088C24D91991AF7E9F8B824D6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <974082BABD9A0549B4D561A2B140D475@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2Vz QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJ0FuZHkgQmllcm1hbicgJmx0O2FuZHlAeXVtYXdv cmtzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBNYXJjaCAyNCwgMjAxOSBhdCA5 OjU5IFBNPGJyPg0KPGI+VG86IDwvYj5LZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRz ZW4ubmV0Jmd0Ozxicj4NCjxiPkNjOiA8L2I+TmV0TW9kIFdHICZsdDtuZXRtb2RAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbmV0bW9kXSBhZG9wdGlvbiBwb2xsIGZvciB5 YW5nLXZlcnNpb25pbmctcmVxcy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBNYXIgMjQsIDIwMTkgYXQgMTo0 NSBQTSBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5u ZXQiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpIaSBBbmR5LDxicj4NCjxicj4NCiZndDsgQW5keSBCaWVy bWFuIHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBCVFcsIEkgZG8gbm90IHN1cHBvcnQgYWRv cHRpb24gb2YgdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBhdCBhbGwuPGJyPg0KPGJyPg0KQ2Fu IHlvdSBzYXkgd2h5PyZuYnNwOyAmbmJzcDtJcyBpdCBhIGJsYW5rZXQgc3RhdGVtZW50IGFib3V0 IGFkb3B0aW5nIHJlcXVpcmVtZW50cyBkcmFmdHMgaW4gZ2VuZXJhbCwgb3Igc29tZXRoaW5nIHNw ZWNpZmljIHRvIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIHRoZXkganVzdCB3YXN0ZSB0aW1lLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhleSBh cmUgbW9zdGx5IHJldmVyc2UgZW5naW5lZXJlZCBmcm9tIHRoZSBkZXNpcmVkIHNvbHV0aW9uIChi eSB0aGUgYXV0aG9ycykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtSUiZndDsgSSBkb27i gJl0IHRoaW5rIHdl4oCZcmUgdGllZCB0byB0aGUgc29sdXRpb24gb2Ygc2VtdmVyIG9yIG1vZGlm aWVkIHNlbXZlciAoc3BlYWtpbmcgZm9yIG15c2VsZiBhdCBsZWFzdCkuIFRoZSBtYWluIHF1ZXN0 aW9uIG9uIHRoZSByZXF1aXJlbWVudHMgaXMgd2hldGhlciBOQkMgY2hhbmdlcyBzaG91bGQgYmUg YWNjZXB0ZWQuIE1hbnkgcGVvcGxlIHNlZW0gdG8gdGhpbmsgc28sIGlmIHlvdSBkb27igJl0IGFn cmVlDQogdGhhdOKAmXMgZmluZSwgYnV0IEkgZGlzYWdyZWUgd2l0aCB0aGUgY2xhaW0gdGhhdCB0 aGUgcmVxdWlyZW1lbnRzIGFyZSByZXZlcnNlIGVuZ2luZWVyZWQgZnJvbSB0aGUgc29sdXRpb24s IEkgYmVsaWV2ZSB0aGUgZGVzaWduIHRlYW0gaGFzIHN0cml2ZWQgdG8gc2VwYXJhdGUgdGhlIDIu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlc2hhZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2UgZW5kIHVwIGhhdmluZyB0aGUgc2FtZSBkZWJhdGVzIHR3aWNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBp cyB1c3VhbGx5IHdvcnNlIHRoZW4gdGhhdCwgc2luY2UgeW91IGVuZCB1cCBkZWJhdGluZyB0aGUg d29yZGluZyBpbiB0aGUgcmVxdWlyZW1lbnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnN0ZWFkIG9mIHRoZSBtZXJpdHMgb2YgdGhlIHNvbHV0 aW9uLWluLXByb2dyZXNzIChjb25zaWRlcmluZyBhbGwgZmFjdG9ycyBhbmQgcmVhZGp1c3RlZCBy ZXF1aXJlbWVudHMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+S2VudDxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_516900C088C24D91991AF7E9F8B824D6ciscocom_-- From nobody Sun Mar 24 15:54:17 2019 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 88D8712016B for ; Sun, 24 Mar 2019 15:54:15 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CMjpH04xwnz1 for ; Sun, 24 Mar 2019 15:54:13 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 0243F120183 for ; Sun, 24 Mar 2019 15:54:12 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id f18so6134743lja.10 for ; Sun, 24 Mar 2019 15:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jNVyl3kaXiuOSQFLU/yVQztY3Rqy7XKj219ICEdfPi0=; b=cDutdEAiEZhRfOadoQJAsRGJ2BarrP+JEHEP50bB0IBONeronJ4pG5aD8S1NHF6K7G Eg3qaxqbi+HUrTIIeiAk9k6axLQdvsnQ2ot/IX2PONUWgqIO1+I0BMSABzY2l/F5OUuN ffe6QCT12FJXPWsopJ3/GNMR1tgVbjnOS11NehzJLhK0AEjlR0bSYH4rNjI0zTxDftik OK2TAHaKKQx0yQRp1nI7T0T7o/gcFafUc/3Jo/OkJHf1J2f15wpuC9R5Z+znXvWIExO3 bSSz2EoBfQypKPBCuGO1MksL5JIUBo8EA9EGvJ0vUh+Io4R2EHm6RPhecaSeBPFbrnm5 k9Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jNVyl3kaXiuOSQFLU/yVQztY3Rqy7XKj219ICEdfPi0=; b=jn2gkaS+ybjOR3CIRWFr0wCeAPBMgAOd09WW/PScmoAbVlEf+xsYJza/u934SH/+br abcpuzatzJCavI/RCoMUp0SdamrgEedScyUvim3YEo+PLFfZuvfy2jvDTDgMycnQufiN aag6cgviACXBkCdlNKJNzQ7z3AmrlAB58k/0SXQpWhSUI+QuMeNS5M7GgRdwr0rdIvUu WgJtVXHUz6edTA5LeS99TIBSUt4QQFV1M+r5ywq4/C1/1kL/PyQIzNg3YSpaBevvt1VW HzaSEz4hi8TmVBEmrvyUWNhkgfnKnX5GAmrVjrqqg/NvLLhG4g7fDDOD3PSnBcQqTXKG cM9Q== X-Gm-Message-State: APjAAAUX3yVMO6PrqZFTTOpWLfVq68/XEIcPlnywYuovdzAuqNOxctg4 tiO2un3TqwHKLcP3NLC0QXxfqNLcR/nRQQRL1Y5bEw== X-Google-Smtp-Source: APXvYqzmvdKGxnL083AR+BJnnqX6JimCbFkT8UZhc5r7SbXDus6Dv0gxQVhypwn0KTq7wYnON7J2PdY6phvAnr8HuF4= X-Received: by 2002:a2e:b045:: with SMTP id d5mr11445494ljl.12.1553468051142; Sun, 24 Mar 2019 15:54:11 -0700 (PDT) MIME-Version: 1.0 References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> <01000169b1732722-f41ea67f-9c6e-4ec4-a6f2-90e340b4d7a4-000000@email.amazonses.com> <516900C0-88C2-4D91-991A-F7E9F8B824D6@cisco.com> In-Reply-To: <516900C0-88C2-4D91-991A-F7E9F8B824D6@cisco.com> From: Andy Bierman Date: Sun, 24 Mar 2019 15:54:00 -0700 Message-ID: To: "Reshad Rahman (rrahman)" Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="0000000000005bcddb0584def773" Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 22:54:16 -0000 --0000000000005bcddb0584def773 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I don't know what it means to "accept" NBC changes. I agree this is a deviation that could be documented somehow. Andy On Sun, Mar 24, 2019 at 2:47 PM Reshad Rahman (rrahman) wrote: > > > *From: *netmod on behalf of 'Andy Bierman' < > andy@yumaworks.com> > *Date: *Sunday, March 24, 2019 at 9:59 PM > *To: *Kent Watsen > *Cc: *NetMod WG > *Subject: *Re: [netmod] adoption poll for yang-versioning-reqs-02 > > > > > > > > On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen wrote: > > > Hi Andy, > > > Andy Bierman wrote: > > > > BTW, I do not support adoption of the requirements document at all. > > Can you say why? Is it a blanket statement about adopting requirements > drafts in general, or something specific to this draft. > > > > Because they just waste time. > > They are mostly reverse engineered from the desired solution (by the > authors). > > > > I don=E2=80=99t think we=E2=80=99re tied to the solution of semver o= r modified semver > (speaking for myself at least). The main question on the requirements is > whether NBC changes should be accepted. Many people seem to think so, if > you don=E2=80=99t agree that=E2=80=99s fine, but I disagree with the clai= m that the > requirements are reverse engineered from the solution, I believe the desi= gn > team has strived to separate the 2. > > > > Reshad. > > > > We end up having the same debates twice. > > > > It is usually worse then that, since you end up debating the wording in > the requirements > > instead of the merits of the solution-in-progress (considering all factor= s > and readjusted requirements). > > > > > > Kent > > > > Andy > > > --0000000000005bcddb0584def773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I don't know what it means to &= quot;accept" NBC changes.
I agree this is a deviation that c= ould be documented somehow.

Andy


On Sun, Mar 24, 2019 at 2:47 PM Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

=C2=A0

From: = netmod <netmod-bounces@ietf.org<= /a>> on behalf of 'Andy Bierman' <andy@yumaworks.com>
Date: Sunday, March 24, 2019 at 9:59 PM
To: Kent Watsen <kent+ietf@watsen.net>
Cc: NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

=C2=A0

=C2=A0

=C2=A0

On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen <kent+ietf@watsen.ne= t> wrote:


Hi Andy,

> Andy Bierman wrote:
>
> BTW, I do not support adoption of the requirements document at all.
Can you say why?=C2=A0 =C2=A0Is it a blanket statement about adopting requi= rements drafts in general, or something specific to this draft.

=C2=A0

Because they just waste time.

They are mostly reverse engineered from the desired = solution (by the authors).

=C2=A0

<RR> I don=E2=80=99t think we=E2=80=99re tied = to the solution of semver or modified semver (speaking for myself at least)= . The main question on the requirements is whether NBC changes should be ac= cepted. Many people seem to think so, if you don=E2=80=99t agree that=E2=80=99s fine, but I disagree with the claim that the requirements a= re reverse engineered from the solution, I believe the design team has stri= ved to separate the 2.

=C2=A0

Reshad.

=C2=A0

We end up having the same debates twice.

=C2=A0

It is usually worse then that, since you end up deba= ting the wording in the requirements

instead of the merits of the solution-in-progress (c= onsidering all factors and readjusted requirements).

=C2=A0

=C2=A0

Kent

=C2=A0

Andy

=C2=A0

--0000000000005bcddb0584def773-- From nobody Mon Mar 25 00:03:21 2019 Return-Path: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@amazonses.watsen.net> 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 83425120360 for ; Mon, 25 Mar 2019 00:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 XU_TFCF29Smr for ; Mon, 25 Mar 2019 00:03:17 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9812120353 for ; Mon, 25 Mar 2019 00:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553497395; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=jzHeKjXh7TEjOs07yC6bwffMMq6C4SFMVD3tHm/SGJA=; b=jCFhbL6RTqXwkhzsU/nGAS9ApPaHcgdf5t22FblyxNu1cPmqVKR5pvj4qq2SzyyQ ckbfdM5h4dt6gOKv12znfYc4bXJ4KL1+rbLvi1i0UHbqOUi4Q4W7/VP1goL4yIqymqp aVCMO6EVM99vGC8AR1CmYCdFWhPNd9QghyyqMCS4= From: Kent Watsen Content-Type: multipart/alternative; boundary=Apple-Mail-FDA390A7-954E-47C1-853D-7F3C42EFBA89 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 25 Mar 2019 07:03:15 +0000 Message-ID: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@email.amazonses.com> To: netmod@ietf.org X-Mailer: iPad Mail (16D57) X-SES-Outgoing: 2019.03.25-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 07:03:20 -0000 --Apple-Mail-FDA390A7-954E-47C1-853D-7F3C42EFBA89 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The Abstract says =E2=80=9Cre-using the same format as the reply to a o= peration/request=E2=80=9D. At first, I was going to suggest replacing = with , but I question if this is correct since the draft supports= JSON, which neither NETCONF RPC is able to return.=20 The Terminology section is missing an entry for =E2=80=9Cinstance data set=E2= =80=9D.=20 I don=E2=80=99t understand what P3 means. Add info text to draft. Re: P4, if file =3D=3D 1 =E2=80=9Cset=E2=80=9D, then the distinction becomes= unclear (see earlier comment about missing =E2=80=9Cset=E2=80=9D term). I u= nderstand that it=E2=80=99s intended to mean instance data for a set of modu= les but, if there=E2=80=99s a 1:1 relationship between file and set, then ju= st pick one term for the draft. I don=E2=80=99t understand what P7 means. Add more text to draft. Section 3 says this about Content data: =E2=80=9CIt MAY include entity-tags a= nd timestamps as defined in [RFC8040]=E2=80=9D. How is this possible? RFC 8= 040 only returns such data in HTTP headers; there=E2=80=99s no defined encod= ing for putting the data into instance data. Section 3 also says =E2=80=9CIt MAY include an explicit tag for default valu= es as defined in [RFC6243] and [RFC8040]=E2=80=9D. Do you mean, the =E2=80=9Cdefault=E2=80=9D= attribute defined in Section 6 in RFC 6243 and Section 4.8.9 in RFC 8040? T= he text should be more explicit. Section 3 also contains paragraphs beginning with: =E2=80=9CIt MAY include i= mplementation specific metadata.=E2=80=9D and =E2=80=9CIt MAY include imple= mentation specific XML attributes.=E2=80=9D I think these two paragraphs sh= ould be merged and a sentence added noting how metadata is encoded for JSON a= nd XML. s/A single instance data set/An instance data set/ (since already there is o= nly one) Section 3 says: =E2=80=9CInstance data files MAY contain partial data sets. T= his means mandatory, min-elements or require-instance=3Dtrue constrains MAY b= e violated.=E2=80=9D Why? This means validations may fail. Generally, I feel that the part of Section 3 describing the content should b= e replaced with a statement that any valid response for or GET on= a top-level resource is okay. If this is not the case, then the draft shou= ld still start with this statement and them list out any exceptions. =E2=80=9CMetadata=E2=80=9D is a general term, please use another term in Sec= tion 3, or spell out what is intended. BTW, there isn=E2=80=99t a node in t= he YANG module called =E2=80=9Cmetadata=E2=80=9D, leading the extra confusio= n. Where is the tree diagram? All drafts defining YANG modules should include a= YANG tree diagram for each module.=20 Actually, reverting on my comment above, I recommend replacing Section 3 wit= h the familiar 3-tuple: tree-diagram, example, YANG module. In particular, I= would delete all the text that can be described (and better at that) by the= YANG module. This eliminates duplication of content, which is both less to= read and eliminates possibly conflicting information. Stopping my review before section 3.1. Kent // contributor=20 --Apple-Mail-FDA390A7-954E-47C1-853D-7F3C42EFBA89 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The Abstract says =E2=80=9Cre-using the same format as the&= nbsp;reply t= o a <get> operation/request=E2=80=9D.  At first, I was going to s= uggest replacing <get> with <get-data>, but I question if this i= s correct since the draft supports JSON, which neither NETCONF RPC is able t= o return. 

The Terminology section is missing= an entry for =E2=80=9Cinstance data set=E2=80=9D. 

I don=E2= =80=99t understand what P3 means.  Add info text to draft.
Re: P4, if file =3D=3D 1 =E2=80=9Cset=E2=80=9D, then the distin= ction becomes unclear (see earlier comment about missing =E2=80=9Cset=E2=80=9D= term).  I understand that it=E2=80=99s intended to mean instance data f= or a set of modules but, if there=E2=80=99s a 1:1 relationship between file a= nd set, then just pick one term for the draft.

I don=E2=80=99t unders= tand what P7 means.  Add more text to draft.

Section 3 says this abo= ut Content data: =E2=80=9CIt MAY include entity-tags and timestamps as defin= ed in [RFC8040]=E2=80=9D.  How is this possible?  = RFC 8040 only returns such data in HTTP headers; there=E2=80=99s no defined e= ncoding for putting the data into instance data.

= 
Section 3 also says =E2=80=9CIt MAY include an expli=
cit tag for default values as defined in
      [RFC6243] and [RFC8=
040]=E2=80=9D.   Do you mean, the =E2=80=9Cdefault=E2=80=9D at=
tribute defined in Section 6 in RFC 6243 and Section 4.8.9 in RFC 8040? &nbs=
p;The text should be more explicit.
<=
br>
<=
font face=3D"UICTFontTextStyleTallBody">Section 3 also contains paragraphs=
 beginning with: =E2=80=9CIt MAY include implementation specific metadata.=E2=
=80=9D  and =E2=80=9CIt MAY include implementation specific XML attributes.=E2=80=9D  =
I think these two paragraphs should be merged and a sentence added noting ho=
w metadata is encoded for JSON and XML.

s/A single instance data set/An instance data set/=
  (since already there is only one)

Section 3 says: =E2=80=9CIns=
tance data files MAY contain partial data sets.  This means mandatory, min-elements or req=
uire-instance=3Dtrue constrains MAY be
   violated.=E2=80=9D  Why?  This means validations may fail.

Generally, I f=
eel that the part of Section 3 describing the content should be replaced wit=
h a statement that any valid response for <get-data> or GET on a top-l=
evel resource is okay.  If this is not the case, then the draft should s=
till start with this statement and them list out any exceptions.

=E2=80=9CMetadata=E2=80=9D is a general term,=
 please use another term in Section 3, or spell out what is intended.  =
BTW, there isn=E2=80=99t a node in the YANG module called =E2=80=9Cmetadata=E2=
=80=9D, leading the extra confusion.
=

=
Where is the tree diagram?  =
;All drafts defining YANG modules should include a YANG tree diagram for eac=
h module. 

Actually, reverting=
 on my comment above, I recommend replacing Section 3 with the familiar 3-tu=
ple: tree-diagram, example, YANG module.  In particular, I would delete=
 all the text that can be described (and better at that) by the YANG module.=
  This eliminates duplication of content, which is both less to read an=
d eliminates possibly conflicting information.

Stopping my review before section 3.1.

Kent // contributor 

<=
/span>
= --Apple-Mail-FDA390A7-954E-47C1-853D-7F3C42EFBA89-- From nobody Mon Mar 25 03:42:18 2019 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 30696120395 for ; Mon, 25 Mar 2019 03:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 z4xxbWhRn_py for ; Mon, 25 Mar 2019 03:42:14 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E43120394 for ; Mon, 25 Mar 2019 03:42:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CA4D03D for ; Mon, 25 Mar 2019 11:42:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id L7AFRjAQDr3X for ; Mon, 25 Mar 2019 11:42:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 25 Mar 2019 11:42:12 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5FFD200A7 for ; Mon, 25 Mar 2019 11:42:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id KAT6pSVn8pM7 for ; Mon, 25 Mar 2019 11:42:12 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7F920200A6 for ; Mon, 25 Mar 2019 11:42:12 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 25 Mar 2019 11:42:12 +0100 Received: by anna.localdomain (Postfix, from userid 501) id B538330077D65F; Mon, 25 Mar 2019 11:42:11 +0100 (CET) Date: Mon, 25 Mar 2019 11:42:11 +0100 From: Juergen Schoenwaelder To: Message-ID: <20190325104211.hwmegn4yhijd5esj@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: [netmod] leaving netmod version design team X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 10:42:16 -0000 Hi, some people know that I have been in the netmod version design team. I joined the design team in order to help working out the requirements and I have also contributed some concrete text to the requirements document. I tried to help phrasing requirements such that the requirements are not favoring a specific solution (we will have to discuss whether we succeeded or whether there are still places where a certain solution is presumed). I have not contributed to the semver solution documents and there are aspects of the solution documents I do not agree with. Given that the requirements are now a WG document and I did not contribute to the "design team's solution", I think it is the right moment in time for me to leave the design team. /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 Mar 25 04:22:42 2019 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 A12FD1203B9; Mon, 25 Mar 2019 04:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Cs7s_yWPAve7; Mon, 25 Mar 2019 04:22:32 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20054.outbound.protection.outlook.com [40.107.2.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F99B120390; Mon, 25 Mar 2019 04:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AHeNbEgbbUhkOgOvdgzF1k8hikHpEcEq2WLHsyEYeFk=; b=JD9fJyJBD9mgVXQuxSYdRUv14kfOctZNRvhH4WR6vixpmtnwlvfMazHmFpYDeCEGypk3TRtfJhbhFFbW55V70nTRfvm+YYZ2vAjOv5dSpTMcTXHCuLUCkRLhFt0uo2CtWR5OTFc1b+GXJr/XSU5OHpJ2O3ChMoVPNbeOmj4J9dc= Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB5431.eurprd07.prod.outlook.com (20.178.88.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 11:22:28 +0000 Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 11:22:28 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Joel Jaeggli CC: NetMod WG , "netmod-ver-dt@ietf.org" Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02 Thread-Index: AQHU4v0HhsWz4a2SB0O3/IV6GxqqIA== Date: Mon, 25 Mar 2019 11:22:28 +0000 Message-ID: <35ba2574-7974-791f-3de8-27f32eecf7cb@ericsson.com> References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:90ab:af5c:5e62:e8f6] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 x-clientproxiedby: AM6PR0502CA0037.eurprd05.prod.outlook.com (2603:10a6:20b:56::14) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15f772b2-db93-4bc6-c740-08d6b11429de x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5431; x-ms-traffictypediagnostic: AM6PR07MB5431: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(136003)(376002)(346002)(199004)(189003)(8936002)(25786009)(58126008)(486006)(54906003)(86362001)(6512007)(110136005)(54896002)(8676002)(5070765005)(81156014)(6506007)(81166006)(64126003)(236005)(31696002)(316002)(11346002)(46003)(106356001)(446003)(478600001)(2616005)(85202003)(6246003)(99286004)(14454004)(105586002)(93886005)(7736002)(99936001)(476003)(53936002)(2906002)(186003)(85182001)(229853002)(6116002)(65956001)(65826007)(65806001)(52116002)(6486002)(14444005)(256004)(31686004)(68736007)(5660300002)(4326008)(36756003)(97736004)(71200400001)(71190400001)(6436002)(102836004)(76176011)(386003)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5431; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hRKJbIe9tRSbc5u2P4Fs7drByJo/VO6WhOLSRFXCwCIoCiCgwIPy5UxyY8Z3D+xnQIQ4lvjdSbAu1Mk8eg/Oz/YFyC0B9npKwBZuxOBgBimEATckX9ZZ7QjRQmgiRw+tFkIATBLfEQEkBC/DFEan/NvC9hMIIuY/XXXFJKBAMAmXLnVCIfRj/1wcd1LIMzZAT68pLW5efcTGlhS7PGMLKTnbxxW+dYG+fiW8e2IlNINA8HA0p/lET4LcLY+khkiwr3YmEIVVYBtnSDHJk69vs2ar0fP7OfrZgrHcbUlJj0GfhjVMdWeMGZ3dg0a0wuFbCmYqgGdqFlHUvQZy12EpXMaPQAE/avp0t6CVFNvs6tazyZU3qcxpXmfjk8beN6OyBRvErPfhQKWvMnWd3Kj0uP9LqiNy7SpfF/pNw4jwTB0= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060400030400000509090502" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15f772b2-db93-4bc6-c740-08d6b11429de X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 11:22:28.2574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5431 Archived-At: Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 11:22:34 -0000 --------------ms060400030400000509090502 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable


On 2019. 03. 24. 21:05, Andy Bierman wrote:


On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <joelja@bogus.com> wrote:


On Mar 22, 2019, at 12:07, Lou Berger <lberger@labn.net> wrote:

Hi,

Thank you all for the good input on this thread.

With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.

It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.

Authors,

Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.=C2=A0 The -01 version should focus on resol= ving issues raised during adoption.=C2=A0 Of course th= e document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.

I think this meeting is great opportunity to decide what steps need to be taken to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible changes.=C2=A0

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 revision rules. So that cat may be out of the bag at least with respect to the real world. the question remains what to do about that?



I do not look at the problem as allowing NBC so much as making it clear to toolmakers what is going on,
like a deviation to the versioning rules.

BTW, I do not support adoption of the requirements document at all.
I support the work on versioning as part of the charter, and I am happy to
accept the design team solution draft as the starting point, and just work on a solution.

But I think the solution is a bit flawed.

1) extensions are optional and problematic since they can be revisioned without changing
=C2=A0 =C2=A0 the language version; the solution needs to = use new YANG 1.2 statements instead of extensions

2) the version string does not have to contain all the NBC semantics.
The solution draft does not show modified semver.
It should be done differently than overloading the version string;

Let's say a fork is done on 1..3.0.
        =
 revision 2017-07-30 {
           description "Added leaf foo-64";
           semver:module-version "1.3.0";
         }

start wi=
th a legal change, just not at the HEAD
        =
 revision 2019-01-10 {
           description "Added leaf bar-64";
           semver:module-version "1.3.1";
         }

            
then lat=
er, an NBC change

            
        revision 2019-02-10 {
           description "Changed leaf bar-64 default-stmt";
           semver:module-version "1.3.2";
           semver:nbc-change;
  =
       }

            
then later, a legal change
        revision 2019-03-10 {
           description "Added leaf baz-64";
           semver:module-version "1.3.3";

<=
span style=3D"white-space:pre-wrap">         }
This is a form of an inli=
ne deviation-stmt.
The YANG update rules are not changing. They are just not being followed.=

The NBC info belongs in the revision-stmt, not overloading the version st=
ring.
Not every major revision will mean NBC changes anyway.

            
Andy
          

        

      

    

    BALAZS: This would not work. Lets say we have 3 versions of a model
    1, 2 and 3. 

    Between 1->2 there is an NB C change (non-backward compatible.
=

    Between 2->3 there is a BC change.
    
We have a server that only implements ver-3. As the last change
      was backward compatible ver-3 does not contain semver:nbc-change=
;

      So if the client-A used ver-2 previously it will get the correct
      information: change is BC

      However if the client-B used ver-1 previously it will get
      INCORRECT information.

    
If you say that the semver:nbc-change;is sticky and ver-3
      contains semver:nbc-change; client-A gets wrong
      information, it believes the change is NBC while it was BC.

    
The problem is that the server does not know which is the
      "previous" model version for the client, and backwards
      compatibility info is needed between the two model-versions the
      client is using.

    
If we connect compatibility to the version number as we propose
      this problem is solved.

    

    
regards Balazs

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms060400030400000509090502
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTExMjExOVow
LwYJKoZIhvcNAQkEMSIEIGs8/c+2XpOZ8jI0SKHtaOsZ73JEs1c1M8XIRCXZBxRgMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBALMrs0Q5NR0c95xV1PEL0FOyagI1IuYQ6Fk5Zhcq7UgHU65o
+dTkvfZbY5sM3DAkeuYBm8RwkX2NbhK7DOJGfLFGwR9cOKUGw3koZVWsp3QHQuHJc6JHmWTo
YKgO9XThlPb2YJAxtsXDbo/+PqGU9f5xMJbjzja06DBU1vdKDTHpLu+6/EEOumL9nrmxbyqB
qoZu8jMieqLJBixUY7hUlLjOKG30YFg1dm+62L4wg80bzAmAOGvAsw2pZTwEUXlsRYIBnr1R
8QHDaqiVnzQChDC5aihRY1YbzYAElv52jyHG5aQhpJ3z9Y4NDmO2U+zaJTI9RxoWnFtqJECZ
gbWUZ7AAAAAAAAA=

--------------ms060400030400000509090502--


From nobody Mon Mar 25 05:19:18 2019
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 A231A1203EF for ; Mon, 25 Mar 2019 05:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 9X7DjMvaR7zJ for ; Mon, 25 Mar 2019 05:19:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E481203E3 for ; Mon, 25 Mar 2019 05:19:10 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id B631163449 for ; Mon, 25 Mar 2019 13:19:07 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553516347; bh=DPpUZRo+p2dniAIaiX4xNiX+TE9p3Z5A1B0QEid/oxY=; h=From:To:Date; b=Y4DRv0xsjePchJ8BZE9h6x/+nPLClpxq97WSf/PLU4kunKMyD5s6el3CqdGLhPc7Q PZMWqH9Y+sueF00vhWX+b2G5wsPArISYDMnDdyG86Ki6Oh1ZFV2DtbMdRdcE52Iam3 sI3pDkpVkZpHziY0W4j0qBksATYqRllDIXvthp1s=
Message-ID: 
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Mon, 25 Mar 2019 13:19:07 +0100
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] unblocking semver
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 12:19:13 -0000

Hi,

after today's discussion about semver, I am even more convinced that the
following two steps could unblock the current situation:

1. Remove sec. 11 from 7950bis, and publish it as a separate RFC addressing only
to the IETF process. After that, nobody can a priori reject non-compatible
changes as illegal in YANG.

2. Introduce critical extensions (issue #49 in yang-next [*]) and develop semver
as a critical extension. Communities that need it can then use it (with special
tools), and those that don't can keep using the old revisions, or even develop
something else.

I am aware that this means some fragmentation of YANG but it may happen anyway
(see OpenConfig). The problem with uncoordinated forks is that they may
eventually deviate from standard YANG in other aspects where some agreement
could in fact be found.

Lada

[*] https://github.com/netmod-wg/yang-next/issues/49  
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Mar 25 06:04:39 2019
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 7760C120465 for ; Mon, 25 Mar 2019 06:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 HngaDpZ403Aj for ; Mon, 25 Mar 2019 06:04:25 -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 471DA12043B for ; Mon, 25 Mar 2019 06:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3415; q=dns/txt; s=iport; t=1553519065; x=1554728665; h=from:to:subject:date:message-id:mime-version; bh=RihIi60YfHKJhDXeczfl97Jyw/Gs46/7nJcU7xhtqoA=; b=HhcunE/CLVWTNVrmoUYvR5z2BBu5U46DR8NmKjBFiVTjWERWTbRwYJW4 riSumQqdck2RXxa8mYRdrsjLtpev3pLn5sb02hys9qIFi/y9yUgBGg7Qk 1sVUS5SvNHzxJSdWEbwCgvuDMksqq4DiqEaR/6TUdYfqjUpJ11XjhcALb I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABk0Zhc/4sNJK1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUgUBAQELAYEOgQJogQMxrBCFd4F7DQEBJYlaIjUIDQEBAwEBCQE?= =?us-ascii?q?DAm0cAQuFfl4BDHQmAQQbgxuBEWQPrzuEMAGFcgWBLwGLMReBQD+HQgICARe?= =?us-ascii?q?HKAOKaIYnlAcJAodhi04hk36LHIYFjSUCERWBLiECNIFWcBWDKIsLhT9Bjzi?= =?us-ascii?q?BHwEB?=
X-IronPort-AV: E=Sophos;i="5.60,256,1549929600";  d="scan'208,217";a="249862446"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 13:04:23 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2PD4N9O009997 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Mar 2019 13:04:23 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Mar 2019 08:04:22 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 25 Mar 2019 08:04:23 -0500
From: "Rob Wilton (rwilton)" 
To: "netmod@ietf.org" 
Thread-Topic: Continued YANG Versioning Discussions
Thread-Index: AdTjCZYfuEarzydIQRCKayTatOiWug==
Date: Mon, 25 Mar 2019 13:04:22 +0000
Message-ID: <270486da1e934de2a6447403a7113897@XCH-RCD-007.cisco.com>
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.61.79.96]
Content-Type: multipart/alternative; boundary="_000_270486da1e934de2a6447403a7113897XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: 
Subject: [netmod] Continued YANG Versioning Discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:04:34 -0000

--_000_270486da1e934de2a6447403a7113897XCHRCD007ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As Lou has just mentioned, anyone who is interested in discussing YANG vers=
ioning is welcome to join the YANG Versioning Design Team tomorrow to conti=
nue discussions.

We are meeting on Tuesday from 4 pm to 6.30 pm in Tyrolka on the mezzani=
ne level.

Thanks,
Rob


--_000_270486da1e934de2a6447403a7113897XCHRCD007ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











As Lou has just mentioned, anyone who is interested =
in discussing YANG versioning is welcome to join the YANG Versioning Design=
 Team tomorrow to continue discussions.


 


We are meeting on Tuesday from 4 pm to 6.30 pm in 
Tyrolka on =
the mezzanine level.


 


Thanks,


Rob


 






--_000_270486da1e934de2a6447403a7113897XCHRCD007ciscocom_--


From nobody Mon Mar 25 06:19:11 2019
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 552F91203F0 for ; Mon, 25 Mar 2019 06:19: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ffQhjR7lTqaf for ; Mon, 25 Mar 2019 06:19:07 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7AC2120381 for ; Mon, 25 Mar 2019 06:19:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 81D5924 for ; Mon, 25 Mar 2019 14:19:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wVfZqyFFZdvG for ; Mon, 25 Mar 2019 14:19:05 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 25 Mar 2019 14:19:05 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44892200A8 for ; Mon, 25 Mar 2019 14:19:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 69SvgEKMpVDB for ; Mon, 25 Mar 2019 14:19:05 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 14AE0200A7 for ; Mon, 25 Mar 2019 14:19:05 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 25 Mar 2019 14:19:04 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 3713F30077DBAF; Mon, 25 Mar 2019 14:19:04 +0100 (CET)
Date: Mon, 25 Mar 2019 14:19:03 +0100
From: Juergen Schoenwaelder 
To: 
Message-ID: <20190325131903.rc2opwhwqgzsdfv2@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: [netmod] instance data new backward compatibility text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:19:09 -0000

Hi,

I am not sure why we have this new section. The notion of backwards
compatibility for instance data is somewhat dubious. There text that
is there now is potentially even harmful or it needs to be ignored. If
I dump datastore content into an instance file, I get what I get. The
text that is there may help with maunally edited instance files but
this is where it ends. My proposal is to simply drop section 6 again.

/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 Mar 25 06:30:01 2019
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 75B2E1203E7 for ; Mon, 25 Mar 2019 06:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 BNgkj9RQQ4vX for ; Mon, 25 Mar 2019 06:29:58 -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 E5BAA120381 for ; Mon, 25 Mar 2019 06:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=908; q=dns/txt; s=iport; t=1553520597; x=1554730197; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=FjtLvkfOglKGFTqHW8X1BJeLFLMp3p6zC71aYCQMLLI=; b=T6E1mm3NnK8lJ3zppfswNUqXIZ+yeyN6rklGYh4JNKNzCwQGgDhISeKP WoUhtkeH4KQD0FuVeDBLFw7O7iVsK823Wv4ajs/ACHqdRdsPrH2EpehCj UJrjTpOGsnN4b7eOHbQovXRf8mhYbTQQ4yMuCLSYZU0tGdOIk7CBTo52t w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAAAQ15hc/5BdJa1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAQBAQsBghBrTTOENZUdmmIPigAiNwYNAQEDAQEJAQMCbR0LhXQPAXs?= =?us-ascii?q?CJgJfDQgBAYMegXafL454gS+KKIELJAGLMReBQD+BOII2B4g6glcDjEGYVQm?= =?us-ascii?q?CAZEyBhmLJIhaixyTUoFjIoFWTSMVgyiCFReOOiMDkFYBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208";a="539520275"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 13:29:56 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id x2PDTtdm004537 for ; Mon, 25 Mar 2019 13:29:56 GMT
To: "netmod@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
Date: Mon, 25 Mar 2019 09:29:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: 
Subject: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:29:59 -0000

First, I agree with Jürgen that the "target" terminology confused me,
especially so given you have target-module and inline-target-spec.  Like
Jürgen and Rob said, "schema" seems to work better.  And maybe
"inline-schema-module-spec" would be clearer that the spec modifies the
modules from which the schema is generated.

To the point about yang-data-ext/structure, I see instance data was very
useful, but it's a must to be able to augment its metadata.  YANG
Catalog would use that.  If this draft moves forward without
sx:structure, then I think it would need to be straight YANG so that
augments will work (i.e., a schema element would exist to augment).

A few other comments (minor):

Section 2.1:

"P2 Re-use existing formats similar to the  operation/request"

Isn't the format similar to a  _response_ versus the request?

===

Section 3

s/and and/and/

Joe


From nobody Mon Mar 25 06:37:21 2019
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 3AB29120381 for ; Mon, 25 Mar 2019 06:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.503
X-Spam-Level: 
X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=H6YsrMOa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EMRZBtt6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yMBsxJGDYau for ; Mon, 25 Mar 2019 06:37:10 -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 9783F12038C for ; Mon, 25 Mar 2019 06:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2012; q=dns/txt; s=iport; t=1553521030; x=1554730630; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lSFo0rdhdu4R2lcbnmZZYiBQrdB7k4F8oE1bBBhnhV4=; b=H6YsrMOaoPNgxAElIc3I9/mVvhuiA0XyXL2rM5aVv9Ccrd0MOSoSFlOh eJFWnROsOdV28mGAZGER5lxFvK2MYsKpq1k5yedj1/jHLooYdOkDW0tDI IrTj3Xywuz4rR+s4Y/5L3lXkDVAIJL03KCEJc/IL2pYS/bLC0pSKbECFa A=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aa56nLxdYKVqmcYEt67srSMrllGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAABG2Jhc/4oNJK1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2h0BAsnCoQEg0cDhFKKV4IylzGBLoEkA1QNAQEYCwm?= =?us-ascii?q?DekYCF4R7IjQJDQEBAwEBCQEDAm0cDIVLAgQBASERDAEBLAwPAgEIGgImAgI?= =?us-ascii?q?CJQsVEAIEARKDIgGBXQMVAQIMow4CihRxgS+CeAEBBYJHgjYYggwDBYELJAG?= =?us-ascii?q?LMReBQD+BOAwTghcHLj6CYQEBgWEXgnMxgiaMRC+YJgkCkzcZk36LHJMqAgQ?= =?us-ascii?q?CBAUCDgEBBYFNOIFWcBU7KgGCQYIKDBeDS4UUhT9ygSiNXwGBHgEB?=
X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208";a="539523443"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 13:37:09 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2PDb9aZ023733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Mar 2019 13:37:09 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Mar 2019 08:37:08 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Mar 2019 09:37:08 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 25 Mar 2019 08:37:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lSFo0rdhdu4R2lcbnmZZYiBQrdB7k4F8oE1bBBhnhV4=; b=EMRZBtt6d104mVckZVVtNVu6ue1E3L2lhYV3a6EpY5yD4NhbT/FXZgnEGbHey6wKWi2RiChURSn7YJwyB16iO7O5yOOvFEs+nLphJ9PrzzM1GWnb0KAS8IkWXlXoTaLeYW9CkGlkD9GYvLzejbS9Bi1bOjDGlEKJEpplz9Lp++4=
Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3856.namprd11.prod.outlook.com (20.178.251.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Mon, 25 Mar 2019 13:37:01 +0000
Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1730.019; Mon, 25 Mar 2019 13:37:01 +0000
From: "Reshad Rahman (rrahman)" 
To: "Joe Clarke (jclarke)" , "netmod@ietf.org" 
Thread-Topic: [netmod] Comments on instance data draft rev -02
Thread-Index: AQHU4w72B4h41eMW9Ea7hYSZb+NIq6YcakmA
Date: Mon, 25 Mar 2019 13:37:00 +0000
Message-ID: <61E39ECE-7358-47CA-9D78-26C5C33853FB@cisco.com>
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
In-Reply-To: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a27842c9-dd00-4d84-8fa5-08d6b126f5d1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3856; 
x-ms-traffictypediagnostic: MN2PR11MB3856:
x-ms-exchange-purlcount: 1
x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(366004)(136003)(199004)(189003)(66574012)(186003)(8676002)(8936002)(102836004)(99286004)(6486002)(97736004)(66066001)(7736002)(81156014)(53936002)(478600001)(105586002)(2501003)(81166006)(83716004)(966005)(446003)(2616005)(486006)(476003)(5660300002)(14454004)(26005)(229853002)(86362001)(11346002)(82746002)(76176011)(25786009)(2906002)(256004)(14444005)(58126008)(316002)(68736007)(6506007)(36756003)(110136005)(33656002)(6246003)(305945005)(71200400001)(71190400001)(6436002)(106356001)(6116002)(3846002)(6306002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3856; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: l9ocgTuBH1yYVxBhJMH/6/GPjU12t2KGirTqwlIWJf2nKoTmrwvdvEPav3IVq1XQ5n80aJFOEuYa76kripX6lQfq2JwQHMzoB9xIdy0A6IT7pDqkobDmAm7R4Zh3CwBECjT+lhp+APQOE6FSRjXVEnh7dXTA0j5QCvWN/p7hRGhJ9ReoAYXPcjmr6YMxJ6Odgnm6ANWtdibBrtmajK4kVNCa9KyJ/HZwVkvKTkkyPy/cPrsCkm8Ph4hWGH+fX5F+s0UzaUhHIMJ23amPG3BpnYoXNsSa5a3c1ivyvUNwZV4HTMDhicvodL4dXiTdx8N7itbgNm6DGprTZINQ0CNWg+zCVReeTAsI3/CFb3Smv08b21lFggWrlcV56/DuWH7++ap0rpAPPUJAb1HTYtHWmwrWIH7DMSAIt9wiRknIBuM=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a27842c9-dd00-4d84-8fa5-08d6b126f5d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 13:37:00.9758 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3856
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:37:13 -0000

KzEgb24gc2NoZW1hLCBhbmQgdGhlIC1wdHIgcGFydCBhZGRlZCB0byBteSBjb25mdXNpb24uDQoN
Ck1pbm9yIGNvbW1lbnQgKHdoaWNoIHRoZSBhdXRob3JzIHByb2JhYmx5IGtub3cgYWxyZWFkeSk6
IHMveWFuZy1kYXRhL3N0cnVjdHVyZS8NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0K77u/T24gMjAx
OS0wMy0yNSwgMjozMCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSm9lIENsYXJrZSIgPG5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqY2xhcmtlQGNpc2NvLmNvbT4gd3JvdGU6
DQoNCiAgICBGaXJzdCwgSSBhZ3JlZSB3aXRoIErDvHJnZW4gdGhhdCB0aGUgInRhcmdldCIgdGVy
bWlub2xvZ3kgY29uZnVzZWQgbWUsDQogICAgZXNwZWNpYWxseSBzbyBnaXZlbiB5b3UgaGF2ZSB0
YXJnZXQtbW9kdWxlIGFuZCBpbmxpbmUtdGFyZ2V0LXNwZWMuICBMaWtlDQogICAgSsO8cmdlbiBh
bmQgUm9iIHNhaWQsICJzY2hlbWEiIHNlZW1zIHRvIHdvcmsgYmV0dGVyLiAgQW5kIG1heWJlDQog
ICAgImlubGluZS1zY2hlbWEtbW9kdWxlLXNwZWMiIHdvdWxkIGJlIGNsZWFyZXIgdGhhdCB0aGUg
c3BlYyBtb2RpZmllcyB0aGUNCiAgICBtb2R1bGVzIGZyb20gd2hpY2ggdGhlIHNjaGVtYSBpcyBn
ZW5lcmF0ZWQuDQogICAgDQogICAgVG8gdGhlIHBvaW50IGFib3V0IHlhbmctZGF0YS1leHQvc3Ry
dWN0dXJlLCBJIHNlZSBpbnN0YW5jZSBkYXRhIHdhcyB2ZXJ5DQogICAgdXNlZnVsLCBidXQgaXQn
cyBhIG11c3QgdG8gYmUgYWJsZSB0byBhdWdtZW50IGl0cyBtZXRhZGF0YS4gIFlBTkcNCiAgICBD
YXRhbG9nIHdvdWxkIHVzZSB0aGF0LiAgSWYgdGhpcyBkcmFmdCBtb3ZlcyBmb3J3YXJkIHdpdGhv
dXQNCiAgICBzeDpzdHJ1Y3R1cmUsIHRoZW4gSSB0aGluayBpdCB3b3VsZCBuZWVkIHRvIGJlIHN0
cmFpZ2h0IFlBTkcgc28gdGhhdA0KICAgIGF1Z21lbnRzIHdpbGwgd29yayAoaS5lLiwgYSBzY2hl
bWEgZWxlbWVudCB3b3VsZCBleGlzdCB0byBhdWdtZW50KS4NCiAgICANCiAgICBBIGZldyBvdGhl
ciBjb21tZW50cyAobWlub3IpOg0KICAgIA0KICAgIFNlY3Rpb24gMi4xOg0KICAgIA0KICAgICJQ
MiBSZS11c2UgZXhpc3RpbmcgZm9ybWF0cyBzaW1pbGFyIHRvIHRoZSA8Z2V0PiBvcGVyYXRpb24v
cmVxdWVzdCINCiAgICANCiAgICBJc24ndCB0aGUgZm9ybWF0IHNpbWlsYXIgdG8gYSA8Z2V0PiBf
cmVzcG9uc2VfIHZlcnN1cyB0aGUgcmVxdWVzdD8NCiAgICANCiAgICA9PT0NCiAgICANCiAgICBT
ZWN0aW9uIDMNCiAgICANCiAgICBzL2FuZCBhbmQvYW5kLw0KICAgIA0KICAgIEpvZQ0KICAgIA0K
ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg
bmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgDQoNCg==


From nobody Mon Mar 25 06:52:14 2019
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 B0516120432 for ; Mon, 25 Mar 2019 06:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7iv3tklGk4Wb for ; Mon, 25 Mar 2019 06:52:05 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7B959120455 for ; Mon, 25 Mar 2019 06:52:04 -0700 (PDT)
Received: from localhost (dhcp-828a.meeting.ietf.org [31.133.130.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 559981AE00A0; Mon, 25 Mar 2019 14:52:02 +0100 (CET)
Date: Mon, 25 Mar 2019 14:52:00 +0100 (CET)
Message-Id: <20190325.145200.336212787973649675.mbj@tail-f.com>
To: jclarke@cisco.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:52:12 -0000

Joe Clarke  wrote:
> First, I agree with J=FCrgen that the "target" terminology confused m=
e,

+1

> especially so given you have target-module and inline-target-spec.  L=
ike
> J=FCrgen and Rob said, "schema" seems to work better.

Since we have "content-data", perhaps use "content-schema"?


And a question:  why is the "name" leaf mandatory?


/martin


> And maybe
> "inline-schema-module-spec" would be clearer that the spec modifies t=
he
> modules from which the schema is generated.
> =

> To the point about yang-data-ext/structure, I see instance data was v=
ery
> useful, but it's a must to be able to augment its metadata.  YANG
> Catalog would use that.  If this draft moves forward without
> sx:structure, then I think it would need to be straight YANG so that
> augments will work (i.e., a schema element would exist to augment).
> =

> A few other comments (minor):
> =

> Section 2.1:
> =

> "P2 Re-use existing formats similar to the  operation/request"
> =

> Isn't the format similar to a  _response_ versus the request?
> =

> =3D=3D=3D
> =

> Section 3
> =

> s/and and/and/
> =

> Joe
> =

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


From nobody Mon Mar 25 06:53:20 2019
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 7C08E120442 for ; Mon, 25 Mar 2019 06:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 ykc6nZ54Y8lk for ; Mon, 25 Mar 2019 06:53:06 -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 78712120421 for ; Mon, 25 Mar 2019 06:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=437; q=dns/txt; s=iport; t=1553521986; x=1554731586; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/dE67ZlKz5p/V/WpmdcaGyTP7Jesb4bT+TintEXcZGA=; b=RnASb2yrXRqvx/KooCmjvPPe2Zt1v7cDh/zOmOEJqCUqroFw8zIoKy7D UyhowO9YstwBtRHGY11vJb3CEAh10I4EQDu03TSp5JY/2FsdgZuuKjQPq KxcFSS6fOB0q8iNo0uz2/Pimp/NTElQq7XMM5kVy83UPxpem03GlO3Kxg Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAAD33Jhc/5tdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIRa00zJ4QOlR4IJZo1D4RsAoUSIjgSAQEDAQEJAQM?= =?us-ascii?q?CbSiFSwEFIw8BRhALDgoCAiYCAlcGDQYCAQGDHoF2rieBL4oogQskizIXgUA?= =?us-ascii?q?/gTgMgioHLj6HToJXA6UWCZMzBhmBcgGJMYhanm6BZCGBVk0jFYMnghYXjjo?= =?us-ascii?q?jAzCQJgEB?=
X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208";a="252287327"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 13:53:05 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x2PDr4EN004629; Mon, 25 Mar 2019 13:53:04 GMT
To: Martin Bjorklund 
Cc: netmod@ietf.org
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com> <20190325.145200.336212787973649675.mbj@tail-f.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <708b5d80-f7be-e501-1944-a7ca8d43d0a4@cisco.com>
Date: Mon, 25 Mar 2019 09:53:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <20190325.145200.336212787973649675.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:53:15 -0000

On 3/25/19 09:52, Martin Bjorklund wrote:
> Joe Clarke  wrote:
>> First, I agree with Jürgen that the "target" terminology confused me,
> 
> +1
> 
>> especially so given you have target-module and inline-target-spec.  Like
>> Jürgen and Rob said, "schema" seems to work better.
> 
> Since we have "content-data", perhaps use "content-schema"?

I like this.  It definitely clarifies things for me.

Joe


From nobody Mon Mar 25 06:54:59 2019
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 D233B120495 for ; Mon, 25 Mar 2019 06:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 zZD8bvgvCLsb for ; Mon, 25 Mar 2019 06:54:52 -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 15AE7120472 for ; Mon, 25 Mar 2019 06:54:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1122; q=dns/txt; s=iport; t=1553522092; x=1554731692; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CtEtULu55COwLZfoZJ12UrdbfKwH9AeCiGk1vn+qevE=; b=PH96/M3Lu1OGYxGt7lVJ6He54y4TSdSo8QmoFvcuyseXqpXfQENklRUj 36sif6oy8CvC2D4/2NH8l6XBXCTyQMXV2EC4rAQa+wBIUyWBvCeEQj1g6 E9ZFsaAM9U49UBZFFTXvxT6qSSvX50m2jXKmdSAHxj9hpA7nJJNGeOxns o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAD33Jhc/5BdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCEGtNM4Q1lR4tmjUPhGwChRIiNwYNAQEDAQE?= =?us-ascii?q?JAQMCbR0LhUsBBSMPAVYLGAICJgICVwYNCAEBgx6Bdq4ngS+KKIELJAGLMRe?= =?us-ascii?q?BQD+BOII2By4+hESDCoJXA4xBhGyTaQmTMwYZiySIWosck1KBYyKBVk0jFR6?= =?us-ascii?q?DCoIVF446IwOQVgEB?=
X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208";a="252288038"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 13:54:51 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id x2PDsoa0007136 for ; Mon, 25 Mar 2019 13:54:50 GMT
To: "netmod@ietf.org" 
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <6bd00fc3-191d-755a-b8b2-2129c867f3e2@cisco.com>
Date: Mon, 25 Mar 2019 09:54:49 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 13:54:58 -0000

On 3/25/19 09:29, Joe Clarke wrote:
> First, I agree with Jürgen that the "target" terminology confused me,
> especially so given you have target-module and inline-target-spec.  Like
> Jürgen and Rob said, "schema" seems to work better.  And maybe
> "inline-schema-module-spec" would be clearer that the spec modifies the
> modules from which the schema is generated.
> 
> To the point about yang-data-ext/structure, I see instance data was very
> useful, but it's a must to be able to augment its metadata.  YANG
> Catalog would use that.  If this draft moves forward without
> sx:structure, then I think it would need to be straight YANG so that
> augments will work (i.e., a schema element would exist to augment).
> 
> A few other comments (minor):
> 
> Section 2.1:
> 
> "P2 Re-use existing formats similar to the  operation/request"
> 
> Isn't the format similar to a  _response_ versus the request?
> 
> ===
> 
> Section 3
> 
> s/and and/and/

One other nit I just noticed.  While I appreciate being acknowledged, my
last name has an 'e' at the end: Joe Clarke.  :-)

Joe


From nobody Mon Mar 25 07:14:08 2019
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 7632A12040A for ; Mon, 25 Mar 2019 07:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 K69KP1NHT7Db for ; Mon, 25 Mar 2019 07:14:05 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EDD12040E for ; Mon, 25 Mar 2019 07:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=881; q=dns/txt; s=iport; t=1553523245; x=1554732845; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=o3VIqb3Y/3Ji1ad6JeRdYCzQ0qyE9KS2eZwbfW9EoXs=; b=VwikNgALeGTDSdFvhF359wS58SG/wuvmv4tJrAlmnUzcfdB9QI1xZBhO e3VhLFQSOK9Ax5h7qIAp8CELmuoVi9VjmOFAb0BiNkuo8oLH3HLTPQeI1 RNLM4OXlWtS1w8Iw4rUzlTIVs3HjAECVWo5T3ScKCP1hYnJ05Nu/u1KjC w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAwCv4Zhc/5hdJa1bCRwBAQEEAQE?= =?us-ascii?q?HBAEBgWWCEWtNM4Q1lR4ImHOBZw+KACI4EgEBAwEBCQEDAm0dC4V0DwF7AiY?= =?us-ascii?q?CXw0IAQGDHoF2ny+OeIEviiiBCySLMheBQD+BOAyCKoUNEwGDIIJXA6UWCYI?= =?us-ascii?q?BkTIGAheLJIhaixyTUoFkIYFWTSMVgyiQZiMDkFYBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208";a="321133486"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 14:14:04 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x2PEE3rH017879 for ; Mon, 25 Mar 2019 14:14:03 GMT
To: "netmod@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>
Date: Mon, 25 Mar 2019 10:14:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 14:14:08 -0000

I support the need for being able to reset a DS to its factory default.
However, I have a question on the current design of the model and the
"factory-default" DS.

It seems to me that this is a single DS that might have been intended to
reset running or startup.  However, what if I have different DSes that
each have unique factory default data?  If I choose to extend
factory-default with a new identity of my other DS, how can I indicate
that the target DS will be reset to _that_ DS?  Does that make sense?

Or if I do a  on a factory-default DS, how do I know what
other DSes does this DS pertain?  Perhaps the server will use this to
reset a given DS, but how would a user know that (other than perhaps
naming of the factory-default DS)?

Maybe the module needs a mapping to let the client know what DS will be
used to reset what other DS?

Joe


From nobody Mon Mar 25 07:55:18 2019
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 31B531203EF for ; Mon, 25 Mar 2019 07:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hAltZCKB45qN for ; Mon, 25 Mar 2019 07:55:14 -0700 (PDT)
Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5211203A2 for ; Mon, 25 Mar 2019 07:55:12 -0700 (PDT)
Received: from ex-hc1.corp.adtran.com (ex-hc1.adtran.com [76.164.174.81]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-203-7lT8STrHM26tYxJS4gREbw-1; Mon, 25 Mar 2019 10:55:09 -0400
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0382.000; Mon, 25 Mar 2019 09:55:08 -0500
From: JOEY BOYD 
To: "netmod@ietf.org" 
Thread-Topic: error-message
Thread-Index: AdTSn2llQGSojFl0QmmWuHXdWeKWOQQevguQ
Date: Mon, 25 Mar 2019 14:55:08 +0000
Message-ID: <26CE489EF4611643B3EFE43D06E02654018CCF76FA@ex-mb1.corp.adtran.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.118.104]
MIME-Version: 1.0
X-MC-Unique: 7lT8STrHM26tYxJS4gREbw-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_26CE489EF4611643B3EFE43D06E02654018CCF76FAexmb1corpadtr_"
Archived-At: 
Subject: Re: [netmod] error-message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 14:55:16 -0000

--_000_26CE489EF4611643B3EFE43D06E02654018CCF76FAexmb1corpadtr_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I wanted to follow up on this as I have not received any feedback. I thinki=
ng now that even though it is isn't specifically called out in the update s=
ection, that adding an error-message could be backward compatible as it has=
 no impact on the data or modeled constraint. It merely defines the error r=
esponse which was previously up to the implementation to determine.

Any thoughts on this?

Regards,
Joey

From: JOEY BOYD
Sent: Monday, March 4, 2019 9:37 AM
To: 'netmod@ietf.org' 
Subject: error-message

Hi,

Is the addition of an 'error-message' to an existing 'must' statement consi=
dered backward compatible? I don't see 'error-message' mentioned in the "Up=
dating a Module" section which leads me to believe that it isn't but wanted=
 to double check to see what implications adding one to an existing module =
would have.

Thanks and regards,
Joey


--_000_26CE489EF4611643B3EFE43D06E02654018CCF76FAexmb1corpadtr_
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable











Hi,<=
/p>

 


I wanted to follow up =
on this as I have not received any feedback. I thinking now that even thoug=
h it is isn’t specifically called out in the update section, that add=
ing an error-message could be backward compatible
 as it has no impact on the data or modeled constraint. It merely defines t=
he error response which was previously up to the implementation to determin=
e.


 


Any thoughts on this?<=
o:p>


 


Regards,

Joey


 






From: JOEY BOYD 

Sent: Monday, March 4, 2019 9:37 AM

To: 'netmod@ietf.org' <netmod@ietf.org>

Subject: error-message






 


Hi,


 


Is the addition of an ‘error-message’ to=
 an existing ‘must’ statement considered backward compatible? I=
 don’t see ‘error-message’ mentioned in the “Updati=
ng a Module” section which leads me to believe that it isn’t bu=
t wanted to double
 check to see what implications adding one to an existing module would have=
.


 


Thanks and regards,

Joey


 






--_000_26CE489EF4611643B3EFE43D06E02654018CCF76FAexmb1corpadtr_--


From nobody Mon Mar 25 08:31:10 2019
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 89C1C12038C for ; Mon, 25 Mar 2019 08:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 F56DR3aAwAIb for ; Mon, 25 Mar 2019 08:30:58 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4276C12049D for ; Mon, 25 Mar 2019 08:30:56 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C69C08B2; Mon, 25 Mar 2019 16:30:54 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ZqftXA5D5ryw; Mon, 25 Mar 2019 16:30:54 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Mar 2019 16:30:54 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B18A7200A8; Mon, 25 Mar 2019 16:30:54 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id RFN6OkOpBPKK; Mon, 25 Mar 2019 16:30:54 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5A1F5200A7; Mon, 25 Mar 2019 16:30:54 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 25 Mar 2019 16:30:53 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 682BB30077E1BB; Mon, 25 Mar 2019 16:30:52 +0100 (CET)
Date: Mon, 25 Mar 2019 16:30:52 +0100
From: Juergen Schoenwaelder 
To: Joe Clarke 
CC: "netmod@ietf.org" 
Message-ID: <20190325153052.cb4bu3rjymjpe3ht@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Joe Clarke , "netmod@ietf.org" 
References: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 15:31:06 -0000

The I-D says:

   o  factory-default datastore: A read-only datastore holding a
      preconfigured minimal initial configuration that can be used to
      initialize the configuration of a server.  The content of the
      datastore is usually static, but MAY depend on external factors
      like available HW.

The problem here is the phrase 'can be used to initialize the
configuration of a server'. In terms of the well-known NMDA
datastores, it is not clear whether the content is copied to 
or  or both. Section 2 adds a bit more confusion since it
says:

   Factory-default content SHALL be specified by one of the following
   means in order of precedence

   1.  For the ,  and  datastores as the
       content of the  datastore, if it exists

So do all these configuration datastores receive a 1:1 copy of
? If so, if we have a , why is
invoking  not good enough?

   2.  YANG Instance Data [I-D.ietf-netmod-yang-instance-file-format]

How would this be done? I do not see anything in reset-datastores that
provides instance data. The copy-config operation already allows to
provide source config inline. Why do we need another way of doing the
same?

I do not really understand why one would need to have reset-datastore
on  - is  not good enough?

Please fix the 'target-datasore' typo or better change the parameter
name to just 'datastore'. Should there be text explaining how an
implementation is supposed to deal with errors or will these resets
never fail?

/js

On Mon, Mar 25, 2019 at 10:14:03AM -0400, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the
> "factory-default" DS.
> 
> It seems to me that this is a single DS that might have been intended to
> reset running or startup.  However, what if I have different DSes that
> each have unique factory default data?  If I choose to extend
> factory-default with a new identity of my other DS, how can I indicate
> that the target DS will be reset to _that_ DS?  Does that make sense?
> 
> Or if I do a  on a factory-default DS, how do I know what
> other DSes does this DS pertain?  Perhaps the server will use this to
> reset a given DS, but how would a user know that (other than perhaps
> naming of the factory-default DS)?
> 
> Maybe the module needs a mapping to let the client know what DS will be
> used to reset what other DS?
> 
> Joe
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Mon Mar 25 12:31:50 2019
Return-Path: <01000169b6565530-c27feaa3-b18e-40a5-8967-f961b172ccb5-000000@amazonses.watsen.net>
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 DCAB1120021 for ; Mon, 25 Mar 2019 12:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 6ShgN-sTuscJ for ; Mon, 25 Mar 2019 12:31:46 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D026120020 for ; Mon, 25 Mar 2019 12:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553542305; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:Cc:To:Feedback-ID; bh=LCObRuIluhZtP/DoWf4sMVnpF9UQxibxX35lqXQ0y5s=; b=cZuJHLXHwgNICNMRajm4aKoyumIeZlvCgym81oPpeIXjU2ryCXiNiHnqjfZNNGCF NBhCEBC/iJSpBQCzNQ8Do756xo9Ia6WW5BM1YpJzFpBB7q2X6TPoML+IQptz4iEpcUK BPxqW06/VUm17WTETG8mh13zO07jgK1isjZbHKBw=
From: Kent Watsen 
Content-Type: multipart/alternative; boundary=Apple-Mail-9FCA60AC-4C4B-424C-8FC5-D370C1AA142A
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 19:31:45 +0000
Message-ID: <01000169b6565530-c27feaa3-b18e-40a5-8967-f961b172ccb5-000000@email.amazonses.com>
Cc: netmod@ietf.org
To: Juergen Schoenwaelder 
X-Mailer: iPad Mail (16D57)
X-SES-Outgoing: 2019.03.25-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] IPR poll on draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 19:31:49 -0000

--Apple-Mail-9FCA60AC-4C4B-424C-8FC5-D370C1AA142A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that applie=
s
to draft-schoenw-netmod-rfc6991-bis-00?  Please Reply-All to *this* email an=
d
state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropriat=
e.

If you are listed as a document author or contributor please answer the abov=
e by
responding to this email regardless of whether or not you are aware of any r=
elevant
IPR.  This document will not advance to the next stage until a response has b=
een
received from each author and listed contributor.  NOTE: THIS APPLIES TO ALL=

OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as a=
n author
or contributor, we remind you of your obligations under the IETF IPR rules w=
hich
encourages you to notify the IETF if you are aware of IPR of others on an IE=
TF
contribution, or to refrain from participating in any contribution or discus=
sion related
to your undisclosed IPR. For more information, please see the RFCs listed ab=
ove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent // as co-chair


--Apple-Mail-9FCA60AC-4C4B-424C-8FC5-D370C1AA142A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware=
 of any IPR that applies
to draft-schoenw-netmod-rfc6991-bis-00?  Please Re=
ply-All to *this* email and
state either:

"No, I'm not aware of any IPR that=
 applies to this draft"
or
"Yes, I'm aware of IP=
R that applies to this draft"

If "yes", has thi=
s IPR been disclosed in compliance with IETF IPR rules
(see RFC=
s 3669, 5378 and 8179 for more details)?

If "ye=
s" again, please state either:

"Yes, the IPR ha=
s been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If y=
ou answer no, please provide any additional details you think appropriate.
If you are listed as a document author or contri=
butor please answer the above by
responding to this email rega=
rdless of whether or not you are aware of any relevant
IPR. &n=
bsp;This document will not advance to the next stage until a response has be=
en
received from each author and listed contributor.  NOT=
E: THIS APPLIES TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINE=
S.

If you are on the WG email list or attend WG=
 meetings but are not listed as an author
or contributor, we r=
emind you of your obligations under the IETF IPR rules which
e=
ncourages you to notify the IETF if you are aware of IPR of others on an IET=
F
contribution, or to refrain from participating in any contri=
bution or discussion related
to your undisclosed IPR. For more=
 information, please see the RFCs listed above
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProper=
ty.

Thank you,
Kent // as co-=
chair

=

--Apple-Mail-9FCA60AC-4C4B-424C-8FC5-D370C1AA142A--


From nobody Mon Mar 25 12:35:31 2019
Return-Path: <01000169b659923f-c455f8f9-0104-4a2f-a22e-d44425ecd295-000000@amazonses.watsen.net>
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 AC2EF120838 for ; Mon, 25 Mar 2019 12:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 aMDtirhJiAB9 for ; Mon, 25 Mar 2019 12:35:19 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1AE1207E5 for ; Mon, 25 Mar 2019 12:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553542517; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:Cc:To:Feedback-ID; bh=+3L0Tn3Uid26Qz9Svysqxnng8ctY0MJKUQeoOQNXeko=; b=amFHPzmVUp6f0oiDLugToXb1gtTWy9JBMe/Jg4kNbZP/OahE/SlFJUMjiyShcdbs IgwwzLK87O77Zr0Fu598uD6JLGSBPcPeQw6gaeSUFPlLOW4Lek3bCFsktthuMERoxl0 KvELu/XiEa0RZNneAmlWPjXrpo/9+vECc8pAILcY=
From: Kent Watsen 
Content-Type: multipart/alternative; boundary=Apple-Mail-29F3E97F-48C1-4EE1-B5D3-DA448F186FAC
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 19:35:17 +0000
Message-ID: <01000169b659923f-c455f8f9-0104-4a2f-a22e-d44425ecd295-000000@email.amazonses.com>
Cc: netmod@ietf.org
To: chopps@labn.net
X-Mailer: iPad Mail (16D57)
X-SES-Outgoing: 2019.03.25-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] IPR poll on draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 19:35:28 -0000

--Apple-Mail-29F3E97F-48C1-4EE1-B5D3-DA448F186FAC
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that applie=
s
to draft-chopps-netmod-geo-location-01?  Please Reply-All to *this* email an=
d
state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropriat=
e.

If you are listed as a document author or contributor please answer the abov=
e by
responding to this email regardless of whether or not you are aware of any r=
elevant
IPR.  This document will not advance to the next stage until a response has b=
een
received from each author and listed contributor.  NOTE: THIS APPLIES TO ALL=

OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as a=
n author
or contributor, we remind you of your obligations under the IETF IPR rules w=
hich
encourages you to notify the IETF if you are aware of IPR of others on an IE=
TF
contribution, or to refrain from participating in any contribution or discus=
sion related
to your undisclosed IPR. For more information, please see the RFCs listed ab=
ove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent // as co-chair=

--Apple-Mail-29F3E97F-48C1-4EE1-B5D3-DA448F186FAC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware=
 of any IPR that applies
to draft-chopps-netmod-geo-location-01?  Please Re=
ply-All to *this* email and
state either:

"No, I'm not aware o=
f any IPR that applies to this draft"
or
"Yes, I=
'm aware of IPR that applies to this draft"

If "=
yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Y=
es, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think a=
ppropriate.

If you are listed as a document aut=
hor or contributor please answer the above by
responding to th=
is email regardless of whether or not you are aware of any relevant
IPR.  This document will not advance to the next stage until a re=
sponse has been
received from each author and listed contribut=
or.  NOTE: THIS APPLIES TO ALL
OF YOU LISTED IN THIS MESS=
AGE'S TO LINES.

If you are on the WG email list=
 or attend WG meetings but are not listed as an author
or cont=
ributor, we remind you of your obligations under the IETF IPR rules whichencourages you to notify the IETF if you are aware of IPR of oth=
ers on an IETF
contribution, or to refrain from participating i=
n any contribution or discussion related
to your undisclosed I=
PR. For more information, please see the RFCs listed above
and=
 http://trac.tools.ietf.org/group/iesg/trac/wiki/Intell=
ectualProperty.

Thank you,
Ke=
nt // as co-chair
=

--Apple-Mail-29F3E97F-48C1-4EE1-B5D3-DA448F186FAC--


From nobody Mon Mar 25 13:10:59 2019
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 37562120077 for ; Mon, 25 Mar 2019 13:10:58 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 3vQtCkjp_lvq for ; Mon, 25 Mar 2019 13:10:55 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC3F120044 for ; Mon, 25 Mar 2019 13:10:55 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7DE9D24; Mon, 25 Mar 2019 21:10:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id GFKvbYVT9Ylk; Mon, 25 Mar 2019 21:10:53 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Mar 2019 21:10:53 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DB75200AA; Mon, 25 Mar 2019 21:10:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id RYXUYQEQgBqc; Mon, 25 Mar 2019 21:10:53 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 11907200A8; Mon, 25 Mar 2019 21:10:52 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 25 Mar 2019 21:10:52 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 237B630078E5CF; Mon, 25 Mar 2019 21:10:51 +0100 (CET)
Date: Mon, 25 Mar 2019 21:10:51 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: 
Message-ID: <20190325201051.sctgjk43jkomkkna@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , netmod@ietf.org
References: <01000169b6565530-c27feaa3-b18e-40a5-8967-f961b172ccb5-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <01000169b6565530-c27feaa3-b18e-40a5-8967-f961b172ccb5-000000@email.amazonses.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] IPR poll on draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:10:58 -0000

No, I'm not aware of any IPR that applies to this draft

/js

On Mon, Mar 25, 2019 at 07:31:45PM +0000, Kent Watsen wrote:
> To each author and contributor listed on the "To" line.
> 
> In order to complete the Adoption poll, are you aware of any IPR that applies
> to draft-schoenw-netmod-rfc6991-bis-00?  Please Reply-All to *this* email and
> state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If "yes", has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If "yes" again, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think appropriate.
> 
> If you are listed as a document author or contributor please answer the above by
> responding to this email regardless of whether or not you are aware of any relevant
> IPR.  This document will not advance to the next stage until a response has been
> received from each author and listed contributor.  NOTE: THIS APPLIES TO ALL
> OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed as an author
> or contributor, we remind you of your obligations under the IETF IPR rules which
> encourages you to notify the IETF if you are aware of IPR of others on an IETF
> contribution, or to refrain from participating in any contribution or discussion related
> to your undisclosed IPR. For more information, please see the RFCs listed above
> and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> Kent // as co-chair
> 

-- 
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 Mar 25 13:14:13 2019
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 55E9B1200B4 for ; Mon, 25 Mar 2019 13:14:11 -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 cON11nV2oh04 for ; Mon, 25 Mar 2019 13:14: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 3A7091200A4 for ; Mon, 25 Mar 2019 13:14:09 -0700 (PDT)
Received: from localhost (dhcp-9545.meeting.ietf.org [31.133.149.69]) by mail.tail-f.com (Postfix) with ESMTPSA id 6CD9D1AE00A0; Mon, 25 Mar 2019 21:14:07 +0100 (CET)
Date: Mon, 25 Mar 2019 21:14:04 +0100 (CET)
Message-Id: <20190325.211404.855691837244375713.mbj@tail-f.com>
To: joey.boyd@adtran.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <26CE489EF4611643B3EFE43D06E02654018CCF76FA@ex-mb1.corp.adtran.com>
References: <26CE489EF4611643B3EFE43D06E02654018CCF76FA@ex-mb1.corp.adtran.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] error-message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:14:11 -0000

Hi,

I think that this should be listed as an acceptable change in secion
11.  Something to fix if we do YANg 1.2.


/martin



JOEY BOYD  wrote:
> Hi,
> 
> I wanted to follow up on this as I have not received any feedback. I
> thinking now that even though it is isn't specifically called out in
> the update section, that adding an error-message could be backward
> compatible as it has no impact on the data or modeled constraint. It
> merely defines the error response which was previously up to the
> implementation to determine.
> 
> Any thoughts on this?
> 
> Regards,
> Joey
> 
> From: JOEY BOYD
> Sent: Monday, March 4, 2019 9:37 AM
> To: 'netmod@ietf.org' 
> Subject: error-message
> 
> Hi,
> 
> Is the addition of an 'error-message' to an existing 'must' statement
> considered backward compatible? I don't see 'error-message' mentioned
> in the "Updating a Module" section which leads me to believe that it
> isn't but wanted to double check to see what implications adding one
> to an existing module would have.
> 
> Thanks and regards,
> Joey
> 


From nobody Mon Mar 25 13:17:25 2019
Return-Path: <01000169b68012f8-63de3dbd-d0a8-4276-99f7-b4073a98b97e-000000@amazonses.watsen.net>
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 5AD5C1200A4 for ; Mon, 25 Mar 2019 13:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 nTBuNGrxxSCH for ; Mon, 25 Mar 2019 13:17:22 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2C7120020 for ; Mon, 25 Mar 2019 13:17:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553545040; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Tl3mg4h/TV0zH0kRdHHvv3QNIX9T5+vHpb4/NVkM4NQ=; b=Kz+g7yhpeh+CblrAnWwqCeXQWHrOitbvxsPIqt7KBBVyeUE3C3tKQvrq+nnsvEkY rXAvO4uB+NQ+yzeK1OjfMI0b7cH33tqmdUvc+aVD+UQRFC8GqV/QpIMyKAEnqQr6Ihh ID8Ekm+OfThqHrD8c/XRvoFEtnF5yQA7gtr5l5Y0=
Content-Type: multipart/alternative; boundary=Apple-Mail-5DC3C582-7430-496D-8B90-14855ED4228D
Mime-Version: 1.0 (1.0)
From: Kent Watsen 
X-Mailer: iPad Mail (16D57)
In-Reply-To: <7C9A4660-9BC6-4B37-AB96-9E4B33FBC44D@watsen.net>
Date: Mon, 25 Mar 2019 20:17:20 +0000
Cc: netmod@ietf.org
Content-Transfer-Encoding: 7bit
Message-ID: <01000169b68012f8-63de3dbd-d0a8-4276-99f7-b4073a98b97e-000000@email.amazonses.com>
References: <7C9A4660-9BC6-4B37-AB96-9E4B33FBC44D@watsen.net>
To: bill.wu@huawei.com, balazs.lengyel@ericsson.com, niuye@huawei.com, rohitrranade@huawei.com
X-SES-Outgoing: 2019.03.25-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] IPR poll on draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:17:24 -0000

--Apple-Mail-5DC3C582-7430-496D-8B90-14855ED4228D
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that applie=
s
to draft-wu-netmod-factory-default-02?  Please Reply-All to *this* email and=
=20
state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropriat=
e.

If you are listed as a document author or contributor please answer the abov=
e by
responding to this email regardless of whether or not you are aware of any r=
elevant
IPR.  This document will not advance to the next stage until a response has b=
een
received from each author and listed contributor.  NOTE: THIS APPLIES TO ALL=

OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as a=
n author
or contributor, we remind you of your obligations under the IETF IPR rules w=
hich
encourages you to notify the IETF if you are aware of IPR of others on an IE=
TF
contribution, or to refrain from participating in any contribution or discus=
sion related
to your undisclosed IPR. For more information, please see the RFCs listed ab=
ove
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent // as co-chair=

--Apple-Mail-5DC3C582-7430-496D-8B90-14855ED4228D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


To each author and contributor listed on the=
 "To" line.

In order to complete the Adoption p=
oll, are you aware of any IPR that applies
to draft-wu-ne=
tmod-factory-default-02?  Please Reply-All to *this* email and 
state either:

"No, I'm not aware of any I=
PR that applies to this draft"
or
"Yes, I'm awar=
e of IPR that applies to this draft"

If "yes", h=
as this IPR been disclosed in compliance with IETF IPR rules
(=
see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the=
 IPR has been disclosed in compliance with IETF IPR rules"
or<=
br class=3D"">"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropr=
iate.

If you are listed as a document author or=
 contributor please answer the above by
responding to this ema=
il regardless of whether or not you are aware of any relevant
=
IPR.  This document will not advance to the next stage until a response=
 has been
received from each author and listed contributor. &n=
bsp;NOTE: THIS APPLIES TO ALL
OF YOU LISTED IN THIS MESSAGE'S T=
O LINES.

If you are on the WG email list or att=
end WG meetings but are not listed as an author
or contributor=
, we remind you of your obligations under the IETF IPR rules which
encourages you to notify the IETF if you are aware of IPR of others on an=
 IETF
contribution, or to refrain from participating in any co=
ntribution or discussion related
to your undisclosed IPR. For m=
ore information, please see the RFCs listed above
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProp=
erty.

Thank you,
Kent // as c=
o-chair
=

--Apple-Mail-5DC3C582-7430-496D-8B90-14855ED4228D--


From nobody Mon Mar 25 13:18:53 2019
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 8C2FB1207E5 for ; Mon, 25 Mar 2019 13:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 mUUO_n4XLycZ for ; Mon, 25 Mar 2019 13:18:49 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2182112080B for ; Mon, 25 Mar 2019 13:18:49 -0700 (PDT)
Received: from pencil (unknown [62.168.35.66]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0C85A6046A; Mon, 25 Mar 2019 16:18:47 -0400 (EDT)
From: 
To: "'Kent Watsen'" , 
Cc: 
References: <01000169b659923f-c455f8f9-0104-4a2f-a22e-d44425ecd295-000000@email.amazonses.com>
In-Reply-To: <01000169b659923f-c455f8f9-0104-4a2f-a22e-d44425ecd295-000000@email.amazonses.com>
Date: Mon, 25 Mar 2019 21:18:46 +0100
Message-ID: <01c201d4e347$f517d530$df477f90$@chopps.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C3_01D4E350.56DCD970"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQHkmOEFT8YFd3Eo+shRHFwVFU6uhKX9XfFQ
Archived-At: 
Subject: Re: [netmod] IPR poll on draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:18:51 -0000

This is a multipart message in MIME format.

------=_NextPart_000_01C3_01D4E350.56DCD970
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

No, I=E2=80=99m not aware of any IPR that applies to this draft.

=20

Thanks,

Chris.

=20

From: netmod  On Behalf Of Kent Watsen
Sent: Monday, March 25, 2019 8:35 PM
To: chopps@labn.net
Cc: netmod@ietf.org
Subject: [netmod] IPR poll on draft-chopps-netmod-geo-location-01

=20

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that =
applies
to draft-chopps-netmod-geo-location-01?  Please Reply-All to *this* =
email and

state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think =
appropriate.

If you are listed as a document author or contributor please answer the =
above by
responding to this email regardless of whether or not you are aware of =
any relevant
IPR.  This document will not advance to the next stage until a response =
has been
received from each author and listed contributor.  NOTE: THIS APPLIES TO =
ALL
OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed =
as an author
or contributor, we remind you of your obligations under the IETF IPR =
rules which
encourages you to notify the IETF if you are aware of IPR of others on =
an IETF
contribution, or to refrain from participating in any contribution or =
discussion related
to your undisclosed IPR. For more information, please see the RFCs =
listed above
and =
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent // as co-chair


------=_NextPart_000_01C3_01D4E350.56DCD970
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


No, =
I=E2=80=99m not aware of any IPR that applies to this =
draft.
 
Thanks,
Chris.
 
From: netmod =
<netmod-bounces@ietf.org> On Behalf Of Kent =
Watsen
Sent: Monday, March 25, 2019 8:35 PM
To: =
chopps@labn.net
Cc: netmod@ietf.org
Subject: =
[netmod] IPR poll on =
draft-chopps-netmod-geo-location-01
 
To each =
author and contributor listed on the "To" line.

In =
order to complete the Adoption poll, are you aware of any IPR that =
applies
to draft-chopp=
s-netmod-geo-location-01?  Please Reply-All to *this* email =
and
state =
either:

"No, I'm not aware of any IPR that applies to this =
draft"
or
"Yes, I'm aware of IPR that applies to this =
draft"

If "yes", has this IPR been disclosed in =
compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more =
details)?

If "yes" again, please state =
either:

"Yes, the IPR has been disclosed in compliance with =
IETF IPR rules"
or
"No, the IPR has not been =
disclosed"

If you answer no, please provide any additional =
details you think appropriate.

If you are listed as a document =
author or contributor please answer the above by
responding to this =
email regardless of whether or not you are aware of any relevant
IPR. =
 This document will not advance to the next stage until a response =
has been
received from each author and listed contributor. =
 NOTE: THIS APPLIES TO ALL
OF YOU LISTED IN THIS MESSAGE'S TO =
LINES.

If you are on the WG email list or attend WG meetings but =
are not listed as an author
or contributor, we remind you of your =
obligations under the IETF IPR rules which
encourages you to notify =
the IETF if you are aware of IPR of others on an IETF
contribution, =
or to refrain from participating in any contribution or discussion =
related
to your undisclosed IPR. For more information, please see the =
RFCs listed above
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty=
.

Thank you,
Kent // as =
co-chair

------=_NextPart_000_01C3_01D4E350.56DCD970--


From nobody Mon Mar 25 13:25:41 2019
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 30A6D1200A4 for ; Mon, 25 Mar 2019 13:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 zVGUsSbwbCPz for ; Mon, 25 Mar 2019 13:25:36 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 592F5120020 for ; Mon, 25 Mar 2019 13:25:36 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3326497291B5FF8588E6; Mon, 25 Mar 2019 20:25:34 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 25 Mar 2019 20:25:33 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 04:25:22 +0800
From: Qin Wu 
To: Kent Watsen , "balazs.lengyel@ericsson.com" , Niuye , Rohit R Ranade 
CC: "netmod@ietf.org" 
Thread-Topic: IPR poll on draft-wu-netmod-factory-default-02
Thread-Index: AdTjSM42WD734nzHRWGVuuqWAsC8NQ==
Date: Mon, 25 Mar 2019 20:25:21 +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.220.69.213]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA487E021nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] IPR poll on draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:25:39 -0000

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

Tm8sIEnigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0
Lg0KDQotUWluDQrlj5Hku7bkuro6IEtlbnQgV2F0c2VuIFttYWlsdG86a2VudCtpZXRmQHdhdHNl
bi5uZXRdDQrlj5HpgIHml7bpl7Q6IDIwMTnlubQz5pyIMjbml6UgNDoxNw0K5pS25Lu25Lq6OiBR
aW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTsg
Tml1eWUgPG5pdXllQGh1YXdlaS5jb20+OyBSb2hpdCBSIFJhbmFkZSA8cm9oaXRycmFuYWRlQGh1
YXdlaS5jb20+DQrmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBJUFIgcG9sbCBvbiBk
cmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyDQoNClRvIGVhY2ggYXV0aG9yIGFuZCBj
b250cmlidXRvciBsaXN0ZWQgb24gdGhlICJUbyIgbGluZS4NCg0KSW4gb3JkZXIgdG8gY29tcGxl
dGUgdGhlIEFkb3B0aW9uIHBvbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp
ZXMNCnRvIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDI/ICBQbGVhc2UgUmVwbHkt
QWxsIHRvICp0aGlzKiBlbWFpbCBhbmQNCnN0YXRlIGVpdGhlcjoNCg0KIk5vLCBJJ20gbm90IGF3
YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQpvcg0KIlllcywgSSdt
IGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYgInllcyIsIGhh
cyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVs
ZXMNCihzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJ
ZiAieWVzIiBhZ2FpbiwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KIlllcywgdGhlIElQUiBoYXMg
YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiJO
bywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBw
bGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0
ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0
b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkNCnJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCBy
ZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50
DQpJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2Ug
dW50aWwgYSByZXNwb25zZSBoYXMgYmVlbg0KcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQg
bGlzdGVkIGNvbnRyaWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTA0KT0YgWU9VIExJ
U1RFRCBJTiBUSElTIE1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cg
ZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu
IGF1dGhvcg0Kb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9u
cyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2gNCmVuY291cmFnZXMgeW91IHRvIG5vdGlm
eSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURg0K
Y29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29u
dHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZA0KdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIu
IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZQ0K
YW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVs
bGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpLZW50IC8vIGFzIGNvLWNoYWlyDQo=

--_000_B8F9A780D330094D99AF023C5877DABAA487E021nkgeml513mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN
CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg
MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz
aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5ObywgSeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh
ZnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LVFpbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0i
RU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy
aWYiPiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldF0NCjxicj4N
Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0i
RU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy
aWYiPiAyMDE5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1V
UyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjY8L3NwYW4+5pelPHNwYW4gbGFuZz0i
RU4tVVMiPg0KIDQ6MTc8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi
Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUWluIFd1ICZsdDtiaWxsLnd1QGh1YXdl
aS5jb20mZ3Q7OyBiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb207IE5pdXllICZsdDtuaXV5ZUBo
dWF3ZWkuY29tJmd0OzsgUm9oaXQgUiBSYW5hZGUgJmx0O3JvaGl0cnJhbmFkZUBodWF3ZWkuY29t
Jmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+
PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKY
PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gSVBSIHBv
bGwgb24gZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMjxvOnA+PC9vOnA+PC9zcGFu
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VG8gZWFjaCBhdXRob3IgYW5kIGNvbnRy
aWJ1dG9yIGxpc3RlZCBvbiB0aGUgJnF1b3Q7VG8mcXVvdDsgbGluZS48YnI+DQo8YnI+DQpJbiBv
cmRlciB0byBjb21wbGV0ZSB0aGUgQWRvcHRpb24gcG9sbCwgYXJlIHlvdSBhd2FyZSBvZiBhbnkg
SVBSIHRoYXQgYXBwbGllczxicj4NCnRvJm5ic3A7ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVm
YXVsdC0wMj8gJm5ic3A7UGxlYXNlIFJlcGx5LUFsbCB0byAqdGhpcyogZW1haWwgYW5kJm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnN0YXRlIGVpdGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PGJyPg0KJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g
dGhpcyBkcmFmdCZxdW90Ozxicj4NCm9yPGJyPg0KJnF1b3Q7WWVzLCBJJ20gYXdhcmUgb2YgSVBS
IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7PGJyPg0KPGJyPg0KSWYgJnF1b3Q7eWVz
JnF1b3Q7LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF
VEYgSVBSIHJ1bGVzPGJyPg0KKHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUg
ZGV0YWlscyk/PGJyPg0KPGJyPg0KSWYgJnF1b3Q7eWVzJnF1b3Q7IGFnYWluLCBwbGVhc2Ugc3Rh
dGUgZWl0aGVyOjxicj4NCjxicj4NCiZxdW90O1llcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9z
ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1b3Q7PGJyPg0Kb3I8YnI+DQom
cXVvdDtObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkJnF1b3Q7PGJyPg0KPGJyPg0K
SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5
b3UgdGhpbmsgYXBwcm9wcmlhdGUuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBk
b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnk8
YnI+DQpyZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5v
dCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudDxicj4NCklQUi4gJm5ic3A7VGhpcyBkb2N1
bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2Ug
aGFzIGJlZW48YnI+DQpyZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJp
YnV0b3IuICZuYnNwO05PVEU6IFRISVMgQVBQTElFUyBUTyBBTEw8YnI+DQpPRiBZT1UgTElTVEVE
IElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLjxicj4NCjxicj4NCklmIHlvdSBhcmUgb24gdGhl
IFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBh
cyBhbiBhdXRob3I8YnI+DQpvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9i
bGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaDxicj4NCmVuY291cmFnZXMg
eW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMg
b24gYW4gSUVURjxicj4NCmNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lw
YXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQ8YnI+DQp0byB5
b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl
IFJGQ3MgbGlzdGVkIGFib3ZlPGJyPg0KYW5kJm5ic3A7PGEgaHJlZj0iaHR0cDovL3RyYWMudG9v
bHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkiPmh0
dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVh
bFByb3BlcnR5PC9hPi48YnI+DQo8YnI+DQpUaGFuayB5b3UsPGJyPg0KS2VudCAvLyBhcyBjby1j
aGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_B8F9A780D330094D99AF023C5877DABAA487E021nkgeml513mbxchi_--


From nobody Mon Mar 25 13:30:22 2019
Return-Path: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@amazonses.watsen.net>
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 E15F61200A4 for ; Mon, 25 Mar 2019 13:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 WaVZZhnPxbK7 for ; Mon, 25 Mar 2019 13:30:19 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E21C120020 for ; Mon, 25 Mar 2019 13:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553545817; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=gDeLLqDV7h6Dagy0dXgfQHCaTTFDvpY0FZ3CcSWZrbA=; b=fgpM8+9jTPPUQVOifBGU35aCH3adlmCBs6Tgp/jeI6SK65JA0Vr2UdWXdPfsdRHu vqHGkRhE/6f7b5sUPSg++1z4ncAALYJ37c8cKNAufS1EJXP0adSahWL/sXmpWN4AEYL trExtVhV1DIj7Abw4exnaFSI9sb+DtMqTjvMpZrM=
From: Kent Watsen 
Content-Type: multipart/alternative; boundary=Apple-Mail-5ECEC78C-DF35-42CB-987D-5103DA7B556C
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 20:30:17 +0000
Message-ID: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
To: netmod@ietf.org
X-Mailer: iPad Mail (16D57)
X-SES-Outgoing: 2019.03.25-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:30:21 -0000

--Apple-Mail-5ECEC78C-DF35-42CB-987D-5103DA7B556C
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00

Please voice your support or objections before April 8.

Kent (and Lou and Joel)


--Apple-Mail-5ECEC78C-DF35-42CB-987D-5103DA7B556C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


This email begins a 2-week adoption poll for=
:

    ht=
tps://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00

Please voice your support or objections before April 8.

Kent (and Lou and Joel)
=


=

--Apple-Mail-5ECEC78C-DF35-42CB-987D-5103DA7B556C--


From nobody Mon Mar 25 13:32:25 2019
Return-Path: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@amazonses.watsen.net>
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 6842D12004E for ; Mon, 25 Mar 2019 13:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 U5GDOn-vqKNJ for ; Mon, 25 Mar 2019 13:32:22 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B855212004D for ; Mon, 25 Mar 2019 13:32:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553545941; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=b4tYGvINZKeruZuhg81SdKATI0kDkyg7N61lbG1+NZ8=; b=OdJbOH4m5J8rtvoEYEZslJKLXZgY2F4CPbMxMWM8ICJIx0xs47uZzSG8Q4kvDMCP cLyn6N6IipbWzXfK7nZsKbYGl1Zm4Xk10nfeGon7Y7n/V2HgguQpzC43w3ODO9zDy4x pzt8yuQoKHzq/iYVjXE2rmHZF57ZkD/JJH+Q8kaw=
From: Kent Watsen 
Content-Type: multipart/alternative; boundary=Apple-Mail-5CF04053-E480-47E0-A8DC-A657F2121812
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 20:32:21 +0000
Message-ID: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
To: netmod@ietf.org
X-Mailer: iPad Mail (16D57)
X-SES-Outgoing: 2019.03.25-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:32:25 -0000

--Apple-Mail-5CF04053-E480-47E0-A8DC-A657F2121812
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01

Please voice your support or objections before April 8.

Kent // as co-chair



--Apple-Mail-5CF04053-E480-47E0-A8DC-A657F2121812
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


This email begins a 2-week adoption poll for=
:

    ht=
tps://tools.ietf.org/html/draft-chopps-netmod-geo-location-01

Please voice your support or objections before April 8.

Kent // as co-chair

<=
/div>

=

--Apple-Mail-5CF04053-E480-47E0-A8DC-A657F2121812--


From nobody Mon Mar 25 13:35:02 2019
Return-Path: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@amazonses.watsen.net>
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 76ACC12004E for ; Mon, 25 Mar 2019 13:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 8GwlX4I-XF6J for ; Mon, 25 Mar 2019 13:34:59 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AC212004D for ; Mon, 25 Mar 2019 13:34:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553546097; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:To:Feedback-ID; bh=AwG8CmCrBS8kd6rtP1xPpJPICFmv+ZuKqPKVAei2af0=; b=NwWzXPPE//258Z7EBNeXPxlp4XWFnGkjv1bepuwUhsXKjpvGPO30O+8ANhYKddKT 78punKo81G9SavEpxySLL/rONiXzxU1rJGt0FzsG6IemKzhM2ZOOrS2DdSY++dhhYfl NEtbenZLWLx5m2zkDdpqNeD0ge3+spYmOG8vMad0=
From: Kent Watsen 
Content-Type: multipart/alternative; boundary=Apple-Mail-852AE129-271A-4399-AA5E-79154C5B545F
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 25 Mar 2019 20:34:57 +0000
Message-ID: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
To: netmod@ietf.org
X-Mailer: iPad Mail (16D57)
X-SES-Outgoing: 2019.03.25-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:35:00 -0000

--Apple-Mail-852AE129-271A-4399-AA5E-79154C5B545F
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02

Please voice your support or objections before April 8.

Kent (and Lou)
--Apple-Mail-852AE129-271A-4399-AA5E-79154C5B545F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

=

--Apple-Mail-852AE129-271A-4399-AA5E-79154C5B545F--


From nobody Mon Mar 25 13:37:47 2019
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 2B5A412080B for ; Mon, 25 Mar 2019 13:37:46 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3URepSzaC31t for ; Mon, 25 Mar 2019 13:37:43 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 6E2861200B4 for ; Mon, 25 Mar 2019 13:37:43 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id f23so9137028ljc.0 for ; Mon, 25 Mar 2019 13:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OUlhykUjxtaTPnslFbM2fvtqkIcwmotsE9Cqhdrs2YA=; b=XH7SpICn2I967ttTp0LRGHymZn2Cm57Fg4j58nOJiaSpBUHyquzJmWacZyR723eEIb b79nAXrgLnUPoVjQZGONhNOF6r5fI+hiKjiawOkIYAtJWSD0TsC03O6nVXg5RgKD9q8k RZIl4XpP9zzgZ2OxRRg3KtzoeO8bUvuoGoWGYUbZA72H+yqb9Ig1fA5gVLuTAmCIdlVq CEj1vk9dQcxuAFD90YzlOQhQMYBRQjiYPTNsQXrCPqU0J/liyC15sEBWMPGfjmtLRk03 bCmQrjISn5TG11E0dUkE/7VvkrAGJezF+yP2rDSaryMmgnW0Pvnb4/dAMO6jPkk/tm8r eAfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OUlhykUjxtaTPnslFbM2fvtqkIcwmotsE9Cqhdrs2YA=; b=Qk7/zcEFxOA6yBSL+ltjB8MRkp/34IFkj86FrVsXKQKaWelBnWTdVMMLOKrRsk0RcV P7v+8vfZt/mI0Mo2LR3uCt+Xsz88cd3iTufR/QS3ZbgrRbBzytjq1G/Iv/j8OApiR+Kw Fbe7B/4FteFIbEUczd0YDis0TzMoHmbXbvASLKkjkHSr30ewAoIT2rmOa8L4zHU184Ra qI4fCIURALma2LQy+WRa+RWP4YdbEXrltzI/tUNobE3J0h2W09EeDYAPV5Zsl5JbtkcR qQ2PElmGSIub9C1zB3DP11yFYd30H0B9Fk+SX6k4ZhpV8LSBEsnaLGxciHR0uVPYZlyW 0yrQ==
X-Gm-Message-State: APjAAAUS79lG6x0iTc3IxR2Q+QS4EBynLzP8axzqq97TR2RgtVsez1z0 rYQOV/xnL6hsfPGAyfNzpBRkEfDUnLpCn9MTcgJN9fOf
X-Google-Smtp-Source: APXvYqyfuC1P0e6gqjbtnvLjA4O4TA1cmPC1JlHP+VQN6EgUMMSlIduPtB8V26pf12E9dPyUKdJNBD5NwHr7RiboF6M=
X-Received: by 2002:a2e:9e4d:: with SMTP id g13mr1087194ljk.12.1553546261451;  Mon, 25 Mar 2019 13:37:41 -0700 (PDT)
MIME-Version: 1.0
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
From: Andy Bierman 
Date: Mon, 25 Mar 2019 13:37:30 -0700
Message-ID: 
To: Kent Watsen 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000000e6da20584f12d87"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:37:46 -0000

--0000000000000e6da20584f12d87
Content-Type: text/plain; charset="UTF-8"

Hi,

I support adoption of this draft.
I suggest that new types be added or adjusted for 1 IETF (4 months).
After that do WGLC and publish an RFC.
YANG modules do not have to take years.

Andy


On Mon, Mar 25, 2019 at 1:30 PM Kent Watsen  wrote:

> This email begins a 2-week adoption poll for:
>
>     https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00
>
> Please voice your support or objections before April 8.
>
> Kent (and Lou and Joel)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--0000000000000e6da20584f12d87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I support adoption of this draft.
I suggest that new types be added or adjusted for 1 IETF (4 months).
After that do WGLC and publish an RFC.
YANG modules =
do not have to take years.

Andy


On Mon, Mar 25, 2019 at 1:30 PM Kent Watsen <kent+ietf@watsen.net> wrote:
This email begins a 2-wee=
k adoption poll for:


Please voice your support or obje=
ctions before April 8.

Kent (and Lou and Joel)

=

_______________________________________________

netmod mailing list

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




--0000000000000e6da20584f12d87--


From nobody Mon Mar 25 13:47:59 2019
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 7BB67120075 for ; Mon, 25 Mar 2019 13:47:57 -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 9M41VtTilifw for ; Mon, 25 Mar 2019 13:47:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 97E0B120059 for ; Mon, 25 Mar 2019 13:47:55 -0700 (PDT)
Received: from localhost (dhcp-9545.meeting.ietf.org [31.133.149.69]) by mail.tail-f.com (Postfix) with ESMTPSA id 87B2F1AE00A0; Mon, 25 Mar 2019 21:47:53 +0100 (CET)
Date: Mon, 25 Mar 2019 21:47:50 +0100 (CET)
Message-Id: <20190325.214750.1687158789187348637.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:47:58 -0000

Kent Watsen  wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00
> 
> Please voice your support or objections before April 8.

I support the adoption of this draft.


/martin


From nobody Mon Mar 25 13:48:06 2019
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 B0295120826 for ; Mon, 25 Mar 2019 13:48:02 -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 vBEVTzaftnZD for ; Mon, 25 Mar 2019 13:48:01 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8112083F for ; Mon, 25 Mar 2019 13:48:01 -0700 (PDT)
Received: from localhost (dhcp-9545.meeting.ietf.org [31.133.149.69]) by mail.tail-f.com (Postfix) with ESMTPSA id 44FF61AE00A0; Mon, 25 Mar 2019 21:48:00 +0100 (CET)
Date: Mon, 25 Mar 2019 21:47:57 +0100 (CET)
Message-Id: <20190325.214757.25506619782783917.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 20:48:05 -0000

Kent Watsen  wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
> 
> Please voice your support or objections before April 8.

I support the adoption of this draft.


/martin


From nobody Mon Mar 25 14:06:23 2019
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 D7459120860 for ; Mon, 25 Mar 2019 14:06:15 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 twjqzuwCpig4 for ; Mon, 25 Mar 2019 14:06:12 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740077.outbound.protection.outlook.com [40.107.74.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E828A120844 for ; Mon, 25 Mar 2019 14:06:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LtJw3Jmbxc3hBs96YqltHP/vSpZLEeLTG213mBjg0tc=; b=WeVgMNY1OPZ6VwA1/FkR51iZUVdsHn2h+dZ83ubcyIhPEqiaP4UzI0jhbMc6S2vBwDBNh8egUjPnYb74TMfHKTdAjrG2EzWod7zDrK5erXVVfzUC28fM/Pvdz/+Z/mnO2RRsLuEOvhWOAS4ybN2wCNNvwM0G7vxFyi5eudnA7W0=
Received: from DM5PR2201CA0087.namprd22.prod.outlook.com (2603:10b6:4:5f::40) by DM5PR22MB0154.namprd22.prod.outlook.com (2603:10b6:3:4f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Mon, 25 Mar 2019 21:06:10 +0000
Received: from CO1NAM03FT028.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::205) by DM5PR2201CA0087.outlook.office365.com (2603:10b6:4:5f::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.15 via Frontend Transport; Mon, 25 Mar 2019 21:06:10 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.54; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.54) by CO1NAM03FT028.mail.protection.outlook.com (10.152.80.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1750.11 via Frontend Transport; Mon, 25 Mar 2019 21:06:09 +0000
From: Alex Campbell 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AQHU406KLWZi4zqL40aMWnIYjPSGcQ==
Date: Mon, 25 Mar 2019 21:05:56 +0000
Message-ID: <1553547968416.52411@Aviatnet.com>
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: multipart/alternative; boundary="_000_155354796841652411Aviatnetcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(39850400004)(376002)(346002)(136003)(2980300002)(189003)(199004)(3846002)(86362001)(336012)(606006)(36756003)(110136005)(76176011)(229853002)(118246002)(53416004)(6486002)(7736002)(7636002)(2906002)(6306002)(54896002)(7596002)(236005)(19627405001)(53546011)(8676002)(356004)(5660300002)(6246003)(106466001)(186003)(7696005)(26005)(6666004)(4546004)(84326002)(246002)(102836004)(5000100001)(6116002)(117636001)(2501003)(8936002)(71190400001)(11346002)(126002)(476003)(446003)(478600001)(956004)(2616005)(72206003)(966005)(486006)(97876018)(25786009)(30436002)(106002)(16586007)(316002)(36736006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR22MB0154; H:mail-send.aviatnet.com; FPR:;  SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2e0cee3f-3793-42bc-be05-08d6b165b493
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM5PR22MB0154; 
X-MS-TrafficTypeDiagnostic: DM5PR22MB0154:
X-MS-Exchange-PUrlCount: 1
X-Microsoft-Antispam-PRVS: 
X-Forefront-PRVS: 0987ACA2E2
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: iy34NYMpbmQo6fefNh1HzK+fB5l/0A9mn5DpYHWBF8M3mA4CCZ/OiPRBdgL88htIUbEykI1JzXvxRo+KGq0D5oAdQtyFNC+Bwh2rre6IRnhnE1OPwHkhlFVjNX56giq0Ofnqg/ASxAapGmpF1Oc1jxczp2SNnIgDq76vFkGso6jzfxbOJ5gCq/mK7lrRm1MraUuwaSeL7qL5CjCwj4EpXa3wQ2YiuIrZjf9UUk48b+RBY2CR4PvfxDhMni7o1SvXqvHwyQ2v9QIZalQzONmyArLrnQ5TQkXX03/riGUMctXwJPWUj/NDqVDq/nwBkjxIMVVDXAeNenJBXAE/ou/1qzXLOMvyXeyEVI1SU/wGcxe0WZCMhakSglWISFlwuvolARYWED5ma3sRO2CW5LgJFMUDfC2ZrTPOlyjxuIt58aw=
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2019 21:06:09.7817 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e0cee3f-3793-42bc-be05-08d6b165b493
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.54];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR22MB0154
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 21:06:21 -0000

--_000_155354796841652411Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Support.


________________________________
From: netmod  on behalf of Kent Watsen 
Sent: Tuesday, 26 March 2019 9:34 a.m.
To: netmod@ietf.org
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02

Please voice your support or objections before April 8.

Kent (and Lou)

--_000_155354796841652411Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Support.











From: netmod <netmod-b=
ounces@ietf.org> on behalf of Kent Watsen <kent+ietf@watsen.net&g=
t;

Sent: Tuesday, 26 March 2019 9:34 a.m.

To: netmod@ietf.org

Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-=
02

 








This email begins a 2-week adoption poll =
for:








    https://tools.ie=
tf.org/html/draft-wu-netmod-factory-default-02







Please voice your support or objections&nb=
sp;before April 8.







Kent (and Lou)














--_000_155354796841652411Aviatnetcom_--


From nobody Mon Mar 25 14:21:13 2019
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 D27BB1200B7 for ; Mon, 25 Mar 2019 14:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4pRNBPVOFNpA for ; Mon, 25 Mar 2019 14:21:10 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10075.outbound.protection.outlook.com [40.107.1.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F69120090 for ; Mon, 25 Mar 2019 14:21:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=20kdl6igGpoWFfdVt3lQQEjbHb8VksaStQ3Utjh9vOA=; b=GNFdVK96STt2XiVM+rPRLFNOpe7RbV3MAmXfJ+3P+Qm7KdR3mI5mnK3pSO7wcforSpKs/2LfnBTa0buzoKG/oaWfTCP2yObmo0QjBt34k28F0ogQiqpkUJXFN+QkMvO7PdW9K8fEKEmByqCX+0U0CL7tFqAQgwt2+qiMYZgb9AI=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB5558.eurprd07.prod.outlook.com (20.178.88.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 21:21:06 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 21:21:06 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02 - etag/timestamp
Thread-Index: AQHU41Co24KKrlm7f0SPFF9dVahhow==
Date: Mon, 25 Mar 2019 21:21:06 +0000
Message-ID: <35eb0c08-1834-5e07-d961-4503298b8515@ericsson.com>
References: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@email.amazonses.com>
In-Reply-To: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: AM5PR0602CA0011.eurprd06.prod.outlook.com (2603:10a6:203:a3::21) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 99f2a3f8-fa96-473d-a492-08d6b167cad9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5558; 
x-ms-traffictypediagnostic: AM6PR07MB5558:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(396003)(136003)(346002)(199004)(189003)(6116002)(36756003)(3846002)(97736004)(6486002)(99936001)(229853002)(105586002)(85202003)(14454004)(186003)(6436002)(6306002)(236005)(6512007)(53936002)(478600001)(102836004)(54896002)(8676002)(81166006)(81156014)(8936002)(85182001)(106356001)(31686004)(68736007)(25786009)(4744005)(6246003)(256004)(2906002)(71200400001)(71190400001)(5660300002)(86362001)(606006)(2501003)(2616005)(486006)(110136005)(58126008)(316002)(31696002)(476003)(386003)(7736002)(99286004)(6506007)(76176011)(65956001)(66066001)(64126003)(65806001)(11346002)(52116002)(65826007)(446003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5558; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: E05BBnGwRpBJTy8ZNZz313rabXwZpNYftMnlcfYZB3i8LEgeWAd+yiLr8Rn7LH/sbn3trJl1Rhbdt/10xYKYuJAagwyoflpzUKQAaUkPlVfiJRMHqycCHar3Bt9v3RLiUMBGhxpOIdRAclsZUNEYyVcO/Vc9LYXDLd8RGXuUPqf9+UzdMw3/uiw98+fV9ZonxRWOuz8TNSRJDBdZb/KpEP/gixYChPdLrp0Hy2iQIjPWMzGg37oCAPKZuUXMOBnBWfVm3eFaSQTPGrlpBjYxcEit9KSKmGRgFHShOVdFJ/JkawMTcgT4ZEWC8cN0w93yZJVFOQdtSflvf1SXNS0Ya+LDq/irgGw1NRY1RIDLKvzJa2GquELN1/qyV93emvhGnalfSUBR690bjTgw3vhJ/Zo0HRCDyluenAwfuQd+Eig=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070106030103020001060302"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 99f2a3f8-fa96-473d-a492-08d6b167cad9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 21:21:06.6225 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5558
Archived-At: 
Subject: Re: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02 - etag/timestamp
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 21:21:13 -0000

--------------ms070106030103020001060302
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hello Kent, 

    

    
Sadly you are right. So I should probably remove it.

    
On the other hand IMHO it is could be useful info. What would you
      think, if I found an alternative encoding for it. (It would be
      optional.)

      It could be encoded as metadata on the content-data
      container/anydata. It could give a quick indication whether the
      data has changed. If config data is read/provided periodically, it
      could be useful.

    
So is it useful enough to bother? Is the encoding as metadata OK?<=
/p>
    
Or should I just remove it?

    

    
regards Balazs

    

    
On 2019. 03. 25. 8:03, Kent Watsen
      wrote:

    

    
Section 3 say=
s
        this about Content data: =E2=80=9CIt MAY include entity-tags and
        timestamps as defined in [RFC8040]=E2=80=9D.
        =C2=A0How is this possible? =C2=A0RFC 8040 only returns such data=
 in HTTP
        headers; there=E2=80=99s no defined encoding for putting the data=
 into
        instance data.

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms070106030103020001060302
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIxMjEwM1ow
LwYJKoZIhvcNAQkEMSIEIHgY/ZWwNkPZlQb3Tk3hwMfXDn580qGVT3cxmYcET1daMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBABUegFAIznzFxWj0SnGKG7pSHCNqcsoOLUVSNqT6OCKSzrMe
KORwjofuKxznxxmdqjmwsmTxhy4vGIA3Gof/1eiqp+GI1D3Csl1Qd75ElR7gjcam4JU67HSR
eoGckpsfWfEl7uCt62yCzd1COr2XRkzcngz1wXLm4YZRWjWS+SPhsHJwl7JpzwjQWuZDXc7l
uu5HipPOikPJdeCneEWypunt6DNQ6DbQY7DWQXZRMovvKH5IZbBPh6XsYjNZ/dA36x3k7MOh
onSWe91qmUb5gSIssX6PnMuvDueEwHEiveoW1tG/Iuaxx7pq7zl02KYUFycT/2NGf49bEPne
4X3PcIEAAAAAAAA=

--------------ms070106030103020001060302--


From nobody Mon Mar 25 14:26:39 2019
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 2C6041200B9 for ; Mon, 25 Mar 2019 14:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 zaj0QhiyY19J for ; Mon, 25 Mar 2019 14:26:36 -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 F0DFF1200C4 for ; Mon, 25 Mar 2019 14:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5874; q=dns/txt; s=iport; t=1553549196; x=1554758796; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5tHgowvvFlLg71I1dSmikaJ0nfDhJnMIJ8kVmcJr6rc=; b=XUncf87K4y2B8Qs+IVsbs7fPhwEdpB//H72mA5oXvW7Hcif3RSKCJoEl 3CiUiocwonOzGypdRQSVFZn4w9FmW48eB4UkqMfkORnznEHnt3Mm11k2R pqrmvuKxSiHOixJFr1JKKA6SQ6+JZVoh1KRjR/lqPaXkOsPuuPDvTxgLH o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACVRplc/49dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDoECaIEDJwqEBIgcjS+SQ4V3FIFnDQEBI4R?= =?us-ascii?q?JAheEeyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQEDIwpcAgEIEQQBASsCAgIwHQg?= =?us-ascii?q?CBAESCIMbgRFkD65agS+ENAKFdAWBLwGLMReBQD+EIz6CYQEBA4ErARIBgym?= =?us-ascii?q?CVwOMcIQfh0aMQQkCh2GLTiGCAoV8jACLHIYFjSUCERWBLh84ZXFwFYMniwy?= =?us-ascii?q?FP0ExjW2BH4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.60,270,1549929600";  d="scan'208,217";a="252496994"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 21:26:35 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2PLQY4R012563 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 21:26:35 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Mar 2019 16:26:34 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 25 Mar 2019 16:26:34 -0500
From: "Rob Wilton (rwilton)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
Thread-Index: AQHU40mdUjDGtQ/CjUez+OGpoYcS4qYc3DKw
Date: Mon, 25 Mar 2019 21:26:34 +0000
Message-ID: <17ce45dfe3864699917a8f3200c3fbb1@XCH-RCD-007.cisco.com>
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
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.61.79.96]
Content-Type: multipart/alternative; boundary="_000_17ce45dfe3864699917a8f3200c3fbb1XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 21:26:38 -0000

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

U3VwcG9ydC4NCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo
YWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiAyNSBNYXJjaCAyMDE5IDIxOjMwDQpUbzogbmV0bW9k
QGlldGYub3JnDQpTdWJqZWN0OiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1zY2hv
ZW53LW5ldG1vZC1yZmM2OTkxLWJpcy0wMA0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIDItd2VlayBh
ZG9wdGlvbiBwb2xsIGZvcjoNCg0KDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXNjaG9lbnctbmV0bW9kLXJmYzY5OTEtYmlzLTAwDQoNCg0KUGxlYXNlIHZvaWNlIHlvdXIg
c3VwcG9ydCBvciBvYmplY3Rpb25zIGJlZm9yZSBBcHJpbCA4Lg0KDQoNCktlbnQgKGFuZCBMb3Ug
YW5kIEpvZWwpDQoNCg==

--_000_17ce45dfe3864699917a8f3200c3fbb1XCHRCD007ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu
MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3VwcG9y
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+IG5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+IDI1IE1hcmNoIDIwMTkg
MjE6MzA8YnI+DQo8Yj5Ubzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i
PiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1zY2hvZW53LW5ldG1vZC1yZmM2OTkx
LWJpcy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGlzIGVtYWlsIGJlZ2lucyBhIDItd2VlayBhZG9wdGlvbiBwb2xsIGZvcjo8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsgJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LXNjaG9lbnctbmV0bW9kLXJmYzY5OTEtYmlzLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtc2Nob2Vudy1uZXRtb2QtcmZjNjk5MS1iaXMtMDA8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB2b2lj
ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwgOC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAoYW5k
IExvdSBhbmQgSm9lbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_17ce45dfe3864699917a8f3200c3fbb1XCHRCD007ciscocom_--


From nobody Mon Mar 25 14:52:16 2019
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 90BE3120100 for ; Mon, 25 Mar 2019 14:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 emfQA9fX1oXq for ; Mon, 25 Mar 2019 14:52:11 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13AB1200F8 for ; Mon, 25 Mar 2019 14:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pb36/m05A6s313QhI/YUMp485E1joITnPFUf0g7fYco=; b=Wcs2UITMOoYp+jQn8t/qPQiJWNp7lSgPt6RgXVigNO1aB6PiKGZbl0PbUnCIO+/28UNdLDh6XT1Upha0ld3T+ufbaGGx1agVWp4D+AqMNKnBnxIuU5xj5ruYqakRhjNa/c56Ex1z7WuxwnNGi73uSrtj2ac0UXcahu6wq+9emDM=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB5989.eurprd07.prod.outlook.com (20.178.94.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 21:52:07 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 21:52:07 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02
Thread-Index: AQHU41T9cAp4skHIuUKo+OEAvF9g/w==
Date: Mon, 25 Mar 2019 21:52:07 +0000
Message-ID: 
References: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@email.amazonses.com>
In-Reply-To: <01000169b3a90fd0-04979928-b059-43aa-81b3-fa40acb5be00-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: AM6PR10CA0046.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:80::23) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ccc1e446-3f3a-440f-4baf-08d6b16c2010
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5989; 
x-ms-traffictypediagnostic: AM6PR07MB5989:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(346002)(376002)(366004)(189003)(199004)(51914003)(52116002)(6486002)(6246003)(6436002)(6506007)(106356001)(478600001)(14444005)(76176011)(229853002)(105586002)(316002)(966005)(2501003)(65826007)(31696002)(65806001)(256004)(606006)(110136005)(65956001)(5660300002)(486006)(86362001)(64126003)(66066001)(53936002)(186003)(99286004)(7736002)(236005)(71190400001)(85182001)(6512007)(31686004)(6306002)(54896002)(446003)(99936001)(58126008)(68736007)(2906002)(476003)(26005)(71200400001)(2616005)(25786009)(85202003)(6116002)(3846002)(11346002)(386003)(36756003)(14454004)(102836004)(97736004)(8676002)(8936002)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5989; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fplk1w1MMXY0C8qhiXDHLXfz8qK/y2z3sv2Rz/OLhw6wkt0LCuvzc659trK4Sv04o2HkHkKo3CGvGrBoDYGHLRFnSEj74fyMXgJ/TlgOh1SvaDFJlKwKUjYs5l0ZFJUHICfzu+63tErPbOkUNdncsttASmrmL/yD7koaCfmEyO3G6gJRPYlWCqotrQr/HrLsJiYCV3eorB/OsSYnkUGauCz2sUADbWXaneymmmtn3OoNILMK5bLgsxruoJXRQmGpf2AF5E8ArcXEBkun2Sk9xDR67lUYm0UvpwXkjhDWWUwUuJx180waKj1UWjPp8RptAzf+umyxW3Ty0DaKOASdwq/6RYOg/KdYV8vmH5YBALKtL2XB7pkbSmHKki4TmVmVnjP759wHQSAMn2Y/OZbvUETP77JXzHr/hcmz02WE/74=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020407040304060702050402"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ccc1e446-3f3a-440f-4baf-08d6b16c2010
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 21:52:07.5309 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5989
Archived-At: 
Subject: Re: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 21:52:15 -0000

--------------ms020407040304060702050402
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Thanks for the comments, see below. Balazs

    

    
On 2019. 03. 25. 8:03, Kent Watsen
      wrote:

    

    

      
      

      The Abstract says =E2=80=9Cre-using the same format as the=C2=A0reply to a
        <get> operation/request=E2=80=9D. =C2=A0At first, I was goi=
ng to
        suggest replacing <get> with <get-data>, but I
        question if this is correct since the draft supports JSON, which
        neither NETCONF RPC is able to return. 

      

    BALAZS: Restconf does have a get method. I
      thought I could refer to it as a get request.

    

      


      

      
The Terminology section is missing an entry for =E2=80=9Cinstance
          data set=E2=80=9D. 

        

    

    BALAZS:
https://tools.iet=
f.org/html/draft-ietf-netmod-yang-instance-file-format-02#section-1=C2=
=A0
      second definition is instance data set

    

      


      

      
I don=E2=80=99t understand what P3 means. =C2=A0Add info text =
to draft.

    

    BALAZS:
https://tools.iet=
f.org/html/draft-ietf-netmod-yang-instance-file-format-02#section-3
      paragraph starting with "Metadata, information about the data set
      itself SHALL be included ..." explains it. Shall I add a
      cross-reference?

    

      


      

      
Re: P4, if file =3D=3D 1 =E2=80=9Cset=E2=80=9D, then the disti=
nction becomes
        unclear (see earlier comment about missing =E2=80=9Cset=E2=80=9D =
term). =C2=A0I
        understand that it=E2=80=99s intended to mean instance data for a=
 set of
        modules but, if there=E2=80=99s a 1:1 relationship between file a=
nd set,
        then just pick one term for the draft.

    

    BALAZS: The relationship is 1-to-1. You don't=

      know how often I got the question: can I put multiple YANG modules
      into a file?

      Others commented, that instance data sets may be used without a
      file e.g. transfered on the wire e.g. as part of some IPC
      mechanism, so separating the set from the file seems like a good
      idea.

    

      


      

      
I
          don=E2=80=99t understand what P7 means. =C2=A0Add more text to =
draft.

    

    BALAZS:=C2=A0 Explained in
https://tools.iet=
f.org/html/draft-ietf-netmod-yang-instance-file-format-02#section-3
    
    
Instance data files MA=
Y contain partial data sets.  This means
   mandatory, min-elements or require-instance=3Dtrue constrains MAY be
   violated.
So if you have a module with 2 mandatory subtrees, you are free to specif=
y data only for one of them.


    

      

=

        

      
Sect=
ion
          3 says this about Content data: =E2=80=9CIt MAY include entity-=
tags
          and timestamps as defined in [RFC8040]=E2=80=9D.
          =C2=A0How is this possible? =C2=A0RFC 8040 only returns such da=
ta in
          HTTP headers; there=E2=80=99s no defined encoding for putting t=
he data
          into instance data.

    

    BALAZS: See separate mail. 

    

      


      

      

        
Section 3 also says =E2=80=9CIt MAY inc=
lude an explicit tag for default values as defined in
=

        
      [RFC6243] and [RFC8040]=E2=80=9D. =C2=A0=C2=A0Do you mean, the =E2=80=9C=
default=E2=80=9D attribute defined in Section 6 in RFC 6243 and Section 4=
=2E8.9 in RFC 8040? =C2=A0The text should be more explicit.=


      

    

    BALAZS: ye=
s,
      and I will update the text.

    

      

        



        
Section 3 also contains paragraphs begi=
nning with: =E2=80=9CIt MAY include implementation specific metadata.=E2=80=
=9D =C2=A0and =E2=80=9CIt MAY include implementation specific XML attributes.=E2=80=9D=
 =C2=A0I think these two paragraphs should be merged and a sentence added=
 noting how metadata is encoded for JSON and XML.

      

    

    BALAZS: OK

    

      

        

        
s/A single instance data set/An instance data set/ =C2=A0(since alre=
ady there is only one)

      

    

    BALAZS: OK=


    

      

        



        
Section 3 says: =E2=80=9CInstance data =
files MAY contain partial data sets.  This means=C2=A0mandatory, min-elements or requi=
re-instance=3Dtrue constrains MAY be
   violated.=E2=80=9D =C2=A0Why? =C2=A0This means validations may fail.

      

    

    BALAZS: 

      E.g. If you want to document the module set a server supports, you
      may omit the namespace. THe name/revision clearly identifies each
      YAM. While the namespace is mandatory in the module it is not
      needed to document the module set.

    
    
E.g. if you want interface statistics as
        diagnostics data, it may be enough to document the counters, but
        not the if-index.

    
E.g. Configuration to be preloaded may be
        provided partially by a file, and partially by the system
        itself, or in more additional files.

      

    

      

        



        
Generally, I feel that the part of Sectio=
n 3 describing the content should be replaced with a statement that any v=
alid response for <get-data> or GET on a top-level resource is okay=
=2E =C2=A0If this is not the case, then the draft should still start with=
 this statement and them list out any exceptions.

      

    

    BALAZS: In the previous version I used that
      kind of definition. However Jurgen and Rob W. objected strong=
ly
        against defining the returned data using the
      get-data/get. 

      We might also have partial-data set, we might have a mix of config
      and state data, which might not be valid get-data replies.
    

      

        



        
=E2=80=9CMetadata=E2=80=9D is a general term, please use ano=
ther term in Section 3, or spell out what is intended. =C2=A0BTW, there i=
sn=E2=80=99t a node in the YANG module called =E2=80=9Cmetadata=E2=80=9D,=
 leading the extra confusion.

      

    

    BALAZS:
      Sorry, I am missing something. Where do you see the metadata node
      in the module? Or which module do you mean?

      Metadata means data about the data. IMHO this is exactly the case
      for the data listed in section 3. It is data about the
      content-data. 

      What other term would you prefer?

    

      

        



        
Where is the tree diagram? =C2=A0All dr=
afts defining YANG modules should include a YANG tree diagram for each mo=
dule.=20


      

    

    BALAZS:
      Sorry, I will add it.

    

      

        



        
Actually=
, reverting on my comment above, I recommend replacing Section 3 with the=
 familiar 3-tuple: tree-diagram, example, YANG module. =C2=A0In particula=
r, I would delete all the text that can be described (and better at that)=
 by the YANG module. =C2=A0This eliminates duplication of content, which =
is both less to read and eliminates possibly conflicting information.

      

    

    BALAZS: I
      will reduce duplication, however IMHO 

    
    
    
      
  • some=

          overview text is useful, 
    • 
      
  • text=

          about file-name, single-set in a file, json/xml encoding etc.
          should not be in the module
    • 
      
  • the
          target pointer needs some explanation, better kept in the
          text, then in the module
    • 
    

    

      

        



        
Stopping=
 my review before section 3.1.

        



        
Kent // =
contributor=C2=A0

        



        



      

      

      

      
____________________________=
___________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms020407040304060702050402
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIxNTIwNVow
LwYJKoZIhvcNAQkEMSIEIHr+jposi60S1/d1znvql9OdHjMxZN124SQcXXJYlHj0MGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAClBzuDup7WQ1UdUDqc9vnWXjrnho6283N+c/77xumZa2ofM
ZYQNUaBXImqDxwi+BpXIFf6wYK92HffYdHunYDv1Kxe5g6yzOVh2YfhfhEjMGtKCdTNqDoef
3K2MJDZFPMtaokn1o7Fl+2gPj7ZzNfJMKKjOZQVJw9ZRcgz8iiNxpSCiKZZW8ghoC4nXLcgj
OALQqd2Dq79LtFwPo2IgR5HbeFreg3BIu4sFFG85URdyab75g9enHkO+kOZl5rXTk7sdpwQp
4cWHYfO9KBIXAll+h+PduciHocydokHLSPqqkjUgKE4ms+50h7VOK69yfXSwtlVOpGzFg2bc
EeMBSp8AAAAAAAA=

--------------ms020407040304060702050402--


From nobody Mon Mar 25 14:59:50 2019
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 E40D1120114 for ; Mon, 25 Mar 2019 14:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.312
X-Spam-Level: **
X-Spam-Status: No, score=2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 VnkzPDDos_k7 for ; Mon, 25 Mar 2019 14:59:46 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B477120106 for ; Mon, 25 Mar 2019 14:59:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m3rucf2IIETqmtbULvWE2bJ1yEv3dvtn0EJz+8p3gYo=; b=lTCekHQ9EjaRy85p3RBZ/4N/GTpmu9Ccs+jlprXeROwAJ6WT3G1qMHHULgZSmq9zycEK1a/i8yyzCxvEXux9ntjyd+3sY55auYv2r9d2+W/tTkycmQTwziD6+u8vCyKzsN0NScyac7yoC7ffzaZtDoz4yvKQ/IfazrJ8kJp1O2c=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB4037.eurprd07.prod.outlook.com (52.134.116.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Mon, 25 Mar 2019 21:59:43 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 21:59:43 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] instance data new backward compatibility text
Thread-Index: AQHU41YNtfrF2XOMeUSipLaMZQVy/A==
Date: Mon, 25 Mar 2019 21:59:43 +0000
Message-ID: 
References: <20190325131903.rc2opwhwqgzsdfv2@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190325131903.rc2opwhwqgzsdfv2@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1PR06CA0162.eurprd06.prod.outlook.com (2603:10a6:7:16::49) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ef704630-b77c-41a5-a98f-08d6b16d2fdc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB4037; 
x-ms-traffictypediagnostic: AM6PR07MB4037:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(396003)(346002)(366004)(199004)(189003)(6246003)(2501003)(31696002)(85182001)(6506007)(99936001)(8936002)(76176011)(386003)(53936002)(86362001)(186003)(64126003)(6512007)(316002)(65956001)(7736002)(66066001)(305945005)(68736007)(58126008)(65806001)(36756003)(256004)(26005)(14444005)(486006)(1730700003)(5640700003)(476003)(85202003)(81156014)(99286004)(446003)(2616005)(11346002)(229853002)(105586002)(6916009)(8676002)(3846002)(6116002)(65826007)(2351001)(81166006)(6486002)(97736004)(71200400001)(71190400001)(106356001)(25786009)(14454004)(561944003)(5660300002)(478600001)(6436002)(31686004)(102836004)(52116002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4037; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: kI++eclrkHu82zL1moZtQc3z87RerYwkir1DVqQOHBSnB2VBJh+I5w1Z6QNSyI/lSGPGjYjjVI4eYHUQulXDA7QmlPRmjDhODyJCcnyDCNOjTMBezI+sDdFv6TtiBQTr+leHlUEkWo+UShUFh0xioF96oDQgV741NxkYqkp26N2j3UJzOYPt3T7nUioPHPVsRHLYJl2miSSs3+2WEdwf9ZqQrd5ESH8yzoEv/lF+yoRhAq/XyPDC3lZRL+tobj+nXKbhhkgxbDBnO7/C7H8/raFjqXZJFfa+dIUrX+heFQIS7xz6lKdxsrTUysoq3zwLbb7XfVCNBKr7WSPZuo4SPcR8vL0hHk4pDcHAhPIGiTiF8Jk3GKzVe189PnnC1NiEW117oefuEP0/QR91UOmvJK/hXBgbEBDFXTPPkvu4a5g=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080601070202090300040600"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef704630-b77c-41a5-a98f-08d6b16d2fdc
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 21:59:43.4697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4037
Archived-At: 
Subject: Re: [netmod] instance data new backward compatibility text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 21:59:49 -0000

--------------ms080601070202090300040600
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hello Jurgen,

You are right that this is important mostly for instance data prepared=20
as a design/implementation activity; while not relevant for data coming=20
from the node.
I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we=20
have had MANY problems with people changing the key values/identities of =

list entries.
They think it is a nice idea to provide better, more meaningful key=20
values; however the NMS designers use these key values to detect=20
changes; also during an upgrade process if a default configuration file=20
is loaded again with slightly changed key values, then e.g. access=20
control rules become duplicated.

regards Balazs

On 2019. 03. 25. 14:19, Juergen Schoenwaelder wrote:
> Hi,
>
> I am not sure why we have this new section. The notion of backwards
> compatibility for instance data is somewhat dubious. There text that
> is there now is potentially even harmful or it needs to be ignored. If
> I dump datastore content into an instance file, I get what I get. The
> text that is there may help with maunally edited instance files but
> this is where it ends. My proposal is to simply drop section 6 again.
>
> /js
>
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms080601070202090300040600
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIxNTkzOVow
LwYJKoZIhvcNAQkEMSIEIHDRyD8SC1CfW1fu7bh6P56rbKp+/bKq7QrEZIVnhgLnMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAE9pD4kqwWxnicKG5VewMOU2iTEDa51Fg8Ct8detkiMJh0FN
MuPngj7mC+W97Db+05eKK4Hi1f0wXLaVdPtDXrDYvVm8ghvhUjTtoJu7mcVdg5kyxkDNtOow
lHGm1KmyKri9Mb7Afwr9OU/rynakSwttgqrW4F/5ydiinOANZvrEri++3Ne2WvFG+2u28jD3
fky+cbOYWFqUzia4ErdWLbr9KlcE5KGpMf9qkypWGZuAaCUmV5yRMLiv73RjNTkN2I7iATP3
Jw+kQXXyBms93rG+DHZ9llxsFDLUPwpM0SY4Z0GogyJsQcJQ8Fc0iW/vCW5n7CgZnpGbT1/l
4AznvCMAAAAAAAA=

--------------ms080601070202090300040600--


From nobody Mon Mar 25 15:08:56 2019
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 16361120105 for ; Mon, 25 Mar 2019 15:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ffL6NjoQHe9v for ; Mon, 25 Mar 2019 15:08:51 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::621]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602B6120005 for ; Mon, 25 Mar 2019 15:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YwzyK6xMin6OfBZstdfZsK+egO9URLSBGag1lqwFXOU=; b=irZzv0oocqfnaaUSlg+keH+BJaxJ5dG51ZEZmXtkklAtjhFOGl9dtnyfnTi2u5gHaUJ4imkztXDsiERFs7XoOHb6RVWZPMuqW4CyIpxeLjZOWyx//4EIsxzmgVKoeoYqAbon4rbwJAbvvta8yjYsua/tV+hWtKpIKn6ot6Epl68=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB5702.eurprd07.prod.outlook.com (20.178.86.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 22:08:49 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 22:08:49 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] Comments on instance data draft rev -02
Thread-Index: AQHU41dSzlAkduL7WUOU+yEHRS9aiA==
Date: Mon, 25 Mar 2019 22:08:49 +0000
Message-ID: 
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
In-Reply-To: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1P192CA0013.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::23) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ea07e378-3f07-48be-459d-08d6b16e7537
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5702; 
x-ms-traffictypediagnostic: AM6PR07MB5702:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(376002)(136003)(39860400002)(189003)(199004)(486006)(6116002)(3846002)(386003)(25786009)(6506007)(71190400001)(966005)(99936001)(186003)(476003)(2616005)(65806001)(71200400001)(316002)(110136005)(606006)(97736004)(102836004)(446003)(14454004)(99286004)(11346002)(26005)(64126003)(68736007)(85182001)(105586002)(53936002)(106356001)(65956001)(65826007)(85202003)(7736002)(229853002)(31686004)(5660300002)(6306002)(54896002)(14444005)(256004)(6436002)(236005)(2906002)(6486002)(6512007)(52116002)(2501003)(81166006)(81156014)(86362001)(8936002)(66066001)(6246003)(8676002)(31696002)(36756003)(76176011)(58126008)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5702; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: eYkHvaINJE5Lr8m5e2XNWh/JqTEfFOgjvkzn8I5qUwUqbO2z5++Ud5NHaJgZ8661Qw2NWS0UI9C03eIbDY/VbgE6nP1VdsDUF3tPW4zAx1RpSg8FvM1EKpE2klG3+o9ASyQ1HFD9qTtz1wh6YvdqRRsUt+TjY1/Ww94CB6kmRoplgp+gFttEthR728sa9xHVbVNAxEPwa0j+ygZEoBMXLN7EtQYn345spuwOzmtaWrcIOxYkVT/t0Awg3kneNkvUXoVQpK7f9fsF9EUF9WK55FJC+xDOdJUzFvNDUmZKtO/oaR9W4bC7uIgcywybomymosKwai5T44EF2ilpUGkJ7Z6X8h/sBjx9wjP5ZNq7+yZdViZu1UXF6gAX9DhkUqM3RVRePSq0Gd+9c0ixk29+hDxEZ6U0xlMapmB/FyrRI5w=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030400000909090404040707"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ea07e378-3f07-48be-459d-08d6b16e7537
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 22:08:49.2860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5702
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:08:54 -0000

--------------ms030400000909090404040707
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 2019. 03. 25. 14:29, Joe Clarke
      wrote:
    

    

      
To the point about yang-data=
-ext/structure, I see instance data was very
useful, but it's a must to be able to augment its metadata.  YANG
Catalog would use that.  If this draft moves forward without
sx:structure, then I think it would need to be straight YANG so that
augments will work (i.e., a schema element would exist to augment).
=

    

    BALAZS: Fully agree. As it is more correct to=

      use data-ext/structure I will keep it that way. If there is=C2=A0 a=

      problem I will make it "straight" yang. I don't see "structure" as
      vital, but somewhat more correct.
    

      
A few other comments (minor)=
:

Section 2.1:

"P2 Re-use existing formats similar to the <get> operation/request"=


Isn't the format similar to a <get> _response_ versus the request?<=
/pre>
    

    BALAZS: Will be corrected.
    
    

      
=3D=3D=3D

Section 3

s/and and/and/

    

    BALAZS: corrected

    

      

Joe

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


    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms030400000909090404040707
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIyMDg0Nlow
LwYJKoZIhvcNAQkEMSIEICDjZ9Axr/orcG2dwQeU7zLpWfABjW15+fGIbreOWtRNMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBADzkYwBn5ZlHAFrm8JQhXQo97p9grcUNyievP9ccSFDSW7jx
WBxdaGuol5s/WobJNzWwhTo6HElPBbOc+HlHZ/CEmK+2z67f2S+W/4bnJxGrsDn3nGnGnDp/
rBh29kTRy4L5jvH4fJPfNnyN8bILjF74qOHI1fmUZzbRhTiWZ8Zse00RtmVO7MOgfNmRGS8n
FtcKB3F93SkFGBHzsrC3DEGePHVez1SnYQaostSIQrOxQV+YUKtLac1juX+j9m/YbdgrkqJ0
QfJxtGrkV4rHEuQAkMSLQS6VqQVIlQMTPb2rQ+x0KBAK5zdAYFORwfjD2aI+gyxvuCKgK3lS
mY3D/xIAAAAAAAA=

--------------ms030400000909090404040707--


From nobody Mon Mar 25 15:11:07 2019
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 9D538120115 for ; Mon, 25 Mar 2019 15:11:04 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 q7Mf_ewJvCzi for ; Mon, 25 Mar 2019 15:11:02 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 E4CEC120005 for ; Mon, 25 Mar 2019 15:11:01 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id b7so2607077lfg.9 for ; Mon, 25 Mar 2019 15:11:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iU8egfBVTeMe9u0YMm8F4YDB9zRdmTMsXuJqfuDxV6s=; b=GD2cOtpJ85fslCmm+Uqh7GsmZqs5GedAIcC+4fxgyaaTlPxRbi8Sl0gQrMujMPy7ly +UTzZTX4yl36AnLKRL1A/ZnDLpLGhddzN6sQybv19bAKiRbsH+cknTkr90hq+wt7goPj fWykamO5yAH62Q1YJ5xwTnTPmzIC6wrOBDLb/EhMdtLW+2VP09B6lD7+TtYUnVXiMT+B 2HavJNeVeX3myrwBY0x54qeWxFcwP66QXSr2USH+ZVbp0TKf9uqMcmmUv+vbFsFuFSJG x3dkKexktzaFwapH0aUaoAu28/4mqqKE0aXfQ59ffrb2Uz/VcTuUK8OXFm4IIM0DTVL+ BWJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iU8egfBVTeMe9u0YMm8F4YDB9zRdmTMsXuJqfuDxV6s=; b=RvTvhw4w7JuQSv7mksUfIC12YBZzIQujspEGMznvNoYkObqeqJ1D0nnmbvm7TBuc7B i/1EN23PDJ6BwmMBnI+ZUy03h5DNoMGsLc/GR3jhtZssmGP+wm5XPjtn12PH7b/espqh rTs8wEuHt+N9MkaH9VAY/k7k+NuXuiQptutCmzkdzMRJn0TBX1OJTq80cUkYVjpIpgA/ ZnkAGif6Dx85XjQ7DGLlcuWLKW/kAMcntnIrZtgvQbtdvO2RlVKDFYXW+4h5GpsT8EFZ JmV7zdLjHlUnmJzeRAirIEwZEfFcgC3gOZSPjR4ue2sIgC/7p6RmbOBMs8w4Mj14Shcr GpMg==
X-Gm-Message-State: APjAAAUUZPAK9YxGS3KQ8dfIl6J0z9ulurz/2X5pnuFyJdpfT+XzR1M3 gP3I+ZZssQj4kKH+6PeRbiVwnNpuIprnKOtiXtBoxA==
X-Google-Smtp-Source: APXvYqwoejQRjiqn9tMyRZt+oj6VuAqcOndpxgH6IOEtvziUwqSailJLg84wvDCq8IghhGSCLiwbTzzojlpW266KVC0=
X-Received: by 2002:ac2:489a:: with SMTP id x26mr1263300lfc.49.1553551859893;  Mon, 25 Mar 2019 15:10:59 -0700 (PDT)
MIME-Version: 1.0
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
From: Andy Bierman 
Date: Mon, 25 Mar 2019 15:10:48 -0700
Message-ID: 
To: Kent Watsen 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000bfdf3a0584f27a9d"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:11:05 -0000

--000000000000bfdf3a0584f27a9d
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 25, 2019 at 1:35 PM Kent Watsen  wrote:

> This email begins a 2-week adoption poll for:
>
>     https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
>
> Please voice your support or objections before April 8.
>
>

I have significant concerns about this draft and work item.
The intentions are good and the scope is well-defined.
The problem is that this is a very proprietary implementation detail.

I have already raised the issue that our server cannot factory reset a
single datastore.
It can only do that for the whole server (which will setup the datastores
in an implementation manner and order). So another RPC is needed, and
if-features.

I have seen some comments on this issue: "This is great but our server
does not work that way, so we need X,Y,Z"  (Just like I am doing ;-)
How will the WG keep that from happening 10 or 30 times?

I support this work if the WG can figure out how to keep it simple.
(Meaning I support adoption of the work but not going to wait 2+ years for
it)


Kent (and Lou)
>

Andy


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

--000000000000bfdf3a0584f27a9d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



I have significant concerns about this draft=
 and work item.
The intentions are good and the scope is well-def=
ined.
The problem is that this is a very proprietary implementati=
on detail.

I have already raised the issue that ou=
r server cannot factory reset a single datastore.
It can only do =
that for the whole server (which will setup the datastores
in an =
implementation manner and order). So another RPC is needed, and if-features=
.

I have seen some comments on this issue: "T=
his is great but our server
does not work that way, so we need X,=
Y,Z"=C2=A0 (Just like I am doing ;-)
How will the WG keep th=
at from happening 10 or 30 times?

I support this w=
ork if the WG can figure out how to keep it simple.
(Meaning I su=
pport adoption of the work but not going to wait 2+ years for it)
=



Kent (and Lou)
=


Andy
=C2=A0
______________________=
_________________________

netmod mailing list

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




--000000000000bfdf3a0584f27a9d--


From nobody Mon Mar 25 15:16:16 2019
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 648B9120115 for ; Mon, 25 Mar 2019 15:16:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 SQAC0OwGJ7NL for ; Mon, 25 Mar 2019 15:16:13 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46B6120005 for ; Mon, 25 Mar 2019 15:16:12 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8289D6F4; Mon, 25 Mar 2019 23:16:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 5K369dSEKPBM; Mon, 25 Mar 2019 23:16:11 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Mar 2019 23:16:11 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45596200AA; Mon, 25 Mar 2019 23:16:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 8u9OPlNH6DcY; Mon, 25 Mar 2019 23:16:11 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id D394C200A8; Mon, 25 Mar 2019 23:16:10 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 25 Mar 2019 23:16:10 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 0E89F30078E86C; Mon, 25 Mar 2019 23:16:09 +0100 (CET)
Date: Mon, 25 Mar 2019 23:16:09 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: "netmod@ietf.org" 
Message-ID: <20190325221609.hiuif4fafhheynok@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  "netmod@ietf.org" 
References: <20190325131903.rc2opwhwqgzsdfv2@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] instance data new backward compatibility text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:16:15 -0000

On Mon, Mar 25, 2019 at 09:59:43PM +0000, Bal=E1zs Lengyel wrote:
> Hello Jurgen,
>=20
> You are right that this is important mostly for instance data prepared =
as a
> design/implementation activity; while not relevant for data coming from=
 the
> node.
> I will add it.
>=20
> However in the first case it is vital!
>=20
> For config files, and also for file documenting server capabilities we =
have
> had MANY problems with people changing the key values/identities of lis=
t
> entries.
> They think it is a nice idea to provide better, more meaningful key val=
ues;
> however the NMS designers use these key values to detect changes; also
> during an upgrade process if a default configuration file is loaded aga=
in
> with slightly changed key values, then e.g. access control rules become
> duplicated.
>

The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.

/js

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


From nobody Mon Mar 25 15:19:13 2019
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 4B15E120115 for ; Mon, 25 Mar 2019 15:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 5Ki9eSn0uEK1 for ; Mon, 25 Mar 2019 15:19:09 -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 2B6CE120005 for ; Mon, 25 Mar 2019 15:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14326; q=dns/txt; s=iport; t=1553552349; x=1554761949; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m9pTnAGbG7pWgQ4AMsHvDRZ70+3qg4XAR5dIheQxJc4=; b=iOo5ZwfGHhcYutnaZShRkpkGdfPQzXgghVr0fAtW2zxXCjyhgkX5lUUS l/TJy15kuruEyr+GEslSJ+AvQ7PL5iWY07+6vrT8NhaGqXyDVD3aN3EbI 1g85SbgWpSEo6vSkLhwbfONCe7Hpq7GtcPOAmmKt5eCv2UJt5jMV7DwNZ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACNU5lc/5JdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ6BAmiBAycKhASIHI0vkkOFdxSBZw0?= =?us-ascii?q?BARgBCoQDRgIXhHsiNAkNAQEDAQEJAQMCbRwMhUoBAQEBAwEBIQpBCxACAQg?= =?us-ascii?q?RBAEBKAMCAgIlCxQJCAIEAQ0FCIMbgRFkD65BgS+ENAKFdAWBLwGLMReBQD+?= =?us-ascii?q?DbjU+gmEBAQIBgSsBEgEIAUyCVIJXA4xwhB+UBwkCh2GECodEIYIChXyMAIs?= =?us-ascii?q?cgReEbo0lAhEVgS4fOGVxcBU7gmyLDIU/QTGNbYEfgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,270,1549929600";  d="scan'208,217";a="536157584"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 22:19:07 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2PMJ7Lg014885 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 22:19:07 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Mar 2019 17:19:06 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Mon, 25 Mar 2019 17:19:06 -0500
From: "Rob Wilton (rwilton)" 
To: Andy Bierman , Kent Watsen 
CC: NetMod WG 
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AQHU40pAE0rZobHHcEaspplVrDxwYKYdPHAA//+t2cA=
Date: Mon, 25 Mar 2019 22:19:06 +0000
Message-ID: 
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com> 
In-Reply-To: 
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.61.79.96]
Content-Type: multipart/alternative; boundary="_000_f1ea969236984b7c982a1e4b26182da0XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:19:11 -0000

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

SWYgeW91IGRvIGEgZmFjdG9yeSByZXNldCwgZG9lcyB0aGF0IGFsc28gbWVhbiB0aGF0IHRoZSBk
ZXZpY2Ugc2hvdWxkIGJlIHJlYm9vdGVkIGF0IHRoZSBzYW1lIHRpbWUgdG8gZ2V0IGl0IGludG8g
YSBjb25zaXN0ZW50IHN0YXRlPw0KDQpPciBzaG91bGQgY2xpZW50cyBoYXZlIHRoZSBvcHBvcnR1
bml0eSB0byB1cGRhdGUgdGhlIGNvbmZpZyBhZnRlciB0aGUgcmVzZXQgYW5kIGJlZm9yZSBpdCBo
YXMgYmVlbiByZWJvb3RlZD8NCg0KT3IgaXMgaXQgbm90IG5lY2Vzc2FyeSB0byByZWJvb3QgdGhl
IGRldmljZSBhdCBhbGw/DQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IG5ldG1vZCA8bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IDI1IE1h
cmNoIDIwMTkgMjM6MTENClRvOiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQpD
YzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gQWRv
cHRpb24gcG9sbCBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMg0KDQoNCg0K
T24gTW9uLCBNYXIgMjUsIDIwMTkgYXQgMTozNSBQTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdh
dHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+PiB3cm90ZToNClRoaXMgZW1h
aWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQogICAgaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDINCg0KUGxl
YXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb25zIGJlZm9yZSBBcHJpbCA4Lg0KDQoN
Cg0KSSBoYXZlIHNpZ25pZmljYW50IGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQgYW5kIHdvcmsg
aXRlbS4NClRoZSBpbnRlbnRpb25zIGFyZSBnb29kIGFuZCB0aGUgc2NvcGUgaXMgd2VsbC1kZWZp
bmVkLg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0aGlzIGlzIGEgdmVyeSBwcm9wcmlldGFyeSBpbXBs
ZW1lbnRhdGlvbiBkZXRhaWwuDQoNCkkgaGF2ZSBhbHJlYWR5IHJhaXNlZCB0aGUgaXNzdWUgdGhh
dCBvdXIgc2VydmVyIGNhbm5vdCBmYWN0b3J5IHJlc2V0IGEgc2luZ2xlIGRhdGFzdG9yZS4NCkl0
IGNhbiBvbmx5IGRvIHRoYXQgZm9yIHRoZSB3aG9sZSBzZXJ2ZXIgKHdoaWNoIHdpbGwgc2V0dXAg
dGhlIGRhdGFzdG9yZXMNCmluIGFuIGltcGxlbWVudGF0aW9uIG1hbm5lciBhbmQgb3JkZXIpLiBT
byBhbm90aGVyIFJQQyBpcyBuZWVkZWQsIGFuZCBpZi1mZWF0dXJlcy4uDQoNCkkgaGF2ZSBzZWVu
IHNvbWUgY29tbWVudHMgb24gdGhpcyBpc3N1ZTogIlRoaXMgaXMgZ3JlYXQgYnV0IG91ciBzZXJ2
ZXINCmRvZXMgbm90IHdvcmsgdGhhdCB3YXksIHNvIHdlIG5lZWQgWCxZLFoiICAoSnVzdCBsaWtl
IEkgYW0gZG9pbmcgOy0pDQpIb3cgd2lsbCB0aGUgV0cga2VlcCB0aGF0IGZyb20gaGFwcGVuaW5n
IDEwIG9yIDMwIHRpbWVzPw0KDQpJIHN1cHBvcnQgdGhpcyB3b3JrIGlmIHRoZSBXRyBjYW4gZmln
dXJlIG91dCBob3cgdG8ga2VlcCBpdCBzaW1wbGUuDQooTWVhbmluZyBJIHN1cHBvcnQgYWRvcHRp
b24gb2YgdGhlIHdvcmsgYnV0IG5vdCBnb2luZyB0byB3YWl0IDIrIHllYXJzIGZvciBpdCkNCg0K
DQpLZW50IChhbmQgTG91KQ0KDQpBbmR5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQo=

--_000_f1ea969236984b7c982a1e4b26182da0XCHRCD007ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHlvdSBkbyBhIGZhY3Rv
cnkgcmVzZXQsIGRvZXMgdGhhdCBhbHNvIG1lYW4gdGhhdCB0aGUgZGV2aWNlIHNob3VsZCBiZSBy
ZWJvb3RlZCBhdCB0aGUgc2FtZSB0aW1lIHRvIGdldCBpdCBpbnRvIGEgY29uc2lzdGVudCBzdGF0
ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9yIHNob3VsZCBjbGll
bnRzIGhhdmUgdGhlIG9wcG9ydHVuaXR5IHRvIHVwZGF0ZSB0aGUgY29uZmlnIGFmdGVyIHRoZSBy
ZXNldCBhbmQgYmVmb3JlIGl0IGhhcyBiZWVuIHJlYm9vdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+T3IgaXMgaXQgbm90IG5lY2Vzc2FyeSB0byByZWJvb3QgdGhl
IGRldmljZSBhdCBhbGw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5U
aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJvYjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
IG5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBNYXJjaCAyMDE5IDIzOjExPGJy
Pg0KPGI+VG86PC9iPiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0
Ozxicj4NCjxiPkNjOjwvYj4gTmV0TW9kIFdHICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC13dS1u
ZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDE6MzUgUE0g
S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JTJCaWV0ZkB3YXRzZW4ubmV0Ij5r
ZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRoaXMgZW1haWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz
cDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdC0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyPC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugdm9p
Y2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbnMmbmJzcDtiZWZvcmUgQXByaWwgOC48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHNpZ25pZmlj
YW50IGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQgYW5kIHdvcmsgaXRlbS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbnRlbnRpb25zIGFy
ZSBnb29kIGFuZCB0aGUgc2NvcGUgaXMgd2VsbC1kZWZpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gaXMgdGhhdCB0aGlz
IGlzIGEgdmVyeSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhbHJlYWR5
IHJhaXNlZCB0aGUgaXNzdWUgdGhhdCBvdXIgc2VydmVyIGNhbm5vdCBmYWN0b3J5IHJlc2V0IGEg
c2luZ2xlIGRhdGFzdG9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkl0IGNhbiBvbmx5IGRvIHRoYXQgZm9yIHRoZSB3aG9sZSBzZXJ2ZXIgKHdo
aWNoIHdpbGwgc2V0dXAgdGhlIGRhdGFzdG9yZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIGFuIGltcGxlbWVudGF0aW9uIG1hbm5lciBhbmQg
b3JkZXIpLiBTbyBhbm90aGVyIFJQQyBpcyBuZWVkZWQsIGFuZCBpZi1mZWF0dXJlcy4uPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBz
ZWVuIHNvbWUgY29tbWVudHMgb24gdGhpcyBpc3N1ZTogJnF1b3Q7VGhpcyBpcyBncmVhdCBidXQg
b3VyIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+ZG9lcyBub3Qgd29yayB0aGF0IHdheSwgc28gd2UgbmVlZCBYLFksWiZxdW90OyZuYnNw
OyAoSnVzdCBsaWtlIEkgYW0gZG9pbmcgOy0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgd2lsbCB0aGUgV0cga2VlcCB0aGF0IGZyb20gaGFw
cGVuaW5nIDEwIG9yIDMwIHRpbWVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgdGhpcyB3b3JrIGlmIHRoZSBXRyBjYW4gZmln
dXJlIG91dCBob3cgdG8ga2VlcCBpdCBzaW1wbGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oTWVhbmluZyBJIHN1cHBvcnQgYWRvcHRpb24gb2Yg
dGhlIHdvcmsgYnV0IG5vdCBnb2luZyB0byB3YWl0IDImIzQzOyB5ZWFycyBmb3IgaXQpPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50IChhbmQgTG91KTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
Pm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_f1ea969236984b7c982a1e4b26182da0XCHRCD007ciscocom_--


From nobody Mon Mar 25 15:35:23 2019
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 6FF51120130 for ; Mon, 25 Mar 2019 15:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fm0qmBMcNcOl for ; Mon, 25 Mar 2019 15:35:18 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 81273120133 for ; Mon, 25 Mar 2019 15:35:17 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id v13so9354465ljk.4 for ; Mon, 25 Mar 2019 15:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oS40r83sH12Bw/3NLQ50D/LzemZ5NhE1NTc6RPJRM4s=; b=JJ7Zn2O3rvF/P0w7/dhw0ep5GV4QoTDHQTzV50ytu896oxSRRgg4sfwEpCiirbZpUZ xKTbzi4RAtFduo5hpDtKuz/+lVAfq3TSnZam1DEhstNxLOpwfGN8nrd7LZ3aYnDhbSVe G7v+UprtRwVgVTCXHHbHOHnk7bCnCnoHRdedbv7ny2GKt7rnzLsO3StJ7hz3d4nFJJZk uvhi38xkU6CvS7WTYyKVGYV9M06FDd6GQX3h0H1RYsz1sy1DiIgQHO6YDlYTYog6eYFH YaLgBW448k24KFW6otMHi4Y0B2akaMHmrZ7b0tjT7M0U8xNl6l6ohs+OwqLO3LapSbTK QHtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oS40r83sH12Bw/3NLQ50D/LzemZ5NhE1NTc6RPJRM4s=; b=UM4jAlPO+OKlYoOtrYJ/1qt2SMYCLhnU1j4vI7wJbtM3ee5nVbOi05gxw5CkhMwQB6 38HHs7v0qyYWGo/vfzrSLHkKeDDtgzcDYKwFu4bO+HoqKPqzBqGCOAlNRmp8PTl63V03 2dIdoB4ecU648CzMPSxW1VcBpT+mNb0rjHF1BLK8G4Q3qAFfhpYRahnEphlEefEu7Vrh SAqavC0oqsSxw51+rmVaHAd9MmqtRq4XrtCdhXZ+SOy0RUOeIXJoaHNbrKQptJlL1J/M 7TZu8I+V3ZRj2ijXV0FmkZyfsQuQSIjAhtDPlSsYx25nRbz6+ow2v1nsDGrURqlduy/H fjTg==
X-Gm-Message-State: APjAAAXCSqL4ECCDMFBUCXWIrZFU+4epDsirPNTk+F8S05kI7Ej9uzJy QkmLiRT5KZEN2lHiVD073UgR1S2jMoi1VRo7C3wuyw==
X-Google-Smtp-Source: APXvYqwPoKBCVYGlgdxQltUd7X2eEQiOhw4E8CZ5wQuogp6kHWqRuVU8uck2o3lUuIIA3OgXcAcwxD9r5e6S74L40Ag=
X-Received: by 2002:a2e:8616:: with SMTP id a22mr14743498lji.173.1553553315604;  Mon, 25 Mar 2019 15:35:15 -0700 (PDT)
MIME-Version: 1.0
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>  
In-Reply-To: 
From: Andy Bierman 
Date: Mon, 25 Mar 2019 15:35:04 -0700
Message-ID: 
To: "Rob Wilton (rwilton)" 
Cc: Kent Watsen , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000008443090584f2d116"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:35:21 -0000

--0000000000008443090584f2d116
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 25, 2019 at 3:19 PM Rob Wilton (rwilton) 
wrote:

> If you do a factory reset, does that also mean that the device should be
> rebooted at the same time to get it into a consistent state?
>
>
>
> Or should clients have the opportunity to update the config after the
> reset and before it has been rebooted?
>
>
>
> Or is it not necessary to reboot the device at all?
>
>
>


I have not seen factory reset of datastores supported at all.
It is always the service or the device.
Sound like you are talking about the SysVinit command "reload" vs.
"restart".

IMO it would be a good goal to support this framework by providing
factory-reload and factory-restart RPC operations.


Thanks,
>
> Rob
>

Andy


>
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* 25 March 2019 23:11
> *To:* Kent Watsen 
> *Cc:* NetMod WG 
> *Subject:* Re: [netmod] Adoption poll for
> draft-wu-netmod-factory-default-02
>
>
>
>
>
>
>
> On Mon, Mar 25, 2019 at 1:35 PM Kent Watsen  wrote:
>
> This email begins a 2-week adoption poll for:
>
>
>
>     https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
>
>
>
> Please voice your support or objections before April 8.
>
>
>
>
>
>
>
> I have significant concerns about this draft and work item.
>
> The intentions are good and the scope is well-defined.
>
> The problem is that this is a very proprietary implementation detail.
>
>
>
> I have already raised the issue that our server cannot factory reset a
> single datastore.
>
> It can only do that for the whole server (which will setup the datastores
>
> in an implementation manner and order). So another RPC is needed, and
> if-features..
>
>
>
> I have seen some comments on this issue: "This is great but our server
>
> does not work that way, so we need X,Y,Z"  (Just like I am doing ;-)
>
> How will the WG keep that from happening 10 or 30 times?
>
>
>
> I support this work if the WG can figure out how to keep it simple.
>
> (Meaning I support adoption of the work but not going to wait 2+ years for
> it)
>
>
>
>
>
> Kent (and Lou)
>
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

--0000000000008443090584f2d116
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 25, 2019 at 3:19 PM Rob W=
ilton (rwilton) <rwilton@cisco.com<=
/a>> wrote:











If you do a factory reset, does that also me=
an that the device should be rebooted at the same time to get it into a con=
sistent state?


=C2=A0


Or should clients have the opportunity to up=
date the config after the reset and before it has been rebooted?<=
/u>


=C2=A0


Or is it not necessary to reboot the device =
at all?


=C2=A0


I have not seen factory reset of da=
tastores supported at all.
It is always the service or the device=
.
Sound like you are talking about the SysVinit command "rel=
oad" vs. "restart".

IMO it would be=
 a good goal to support this framework by providing
factory-reloa=
d and factory-restart RPC operations.




Thanks,


Rob


=C2=A0


=C2=A0








From: netmod <netmod-bounces@ietf.org>
On Behalf Of Andy Bierman

Sent: 25 March 2019 23:11

To: Kent Watsen <kent+ietf@watsen.net>

Cc: NetMod WG <netmod@ietf.org>

Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-defa=
ult-02






=C2=A0






=C2=A0




=C2=A0






On Mon, Mar 25, 2019 at 1:35 PM Kent Watsen <kent+ietf@watsen.ne=
t> wrote:












This email begins a 2-week adoption poll for:=







=C2=A0







=C2=A0






Please voice your support or objections=C2=A0before =
April 8.






=C2=A0
















=C2=A0






=C2=A0






I have significant concerns about this draft and wor=
k item.






The intentions are good and the scope is well-define=
d.






The problem is that this is a very proprietary imple=
mentation detail.






=C2=A0






I have already raised the issue that our server cann=
ot factory reset a single datastore.






It can only do that for the whole server (which will=
 setup the datastores






in an implementation manner and order). So another R=
PC is needed, and if-features..






=C2=A0






I have seen some comments on this issue: "This =
is great but our server






does not work that way, so we need X,Y,Z"=C2=A0=
 (Just like I am doing ;-)






How will the WG keep that from happening 10 or 30 ti=
mes?






=C2=A0






I support this work if the WG can figure out how to =
keep it simple.






(Meaning I support adoption of the work but not goin=
g to wait 2+ years for it)






=C2=A0






=C2=A0
















Kent (and Lou)
















=C2=A0






Andy






=C2=A0






_______________________________________________

netmod mailing list

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

















--0000000000008443090584f2d116--


From nobody Mon Mar 25 15:36:49 2019
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 223C1120130 for ; Mon, 25 Mar 2019 15:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0ylju7C-TIKI for ; Mon, 25 Mar 2019 15:36:44 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::60e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D826120047 for ; Mon, 25 Mar 2019 15:36:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DoFCbZCAG6FvgcZB4FSVZQWOo+nStQ1tdK7o6nC7TJ4=; b=Ifqfhr0UKlG9ZJB5R5vB2L+UMslWp/udwxzdDoEYl+YvnqxY039+oXXWj0lT/Iha36EIA2hbZim3NsDXyoUpp19fNQICk58gPMkcN8k+MNXwUZtPfLAYJyZczvtotGoeRp+nQHMYpohiy+77HO1ZiaTGCQrn/iJnoO28VOiP1FE=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB4021.eurprd07.prod.outlook.com (52.134.114.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 22:36:42 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 22:36:42 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] Comments on instance data draft rev -02 - Change target-module to what name?
Thread-Index: AQHU41s4cGcIcEr8ek2bLhHlcXotkw==
Date: Mon, 25 Mar 2019 22:36:42 +0000
Message-ID: <9b9aebc0-3f72-9724-4a0b-c3587d16b65d@ericsson.com>
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
In-Reply-To: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1PR09CA0066.eurprd09.prod.outlook.com (2603:10a6:7:3c::34) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: abd74080-dbf3-4839-8b10-08d6b1725a5f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB4021; 
x-ms-traffictypediagnostic: AM6PR07MB4021:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(136003)(39860400002)(189003)(199004)(52116002)(6486002)(85202003)(386003)(86362001)(14454004)(316002)(106356001)(229853002)(478600001)(6506007)(6246003)(2501003)(65826007)(65956001)(65806001)(110136005)(256004)(31696002)(76176011)(105586002)(64126003)(66066001)(6436002)(186003)(99286004)(53936002)(7736002)(486006)(236005)(71200400001)(85182001)(6512007)(31686004)(54896002)(5660300002)(2906002)(26005)(68736007)(25786009)(476003)(99936001)(58126008)(71190400001)(446003)(2616005)(6116002)(11346002)(36756003)(3846002)(97736004)(102836004)(8936002)(81166006)(81156014)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4021; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6b2+cvYqhgxjkKbQP73F74fsk7prnoX3E6s07dGHOC9mAQoegfRIiJPCTNHxq8cXIJsUAE7+s0hASMWHRkEtwhy6VC8zhdmWpxUF3NYmdvtuaQ4MSVuVpODQwNT2j9V8h1VTXKM2i6lHMz14xhOQpzDFVt8Pw3EQ79Mbm0WI/twRpyJPUNBCM05m7waZEUwdq950qXWoa6/88NicpqDmo+2Nlzsfa9s9OZUDVyiBo1OUda8rxtB8Wleis5xA+O8Aoh8AE5XiA0Ubh866QhBGq0Oa5WtpU1QC1yUpV7diWptuzwS+Mh63XYkcRR3+mtNDK3IwT8/XUexkia36YM+Y0Q4MCiZnLuuvDbFFBMvEpLXDpVI4eM0sQEQJiuEslSKG7Ez/EbZY7hnM1gErtoYsma00zuVK0PAS1yipR+PiQrs=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208090900070704080908"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: abd74080-dbf3-4839-8b10-08d6b1725a5f
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 22:36:42.2434 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4021
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02 - Change target-module to what name?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:36:47 -0000

--------------ms020208090900070704080908
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
While I agree that target might not be the best name, I want a
      name that describes that 

      "these are the modules I am providing instance data for".

    
I propose to use the terms:

      "content-schema" and "content defining Yang
          module(s)" (Sometimes I need to refer them
      individually.)

    

    
Just schema is a too generic word. It does not tell you which
      schema are we speaking about? The schema for=C2=A0
      ietf-yang-instance-data,or=C2=A0 the schema just for the content pa=
rt?
      Are we speaking about individual modules or the collection of all
      target modules?

    

    
regards Balazs

    

    
On 2019. 03. 25. 14:29, Joe Clarke
      wrote:

    

    

      
First, I agree with J=C3=BCr=
gen that the "target" terminology confused me,
especially so given you have target-module and inline-target-spec.  Like
J=C3=BCrgen and Rob said, "schema" seems to work better.  And maybe
"inline-schema-module-spec" would be clearer that the spec modifies the
modules from which the schema is generated.

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms020208090900070704080908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIyMzYzOFow
LwYJKoZIhvcNAQkEMSIEIKun017O9ZhXIDDxgfYfeYXGwxw5U3CszGsln9HA+QhxMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAMmGTaMe01a6HOa0UQXZtNosKFyuPrAQpisyt9eqIOm3TjlB
SjKqVscJoHS9sm/1CHrW/Gjk7x3cEJv3hboPExbfN1vGml1iM6YOCvwsMKnGHwttrgtpQPTI
DKKHOHuBxKXk6mQM0DZ9nxTwR/oU7/goLf8hWWCgETNN7wA01CNcVLVy0CfRR9ht0bTNvueQ
7a8L1VYJ2zs9RpJC/Ee/bMBjeUEh8556EchcN/p09mlUlRHepU4+MYThqwE3Mt9DjdHNQTUD
t5hZ6A2Of/rHUX8SBHcukd8iiVW4cYo9HBWpnwQHiHthDo1dhq1yugP0HfZ+8ANSoKuVEVcC
9c+Go9wAAAAAAAA=

--------------ms020208090900070704080908--


From nobody Mon Mar 25 15:39:52 2019
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 EC327120130 for ; Mon, 25 Mar 2019 15:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.311
X-Spam-Level: **
X-Spam-Status: No, score=2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 mB8XullP670O for ; Mon, 25 Mar 2019 15:39:49 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40084.outbound.protection.outlook.com [40.107.4.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC8C120135 for ; Mon, 25 Mar 2019 15:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/OZQkcM3ZwEtJR1k5m1qOzUDuJmt1CXEEWaIC/ke+YU=; b=QIAG8bYDuFZfYfVIIOx87iig0av3auPZRN249AB0xytGrL6B3VN4UlNxJcGIpBQy/RWH/KbW3LOaU+gto5hBbfTS6unx+892dHQ//QeuSFncZ2aVhLJ8g+HsGdxHDyEXpc4TLCOyAmhMo6cUWIipclONa0KETaArUqPYWjpGPrA=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB4021.eurprd07.prod.outlook.com (52.134.114.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 22:39:47 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 22:39:47 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Martin Bjorklund , "jclarke@cisco.com" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Comments on instance data draft rev -02
Thread-Index: AQHU41umzlAkduL7WUOU+yEHRS9aiA==
Date: Mon, 25 Mar 2019 22:39:46 +0000
Message-ID: <06a42c46-f0c9-135f-967b-c9326501b138@ericsson.com>
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com> <20190325.145200.336212787973649675.mbj@tail-f.com>
In-Reply-To: <20190325.145200.336212787973649675.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1PR0802CA0017.eurprd08.prod.outlook.com (2603:10a6:3:bd::27) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8b779cfb-b3bf-4ad0-baa6-08d6b172c86d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB4021; 
x-ms-traffictypediagnostic: AM6PR07MB4021:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(136003)(39860400002)(189003)(199004)(52116002)(6486002)(85202003)(386003)(86362001)(14454004)(316002)(106356001)(229853002)(478600001)(6506007)(6246003)(2501003)(65826007)(65956001)(65806001)(110136005)(256004)(31696002)(76176011)(105586002)(64126003)(66066001)(6436002)(186003)(99286004)(53936002)(7736002)(305945005)(486006)(71200400001)(85182001)(6512007)(31686004)(5660300002)(2906002)(26005)(68736007)(25786009)(476003)(4744005)(99936001)(58126008)(71190400001)(446003)(2616005)(6116002)(11346002)(36756003)(3846002)(97736004)(102836004)(8936002)(81166006)(81156014)(4326008)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4021; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: LPGam6owtlgCI08GdazZ03Z0tRL4ZrA2RJ214zP6gJAhtcbxUQdd0a9W9EOTElV6oyrS1+UoyIPolIN2d1ssC8RpAHEpdIgi/fZpcRGB11voCe2/ANT5I6jr3j4yWvX/C7E/+itFlAlZJ1GDyQEOYL4IxCU1Ss/5gMnPqf47b67tATwIwVi5hdp3Sx+SFR8kqnjp89yvv1+piZj3oxZy92F2G3zYlnHTi6tM/f0h4HiVNMhc3Hbf00DgbsdmWjLf1+PgeZvLTmDIz8f1RLEGeEruGxMWUw6OgSZbx33ukTLH0tTmBpac4Gu8IUTisjCMDtiItF4BwmdcsSRy4UJ1wtaZ99MfrJcoGcq22PKMtmbTStdEOM7PkEFfX4BPd9F2aZql/3Rz4qEcaEQ+hhXPg7BwYRwV9XOP+ohGlb9bcZo=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090207020301070002050207"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b779cfb-b3bf-4ad0-baa6-08d6b172c86d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 22:39:46.9158 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4021
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 22:39:51 -0000

--------------ms090207020301070002050207
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

I wanted to have an identifier for a particular instance-data-set.
name+revision-date OR timestamp should serve that purpose.

While it would be possible to use this without a name, IMHO that would=20
be a very bad practice.

Balazs

On 2019. 03. 25. 14:52, Martin Bjorklund wrote:
> And a question:  why is the "name" leaf mandatory?
>
>
> /martin

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms090207020301070002050207
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIyMzkzNVow
LwYJKoZIhvcNAQkEMSIEILMNSI3Td+P+IK6ZzaW2qBNfRGN9Z/3mwbpI8bCmxxg1MGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBABlkLWArjD/xIHPGGNhhDf/JEB+7liC8nRTRlD6iFYFVnu/l
JkVVRYy+fDwsTQBQaE2ASJ3Ccgm34reDMDSrNNXAts3OS0DfCDSX77sKWMqXCP2y6LYMUUca
FlROem7W+i8T4GJdSlMZY2Yh7htdSfsaqpf9h0BGPuZU4+vB7z8pXPaDAROcSZ7nz4gy62tl
9RD1vM+xuSEU3/3gtrpofj+gzxW4QnEuTCOPHWRigMVrA0qiDVBEB+9eKNWQUrxeg8yCErMz
1sCMmrIvdSdj7IlFeDspU38RJsHoitq9rYs1vt5uHP+RTm7hy499I1EXbrFDcftMt2w1MVhd
OMpoMNkAAAAAAAA=

--------------ms090207020301070002050207--


From nobody Mon Mar 25 16:02:03 2019
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 48DE4120150 for ; Mon, 25 Mar 2019 16:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.036
X-Spam-Level: ***
X-Spam-Status: No, score=3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DJmc3d23YlCH for ; Mon, 25 Mar 2019 16:01:58 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40048.outbound.protection.outlook.com [40.107.4.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBE5120152 for ; Mon, 25 Mar 2019 16:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=85+7mP4FQQjzBmwzzE0EtLnm2CA+DMpPYtjoY6j6xng=; b=TR6puID8urVXn3D2Wtrh3TgDpNRQ9KwMa25PpQGErB7Q8fNz97sKVwn74BlqA+pGb6gSs6rDiriBGUzA7lDTA16JdZgSl7MWq1Vj9PMLK61uoGalUfwgsjg47Ew0CnI1UTXAB0IoEEjqXxRmlpVgQy9g0lqIgoHFy/RdVu+XkGg=
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com (52.134.115.144) by AM6PR07MB5075.eurprd07.prod.outlook.com (20.177.188.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.11; Mon, 25 Mar 2019 23:01:52 +0000
Received: from AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c]) by AM6PR07MB3847.eurprd07.prod.outlook.com ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 23:01:52 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] instance data new backward compatibility text
Thread-Index: AQHU41YNtfrF2XOMeUSipLaMZQVy/KYc6gWAgAAMugA=
Date: Mon, 25 Mar 2019 23:01:52 +0000
Message-ID: <8cc2ecb9-53b8-36dc-97d9-e7ce92a27d5c@ericsson.com>
References: <20190325131903.rc2opwhwqgzsdfv2@anna.jacobs.jacobs-university.de>  <20190325221609.hiuif4fafhheynok@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190325221609.hiuif4fafhheynok@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1P190CA0002.EURP190.PROD.OUTLOOK.COM (2603:10a6:3:bc::12) To AM6PR07MB3847.eurprd07.prod.outlook.com (2603:10a6:209:31::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3abd2840-1a5b-4349-00cc-08d6b175deb2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5075; 
x-ms-traffictypediagnostic: AM6PR07MB5075:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(136003)(366004)(346002)(396003)(199004)(189003)(6486002)(1730700003)(8936002)(14454004)(478600001)(3846002)(85182001)(66574012)(65826007)(31686004)(316002)(52116002)(105586002)(71190400001)(99286004)(25786009)(58126008)(14444005)(256004)(5660300002)(76176011)(85202003)(97736004)(2906002)(106356001)(36756003)(5640700003)(53936002)(7736002)(6436002)(2616005)(11346002)(186003)(6512007)(31696002)(386003)(68736007)(236005)(54896002)(446003)(71200400001)(476003)(6506007)(64126003)(26005)(86362001)(2351001)(6116002)(65956001)(65806001)(66066001)(81156014)(2501003)(229853002)(8676002)(102836004)(81166006)(486006)(6346003)(99936001)(6246003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5075; H:AM6PR07MB3847.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: k+pncpVwZxigEH2ynCAd12bexhSwiFUBxwMy6uZUNUWcSRzDOXa9EHTu1ClbKGnKKH3pZ1ki/wT2Ohm5NTxHcLy0/6Os0Fg5Ev3rwmNHSCklLVzDz4qL/rZuJGVF/6lNgMWLJorkAUnv7x6zkBE8ZjYy/qgSaKhcOwzJJIuWwRkhLOn/A25bH1aOxtqkKJXaX7mZDCzjtOKa2AQVtjknFs9k5sH7qZZYB2LLTFWZRr9mT7tFHVtLSF5zCjqOgh+pZABBm4wZG7J1VIzLC6GPI07aG39RLx3+y0oGNJO31VVhZK1gunA67YoNgKODT4+VOE/Hr0DiW0JVTw8z54zOv53vvDcEk5/VtN6yqGTU57Njlek6PZqoFU8iKq6/2LDiCL4KBUOlkQjTi1AdZP4jc3Kzs9LZ3HcDTBlGX5dZlOY=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050105080601090402000805"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3abd2840-1a5b-4349-00cc-08d6b175deb2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 23:01:52.7042 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5075
Archived-At: 
Subject: Re: [netmod] instance data new backward compatibility text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 23:02:01 -0000

--------------ms050105080601090402000805
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hello Jurgen,

    
I don't think these rules are Ericsson specific. In some of our
      most important use-cases (UC1, UC2, UC6) changing the keys would
      lead to problems.

    
UC1: If you document server capabilities using ietf-yang-library
      the name of the module sets may be/should be meaningful. It might
      be used by the NMS to compare the capabilities of different
      versions of the YANG server; changing keys without a reason will
      mislead the NMS into assuming the server capabilities changed.. 
    
UC2: Preloading default configuration data. E.g.=C2=A0 If you chan=
ge
      the identifier of NACM ruleset, then during upgrade it might be
      loaded again as the server can not detect, that this is the same
      ruleset that is already in the datastore.

    

    
UC6:=C2=A0 Storing diagnostics data. If you change the keys used i=
n
      diagnostic data, comparing values before and after the key change
      will be difficult.

    
And yes as we were using instance data for the last then years,
      we did have a lot of problem with people changing the keys without
      considering compatibility effects.

      I agree that this is not always a problem, so I only used SHOULD=C2=
=A0
      (and not MUST) in the text.

    

    
regards Balazs

    

    
On 2019. 03. 25. 23:16, Juergen
      Schoenwaelder wrote:

    

    

      
On Mon, Mar 25, 2019 at 09:5=
9:43PM +0000, Bal=C3=A1zs Lengyel wrote:


      

        
Hello Jurgen,

You are right that this is important mostly for instance data prepared as=
 a
design/implementation activity; while not relevant for data coming from t=
he
node.
I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we ha=
ve
had MANY problems with people changing the key values/identities of list
entries.
They think it is a nice idea to provide better, more meaningful key value=
s;
however the NMS designers use these key values to detect changes; also
during an upgrade process if a default configuration file is loaded again=

with slightly changed key values, then e.g. access control rules become
duplicated.



      

      
The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.

/js



    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms050105080601090402000805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNTIzMDE0Mlow
LwYJKoZIhvcNAQkEMSIEIHhViRosM6EJccYo2XJ7zsHVHtkMfUS8leLk9z1qDrdrMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAGKj8j8rK4ri7mgDbpPnFo66lqir9ts7Q1bARWh9uznrsG+5
4yCSI2cffdjcNLyngzwodcDRsdEOreGqGHtAG4MKbZaClB4kkB8dVX8Wgrl28Mgh2kLEgsIs
CEJjIf0d0JqtbvdhZ+JfmUd4XuzijjHolpu/FoY1tycQT2MAF5/7g+PWoyaSN933AandZ/PV
aoQvma8hpoPzSDYDZBRG0LuTk91IIRgTFg4jVhFiQ7UOuOhRtY/8WZNKTTZvsXbeJ1KbXjcl
XP4Q1HNGPWboLdT03kL9UYERkf18S7F82h8iD39jf12yC8zFVTmpm+7sL5O+zAwGLJMtVD5A
1PPY1/cAAAAAAAA=

--------------ms050105080601090402000805--


From nobody Mon Mar 25 16:17:52 2019
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 5AD0B12014D for ; Mon, 25 Mar 2019 16:17:51 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 h9KosKwf30BN for ; Mon, 25 Mar 2019 16:17:49 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEC512014C for ; Mon, 25 Mar 2019 16:17:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7E1D337; Tue, 26 Mar 2019 00:17:46 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id jIkeG7-naQkI; Tue, 26 Mar 2019 00:17:46 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 00:17:46 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D81C200A8; Tue, 26 Mar 2019 00:17:46 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id nQog1fiuoeMX; Tue, 26 Mar 2019 00:17:45 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id C17A8200A7; Tue, 26 Mar 2019 00:17:45 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 00:17:45 +0100
Received: by anna.localdomain (Postfix, from userid 501) id C7ECC30078EA05; Tue, 26 Mar 2019 00:17:44 +0100 (CET)
Date: Tue, 26 Mar 2019 00:17:44 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: Joe Clarke , "netmod@ietf.org" 
Message-ID: <20190325231744.hj534aep3jbxardv@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  Joe Clarke , "netmod@ietf.org" 
References: <5f17a293-346e-b469-e78f-8933a7650db4@cisco.com> <9b9aebc0-3f72-9724-4a0b-c3587d16b65d@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <9b9aebc0-3f72-9724-4a0b-c3587d16b65d@ericsson.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Comments on instance data draft rev -02 - Change target-module to what name?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 23:17:51 -0000

For me, it seems obvious that we talk about the schema of the instance
data (content). (The other schema defining the format of the instance
data file is fixed and it would be pointless to include it.) Anyway,
we should look at the existing definitions. RFC 8342 defines:

   o  datastore schema: The combined set of schema nodes for all modules
      supported by a particular datastore, taking into consideration any
      deviations and enabled features for that datastore.

So perhaps you want to define the term 'instance data schema' or
something like that. Within the model, however, I would prefer to use
simple and short names, that is s/target/schema/.

/js

On Mon, Mar 25, 2019 at 10:36:42PM +0000, Bal=C3=A1zs Lengyel wrote:
>    While I agree that target might not be the best name, I want a name =
that
>    describes that
>    "these are the modules I am providing instance data for".
>=20
>    I propose to use the terms:
>    "content-schema" and "content defining Yang module(s)" (Sometimes I =
need
>    to refer them individually.)
>=20
>=20
>    Just schema is a too generic word. It does not tell you which schema=
 are
>    we speaking about? The schema for=C2 ietf-yang-instance-data,or=C2 t=
he schema
>    just for the content part? Are we speaking about individual modules =
or the
>    collection of all target modules?
>=20
>    regards Balazs
>=20
>    On 2019. 03. 25. 14:29, Joe Clarke wrote:
>=20
>  First, I agree with J=FCrgen that the "target" terminology confused me=
,
>  especially so given you have target-module and inline-target-spec.  Li=
ke
>  J=FCrgen and Rob said, "schema" seems to work better.  And maybe
>  "inline-schema-module-spec" would be clearer that the spec modifies th=
e
>  modules from which the schema is generated.
>=20
>  --
>  Balazs Lengyel                       Ericsson Hungary Ltd.
>  Senior Specialist
>  Mobile: +36-70-330-7909              email: [1]Balazs.Lengyel@ericsson=
.com
>=20
> References
>=20
>    Visible links
>    1. mailto:Balazs.Lengyel@ericsson.com



> _______________________________________________
> 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 Mon Mar 25 16:22:57 2019
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 BE545120156 for ; Mon, 25 Mar 2019 16:22:45 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 dY7A00pQxZoj for ; Mon, 25 Mar 2019 16:22:43 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052A3120166 for ; Mon, 25 Mar 2019 16:22:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ACEDA1F; Tue, 26 Mar 2019 00:22:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id mN1v6uJND_uo; Tue, 26 Mar 2019 00:22:41 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 00:22:41 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97692200A8; Tue, 26 Mar 2019 00:22:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 5kb5gH058O6z; Tue, 26 Mar 2019 00:22:41 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 3B0DE200A7; Tue, 26 Mar 2019 00:22:41 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 00:22:40 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 6BB6230078EA8A; Tue, 26 Mar 2019 00:22:40 +0100 (CET)
Date: Tue, 26 Mar 2019 00:22:40 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: "netmod@ietf.org" 
Message-ID: <20190325232240.ttcddrly3gnmldod@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  "netmod@ietf.org" 
References: <20190325131903.rc2opwhwqgzsdfv2@anna.jacobs.jacobs-university.de>  <20190325221609.hiuif4fafhheynok@anna.jacobs.jacobs-university.de> <8cc2ecb9-53b8-36dc-97d9-e7ce92a27d5c@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <8cc2ecb9-53b8-36dc-97d9-e7ce92a27d5c@ericsson.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] instance data new backward compatibility text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Mar 2019 23:22:55 -0000

Your rules are use case specific and I am not convinced they are
applying to all use cases. It should be a perfectly valid use case to
store snapshots of  in instance data files. Your rules do not
make sense here and I do not think this is a valid usage of the SHOULD
mechanism.

/js

On Mon, Mar 25, 2019 at 11:01:52PM +0000, Bal=C3=A1zs Lengyel wrote:
>    Hello Jurgen,
>=20
>    I don't think these rules are Ericsson specific. In some of our most
>    important use-cases (UC1, UC2, UC6) changing the keys would lead to
>    problems.
>=20
>    UC1: If you document server capabilities using ietf-yang-library the=
 name
>    of the module sets may be/should be meaningful. It might be used by =
the
>    NMS to compare the capabilities of different versions of the YANG se=
rver;
>    changing keys without a reason will mislead the NMS into assuming th=
e
>    server capabilities changed..
>=20
>    UC2: Preloading default configuration data. E.g.=C2 If you change th=
e
>    identifier of NACM ruleset, then during upgrade it might be loaded a=
gain
>    as the server can not detect, that this is the same ruleset that is
>    already in the datastore.
>=20
>    UC6:=C2 Storing diagnostics data. If you change the keys used in dia=
gnostic
>    data, comparing values before and after the key change will be diffi=
cult.
>=20
>    And yes as we were using instance data for the last then years, we d=
id
>    have a lot of problem with people changing the keys without consider=
ing
>    compatibility effects.
>    I agree that this is not always a problem, so I only used SHOULD=C2 =
(and not
>    MUST) in the text.
>=20
>    regards Balazs
>=20
>=20
>    On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:
>=20
>  On Mon, Mar 25, 2019 at 09:59:43PM +0000, Bal=E1zs Lengyel wrote:
>=20
>  Hello Jurgen,
>=20
>  You are right that this is important mostly for instance data prepared=
 as a
>  design/implementation activity; while not relevant for data coming fro=
m the
>  node.
>  I will add it.
>=20
>  However in the first case it is vital!
>=20
>  For config files, and also for file documenting server capabilities we=
 have
>  had MANY problems with people changing the key values/identities of li=
st
>  entries.
>  They think it is a nice idea to provide better, more meaningful key va=
lues;
>  however the NMS designers use these key values to detect changes; also
>  during an upgrade process if a default configuration file is loaded ag=
ain
>  with slightly changed key values, then e.g. access control rules becom=
e
>  duplicated.
>=20
>=20
>  The conditions under which it is meaningful to change keys and when it
>  is not appropriate are very application specific.  You may have
>  specific use cases at Ericsson where you want internal regulations but
>  I do not think this leads to meaningful rules outside your specific
>  application scenario.
>=20
>  /js
>=20
>=20
>  --
>  Balazs Lengyel                       Ericsson Hungary Ltd.
>  Senior Specialist
>  Mobile: +36-70-330-7909              email: [1]Balazs.Lengyel@ericsson=
.com
>=20
> References
>=20
>    Visible links
>    1. mailto:Balazs.Lengyel@ericsson.com



> _______________________________________________
> 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 Mon Mar 25 21:28:59 2019
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 A638E12024B for ; Mon, 25 Mar 2019 21:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 6fnZFINQhYOc for ; Mon, 25 Mar 2019 21:28:55 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2073E12024A for ; Mon, 25 Mar 2019 21:28:55 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DEE012E1B63D15E59EC3; Tue, 26 Mar 2019 04:28:52 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 04:28:52 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 12:28:43 +0800
From: Rohit R Ranade 
To: Kent Watsen , Qin Wu , "balazs.lengyel@ericsson.com" , Niuye 
CC: "netmod@ietf.org" 
Thread-Topic: IPR poll on draft-wu-netmod-factory-default-02
Thread-Index: AQHU40fGE9vhKk9p2EmT5u3EZOYp0aYdUf3g
Date: Tue, 26 Mar 2019 04:28:42 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BD220A8@dggeml510-mbx.china.huawei.com>
References: <7C9A4660-9BC6-4B37-AB96-9E4B33FBC44D@watsen.net> <01000169b68012f8-63de3dbd-d0a8-4276-99f7-b4073a98b97e-000000@email.amazonses.com>
In-Reply-To: <01000169b68012f8-63de3dbd-d0a8-4276-99f7-b4073a98b97e-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BD220A8dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] IPR poll on draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 04:28:58 -0000

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

Tm8sIEnigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0
Lg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdA0KDQpGcm9tOiBLZW50IFdhdHNlbiBbbWFpbHRvOmtl
bnQraWV0ZkB3YXRzZW4ubmV0XQ0KU2VudDogMjYgTWFyY2ggMjAxOSAwMTo0Nw0KVG86IFFpbiBX
dSA8YmlsbC53dUBodWF3ZWkuY29tPjsgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tOyBOaXV5
ZSA8bml1eWVAaHVhd2VpLmNvbT47IFJvaGl0IFIgUmFuYWRlIDxyb2hpdHJyYW5hZGVAaHVhd2Vp
LmNvbT4NCkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBwb2xsIG9uIGRyYWZ0LXd1
LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDINCg0KVG8gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1
dG9yIGxpc3RlZCBvbiB0aGUgIlRvIiBsaW5lLg0KDQpJbiBvcmRlciB0byBjb21wbGV0ZSB0aGUg
QWRvcHRpb24gcG9sbCwgYXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcw0KdG8g
ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMj8gIFBsZWFzZSBSZXBseS1BbGwgdG8g
KnRoaXMqIGVtYWlsIGFuZA0Kc3RhdGUgZWl0aGVyOg0KDQoiTm8sIEknbSBub3QgYXdhcmUgb2Yg
YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVzLCBJJ20gYXdhcmUg
b2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiAieWVzIiwgaGFzIHRoaXMg
SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNl
ZSBSRkNzIDM2NjksIDUzNzggYW5kIDgxNzkgZm9yIG1vcmUgZGV0YWlscyk/DQoNCklmICJ5ZXMi
IGFnYWluLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRp
c2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KIk5vLCB0aGUg
SVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBw
cm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQpJ
ZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVh
c2UgYW5zd2VyIHRoZSBhYm92ZSBieQ0KcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxl
c3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQNCklQUi4g
IFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBh
IHJlc3BvbnNlIGhhcyBiZWVuDQpyZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQg
Y29udHJpYnV0b3IuICBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMDQpPRiBZT1UgTElTVEVEIElO
IFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBs
aXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9y
DQpvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVy
IHRoZSBJRVRGIElQUiBydWxlcyB3aGljaA0KZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJ
RVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGDQpjb250cmli
dXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRp
b24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkDQp0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1v
cmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQphbmQgaHR0
cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFs
UHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCktlbnQgLy8gYXMgY28tY2hhaXINCg==

--_000_991B70D8B4112A4699D5C00DDBBF878A6BD220A8dggeml510mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls
U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAu
MHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ObywgSeKAmW0gbm90
IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PldpdGggUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvaGl0PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQmIzQzO2lldGZAd2F0
c2VuLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNiBNYXJjaCAyMDE5IDAxOjQ3PGJyPg0KPGI+
VG86PC9iPiBRaW4gV3UgJmx0O2JpbGwud3VAaHVhd2VpLmNvbSZndDs7IGJhbGF6cy5sZW5neWVs
QGVyaWNzc29uLmNvbTsgTml1eWUgJmx0O25pdXllQGh1YXdlaS5jb20mZ3Q7OyBSb2hpdCBSIFJh
bmFkZSAmbHQ7cm9oaXRycmFuYWRlQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRt
b2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSVBSIHBvbGwgb24gZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj5UbyBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IgbGlzdGVkIG9uIHRoZSAmcXVv
dDtUbyZxdW90OyBsaW5lLjxicj4NCjxicj4NCkluIG9yZGVyIHRvIGNvbXBsZXRlIHRoZSBBZG9w
dGlvbiBwb2xsLCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzPGJyPg0KdG8m
bmJzcDtkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyPyAmbmJzcDtQbGVhc2UgUmVw
bHktQWxsIHRvICp0aGlzKiBlbWFpbCBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+c3Rh
dGUgZWl0aGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQomcXVvdDtObywgSSdtIG5vdCBh
d2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7PGJyPg0Kb3I8
YnI+DQomcXVvdDtZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh
ZnQmcXVvdDs8YnI+DQo8YnI+DQpJZiAmcXVvdDt5ZXMmcXVvdDssIGhhcyB0aGlzIElQUiBiZWVu
IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM8YnI+DQooc2VlIFJG
Q3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT88YnI+DQo8YnI+DQpJZiAm
cXVvdDt5ZXMmcXVvdDsgYWdhaW4sIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PGJyPg0KPGJyPg0KJnF1
b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVU
RiBJUFIgcnVsZXMmcXVvdDs8YnI+DQpvcjxicj4NCiZxdW90O05vLCB0aGUgSVBSIGhhcyBub3Qg
YmVlbiBkaXNjbG9zZWQmcXVvdDs8YnI+DQo8YnI+DQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2Ug
cHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS48YnI+
DQo8YnI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmli
dXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieTxicj4NCnJlc3BvbmRpbmcgdG8gdGhpcyBl
bWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl
bGV2YW50PGJyPg0KSVBSLiAmbmJzcDtUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8g
dGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbjxicj4NCnJlY2VpdmVkIGZy
b20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gJm5ic3A7Tk9URTogVEhJUyBB
UFBMSUVTIFRPIEFMTDxicj4NCk9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MgVE8gTElO
RVMuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQg
V0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvcjxicj4NCm9yIGNvbnRy
aWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYg
SVBSIHJ1bGVzIHdoaWNoPGJyPg0KZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlm
IHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGPGJyPg0KY29udHJpYnV0
aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9u
IG9yIGRpc2N1c3Npb24gcmVsYXRlZDxicj4NCnRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3Ig
bW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmU8YnI+DQph
bmQmbmJzcDs8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3Ry
YWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eSI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv
Z3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHk8L2E+Ljxicj4NCjxicj4N
ClRoYW5rIHlvdSw8YnI+DQpLZW50IC8vIGFzIGNvLWNoYWlyPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_991B70D8B4112A4699D5C00DDBBF878A6BD220A8dggeml510mbxchi_--


From nobody Mon Mar 25 21:58:34 2019
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 BC3BF120258 for ; Mon, 25 Mar 2019 21:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 LZKkvxHjGk8j for ; Mon, 25 Mar 2019 21:58:27 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0CD5012025D for ; Mon, 25 Mar 2019 21:58:27 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8212BC417DC613E6C6D0 for ; Tue, 26 Mar 2019 04:58:23 +0000 (GMT)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 04:58:23 +0000
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 26 Mar 2019 04:58:22 +0000
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 26 Mar 2019 04:58:22 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 12:58:16 +0800
From: Qin Wu 
To: Andy Bierman , Kent Watsen 
CC: NetMod WG 
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AdTjj/JikYsFoUEQQeaG/6b58sFraA==
Date: Tue, 26 Mar 2019 04:58:15 +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.220.64.122]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA487E462nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 04:58:30 -0000

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

VGhhbmtzIEFuZHksIHNlZSByZXBseSBpbmxpbmUuDQoNCuWPkeS7tuS6ujogbmV0bW9kIFttYWls
dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBBbmR5IEJpZXJtYW4NCuWPkemAgeaX
tumXtDogMjAxOeW5tDPmnIgyNuaXpSA2OjExDQrmlLbku7bkuro6IEtlbnQgV2F0c2VuIDxrZW50
K2lldGZAd2F0c2VuLm5ldD4NCuaKhOmAgTogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQrk
uLvpopg6IFJlOiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC13dS1uZXRtb2QtZmFj
dG9yeS1kZWZhdWx0LTAyDQoNCg0KDQpPbiBNb24sIE1hciAyNSwgMjAxOSBhdCAxOjM1IFBNIEtl
bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCUyQmlldGZAd2F0c2Vu
Lm5ldD4+IHdyb3RlOg0KVGhpcyBlbWFpbCBiZWdpbnMgYSAyLXdlZWsgYWRvcHRpb24gcG9sbCBm
b3I6DQoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZh
Y3RvcnktZGVmYXVsdC0wMg0KDQpQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlv
bnMgYmVmb3JlIEFwcmlsIDguDQoNCg0KDQpJIGhhdmUgc2lnbmlmaWNhbnQgY29uY2VybnMgYWJv
dXQgdGhpcyBkcmFmdCBhbmQgd29yayBpdGVtLg0KVGhlIGludGVudGlvbnMgYXJlIGdvb2QgYW5k
IHRoZSBzY29wZSBpcyB3ZWxsLWRlZmluZWQuDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoaXMgaXMg
YSB2ZXJ5IHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9uIGRldGFpbC4NCg0KSSBoYXZlIGFscmVh
ZHkgcmFpc2VkIHRoZSBpc3N1ZSB0aGF0IG91ciBzZXJ2ZXIgY2Fubm90IGZhY3RvcnkgcmVzZXQg
YSBzaW5nbGUgZGF0YXN0b3JlLg0KSXQgY2FuIG9ubHkgZG8gdGhhdCBmb3IgdGhlIHdob2xlIHNl
cnZlciAod2hpY2ggd2lsbCBzZXR1cCB0aGUgZGF0YXN0b3Jlcw0KaW4gYW4gaW1wbGVtZW50YXRp
b24gbWFubmVyIGFuZCBvcmRlcikuIFNvIGFub3RoZXIgUlBDIGlzIG5lZWRlZCwgYW5kIGlmLWZl
YXR1cmVzLi4NCltRaW5dOiBXZSBhbGxvdyB0byByZXNldCBtdWx0aXBsZSB0YXJnZXQgZGF0YXN0
b3JlIHdpdGhpbiB0aGUgc2VydmVyLCB0aGF0IG1lYW5zIHdlIGhhdmUgY2FwYWJpbGl0eSB0bw0K
UmVzZXQgYWxsIHRhcmdldCBkYXRhc3RvcmVzIGluIHRoZSBzZXJ2ZXIuIEluIHRoZSBZQU5HIG1v
ZHVsZSwgd2UgZG8gYWRkIGEgbm90ZSB0byBzYXk6DQrigJwNCiAgICAgIC8vIERvIHdlIG5lZWQg
YW4gZXh0cmEgcGFyYW1ldGVyIHRoYXQgbWF5IG9yZGVyIGEgcmVzdGFydCBvZg0KICAgICAgLy8g
dGhlIFlBTkctc2VydmVyIG9yIHRoZSB3aG9sZSBzeXN0ZW0/DQrigJ0NClNvIHRoYW5rcyBBbmR5
LCB3ZSBhcmUgYXdhcmUgdGhpcyBpc3N1ZS4NCkkgaGF2ZSBzZWVuIHNvbWUgY29tbWVudHMgb24g
dGhpcyBpc3N1ZTogIlRoaXMgaXMgZ3JlYXQgYnV0IG91ciBzZXJ2ZXINCmRvZXMgbm90IHdvcmsg
dGhhdCB3YXksIHNvIHdlIG5lZWQgWCxZLFoiICAoSnVzdCBsaWtlIEkgYW0gZG9pbmcgOy0pDQpI
b3cgd2lsbCB0aGUgV0cga2VlcCB0aGF0IGZyb20gaGFwcGVuaW5nIDEwIG9yIDMwIHRpbWVzPw0K
DQpJIHN1cHBvcnQgdGhpcyB3b3JrIGlmIHRoZSBXRyBjYW4gZmlndXJlIG91dCBob3cgdG8ga2Vl
cCBpdCBzaW1wbGUuDQooTWVhbmluZyBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIHdvcmsgYnV0
IG5vdCBnb2luZyB0byB3YWl0IDIrIHllYXJzIGZvciBpdCkNCltRaW5dOiBUaGFua3MsIHRoYXQg
aXMgYWxzbyB0aGUgZ29hbCB3ZSBzZXQgZm9yIHRoaXMgZHJhZnQuDQoNCktlbnQgKGFuZCBMb3Up
DQoNCkFuZHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll
dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==

--_000_B8F9A780D330094D99AF023C5877DABAA487E462nkgeml513mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN
CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg
MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj
bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh
bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG
NDk3RDt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8
jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg
6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5UaGFua3MgQW5keSwgc2VlIHJlcGx5IGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9
r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv
c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IG5ldG1v
ZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz
YW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu
cy1zZXJpZiI+QW5keSBCaWVybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm
Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl
vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMTk8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt
c2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4zPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT
Ij4yNjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogNjoxMTxicj4NCjwvc3Bhbj48Yj7m
lLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi
PiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ozxicj4NCjwvc3Bh
bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t
VVMiPiBOZXRNb2QgV0cgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8L3NwYW4+PGI+5Li7
6aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6
IFtuZXRtb2RdIEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1
bHQtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgTWFyIDI1LCAyMDE5
IGF0IDE6MzUgUE0gS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JTJCaWV0ZkB3
YXRzZW4ubmV0Ij5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBlbWFpbCBiZWdp
bnMgYSAyLXdlZWsgYWRvcHRpb24gcG9sbCBmb3I6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMiIg
dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRt
b2QtZmFjdG9yeS1kZWZhdWx0LTAyPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb25z
Jm5ic3A7YmVmb3JlIEFwcmlsIDguPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+SSBoYXZlIHNpZ25pZmljYW50IGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQgYW5kIHdvcmsg
aXRlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGludGVudGlvbnMgYXJlIGdvb2QgYW5kIHRo
ZSBzY29wZSBpcyB3ZWxsLWRlZmluZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcm9ibGVt
IGlzIHRoYXQgdGhpcyBpcyBhIHZlcnkgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb24gZGV0YWls
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZl
IGFscmVhZHkgcmFpc2VkIHRoZSBpc3N1ZSB0aGF0IG91ciBzZXJ2ZXIgY2Fubm90IGZhY3Rvcnkg
cmVzZXQgYSBzaW5nbGUgZGF0YXN0b3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCBjYW4gb25s
eSBkbyB0aGF0IGZvciB0aGUgd2hvbGUgc2VydmVyICh3aGljaCB3aWxsIHNldHVwIHRoZSBkYXRh
c3RvcmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmluIGFuIGltcGxlbWVudGF0aW9uIG1hbm5lciBh
bmQgb3JkZXIpLiBTbyBhbm90aGVyIFJQQyBpcyBuZWVkZWQsIGFuZCBpZi1mZWF0dXJlcy4uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUWluXTogV2UgYWxsb3cg
dG8gcmVzZXQgbXVsdGlwbGUgdGFyZ2V0IGRhdGFzdG9yZSB3aXRoaW4gdGhlIHNlcnZlciwgdGhh
dCBtZWFucyB3ZSBoYXZlIGNhcGFiaWxpdHkgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPlJlc2V0IGFsbCB0YXJnZXQgZGF0YXN0b3JlcyBpbiB0aGUgc2VydmVyLiBJbiB0aGUgWUFO
RyBtb2R1bGUsIHdlIGRvIGFkZCBhIG5vdGUgdG8gc2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+4oCcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBEbyB3ZSBuZWVkIGFuIGV4dHJhIHBhcmFtZXRlciB0
aGF0IG1heSBvcmRlciBhIHJlc3RhcnQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC8vIHRoZSBZQU5HLXNlcnZlciBvciB0aGUgd2hvbGUgc3lzdGVtPzwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyB0aGFua3Mg
QW5keSwgd2UgYXJlIGF3YXJlIHRoaXMgaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2
ZSBzZWVuIHNvbWUgY29tbWVudHMgb24gdGhpcyBpc3N1ZTogJnF1b3Q7VGhpcyBpcyBncmVhdCBi
dXQgb3VyIHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kb2VzIG5vdCB3b3JrIHRoYXQgd2F5
LCBzbyB3ZSBuZWVkIFgsWSxaJnF1b3Q7Jm5ic3A7IChKdXN0IGxpa2UgSSBhbSBkb2luZyA7LSk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+SG93IHdpbGwgdGhlIFdHIGtlZXAgdGhhdCBmcm9tIGhhcHBl
bmluZyAxMCBvciAzMCB0aW1lcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPkkgc3VwcG9ydCB0aGlzIHdvcmsgaWYgdGhlIFdHIGNhbiBmaWd1cmUgb3V0
IGhvdyB0byBrZWVwIGl0IHNpbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+KE1lYW5pbmcgSSBz
dXBwb3J0IGFkb3B0aW9uIG9mIHRoZSB3b3JrIGJ1dCBub3QgZ29pbmcgdG8gd2FpdCAyJiM0Mzsg
eWVhcnMgZm9yIGl0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
W1Fpbl06IFRoYW5rcywgdGhhdCBpcyBhbHNvIHRoZSBnb2FsIHdlIHNldCBmb3IgdGhpcyBkcmFm
dC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj5LZW50IChhbmQgTG91KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
Cm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_B8F9A780D330094D99AF023C5877DABAA487E462nkgeml513mbxchi_--


From nobody Mon Mar 25 22:15:49 2019
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 C5E7312027D for ; Mon, 25 Mar 2019 22:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 F-rQyYrmT9ES for ; Mon, 25 Mar 2019 22:15:45 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7CC4712027B for ; Mon, 25 Mar 2019 22:15:45 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B63C7A2A81B613825A65; Tue, 26 Mar 2019 05:15:43 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 05:15:43 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 13:15:40 +0800
From: Qin Wu 
To: Juergen Schoenwaelder , Joe Clarke 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Question on draft-wu-netmod-factory-default
Thread-Index: AdTjkPCwnvydF2AuQoOdsCxKRcPpiw==
Date: Tue, 26 Mar 2019 05:15:40 +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.220.64.122]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 05:15:48 -0000

SGksSnVyZ2VuOg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWlsdG86
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVlcmdlbiBTY2hvZW53YWVsZGVyDQq3osvN
yrG85DogMjAxOcTqM9TCMjXI1SAyMzozMQ0KytW8/sjLOiBKb2UgQ2xhcmtlIDxqY2xhcmtlQGNp
c2NvLmNvbT4NCrOty806IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogUmU6IFtuZXRtb2RdIFF1ZXN0
aW9uIG9uIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQNCg0KVGhlIEktRCBzYXlzOg0K
DQogICBvICBmYWN0b3J5LWRlZmF1bHQgZGF0YXN0b3JlOiBBIHJlYWQtb25seSBkYXRhc3RvcmUg
aG9sZGluZyBhDQogICAgICBwcmVjb25maWd1cmVkIG1pbmltYWwgaW5pdGlhbCBjb25maWd1cmF0
aW9uIHRoYXQgY2FuIGJlIHVzZWQgdG8NCiAgICAgIGluaXRpYWxpemUgdGhlIGNvbmZpZ3VyYXRp
b24gb2YgYSBzZXJ2ZXIuICBUaGUgY29udGVudCBvZiB0aGUNCiAgICAgIGRhdGFzdG9yZSBpcyB1
c3VhbGx5IHN0YXRpYywgYnV0IE1BWSBkZXBlbmQgb24gZXh0ZXJuYWwgZmFjdG9ycw0KICAgICAg
bGlrZSBhdmFpbGFibGUgSFcuDQoNClRoZSBwcm9ibGVtIGhlcmUgaXMgdGhlIHBocmFzZSAnY2Fu
IGJlIHVzZWQgdG8gaW5pdGlhbGl6ZSB0aGUgY29uZmlndXJhdGlvbiBvZiBhIHNlcnZlcicuIElu
IHRlcm1zIG9mIHRoZSB3ZWxsLWtub3duIE5NREEgZGF0YXN0b3JlcywgaXQgaXMgbm90IGNsZWFy
IHdoZXRoZXIgdGhlIGNvbnRlbnQgaXMgY29waWVkIHRvIDxydW5uaW5nPiBvciA8c3RhcnR1cD4g
b3IgYm90aC4gU2VjdGlvbiAyIGFkZHMgYSBiaXQgbW9yZSBjb25mdXNpb24gc2luY2UgaXQNCnNh
eXM6DQoNCiAgIEZhY3RvcnktZGVmYXVsdCBjb250ZW50IFNIQUxMIGJlIHNwZWNpZmllZCBieSBv
bmUgb2YgdGhlIGZvbGxvd2luZw0KICAgbWVhbnMgaW4gb3JkZXIgb2YgcHJlY2VkZW5jZQ0KDQog
ICAxLiAgRm9yIHRoZSA8cnVubmluZz4sIDxjYW5kaWRhdGU+IGFuZCA8c3RhcnR1cD4gZGF0YXN0
b3JlcyBhcyB0aGUNCiAgICAgICBjb250ZW50IG9mIHRoZSA8ZmFjdG9yeS1kZWZhdWx0PiBkYXRh
c3RvcmUsIGlmIGl0IGV4aXN0cw0KDQpTbyBkbyBhbGwgdGhlc2UgY29uZmlndXJhdGlvbiBkYXRh
c3RvcmVzIHJlY2VpdmUgYSAxOjEgY29weSBvZiA8ZmFjdG9yeS1kZWZhdWx0Pj8NCltRaW5dOiBU
aGlzIGlzIGNsb3NlIHRvIHdoYXQgQW5keSBpcyBhc2tpbmcsIHdlIGFsbG93IG11bHRpcGxlIHRh
cmdldCBkYXRhc3RvcmUgdG8gYmUgcmVzZXQuDQogSWYgc28sIGlmIHdlIGhhdmUgYSA8ZmFjdG9y
eS1kZWZhdWx0Piwgd2h5IGlzIGludm9raW5nIDxjb3B5LWNvbmZpZz4gbm90IGdvb2QgZW5vdWdo
Pw0KW1Fpbl06IE5ldGNvbmYgPGNvcHktY29uZmlnPiBvcGVyYXRpb24gbmVlZHMgdG8gYmUgZXh0
ZW5kZWQgdG8gYWxsb3cgaXQgdG8gb3BlcmF0ZSBvbiB0aGUgZmFjdG9yeS1kZWZhdWx0IGRhdGFz
dG9yZS4NCiAgIDIuICBZQU5HIEluc3RhbmNlIERhdGEgW0ktRC5pZXRmLW5ldG1vZC15YW5nLWlu
c3RhbmNlLWZpbGUtZm9ybWF0XQ0KDQpIb3cgd291bGQgdGhpcyBiZSBkb25lPyBJIGRvIG5vdCBz
ZWUgYW55dGhpbmcgaW4gcmVzZXQtZGF0YXN0b3JlcyB0aGF0IHByb3ZpZGVzIGluc3RhbmNlIGRh
dGEuIFRoZSBjb3B5LWNvbmZpZyBvcGVyYXRpb24gYWxyZWFkeSBhbGxvd3MgdG8gcHJvdmlkZSBz
b3VyY2UgY29uZmlnIGlubGluZS4gV2h5IGRvIHdlIG5lZWQgYW5vdGhlciB3YXkgb2YgZG9pbmcg
dGhlIHNhbWU/DQpbUWluXTogSW4gbm9ybWFsIGNvcHktY29uZmlnIG9wZXJhdGlvbiwgaG93IGRv
IHdlIHNvdXJjZSBjb25maWcgaW5saW5lIGlzIHVzZWQgZm9yIGZhY3RvcnkgZGVmYXVsdCBzZXR0
aW5nLg0KIFlBTkcgaW5zdGFuY2UgZGF0YSBkcmFmdCBjb3VsZCBwcm92aWRlIGdlbmVyaWMgc29s
dXRpb24gZm9yIHRoaXMuIFdlIGFkZCBhIG5vdGUgdG8gc2VlIGlmIHRoZXJlIGlzIGFkZGl0aW9u
YWwgcGFyYW1ldGVycyB0aGF0IG5lZWQgdG8gYmUgYWRkZWQsIHdpbGwgc2VlIGhvdyB0byBhZGRy
ZXNzIHRoaXMuDQoNCkkgZG8gbm90IHJlYWxseSB1bmRlcnN0YW5kIHdoeSBvbmUgd291bGQgbmVl
ZCB0byBoYXZlIHJlc2V0LWRhdGFzdG9yZSBvbiA8Y2FuZGlkYXRlPiAtIGlzIDxkaXNjYXJkLWNo
YW5nZXM+IG5vdCBnb29kIGVub3VnaD8NCltRaW5dOiBJdCBkb2Vzbid0IGFsbG93IHlvdSByZXNl
dCB0byA8Y2FuZGlkYXRlPiB3aXRob3V0IGNoYW5naW5nIDxydW5uaW5nPi4NClBsZWFzZSBmaXgg
dGhlICd0YXJnZXQtZGF0YXNvcmUnIHR5cG8gb3IgYmV0dGVyIGNoYW5nZSB0aGUgcGFyYW1ldGVy
IG5hbWUgdG8ganVzdCAnZGF0YXN0b3JlJy4NCltRaW5dOiBPa2F5LHdpbGwgZmlndXJlIG91dCB0
aGUgcmlnaHQgdGVybWlub2xvZ3kuDQpTaG91bGQgdGhlcmUgYmUgdGV4dCBleHBsYWluaW5nIGhv
dyBhbiBpbXBsZW1lbnRhdGlvbiBpcyBzdXBwb3NlZCB0byBkZWFsIHdpdGggZXJyb3JzIG9yIHdp
bGwgdGhlc2UgcmVzZXRzIG5ldmVyIGZhaWw/DQpbUWluXTogT2theSwgd2lsbCBhZGQgdGV4dCBp
biB0aGUgbmV4dCB2ZXJzaW9uLg0KL2pzDQoNCk9uIE1vbiwgTWFyIDI1LCAyMDE5IGF0IDEwOjE0
OjAzQU0gLTA0MDAsIEpvZSBDbGFya2Ugd3JvdGU6DQo+IEkgc3VwcG9ydCB0aGUgbmVlZCBmb3Ig
YmVpbmcgYWJsZSB0byByZXNldCBhIERTIHRvIGl0cyBmYWN0b3J5IGRlZmF1bHQuDQo+IEhvd2V2
ZXIsIEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHRoZSBjdXJyZW50IGRlc2lnbiBvZiB0aGUgbW9kZWwg
YW5kIHRoZSANCj4gImZhY3RvcnktZGVmYXVsdCIgRFMuDQo+IA0KPiBJdCBzZWVtcyB0byBtZSB0
aGF0IHRoaXMgaXMgYSBzaW5nbGUgRFMgdGhhdCBtaWdodCBoYXZlIGJlZW4gaW50ZW5kZWQgDQo+
IHRvIHJlc2V0IHJ1bm5pbmcgb3Igc3RhcnR1cC4gIEhvd2V2ZXIsIHdoYXQgaWYgSSBoYXZlIGRp
ZmZlcmVudCBEU2VzIA0KPiB0aGF0IGVhY2ggaGF2ZSB1bmlxdWUgZmFjdG9yeSBkZWZhdWx0IGRh
dGE/ICBJZiBJIGNob29zZSB0byBleHRlbmQgDQo+IGZhY3RvcnktZGVmYXVsdCB3aXRoIGEgbmV3
IGlkZW50aXR5IG9mIG15IG90aGVyIERTLCBob3cgY2FuIEkgaW5kaWNhdGUgDQo+IHRoYXQgdGhl
IHRhcmdldCBEUyB3aWxsIGJlIHJlc2V0IHRvIF90aGF0XyBEUz8gIERvZXMgdGhhdCBtYWtlIHNl
bnNlPw0KPiANCj4gT3IgaWYgSSBkbyBhIDxnZXQtZGF0YT4gb24gYSBmYWN0b3J5LWRlZmF1bHQg
RFMsIGhvdyBkbyBJIGtub3cgd2hhdCANCj4gb3RoZXIgRFNlcyBkb2VzIHRoaXMgRFMgcGVydGFp
bj8gIFBlcmhhcHMgdGhlIHNlcnZlciB3aWxsIHVzZSB0aGlzIHRvIA0KPiByZXNldCBhIGdpdmVu
IERTLCBidXQgaG93IHdvdWxkIGEgdXNlciBrbm93IHRoYXQgKG90aGVyIHRoYW4gcGVyaGFwcyAN
Cj4gbmFtaW5nIG9mIHRoZSBmYWN0b3J5LWRlZmF1bHQgRFMpPw0KPiANCj4gTWF5YmUgdGhlIG1v
ZHVsZSBuZWVkcyBhIG1hcHBpbmcgdG8gbGV0IHRoZSBjbGllbnQga25vdyB3aGF0IERTIHdpbGwg
DQo+IGJlIHVzZWQgdG8gcmVzZXQgd2hhdCBvdGhlciBEUz8NCj4gDQo+IEpvZQ0KPiANCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1h
aWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAg
ICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1
ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAg
ICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku
ZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Mon Mar 25 22:21:36 2019
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 CABF7120284 for ; Mon, 25 Mar 2019 22:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 kUkG-Jtipprg for ; Mon, 25 Mar 2019 22:21:32 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3D1AE120282 for ; Mon, 25 Mar 2019 22:21:32 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 554F3C7EC06F88EFAE35 for ; Tue, 26 Mar 2019 05:21:30 +0000 (GMT)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 05:21:29 +0000
Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.77]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 13:21:25 +0800
From: wangzitao 
To: Martin Bjorklund , kent+ietf 
CC: netmod 
Thread-Topic: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
Thread-Index: AQHU40md3tBH3pq1G062uJ/hN8PtbKYcS1UAgAEVmgU=
Date: Tue, 26 Mar 2019 05:21:24 +0000
Message-ID: 
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>, <20190325.214750.1687158789187348637.mbj@tail-f.com>
In-Reply-To: <20190325.214750.1687158789187348637.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2D979483DGGEMM527MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 05:21:34 -0000

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2D979483DGGEMM527MBXchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

KzENCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCs3119Poug0KTaO6
Kzg2LTE1ODUwNTgxOTU1PHRlbDorODYtMTU4NTA1ODE5NTU+DQpFo7p3YW5neml0YW9AaHVhd2Vp
LmNvbTxtYWlsdG86d2FuZ3ppdGFvQGh1YXdlaS5jb20+DQrN+MLnsvrGt9PrveK+9re9sLgtyv2+
3c2o0MVBScq5xNy8vMr1sr8NCk5ldHdvcmsgUHJvZHVjdHMgJiBTb2x1dGlvbnMtRGF0YSBDb21t
dW5pY2F0aW9uIEFJIEVuYWJsaW5nIFRlY2hub2xvZ3kgRGVwdA0KDQq3orz+yMujuiBNYXJ0aW4g
QmpvcmtsdW5kPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+DQrK1bz+yMuj
uiBrZW50K2lldGY8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4u
bmV0Pj4NCrOty82juiBuZXRtb2Q8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v
cmc+Pg0K1vfM4qO6IFJlOiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1zY2hvZW53
LW5ldG1vZC1yZmM2OTkxLWJpcy0wMA0KyrG85KO6IDIwMTktMDMtMjUgMjE6NDg6MTYNCg0KS2Vu
dCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gVGhpcyBlbWFpbCBiZWdp
bnMgYSAyLXdlZWsgYWRvcHRpb24gcG9sbCBmb3I6DQo+DQo+ICAgICBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtc2Nob2Vudy1uZXRtb2QtcmZjNjk5MS1iaXMtMDANCj4NCj4gUGxl
YXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb25zIGJlZm9yZSBBcHJpbCA4Lg0KDQpJ
IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCg0KL21hcnRpbg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp
bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0K

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2D979483DGGEMM527MBXchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











+1











=CD=F5=D7=D3=E8=BA

M=A3=BA+86-15850581955 

E=A3=BAwangzitao@huawei.com

=CD=F8=C2=E7=B2=FA=C6=B7=D3=EB=BD=E2=BE=F6=B7=BD=B0=B8-=CA=FD=BE=DD=CD=A8=
=D0=C5AI=CA=B9=C4=DC=BC=BC=CA=F5=B2=BF

Network Products & Solutions-Data Communication AI Enabling Technology =
Dept








=B7=A2=BC=FE=C8=CB=A3=BA Martin Bjorklund<mbj@tail-f.com>


=CA=D5=BC=FE=C8=CB=A3=BA kent+ietf<kent+ietf@watsen.net>


=B3=AD=CB=CD=A3=BA netmod<netmod@ietf.org>


=D6=F7=CC=E2=A3=BA Re: [netmod] Adoption poll for draft-schoenw=
-netmod-rfc6991-bis-00


=CA=B1=BC=E4=A3=BA 2019-03-25 21:48:16









Kent Watsen <kent+ietf@watsen.net> wrote=
:

> This email begins a 2-week adoption poll for:

> 

>     https://tools.ietf.org/html/draft-schoenw-net=
mod-rfc6991-bis-00

> 

> Please voice your support or objections before April 8.



I support the adoption of this draft.





/martin



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.o=
rg/mailman/listinfo/netmod







--_000_E6BC9BBCBCACC246846FC685F9FF41EA2D979483DGGEMM527MBXchi_--


From nobody Mon Mar 25 22:26:03 2019
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 832D5120284 for ; Mon, 25 Mar 2019 22:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 SYkHXbFucxh2 for ; Mon, 25 Mar 2019 22:25:59 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A3268120283 for ; Mon, 25 Mar 2019 22:25:59 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CEEC2C497191CB945077 for ; Tue, 26 Mar 2019 05:25:57 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 05:25:57 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 13:25:45 +0800
From: Qin Wu 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] Question on draft-wu-netmod-factory-default
Thread-Index: AdTjkxFcCYeISMFOQFKN5gIZBlyFgQ==
Date: Tue, 26 Mar 2019 05:25:45 +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.220.64.122]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 05:26:02 -0000

Sm9lLA0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRt
b2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKb2UgQ2xhcmtlDQq3osvNyrG85DogMjAxOcTqM9TC
MjXI1SAyMjoxNA0KytW8/sjLOiBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6IFtuZXRtb2RdIFF1ZXN0
aW9uIG9uIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQNCg0KSSBzdXBwb3J0IHRoZSBu
ZWVkIGZvciBiZWluZyBhYmxlIHRvIHJlc2V0IGEgRFMgdG8gaXRzIGZhY3RvcnkgZGVmYXVsdC4N
Ckhvd2V2ZXIsIEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHRoZSBjdXJyZW50IGRlc2lnbiBvZiB0aGUg
bW9kZWwgYW5kIHRoZSAiZmFjdG9yeS1kZWZhdWx0IiBEUy4NCg0KSXQgc2VlbXMgdG8gbWUgdGhh
dCB0aGlzIGlzIGEgc2luZ2xlIERTIHRoYXQgbWlnaHQgaGF2ZSBiZWVuIGludGVuZGVkIHRvIHJl
c2V0IHJ1bm5pbmcgb3Igc3RhcnR1cC4gIEhvd2V2ZXIsIHdoYXQgaWYgSSBoYXZlIGRpZmZlcmVu
dCBEU2VzIHRoYXQgZWFjaCBoYXZlIHVuaXF1ZSBmYWN0b3J5IGRlZmF1bHQgZGF0YT8gDQoNCltR
aW5dOldlIHN0YXJ0IHdpdGggYSBzaW1wbGUgY2FzZSwgeW91IGNhc2UgY291bGQgYmUgYWRkcmVz
c2VkIGJ5IGludm9raW5nIG11bHRpcGxlIHJwYyB3aXRoIGVhY2ggcnBjIHRvIGFsbG93IHJlc2V0
IGEgc2V0IG9mIGRhdGFzdG9yZXMuDQogSWYgSSBjaG9vc2UgdG8gZXh0ZW5kIGZhY3RvcnktZGVm
YXVsdCB3aXRoIGEgbmV3IGlkZW50aXR5IG9mIG15IG90aGVyIERTLCBob3cgY2FuIEkgaW5kaWNh
dGUgdGhhdCB0aGUgdGFyZ2V0IERTIHdpbGwgYmUgcmVzZXQgdG8gX3RoYXRfIERTPyAgRG9lcyB0
aGF0IG1ha2Ugc2Vuc2U/DQoNCltRaW5dOiBJbiBzaW1wbGUgY2FzZSwgdGFyZ2V0IERTIHdpbGwg
b25seSBiZSByZXNldCBieSBhIHNpbmdsZSBmYWN0b3J5IGRhdGFzdG9yZS4gSWYgdGhlcmUgaXMg
YSBuZXcgZmFjdG9yeSBkYXRhc3RvcmUgY291bGQgYmUgZGVyaXZlZCBmcm9tIHRoYXQgRFMsIEkg
dGhpbmsgdGFyZ2V0IERTIHNob3VsZCBiZSBjaGFuZ2VkIHRvIHJlc2V0IHRoYXQgbmV3IGZhY3Rv
cnkgZGF0YXN0b3JlLg0KDQpPciBpZiBJIGRvIGEgPGdldC1kYXRhPiBvbiBhIGZhY3RvcnktZGVm
YXVsdCBEUywgaG93IGRvIEkga25vdyB3aGF0IG90aGVyIERTZXMgZG9lcyB0aGlzIERTIHBlcnRh
aW4/ICBQZXJoYXBzIHRoZSBzZXJ2ZXIgd2lsbCB1c2UgdGhpcyB0byByZXNldCBhIGdpdmVuIERT
LCBidXQgaG93IHdvdWxkIGEgdXNlciBrbm93IHRoYXQgKG90aGVyIHRoYW4gcGVyaGFwcyBuYW1p
bmcgb2YgdGhlIGZhY3RvcnktZGVmYXVsdCBEUyk/DQoNCk1heWJlIHRoZSBtb2R1bGUgbmVlZHMg
YSBtYXBwaW5nIHRvIGxldCB0aGUgY2xpZW50IGtub3cgd2hhdCBEUyB3aWxsIGJlIHVzZWQgdG8g
cmVzZXQgd2hhdCBvdGhlciBEUz8NCltRaW5dOiBTbyB5b3VyIHBvaW50IGlzIHNob3VsZCB3ZSBh
bGxvdyBtdWx0aXBsZSBzb3VyY2UsIG11bHRpcGxlIHRhcmdldCBpbiB0aGUgc2FtZSBSUEMsIHdp
bGwgdGhpbmsgaXQgb3Zlci4gVGhhbmtzLg0KSm9lDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Mon Mar 25 22:41:11 2019
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 9D846120286 for ; Mon, 25 Mar 2019 22:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 Orfev3i2u4hB for ; Mon, 25 Mar 2019 22:41:07 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7409120282 for ; Mon, 25 Mar 2019 22:41:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7846B6F4; Tue, 26 Mar 2019 06:41:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ctIPfrESTW6U; Tue, 26 Mar 2019 06:41:04 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 06:41:04 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60D63200A8; Tue, 26 Mar 2019 06:41:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id YlBwce-8OKxc; Tue, 26 Mar 2019 06:41:04 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id AD49F200A7; Tue, 26 Mar 2019 06:41:03 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 06:41:03 +0100
Received: by anna.localdomain (Postfix, from userid 501) id B1B4830078EEEC; Tue, 26 Mar 2019 06:41:02 +0100 (CET)
Date: Tue, 26 Mar 2019 06:41:02 +0100
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: Joe Clarke , "netmod@ietf.org" 
Message-ID: <20190326054102.tmpo35qzdab6jv3t@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Joe Clarke , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 05:41:10 -0000

On Tue, Mar 26, 2019 at 05:15:40AM +0000, Qin Wu wrote:
> 
> So do all these configuration datastores receive a 1:1 copy of ?
> [Qin]: This is close to what Andy is asking, we allow multiple target datastore to be reset.

I did understand that you allow multiple targets. My question is if
all targets receive the same content, i.e., whether reset-datastore is
just N-times copy-config or whether there is more to it.

>  If so, if we have a , why is invoking  not good enough?
> [Qin]: Netconf  operation needs to be extended to allow it to operate on the factory-default datastore.
>    2.  YANG Instance Data [I-D.ietf-netmod-yang-instance-file-format]
> 
> How would this be done? I do not see anything in reset-datastores that provides instance data. The copy-config operation already allows to provide source config inline. Why do we need another way of doing the same?
> [Qin]: In normal copy-config operation, how do we source config inline is used for factory default setting.

RFC 6241 page 43:

      source:  Name of the configuration datastore to use as the source
         of the  operation, or the  element
         containing the complete configuration to copy.

>  YANG instance data draft could provide generic solution for this. We add a note to see if there is additional parameters that need to be added, will see how to address this.

I am not saying this is needed. I think the WG needs to discuss
whether all four options listed in section 2 of your I-D make sense.
Perhaps 1. and 3. are sufficient (except that I do not know exactly
how 1. is supposed to work).
 
> I do not really understand why one would need to have reset-datastore on  - is  not good enough?
> [Qin]: It doesn't allow you reset to  without changing .

Why would that be useful? The normal reset of  is to
.  is an editing scratch pad - does it really
make sense to reset  to  without
resetting ? What is the use case of 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 Mar 25 22:51:27 2019
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 C781F12026B for ; Mon, 25 Mar 2019 22:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 xVKH4ExVaBkQ for ; Mon, 25 Mar 2019 22:51:23 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A71120287 for ; Mon, 25 Mar 2019 22:51:22 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 13AC06F4; Tue, 26 Mar 2019 06:51:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id N0X2BXShf0WW; Tue, 26 Mar 2019 06:51:20 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 06:51:20 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C78C7200A8; Tue, 26 Mar 2019 06:51:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id FJd9YdEGnukR; Tue, 26 Mar 2019 06:51:20 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 561BE200A7; Tue, 26 Mar 2019 06:51:20 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 06:51:19 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 810C530078EF3E; Tue, 26 Mar 2019 06:51:18 +0100 (CET)
Date: Tue, 26 Mar 2019 06:51:18 +0100
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: Joe Clarke , "netmod@ietf.org" 
Message-ID: <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , Joe Clarke , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 05:51:25 -0000

Qin,

the idea should be to make things simpler, not more complex. Perhaps
it is not necessary to expose N options to reset a device. Perhaps a
simple "factory-reset" RPC which resets all relevant datastores in an
implementation specific manner is sufficient. Why expose more details
to the management client?

/js

On Tue, Mar 26, 2019 at 05:25:45AM +0000, Qin Wu wrote:
> Joe,
>=20
>=20
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=
=BB=A3=E8=A1=A8 Joe Clarke
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B43=E6=9C=8825=E6=97=A5=
 22:14
> =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org
> =E4=B8=BB=E9=A2=98: [netmod] Question on draft-wu-netmod-factory-defaul=
t
>=20
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the "=
factory-default" DS.
>=20
> It seems to me that this is a single DS that might have been intended t=
o reset running or startup.  However, what if I have different DSes that =
each have unique factory default data?=20
>=20
> [Qin]:We start with a simple case, you case could be addressed by invok=
ing multiple rpc with each rpc to allow reset a set of datastores.
>  If I choose to extend factory-default with a new identity of my other =
DS, how can I indicate that the target DS will be reset to _that_ DS?  Do=
es that make sense?
>=20
> [Qin]: In simple case, target DS will only be reset by a single factory=
 datastore. If there is a new factory datastore could be derived from tha=
t DS, I think target DS should be changed to reset that new factory datas=
tore.
>=20
> Or if I do a  on a factory-default DS, how do I know what oth=
er DSes does this DS pertain?  Perhaps the server will use this to reset =
a given DS, but how would a user know that (other than perhaps naming of =
the factory-default DS)?
>=20
> Maybe the module needs a mapping to let the client know what DS will be=
 used to reset what other DS?
> [Qin]: So your point is should we allow multiple source, multiple targe=
t in the same RPC, will think it over. Thanks.
> Joe
>=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

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


From nobody Mon Mar 25 23:35:43 2019
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 D9B9B1202C9 for ; Mon, 25 Mar 2019 23:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 c0KLxsaCL8PH for ; Mon, 25 Mar 2019 23:35:36 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 0458312028A for ; Mon, 25 Mar 2019 23:35:35 -0700 (PDT)
Received: from mb.local ([IPv6:2601:647:4201:4561:6007:78cc:2e64:a0e]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id x2Q6ZZ9u058355; Tue, 26 Mar 2019 06:35:35 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:4561:6007:78cc:2e64:a0e] claimed to be mb.local
To: Kent Watsen , netmod@ietf.org
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
From: joel jaeggli 
Openpgp: preference=signencrypt
Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= mQGiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfmrQfSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiauQQNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8GIRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w=
Message-ID: <7ea08b11-ee3d-dfb4-f466-bf0c2b4d5bc8@bogus.com>
Date: Mon, 25 Mar 2019 23:35:34 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yixN2A8x64FrqvrigBkhT2d4w2FvZE9Fj"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 06:35:42 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--yixN2A8x64FrqvrigBkhT2d4w2FvZE9Fj
Content-Type: multipart/mixed; boundary="H9MUi2u3TegIp3EvFPf76AfL2UqfsuP72";
 protected-headers="v1"
From: joel jaeggli 
To: Kent Watsen , netmod@ietf.org
Message-ID: <7ea08b11-ee3d-dfb4-f466-bf0c2b4d5bc8@bogus.com>
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>

--H9MUi2u3TegIp3EvFPf76AfL2UqfsuP72
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 3/25/19 13:34, Kent Watsen wrote:
> This email begins a 2-week adoption poll for:
>=20
> =C2=A0 =C2=A0=C2=A0https://tools.ietf.org/html/draft-wu-netmod-factory-=
default-02
>=20
> Please voice your support or objections=C2=A0before April 8.
> 

support.

I would note that it probably needs a security considerations section
that addresses the two points raised in the security considerations
section of the informatively referenced  rfc 5870.

> Kent (and Lou)
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20



--H9MUi2u3TegIp3EvFPf76AfL2UqfsuP72--

--yixN2A8x64FrqvrigBkhT2d4w2FvZE9Fj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCXJnINgAKCRDwADWrtn9W
sumAAJ9MG4LnJbQWh4CVOhPA2CGZsMPfJACeJnU04dql/1W+qKzGML1Lp6KV2zA=
=hN6y
-----END PGP SIGNATURE-----

--yixN2A8x64FrqvrigBkhT2d4w2FvZE9Fj--


From nobody Mon Mar 25 23:41:37 2019
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 0395912015E for ; Mon, 25 Mar 2019 23:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 vV78bRoP1g2c for ; Mon, 25 Mar 2019 23:41:33 -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 A0FD6120286 for ; Mon, 25 Mar 2019 23:41:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5956; q=dns/txt; s=iport; t=1553582492; x=1554792092; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=duybobrwe6koAZTEpguxxROkNqznhYxgVtFp8opX14k=; b=mM7Iwx33meW6q/Ksd2ZadsXY+HQknDWIT7JqtWfiLU2tCxQ96MFqVYyf zfj3OrEF8AOC7sscn0nI0Ig1mv1BmswfuDpy7LeWwOdHx0/HA05p8IECO 0V/7fqvt5XnOQeq1OoIQXMsHDHmb/AtJyTn0yqVWX9qMWhqjJW4WIp8zw Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADmyJlc/4wNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDoECaIEDJwqEBIgcjTCSRIV3FIFnDQEBI4R?= =?us-ascii?q?JAheFASI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQjClwCAQgRBAEBKwICAjAdCAI?= =?us-ascii?q?EARIIgxuBEWQPrTmBL4Q0AoV5BYEvAYsxF4FAP4QjPoJhAQECAYErARIBgym?= =?us-ascii?q?CVwOMcIQfh0eMQQkCh2GLUCGCAoV8jAKLHYYFjSgCERWBLh84ZXFwFYMniwy?= =?us-ascii?q?FP0ExjguBH4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="536274024"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 06:41:30 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q6fUxr028177 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 06:41:30 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 01:41:30 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 01:41:29 -0500
From: "Rob Wilton (rwilton)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
Thread-Index: AQHU40njfz1S2wE5e0KFegGLeqF6rKYdd0HQ
Date: Tue, 26 Mar 2019 06:41:29 +0000
Message-ID: <93a640eda42345958f1c21964f3e2fd0@XCH-RCD-007.cisco.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
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.61.79.96]
Content-Type: multipart/alternative; boundary="_000_93a640eda42345958f1c21964f3e2fd0XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 06:41:35 -0000

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

U3VwcG9ydC4NCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo
YWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiAyNSBNYXJjaCAyMDE5IDIxOjMyDQpUbzogbmV0bW9k
QGlldGYub3JnDQpTdWJqZWN0OiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jaG9w
cHMtbmV0bW9kLWdlby1sb2NhdGlvbi0wMQ0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIDItd2VlayBh
ZG9wdGlvbiBwb2xsIGZvcjoNCg0KDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWNob3Bwcy1uZXRtb2QtZ2VvLWxvY2F0aW9uLTAxDQoNCg0KUGxlYXNlIHZvaWNlIHlvdXIg
c3VwcG9ydCBvciBvYmplY3Rpb25zIGJlZm9yZSBBcHJpbCA4Lg0KDQoNCktlbnQgLy8gYXMgY28t
Y2hhaXINCg0KDQoNCg==

--_000_93a640eda42345958f1c21964f3e2fd0XCHRCD007ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu
MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3VwcG9y
dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+IG5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBC
ZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+IDI1IE1hcmNoIDIwMTkg
MjE6MzI8YnI+DQo8Yj5Ubzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i
PiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jaG9wcHMtbmV0bW9kLWdlby1sb2Nh
dGlvbi0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGlzIGVtYWlsIGJlZ2lucyBhIDItd2VlayBhZG9wdGlvbiBwb2xsIGZvcjo8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsgJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWNob3Bwcy1uZXRtb2QtZ2VvLWxvY2F0aW9uLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtY2hvcHBzLW5ldG1vZC1nZW8tbG9jYXRpb24tMDE8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB2b2lj
ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwgOC48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBh
cyBjby1jaGFpcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_93a640eda42345958f1c21964f3e2fd0XCHRCD007ciscocom_--


From nobody Tue Mar 26 00:02:00 2019
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 93D3612028B for ; Tue, 26 Mar 2019 00:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 lKU8YgT4gT65 for ; Tue, 26 Mar 2019 00:01:56 -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 20D59120284 for ; Tue, 26 Mar 2019 00:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14326; q=dns/txt; s=iport; t=1553583716; x=1554793316; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aYts3QEkQ7pHOp9SgzFi6xPeAa9NvAG/arVatJ3ayOQ=; b=RIgoXQD30/u/1zIc0k9FuXrvqPqVd4F0dfhUVEJYxyGKtvNpv4IAkPds Nl26IFH1VUbU7gyebLX9O7wsHnNBnc4Rz/YE8FaGpjbQettz9jA0F7hov hbeDo3GgSKMxJfm2Bee/n9fE6/AJuKlldkTyIhdVeNe3rhtDTiUFlrTCw Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAB/zZlc/4QNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDoECaIEDJwqEBIgciySCDZJEhXcUgWcNAQE?= =?us-ascii?q?jgVSCdQIXhQEiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIwpcAgEIEQQBASsCAgI?= =?us-ascii?q?wHQgCBAESCBODCIERZA+tNIEvhDQChXoFgS8BizEXgUA/gRGDEj6CYQEBA4E?= =?us-ascii?q?rARIBCAODHoJXA4xwhCGUCAkCh2GLUCGCAoV9jAOLHYYGjSoCERWBLh84ZXF?= =?us-ascii?q?wFYMniwyFP0ExjXwOF4EIgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="539625388"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 07:01:54 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q71smE012373 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 07:01:54 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 02:01:53 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 02:01:53 -0500
From: "Rob Wilton (rwilton)" 
To: Kent Watsen , "netmod@ietf.org" , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Qin Wu 
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AQHU40pAE0rZobHHcEaspplVrDxwYKYdd2DA
Date: Tue, 26 Mar 2019 07:01:53 +0000
Message-ID: <7cc1a662c56748eb8edfc767735d4a5d@XCH-RCD-007.cisco.com>
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
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.61.79.96]
Content-Type: multipart/alternative; boundary="_000_7cc1a662c56748eb8edfc767735d4a5dXCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:01:59 -0000

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

SSBzdXBwb3J0IHRoaXMgZHJhZnQgYXMgYSBzdGFydGluZyBwbGFjZSBmb3IgdGhpcyB3b3JrLCBi
dXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGNoYW5nZXMgaW4gdGhlIGZpbmFsIHNvbHV0aW9u
Og0KDQpJIHRoaW5rIHRoYXQgaGF2aW5nIGEgZGF0YXN0b3JlIHJlcG9ydCB0aGUgZmFjdG9yeSBk
ZWZhdWx0IGNvbmZpZ3VyYXRpb24gaXMgZ29vZCwgYW5kIGl0IGlzIGFsc28gcmlnaHQgdGhhdCB0
aGlzIHNob3VsZCBiZSBvcHRpb25hbCB0byBpbXBsZW1lbnQsIHNpbmNlIHNvbWUgZGV2aWNlcyBt
aWdodCBub3QgaGF2ZSBkZWZhdWx0IGZhY3RvcnkgY29uZmlndXJhdGlvbiwgYnV0IGluc3RlYWQg
cnVuIGEgZmlyc3QgYm9vdCBzZXF1ZW5jZSB0byBjb25zdHJ1Y3QgYW4gaW5pdGlhbCBjb25maWd1
cmF0aW9uLg0KDQpJIGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIG5lZWQgdG8gYmUgYWJs
ZSB0byBwZXJmb3JtIGEgZmFjdG9yeSByZXNldCBvbiBhIHBlciBkYXRhc3RvcmUgYmFzaXMsIGJ1
dCBpbnN0ZWFkIEkgd291bGQgcHJlZmVyIHRvIHNlZSBhIHNpbmdsZSBkZXZpY2UgbGV2ZWwgZmFj
dG9yeSByZXNldCBSUEMuICBTdWNoIGFuIFJQQyBtYXkgZG8gbW9yZSB0aGFuIGp1c3QgcmVzZXR0
aW5nIHRoZSBjb25maWd1cmF0aW9uIGFuZCByZWJvb3RpbmcgdGhlIGRldmljZSwgaXQgbWlnaHQg
YWxzbyBjaGFuZ2UgdGhlIHNvZnR3YXJlIHZlcnNpb24sIHdpcGUgYXJlYXMgb2Ygc3RvcmFnZSBz
dWNoIGFzIGxvZyBmaWxlcywgY2FjaGVkIGZpbGVzLCBldGMuICBQb3NzaWJseSwgc29tZSBvZiB0
aGVzZSBvcHRpb25zIGNvdWxkIGJlIGNvbnRyb2xsZWQgdmlhIHBhcmFtZXRlcnMgdG8gdGhlIFJQ
QyBpZiB0aGVyZSBpcyBlbm91Z2ggY29tbW9uYWxpdHksIG9mIG90aGVyd2lzZSB2ZW5kb3JzIGNv
dWxkIGF1Z21lbnQgaW4gdGhlaXIgb3duIG9wdGlvbnMgdG8gYSBtaW5pbWFsIHN0YW5kYXJkIFJQ
Qy4NCg0KQ29weWluZyBmcm9tIDxmYWN0b3J5LWRlZmF1bHQ+IHRvIGFub3RoZXIgZGF0YXN0b3Jl
IGlzIE9LIHdpdGggbWUsIGFsdGhvdWdoIEkgZG9u4oCZdCBzZWUgYW55IHBhcnRpY3VsYXIgbmVl
ZC92YWx1ZSBpbiBkb2luZyB0aGlzLCBoZW5jZSBJIHdvdWxkIHJhdGhlciBzZWUgPGNvcHktY29u
ZmlnPiBmaXhlZCBtb3JlIGdlbmVyaWNhbGx5IHRvIGFsbG93IGNvcHlpbmcgYmV0d2VlbiB0d28g
Y29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIHRoYW4gc3BlY2lmaWNhbGx5IGF1Z21lbnRpbmcgc3Bl
Y2lmaWNhbGx5IGZvciB0aGlzIGRhdGFzdG9yZS4gIEhlbmNlLCBJIHRoaW5rIHRoYXQgZXh0ZW5k
aW5nL3JlcGxhY2luZyB0aGUgPGNvcHktY29uZmlnPiBSUEMgY291bGQgcHJvYmFibHkgYmUgZGVm
ZXJyZWQgdG8gYSBORVRDT05GLWJpcyBvciBORVRDT05GLU5NREEtYmlzIGRvY3VtZW50Lg0KDQpJ
IGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgdGhpcyBkb2N1bWVudCB0byByZWZlcmVuY2Ugb3IgcmVm
ZXIgdG8gdGhlIGluc3RhbmNlcy1kYXRhIGRyYWZ0LiAgSSB0aGluayB0aGF0IHVzaW5nIGluc3Rh
bmNlLWRhdGEgcmF0aGVyIHRoYW4gYSBmYWN0b3J5LWRlZmF1bHQgZGF0YXN0b3JlIGlzIGp1c3Qg
YW4gaW50ZXJuYWwgaW1wbGVtZW50YXRpb24gZGV0YWlsIGFuZCBzaG91bGRu4oCZdCBiZSBleHBv
c2VkIHRvIHRoZSB1c2VyLg0KDQpIb3dldmVyLCBCYWxhenMsIEkgZG8gc2VlIG1lcml0IGluIGFs
bG93aW5nIHRoZSBjb250ZW50cyBvZiBhbnkgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgdG8gYmUg
bG9hZGVkIGZyb20gYW4gaW5zdGFuY2UtZGF0YSBmaWxlLCBvciB3cml0dGVuIHRvIGFuIGluc3Rh
bmNlIGRhdGEgZmlsZSAoZWl0aGVyIGxvY2FsIG9yIHJlbW90ZSkuICAgQnV0LCBJIGRvbuKAmXQg
dGhpbmsgdGhhdCB0aGlzIHNob3VsZCBnbyBpbnRvIHRoaXMgZHJhZnQsIGFuZCBwcm9iYWJseSBp
dCBpcyB0b28gbGF0ZSB0byBhZGQgdGhpcyB0byB0aGUgaW5zdGFuY2UtZGF0YSBkcmFmdC4NCg0K
VGhhbmtzLA0KUm9iDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4g
T24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiAyNSBNYXJjaCAyMDE5IDIxOjM1DQpUbzog
bmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFm
dC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyDQoNClRoaXMgZW1haWwgYmVnaW5zIGEgMi13
ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMg0KDQoNClBsZWFzZSB2b2ljZSB5
b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwgOC48eC1hcHBsZS1kYXRhLWRl
dGVjdG9yczovLzE+DQoNCg0KS2VudCAoYW5kIExvdSkNCg==

--_000_7cc1a662c56748eb8edfc767735d4a5dXCHRCD007ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu
MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBzdXBw
b3J0IHRoaXMgZHJhZnQgYXMgYSBzdGFydGluZyBwbGFjZSBmb3IgdGhpcyB3b3JrLCBidXQgSSB3
b3VsZCBsaWtlIHRvIHNlZSBzb21lIGNoYW5nZXMgaW4gdGhlIGZpbmFsIHNvbHV0aW9uOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB0aGluayB0aGF0IGhhdmluZyBh
IGRhdGFzdG9yZSByZXBvcnQgdGhlIGZhY3RvcnkgZGVmYXVsdCBjb25maWd1cmF0aW9uIGlzIGdv
b2QsIGFuZCBpdCBpcyBhbHNvIHJpZ2h0IHRoYXQgdGhpcyBzaG91bGQgYmUgb3B0aW9uYWwNCiB0
byBpbXBsZW1lbnQsIHNpbmNlIHNvbWUgZGV2aWNlcyBtaWdodCBub3QgaGF2ZSBkZWZhdWx0IGZh
Y3RvcnkgY29uZmlndXJhdGlvbiwgYnV0IGluc3RlYWQgcnVuIGEgZmlyc3QgYm9vdCBzZXF1ZW5j
ZSB0byBjb25zdHJ1Y3QgYW4gaW5pdGlhbCBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHRoZSBu
ZWVkIHRvIGJlIGFibGUgdG8gcGVyZm9ybSBhIGZhY3RvcnkgcmVzZXQgb24gYSBwZXIgZGF0YXN0
b3JlIGJhc2lzLCBidXQgaW5zdGVhZCBJIHdvdWxkIHByZWZlciB0byBzZWUNCiBhIHNpbmdsZSBk
ZXZpY2UgbGV2ZWwgZmFjdG9yeSByZXNldCBSUEMuJm5ic3A7IFN1Y2ggYW4gUlBDIG1heSBkbyBt
b3JlIHRoYW4ganVzdCByZXNldHRpbmcgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIHJlYm9vdGluZyB0
aGUgZGV2aWNlLCBpdCBtaWdodCBhbHNvIGNoYW5nZSB0aGUgc29mdHdhcmUgdmVyc2lvbiwgd2lw
ZSBhcmVhcyBvZiBzdG9yYWdlIHN1Y2ggYXMgbG9nIGZpbGVzLCBjYWNoZWQgZmlsZXMsIGV0Yy4m
bmJzcDsgUG9zc2libHksIHNvbWUgb2YgdGhlc2UNCiBvcHRpb25zIGNvdWxkIGJlIGNvbnRyb2xs
ZWQgdmlhIHBhcmFtZXRlcnMgdG8gdGhlIFJQQyBpZiB0aGVyZSBpcyBlbm91Z2ggY29tbW9uYWxp
dHksIG9mIG90aGVyd2lzZSB2ZW5kb3JzIGNvdWxkIGF1Z21lbnQgaW4gdGhlaXIgb3duIG9wdGlv
bnMgdG8gYSBtaW5pbWFsIHN0YW5kYXJkIFJQQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPkNvcHlpbmcgZnJvbSAmbHQ7ZmFjdG9yeS1kZWZhdWx0Jmd0OyB0byBhbm90
aGVyIGRhdGFzdG9yZSBpcyBPSyB3aXRoIG1lLCBhbHRob3VnaCBJIGRvbuKAmXQgc2VlIGFueSBw
YXJ0aWN1bGFyIG5lZWQvdmFsdWUgaW4gZG9pbmcgdGhpcywgaGVuY2UNCiBJIHdvdWxkIHJhdGhl
ciBzZWUgJmx0O2NvcHktY29uZmlnJmd0OyBmaXhlZCBtb3JlIGdlbmVyaWNhbGx5IHRvIGFsbG93
IGNvcHlpbmcgYmV0d2VlbiB0d28gY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIHRoYW4gc3BlY2lm
aWNhbGx5IGF1Z21lbnRpbmcgc3BlY2lmaWNhbGx5IGZvciB0aGlzIGRhdGFzdG9yZS4mbmJzcDsg
SGVuY2UsIEkgdGhpbmsgdGhhdCBleHRlbmRpbmcvcmVwbGFjaW5nIHRoZSAmbHQ7Y29weS1jb25m
aWcmZ3Q7IFJQQyBjb3VsZCBwcm9iYWJseSBiZSBkZWZlcnJlZA0KIHRvIGEgTkVUQ09ORi1iaXMg
b3IgTkVUQ09ORi1OTURBLWJpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPkkgZG9u4oCZdCBzZWUgYSBuZWVkIGZvciB0aGlzIGRvY3VtZW50IHRvIHJl
ZmVyZW5jZSBvciByZWZlciB0byB0aGUgaW5zdGFuY2VzLWRhdGEgZHJhZnQuJm5ic3A7IEkgdGhp
bmsgdGhhdCB1c2luZyBpbnN0YW5jZS1kYXRhIHJhdGhlciB0aGFuDQogYSBmYWN0b3J5LWRlZmF1
bHQgZGF0YXN0b3JlIGlzIGp1c3QgYW4gaW50ZXJuYWwgaW1wbGVtZW50YXRpb24gZGV0YWlsIGFu
ZCBzaG91bGRu4oCZdCBiZSBleHBvc2VkIHRvIHRoZSB1c2VyLiZuYnNwOw0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ib3dldmVyLCBCYWxhenMsIEkgZG8gc2VlIG1l
cml0IGluIGFsbG93aW5nIHRoZSBjb250ZW50cyBvZiBhbnkgY29uZmlndXJhdGlvbiBkYXRhc3Rv
cmUgdG8gYmUgbG9hZGVkIGZyb20gYW4gaW5zdGFuY2UtZGF0YSBmaWxlLCBvcg0KIHdyaXR0ZW4g
dG8gYW4gaW5zdGFuY2UgZGF0YSBmaWxlIChlaXRoZXIgbG9jYWwgb3IgcmVtb3RlKS4gJm5ic3A7
Jm5ic3A7QnV0LCBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGlzIHNob3VsZCBnbyBpbnRvIHRoaXMg
ZHJhZnQsIGFuZCBwcm9iYWJseSBpdCBpcyB0b28gbGF0ZSB0byBhZGQgdGhpcyB0byB0aGUgaW5z
dGFuY2UtZGF0YSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0
Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZW50IFdhdHNlbjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBN
YXJjaCAyMDE5IDIxOjM1PGJyPg0KPGI+VG86PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gW25ldG1vZF0gQWRvcHRpb24gcG9sbCBmb3IgZHJhZnQtd3UtbmV0bW9kLWZh
Y3RvcnktZGVmYXVsdC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBlbWFpbCBiZWdpbnMgYSAyLXdlZWsgYWRvcHRpb24g
cG9sbCBmb3I6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyIj5odHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMjwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+UGxlYXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb25zJm5ic3A7PGEgaHJlZj0i
eC1hcHBsZS1kYXRhLWRldGVjdG9yczovLzEiPmJlZm9yZSBBcHJpbCA4LjwvYT48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAo
YW5kIExvdSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7cc1a662c56748eb8edfc767735d4a5dXCHRCD007ciscocom_--


From nobody Tue Mar 26 00:12:37 2019
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 197E71202A0 for ; Tue, 26 Mar 2019 00:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 9OKbWB7c30-d for ; Tue, 26 Mar 2019 00:12:29 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E83B120284 for ; Tue, 26 Mar 2019 00:12:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2695; q=dns/txt; s=iport; t=1553584349; x=1554793949; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=JmuuDE7dRvNMfYp+KnspW/mibc5xjdfhng3KhrJygM4=; b=TOoFJ7nWIzL9nC/+37ksT7w9Ukk0qZ3Wj9dGLYdCN/idQmVl9wITRD5s 7ReVcg3bjU8La7S+b43FtAmYswDk2PRhPpyYLYcZZCHO71DDx7OdB0aDU Q6GWBXpcIem2bNoHfoKB6OnG8ge1keNsF0CmaxYzF/5in0m3g5okibxrn Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AADxz5lc/5pdJa1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCEWgDTTMnhA6TQIFgCCWYT4FnDxgLhANGAoUYIjg?= =?us-ascii?q?SAQEDAQEJAQMCbRwMhUsBAQQBASEPATsbCQIOCgICGQoDAgInHxEGAQwGAgE?= =?us-ascii?q?Bgx4BgXUPkVCbZoEvijAFgQskizIXgUA/gTgMgio1PoJhAQGBNxMBgyCCVwO?= =?us-ascii?q?KKppvCZM1BhmLJYhdix2TWIFkIYFWTSMVO4JsiwyFWyMDMJBIAQE?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="321422842"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 07:12:28 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x2Q7CRJO023017; Tue, 26 Mar 2019 07:12:27 GMT
To: Qin Wu , "netmod@ietf.org" 
References:  <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <87f6395d-5409-1d4c-4566-1e3ebe81e4d7@cisco.com>
Date: Tue, 26 Mar 2019 03:12:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:12:36 -0000

On 3/26/19 01:51, Juergen Schoenwaelder wrote:
> Qin,
> 
> the idea should be to make things simpler, not more complex. Perhaps
> it is not necessary to expose N options to reset a device. Perhaps a
> simple "factory-reset" RPC which resets all relevant datastores in an
> implementation specific manner is sufficient. Why expose more details
> to the management client?

This would certainly make it simpler from the RPC standpoint.  However,
if one can  from the factory-default DSes, I still think there
is a need to know what factory-default DS maps to what other DS (in the
case where there might be multiple that are different).

Joe

> 
> /js
> 
> On Tue, Mar 26, 2019 at 05:25:45AM +0000, Qin Wu wrote:
>> Joe,
>>
>>
>> -----邮件原件-----
>> å‘件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Joe Clarke
>> å‘é€æ—¶é—´: 2019å¹´3月25æ—¥ 22:14
>> 收件人: netmod@ietf.org
>> 主题: [netmod] Question on draft-wu-netmod-factory-default
>>
>> I support the need for being able to reset a DS to its factory default.
>> However, I have a question on the current design of the model and the "factory-default" DS.
>>
>> It seems to me that this is a single DS that might have been intended to reset running or startup.  However, what if I have different DSes that each have unique factory default data? 
>>
>> [Qin]:We start with a simple case, you case could be addressed by invoking multiple rpc with each rpc to allow reset a set of datastores.
>>  If I choose to extend factory-default with a new identity of my other DS, how can I indicate that the target DS will be reset to _that_ DS?  Does that make sense?
>>
>> [Qin]: In simple case, target DS will only be reset by a single factory datastore. If there is a new factory datastore could be derived from that DS, I think target DS should be changed to reset that new factory datastore.
>>
>> Or if I do a  on a factory-default DS, how do I know what other DSes does this DS pertain?  Perhaps the server will use this to reset a given DS, but how would a user know that (other than perhaps naming of the factory-default DS)?
>>
>> Maybe the module needs a mapping to let the client know what DS will be used to reset what other DS?
>> [Qin]: So your point is should we allow multiple source, multiple target in the same RPC, will think it over. Thanks.
>> Joe
>>
>> _______________________________________________
>> 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 Mar 26 00:13:03 2019
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 28FF4120284 for ; Tue, 26 Mar 2019 00:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 rd-4KswbvTxX for ; Tue, 26 Mar 2019 00:13:00 -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 93A2912028E for ; Tue, 26 Mar 2019 00:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=258; q=dns/txt; s=iport; t=1553584378; x=1554793978; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6xGa5RaLZAxQI183FS+X+8Mp6DyqqpXiK55O9sn4LxM=; b=V+kCEY0C//bq5oxJoaITJXczyqpBeqXa3Lj39zYYQ3sGn/SWNBLQ6lfb E47QewMvqwTBPEyDdZjYZHV7RNxiILn/2XmI8u6bsa06ElBG1nnFk1Zbf HrAl1fMAnZ6AKdvy+JPdWnovz/2gm/+mYSZ9zxEyaqdmN7MbgSHdynNOi I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AADxz5lc/5RdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIRaANNM4Q1k0CBYAglmE+BZw8jhEkChRgiOBIBAQM?= =?us-ascii?q?BAQkBAwJtHAyFSwEFIw8BVgsYAgIZDQICVwYBDAgBAYMeAYF1D602gS+ENAK?= =?us-ascii?q?FegWBCySLMheBQD+BOAyCXz6CYQEBAgGBKwESAYMpglcDmFiMQQmHY4tSBhm?= =?us-ascii?q?BcgEPhX2DJohdix2GBo1SgWQhZXFNIxWDKIsLhVsjA446gj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="249901525"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 07:12:57 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTP id x2Q7Cue7001247; Tue, 26 Mar 2019 07:12:56 GMT
To: Kent Watsen , netmod@ietf.org
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: 
Date: Tue, 26 Mar 2019 03:12:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:13:02 -0000

On 3/25/19 16:32, Kent Watsen wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
> 
> Please voice your support or objections before April 8.

I support adoption.

Joe


From nobody Tue Mar 26 00:16:35 2019
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 43400120294 for ; Tue, 26 Mar 2019 00:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 y00eSpkPc86h for ; Tue, 26 Mar 2019 00:16:31 -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 05F081202A0 for ; Tue, 26 Mar 2019 00:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=678; q=dns/txt; s=iport; t=1553584590; x=1554794190; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=hr4f1lU3VvqXKPTAfT6Nokkr+a046L4cJ17jj/Z/WhY=; b=J1Md2lOa1o6cGXSGjivTNKbyXkx7oj99yfjhBRU7k7ll/FYXAdIboCax tEB03uB+brYvt6XH/kje/vovvB6auBtw8HAO7RqaANv75kYKBvh8xKAk6 n3a2PTAikswf0Zipm0ZubAfZAXkk8KiT4qHYNgr3U5XvV9kgaoW1Dfeub M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAAAL0Zlc/5JdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBghBoA00zhDWTQIFgLZhPgWcPI4RJAoU?= =?us-ascii?q?ZIjcGDQEBAwEBCQEDAm0cDIVLAQUjDwFWCxgCAhkNAgJXBgEMCAEBgx4BgXU?= =?us-ascii?q?PrTeBL4Q0AoV6BYELJAGLMReBQD+BOIJrPoJhAQEDgSsBEgEIgyGCVwOKSpp?= =?us-ascii?q?PCYdji1IGGYIChX2DJohdix2GBo1SgWMiZXFNIxWDKIsLhVsjA446gj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="539471463"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 07:16:29 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTP id x2Q7GSls013200; Tue, 26 Mar 2019 07:16:29 GMT
To: Kent Watsen , netmod@ietf.org
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: 
Date: Tue, 26 Mar 2019 03:16:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:16:33 -0000

On 3/25/19 16:34, Kent Watsen wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
> 
> Please voice your support or objections before April 8.
> 

I support, and I've already sent some comments.  I think more work is
needed in the case where multiple datastores need to be reset with
different factory-default data.  I agree with others' comments that an
RPC that does all of the required work without needing to specify the
input datastore is simpler.  Still, understanding what factory-default
datastore maps to what other datastore is needed IMO.

Joe


From nobody Tue Mar 26 00:19:07 2019
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 A7B5E12028C for ; Tue, 26 Mar 2019 00:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 7DeiV8vAHxjB for ; Tue, 26 Mar 2019 00:19:02 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 3FA5212028D for ; Tue, 26 Mar 2019 00:19:02 -0700 (PDT)
Received: from mb.local ([IPv6:2601:647:4201:4561:6007:78cc:2e64:a0e]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id x2Q7IxgW058737; Tue, 26 Mar 2019 07:18:59 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:4561:6007:78cc:2e64:a0e] claimed to be mb.local
To: Joe Clarke , "netmod@ietf.org" 
References: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>
From: joel jaeggli 
Openpgp: preference=signencrypt
Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= mQGiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfmrQfSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiauQQNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8GIRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w=
Message-ID: <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com>
Date: Tue, 26 Mar 2019 00:18:58 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ySJEnAn1mEodAl5D9XZ65vUffOFhxi9p"
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:19:05 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4ySJEnAn1mEodAl5D9XZ65vUffOFhxi9p
Content-Type: multipart/mixed; boundary="yZi2NdrActC4iRnI9pNbQUs3eBuAU8AMV";
 protected-headers="v1"
From: joel jaeggli 
To: Joe Clarke , "netmod@ietf.org" 
Message-ID: <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com>
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
References: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>
In-Reply-To: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>

--yZi2NdrActC4iRnI9pNbQUs3eBuAU8AMV
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 3/25/19 07:14, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.=

> However, I have a question on the current design of the model and the
> "factory-default" DS.
>=20
> It seems to me that this is a single DS that might have been intended t=
o
> reset running or startup.  However, what if I have different DSes that
> each have unique factory default data?  If I choose to extend
> factory-default with a new identity of my other DS, how can I indicate
> that the target DS will be reset to _that_ DS?  Does that make sense?
>=20
> Or if I do a  on a factory-default DS, how do I know what
> other DSes does this DS pertain?  Perhaps the server will use this to
> reset a given DS, but how would a user know that (other than perhaps
> naming of the factory-default DS)?
>=20
> Maybe the module needs a mapping to let the client know what DS will be=

> used to reset what other DS?

the germ of the idea is sensible enough. reset a DS to it's factory state=
=2E

When it meets reality of course is that there seem to be a bunch of
variants that seem like pretty compelling use cases.

reset the whole device being one of them.

the specification of a factory-default datastore and then

   o  startup configuration datastore

   o  candiate configuration datastore

   o  running configuration datastore

actually sound a bit implementation specific though I recognize that
most network operating systems due tend to follow models that at least
superficially resembled that.

I'm generally sympathetic to the application the draft proposes.

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



--yZi2NdrActC4iRnI9pNbQUs3eBuAU8AMV--

--4ySJEnAn1mEodAl5D9XZ65vUffOFhxi9p
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCXJnSYgAKCRDwADWrtn9W
sorpAJ0apj4R3nQ4nhSkQmmCPiHs454RigCfW+MgAIpEiCdKC1beYzjfVic+b4Q=
=jNkQ
-----END PGP SIGNATURE-----

--4ySJEnAn1mEodAl5D9XZ65vUffOFhxi9p--


From nobody Tue Mar 26 00:22:49 2019
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 F37F512028C for ; Tue, 26 Mar 2019 00:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 gKl4knolQS_g for ; Tue, 26 Mar 2019 00:22:45 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70985120284 for ; Tue, 26 Mar 2019 00:22:45 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DBFA4B71; Tue, 26 Mar 2019 08:22:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id qX4utYRleVY2; Tue, 26 Mar 2019 08:22:43 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Mar 2019 08:22:43 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5951200A8; Tue, 26 Mar 2019 08:22:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id TUv8-OatVFbo; Tue, 26 Mar 2019 08:22:43 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 36FF7200A7; Tue, 26 Mar 2019 08:22:43 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 26 Mar 2019 08:22:42 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 518F430078F118; Tue, 26 Mar 2019 08:22:42 +0100 (CET)
Date: Tue, 26 Mar 2019 08:22:42 +0100
From: Juergen Schoenwaelder 
To: Joe Clarke 
CC: Qin Wu , "netmod@ietf.org" 
Message-ID: <20190326072242.vqfxr7lvsyybjmri@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Joe Clarke , Qin Wu , "netmod@ietf.org" 
References:  <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de> <87f6395d-5409-1d4c-4566-1e3ebe81e4d7@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87f6395d-5409-1d4c-4566-1e3ebe81e4d7@cisco.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:22:48 -0000

On Tue, Mar 26, 2019 at 03:12:26AM -0400, Joe Clarke wrote:
> On 3/26/19 01:51, Juergen Schoenwaelder wrote:
> > Qin,
> > 
> > the idea should be to make things simpler, not more complex. Perhaps
> > it is not necessary to expose N options to reset a device. Perhaps a
> > simple "factory-reset" RPC which resets all relevant datastores in an
> > implementation specific manner is sufficient. Why expose more details
> > to the management client?
> 
> This would certainly make it simpler from the RPC standpoint.  However,
> if one can  from the factory-default DSes, I still think there
> is a need to know what factory-default DS maps to what other DS (in the
> case where there might be multiple that are different).
>

The notion of multiple factory-default datastores sounds complex. And
what is a management application going to do with them? How would a
management application know which sets of datastores to reset together
in a meaningful way?

My naive interpretation of the factory default DS (a single one) would
be that it exposes the content you will find in  after the
factory-reset has been executed. An extended version of Figure 2 of
RFC 8342 would look like this:

     +-------------+                 +-----------+        +-----------+
     |  |                 |  |        |  |
     |  (ct, rw)   |<---+       +--->| (ct, rw)  |        | (ct, ro)  |
     +-------------+    |       |    +-----------+        +-----------+
            |           |       |           |                   |
            |         +-----------+         |                   |
            +-------->|  |<--------+                   |
                      | (ct, rw)  |<----------------------------+
                      +-----------+

And exposing such a factory default datastore would be optional I
think.

/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 Mar 26 00:36:53 2019
Return-Path: <01000169b8ee22e7-9d836ea4-9bef-4480-a4ce-560e4eac1a1d-000000@amazonses.watsen.net>
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 C36F112028B for ; Tue, 26 Mar 2019 00:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 BL0yJJlJVUSg for ; Tue, 26 Mar 2019 00:36:50 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA132120047 for ; Tue, 26 Mar 2019 00:36:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553585808; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=qE1Qa52rOLKAkQUVI05tQJOhDwWk0QvL3VJV5l0wSYM=; b=Kbd+IieYlQS7ioTOuAg0yEFAuG/YiaxzpZS6u1xUoMWH4irohoZdXv9L5NGnwvZS oBctonWijZXfUSJF6pvqLBAA2dcSDX1tHp/FWvgFNT6m7cE672+o5k+eEeJRIFooShH o963jD2owHGSXHRb6+2yo+PsDA/8lNYNmUqvh+i8=
Content-Type: multipart/alternative; boundary=Apple-Mail-BF8EA90D-15AA-4D14-9697-EAA2AF8CC3E1
Mime-Version: 1.0 (1.0)
From: Kent Watsen 
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <7cc1a662c56748eb8edfc767735d4a5d@XCH-RCD-007.cisco.com>
Date: Tue, 26 Mar 2019 07:36:48 +0000
Cc: Kent Watsen , "netmod@ietf.org" , =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , Qin Wu 
Content-Transfer-Encoding: 7bit
Message-ID: <01000169b8ee22e7-9d836ea4-9bef-4480-a4ce-560e4eac1a1d-000000@email.amazonses.com>
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com> <7cc1a662c56748eb8edfc767735d4a5d@XCH-RCD-007.cisco.com>
To: "Rob Wilton (rwilton)" 
X-SES-Outgoing: 2019.03.26-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:36:52 -0000

--Apple-Mail-BF8EA90D-15AA-4D14-9697-EAA2AF8CC3E1
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> I would rather see  fixed more generically to allow copying b=
etween two configuration datastores than specifically augmenting specificall=
y for this datastore.  Hence, I think that extending/replacing the  RPC could probably be deferred to a NETCONF-bis or NETCONF-NMDA-bis doc=
ument.

Agreed.  Qin, please add to the NETCONF-next issue tracker.=20

https://github.com/netconf-wg/netconf-next/issues

Kent=

--Apple-Mail-BF8EA90D-15AA-4D14-9697-EAA2AF8CC3E1
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit



I would rather see <copy-config> fixed more generically to allow copying between two configuration datastores than specifically augmenting specifically for this datastore.  Hence, I think that extending/replacing the <copy-config> RPC could probably be deferred
 to a NETCONF-bis or NETCONF-NMDA-bis document.

Agreed.  Qin, please add to the NETCONF-next issue tracker. 


Kent



--Apple-Mail-BF8EA90D-15AA-4D14-9697-EAA2AF8CC3E1--


From nobody Tue Mar 26 00:37:50 2019
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 CFA4C12028C for ; Tue, 26 Mar 2019 00:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 gmOGmAWG7Bmz for ; Tue, 26 Mar 2019 00:37:48 -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 10F76120047 for ; Tue, 26 Mar 2019 00:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport; t=1553585868; x=1554795468; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=lVW7bm+ZTDZqDQCW2O3x2B7zAZmPFxQYaUEI/vGuJ/w=; b=PU/fOd1LVSBpleA83e14trhvnryO5Prp8Rz327DYCUWGI5r4hdIcC/aJ FRqhkvL0qlfynxYHySRPdqfhNSPW8dsH8VkBCcDN5WSLmveIKoJRLxvLo +AzQLpz0Nq5VXNF8dd5vIeMP5Bj85hK3Y7fI7HPykcqEg5Y4CtxEgeBdD s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAADE1Zlc/5hdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYIRa00zhDWTQIFgCCWYT4FnD4RsAoUbIjgSAQEDAQEJAQM?= =?us-ascii?q?CbSiFSgEBAQMBIwRiCw4KAgIZDQICVwYBDAgBAYMegW4IrUp8M4o1gQskizI?= =?us-ascii?q?XgUA/gTgMgl8+hC2DIYJXA4oqEjGHDpMeCZM1BhmLJYhdix2TWIFkIYFWTSM?= =?us-ascii?q?VgyiQZiMDkHgBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="539855561"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 07:37:46 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x2Q7bjwc022942; Tue, 26 Mar 2019 07:37:46 GMT
To: Qin Wu , "netmod@ietf.org" 
References:  <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de> <87f6395d-5409-1d4c-4566-1e3ebe81e4d7@cisco.com> <20190326072242.vqfxr7lvsyybjmri@anna.jacobs.jacobs-university.de>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: <182da65f-6863-9a99-5287-9700492eeb70@cisco.com>
Date: Tue, 26 Mar 2019 03:37:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <20190326072242.vqfxr7lvsyybjmri@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:37:50 -0000

On 3/26/19 03:22, Juergen Schoenwaelder wrote:
> On Tue, Mar 26, 2019 at 03:12:26AM -0400, Joe Clarke wrote:
>> On 3/26/19 01:51, Juergen Schoenwaelder wrote:
>>> Qin,
>>>
>>> the idea should be to make things simpler, not more complex. Perhaps
>>> it is not necessary to expose N options to reset a device. Perhaps a
>>> simple "factory-reset" RPC which resets all relevant datastores in an
>>> implementation specific manner is sufficient. Why expose more details
>>> to the management client?
>>
>> This would certainly make it simpler from the RPC standpoint.  However,
>> if one can  from the factory-default DSes, I still think there
>> is a need to know what factory-default DS maps to what other DS (in the
>> case where there might be multiple that are different).
>>
> 
> The notion of multiple factory-default datastores sounds complex. And
> what is a management application going to do with them? How would a
> management application know which sets of datastores to reset together
> in a meaningful way?

This is why I think having a single RPC to "reset the device to factory"
makes sense.  Not to say that's the only use case, but it would be
useful in a number of cases.

> 
> My naive interpretation of the factory default DS (a single one) would
> be that it exposes the content you will find in  after the
> factory-reset has been executed. An extended version of Figure 2 of
> RFC 8342 would look like this:

Yep, this makes sense.  And I fully admit that my use case is likely
vendor-specific, but we may not be the only vendor with ancillary
datastores that do not look like  or .

Joe

> 
>      +-------------+                 +-----------+        +-----------+
>      |  |                 |  |        |  |
>      |  (ct, rw)   |<---+       +--->| (ct, rw)  |        | (ct, ro)  |
>      +-------------+    |       |    +-----------+        +-----------+
>             |           |       |           |                   |
>             |         +-----------+         |                   |
>             +-------->|  |<--------+                   |
>                       | (ct, rw)  |<----------------------------+
>                       +-----------+
> 
> And exposing such a factory default datastore would be optional I
> think.
> 
> /js
> 


From nobody Tue Mar 26 00:50:35 2019
Return-Path: <01000169b8faa024-6c5bd062-5d5b-4e61-a28e-5bf95758df94-000000@amazonses.watsen.net>
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 E613212028D for ; Tue, 26 Mar 2019 00:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 m2wKoUq6oz7W for ; Tue, 26 Mar 2019 00:50:28 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAE1120047 for ; Tue, 26 Mar 2019 00:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553586626; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=sS6BaHDJz4iE0VQeBVdK/IxFsUFWGg/TZ2cPIoh8WBw=; b=WeqcFJpOtQGjja3i5WzDMDp6KSUWorMpHZXRPe6ZRyDalumJnlyFeRwrxePZRN1w nMPTj/ir4JVdLLC7d5EdHNAJQLot2O0b8Y5fU+DJbEzTu6yeG6duBB5qNuh1j86644H bbqAhhATEmcoSRtu+jS3GpelhaajvKiqVbWmYsnk=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Kent Watsen 
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <182da65f-6863-9a99-5287-9700492eeb70@cisco.com>
Date: Tue, 26 Mar 2019 07:50:26 +0000
Cc: Qin Wu , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000169b8faa024-6c5bd062-5d5b-4e61-a28e-5bf95758df94-000000@email.amazonses.com>
References:  <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de> <87f6395d-5409-1d4c-4566-1e3ebe81e4d7@cisco.com> <20190326072242.vqfxr7lvsyybjmri@anna.jacobs.jacobs-university.de> <182da65f-6863-9a99-5287-9700492eeb70@cisco.com>
To: Joe Clarke 
X-SES-Outgoing: 2019.03.26-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 07:50:30 -0000

Sent from my iPhone

> On Mar 26, 2019, at 8:37 AM, Joe Clarke  wrote:
>=20
>> On 3/26/19 03:22, Juergen Schoenwaelder wrote:
>>> On Tue, Mar 26, 2019 at 03:12:26AM -0400, Joe Clarke wrote:
>>>> On 3/26/19 01:51, Juergen Schoenwaelder wrote:
>>>> Qin,
>>>>=20
>>>> the idea should be to make things simpler, not more complex. Perhaps
>>>> it is not necessary to expose N options to reset a device. Perhaps a
>>>> simple "factory-reset" RPC which resets all relevant datastores in an
>>>> implementation specific manner is sufficient. Why expose more details
>>>> to the management client?
>>>=20
>>> This would certainly make it simpler from the RPC standpoint.  However,
>>> if one can  from the factory-default DSes, I still think there=

>>> is a need to know what factory-default DS maps to what other DS (in the
>>> case where there might be multiple that are different).
>>>=20
>>=20
>> The notion of multiple factory-default datastores sounds complex. And
>> what is a management application going to do with them? How would a
>> management application know which sets of datastores to reset together
>> in a meaningful way?
>=20
> This is why I think having a single RPC to "reset the device to factory"
> makes sense.  Not to say that's the only use case, but it would be
> useful in a number of cases.

Correct.   This was requested by the WG last time it was presented, as there=
 are other things that need to be reset besides YANG-modeled configuration. =
 Not only does such an RPC make sense, I will likely object a Last Call if i=
t if such an RPC is missing.=20



>> My naive interpretation of the factory default DS (a single one) would
>> be that it exposes the content you will find in  after the
>> factory-reset has been executed. An extended version of Figure 2 of
>> RFC 8342 would look like this:

The contents are, effectively, the first  data store, as shipped fr=
om factory.=20

Resetting other datastores to default needs discussion.  For all of the =E2=80=
=9Cconventional configuration datastores=E2=80=9D, there=E2=80=99s likely ju=
st the one mentioned previously; each dynamic datastore might have its own n=
otion of a factory default.=20

Kent // contributor=20=


From nobody Tue Mar 26 01:32:31 2019
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 8B32E1202CC for ; Tue, 26 Mar 2019 01:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=WTkACX5G; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FEfSovp6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYCVxJrWYV9T for ; Tue, 26 Mar 2019 01:32:14 -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 7034E1202C1 for ; Tue, 26 Mar 2019 01:32:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5489; q=dns/txt; s=iport; t=1553589134; x=1554798734; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kilB7m3zeN90a3j56KvrcC2MUDwzDDmI/5Yn0YmlCd0=; b=WTkACX5GurdV4tGFbhoWLa+fuYuwKmXaY3M/zyFNw169yd0ouBmamUa1 i4ZP0bIT2tnqBqgPI3+OJtq0Zug4xYIIFjhnXz4IJXDhLCqp2QEGmprQp EC/vFhQx+/b8iFMZk4BXsyFo2ZcMzZSqDY1eUaXpsruPTgY2D9DghI2zp E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AbU2lOxDiWEnqDPCOnCrsUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuTjbykzGuxJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAB44plc/5FdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDi9QA2h0BAsnCoQEg0cDhFKKWkqCDZJEhEm?= =?us-ascii?q?BLhSBEANUDQEBIwmEQAIXhQgiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIx0BATg?= =?us-ascii?q?PAgEIEQMBAisCAgIwHQgCBAESgyIBgRFMAxUBAgyiIQKKFHGBL4J4AQEFgTU?= =?us-ascii?q?CgRCCQxiCDAMFgS8BizEXgUA/gTgfgkw+gmEBAQIBgSsBEgE/DYJdMYImjHO?= =?us-ascii?q?EIZQICQKHYYtYGYIChX2MA4sdhgaNKgIEAgQFAg4BAQWBTThlcXAVZQGCQYI?= =?us-ascii?q?Kg26FFIU/coEojGKBHwGBHgEB?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="252721232"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 08:32:12 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q8WCUs031547 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 08:32:12 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 03:32:11 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 03:32:10 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 03:32:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kilB7m3zeN90a3j56KvrcC2MUDwzDDmI/5Yn0YmlCd0=; b=FEfSovp6iLrqmahrzrVPMyJXECa4UtgYkrsTgg5qOI59kks4ed4BbmoEpXl22d+Oip61UAFmoPv1k3QzRef+RmY6Zw0x/OUBB2ksUw1MWjhPfnWH2jbgU5GZ22tQiQhV/+y4sHfPOnszuig4Cnpl5nP+I7S07IGn+gh84KdDWds=
Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 08:32:09 +0000
Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 08:32:09 +0000
From: "Reshad Rahman (rrahman)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
Thread-Index: AQHU40nyp3fGtdNzxkKwQ6SzRgxpqaYdpvqA
Date: Tue, 26 Mar 2019 08:32:09 +0000
Message-ID: <51A4FB36-BA77-4B32-810F-C8537264B652@cisco.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c58489e4-7b57-4cdf-4291-08d6b1c589be
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3551; 
x-ms-traffictypediagnostic: MN2PR11MB3551:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(396003)(39860400002)(376002)(199004)(189003)(2501003)(8676002)(7736002)(6306002)(229853002)(33656002)(236005)(81156014)(81166006)(6512007)(54896002)(478600001)(966005)(106356001)(36756003)(4744005)(14454004)(53546011)(53936002)(102836004)(476003)(68736007)(6246003)(66066001)(6436002)(6486002)(186003)(25786009)(486006)(86362001)(26005)(3846002)(11346002)(99286004)(82746002)(446003)(71190400001)(5660300002)(6116002)(316002)(8936002)(110136005)(256004)(58126008)(6506007)(76176011)(83716004)(606006)(105586002)(97736004)(2906002)(71200400001)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: x5k/IRiCmLbV7kifG4DwiLMx1MfqdAbTlJB1uf/torAb35SAzikX+DkNJ/JAQtDyhg2w9Xywg/j+zltCrELmXiOm4kGCWpnTgD/qksX925Zyi+1Bfwkcq2C3mP/Owq2jIhgBKf0cZ6gyguoiq/fjVQZpnaVrIn3DEYomCGIbK64iqE0jaXR+XVpGTq2/6H9gtZ/kJ2qQ/II2EIIq5dMYVcrR5jWYxbjH3dLMB4cNYo6yby2lmUnWfC/mtuag1SLC290Im3N9AM9U6IumXH53PojNtAO0cp/FXeK2g9guW9bbcg6Zo/tQ/Qr72gGBlI3gVU0gL9Y2dHFm7UolA6b6H0ksmhyCNJ5mWcPSX2bkXwzJcvDd9EU6B14tEO+k6Z6b92zKGaQzQWbg6hpU82fdVfNrLRxMjULqh02u+LbWEUM=
Content-Type: multipart/alternative; boundary="_000_51A4FB36BA774B32810FC8537264B652ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c58489e4-7b57-4cdf-4291-08d6b1c589be
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 08:32:09.5373 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3551
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 08:32:28 -0000

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

SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4NCg0KRnJv
bTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0
c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCkRhdGU6IE1vbmRheSwgTWFyY2ggMjUsIDIwMTkg
YXQgOTozMyBQTQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jaG9wcHMtbmV0bW9kLWdlby1s
b2NhdGlvbi0wMQ0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIDItd2VlayBhZG9wdGlvbiBwb2xsIGZv
cjoNCg0KDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNob3Bwcy1uZXRt
b2QtZ2VvLWxvY2F0aW9uLTAxDQoNCg0KUGxlYXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmpl
Y3Rpb25zIGJlZm9yZSBBcHJpbCA4Lg0KDQoNCktlbnQgLy8gYXMgY28tY2hhaXINCg0KDQoNCg==

--_000_51A4FB36BA774B32810FC8537264B652ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <970605CE37438A4983FDD05A81828F57@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0
IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEg
V0cgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2Vz
QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZA
d2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBNYXJjaCAyNSwgMjAxOSBh
dCA5OjMzIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0
O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W25ldG1vZF0gQWRvcHRp
b24gcG9sbCBmb3IgZHJhZnQtY2hvcHBzLW5ldG1vZC1nZW8tbG9jYXRpb24tMDE8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg
ZW1haWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOiA8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7
Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNob3Bwcy1u
ZXRtb2QtZ2VvLWxvY2F0aW9uLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
Y2hvcHBzLW5ldG1vZC1nZW8tbG9jYXRpb24tMDE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB2b2ljZSB5b3VyIHN1
cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwgOC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBhcyBjby1jaGFp
cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_51A4FB36BA774B32810FC8537264B652ciscocom_--


From nobody Tue Mar 26 01:32:41 2019
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 BE3971202BC for ; Tue, 26 Mar 2019 01:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=YqZ2VFOy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VnIPCG1T
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmCzDAQ2Dd8n for ; Tue, 26 Mar 2019 01:32:23 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489401202B6 for ; Tue, 26 Mar 2019 01:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5407; q=dns/txt; s=iport; t=1553589143; x=1554798743; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sIl4n27MH+oW8CsEvOKPUgQYClVEKpa2RYI1pnSXmHA=; b=YqZ2VFOyWIqViucm+y0Z6Udlg2QP1kJnDD86uL2E+Cf9DcA0Lfzctzwo GMGlfFLi6AcjmH5p9QJZDLS8tgx7WkCISbW5x9dvL1h1IYxcSNNlDM2zA ruAcjMiKNc9WuN5MNT5GbfYu5CrRDcjJ2eIiP3792LPh5n5KS3Yxof8N/ 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3Awphlrhd867lc/XuLm9Dz/FZylGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAB44plc/5JdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDi9QA2h0BAsnCoQEg0cDhFKKWkqCDZJEhEm?= =?us-ascii?q?BLhSBEANUDQEBIwmEQAIXhQgiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIx0BATg?= =?us-ascii?q?PAgEIBA0DAQIrAgICMB0IAgQBEoMiAYERTAMVAQIMoiECihRxgS+CeAEBBYE?= =?us-ascii?q?1AoEQgkMYggwDBYEvAYsxF4FAP4E4H4JMPoJhAQEDgSsBEgE/DYJdMYImjHO?= =?us-ascii?q?EIZQICQKHYYtYGYIChX2MA4sdhgaNKgIEAgQFAg4BAQWBTThlcXAVZQGCQYI?= =?us-ascii?q?Kg26FFIU/coEojGKBHwGBHgEB?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="529148450"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 08:32:21 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q8WLgK020394 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 08:32:21 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 03:32:20 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 03:32:20 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 03:32:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sIl4n27MH+oW8CsEvOKPUgQYClVEKpa2RYI1pnSXmHA=; b=VnIPCG1TNwWElT+RKdTE7r9c5dFjoyRcgE3W1zXehDUZOY6dZAdeMeCfpnmpzFinWq8bojU6FQuDfO1CtxsKpS9x+NeWiIZCuVyQiVFQq9nwSMU9CQbdof2fkO1CnM95x8vZHjGKhssi+/qyEC10MHSIfW9CH5t+BMn+Sd3sRCE=
Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2SPR01MB0013.namprd11.prod.outlook.com (20.179.87.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Tue, 26 Mar 2019 08:32:19 +0000
Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 08:32:18 +0000
From: "Reshad Rahman (rrahman)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
Thread-Index: AQHU40mp9Pd34zbWQk2nRqk7r/2a0qYdpwYA
Date: Tue, 26 Mar 2019 08:32:18 +0000
Message-ID: <57973E8F-C18C-4F25-B9A4-158736A55BE0@cisco.com>
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d84ebde9-707f-406c-047a-08d6b1c58f43
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2SPR01MB0013; 
x-ms-traffictypediagnostic: MN2SPR01MB0013:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(376002)(346002)(199004)(189003)(236005)(6512007)(6486002)(54896002)(82746002)(256004)(25786009)(6116002)(97736004)(6436002)(36756003)(3846002)(6306002)(33656002)(71190400001)(2501003)(7736002)(83716004)(71200400001)(4744005)(68736007)(446003)(186003)(26005)(478600001)(11346002)(76176011)(606006)(99286004)(106356001)(8676002)(86362001)(66066001)(81166006)(5660300002)(81156014)(966005)(229853002)(102836004)(14454004)(2906002)(316002)(105586002)(58126008)(6246003)(53936002)(486006)(476003)(8936002)(6506007)(2616005)(110136005)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2SPR01MB0013; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 2MCttlCmZZuZADJEPhTbX8AT9YL+mqh/mqwhJaAHXq8Zqj5AWY+5TRU1sLl55BOD4PBuwRMJEzIcXiD/oHzT+n+468T0XjsdEiUxLOUlL3NTrd9QCuT0dvRi8yS9WwsNw7BYsCDhHjPzNhYw5UY2qRYIcRAjyybiaK7x+xajPmmmF7aVqvhtOD16oSXyscuMIPdC2jSLjkyqH/+H5qOV2s3qHVqfW/HShOwRAjarQI4GvFiUDwjB+E99FhXtrG1864zQ5AhmTf8onDU0TkYGRAcZqXGaH+teppV2wGDwoordiDDyU2TIA4Y+x+Ws4KiR9WrTHZqYTSFBdNu0Ijf36qjGR60ei1oXogQPWaIXj3yHoRq9x81AIP8dSQm1qh4yJ0oDptY+a/irdGjj4U3K85e6tvN/Ac3OAJ/cEGpnvpY=
Content-Type: multipart/alternative; boundary="_000_57973E8FC18C4F25B9A4158736A55BE0ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d84ebde9-707f-406c-047a-08d6b1c58f43
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 08:32:18.8150 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2SPR01MB0013
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 08:32:38 -0000

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

SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4NCg0KRnJv
bTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0
c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCkRhdGU6IE1vbmRheSwgTWFyY2ggMjUsIDIwMTkg
YXQgOTozMSBQTQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1zY2hvZW53LW5ldG1vZC1yZmM2
OTkxLWJpcy0wMA0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIDItd2VlayBhZG9wdGlvbiBwb2xsIGZv
cjoNCg0KDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaG9lbnctbmV0
bW9kLXJmYzY5OTEtYmlzLTAwDQoNCg0KUGxlYXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmpl
Y3Rpb25zIGJlZm9yZSBBcHJpbCA4Lg0KDQoNCktlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQoNCg==

--_000_57973E8FC18C4F25B9A4158736A55BE0ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0
IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEg
V0cgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2Vz
QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZA
d2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBNYXJjaCAyNSwgMjAxOSBh
dCA5OjMxIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0
O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W25ldG1vZF0gQWRvcHRp
b24gcG9sbCBmb3IgZHJhZnQtc2Nob2Vudy1uZXRtb2QtcmZjNjk5MS1iaXMtMDA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg
ZW1haWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOiA8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7
Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaG9lbnct
bmV0bW9kLXJmYzY5OTEtYmlzLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
c2Nob2Vudy1uZXRtb2QtcmZjNjk5MS1iaXMtMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB2b2ljZSB5b3VyIHN1
cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwgOC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAoYW5kIExvdSBhbmQg
Sm9lbCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_57973E8FC18C4F25B9A4158736A55BE0ciscocom_--


From nobody Tue Mar 26 01:33:34 2019
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 571591202DC for ; Tue, 26 Mar 2019 01:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=OUqmDQfG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dpyKwQAS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgpDWoX8U7Xj for ; Tue, 26 Mar 2019 01:33:23 -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 85E5C1202CA for ; Tue, 26 Mar 2019 01:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5843; q=dns/txt; s=iport; t=1553589203; x=1554798803; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uZ40aim2BUOgZTKou/gSmVrhGXyGm4XifQl75unwc8E=; b=OUqmDQfGiPU1q632Fpj9iRJQ0uWLKkoAcxM2oMvB+OcM0ZsXzoVHI3SW PNNJF3HOj9hIVdovM/TazVulbIWRPFUzhTuanoIzwPbValrWX9fZoheQu m2kBU0syJ0c9GElfZM7bR5XBv1lC/brlVLCTpJNrmCrDLXaU2Z6hDZE6f 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3AMaczBxxAreXGMBbXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufE0T7KffsRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAB44plc/4cNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDi9QA2h0BAsnCoQEg0cDhFKKWkqCDZJEhEm?= =?us-ascii?q?BLhSBEANUDQEBIwmEQAIXhQgiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIx0BATg?= =?us-ascii?q?PAgEIEQMBAisCAgIwHQgCBAESgyIBgRFMAxUBAgyiIQKKFHGBL4J4AQEFgTU?= =?us-ascii?q?CgRCCQxiCDAMFgS8BizEXgUA/gTgfgkw+gmEBAQOBKwESAT8Ngl0xgiaMc4Q?= =?us-ascii?q?hlAgJAodhi1gZggKFfYwDix2GBo0qAgQCBAUCDgEBBYFNOGVxcBVlAYJBggo?= =?us-ascii?q?MF4NLhRSFP3KBKIxigR8BgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="249927748"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 08:33:22 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q8XMKW003074 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 08:33:22 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 03:33:21 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 03:33:20 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 04:33:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uZ40aim2BUOgZTKou/gSmVrhGXyGm4XifQl75unwc8E=; b=dpyKwQASExBwSuv8owdS4wGjvT1WFpHkVBJL39ZR5YAYQ2W62l3TNHt2JUiTj227pZzu53jl68Q64D3jfMtA/PNDgl5+nhx3eG2Suf77OBV3qDm4aou8IQMQbJY2/igWHlVnJl4eL7RW98VihORpykKdSmnubyOqCIS8urWVOmg=
Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2SPR01MB0013.namprd11.prod.outlook.com (20.179.87.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Tue, 26 Mar 2019 08:33:19 +0000
Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 08:33:19 +0000
From: "Reshad Rahman (rrahman)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AQHU40pKkr61dMxHh02ljNoFCTrJvKYdp0wA
Date: Tue, 26 Mar 2019 08:33:19 +0000
Message-ID: <4F113C56-851E-4C37-A108-DF69F60831D4@cisco.com>
References: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
In-Reply-To: <01000169b69032d0-ca63f6e6-7c28-46ad-b0bc-d47b72d4e118-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0fe4d273-13cc-4ecf-92cc-08d6b1c5b329
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2SPR01MB0013; 
x-ms-traffictypediagnostic: MN2SPR01MB0013:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(376002)(346002)(199004)(189003)(236005)(6512007)(6486002)(54896002)(82746002)(256004)(25786009)(6116002)(97736004)(6436002)(36756003)(3846002)(6306002)(33656002)(71190400001)(2501003)(7736002)(83716004)(71200400001)(4744005)(68736007)(446003)(186003)(26005)(478600001)(11346002)(76176011)(606006)(99286004)(106356001)(8676002)(86362001)(66066001)(81166006)(5660300002)(81156014)(966005)(229853002)(102836004)(14454004)(2906002)(316002)(105586002)(58126008)(6246003)(53936002)(486006)(476003)(8936002)(6506007)(2616005)(110136005)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2SPR01MB0013; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: gWgfxLsI+/qFkBIQq6JK6MeH3L3K9jiSZkZeZT5WiAL2wNJ5t5c7ItztiVXwFLYub2tup+469o9Ki6q7giJaWxXxmkKCVQW1ocXguAi7DPz2i7jDMLx7Ar7ZcFf4RecrLKipo7hTGgViGcH3/DHMIsNcAca+Ar/sEr5Eu9H0HNp++VMS+sg3QRxyVAreWBDB86OjH86nrXmEgji5BxKlBe0bazRlmCL6FWOyAKTv3zm/g+JcIrq/4sTMObKla6PJDwVE44uewC8iIeyL0I+mBvOW3s+527XiAATPtpApwfB4t2Rqm0q8ScODvf7Yk6YQnHz+92ITsTwwZFC5gy3a2hTtyDV9NL8em3muOZMpjsL7gcgiHSl9B1nRcvMI7DNJK/jLfnjfP0+70lxcLAbMWBm1ifaKZ/KYI4QkoVuSQKI=
Content-Type: multipart/alternative; boundary="_000_4F113C56851E4C37A108DF69F60831D4ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0fe4d273-13cc-4ecf-92cc-08d6b1c5b329
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 08:33:19.0362 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2SPR01MB0013
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 08:33:33 -0000

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

SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4NCg0KKzEg
dG8gd2hhdCB2YXJpb3VzIHBlb3BsZSBzYWlkIHdpdGggcmVnYXJkcyB0byBzaW1wbGlmaWNhdGlv
bnMgbmVlZGVkIGluIHRoZSBkb2N1bWVudC4NCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5l
dD4NCkRhdGU6IE1vbmRheSwgTWFyY2ggMjUsIDIwMTkgYXQgOTozNSBQTQ0KVG86ICJuZXRtb2RA
aWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbmV0bW9kXSBBZG9wdGlvbiBw
b2xsIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyDQoNClRoaXMgZW1haWwg
YmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQoNCiAgICBodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMg0KDQoNClBs
ZWFzZSB2b2ljZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwgOC48eC1h
cHBsZS1kYXRhLWRldGVjdG9yczovLzE+DQoNCg0KS2VudCAoYW5kIExvdSkNCg==

--_000_4F113C56851E4C37A108DF69F60831D4ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0
IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEg
V0cgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mIzQzOzEgdG8gd2hhdCB2YXJpb3VzIHBl
b3BsZSBzYWlkIHdpdGggcmVnYXJkcyB0byBzaW1wbGlmaWNhdGlvbnMgbmVlZGVkIGluIHRoZSBk
b2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRz
ZW4ubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDI1LCAyMDE5IGF0IDk6
MzUgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0
bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bbmV0bW9kXSBBZG9wdGlvbiBw
b2xsIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp
cyBlbWFpbCBiZWdpbnMgYSAyLXdlZWsgYWRvcHRpb24gcG9sbCBmb3I6IDxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz
cDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdC0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB2b2ljZSB5b3VyIHN1
cHBvcnQgb3Igb2JqZWN0aW9ucyZuYnNwOzxhIGhyZWY9IngtYXBwbGUtZGF0YS1kZXRlY3RvcnM6
Ly8xIj5iZWZvcmUgQXByaWwgOC48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbnQgKGFuZCBMb3UpPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_4F113C56851E4C37A108DF69F60831D4ciscocom_--


From nobody Tue Mar 26 02:15:34 2019
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 742DC1202CE; Tue, 26 Mar 2019 02:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.394
X-Spam-Level: 
X-Spam-Status: No, score=-13.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, 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 header.b=PgYxPiTP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FeCtQHVO
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6_fLkEPf1Mw; Tue, 26 Mar 2019 02:15:23 -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 124331202FA; Tue, 26 Mar 2019 02:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7993; q=dns/txt; s=iport; t=1553591723; x=1554801323; h=from:to:cc:subject:date:message-id:mime-version; bh=TbqCObZ8L5Ptjl4+Qpe0oaSZ+as8oYEulNSPbpkQH20=; b=PgYxPiTPeaXxWxk1PtNz9pP2wkH43t68v8tFwQYv69zehSwiTBzcEiNs K6VjF/t7M4G+m0uddlOdcq5a4z95erUx/f6Vr7SNpq6PvrP385Z4a0JGh ZDw0WR8gewcyajpQFipZRoa8lNxPq9KsgjG5lMnGpYeH3o/zTMotxeCYk c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AUenMohfjk/HJVQBSOlojEuGMlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCBQCU7Jlc/5hdJa1kHQEBBQEHBQG?= =?us-ascii?q?BUQgBCwGBDi8pJwNoNj4ECycKhASDRwOEUopagjKSaYRJgS4UgRADVA0BASy?= =?us-ascii?q?EQA4LhQgiNAkNAQEDAQEJAQMCbRwBC4V0HQEBNwERAUoCBDAnBA6CXEsBgRF?= =?us-ascii?q?MAxUBAqIuAooUcYEvgngBAQWCR4JDGIIMCIEvAYsxF4FAP4E4DBOCF4UggyE?= =?us-ascii?q?xgiaMc4QhHocpjEEJApM5GZQCix2TMAIEAgQFAg4BAQWBTTgogS5wFTsqAYJ?= =?us-ascii?q?BggqDbopTcoEojgEBgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="539883064"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 09:15:21 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q9FLxq020781 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 09:15:21 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 04:15:20 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 04:15:20 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 05:15:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TbqCObZ8L5Ptjl4+Qpe0oaSZ+as8oYEulNSPbpkQH20=; b=FeCtQHVO9DNUhh7BpH1d7md6lbmCcMh7uIT7j9NWI6viLZr3yBv2kvfZ1HBqno74cfH6aqE/vcqaHwk3yHNr17pd0MUAYzJolzXO833/n/rFijsXlkO+w+KaeXjr8dEju9ToVY3e2k0Qij9wJmNqKye/Mc2U8fCBlCh9wQ6jgp0=
Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3917.namprd11.prod.outlook.com (10.255.180.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Tue, 26 Mar 2019 09:15:18 +0000
Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 09:15:18 +0000
From: "Reshad Rahman (rrahman)" 
To: "draft-wwx-netmod-event-yang@ietf.org" 
CC: "netmod@ietf.org" 
Thread-Topic: draft-wwx-netmod-event-yang
Thread-Index: AQHU47RufUSeb+AC002ZW4vAXwSz8w==
Date: Tue, 26 Mar 2019 09:15:18 +0000
Message-ID: <1E3F911F-B9B8-4750-AEA3-3AC52E2EB215@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7de26513-1984-4043-5161-08d6b1cb90f7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3917; 
x-ms-traffictypediagnostic: MN2PR11MB3917:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(39860400002)(396003)(189003)(199004)(14454004)(99286004)(486006)(9326002)(6506007)(25786009)(450100002)(4326008)(186003)(71200400001)(26005)(33656002)(2616005)(316002)(476003)(71190400001)(102836004)(58126008)(7736002)(97736004)(83716004)(2501003)(106356001)(4744005)(105586002)(53936002)(68736007)(36756003)(6436002)(256004)(6306002)(54896002)(2906002)(5640700003)(6916009)(6486002)(6512007)(82746002)(2351001)(81156014)(3846002)(8676002)(81166006)(66066001)(86362001)(8936002)(6116002)(478600001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3917; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DSSvuk9Jix6t2n771t5rLmZOMVLQfmz3xbEahAvfLVq+ZiK+RmzZ4ksmJ9SRmjXAVl6WA+ucnswnnEMleABB3RDfmUhX/4AAENG6VKWI7Z9on6V2TOx+XHs/NM/OfGPJ0KuSO7FRsI8Y5o1ayx7a8T2OrOyefHG0lUblcmLGrbLgzNW7w+eOGv6VBEc9dSq/GgnG2+xi8/ha+k5+0NcSi9ClbviPTbvsRukxgIcYuKZg9A49wtu86RTUUEZ59ZpUmQg4RN7lvMFyiO4FRmxuJCNQR+LV3EaDgfqDB8fPovZPbU6J9GRKH2/KW6MIyY1q5GMm6gLzKAwf4LBYqnZPjvOs6tM8dc0QE9Igt7ggx2IfTgoLRETj44xFB6fEDAi2/+s2DzQMQ74JcQVvMAa2OYw19GUCb0I3Ahd+UiWI2bA=
Content-Type: multipart/alternative; boundary="_000_1E3F911FB9B84750AEA33AC52E2EB215ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7de26513-1984-4043-5161-08d6b1cb90f7
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 09:15:18.5847 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3917
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: 
Subject: [netmod] draft-wwx-netmod-event-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 09:15:33 -0000

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

SGksDQoNClRvb2sgYSBsb29rIGF0IHRoZSBkcmFmdCwgc29tZSBjb21tZW50cy9xdWVzdGlvbnM6
DQoNCiAgMS4gIFVzZSBvZiBpbnN0YW5jZS1pZGVudGlmaWVyLCBzbyB3ZSBuZWVkIHRvIGxpc3Qg
YWxsIGluc3RhbmNlcyBpbmRpdmlkdWFsbHk/DQogIDIuICBJcyB0aGUgb25seSBwb3NzaWJsZSBh
Y3Rpb24gYSBzZXQgb3BlcmF0aW9uPyBJbiBzb21lIGNhc2VzIGFuIGFjdGlvbiBzdWNoIGFzIHJl
c2V0IHdvdWxkIGJlIGRlc2lyYWJsZSwgaGF2ZSB5b3UgY29uc2lkZXJlZCBSUEM/DQogIDMuICBU
aGVyZSBhcmUgZXJyb3JzIGluIHRoZSBleGFtcGxlLCBlLmcuIG5hbWUgc2hvdWxkIGJlIGludGVy
ZmFjZS1zdGF0ZS1leGNlcHRpb24gKG5vdCBpbnRlcmZhY2UtZXhjZXB0aW9uKT8NCiAgNC4gIFRo
ZSBleGFtcGxlIGhhcyAzIGludGVyZmFjZXMgW2V0aDEsIGV0aDIsIGV0aDNdIGluIHRoZSBldmVu
dCB0YXJnZXQsIDIgaW50ZXJmYWNlcyBbZXRoMSwgZXRoMl0gaW4gdGhlIHRyaWdnZXIgdGVzdCBh
bmQgMSBpbnRlcmZhY2UgW2V0aDFdIGluIHRoZSBhY3Rpb24uIEkgZG9u4oCZdCB1bmRlcnN0YW5k
IHdoeS4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0K

--_000_1E3F911FB9B84750AEA33AC52E2EB215ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <73EED74A38CFBC43BC778B1087A6BB73@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo
LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt
cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn
aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t
c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw
dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM
aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjg1NjIwMjE4Ow0K
CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDI3ODcyMjQg
Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2
OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl
bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu
ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl
cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7
fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww
OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy
Z2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3
MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+VG9vayBhIGxvb2sgYXQgdGhlIGRyYWZ0LCBzb21lIGNvbW1lbnRz
L3F1ZXN0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6
MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0
eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5Vc2Ugb2YgaW5zdGFuY2UtaWRlbnRpZmllciwgc28gd2UgbmVl
ZCB0byBsaXN0IGFsbCBpbnN0YW5jZXMgaW5kaXZpZHVhbGx5Pw0KPG86cD48L286cD48L3NwYW4+
PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207
bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J
cyB0aGUgb25seSBwb3NzaWJsZSBhY3Rpb24gYSBzZXQgb3BlcmF0aW9uPyBJbiBzb21lIGNhc2Vz
IGFuIGFjdGlvbiBzdWNoIGFzIHJlc2V0IHdvdWxkIGJlIGRlc2lyYWJsZSwgaGF2ZSB5b3UgY29u
c2lkZXJlZCBSUEM/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh
Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGVyZSBhcmUgZXJyb3JzIGluIHRoZSBleGFt
cGxlLCBlLmcuIG5hbWUgc2hvdWxkIGJlIGludGVyZmFjZS1zdGF0ZS1leGNlcHRpb24gKG5vdCBp
bnRlcmZhY2UtZXhjZXB0aW9uKT88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv
TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBleGFtcGxlIGhhcyAzIGlu
dGVyZmFjZXMgW2V0aDEsIGV0aDIsIGV0aDNdIGluIHRoZSBldmVudCB0YXJnZXQsIDIgaW50ZXJm
YWNlcyBbZXRoMSwgZXRoMl0gaW4gdGhlIHRyaWdnZXIgdGVzdCBhbmQgMSBpbnRlcmZhY2UgW2V0
aDFdIGluIHRoZSBhY3Rpb24uDQogSSBkb27igJl0IHVuZGVyc3RhbmQgd2h5LjxvOnA+PC9vOnA+
PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_1E3F911FB9B84750AEA33AC52E2EB215ciscocom_--


From nobody Tue Mar 26 02:22:30 2019
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 DE4681202A1 for ; Tue, 26 Mar 2019 02:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 vUro8BwJ36Au for ; Tue, 26 Mar 2019 02:22:28 -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 E63EF12029B for ; Tue, 26 Mar 2019 02:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2724; q=dns/txt; s=iport; t=1553592147; x=1554801747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PfZrkop2xpDgEaqm33h+IUfOvWsBPe1p/B1FeQqBtRk=; b=eHZ11kTIjsb8axYB+fplMnBi3MVaf1ofZiiArCCNESOuTCjwPSTi2b/Z M2hBjdniy8wy8aIQUV0GF/YXzCZ23b1kGZIM4fY/Z8nYI59RvPUQHLy5e DOdTRZBfvlG4XAaLvr3aJLq5CbUMPPHeqaDMFZ9fQV4KQiv9IXT5nzez3 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAACl7plc/4gNJK1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCEWiBAycKmVGYT4FnDQEBGAuEA0YChR8iOBIBAQM?= =?us-ascii?q?BAQkBAwJtHAyFSgEBAQQBASUTNAsMAgICAQgOAgEEAQEBHhAbDAsdCAEBBAE?= =?us-ascii?q?NBQiDG4F1D64RM4owBQWBKosyF4FAP4QjPoJhAQGBSjgmhRoDiioSml0JApM?= =?us-ascii?q?xIZQCix2TMAIRFYEuNiGBVnAVO4JshiuEYYU/QTGPKYEfAQE?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="537768732"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 09:22:26 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2Q9MQZw007978 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 09:22:26 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 04:22:25 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 04:22:25 -0500
From: "Rob Wilton (rwilton)" 
To: Juergen Schoenwaelder , "Joe Clarke (jclarke)" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Question on draft-wu-netmod-factory-default
Thread-Index: AdTjkxFcTn/lCV6PJUaC2JeIK+aw5QALsXgAAALVZAAAAFvKAAAGXIxw
Date: Tue, 26 Mar 2019 09:22:25 +0000
Message-ID: 
References:  <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de> <87f6395d-5409-1d4c-4566-1e3ebe81e4d7@cisco.com> <20190326072242.vqfxr7lvsyybjmri@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190326072242.vqfxr7lvsyybjmri@anna.jacobs.jacobs-university.de>
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.61.79.96]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 09:22:30 -0000

+1 to Juergen's comments and diagram.

Thanks,
Rob


> -----Original Message-----
> From: netmod  On Behalf Of Juergen
> Schoenwaelder
> Sent: 26 March 2019 08:23
> To: Joe Clarke (jclarke) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
>=20
> On Tue, Mar 26, 2019 at 03:12:26AM -0400, Joe Clarke wrote:
> > On 3/26/19 01:51, Juergen Schoenwaelder wrote:
> > > Qin,
> > >
> > > the idea should be to make things simpler, not more complex. Perhaps
> > > it is not necessary to expose N options to reset a device. Perhaps a
> > > simple "factory-reset" RPC which resets all relevant datastores in
> > > an implementation specific manner is sufficient. Why expose more
> > > details to the management client?
> >
> > This would certainly make it simpler from the RPC standpoint.
> > However, if one can  from the factory-default DSes, I still
> > think there is a need to know what factory-default DS maps to what
> > other DS (in the case where there might be multiple that are different)=
.
> >
>=20
> The notion of multiple factory-default datastores sounds complex. And wha=
t is a
> management application going to do with them? How would a management
> application know which sets of datastores to reset together in a meaningf=
ul
> way?
>=20
> My naive interpretation of the factory default DS (a single one) would be=
 that it
> exposes the content you will find in  after the factory-reset ha=
s been
> executed. An extended version of Figure 2 of RFC 8342 would look like thi=
s:
>=20
>      +-------------+                 +-----------+        +-----------+
>      |  |                 |  |        |  |
>      |  (ct, rw)   |<---+       +--->| (ct, rw)  |        | (ct, ro)  |
>      +-------------+    |       |    +-----------+        +-----------+
>             |           |       |           |                   |
>             |         +-----------+         |                   |
>             +-------->|  |<--------+                   |
>                       | (ct, rw)  |<----------------------------+
>                       +-----------+
>=20
> And exposing such a factory default datastore would be optional I think.
>=20
> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Mar 26 03:16:44 2019
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 2D4C91202EC for ; Tue, 26 Mar 2019 03:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 8PWyl1_hcHR9 for ; Tue, 26 Mar 2019 03:16:30 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 05B9F1202AC for ; Tue, 26 Mar 2019 03:16:30 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id BF9A063492 for ; Tue, 26 Mar 2019 11:16:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553595386; bh=DBDhzMNQlu1xSWoIWGHSSAFe3MfYaiXi+LTD0RRxgQg=; h=From:To:Date; b=MSL0e0fDhkkrJp5j4x2VPYtaF5fZsic41YJ5nehlaTpXVZDhc9l1gk40BS3PL7tWK ej1ZRA5oTjYcdl5Jgsb9Z5Z0tks/xDka055ahb4Vn9vALtMFvwl+cO9KkWY012R64q JErBg7awKtvQDew5v9fLFs3+h0QwbtsRo5FOOxcg=
Message-ID: 
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 26 Mar 2019 11:16:26 +0100
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 10:16:43 -0000

Kent Watsen píše v Po 25. 03. 2019 v 20:32 +0000:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
> 
> Please voice your support or objections before April 8.
> 
> Kent // as co-chair

I support the adoption.

Lada

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


From nobody Tue Mar 26 03:17:27 2019
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 4E0051202A4 for ; Tue, 26 Mar 2019 03:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 anFjfc_DWu2j for ; Tue, 26 Mar 2019 03:17:23 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E27120282 for ; Tue, 26 Mar 2019 03:17:23 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 53922632D7 for ; Tue, 26 Mar 2019 11:17:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553595441; bh=rKGgoy5yrKVZ/ZtBAt5YeS6KVeDn9ATDUMKDugSoZrc=; h=From:To:Date; b=TwZbVeTHDACkgjOdPLXTUdnoA+7RGfBzcE6GTxVyt0E4Y5zKNhrxMPz4/H+cE8Wva 5xH+zGFtgwEpRJgOtutypT2VBeRNQ8ntw3YPgAKraRtODidf18VN6vQbK9I0fdnVAW /eoDPTTAkr3tmApwyGCPPI53m75nCi9PSj994c64=
Message-ID: 
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 26 Mar 2019 11:17:21 +0100
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 10:17:25 -0000

Kent Watsen píše v Po 25. 03. 2019 v 20:30 +0000:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00
> 
> Please voice your support or objections before April 8.
> 
> Kent (and Lou and Joel)

I support the adoption.

Lada

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


From nobody Tue Mar 26 03:42:50 2019
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 25DAC1202A4 for ; Tue, 26 Mar 2019 03:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 F44qYsCmTiMW for ; Tue, 26 Mar 2019 03:42:47 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 389581202A3 for ; Tue, 26 Mar 2019 03:42:47 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id k11so6298531wro.5 for ; Tue, 26 Mar 2019 03:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=date:from:to:message-id:in-reply-to:references:subject:mime-version;  bh=DXa6e0dc6o14D/onBYwV14+Q1whphohgccVqT8hwYmM=; b=JDQTnSdhlav56/exvpzhKC5/66+xcUzLeZPdkBjzG8AhVG+XBTy4m5QX5iByC9LiD/ 9lDvv71n+dATvv+/Fm2EI4lP9wRdXSU7wr3WJI/FySI/caDS9f/CkLJkUPmr2RT+2/mz pFeEHpFZ4XAqVKND6u543q+0qSF27myj/Uffwfk9PqgNjABlc3eGSQPSwamDn5uFQQZU PeVi/X7j1Q3D4I0jD7CovBqSbj1ZoIaxfF80sPKrz1LcpycR/xB70Y59EW1utwXI3Zfv Kxo1tFjgaZiJEvyMMjJAVCogTBc/75e+54SJez6GunZ+WyKSVrn6jtXCgvAW9O8+t7JM p+cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=DXa6e0dc6o14D/onBYwV14+Q1whphohgccVqT8hwYmM=; b=Uhca+kx9OmvLH6ALlpXq/QIbuFkz9I4S3xwxW+hHQ2ZmseZ9ulC+4oVFokmpQ3oBl3 rrrU26aSUSJojL5aWXwSU7kOxsjwDNDk9UvNuTphbKai2MeqLexBckEbxYNHj/A6KCKZ niWd/IHl1MvfoCBDvQY9AKxFqb/M0k4ZHT39TJga4pm3Z0NkjjrEJDE3NWosFo62tNOZ +tAeH9R9kiP73Ndqoi/aE9QPl9edGUc2oZF8ooC39K6/OeyiB+ER57j5zYGJphs+l41U tPMO319gzC0gLRXpgUOJ3El9/+FGMb10HySczxZlAQmnf/jMPHJveAIxl/WqMSKzcFr/ 2bDg==
X-Gm-Message-State: APjAAAVsxRAWqdP116DC+4jAH2/X5epfZ1+uIo9jvVwkWalUAZpem+bd ql86b6K12yhm7n2064Ui1G0=
X-Google-Smtp-Source: APXvYqwnRRwENPWkjlOE2THt/H/IskPkAfnx1OKGUt0kzzkDXGyvwhnld2VGO5uOd9cTTmVRgwWqQw==
X-Received: by 2002:adf:f050:: with SMTP id t16mr18903602wro.198.1553596965673;  Tue, 26 Mar 2019 03:42:45 -0700 (PDT)
Received: from [2001:67c:1232:144:a019:575b:70::] ([2001:67c:1232:144:a90c:a56a:d8a4:7634]) by smtp.gmail.com with ESMTPSA id t81sm25227905wmb.5.2019.03.26.03.42.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 03:42:45 -0700 (PDT)
Date: Tue, 26 Mar 2019 11:42:36 +0100
From: Jeff Tantsura 
To: Kent Watsen , "=?utf-8?Q?netmod=40ietf.org?=" , "Rob Wilton (rwilton)" 
Message-ID: <6a093ff9-8337-475f-abb2-51ca6a2cf211@Spark>
In-Reply-To: <93a640eda42345958f1c21964f3e2fd0@XCH-RCD-007.cisco.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com> <93a640eda42345958f1c21964f3e2fd0@XCH-RCD-007.cisco.com>
X-Readdle-Message-ID: 6a093ff9-8337-475f-abb2-51ca6a2cf211@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5c9a0224_7fdcc233_159ec"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 10:42:49 -0000

--5c9a0224_7fdcc233_159ec
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

yes/support

Cheers,
Jeff
On Mar 26, 2019, 7:41 AM +0100, Rob Wilton (rwilton) , wrote:
> Support.
>
> =46rom: netmod  On Behalf Of Kent Watsen
> Sent: 25 March 2019 21:32
> To: netmod=40ietf.org
> Subject: =5Bnetmod=5D Adoption poll for draft-chopps-netmod-geo-locatio=
n-01
>
> This email begins a 2-week adoption poll for:
>
>
> =C2=A0 =C2=A0=C2=A0https://tools.ietf.org/html/draft-chopps-netmod-geo-=
location-01
>
>
> Please voice your support or objections before April 8.
>
>
> Kent // as co-chair
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> netmod mailing list
> netmod=40ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--5c9a0224_7fdcc233_159ec
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline







yes/support




Cheers,

Jeff






On Mar 26, 2019=
, 7:41 AM +0100, Rob Wilton (rwilton) <rwilton=40cisco.com>, wrote:=







Support.


&=23160;








=46rom: netmod <netmod-bounces=40ietf.org> On Behalf Of Kent Watsen=


Sent: 25 March 2019 21:32

To: netmod=40ietf.org

Subject: =5Bnetmod=5D Adoption poll for draft-chopps-netmod-geo-lo=
cation-01






&=23160;




This email begins a 2-week adoption poll for:<=
/p>
























Please voice your support or objections before=
 April 8.















Kent // as co-chair















&=23160;











=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

netmod mailing list

netmod=40ietf.org

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






--5c9a0224_7fdcc233_159ec--


From nobody Tue Mar 26 03:53:11 2019
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 BD3BD1202BC for ; Tue, 26 Mar 2019 03:53: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, SPF_PASS=-0.001, URIBL_BLOCKED=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 lKvRBYMCiTsm for ; Tue, 26 Mar 2019 03:53:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C688A1202A4 for ; Tue, 26 Mar 2019 03:53:07 -0700 (PDT)
Received: from localhost (dhcp-97ad.meeting.ietf.org [31.133.151.173]) by mail.tail-f.com (Postfix) with ESMTPSA id 8FB581AE02BD; Tue, 26 Mar 2019 11:53:05 +0100 (CET)
Date: Tue, 26 Mar 2019 11:53:03 +0100 (CET)
Message-Id: <20190326.115303.1797338774709462584.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: balazs.lengyel@ericsson.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20190325232240.ttcddrly3gnmldod@anna.jacobs.jacobs-university.de>
References: <20190325221609.hiuif4fafhheynok@anna.jacobs.jacobs-university.de> <8cc2ecb9-53b8-36dc-97d9-e7ce92a27d5c@ericsson.com> <20190325232240.ttcddrly3gnmldod@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] instance data new backward compatibility text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 10:53:11 -0000

Hi

I agree with Juergen.  I think section 6 should be removed.  This
document should specify the document format (which it does), but it
shouldn't specify specific rules for the different use cases.


/martin


Juergen Schoenwaelder  wrote:
> Your rules are use case specific and I am not convinced they are
> applying to all use cases. It should be a perfectly valid use case to=

> store snapshots of  in instance data files. Your rules do no=
t
> make sense here and I do not think this is a valid usage of the SHOUL=
D
> mechanism.
> =

> /js
> =

> On Mon, Mar 25, 2019 at 11:01:52PM +0000, Bal=C3=A1zs Lengyel wrote:
> >    Hello Jurgen,
> > =

> >    I don't think these rules are Ericsson specific. In some of our =
most
> >    important use-cases (UC1, UC2, UC6) changing the keys would lead=
 to
> >    problems.
> > =

> >    UC1: If you document server capabilities using ietf-yang-library=
 the name
> >    of the module sets may be/should be meaningful. It might be used=
 by the
> >    NMS to compare the capabilities of different versions of the YAN=
G server;
> >    changing keys without a reason will mislead the NMS into assumin=
g the
> >    server capabilities changed..
> > =

> >    UC2: Preloading default configuration data. E.g.=C2 If you chang=
e the
> >    identifier of NACM ruleset, then during upgrade it might be load=
ed again
> >    as the server can not detect, that this is the same ruleset that=
 is
> >    already in the datastore.
> > =

> >    UC6:=C2 Storing diagnostics data. If you change the keys used in=
 diagnostic
> >    data, comparing values before and after the key change will be d=
ifficult.
> > =

> >    And yes as we were using instance data for the last then years, =
we did
> >    have a lot of problem with people changing the keys without cons=
idering
> >    compatibility effects.
> >    I agree that this is not always a problem, so I only used SHOULD=
=C2 (and not
> >    MUST) in the text.
> > =

> >    regards Balazs
> > =

> > =

> >    On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:
> > =

> >  On Mon, Mar 25, 2019 at 09:59:43PM +0000, Bal=E1zs Lengyel wrote:
> > =

> >  Hello Jurgen,
> > =

> >  You are right that this is important mostly for instance data prep=
ared as a
> >  design/implementation activity; while not relevant for data coming=
 from the
> >  node.
> >  I will add it.
> > =

> >  However in the first case it is vital!
> > =

> >  For config files, and also for file documenting server capabilitie=
s we have
> >  had MANY problems with people changing the key values/identities o=
f list
> >  entries.
> >  They think it is a nice idea to provide better, more meaningful ke=
y values;
> >  however the NMS designers use these key values to detect changes; =
also
> >  during an upgrade process if a default configuration file is loade=
d again
> >  with slightly changed key values, then e.g. access control rules b=
ecome
> >  duplicated.
> > =

> > =

> >  The conditions under which it is meaningful to change keys and whe=
n it
> >  is not appropriate are very application specific.  You may have
> >  specific use cases at Ericsson where you want internal regulations=
 but
> >  I do not think this leads to meaningful rules outside your specifi=
c
> >  application scenario.
> > =

> >  /js
> > =

> > =

> >  --
> >  Balazs Lengyel                       Ericsson Hungary Ltd.
> >  Senior Specialist
> >  Mobile: +36-70-330-7909              email: [1]Balazs.Lengyel@eric=
sson..com
> > =

> > References
> > =

> >    Visible links
> >    1. mailto:Balazs.Lengyel@ericsson.com
> =

> =

> =

> > _______________________________________________
> > 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 | German=
y
> Fax:   +49 421 200 3103         
> =


From nobody Tue Mar 26 04:19:58 2019
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 52D591202D0 for ; Tue, 26 Mar 2019 04:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 nQHPhbyIM0Zh for ; Tue, 26 Mar 2019 04:19:53 -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 E94351202A4 for ; Tue, 26 Mar 2019 04:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1030; q=dns/txt; s=iport; t=1553599193; x=1554808793; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=4YtbrO/8vefKM3yGSWJOvyCAUGL69bCeuq236Mc/R5M=; b=BR8r0q34SNYNLlLJ833KFVVd64GwM6o/w9UoQThuIz1QXJY3hp0MIcDU PPF0onbdNSmFL70hk2X/s0NBePzI9cYDG5CjnU927j2JPRh3dm3hTxmvo 2AFCdVPmgI+511TQJ4cRBzMOtZ3rHOB6N4BGnNC0BqzF1jhUdNROM2f8+ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAACsCppc/5tdJa1KFwMbAQEBAQM?= =?us-ascii?q?BAQEHAwEBAYFRBgEBAQsBghBoA00zJ4QOiByLJIFgCJhggXsPJYRHhSMiNAk?= =?us-ascii?q?NAQEDAQEJAQMCbRwBC4V0QyEnAhAEDAYCHTsHDQYCAQGDHgGBdQ81rGGBL4N?= =?us-ascii?q?Chm0FBYEGJAGFOYV4F4FAP4ERJwyEIQGBXAQYgTgwJgiCO4JXA4poAocRkx4?= =?us-ascii?q?Jh2OLUgYZiyWFL4Muix2GBo1SgU04gVZNIxWDJxOCAwwLgSyCH4pvIwMwAY4?= =?us-ascii?q?egikBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="251885035"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 11:19:47 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x2QBJkUX023505 for ; Tue, 26 Mar 2019 11:19:47 GMT
To: "netmod@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: 
Date: Tue, 26 Mar 2019 07:19:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: [netmod] WebEx for today's YANG versioning design team working session
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 11:19:56 -0000

We have created a WebEx (see below) for today's working session meeting
for those that may want to join from remote.  We will all be able to see
the shared content that comes from our discussion.  However, the audio
may not be very strong.

The meeting is at 16:00 UTC+1 until 18:30 UTC+1 today, March 26.

Joe

NETMOD YANG Version Design Team Working Session
Hosted by Joe Clarke

Tuesday, Mar 26, 2019 11:00 am | 2 hours 30 minutes | (UTC-05:00)
Eastern Time (US & Canada)
Meeting number: 204 071 949
Password: yangver (9264837 from phones)
https://cisco.webex.com/cisco/j.php?MTID=m2bd0b7997ef45871811dd0c22e03a9f3

Join by video system
Dial 204071949@cisco.webex.com
You can also dial 173.243.2.68 and enter your meeting number.
>From the Cisco internal network, dial *267* and the 9-digit meeting
number.  If you are the host, enter your PIN when prompted.

Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 204 071 949


From nobody Tue Mar 26 05:18:19 2019
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 3E2251202D1 for ; Tue, 26 Mar 2019 05:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 B8Sh75QfOjjl for ; Tue, 26 Mar 2019 05:18:16 -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 42CE81202BC for ; Tue, 26 Mar 2019 05:18:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1651; q=dns/txt; s=iport; t=1553602696; x=1554812296; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NxSKaajSvEy5RO/0jP7rOx6NOh4v8CXaGGv4j6kbpJw=; b=IO9dhfyiM8mqXrYWvR5IyRGYmp5j6/3tV8nzOrz17+cFxheerQYd4VDt mzqgxqSLmCL1SsESJBRTJc+dzOWo4secCdtKI/tE+y3bW9eJ+0aJQ0P7J XgnruQkg0xPCLNWAvByMyWeLL72xYaxyXIBYW0vbHpCHmSV3InyxH65bm g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAATGJpc/49dJa1JFwMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFRBAEBAQEBCwGBZipogQMnCowgiySCDZg7gXsNAQE?= =?us-ascii?q?YC4QDRgKFIiI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQBATgsCBcCAgIBCBEEAQE?= =?us-ascii?q?VBAYGChsMCx0HAQIEARIIgxuBdQ81rX6DQoZtBQWBKgGFOYV4F4FAP4ERgxI?= =?us-ascii?q?+gQQBgVwBAQIYgTgwJgiFEgOKaAKaLwkCh2GLUCGQVIMuix2GBo0sAhEVgS4?= =?us-ascii?q?fOIFWcBU7gmwTggMXgQABCCOCH4UUhT9BMQGOEoEKgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208";a="539720621"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 12:18:14 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QCIE85026520 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Mar 2019 12:18:14 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 07:18:13 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 07:18:13 -0500
From: "Rob Wilton (rwilton)" 
To: "Joe Clarke (jclarke)" , "netmod@ietf.org" 
Thread-Topic: [netmod] WebEx for today's YANG versioning design team working session
Thread-Index: AQHU48XgjGYVJxfxrEyKkk/lWmELwqYd0+iw
Date: Tue, 26 Mar 2019 12:18:13 +0000
Message-ID: <7b0a88fe8c5e47cfad68f89624592910@XCH-RCD-007.cisco.com>
References: 
In-Reply-To: 
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.61.79.96]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: 
Subject: Re: [netmod] WebEx for today's YANG versioning design team working session
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 12:18:18 -0000

Having taken a quick look in the room then it looks like we should be able =
to project and also hopefully connect to teleconferencing.

Thanks,
Rob

> -----Original Message-----
> From: netmod  On Behalf Of Joe Clarke
> Sent: 26 March 2019 12:20
> To: netmod@ietf.org
> Subject: [netmod] WebEx for today's YANG versioning design team working
> session
>=20
> We have created a WebEx (see below) for today's working session meeting f=
or
> those that may want to join from remote.  We will all be able to see the =
shared
> content that comes from our discussion.  However, the audio may not be ve=
ry
> strong.
>=20
> The meeting is at 16:00 UTC+1 until 18:30 UTC+1 today, March 26.
>=20
> Joe
>=20
> NETMOD YANG Version Design Team Working Session Hosted by Joe Clarke
>=20
> Tuesday, Mar 26, 2019 11:00 am | 2 hours 30 minutes | (UTC-05:00) Eastern
> Time (US & Canada) Meeting number: 204 071 949
> Password: yangver (9264837 from phones)
> https://cisco.webex.com/cisco/j.php?MTID=3Dm2bd0b7997ef45871811dd0c22e0
> 3a9f3
>=20
> Join by video system
> Dial 204071949@cisco.webex.com
> You can also dial 173.243.2.68 and enter your meeting number.
> >From the Cisco internal network, dial *267* and the 9-digit meeting
> number.  If you are the host, enter your PIN when prompted.
>=20
> Join by phone
> +1-408-525-6800 Call-in toll number (US/Canada)
> +1-866-432-9903 Call-in toll-free number (US/Canada)
> Access code: 204 071 949
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Mar 26 06:33:35 2019
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 A4B2012006A for ; Tue, 26 Mar 2019 06:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=eLJHypaF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nDafYDH0
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvIIXVTyDTFa for ; Tue, 26 Mar 2019 06:33:31 -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 A1A6712008A for ; Tue, 26 Mar 2019 06:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5797; q=dns/txt; s=iport; t=1553607211; x=1554816811; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4NgfwgofoRK5vZlMaHc6rnDI66X9ufLNeDfoqNNNpBs=; b=eLJHypaFGRKahZNt13fqevo+j4qPMmWpGR/x7kUbB0MZGvq25Djl67np xEN3f8bGqs5X8uBEBqmXKMV0TtrXq/VTs6/sM6jFvvDaXQ/kZZUBocIIE 1j5L9P8ma4X544pAlieme5vKnDEqPjW+KTb6dJdZaJcu3QIRsO3dT+eAv g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AJc3EXxRt6i3x/LMsb68vt58kUNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUANfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5NksAKh0olCc+BB1f8KavjZCE3NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABuKZpc/4QNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDi9QA2h0BAsnhA6DRwOEUopbSoFoJZJEhEm?= =?us-ascii?q?BLhSBEANUDQEBIwmEQAIXhQsiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIx0BATg?= =?us-ascii?q?PAgEIEQMBAisCAgIwHQgCBAESgyIBgRFMAxUBDqITAooUcYEvgngBAQWBNQK?= =?us-ascii?q?BEIJCGIIMAwWBLwGLMReBf4E4DBOCTD6CYQEBAgGBKwESAT8Ngl0xgiaMc4Q?= =?us-ascii?q?hh0eMQQkCh2GLWBmCAoV9jAOLHYYGjSwCBAIEBQIOAQEFgU04ZXFwFWUBgkG?= =?us-ascii?q?CCoNuhRSFP3KBKIxWgj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="543069477"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 13:33:30 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QDXU7G001718 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 13:33:30 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 08:33:29 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 08:33:29 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 09:33:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4NgfwgofoRK5vZlMaHc6rnDI66X9ufLNeDfoqNNNpBs=; b=nDafYDH0OtpJt1khlNVjf/IN1D9YZQ1bAWyY9ZY4Otik3B3PBo4qtGNSQvtJM0uzVzS+jMvuQhrd6OekkPmvfOqps18Gdu3dk7gTJBVuJwoXnvOqweMVu1GgpUQ3Bo2Qbi6cO0avYEzQ53Jex0MzFOXVGxc0YVOAFGb9g9fW9nk=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2130.namprd11.prod.outlook.com (10.174.239.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 13:33:27 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28%5]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 13:33:27 +0000
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
Thread-Index: AQHU40nxEcHK5jtKOE+P9bUg65mv4aYdp1kA
Date: Tue, 26 Mar 2019 13:33:27 +0000
Message-ID: <93D0C4A0-4383-4052-A616-310A56D3F1B8@cisco.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; 
x-originating-ip: [2001:420:c0c8:1007::44f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4fe1a700-e6db-42fe-54b0-08d6b1efa0fb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2130; 
x-ms-traffictypediagnostic: BN6PR1101MB2130:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(396003)(376002)(346002)(189003)(199004)(446003)(11346002)(4744005)(6246003)(81156014)(6436002)(76176011)(53936002)(105586002)(2616005)(6116002)(81166006)(8676002)(229853002)(86362001)(82746002)(68736007)(478600001)(476003)(54896002)(236005)(6486002)(316002)(6306002)(6512007)(7736002)(110136005)(2906002)(46003)(2501003)(102836004)(83716004)(5660300002)(14454004)(97736004)(486006)(8936002)(6506007)(71190400001)(25786009)(106356001)(33656002)(36756003)(606006)(53546011)(71200400001)(186003)(256004)(99286004)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2130; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: JwFcWL9PCh1zHkSbjTyFYZHcOPCYtp7fQqCUNVaDrIF5t7t8n+u1M+S0srSfRvlrzGMtfYpoRNRnJMHmDVaWUthjUTiFL80Bo1NLjR5NivYXj2cDFuE53YxozdBxcsP3gezpPPaBZCPMOiEx4BYqO5lJm1p8/hW7RK2BXJloLk/r5lyuJeAz09Za1LMfRJhKvNNQnfmlvTlHbmFIr32aPGYWiV+SE/Q4qWu/RDX6e/ZWAE+GmLbsy/ymaznjWeX1HuGCpHTUDePlbZLvG+pCNrpZjR8wjH4rE5XbwTOkFX3xAq62G7FP5TQUHIXuFqnSYKl7Y9Y2xamkdDZBpkw1GASiktOIYS6xnQYt6IEc6+CQW8Up8E4IcuguUjDVZvbyaRnO01H+hm7D4iLstR7YvTvozbkgqBQQdaX4vpYAHWA=
Content-Type: multipart/alternative; boundary="_000_93D0C4A043834052A616310A56D3F1B8ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fe1a700-e6db-42fe-54b0-08d6b1efa0fb
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 13:33:27.4708 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2130
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 13:33:34 -0000

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

SSBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBuZXRtb2QgPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGtlbnQraWV0
ZkB3YXRzZW4ubmV0Pg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAyNSwgMjAxOSBhdCA0OjMzIFBNDQpU
bzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFtuZXRtb2Rd
IEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNob3Bwcy1uZXRtb2QtZ2VvLWxvY2F0aW9uLTAxDQoN
ClRoaXMgZW1haWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQoNCiAgICBo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hvcHBzLW5ldG1vZC1nZW8tbG9jYXRp
b24tMDENCg0KDQpQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbnMgYmVmb3Jl
IEFwcmlsIDguDQoNCg0KS2VudCAvLyBhcyBjby1jaGFpcg0KDQoNCg0K

--_000_93D0C4A043834052A616310A56D3F1B8ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <2FB073BCD4FB5F4D94D8906C3B44B551@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgc3VwcG9ydCBXRyBhZG9wdGlvbi4gPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5BY2VlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Y29sb3I6YmxhY2siPm5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7
IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0
Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDI1LCAyMDE5IGF0IDQ6MzMgUE08YnI+
DQo8Yj5UbzogPC9iPiZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYu
b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBk
cmFmdC1jaG9wcHMtbmV0bW9kLWdlby1sb2NhdGlvbi0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGVtYWlsIGJlZ2lucyBhIDItd2Vl
ayBhZG9wdGlvbiBwb2xsIGZvcjoNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaG9wcHMtbmV0bW9kLWdlby1sb2NhdGlvbi0wMSI+aHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNob3Bwcy1uZXRtb2QtZ2VvLWxvY2F0aW9u
LTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPlBsZWFzZSB2b2ljZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyBiZWZvcmUgQXByaWwg
OC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5L
ZW50IC8vIGFzIGNvLWNoYWlyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_93D0C4A043834052A616310A56D3F1B8ciscocom_--


From nobody Tue Mar 26 06:34:34 2019
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 18B311202DC for ; Tue, 26 Mar 2019 06:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=lTT2z3ZX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Yov60zkO
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGDRDCweOfCD for ; Tue, 26 Mar 2019 06:34:29 -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 8397E12008A for ; Tue, 26 Mar 2019 06:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5605; q=dns/txt; s=iport; t=1553607265; x=1554816865; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Pq44GLdKRtUZULQFp1iPFdc9nDsXah0RpEX1oC3lAgM=; b=lTT2z3ZXteCYkHr/9F7HOyxoAb4lfkNES22Ycf68vYUFz+590xNTRNZ6 JfGAIqRagEE+Fy8IlP/0sotcKNRZcypGac9lCDtY1z8hVZjks8fQl8q/e nkgnw3Ze5u0w4uMmNgZzn7eQVpvGEge6Vjn6Y26kPYfIRJySGwEA60bXy 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3A0FvMgx9bA5nj2P9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98RmlkpC8OIIUb6N/XtKSc9GZcKWQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABuKZpc/4ENJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDi9QA2h0BAsnhA6DRwOEUopbSoFoJZJEhEm?= =?us-ascii?q?BLhSBEANUDQEBIwmEQAIXhQsiNAkNAQEDAQEJAQMCbRwMhUoBAQEEIx0BATg?= =?us-ascii?q?PAgEIEQMBAisCAgIwHQgCBAESgyIBgRFMAxUBDqITAooUcYEvgngBAQWBNQK?= =?us-ascii?q?BEIJCGIIMAwWBLwGLMReBf4E4DBOCTD6CYQEBA4ErARIBPw2CXYJXjHOEIYd?= =?us-ascii?q?HjEEJAodhi1gZggKFfYwDix2GBo0sAgQCBAUCDgEBBYFNOGVxcBVlAYJBggq?= =?us-ascii?q?DboUUhT9ygSiMVoI+AQE?=
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600";  d="scan'208,217";a="539748212"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 13:34:22 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QDYMCv013211 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 13:34:22 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 08:34:21 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 08:34:21 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 08:34:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pq44GLdKRtUZULQFp1iPFdc9nDsXah0RpEX1oC3lAgM=; b=Yov60zkO7weTqoD7OaHzpJbpXWKdRsBtPBfltdf/pkpfoQ0HOwYelQSyJflDVzUEkcZsGK0b4gK04cTy6m8EMKwDaLMMhfgiNnnF61epBI/FbL07wXr8IPMHKOKHzb2jK53zEuqFXmdWKf61ME3VOzccz7QmKqm+eElClLJI3u0=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2130.namprd11.prod.outlook.com (10.174.239.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 13:34:20 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28%5]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 13:34:20 +0000
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
Thread-Index: AQHU40mogl9FECn/TEiI87fVTWhGZKYdp5iA
Date: Tue, 26 Mar 2019 13:34:20 +0000
Message-ID: <43A8102D-B0A7-4376-89C5-7255298537DF@cisco.com>
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; 
x-originating-ip: [2001:420:c0c8:1007::44f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 234def6d-04e6-4b81-12d1-08d6b1efc060
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2130; 
x-ms-traffictypediagnostic: BN6PR1101MB2130:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(396003)(376002)(346002)(189003)(199004)(446003)(11346002)(4744005)(6246003)(81156014)(6436002)(76176011)(53936002)(105586002)(2616005)(6116002)(81166006)(8676002)(229853002)(86362001)(82746002)(68736007)(478600001)(476003)(54896002)(236005)(6486002)(316002)(6306002)(6512007)(7736002)(110136005)(2906002)(46003)(2501003)(102836004)(83716004)(5660300002)(14454004)(97736004)(486006)(8936002)(6506007)(71190400001)(25786009)(106356001)(33656002)(36756003)(606006)(53546011)(71200400001)(186003)(256004)(99286004)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2130; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: FoefPYqw0NTqt5xcHOM/AfoWjqx2FHwQmPWbedO1Kizn/Fk6kqg+06nMEF1V+Y/9XWy8PygcL+hYNYPJR73aCnHKgHdPYxFlykxKOuC5+n6u9Y/g9nAIzdrrWr7jYQJBHMb6readdeSORp8jHrSgw1HAPMgV0S++6ZYjpbkShoRO8OGslRWPhnMcLQ8QZONZRFyqug7tIYStLxK8SnhF19i1C8dvihWDxBHLhUxY3Xh9hDsO+t1TEBEm9VjRvHYcqe/wuncadjBxDDvEYC4cOeyetxtakOFrRV93y+uVYGyD9gnFgE753etM6p6PEt+T/zWF29Q18eHlTvP4wRk4VUKqMgWSr2Aa+D6v4HqfTSC8UR80nlwXw13MZBEX/hdeE6/CJJKmNlwF47vm2j7XVlrVp5S02n1NtLqvnydJoVY=
Content-Type: multipart/alternative; boundary="_000_43A8102DB0A7437689C57255298537DFciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 234def6d-04e6-4b81-12d1-08d6b1efc060
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 13:34:20.1404 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2130
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 13:34:32 -0000

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

SSBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KQWNlZQ0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4u
bmV0Pg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAyNSwgMjAxOSBhdCA0OjMxIFBNDQpUbzogIm5ldG1v
ZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFtuZXRtb2RdIEFkb3B0aW9u
IHBvbGwgZm9yIGRyYWZ0LXNjaG9lbnctbmV0bW9kLXJmYzY5OTEtYmlzLTAwDQoNClRoaXMgZW1h
aWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQoNCiAgICBodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nob2Vudy1uZXRtb2QtcmZjNjk5MS1iaXMtMDANCg0K
DQpQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbnMgYmVmb3JlIEFwcmlsIDgu
DQoNCg0KS2VudCAoYW5kIExvdSBhbmQgSm9lbCkNCg0K

--_000_43A8102DB0A7437689C57255298537DFciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <77D05F01701B9E46B80D1E89605C268F@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgc3VwcG9ydCBXRyBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkFjZWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+bmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0Bp
ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdh
dHNlbi5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgTWFyY2ggMjUsIDIwMTkgYXQg
NDozMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7ICZsdDtu
ZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltuZXRtb2RdIEFkb3B0aW9u
IHBvbGwgZm9yIGRyYWZ0LXNjaG9lbnctbmV0bW9kLXJmYzY5OTEtYmlzLTAwPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoaXMgZW1haWwgYmVn
aW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PGEgaHJlZj0i
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaG9lbnctbmV0bW9kLXJmYzY5OTEt
YmlzLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nob2Vudy1uZXRtb2Qt
cmZjNjk5MS1iaXMtMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjVpbiI+UGxlYXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb25zIGJl
Zm9yZSBBcHJpbCA4LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW4iPktlbnQgKGFuZCBMb3UgYW5kIEpvZWwpPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_43A8102DB0A7437689C57255298537DFciscocom_--


From nobody Tue Mar 26 06:37:26 2019
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 2966A120043 for ; Tue, 26 Mar 2019 06:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 ErPhZLzxCTAk for ; Tue, 26 Mar 2019 06:37:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 4F05B120394 for ; Tue, 26 Mar 2019 06:37:17 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0842DE813274E794231B; Tue, 26 Mar 2019 13:37:15 +0000 (GMT)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 13:37:14 +0000
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 26 Mar 2019 13:37:14 +0000
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 26 Mar 2019 13:37:14 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 21:37:09 +0800
From: Qin Wu 
To: Kent Watsen , "Rob Wilton (rwilton)" 
CC: Kent Watsen , "netmod@ietf.org" , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AdTjt49+/Dg5AILGT8i5Hz+oFOy1ew==
Date: Tue, 26 Mar 2019 13:37:08 +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.220.68.43]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA48802B6nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 13:37:25 -0000

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

5Y+R5Lu25Lq6OiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnRAd2F0c2VuLm5ldF0NCuWPkemAgeaX
tumXtDogMjAxOeW5tDPmnIgyNuaXpSAxNTozNw0K5pS25Lu25Lq6OiBSb2IgV2lsdG9uIChyd2ls
dG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQrmioTpgIE6IEtlbnQgV2F0c2VuIDxrZW50K2lldGZA
d2F0c2VuLm5ldD47IG5ldG1vZEBpZXRmLm9yZzsgQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVu
Z3llbEBlcmljc3Nvbi5jb20+OyBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCuS4u+mimDog
UmU6IFtuZXRtb2RdIEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRl
ZmF1bHQtMDINCg0KDQpJIHdvdWxkIHJhdGhlciBzZWUgPGNvcHktY29uZmlnPiBmaXhlZCBtb3Jl
IGdlbmVyaWNhbGx5IHRvIGFsbG93IGNvcHlpbmcgYmV0d2VlbiB0d28gY29uZmlndXJhdGlvbiBk
YXRhc3RvcmVzIHRoYW4gc3BlY2lmaWNhbGx5IGF1Z21lbnRpbmcgc3BlY2lmaWNhbGx5IGZvciB0
aGlzIGRhdGFzdG9yZS4gIEhlbmNlLCBJIHRoaW5rIHRoYXQgZXh0ZW5kaW5nL3JlcGxhY2luZyB0
aGUgPGNvcHktY29uZmlnPiBSUEMgY291bGQgcHJvYmFibHkgYmUgZGVmZXJyZWQgdG8gYSBORVRD
T05GLWJpcyBvciBORVRDT05GLU5NREEtYmlzIGRvY3VtZW50Lg0KDQpBZ3JlZWQuICBRaW4sIHBs
ZWFzZSBhZGQgdG8gdGhlIE5FVENPTkYtbmV4dCBpc3N1ZSB0cmFja2VyLg0KDQpodHRwczovL2dp
dGh1Yi5jb20vbmV0Y29uZi13Zy9uZXRjb25mLW5leHQvaXNzdWVzPGh0dHBzOi8vZ2l0aHViLmNv
bS9uZXRjb25mLXdnL25ldGNvbmYtbmV4dC9pc3N1ZXMvPg0KDQpbUWluXTogRG9uZS4NCktlbnQN
Cg==

--_000_B8F9A780D330094D99AF023C5877DABAA48802B6nkgeml513mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buROw0KCXBhbm9zZS0xOjIg
MTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5b6u6L2v
6ZuF6buRIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj
MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJa
SC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7
tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7
kSZxdW90OyxzYW5zLXNlcmlmIj4gS2VudCBXYXRzZW4gW21haWx0bzprZW50QHdhdHNlbi5uZXRd
DQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkemAgeaXtumXtDxzcGFu
IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz
YW5zLXNlcmlmIj4gMjAxOTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFu
Zz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI2PC9zcGFuPuaXpTxzcGFu
IGxhbmc9IkVOLVVTIj4NCiAxNTozNzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5n
PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSb2IgV2lsdG9uIChyd2ls
dG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFu
IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtlbnQgV2F0c2Vu
ICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7OyBuZXRtb2RAaWV0Zi5vcmc7IEJhbDwv
c3Bhbj7DoTxzcGFuIGxhbmc9IkVOLVVTIj56cyBMZW5neWVsICZsdDtiYWxhenMubGVuZ3llbEBl
cmljc3Nvbi5jb20mZ3Q7OyBRaW4gV3UgJmx0O2JpbGwud3VAaHVhd2VpLmNvbSZndDs8YnI+DQo8
L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIj4gUmU6IFtuZXRtb2RdIEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXd1LW5ldG1vZC1m
YWN0b3J5LWRlZmF1bHQtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291bGQgcmF0aGVyIHNlZSAmbHQ7Y29w
eS1jb25maWcmZ3Q7IGZpeGVkIG1vcmUgZ2VuZXJpY2FsbHkgdG8gYWxsb3cgY29weWluZyBiZXR3
ZWVuIHR3byBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMgdGhhbiBzcGVjaWZpY2FsbHkgYXVnbWVu
dGluZyBzcGVjaWZpY2FsbHkgZm9yIHRoaXMgZGF0YXN0b3JlLiZuYnNwOyBIZW5jZSwgSSB0aGlu
ayB0aGF0IGV4dGVuZGluZy9yZXBsYWNpbmcgdGhlDQogJmx0O2NvcHktY29uZmlnJmd0OyBSUEMg
Y291bGQgcHJvYmFibHkgYmUgZGVmZXJyZWQgdG8gYSBORVRDT05GLWJpcyBvciBORVRDT05GLU5N
REEtYmlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+QWdyZWVkLiAmbmJzcDtRaW4sIHBsZWFzZSBhZGQgdG8gdGhlIE5FVENPTkYtbmV4
dCBpc3N1ZSB0cmFja2VyLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvbmV0
Y29uZi1uZXh0L2lzc3Vlcy8iPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL25ldGNvbmYt
bmV4dC9pc3N1ZXM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+W1Fpbl06IERvbmUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5LZW50PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_B8F9A780D330094D99AF023C5877DABAA48802B6nkgeml513mbxchi_--


From nobody Tue Mar 26 07:05:03 2019
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 BD3691202F9 for ; Tue, 26 Mar 2019 07:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=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 WBNaRi1YSM2B for ; Tue, 26 Mar 2019 07:05:00 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 E4CBA120342 for ; Tue, 26 Mar 2019 07:04:59 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.129.192; 
From: Susan Hares 
To: Kent Watsen , 
Date: Tue, 26 Mar 2019 10:04:57 -0400
Message-ID: <5c9a3189.6fc.10e0.6c18@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_SW_3979_1553609097_mpa="
X-Originating-IP: 31.133.129.192
X-Mailer: SurgeWeb - Ajax Webmail Client
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 14:05:02 -0000

This is a multi-part message in MIME format.

------=_SW_3979_1553609097_mpa=
Content-Type: text/plain; charset=us-ascii; format=flowed


 Kent:

This is a useful feature.  The draft is a good place to start the 
work, but there are issues that need to be agreed upon.

Sue


On Monday 25/03/2019 at 4:35 pm, Kent Watsen  wrote:
>
>
>
> This email begins a 2-week adoption poll for:
>
>
>
>    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
>
>
> Please voice your support or objections before April 8.
>
>
> Kent (and Lou)_______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


------=_SW_3979_1553609097_mpa=
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable







 Kent: 

This is a useful feature.&nb=
sp; The draft is a good place to start the work, but there are issues that n=
eed to be agreed upon. 

Sue  
<=
div> 
On Monday 25/03/2019=
 at 4:35 pm, Kent Watsen  wrote: 
<=
div>This email beg=
ins a 2-week adoption poll for:

https://tools.ietf.org/html/dra=
ft-wu-netmod-factory-default-02

Please voic=
e your support or objections before April 8.

Kent (and Lou)<=
/span>
________________________________________=
_______
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mai=
lman/listinfo/netmod


 


------=_SW_3979_1553609097_mpa=--


From nobody Tue Mar 26 07:49:31 2019
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 DBEF512033B for ; Tue, 26 Mar 2019 07:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 J8Pu1huFtJKc for ; Tue, 26 Mar 2019 07:49:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 32291120329 for ; Tue, 26 Mar 2019 07:49:28 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 71E92ABBE349D8583B87 for ; Tue, 26 Mar 2019 14:49:25 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 14:49:24 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.5]) by SJCEML702-CHM.china.huawei.com ([169.254.4.253]) with mapi id 14.03.0439.000;  Tue, 26 Mar 2019 07:49:19 -0700
From: Yingzhen Qu 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
Thread-Index: AQHU40nq8dZ8uYH9/kmkpsycCVCjGKYd/5AA
Date: Tue, 26 Mar 2019 14:49:18 +0000
Message-ID: <48FBA85F-81F5-4153-8B48-4B22EF149C60@huawei.com>
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.220.68.196]
Content-Type: multipart/alternative; boundary="_000_48FBA85F81F541538B484B22EF149C60huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 14:49:30 -0000

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

SSBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KDQpUaGFua3MsDQpZaW5nemhlbg0KDQpGcm9tOiBuZXRt
b2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGtl
bnQraWV0ZkB3YXRzZW4ubmV0Pg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAyNSwgMjAxOSBhdCAxOjMy
IFBNDQpUbzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFtu
ZXRtb2RdIEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNob3Bwcy1uZXRtb2QtZ2VvLWxvY2F0aW9u
LTAxDQoNClRoaXMgZW1haWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQoN
CiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hvcHBzLW5ldG1vZC1nZW8t
bG9jYXRpb24tMDENCg0KDQpQbGVhc2Ugdm9pY2UgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbnMg
YmVmb3JlIEFwcmlsIDguDQoNCg0KS2VudCAvLyBhcyBjby1jaGFpcg0KDQoNCg0K

--_000_48FBA85F81F541538B484B22EF149C60huaweicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <35790C746C0197449C8B36410A44B657@huawei.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6
MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT
dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v
cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh
bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r
Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2
Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w
LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv
cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9ydCBXRyBhZG9w
dGlvbi4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPllpbmd6aGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv
bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi
ZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZndDs8YnI+
DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBNYXJjaCAyNSwgMjAxOSBhdCAxOjMyIFBNPGJyPg0KPGI+
VG86IDwvYj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZn
dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W25ldG1vZF0gQWRvcHRpb24gcG9sbCBmb3IgZHJhZnQt
Y2hvcHBzLW5ldG1vZC1nZW8tbG9jYXRpb24tMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZW1haWwgYmVnaW5zIGEgMi13
ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNob3Bwcy1uZXRtb2QtZ2VvLWxvY2F0aW9u
LTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hvcHBzLW5ldG1vZC1nZW8t
bG9jYXRpb24tMDE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSB2b2ljZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9u
cyBiZWZvcmUgQXByaWwgOC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBhcyBjby1jaGFpcjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_48FBA85F81F541538B484B22EF149C60huaweicom_--


From nobody Tue Mar 26 08:09:59 2019
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 C235A120415 for ; Tue, 26 Mar 2019 08:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level: 
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ss5W00zCedd4 for ; Tue, 26 Mar 2019 08:09:52 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70083.outbound.protection.outlook.com [40.107.7.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A331203CE for ; Tue, 26 Mar 2019 08:09:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kAMhdP6OX5T8IbQukDExCgS9wj43p79hrWXxIGv2hwA=; b=flHPapuZ6qDDEAA+JHDoudEUkjT+vBucZ3VF0CqZgaMBUwWsth+t+kzarU0VjrK+t1dG8vqThgR7yWp1DXEQI9NC6nbrEakOhPwQiHOQjaa8hJ7u2bh1L6dQDG0i/YIcdojoVmkatXcwNC3qLy3Fh9SSmZ3/azn2/xClmASG/Ow=
Received: from DB7PR07MB3850.eurprd07.prod.outlook.com (52.134.99.143) by DB7PR07MB5548.eurprd07.prod.outlook.com (20.178.45.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.10; Tue, 26 Mar 2019 15:09:48 +0000
Received: from DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::6c96:5ffd:d461:9f5e]) by DB7PR07MB3850.eurprd07.prod.outlook.com ([fe80::6c96:5ffd:d461:9f5e%3]) with mapi id 15.20.1750.014; Tue, 26 Mar 2019 15:09:48 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Kent Watsen , "bill.wu@huawei.com" , "niuye@huawei.com" , "rohitrranade@huawei.com" 
CC: "netmod@ietf.org" 
Thread-Topic: IPR poll on draft-wu-netmod-factory-default-02
Thread-Index: AQHU4+X0dEMhsxG08UShp4suW6MB1Q==
Date: Tue, 26 Mar 2019 15:09:48 +0000
Message-ID: 
References: <7C9A4660-9BC6-4B37-AB96-9E4B33FBC44D@watsen.net> <01000169b68012f8-63de3dbd-d0a8-4276-99f7-b4073a98b97e-000000@email.amazonses.com>
In-Reply-To: <01000169b68012f8-63de3dbd-d0a8-4276-99f7-b4073a98b97e-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.95]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: HE1PR0202CA0003.eurprd02.prod.outlook.com (2603:10a6:3:8c::13) To DB7PR07MB3850.eurprd07.prod.outlook.com (2603:10a6:5:7::15)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5bd79dcf-29f6-4bfb-0ea6-08d6b1fd166d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5548; 
x-ms-traffictypediagnostic: DB7PR07MB5548:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(396003)(366004)(346002)(189003)(199004)(2616005)(85182001)(65826007)(99286004)(105586002)(4326008)(8676002)(85202003)(99936001)(486006)(65956001)(476003)(386003)(106356001)(31686004)(66066001)(446003)(81156014)(14444005)(26005)(236005)(36756003)(256004)(2501003)(52116002)(65806001)(2906002)(6246003)(53936002)(102836004)(6512007)(81166006)(3846002)(68736007)(6506007)(54896002)(6486002)(8936002)(966005)(11346002)(6306002)(64126003)(2201001)(7736002)(25786009)(86362001)(14454004)(606006)(478600001)(71190400001)(31696002)(6436002)(71200400001)(186003)(5660300002)(229853002)(316002)(97736004)(6116002)(58126008)(110136005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5548; H:DB7PR07MB3850.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: WnRqx8KhVr85PNafeBvU1AE3Lwte8JyHQzZaC7+6TFGcfprUmXOblr5mp6kXLh4uVwBipO+KYhUeGZlao1+Gix/yxP1n2edDfeCBcO5HyrSwUFYf2CK8n6t1EMDgSSx47qInxw95Fiv/5MX1qBfFchzvFjT3ZWYENOu17x8Jixmjlcu+ljoAmf4YPrtp3d3hSdvxsscTZQTNFJY9ZRbqXKW303NVK9d0JAmAt403yXC5E7ag6MhQa2+3uDShnMvlNjaFsm4fkfCuHsdKE9sWObi4pRih/yYP5DQHD3Bl7bgHNlZnnCi+ddmLXZWfy6F2azc3ntPOEfUGgAypwvdjkfZ2V1CYkI6YcP6UuolNbUZQK4NlQlqN4j4nAnWtBWXMz3W+WVnyfyXLCACLLbxfHCywCZ4GpIb2XGaPqF0Ny2c=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070502020303090506090803"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5bd79dcf-29f6-4bfb-0ea6-08d6b1fd166d
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 15:09:48.4324 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5548
Archived-At: 
Subject: Re: [netmod] IPR poll on draft-wu-netmod-factory-default-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 15:09:58 -0000

--------------ms070502020303090506090803
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
No, I=E2=80=99m not aware=
 of any IPR
        that applies to this draft.

      

    
Balazs

      

    
On 2019. 03. 25. 21:17, Kent Watsen
      wrote:

    

    

      
      
To each author and contributor listed on the "To" line.
          

          In order to complete the Adoption poll, are you aware of any
          IPR that applies

          to=C2=A0draft-wu-netmod-factory-default-02? =C2=A0Please Reply-=
All to
          *this* email and=C2=A0

      
state either:

      


          "No, I'm not aware of any IPR that applies to this draft"

          or

          "Yes, I'm aware of IPR that applies to this draft"

          

          If "yes", has this IPR been disclosed in compliance with IETF
          IPR rules

          (see RFCs 3669, 5378 and 8179 for more details)?
=

          

          If "yes" again, please state either:

          

          "Yes, the IPR has been disclosed in compliance with IETF IPR
          rules"

          or

          "No, the IPR has not been disclosed"

          

          If you answer no, please provide any additional details you
          think appropriate.

          

          If you are listed as a document author or contributor please
          answer the above by

          responding to this email regardless of whether or not you are
          aware of any relevant

          IPR. =C2=A0This document will not advance to the next stage unt=
il a
          response has been

          received from each author and listed contributor. =C2=A0NOTE: T=
HIS
          APPLIES TO ALL

          OF YOU LISTED IN THIS MESSAGE'S TO LINES.

          

          If you are on the WG email list or attend WG meetings but are
          not listed as an author

          or contributor, we remind you of your obligations under the
          IETF IPR rules which

          encourages you to notify the IETF if you are aware of IPR of
          others on an IETF

          contribution, or to refrain from participating in any
          contribution or discussion related

          to your undisclosed IPR. For more information, please see the
          RFCs listed above

          and=C2=A0http://trac.tools.ietf.or=
g/group/iesg/trac/wiki/IntellectualProperty.

          

          Thank you,

          Kent // as co-chair

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms070502020303090506090803
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMyNjE1MDk0Mlow
LwYJKoZIhvcNAQkEMSIEIESltJz/nb+FgPmMB/GhmgBAcfHswEFwdOqprmK8xKBPMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAMD26GWuScB9nq05waUZbsuVyIBMPKAzsywYUa5L+iyiLWzP
vuh+2BWqCKVleMhBpeLVSXNxZJ5ApU7XtHZni8cfCrk9Wl1vKKDuR9WcfbKRppy4NxbBuM0Q
2k1zkAURcr3K9s2v4a616rQ6ZhuvJu+cbpEdItMOTlD70UTUO+5Ql5TRWjn67CzBQtjROKem
uQ0N55xEPeDSvX3OMpNNbEB3IGRlSy8ZwFCIScOOW9yWsr2C4/fYg/fRzuGeWwLOq4F1AOKB
eRi1CM9x533VUzYlSXwQREQpzUJ0wNF4SW/OoK0OgIQ5xgL3GKvywvRTmAEn6feOZnz/mocT
9KdwL+QAAAAAAAA=

--------------ms070502020303090506090803--


From nobody Tue Mar 26 08:24:03 2019
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 5F66312039B; Tue, 26 Mar 2019 08:24:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <155361384027.18730.16147143635309153048@ietfa.amsl.com>
Date: Tue, 26 Mar 2019 08:24:00 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 15:24:00 -0000

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

        Title           : YANG Module Versioning Requirements
        Author          : Joe Clarke
	Filename        : draft-ietf-netmod-yang-versioning-reqs-00.txt
	Pages           : 12
	Date            : 2019-03-26

Abstract:
   This document describes the problems that can arise because of the
   YANG language module update rules, that require all updates to YANG
   module preserve strict backwards compatibility.  It also defines the
   requirements on any solution designed to solve the stated problems.
   This document does not consider possible solutions, nor endorse any
   particular solution.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-versioning-reqs-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-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 Mar 26 09:14:13 2019
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 736531204EC for ; Tue, 26 Mar 2019 09:14:11 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ojolCdwNFNiC for ; Tue, 26 Mar 2019 09:14:08 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 C1E5C12052F for ; Tue, 26 Mar 2019 09:14:07 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id l7so11653248ljg.6 for ; Tue, 26 Mar 2019 09:14:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=I1Rhpx5mjOTPR1UCqFmqDHJNE/Vesr5YybrWuPmc6GA=; b=IcCqk63/xas/lB7KX5WPdRGDKuDT5fH0ucTGCn7QLpgqCvyz7VQ4q1bQJbtX0b8QgS P8rDjH0YcHaylOh7m+EQ0Q/z5Fy9xlMXl+eceAtm8jMR0cFR0goL7akfKNDHXzpGFdQ0 pFh+gX0m1YrTLhzIyBTSCjyTTgLS3SWh9vHjNIo3P6yTZpMLY+cfwUCWfiRM05YsEyu4 +ojUZGPkufE9/GEQpafoFRD9yZ23FO0vVur7OhHxrCfUPhJlw7fjpAbHgOYpmFMwWGD7 XcPNhqb/AknRjPfp7iptJes6ZBV4Z3UVAlnLn54yQ8HeEXkcn9jD5RzRiN3S1srdvTPo OKRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=I1Rhpx5mjOTPR1UCqFmqDHJNE/Vesr5YybrWuPmc6GA=; b=jhWYjO95dq6RPTgYbKyYu2KmBwnOX30bZQXszjwxvOGUmEMs0cPGvKMtNvAIWw1pt+ a1zTc4BIN7JuKBCv6SlaxMvwSxCci42c+5BIvzj0mwItKHsusfAT+GGsdgxheu+N1/V7 r1Y8TmxcOWiA8AngNNTkjLFxfy9qBp6rYxsECEasaPexst5rNFKBDVinOsNbM9XL4wq2 KzCIxj+ZU8m3mBslZhp8QhX/DloBFPBhb/hbSIGsE2GfnQBtvoMcsG3d0bCK1Yye3f68 ClfclhViWO9PdykxShQGtLlpkD7BBQVvTGoblddLlz6kC0f9IPvgi7a+zJAkBp/qKpQG D7eQ==
X-Gm-Message-State: APjAAAXFUzX/Zm1AbIhuaDjozAx/2xUedhpIpdgDg+M7ZPbIHvEcNnRc 09K9H/hxD4qSn5Wo4cS0plnsZwxcgpteOz0oHmfa1w==
X-Google-Smtp-Source: APXvYqwoRGTnIWgao5TmJnb/OP+pq7W/ZIRzjN4FfdOmEUuFGQ+aBXeXk9PmYG20stxLG8a11ozibwJmYyUf//Kl5/M=
X-Received: by 2002:a2e:12c4:: with SMTP id 65mr17070743ljs.141.1553616845943;  Tue, 26 Mar 2019 09:14:05 -0700 (PDT)
MIME-Version: 1.0
References:  <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190326055118.nhm27b3gsivthi37@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Tue, 26 Mar 2019 09:13:54 -0700
Message-ID: 
To: Juergen Schoenwaelder , Qin Wu ,  Joe Clarke , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000003849040585019ce0"
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 16:14:11 -0000

--0000000000003849040585019ce0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 25, 2019 at 10:51 PM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Qin,
>
> the idea should be to make things simpler, not more complex. Perhaps
> it is not necessary to expose N options to reset a device. Perhaps a
> simple "factory-reset" RPC which resets all relevant datastores in an
> implementation specific manner is sufficient. Why expose more details
> to the management client?
>
>
+1

Some of us have not consumed the NMDA kool-aid ;-)
We still manage servers, not datastores.
You can reset the server so it comes back with the factory-default config.
I have never heard of resetting specific datastores to factory-default.

>From the client POV, why would I even want to know the
implementation-specific
details and have to provide reset contents for each datastore and the order
to reset them?
No customers are asking for this!

/js
>

Andy


>
> On Tue, Mar 26, 2019 at 05:25:45AM +0000, Qin Wu wrote:
> > Joe,
> >
> >
> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =
=E4=BB=A3=E8=A1=A8 Joe Clarke
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B43=E6=9C=8825=E6=97=
=A5 22:14
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org
> > =E4=B8=BB=E9=A2=98: [netmod] Question on draft-wu-netmod-factory-defaul=
t
> >
> > I support the need for being able to reset a DS to its factory default.
> > However, I have a question on the current design of the model and the
> "factory-default" DS.
> >
> > It seems to me that this is a single DS that might have been intended t=
o
> reset running or startup.  However, what if I have different DSes that ea=
ch
> have unique factory default data?
> >
> > [Qin]:We start with a simple case, you case could be addressed by
> invoking multiple rpc with each rpc to allow reset a set of datastores.
> >  If I choose to extend factory-default with a new identity of my other
> DS, how can I indicate that the target DS will be reset to _that_ DS?  Do=
es
> that make sense?
> >
> > [Qin]: In simple case, target DS will only be reset by a single factory
> datastore. If there is a new factory datastore could be derived from that
> DS, I think target DS should be changed to reset that new factory datasto=
re.
> >
> > Or if I do a  on a factory-default DS, how do I know what
> other DSes does this DS pertain?  Perhaps the server will use this to res=
et
> a given DS, but how would a user know that (other than perhaps naming of
> the factory-default DS)?
> >
> > Maybe the module needs a mapping to let the client know what DS will be
> used to reset what other DS?
> > [Qin]: So your point is should we allow multiple source, multiple targe=
t
> in the same RPC, will think it over. Thanks.
> > Joe
> >
> > _______________________________________________
> > 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         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--0000000000003849040585019ce0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 25, 2019 at 10:51 PM Juer=
gen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Qin,



the idea should be to make things simpler, not more complex. Perhaps

it is not necessary to expose N options to reset a device. Perhaps a

simple "factory-reset" RPC which resets all relevant datastores i=
n an

implementation specific manner is sufficient. Why expose more details

to the management client?



+1

Some of us=
 have not consumed the NMDA kool-aid ;-)
We still manage servers,=
 not datastores.
You can reset the server so it comes back with t=
he factory-default config.
I have never heard of resetting specif=
ic datastores to factory-default.

From the client =
POV, why would I even want to know the implementation-specific
de=
tails and have to provide reset contents for each datastore and the order t=
o reset them?
No customers are asking for this!


/js

Andy
=C2=A0



On Tue, Mar 26, 2019 at 05:25:45AM +0000, Qin Wu wrote:

> Joe,

> 

> 

> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----

> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=BB=A3=
=E8=A1=A8 Joe Clarke

> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B43=E6=9C=8825=E6=97=
=A5 22:14

> =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org

> =E4=B8=BB=E9=A2=98: [netmod] Question on draft-wu-netmod-factory-defau=
lt

> 

> I support the need for being able to reset a DS to its factory default=
.

> However, I have a question on the current design of the model and the =
"factory-default" DS.

> 

> It seems to me that this is a single DS that might have been intended =
to reset running or startup.=C2=A0 However, what if I have different DSes t=
hat each have unique factory default data? 

> 

> [Qin]:We start with a simple case, you case could be addressed by invo=
king multiple rpc with each rpc to allow reset a set of datastores.

>=C2=A0 If I choose to extend factory-default with a new identity of my =
other DS, how can I indicate that the target DS will be reset to _that_ DS?=
=C2=A0 Does that make sense?

> 

> [Qin]: In simple case, target DS will only be reset by a single factor=
y datastore. If there is a new factory datastore could be derived from that=
 DS, I think target DS should be changed to reset that new factory datastor=
e.

> 

> Or if I do a <get-data> on a factory-default DS, how do I know w=
hat other DSes does this DS pertain?=C2=A0 Perhaps the server will use this=
 to reset a given DS, but how would a user know that (other than perhaps na=
ming of the factory-default DS)?

> 

> Maybe the module needs a mapping to let the client know what DS will b=
e used to reset what other DS?

> [Qin]: So your point is should we allow multiple source, multiple targ=
et in the same RPC, will think it over. Thanks.

> Joe

> 

> _______________________________________________

> 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=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<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

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




--0000000000003849040585019ce0--


From nobody Tue Mar 26 09:52:12 2019
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 ACCB11203D6 for ; Tue, 26 Mar 2019 09:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NS1A77sZiRgN for ; Tue, 26 Mar 2019 09:52:07 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 73BA1120372 for ; Tue, 26 Mar 2019 09:52:07 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id y13so15254738wrd.3 for ; Tue, 26 Mar 2019 09:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Vri2htj21G36jpwg71pyMtTTx5+nc5sDSC334lGcZLI=; b=FDkRmyAZdNJ7OMgOAn794j940PtkMPpUbUbBTTF6z4X+xa13ZBDTfQSsdJf1F8GddQ daJFIWsKyiJHeE3fz0iVEsS726avMT2NmOLX0cqunllzyn00aVjzm5dt8YZQ0J1UACIS rAAr40o7AYInmi2R2J59l3+28ibOEw5nt2krYjnOpWtV0yK0gt+V7pL5+HvTqKOCs+lw AUoK/jaTFe6ubw8tpR8KblH1Aqc8yds1FR2CP0a7JECUCZJTaodYA1HeQp/Aw18OYAZU qcTTpA/dC/YITZl0rjdnijVbwOzKpvcclsrp2/1WhY3k8/oIccKJAtj3WXysQdrO46CS WINQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Vri2htj21G36jpwg71pyMtTTx5+nc5sDSC334lGcZLI=; b=aELPpfFY/hPITwg5jPrsSjddF0lRixQDNKu/79/nqQY9IStTsK115tGDMZ/aRB30Ta aYF/lK5+uPGJwwUuOo78+6a7mDkbyC07N5xghKNdsMYIuBdjGHtyxGIy5c5Ib8Vzvhth kZ0DmpZ5Y7srHyBQQ1PJ3JzDYf6dq6YDT0mnQ98auSW/XnnD4V+auXToF7NHQe8XWfTk bNDLAMQJCOQ2QmaYjIMOJtvYDIOIL+Xy1dlAbp3Llln4L2ELy5W9oRpka1Mp4woIWguY o7R92p0yB2QKFa4PZZXNUi0SoX5px1ujgeVVeJL73ydCfldcO5yabpK5zp7tvHLswAMh hoMg==
X-Gm-Message-State: APjAAAVr4/ZDRE0GpW/uDg42Inyj0AWgxz5VSod57Pmr+XiTOLz8GtRf nInOffKMIpgpvYus77vFjZB5VqMZjQaBXA==
X-Google-Smtp-Source: APXvYqxliu2EuPFGWQzSnETTjuXhywtiRMPoPPVzaINABczSGL8yPugfy8w4y4ovX/oIfxmEebhMfQ==
X-Received: by 2002:a5d:6883:: with SMTP id h3mr19768033wru.215.1553619125724;  Tue, 26 Mar 2019 09:52:05 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:9d0d:7f73:f57c:8a3c? ([2001:67c:1232:144:9d0d:7f73:f57c:8a3c]) by smtp.gmail.com with ESMTPSA id v16sm27328189wru.76.2019.03.26.09.52.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 09:52:04 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <856BCEF1-E396-4FFD-B7C2-7945D4191D2A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_642AFAE4-800F-4CD3-A42D-9DF5A0C5505D"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 26 Mar 2019 17:52:03 +0100
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
Cc: netmod@ietf.org
To: Kent Watsen 
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 16:52:10 -0000

--Apple-Mail=_642AFAE4-800F-4CD3-A42D-9DF5A0C5505D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Support.

> On Mar 25, 2019, at 9:30 PM, Kent Watsen  wrote:
>=20
> This email begins a 2-week adoption poll for:
>=20
>     https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00 =

>=20
> Please voice your support or objections before April 8.
>=20
> Kent (and Lou and Joel)
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_642AFAE4-800F-4CD3-A42D-9DF5A0C5505D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Support.

On Mar 25, 2019, at 9:30 PM, =
Kent Watsen <kent+ietf@watsen.net> wrote:

This =
email begins a 2-week adoption poll for:

  =
  https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00=


Please voice your support or objections before April =
8.

Kent (and Lou and Joel)

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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_642AFAE4-800F-4CD3-A42D-9DF5A0C5505D--


From nobody Tue Mar 26 14:04:31 2019
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 8420E120BAB for ; Tue, 26 Mar 2019 14:04:29 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.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 vZERhDy2qFw4 for ; Tue, 26 Mar 2019 14:04:26 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810049.outbound.protection.outlook.com [40.107.81.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A33D120BA5 for ; Tue, 26 Mar 2019 14:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ir4J5N70Wo3j0b9ORs8JmxfYCWjB5J26P/bwyqUUVrU=; b=daTsDkv9Cxkr8Onh4CXF/kOXSsQxxzUZ+B6uCru1VSBjMd6DAOHpOaZCTkaaIZAbY6B/iD5SB3dmMq3FPDDWHoJ3QcUBVxYtiQX9HdJLYA/M0W/KK9P06N02Lg5YGO/ZFXI37qnSfB1C5pGKXwmMI2c4DGEix339olwE0ZXvNEc=
Received: from MWHPR2201CA0059.namprd22.prod.outlook.com (2603:10b6:301:16::33) by MWHPR2201MB1119.namprd22.prod.outlook.com (2603:10b6:301:33::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.19; Tue, 26 Mar 2019 21:04:24 +0000
Received: from CO1NAM03FT057.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::208) by MWHPR2201CA0059.outlook.office365.com (2603:10b6:301:16::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.18 via Frontend Transport; Tue, 26 Mar 2019 21:04:24 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; bogus.com; dkim=none (message not signed) header.d=none;bogus.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.54; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.54) by CO1NAM03FT057.mail.protection.outlook.com (10.152.81.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1730.9 via Frontend Transport; Tue, 26 Mar 2019 21:04:23 +0000
From: Alex Campbell 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] Question on draft-wu-netmod-factory-default
Thread-Index: AQHU5BdzaRAHgL+6bUajrS0KOdVWNQ==
Date: Tue, 26 Mar 2019 21:04:07 +0000
Message-ID: <1553634262537.25586@Aviatnet.com>
References: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com>, <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com>
In-Reply-To: <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(396003)(39850400004)(346002)(376002)(2980300002)(189003)(199004)(36736006)(5660300002)(106002)(2906002)(6246003)(106466001)(6116002)(3846002)(356004)(6666004)(6306002)(336012)(6486002)(117636001)(97876018)(4326008)(8676002)(53416004)(86362001)(25786009)(118246002)(8746002)(110136005)(246002)(8936002)(316002)(23756003)(11346002)(229853002)(26005)(7696005)(76176011)(36756003)(966005)(53546011)(102836004)(956004)(126002)(2616005)(305945005)(47776003)(478600001)(50466002)(7636002)(476003)(7736002)(186003)(486006)(446003)(2501003)(7596002)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR2201MB1119; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3eb2c2be-b275-4882-7f2f-08d6b22e9fdb
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MWHPR2201MB1119; 
X-MS-TrafficTypeDiagnostic: MWHPR2201MB1119:
X-MS-Exchange-PUrlCount: 1
X-Microsoft-Antispam-PRVS: 
X-Forefront-PRVS: 09888BC01D
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: 8IxElRM9d6OyMkDr/pfwuuHDw0ii3J2S5yY6cJNGyr1iYwfsTXhZatDrSpjcF3FCuYy0Lh5yCBf8TXNVQaWMqy8SMRnr8wPkWbowQeHPr2KqhukFhaENLC+litXL55/aYFR4kHdbxSQXGIZcCU7ZHQobsp+DavFQKGuZYNyJPnoKwecpD9hVqguIv4gc50ZdFGmZXQlMsOSvvHG72e1UR1uundCVpC0J/LVcBOB9+8vArF4nfVmR4+6+XdG3BhToGpMxW4SAeq4HIyzbqIyCTj7vvHhjumhqKnEyhCEFCfE5lX0dnTSlsdQFqihUinR7JK+/uOTpNolT2qa2k/05uojYxEWeuqxhaZrpcXr1kaH5BDQC9XQQ2Mr7s09t4+O9TiyZ/lich5LEHyR5U1XkeCD1e1NFa6IMR13ZvUfh35o=
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2019 21:04:23.8615 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3eb2c2be-b275-4882-7f2f-08d6b22e9fdb
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.54];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR2201MB1119
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 21:04:30 -0000

As I understand it,the only purpose for the candidate and startup datastore=
s is to indirectly set the contents of the running datastore.=0A=
=0A=
Therefore it wouldn't make sense to have different factory defaults for the=
 running, startup and candidate datastores. And those are the only writable=
 ones.=0A=
=0A=
Joe, which other datastores were you thinking of?=0A=
=0A=
Alex=0A=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of joel jaeggli =0A=
Sent: Tuesday, 26 March 2019 8:18 p.m.=0A=
To: Joe Clarke; netmod@ietf.org=0A=
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default=0A=
=0A=
On 3/25/19 07:14, Joe Clarke wrote:=0A=
> I support the need for being able to reset a DS to its factory default.=
=0A=
> However, I have a question on the current design of the model and the=0A=
> "factory-default" DS.=0A=
>=0A=
> It seems to me that this is a single DS that might have been intended to=
=0A=
> reset running or startup.  However, what if I have different DSes that=0A=
> each have unique factory default data?  If I choose to extend=0A=
> factory-default with a new identity of my other DS, how can I indicate=0A=
> that the target DS will be reset to _that_ DS?  Does that make sense?=0A=
>=0A=
> Or if I do a  on a factory-default DS, how do I know what=0A=
> other DSes does this DS pertain?  Perhaps the server will use this to=0A=
> reset a given DS, but how would a user know that (other than perhaps=0A=
> naming of the factory-default DS)?=0A=
>=0A=
> Maybe the module needs a mapping to let the client know what DS will be=
=0A=
> used to reset what other DS?=0A=
=0A=
the germ of the idea is sensible enough. reset a DS to it's factory state.=
=0A=
=0A=
When it meets reality of course is that there seem to be a bunch of=0A=
variants that seem like pretty compelling use cases.=0A=
=0A=
reset the whole device being one of them.=0A=
=0A=
the specification of a factory-default datastore and then=0A=
=0A=
   o  startup configuration datastore=0A=
=0A=
   o  candiate configuration datastore=0A=
=0A=
   o  running configuration datastore=0A=
=0A=
actually sound a bit implementation specific though I recognize that=0A=
most network operating systems due tend to follow models that at least=0A=
superficially resembled that.=0A=
=0A=
I'm generally sympathetic to the application the draft proposes.=0A=
=0A=
>=0A=
> Joe=0A=
>=0A=
> _______________________________________________=0A=
> netmod mailing list=0A=
> netmod@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/netmod=0A=
>=0A=
=0A=
=0A=


From nobody Tue Mar 26 14:15:39 2019
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 711C912006D for ; Tue, 26 Mar 2019 14:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZAbEfQ7YmoXd for ; Tue, 26 Mar 2019 14:15:35 -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 3995D120020 for ; Tue, 26 Mar 2019 14:15:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2985; q=dns/txt; s=iport; t=1553634935; x=1554844535; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hwjgObpmo7Mc3Unbu6Ahb+XF6+rBY+hEXAfx+tVX3is=; b=d872d6pfNsD+SQyH/Gp4kO2YplEqKkML5MhOgPtsBkmkquzNs/1E5IzR 5CO32k+k0cO8w2Aovwe39xB16l3v8aJthU7H6RC9h5aTQ3HxdHYv6Dobu 2xfoe6bOkf9aEEczhSYiuNjXKP6pocSccqoJ4JUjLUcKihUwFGZst3e4e U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAACSlZpc/4ENJK1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCEWgDTTMnhA6TQ4FgLZhPgWcPGAuEA0YChSIiOBI?= =?us-ascii?q?BAQMBAQkBAwJtHAyFSgEBAQMBAQEhSwsQCxEEAQEBAgImAgInKAgGAQwGAgE?= =?us-ascii?q?Bgx4BgW0ID6xLgS+KLAWBCySLMheBQD+BOII2NT6CYQEBgTcTAYMgglcDim2?= =?us-ascii?q?HDpMeCZM1BhmLJYhdix2TWoFkIYFWTSMVO4JsiwyFWyMDMJBCAQE?=
X-IronPort-AV: E=Sophos;i="5.60,274,1549929600"; d="scan'208";a="538029819"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 21:15:28 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTP id x2QLFRS8023188; Tue, 26 Mar 2019 21:15:28 GMT
To: Alex Campbell , "netmod@ietf.org" 
References: <94605356-c2a1-d00b-cffd-e7df94739a62@cisco.com> <665b7eef-54d1-6bd4-16bb-a66b820f5ebe@bogus.com> <1553634262537.25586@Aviatnet.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQINBFx0f7kBEACpXvK/9vZPCzcdpjMCFxTYDJSbYGPBj4jAct6j26evawhP4nQFuk8a/N0T u/l5KhN8nj0F+4wYLBBm/Vq6OYnXcuu/Qnaa5SeN6A8xp0KGFvY81x2BzPMqoM1XLnBAgcHU BlO+OikGlQSouJYagtw1qhlJpmtjwdcJ91Sun5N0SLd8iJVTU2ndCBdlj4PFuDBae9urft7D lkL3sDeAimsnPp8SJF8L2wdMWBXuht666lla+xYzwQ76+ibEmH+zr9Xy3JWySCcS75pbIikj eV/LF/YdyVPr6YGPXawO+srQGiiaqAcUY4oeWYEuFZuG0zGiCDNl106Sc4GVPOTOragqFMZv 1DoFvdaHvmBz3dbKQJ7L+W/paaBxk9F7uu73g9pPWgdio/Bh63iDlEfOm360qIQI3cbisSPF yR9RLnQTUWsy3aolG3NmxSJ+YPDwunNS9soPvPwZixbL6XUy05sUyu6d4lFKMtfo135VJ8N0 SgxNlBn/MZwFsuj66nLq015rz+bud5kz1EIK428q9+Kn4t92uq61oa/9un42qm9Xp/mm4j0J LUdNXXp987F1lZdZltcqkoYlY66OWmUr+YcVB+JAGPCA+C0T7CDjXgxkeyA3/9y7/jtVEDSx UWzCzLhzU/78QqC3NtMyUVRG7feRF0NWRzcc+d4ZEsojicmdEwARAQABtCtKb2UgQ2xhcmtl IChqY2xhcmtlKSAoKSA8amNsYXJrZUBjaXNjby5jb20+iQJOBBMBCAA4FiEE40r9XruLwkD8 nwY9s2u9ges9Y6oFAlx0f7kCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQs2u9ges9 Y6oT1Q//Vjy5ZVYA2Hy6eDz0jrmdkwQZklLU/MXvRgI8WWj6wGs2JKugdKSkkfwvDbD7Rg7b nqkMaZDcLK5eh/492CcwXwvcJKo/9bH1gUPYcDbu5INahiEagkgOS9GOjuHQs4cVr1JNiExf UZ/UcF0R+agP9jfqlJ7eiUN74w1cddZUfhfM0U0cLJ5TJtTjqnqsOCefNiWBLdSn+9RX8c6y cW77N4TVO6Vtv03SvLs5KniLmb6r7qwg6gkU2Vw6TDCk9UdJWSsKHEiOBmq1aGGmZHfBq9iZ GxwCaEqUBdN438JYN8RJMB2qv7EzTsv+KVz2E96jUBzeWdTFqu2xPikg4mwwUmJ1SAqc6AGI JZ8ICNr50xONoPpfdR+1QQzImnua8TuV28pracEDKex8r/ieDZQh8UyVM3mdGL7RSVa4/+EO iKCVmFfHLdnbuwhJLUhsHOlfeYSmRzmHUwS9K1sERMPUJCImMJUOAynQEoeTuLc6dDWq0oTP 6kJ3my7eMcg5MsFsGob8qtUDujiGof7LKZYHOqwYjCzrK4s4vwyX1Yh228sLRiEuNbCpvlD1 U/iKBv/VL5FMbI1kd0FPXvY+ygW+aobZYUOYXOvvdTeq9phCL2aHa5hHG7QNhSF6NsCuZhg6 mnOFOdAF7imXVmLa6cYEYqV17SGgceDKotNea2AxL965Ag0EXHR/uQEQAOIdXbR7GqhQdITX a+tCgi9r8p0o5e2Q2Rq22YIMR6FiyeWFTO2RQpW2NZW4yDfpGZnvBdFTWB62MWxu5Z7FwA09 ZON0l7c4IK7TFJ7Vx9azx1Ebx7r1p5hcARSmvU4CmlJZGPR0m9b+p9rPx27B5vCIWITQbWB/ PPgbksEdxXYYHCVJCWHk6LxL5iZJFVjoQGvHX/3PtzxByHtnVWQ937PZRCHaSAgERr6qVNWd XaO9ZlHm8l2yqMxKk+LUxOtj0FYY/vVdVwFFaGGkhXzhr4f6FJ7+j6Q+aOBbCvO2z/xfw/mh Tlg8W3cQYFwQcaW//FzdTprIRD8AiBRuEH5daLHZAhqj1M1srMv1SRyE7wu/e233ngUZ7UbZ J52bE2RsmA4sUVQVPB57/mn1U9xXW1pyus0n45sQi0GRsFl8fHujeQeAVPWIZl9AL8FiNlLZ +VDvMV0V24vChwRo7OVgohJNkc9NkIb7zYsv8Hqo2OinXWmQmMsluQzU9nSkGdC2eSgOPzVF fzY1KEcifF5O7A5PH2DPNsC1hPer+4vVZbMEQwW5mBIl04IvuCA3S3j+Vvfj3yyPuhf5ExjM 0YtaP5x0S4pqXVKNhzrHX/YtV13c3BP6Zx56MW2t5KnmV0MF97h2vejh/DHPSymz5blUv2Mr 0kknFYhJ+tp/rqP7B8+HABEBAAGJAjYEGAEIACAWIQTjSv1eu4vCQPyfBj2za72B6z1jqgUC XHR/uQIbDAAKCRCza72B6z1jqpFIEACKHqK4wdmimwJU+uq3HJcDBP12vnISDxkrcq19xWCv 01EWp1DR4izRLJXFIke7jlGk1GWfHKkjpUmkXOdujxYZvrVUXD9BwnNDWfDlZaPgpQNoMIlH Pcnq+MovlsuHiLnA29RRxUfRRn49fnpB4MQhB9tzsHGcghApFxB0h/CLs8ZWLTP6EDyDSNem ynEeJ8YjsbyBDqmAHs/+PS14FS7R6jHW8XNonzu5qKVvwkfA5EAI17CLJWTLkFwa3y7vOL6v x6qsoGNPvN4kolAGhz8cm2zqyZ/ts3paYnjZnBWnziYATv3hZzijcLKlLKBJaP7dUlkdNePN yzLkeN+oCVcz1DTGBhfIzlp+Dk3ySFoV2bYyEqiFmttpaDcBbPoB1LKvVZE/C1/f0Z9Tc0Fi VYQ2R60npDISUCanFF0JsN14PGoJdaV90Ouitr8GBzUJpKXFYi93L4M8gHCnSGWmjqAFGNj9 374pUwI8wbBAK5GI1hmjQZLA1UFM/SJ9J86gBzPUPNFR1xTSU+GTEufGHtcQ7wL42X+xz/lv 2pzhluScPl2WWXnwMSiE1a8AaVIhJvsrHuBxNH2l0RHuknWvJOjKtn6wdvPnEURJMH5dQ0jl QFqXPmJVYpL5AvqTYKXtS0Jy1z9oQN6ZUngZoaIYLDogKSQ9DOYd8WvdmOE24auWtA==
Organization: Cisco
Message-ID: 
Date: Tue, 26 Mar 2019 17:15:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <1553634262537.25586@Aviatnet.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: 
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Mar 2019 21:15:38 -0000

On 3/26/19 17:04, Alex Campbell wrote:
> As I understand it,the only purpose for the candidate and startup datastores is to indirectly set the contents of the running datastore.
> 
> Therefore it wouldn't make sense to have different factory defaults for the running, startup and candidate datastores. And those are the only writable ones.
> 
> Joe, which other datastores were you thinking of?

Again, this is likely vendor-dependent.  I was thinking of additional
system datastores that would also need to be reset to default for a full
device reset.  This is why I like the "reset-device" RPC, which would
take care of any such DS.

As a concrete example, Cisco switches have a vlan.dat file that is not
part of  or  that would need to be reset to factory to
fully reset the device.

Joe

> 
> Alex
> 
> 
> ________________________________________
> From: netmod  on behalf of joel jaeggli 
> Sent: Tuesday, 26 March 2019 8:18 p.m.
> To: Joe Clarke; netmod@ietf.org
> Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
> 
> On 3/25/19 07:14, Joe Clarke wrote:
>> I support the need for being able to reset a DS to its factory default.
>> However, I have a question on the current design of the model and the
>> "factory-default" DS.
>>
>> It seems to me that this is a single DS that might have been intended to
>> reset running or startup.  However, what if I have different DSes that
>> each have unique factory default data?  If I choose to extend
>> factory-default with a new identity of my other DS, how can I indicate
>> that the target DS will be reset to _that_ DS?  Does that make sense?
>>
>> Or if I do a  on a factory-default DS, how do I know what
>> other DSes does this DS pertain?  Perhaps the server will use this to
>> reset a given DS, but how would a user know that (other than perhaps
>> naming of the factory-default DS)?
>>
>> Maybe the module needs a mapping to let the client know what DS will be
>> used to reset what other DS?
> 
> the germ of the idea is sensible enough. reset a DS to it's factory state.
> 
> When it meets reality of course is that there seem to be a bunch of
> variants that seem like pretty compelling use cases.
> 
> reset the whole device being one of them.
> 
> the specification of a factory-default datastore and then
> 
>    o  startup configuration datastore
> 
>    o  candiate configuration datastore
> 
>    o  running configuration datastore
> 
> actually sound a bit implementation specific though I recognize that
> most network operating systems due tend to follow models that at least
> superficially resembled that.
> 
> I'm generally sympathetic to the application the draft proposes.
> 
>>
>> Joe
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> 
> 


From nobody Tue Mar 26 22:37:26 2019
Return-Path: <01000169bda7252b-5dfcab34-d1fc-4377-a405-8c9f09d24161-000000@amazonses.watsen.net>
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 F107E120186 for ; Tue, 26 Mar 2019 22:37: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 22Yi_fAJNhGg for ; Tue, 26 Mar 2019 22:37:23 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2052A120247 for ; Tue, 26 Mar 2019 22:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553665041; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Date:Subject:Message-Id:References:In-Reply-To:To:Feedback-ID; bh=f9pZVv1FBMFD8jhSQbSavgWbTIx8roCO+tBPgQprajk=; b=lqrOhTqj3PB8ql8c1LjjvSPeqVEqlQJuaXjg1VwQkwbKbDhEp689bNZhhuO4jf1Q 6gNFYFgmf0A5waWeLPMbajqOETkU76vaV9a4DNuaFzo9nLIjDx9/hH0ot9dBIy1pSVJ g2FgsVWSORLFNTjMQ22FccjQUEyrvU5bs4c6g4kw=
From: Kent Watsen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Wed, 27 Mar 2019 05:37:21 +0000
Message-ID: <01000169bda7252b-5dfcab34-d1fc-4377-a405-8c9f09d24161-000000@email.amazonses.com>
References: <010001695994a2b4-cf449680-5a3e-4500-83d6-8268450726f3-000000@email.amazonses.com>
In-Reply-To: <010001695994a2b4-cf449680-5a3e-4500-83d6-8268450726f3-000000@email.amazonses.com>
To: netmod@ietf.org
X-Mailer: iPhone Mail (16D57)
X-SES-Outgoing: 2019.03.27-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] =?utf-8?q?Today=E2=80=99s_YANG-Next_Discussion?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 05:37:25 -0000

Reminder: today there is a 2-hour deep-dive meeting on YANG Next  in Karlin 3=
 from 15:00-17:00.=20

Kent



From nobody Wed Mar 27 00:21:36 2019
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 A846A120256 for ; Wed, 27 Mar 2019 00:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PEoujEQIsuRk for ; Wed, 27 Mar 2019 00:21:30 -0700 (PDT)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 CFBD5120266 for ; Wed, 27 Mar 2019 00:21:29 -0700 (PDT)
Received: by mail-it1-x12d.google.com with SMTP id y63so12835708itb.5 for ; Wed, 27 Mar 2019 00:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dBs+lkf3ElPQqaUWQhQh4M4ojbTFdnyBAWOWHfdKP7A=; b=coPjdf5OBxLPSoQFN+LhcKrLTaVUIARgmMHqQ+TRTbCS/qXaB+XBu+grQiO82I6iXY gBUASNiBivy6MNuKKOCFE1lCK+spBW/GCL36wiugNXONM36k3d0E57/5e7v4/Go8BrAH 1XSpCsIWWZmr02HI9k+Kuqitv1ArjKCLHxHULZJXXF/hI1RnmL5EDVvToYi8/CI+HZ0A J2Ec6lN1R0ybfmLUzwuOtVRQgjitTjFtGfxwi4maCOOYgdfP4qrpTrOHd/MeFWGkJ9sf Zb0rWNMYE8f81BTFvpGwcB/xmVCwdZ+uZ6SUZnKPDmPpYLh9Fr2t8iBz7ABRGzH+0tFw Bpog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dBs+lkf3ElPQqaUWQhQh4M4ojbTFdnyBAWOWHfdKP7A=; b=i4nWBvkP8bg64rQ/r8Bof39TMI0QdGBX5qf+lB90bWafMp/WyG1r2VQOfR+SkbCkAs XjSW9XJmCygoDQYMYaN7DaBRkJS4v4kU9WvqlxmHb7XcbPcxf0WYKneOhtraCmZ9hnlB XnKZS1Tvv6OCf8InUs3rQO0ZvBfDImgcdMLQ+a/cuUeUVaogIsY3/hhGV/lElZ6NoGSe CQ3HEhSVrbKIiQLMfnAyWKon22LDIRahdLV+AMC4DAbCVIlRHfKFA0letEOTsU4J4TMo 7AwR681amVYZRWqzRvE930rs0MpEGgKWzQ76DyDo64lpHlXUYM1RqRqqFtP5xo5Pw7iy jurg==
X-Gm-Message-State: APjAAAVzyfCpz3WjrLJrRbGNzO5g/LTFwqCEInxIbZVqMz4NNLfbolB4 izrQ3IYEJNYauzzc0+pM6O9aIkgN+z8r3Gh/P1943WB6zZkxGA==
X-Google-Smtp-Source: APXvYqxiaGjepcMee1x295vp/xZYN1BusbrnUPYBl27BkaDbPhSpMa8hBNofTKDuisZM4utgWBgYO7LHtF3f/N0pl1s=
X-Received: by 2002:a24:f30d:: with SMTP id t13mr2389568ith.90.1553671287998;  Wed, 27 Mar 2019 00:21:27 -0700 (PDT)
MIME-Version: 1.0
References: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
In-Reply-To: <01000169b68beedf-0354c428-3a7c-4453-8a2f-7f2ae6c6b10d-000000@email.amazonses.com>
From: Xufeng Liu 
Date: Wed, 27 Mar 2019 03:21:16 -0400
Message-ID: 
To: Kent Watsen 
Cc: NETMOD WG 
Content-Type: multipart/alternative; boundary="0000000000003815bb05850e490f"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 07:21:34 -0000

--0000000000003815bb05850e490f
Content-Type: text/plain; charset="UTF-8"

Support.
- Xufneg

On Mon, Mar 25, 2019 at 4:30 PM Kent Watsen  wrote:

> This email begins a 2-week adoption poll for:
>
>     https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00
>
> Please voice your support or objections before April 8.
>
> Kent (and Lou and Joel)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--0000000000003815bb05850e490f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Support.
- Xufneg




=
On Mon, Mar 25, 2019 at 4:30 PM Kent Watsen <kent+ietf@watsen.net> wrote:
This email begins a 2-week =
adoption poll for:


Please voice your support or objecti=
ons before April 8.

Kent (and Lou and Joel)

_______________________________________________

netmod mailing list

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




--0000000000003815bb05850e490f--


From nobody Wed Mar 27 00:24:00 2019
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 C1BED120256 for ; Wed, 27 Mar 2019 00:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gOCLRVir-1V0 for ; Wed, 27 Mar 2019 00:23:56 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 815F1120253 for ; Wed, 27 Mar 2019 00:23:56 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id f22so315350ita.3 for ; Wed, 27 Mar 2019 00:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jjTAfhamLTEePhsreF4+6AuM1IuEYyjUECuJhEyNAUM=; b=ki0e/v5o/bnXqhy0flV+qkw5FQbe/zT25lTdy8jaOIe/iytFO4b76goovotp4rcxIj /47+OStG6SOt8y33BqtXWwFvBAD1TUimhyofNAKequLsO/7xooHtTytvwZXfmlNL39Lv pgqwlIOdak0AWzN1qJT7xrwatrCnnX1NBk9CVIJr3Oo+0WOFG17CN7Cc0nRSvQ7krfDS FA0cVY9JeNz0ku6JT5aB//Nl+NH7NTTARi1jy3yZYXl164RqCjyXl8WUYnOEWmUGQhHE /iIOZjDSoqZul37gXVbZQEbS5yKH1dcdiYmJvmCtwHt3SYB/epac3YM+fyNgAZa4u/cd pLbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jjTAfhamLTEePhsreF4+6AuM1IuEYyjUECuJhEyNAUM=; b=TVl6kbbWHuHtb0VZV7Wcw6q5JWaS88ZyjPie2tdcuXqaZdcNKKQ7ijvAP0BWcgKgPE 3KwVpiG9O3wXOBHpIiz05cXiRCk09qkRvSUVVtuU70Zr9ViZeBgWcIp5EwPjFK2UvceR T4/7SgaxiPktV84YYGux71xVscts6SbaKiqWQFAnahV3wZK9fM9d/Z0cTxG+5oJIGYT8 g2ZTZA668NE5uBprH/CTIruNGt7NmCO65vGBb/F/JdViXVvk2Hd49uSeevl+Z/SZ/Sp7 dVqAte2ie7kdiNbOxrah97D7qJejzLfkSNiPVwgr/npaw8fvBy8VojIg4ibEuzm1avGN zb8g==
X-Gm-Message-State: APjAAAXmdyeo5TAN5IBdpeNAek6CXxXARqY2Io4u+MLfx20UWp42nC0P MpfBHUUFrWzqjOwk3eRuJYl01Zk9INCkeG2iEeuffqIjoZUvlg==
X-Google-Smtp-Source: APXvYqyd+M+bGY7oj0hHp+OiqHyfDnB9T6HHABmXRA0S13dz8KcEb03XAKnYhu4+7GeWtksNvu83P8rBQnAXUz1oHRY=
X-Received: by 2002:a24:50d5:: with SMTP id m204mr2495667itb.103.1553671435785;  Wed, 27 Mar 2019 00:23:55 -0700 (PDT)
MIME-Version: 1.0
References: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
In-Reply-To: <01000169b68dd0fc-3453e82e-5dbe-4022-82ad-6031daaedd5b-000000@email.amazonses.com>
From: Xufeng Liu 
Date: Wed, 27 Mar 2019 03:23:44 -0400
Message-ID: 
To: Kent Watsen 
Cc: NETMOD WG 
Content-Type: multipart/alternative; boundary="000000000000071aae05850e528b"
Archived-At: 
Subject: Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Mar 2019 07:23:59 -0000

--000000000000071aae05850e528b
Content-Type: text/plain; charset="UTF-8"

 Support.
- Xufeng

On Mon, Mar 25, 2019 at 4:32 PM Kent Watsen  wrote:

> This email begins a 2-week adoption poll for:
>
>     https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
>
> Please voice your support or objections before April 8.
>
> Kent // as co-chair
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--000000000000071aae05850e528b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




Support.
- Xufeng



=
On Mon, Mar 25, 2019 at 4:32 PM Kent Watsen <kent+ietf@watsen.net> wrote:
This email begins a 2-week =
adoption poll for:


Please voice your support or objecti=
ons before April 8.

Kent // as co-chair


<=
/div>_______________________________________________

netmod mailing list

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




--000000000000071aae05850e528b--


From nobody Thu Mar 28 01:44:03 2019
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 AE258120074 for ; Thu, 28 Mar 2019 01:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 IYYMgRZ0j37Z for ; Thu, 28 Mar 2019 01:43:51 -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 26F2B12026D for ; Thu, 28 Mar 2019 01:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27005; q=dns/txt; s=iport; t=1553762631; x=1554972231; h=from:to:subject:date:message-id:mime-version; bh=frANjkmGOm+oL2gRs1IbTnCArtZDItHZ2oFScnUOmy8=; b=Gz1UdeMuGMiJ538OHJFY3vmL9whHfdbfXSKrKu/uQDt8Fj8ASoIQp/0T T2BTB4AWMLQgB/ijnZHEcazknRd+/2oMElox2qJ9zqGLbH1c7ODcQlcJ9 TZb7d/OFQgesayAuUDiPs/skubOnNQbqYrqKHdtyXqUgZXd7g3CUJSRuQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAADoiJxc/4kNJK1JGhwBAQEEAQE?= =?us-ascii?q?HBAEBgVEHAQELAYEOgQJogQMnCowgiyKDC5c+FIFnDQEBJYl4IjQJDQEBAwE?= =?us-ascii?q?BCQEDAm0cAQuFfkUZATgIBDwmAQQbE4MIgRFkDzWqSoNChmwFgS8BizEXgUA?= =?us-ascii?q?/gRGBfWAHg00EGIEgD2eFEgOKcAIDhiYek3IJAodqi1MilAyLLIYJjTECERW?= =?us-ascii?q?BLh84gVZwFTuCbYIVF4NLilNBMQEJjR4kgQqBHwEB?=
X-IronPort-AV: E=Sophos;i="5.60,280,1549929600";  d="scan'208,217";a="251983024"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 08:43:49 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2S8hnVn018305 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Mar 2019 08:43:49 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 03:43:48 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 28 Mar 2019 03:43:48 -0500
From: "Rob Wilton (rwilton)" 
To: "netmod@ietf.org" 
Thread-Topic: Meeting Notes from open YANG versioning Design Team meeting
Thread-Index: AdTkoRj6svo9SZKZQ5Ggg56oL5hxCA==
Date: Thu, 28 Mar 2019 08:43:48 +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.61.79.96]
Content-Type: multipart/alternative; boundary="_000_c22dd347c9ac42d68f74177c36bdea27XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: 
Subject: [netmod] Meeting Notes from open YANG versioning Design Team meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Mar 2019 08:44:01 -0000

--_000_c22dd347c9ac42d68f74177c36bdea27XCHRCD007ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

These are the meeting notes that I captured from the open YANG versioning d=
esign team meeting yesterday.

Attendees: Juergen, Joe, Rob, Martin, Balazs, Kent, Reshad, Qin, Michael, J=
ason, Mahesh

Recording:

https://cisco.webex.com/cisco/lsr.php?RCID=3Dc4d757b2c15e4f3cb20eff11a15520=
3c



Password: iPpxJQA4


1) The first half of the meeting was based on discussing the requirements:

In summary, my interpretation is that there is consensus on the underlying =
spirit or the requirements, although in some cases the requirements text ne=
eds further polishing, and there was not complete consensus on all parts of=
 all requirements.


-        The requirements discussion was only focussed on the requirements =
section 5 of draft-verdt-netmod-yang-versioning-reqs-02, we didn't discuss =
the background text.


-        The assumption as to whether this document should take the full pa=
th to publication has been deferred, but with the understanding that more d=
iscussion would be required on the background text to reach consensus.  The=
re was a desire to reach agreement on the list of requirements itself.



-        These was agreement that IETF models should be limited to a linear=
 revision history, with changes only in the most recent revision.  It was a=
greed that in some cases it is necessary to make NBC changes (in a new most=
 recent revision) in IETF YANG modules to fix bugs.



-        There was discussion that an applicability statement could be adde=
d, or some of the requirements could be split between SDO vs Vendor require=
ments, but there did not seem to be strong consensus either for or against =
this change.  In anything, there seemed to be a slight preference to trying=
 not to make this split.



-        It was agreed that YANG should have a single versioning scheme tha=
t is capable of covering both SDO requirements and vendor requirements.  Th=
ere was agreement that guidelines text could be used to provide guidance on=
 how IETF models should be versioned.



-        It was agreed that it would be better to change the requirement te=
xt so that instead of saying "NBC changes are allowed" the text to be more =
along that the requirement is to have a way "to communicate when NBC change=
s have occurred".  I.e. the key is how NBC changes are documented, rather t=
han saying whether or not they are allowed/encouraged/etc.



-        We also discussed and agreed that it is better not to refer to "bu=
g fixes" because we don't want to have to try and define what a bug fix is.=
  Instead, we agreed that requirement 1.4 should be stated something along =
the lines of:  "The solution MUST be able to describe backwards-compatible =
changes, as well as non-backwards-compatible changes in non-latest-release =
modules."



-        We discussed the import requirement (1.3), and there was strong co=
nsensus that there is a need to import version "X or later" (e.g. to fufill=
 a leafref/augmentation/etc dependency).  There was no consensus on the sec=
ond sentence ("Once non-backwards-compatible changes to modules are allowed=
, the refined import statement is used to express the correct dependency be=
tween modules"); specifically, whether there needs to be an "upper bound" o=
n what version can be imported.



-        There was no consensus on whether "linear module development of YA=
NG models is ideal" is correct.  In particular, it was noted that what migh=
t be ideal for clients may not be ideal for vendors.



2) Discussion on solutions:

No consensus was reached on a direction for the solution.

Most of the time was spent discussing a scheme suggested by Kent of keeping=
 a ledger in the top of the YANG file that documents its history.  My inter=
pretation is that this is very similar as the existing revision history in =
a YANG module, but with the following points:

-        Revisions are identified by a revision-date (as they are today), b=
ut the revision-date only identifies uniqueness, and the most recent versio=
n of a particular YANG module file.  E.g. it represents the head tip of a b=
ranch (or DAG leaf node), rather than the head tip of only a single linear =
history (as it does today).

-        For each revision, addition metadata is added to indicate whether =
the change is bc or nbc.

-        Extra metadata could be added (in the form of xpaths) to document =
which parts of the schema have changed (if a tree was added/removed then it=
 would only reference the tree, not every element in it).

-        A "version tag" could be added to label a particular revision in a=
 more human readable way.

-        YANG files would be identified by their revision-date, but the tag=
 could also be optionally included in the filename.

-        Importing revision "X or later" would not mean any revision with a=
 later date, but any revision that is contained in the history (i.e. ledger=
) of the file that is being imported.

-        The revision for an import could also be identified by the tag nam=
e.

-        This scheme allows for unlimited "branching" (since each new revis=
ion only has to point to the revision that it is derived from).

-        Possibly semver or similar annotations could still be done using t=
he version tags.

-        There were concerns expressed about how easily clients will be abl=
e to relate to YANG modules that are only identified by revision date, but =
the tag may mitigate this problem.

-        We discussed the biggest benefit of this solution being that it al=
lows arbitrary unlimited branching at any point, rather than being arbitrar=
ily constrained.  The biggest downside to the solution is perhaps additiona=
l complexity for users managing multiple versions, i.e. it is less intuitiv=
e as to the relationship between revisions.

We ran out of time at 6.30 and no clear next steps were identified in the m=
eeting.  The expectation is that this solution should be investigated furth=
er, either by the design team, or as a separate individual draft.  It would=
 be good to try and reach agreement on the next steps so that the WG/DT can=
 continue to make progress in this area.

Thanks,
Rob


--_000_c22dd347c9ac42d68f74177c36bdea27XCHRCD007ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


These are the meeting notes that I captured from the=
 open YANG versioning design team meeting yesterday.


 


Attendees: Juergen, Joe, Rob, Martin, Balazs, Kent, =
Reshad, Qin, Michael, Jason, Mahesh


 


Recording:


https://cisco.webex.com/cisco/lsr.=
php?RCID=3Dc4d757b2c15e4f3cb20eff11a155203c


 


Password: iPpxJQA4


 


 


1) The first half of the meeting was based on discus=
sing the requirements:


 


In summary, my interpretation is that there is conse=
nsus on the underlying spirit or the requirements, although in some cases t=
he requirements text needs further polishing, and there was not complete co=
nsensus on all parts of all requirements.


 


-     &=
nbsp; 
The requirements discussion was only focussed on th=
e requirements section 5 of draft-verdt-netmod-yang-versioning-reqs-02, we =
didn’t discuss the background text.


 


-     &=
nbsp; 
The assumption as to whether this document should t=
ake the full path to publication has been deferred, but with the understand=
ing that more discussion would be required on the background text to reach =
consensus.  There was a desire to
 reach agreement on the list of requirements itself.


 


-     &=
nbsp; 
These was agreement that IETF models should be limi=
ted to a linear revision history, with changes only in the most recent revi=
sion.  It was agreed that in some cases it is necessary to make NBC ch=
anges (in a new most recent revision)
 in IETF YANG modules to fix bugs.


 


-     &=
nbsp; 
There was discussion that an applicability statemen=
t could be added, or some of the requirements could be split between SDO vs=
 Vendor requirements, but there did not seem to be strong consensus either =
for or against this change.  In
 anything, there seemed to be a slight preference to trying not to make thi=
s split.


 


-     &=
nbsp; 
It was agreed that YANG should have a single versio=
ning scheme that is capable of covering both SDO requirements and vendor re=
quirements.  There was agreement that guidelines text could be used to=
 provide guidance on how IETF models
 should be versioned.


 


-     &=
nbsp; 
It was agreed that it would be better to change the=
 requirement text so that instead of saying “NBC changes are allowed&=
#8221; the text to be more along that the requirement is to have a way R=
20;to communicate when NBC changes have occurred”. 
 I.e. the key is how NBC changes are documented, rather than saying whether=
 or not they are allowed/encouraged/etc.


 



-       =
;
We also discussed and agreed that it is better not =
to refer to “bug fixes” because we don’t want to have to =
try and define what a bug fix is.  Instead, we agreed that requirement=
 1.4 should be stated something along the lines of:  “The
 solution MUST be able to describe backwards-compatible changes, as well as=
 non-backwards-compatible changes in non-latest-release modules.”


 


-     &=
nbsp; 
We discussed the import requirement (1.3), and ther=
e was strong consensus that there is a need to import version “X or l=
ater” (e.g. to fufill a leafref/augmentation/etc dependency).  T=
here was no consensus on the second sentence (“Once
 non-backwards-compatible changes to modules are allowed, the refined impor=
t statement is used to express the correct dependency between modules”=
;); specifically, whether there needs to be an “upper bound” on=
 what version can be imported.


 


-     &=
nbsp; 
There was no consensus on whether “linear mod=
ule development of YANG models is ideal” is correct.  In particu=
lar, it was noted that what might be ideal for clients may not be ideal for=
 vendors.



 


 


2) Discussion on solutions:


 


No consensus was reached on a direction for the solu=
tion.


 


Most of the time was spent discussing a scheme sugge=
sted by Kent of keeping a ledger in the top of the YANG file that documents=
 its history.  My interpretation is that this is very similar as the e=
xisting revision history in a YANG module,
 but with the following points:


-     &=
nbsp; 
Revisions are identified by a revision-date (as the=
y are today), but the revision-date only identifies uniqueness, and the mos=
t recent version of a particular YANG module file.  E.g. it represents=
 the head tip of a branch (or DAG leaf
 node), rather than the head tip of only a single linear history (as it doe=
s today).


-     &=
nbsp; 
For each revision, addition metadata is added to in=
dicate whether the change is bc or nbc.


-     &=
nbsp; 
Extra metadata could be added (in the form of xpath=
s) to document which parts of the schema have changed (if a tree was added/=
removed then it would only reference the tree, not every element in it).


-     &=
nbsp; 
A “version tag” could be added to label=
 a particular revision in a more human readable way.


-     &=
nbsp; 
YANG files would be identified by their revision-da=
te, but the tag could also be optionally included in the filename.


-     &=
nbsp; 
Importing revision “X or later” would n=
ot mean any revision with a later date, but any revision that is contained =
in the history (i.e. ledger) of the file that is being imported.=



-     &=
nbsp; 
The revision for an import could also be identified=
 by the tag name.


-     &=
nbsp; 
This scheme allows for unlimited “branching&#=
8221; (since each new revision only has to point to the revision that it is=
 derived from).


-     &=
nbsp; 
Possibly semver or similar annotations could still =
be done using the version tags.


-     &=
nbsp; 
There were concerns expressed about how easily clie=
nts will be able to relate to YANG modules that are only identified by revi=
sion date, but the tag may mitigate this problem.


-     &=
nbsp; 
We discussed the biggest benefit of this solution b=
eing that it allows arbitrary unlimited branching at any point, rather than=
 being arbitrarily constrained.  The biggest downside to the solution =
is perhaps additional complexity for
 users managing multiple versions, i.e. it is less intuitive as to the rela=
tionship between revisions.


 


We ran out of time at 6.30 and no clear next steps w=
ere identified in the meeting.  The expectation is that this solution =
should be investigated further, either by the design team, or as a separate=
 individual draft.  It would be good to
 try and reach agreement on the next steps so that the WG/DT can continue t=
o make progress in this area.


 


Thanks,


Rob


 






--_000_c22dd347c9ac42d68f74177c36bdea27XCHRCD007ciscocom_--


From nobody Fri Mar 29 03:20:20 2019
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 1082E1202ED for ; Fri, 29 Mar 2019 03:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 MseqFM6KpCM6 for ; Fri, 29 Mar 2019 03:20:16 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 B1A7512025E for ; Fri, 29 Mar 2019 03:20:16 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id A892363080 for ; Fri, 29 Mar 2019 11:20:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553854814; bh=M6YyNS1Idccn2AQ/IrJA8eowPGduU4kQAoacBpOrHJ0=; h=From:To:Date; b=vS9T5ojmt7jKMFh/72uol49JyGmG4Y75dOKE0bQ5I+LnA/x5ORECXIyIwBmB3B8Vx Q7vZuK/QkfiQ16WOz04tYu3zqKPECnPXQ0mNRBMikROxZkQqQYqub6bQ1sfho8/Bv8 +cb8ZF0J3w/Gz9uhPbAnMxuGfzm7/8P6eydJED+0=
Message-ID: 
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Fri, 29 Mar 2019 11:20:13 +0100
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] 6991bis: domain-name
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 10:20:19 -0000

Hi,

as a follow-up to my comment during the NETMOD session, I want to propose the
following update to the the inet:domain-name type. The aim is to include use
cases that are currently rejected:

- classless in-addr.arpa delegations [RFC 2317], i.e. labels like "128/26"

- wildcards [RFC 4592], e.g. "*.example.net"

OLD

    pattern
      '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
    + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
    + '|\.';

NEW

    pattern
      '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
    + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
    + '|\.';

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





From nobody Fri Mar 29 04:15:49 2019
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 6EEF912026E for ; Fri, 29 Mar 2019 04:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 KxUx84Lo8kVa for ; Fri, 29 Mar 2019 04:15:44 -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 D9A02120267 for ; Fri, 29 Mar 2019 04:15:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1553858143; x=1555067743; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lFcjWytv73NpIHRKCakdtlSgdzJTi0cA4L0CClya7U0=; b=iELJPIk7MP8XKl3ZCuV65YU1T1OeOsAQ+G8Z3mMnNJOna+rFO6bqIpef 5ycLe0XTMenH5RWhn8tUbEgsK+V30EXYYlLq29ohzirbxb+ir5l/3XXKe uPh9DPtyFm14WchzqAF2tKIZ4JcMqmtEJfiAcooI+rl4dj79GvZmybGy+ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACn/Z1c/51dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghBogQMnCowgiymCDZg8gXsNAQEYC4Q?= =?us-ascii?q?DRgKFNyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQBATg0FwQCAQgRBAEBHxAnCx0?= =?us-ascii?q?IAgQBEgiDG4F1D6pWijKBLwGLMReBQD+EIz6CYQEBh0IDimqGT4FpkgkJAod?= =?us-ascii?q?qi1MiggNdkSyLLIEYkiICERWBLh84gVZwFTuCbAmEH4YpO4U/QTGOVoEfAQE?=
X-IronPort-AV: E=Sophos;i="5.60,284,1549929600"; d="scan'208";a="541266103"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 11:15:42 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2TBFgs2022499 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 11:15:42 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 06:15:41 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 29 Mar 2019 06:15:41 -0500
From: "Rob Wilton (rwilton)" 
To: Ladislav Lhotka , NETMOD WG 
Thread-Topic: [netmod] 6991bis: domain-name
Thread-Index: AQHU5hkKAEZh80vKfkGPoHXxJkfneqYidMrA
Date: Fri, 29 Mar 2019 11:15:41 +0000
Message-ID: <0fd250f07f2949ec9010c9c4f5b9b0d0@XCH-RCD-007.cisco.com>
References: 
In-Reply-To: 
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.63.23.177]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [netmod] 6991bis: domain-name
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 11:15:47 -0000

Hi Lada,

For a domain name that supports wildcard, I wonder whether that wouldn't be=
 better as a separate type.  I can imagine that in a lot of places a wildca=
rd domain name isn't appropriate.

Thanks,
Rob


> -----Original Message-----
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 29 March 2019 10:20
> To: NETMOD WG 
> Subject: [netmod] 6991bis: domain-name
>=20
> Hi,
>=20
> as a follow-up to my comment during the NETMOD session, I want to propose
> the following update to the the inet:domain-name type. The aim is to incl=
ude
> use cases that are currently rejected:
>=20
> - classless in-addr.arpa delegations [RFC 2317], i.e. labels like "128/26=
"
>=20
> - wildcards [RFC 4592], e.g. "*.example.net"
>=20
> OLD
>=20
>     pattern
>       '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
>     + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
>     + '|\.';
>=20
> NEW
>=20
>     pattern
>       '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
>     + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
>     + '|\.';
>=20
> Lada
>=20
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Mar 29 04:19:38 2019
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 6CE96120271 for ; Fri, 29 Mar 2019 04:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 eXqW53G1_vRo for ; Fri, 29 Mar 2019 04:19:33 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4522C120256 for ; Fri, 29 Mar 2019 04:19:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ADAFD747 for ; Fri, 29 Mar 2019 12:19:31 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id sdxg1b7qk_-X for ; Fri, 29 Mar 2019 12:19:31 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 29 Mar 2019 12:19:31 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98FD2200A8 for ; Fri, 29 Mar 2019 12:19:31 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id aR1BsncROKWO for ; Fri, 29 Mar 2019 12:19:31 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 61E58200A7 for ; Fri, 29 Mar 2019 12:19:31 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 29 Mar 2019 12:19:30 +0100
Received: by anna.localdomain (Postfix, from userid 501) id A62D63007A348D; Fri, 29 Mar 2019 12:19:30 +0100 (CET)
Date: Fri, 29 Mar 2019 12:19:30 +0100
From: Juergen Schoenwaelder 
To: 
Message-ID: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 11:19:37 -0000

Hi,

this is issue is closed but I wonder whether this is correct. I have
several questions looking at the issue on github:

- Why is this not a YANG issue?
- Which workaround is better?
- Why is this tagged as a NETCONF issue?

If we want to support binary encodings, we need to allow modelers to
define which types map to a canonical binary representation in
addition to the canonical string representation. As stated in the
issue description, hard-wiring some types in the encoding
specifications is very limited.

In terms of backwards compatibility, this issue should IMHO be tagged
high (adding binary encoding for some types does not cause any
backwards compatibility problem since so far we have only strings).

While I do not have a solution proposal, I think this issue is worth
to look at and we should not close it right now.

/js

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


From nobody Fri Mar 29 04:43:13 2019
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 83DC5120251 for ; Fri, 29 Mar 2019 04:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 qVAgXspNmnqx for ; Fri, 29 Mar 2019 04:43:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4169E12024B for ; Fri, 29 Mar 2019 04:43:08 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 0DA9463080; Fri, 29 Mar 2019 12:43:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553859786; bh=6lKCGQnw1+zeOriZDInd5xYL8fshsbmUeIf6ClpjhLU=; h=From:To:Date; b=E1XgjcUgSbJ6K3eATlIMWCpglzGKzUU6XCGTnaLoxGbPd9YHfyUY74YvM2nKeRW7K R0p58WkU6Ha4wUzlmey1W25hzacWSTAI/lzQijzKWQS/G4MXAyu0VmXSUxCrOZdpcb 1iFW1dznQ8SFE/rWkR/n+cNvlCc1puHVl7vQeSw4=
Message-ID: <51a374de9abfcef82452198ff078e0986cc179fc.camel@nic.cz>
From: Ladislav Lhotka 
To: "Rob Wilton (rwilton)" , NETMOD WG 
Date: Fri, 29 Mar 2019 12:43:05 +0100
In-Reply-To: <0fd250f07f2949ec9010c9c4f5b9b0d0@XCH-RCD-007.cisco.com>
References:  <0fd250f07f2949ec9010c9c4f5b9b0d0@XCH-RCD-007.cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] 6991bis: domain-name
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 11:43:12 -0000

Rob Wilton (rwilton) píše v Pá 29. 03. 2019 v 11:15 +0000:
> Hi Lada,
> 
> For a domain name that supports wildcard, I wonder whether that wouldn't be
> better as a separate type.  I can imagine that in a lot of places a wildcard
> domain name isn't appropriate.

But the description says:

It is designed to hold various types of domain names, including names used for A
or AAAA records (host names) and other records, such as SRV records.

And in DNS resource records, wilcard names are possible.

It is true that wildcards are not permitted in host names and such, but then the
"inet:host" type should not have domain-name as its member type. Even with the
existing version the "host" type permits "." which is not good either.

The "inet:host" type should IMO adhere to a stricter syntax of RFC 952. I will
send another message to address this.

Lada

> 
> Thanks,
> Rob
> 
> 
> > -----Original Message-----
> > From: netmod  On Behalf Of Ladislav Lhotka
> > Sent: 29 March 2019 10:20
> > To: NETMOD WG 
> > Subject: [netmod] 6991bis: domain-name
> > 
> > Hi,
> > 
> > as a follow-up to my comment during the NETMOD session, I want to propose
> > the following update to the the inet:domain-name type. The aim is to include
> > use cases that are currently rejected:
> > 
> > - classless in-addr.arpa delegations [RFC 2317], i.e. labels like "128/26"
> > 
> > - wildcards [RFC 4592], e.g. "*.example.net"
> > 
> > OLD
> > 
> >     pattern
> >       '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
> >     + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
> >     + '|\.';
> > 
> > NEW
> > 
> >     pattern
> >       '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
> >     + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
> >     + '|\.';
> > 
> > Lada
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > 
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Mar 29 07:29:14 2019
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 28E611202A7 for ; Fri, 29 Mar 2019 07:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 aZ8SoqABxZ7N for ; Fri, 29 Mar 2019 07:29:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDC41202A3 for ; Fri, 29 Mar 2019 07:29:08 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 19AD163080 for ; Fri, 29 Mar 2019 15:29:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553869746; bh=T272/5w/V1pXgVl7my34dkeMEZtOrzLk7+RWcPGG4i8=; h=From:To:Date; b=SnYZGRRxt5mPwT437WN5DuMUSuGv7loB01iRmqMNH+G/6LMB2AFTO9MGSTNym57+3 tLScH9fKrjDXu6HcgSxXzInD05BiY7CpW6cVPAV9YJ5KOA1BbZDJLYz5+e7EcSAxpE 8IxCzflqwJ64gYv7Kx2jPER8ZfR/YffPzEs9YBcI=
Message-ID: <542f5183bee87d67247a111733fe7aeccf520085.camel@nic.cz>
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Fri, 29 Mar 2019 15:29:05 +0100
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.0 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] 6991bis: host
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 14:29:13 -0000

Hi,

the inet:host type should not use the inet:domain-name as its member because the
latter type doesn't satisfy the requirements of RFC 952 and 1123 on host names.
For example, the type now permits a single dot (".") as the value or the
underscore character.

I propose to change the "host" type as follows:

OLD

    typedef host {
      type union {
        type inet:ip-address;
        type inet:domain-name;
      }
      ...
    }

NEW

    typedef host {
      type union {
        type inet:ip-address;
        type inet:host-name;
      }
      ...
    }

A reasonable definition of "host-name" is IMO a domain name whose labels are NR-
LDH (non-registered letter-digit-hyphen label) [RFC 5890]:

    typedef host-name {
      type string {
        pattern
          '((([a-zA-Z0-9]([a-zA-Z0-9\-]){0,61})?[a-zA-Z0-9]\.)*'
        + '([a-zA-Z0-9]([a-zA-Z0-9\-]){0,61})?[a-zA-Z0-9]\.?)';
        pattern '(.*\.)?..\-\-.*' {
          modifier invert-match;
        }
        length "2..253";
        ...
      }
    }

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Mar 29 09:07:36 2019
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 CC57E12001B for ; Fri, 29 Mar 2019 09:07:34 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hPkgnKGwIvoT for ; Fri, 29 Mar 2019 09:07:32 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 E7EF8120013 for ; Fri, 29 Mar 2019 09:07:31 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id r25so1792806lfn.13 for ; Fri, 29 Mar 2019 09:07:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Xfii+whgIOP+oBIci/yx8aFW8612MAYzhpH6WuTS4iQ=; b=cWABf5HnLY1zKT2FGJYXhJ5gLEu/Xl6hK1mIePLeWKpifRQ20femKTWB2mWhIIqI/X cagTLj5xKE11uJLKHpYZgCJcm/v7asFJUY2UlyFhd589YHTLAO5KPwYUDvtd/dVrcN2z Oyy8OGbAjJSqf+vUjSvspQS5hPK7pQ/WkyfTy2u8mvenPOPqU3WvQ2QYMsaB7tBiW8md CheFFVg/lhVnXC0UxtMZf8m3XV0aUPFt+lY/Dtin1WRI6fvqvzD6Lt9qQWHU0FCn0B7m cMjv+Eyk/4BV8llu72nDqAfNRCa50WiE2eKiH+tchF9Vq3HgU0a/0y+ZwavaB37fDb3R MjCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Xfii+whgIOP+oBIci/yx8aFW8612MAYzhpH6WuTS4iQ=; b=XnzDZxy35kXELsDs6v6XtRCk6VMUACqQIk61YN2m4+LqXxon+gns9ohD3cCfJzNcuG rL9ljTeFvoF7NogAZqXPwPkIz3g9TXvKaqe4/jXE19sTccz2v88aiWGxRg65QM8eP5bb nD4K1uflAXRf+uPCxoBfaRV6Uf6OqeJauCd5VJ9Q5EjdVSrpyMuUgUB02KgD7URPS1uw pes+aspi2/QFKOfAoRtB4FmCKR5xT8E4FsMIOuDsyhv+PXgEvzF0FYoaeCbOvyXrIQRT uVT7/lUXUasiPn2ct4cPUtO6sfFfHEN9fKb2he5pTy6rkRfPmmtjlmh9h1jbzPfc5dfS Uuxw==
X-Gm-Message-State: APjAAAXxrYRZb3T3DDifgwkjTg/mLmhHzjslMsUEuoqpmjrIkBEMCr24 6OONQi5g3q9+Sbz1zIyaKfqBD9T+Ddj10SK1ppqprA==
X-Google-Smtp-Source: APXvYqxcdH+uZQDh8kgBSUKH0OZm+QfqIbSqlVx5eImGjHLZD727auTHSN0wsril2KkIPPwbZAm/gwLMwWsDqXfPrSo=
X-Received: by 2002:ac2:489a:: with SMTP id x26mr8700849lfc.49.1553875650026;  Fri, 29 Mar 2019 09:07:30 -0700 (PDT)
MIME-Version: 1.0
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 29 Mar 2019 09:07:18 -0700
Message-ID: 
To: Juergen Schoenwaelder , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000025342d05853ddedf"
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 16:07:35 -0000

--00000000000025342d05853ddedf
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> this is issue is closed but I wonder whether this is correct. I have
> several questions looking at the issue on github:
>
> - Why is this not a YANG issue?
> - Which workaround is better?
> - Why is this tagged as a NETCONF issue?
>
>
Did you mean this should be NETCONF issue?
It is more of a protocol problem then a modeling problem.
The goal is to use the model unaltered.



> If we want to support binary encodings, we need to allow modelers to
> define which types map to a canonical binary representation in
> addition to the canonical string representation. As stated in the
> issue description, hard-wiring some types in the encoding
> specifications is very limited.
>
> In terms of backwards compatibility, this issue should IMHO be tagged
> high (adding binary encoding for some types does not cause any
> backwards compatibility problem since so far we have only strings).
>
>
Not so sure.
The base64 encoding could look like a valid string.
The receiver must know a binary type is being sent (XML and JSON both fail
here, but not CBOR).



> While I do not have a solution proposal, I think this issue is worth
> to look at and we should not close it right now.
>
>
I have a solution proposal, but I have not implemented it yet, so it it not
detailed...

Both sender and receiver need to agree on the binary encoding and how the
data is tagged as binary.

This expired draft should address that problem:
https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01

For every type T that they agree on, there are standard T.b2y() and T.y2b()
conversion functions.
There are also some extensions to define conversion templates so vendors
can add their own types.

The YANG modules do not need to actually be altered.  The peers will
negotiate the
set of types that will be sent as binary when the session starts.
The receiver knows T and the SID for each object, and will accept either
the YANG or binary encoding.



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

--00000000000025342d05853ddedf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Mar 29, 2019 at 4:19 AM Juerg=
en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,



this is issue is closed but I wonder whether this is correct. I have

several questions looking at the issue on github:



- Why is this not a YANG issue?

- Which workaround is better?

- Why is this tagged as a NETCONF issue?



Did you mean this should be NETCONF is=
sue?
It is more of a protocol problem then a modeling problem.
The goal is to use the model unaltered.

=
=C2=A0

If we want to support binary encodings, we need to allow modelers to

define which types map to a canonical binary representation in

addition to the canonical string representation. As stated in the

issue description, hard-wiring some types in the encoding

specifications is very limited.



In terms of backwards compatibility, this issue should IMHO be tagged

high (adding binary encoding for some types does not cause any

backwards compatibility problem since so far we have only strings).



Not so sure.
The base64 enco=
ding could look like a valid string.
The receiver must know a bin=
ary type is being sent (XML and JSON both fail
here, but not CBOR=
).

=C2=A0

While I do not have a solution proposal, I think this issue is worth

to look at and we should not close it right now.



I have a solution proposal, but I have=
 not implemented it yet, so it it not detailed...

=
Both sender and receiver need to agree on the binary encoding and how the d=
ata is tagged as binary.

This expired draft should=
 address that problem:

For every t=
ype T that they agree on, there are standard T.b2y() and T.y2b() conversion=
 functions.
There are also some extensions to define conversion t=
emplates so vendors can add their own types.

The Y=
ANG modules do not need to actually be altered.=C2=A0 The peers will negoti=
ate the
set of types that will be sent as binary when the session=
 starts.
The receiver knows T and the SID for each object, and wi=
ll accept either the YANG or binary encoding.

=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<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

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




--00000000000025342d05853ddedf--


From nobody Fri Mar 29 09:17:32 2019
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 0346912003E for ; Fri, 29 Mar 2019 09:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 7MB5Yp4z9La9 for ; Fri, 29 Mar 2019 09:17:27 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD33412001B for ; Fri, 29 Mar 2019 09:17:26 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4D55D747; Fri, 29 Mar 2019 17:17:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 0YnmYCCRDmPL; Fri, 29 Mar 2019 17:17:25 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 17:17:25 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36ED9200A8; Fri, 29 Mar 2019 17:17:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id gKofj_xB-a-t; Fri, 29 Mar 2019 17:17:24 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id C88C9200A7; Fri, 29 Mar 2019 17:17:24 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 29 Mar 2019 17:17:24 +0100
Received: by anna.localdomain (Postfix, from userid 501) id D986D3007A3A47; Fri, 29 Mar 2019 17:17:23 +0100 (CET)
Date: Fri, 29 Mar 2019 17:17:23 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: NetMod WG 
Message-ID: <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , NetMod WG 
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 16:17:31 -0000

On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > Hi,
> >
> > this is issue is closed but I wonder whether this is correct. I have
> > several questions looking at the issue on github:
> >
> > - Why is this not a YANG issue?
> > - Which workaround is better?
> > - Why is this tagged as a NETCONF issue?
> >
> >
> Did you mean this should be NETCONF issue?
> It is more of a protocol problem then a modeling problem.
> The goal is to use the model unaltered.
 
I think it would be valuable if say the definition of ipv4-address
could state that a canonical binary representation is of type binary {
length 4; }. Doing this is only meaningful for some types but it would
allow to add more binary representations over time.
 
> > If we want to support binary encodings, we need to allow modelers to
> > define which types map to a canonical binary representation in
> > addition to the canonical string representation. As stated in the
> > issue description, hard-wiring some types in the encoding
> > specifications is very limited.
> >
> > In terms of backwards compatibility, this issue should IMHO be tagged
> > high (adding binary encoding for some types does not cause any
> > backwards compatibility problem since so far we have only strings).
> >
> >
> Not so sure.
> The base64 encoding could look like a valid string.
> The receiver must know a binary type is being sent (XML and JSON both fail
> here, but not CBOR).

I am talking about CBOR, not about XML or JSON. I want to provide
hints to CBOR (or similar binary encodings) that values can be
represented in a different format. I do not expect these hints to be
used by XML or JSON. If you need binary encoding efficiency, use CBOR
instead of JSON.

> > While I do not have a solution proposal, I think this issue is worth
> > to look at and we should not close it right now.
> >
> >
> I have a solution proposal, but I have not implemented it yet, so it it not
> detailed...
> 
> Both sender and receiver need to agree on the binary encoding and how the
> data is tagged as binary.
> 
> This expired draft should address that problem:
> https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> 
> For every type T that they agree on, there are standard T.b2y() and T.y2b()
> conversion functions.
> There are also some extensions to define conversion templates so vendors
> can add their own types.
>
> The YANG modules do not need to actually be altered.  The peers will
> negotiate the
> set of types that will be sent as binary when the session starts.
> The receiver knows T and the SID for each object, and will accept either
> the YANG or binary encoding.

Sounds complex for me to negotiate this. I rather say once that a
binary encoding can ship an IPv6 address as type binary { length 16; }
and then CBOR will simply do the right thing.

/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 Mar 29 09:17:40 2019
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 D1C5712023C for ; Fri, 29 Mar 2019 02:01: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, SPF_PASS=-0.001, URIBL_BLOCKED=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 tFprebRg_noP for ; Fri, 29 Mar 2019 02:01:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E47C212015F for ; Fri, 29 Mar 2019 02:01:22 -0700 (PDT)
Received: from localhost (dhcp-9216.meeting.ietf.org [31.133.146.22]) by mail.tail-f.com (Postfix) with ESMTPSA id 443B81AE018B; Fri, 29 Mar 2019 10:01:21 +0100 (CET)
Date: Fri, 29 Mar 2019 10:01:12 +0100 (CET)
Message-Id: <20190329.100112.529032706409100311.mbj@tail-f.com>
To: exa@arrcus.com
Cc: nite@hq.sk, rwilton@cisco.com, rfc-editor@rfc-editor.org, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20190320164434.o456avee5r5gg2wo@localhost>
References:   <20190320164434.o456avee5r5gg2wo@localhost>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
X-Mailman-Approved-At: Fri, 29 Mar 2019 09:17:39 -0700
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5663)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 09:01:25 -0000

Ebben Aries  wrote:
> On Mar 19 23:27 PM, Robert Varga wrote:
> > On 19/03/2019 19:12, Rob Wilton (rwilton) wrote:
> > > Hi Ebben,
> > > 
> > > I've always taken the ABNF to list the definitive sub-statements that are allowed for the various deviate "add", "replace", or "delete" options.  Perhaps the RFC could state this more explicitly.  Perhaps raise an issue on the YANG Next issue tracker to clarify this (https://github.com/netmod-wg/yang-next/issues) and it might get discussed tomorrow.
> > 
> > I agree.
> > 
> > Proposed statements are simple cases, for which 'deviate replace' can be
> > used to specify the correct value -- for example remove 'min-elements'
> > by replacing it with 'min-elements 0'.
> 
> Sure - my point was rather that in either case we have an issue.  The
> table of substatements in 7.20.3.2 is either not accurate or we modify
> the grammar to match.

I agree that the document needs clarification, and the yang-next issue
will take care of that.  The document needs a clarification that the
refers to the grammar, or perhaps different substatement tables for
add/replace/delete.

Meanwhile, I think that this errata should be rejected.


/martin




> 'deviate replace' can be used to 'reverse' these
> substatements much like a 'delete' would as you point out but the
> wording in this section should state this - I'll raise an issue on the
> tracker
> 
> FWIW - pyang does not honor the grammar and allows for a mandatory
> substatement of 'deviate delete' while yanglint appears to follow the
> ABNF strictly
> 


From nobody Fri Mar 29 09:30:46 2019
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 3102C120048 for ; Fri, 29 Mar 2019 09:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SyPf7J12_u8C for ; Fri, 29 Mar 2019 09:30:39 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 EE2751202FB for ; Fri, 29 Mar 2019 09:30:31 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id v22so2504802lje.9 for ; Fri, 29 Mar 2019 09:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9ubKEcHeMZSjghz0SCyc2YPziBCqH6cJt6GcLhNF7m0=; b=hxCmOi8hBoCCQF/vkYjPZ+nv2/Zw3r2qKzIAinE2qwtOEBjhVZhzzuVKykpJ0OPZQD YzHBGIT7y242p+IqXzmqvf/J1QUHeMVEEDJSHbEIG33K0GuaWJ/ZbMn3Rb/69nCfIoIN X/1miPU4+KIhZAgjJ/M61pFofOH0p7ah8LkKypbQY2MvCzyYfmpUzpntX8e/dr2sXtbo cfTsIonE1FQAdyvOdIOHxrYH8ZJlOIqbEL93DCJ0Mzj6WDL1p9Y7kVpM7QyZe8+2jdQl MNhkPjA3w6c8bGq3kSz8GC3QyNl7rpPU2cBnOpRU7TEbWE4fDu1LRvAdfmEcZcgXj8YM C8wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9ubKEcHeMZSjghz0SCyc2YPziBCqH6cJt6GcLhNF7m0=; b=QvTM1wf7d9sp7ww20yWQFoOxkIzbtlqFH8Gwv5G23vY4KlBTDM+AKO8Eg+Qvtqjmqg jHRxttS26rCVOilXd83TqtwiMSgp5IQhbXfcdE3+ojkqdwECoFFL811MS19YWbA6PUts oOlEz2JA82de3k35C7PTW3U1ewrYXOMMQcg4H7WWB4QXXW/QOR9DrFkt4rEGpQEajrlH 2G6einjVk6yxuXwCQDBoAyWVxvglY0wpOT+jwRiumZ6V5A25/cwKg4nnck1vgyqMgpqB dXlVo4hBnTJxjohuAJhog7M02oa6s+bWcukWuuN9srUUaoYbZ6Yx5CSp6AbBB4+hCKR2 maQQ==
X-Gm-Message-State: APjAAAUFgSfym7U1SpP5XbGBOtMSWJGLbM7R9UK1QRSqvoxLnXND6qv9 xQ0kvcrwuypZyBTySVAydGGKoMx2NvUENEPiLmEzEg==
X-Google-Smtp-Source: APXvYqyqVIqsdeiVnWLM+FEyhRLXZqwCKwpPgeNc0yYHddqG3poDgh+cckro+U+SnLY9eAYJ1PVPSXIinTisqgwFR7E=
X-Received: by 2002:a2e:8616:: with SMTP id a22mr27351455lji.173.1553877030099;  Fri, 29 Mar 2019 09:30:30 -0700 (PDT)
MIME-Version: 1.0
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>  <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 29 Mar 2019 09:30:19 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000006772c005853e3027"
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 16:30:43 -0000

--0000000000006772c005853e3027
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > Hi,
> > >
> > > this is issue is closed but I wonder whether this is correct. I have
> > > several questions looking at the issue on github:
> > >
> > > - Why is this not a YANG issue?
> > > - Which workaround is better?
> > > - Why is this tagged as a NETCONF issue?
> > >
> > >
> > Did you mean this should be NETCONF issue?
> > It is more of a protocol problem then a modeling problem.
> > The goal is to use the model unaltered.
>
> I think it would be valuable if say the definition of ipv4-address
> could state that a canonical binary representation is of type binary {
> length 4; }. Doing this is only meaningful for some types but it would
> allow to add more binary representations over time.
>
> > > If we want to support binary encodings, we need to allow modelers to
> > > define which types map to a canonical binary representation in
> > > addition to the canonical string representation. As stated in the
> > > issue description, hard-wiring some types in the encoding
> > > specifications is very limited.
> > >
> > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > high (adding binary encoding for some types does not cause any
> > > backwards compatibility problem since so far we have only strings).
> > >
> > >
> > Not so sure.
> > The base64 encoding could look like a valid string.
> > The receiver must know a binary type is being sent (XML and JSON both
> fail
> > here, but not CBOR).
>
> I am talking about CBOR, not about XML or JSON. I want to provide
> hints to CBOR (or similar binary encodings) that values can be
> represented in a different format. I do not expect these hints to be
> used by XML or JSON. If you need binary encoding efficiency, use CBOR
> instead of JSON.
>
> > > While I do not have a solution proposal, I think this issue is worth
> > > to look at and we should not close it right now.
> > >
> > >
> > I have a solution proposal, but I have not implemented it yet, so it it
> not
> > detailed...
> >
> > Both sender and receiver need to agree on the binary encoding and how the
> > data is tagged as binary.
> >
> > This expired draft should address that problem:
> > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> >
> > For every type T that they agree on, there are standard T.b2y() and
> T.y2b()
> > conversion functions.
> > There are also some extensions to define conversion templates so vendors
> > can add their own types.
> >
> > The YANG modules do not need to actually be altered.  The peers will
> > negotiate the
> > set of types that will be sent as binary when the session starts.
> > The receiver knows T and the SID for each object, and will accept either
> > the YANG or binary encoding.
>
> Sounds complex for me to negotiate this. I rather say once that a
> binary encoding can ship an IPv6 address as type binary { length 16; }
> and then CBOR will simply do the right thing.
>
>
OK, but this would require new type names.
You cannot simply change some standard type to be a union with a binary
type.
This forces all implementations of that type to support the binary variant.
That breaks old clients that worked with the version before the binary
variant.

The ripple effect on the models changing types would be non-trivial.
Using this union-type approach forces every protocol to support the binary
encoding,
yet base64 in a union with strings is very error-prone.


/js
>

Andy



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

--0000000000006772c005853e3027
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Mar 29, 2019 at 9:17 AM Juerg=
en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Mar 29, 2019 at 09:07:18AM -0=
700, Andy Bierman wrote:

> On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <

> j.schoenwaelder@jacobs-university.de> wrote:

> 

> > Hi,

> >

> > this is issue is closed but I wonder whether this is correct. I h=
ave

> > several questions looking at the issue on github:

> >

> > - Why is this not a YANG issue?

> > - Which workaround is better?

> > - Why is this tagged as a NETCONF issue?

> >

> >

> Did you mean this should be NETCONF issue?

> It is more of a protocol problem then a modeling problem.

> The goal is to use the model unaltered.



I think it would be valuable if say the definition of ipv4-address

could state that a canonical binary representation is of type binary {

length 4; }. Doing this is only meaningful for some types but it would

allow to add more binary representations over time.



> > If we want to support binary encodings, we need to allow modelers=
 to

> > define which types map to a canonical binary representation in
> > addition to the canonical string representation. As stated in the=


> > issue description, hard-wiring some types in the encoding

> > specifications is very limited.

> >

> > In terms of backwards compatibility, this issue should IMHO be ta=
gged

> > high (adding binary encoding for some types does not cause any
> > backwards compatibility problem since so far we have only strings=
).

> >

> >

> Not so sure.

> The base64 encoding could look like a valid string.

> The receiver must know a binary type is being sent (XML and JSON both =
fail

> here, but not CBOR).



I am talking about CBOR, not about XML or JSON. I want to provide

hints to CBOR (or similar binary encodings) that values can be

represented in a different format. I do not expect these hints to be

used by XML or JSON. If you need binary encoding efficiency, use CBOR

instead of JSON.



> > While I do not have a solution proposal, I think this issue is wo=
rth

> > to look at and we should not close it right now.

> >

> >

> I have a solution proposal, but I have not implemented it yet, so it i=
t not

> detailed...

> 

> Both sender and receiver need to agree on the binary encoding and how =
the

> data is tagged as binary.

> 

> This expired draft should address that problem:

> https://tools.ietf.org/html/=
draft-mahesh-netconf-binary-encoding-01

> 

> For every type T that they agree on, there are standard T.b2y() and T.=
y2b()

> conversion functions.

> There are also some extensions to define conversion templates so vendo=
rs

> can add their own types.

>

> The YANG modules do not need to actually be altered.=C2=A0 The peers w=
ill

> negotiate the

> set of types that will be sent as binary when the session starts.

> The receiver knows T and the SID for each object, and will accept eith=
er

> the YANG or binary encoding.



Sounds complex for me to negotiate this. I rather say once that a

binary encoding can ship an IPv6 address as type binary { length 16; }

and then CBOR will simply do the right thing.



OK, but this would require new type na=
mes.
You cannot simply change some standard type to be a union wi=
th a binary type.
This forces all implementations of that type to=
 support the binary variant.
That breaks old clients that worked =
with the version before the binary variant.

The ri=
pple effect on the models changing types would be non-trivial.
Us=
ing this union-type approach forces every protocol to support the binary en=
coding,
yet base64 in a union with strings is very error-prone.



/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<https://www.jacobs-university.de/>




--0000000000006772c005853e3027--


From nobody Fri Mar 29 10:51:08 2019
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 E79E71202CF for ; Fri, 29 Mar 2019 10:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5znf0Y7S8Vjf for ; Fri, 29 Mar 2019 10:51:02 -0700 (PDT)
Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 E0B1512008A for ; Fri, 29 Mar 2019 10:50:56 -0700 (PDT)
Received: by mail-yw1-xc31.google.com with SMTP id c4so965344ywa.11 for ; Fri, 29 Mar 2019 10:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yJB7o9EnDN9rZ5XOCJYYEmnepvJe2fHfl7hCp3MaJc4=; b=Hu2dZCuyNIt6Pj/ER+R04S6TRNYvSbg2CukZn/DRI4PQ2emuYVTKIWX2PwGYR+nonP 3f89dFA+M8vrHiTU87uAZ91oeOXOa0e5Pr2AtuVmy/84MoE55TPxaXneIRd+RJvXLVaw OHjYO/IytvrGBQYuSZITldCcSn+1/AWcprpn+3jVDsJaVymnemmCY3lOqKiszPtzcWMU zjPZz0VilMlDjsZX5xZpSBTSQ0mSTnifAuOvk7oP+cAbshWk1kCwp722+XqnMTAGKOKp 7N91AwlG87zfK4ZnxeiNeph6RAv95lIeBaSUmhGrjgDVdI9B/+mn78SOuVVz4oy+5sPY aOZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yJB7o9EnDN9rZ5XOCJYYEmnepvJe2fHfl7hCp3MaJc4=; b=fFJdY0k6q+2wHvzT1gTqCgVezSi1JFVnbXrt9OIbVlBDifIDLZTEYgVXsw/S/MIIIV yXl2P4l0Zfhf1TzfH33loAhuo+gGvpsvA9hTlhfzuyLzntWR10pgMOlzt9Ito7wJM5Fn ydzhNQrL9ANjSaROLI5yxinjb85GL6VP+vdBT0r1U1C7F+bA7NYcoLdPMEMLRwvPfKJI d06UuXQ6iRTh8DwyoTWHbKx1OKsoOKwtdj5ylU8ytkK5gtLDY5Del4B6quHhR3YokaVl eGI5fTAA8SSklFS/0y+CnPm5EjUQgwnca1bF+p3rGkWEu5dxjCIedrAx00esAYfxmpBK K2CQ==
X-Gm-Message-State: APjAAAXZbEUX+P5aALQbTxRLsn4deiXuAbrZRoQn8Ia6Tw1oRyiffZBC F+z7FLIa3+q0e3HW/i8yhpE=
X-Google-Smtp-Source: APXvYqx8oBk2xVK6bZ3Bf2TIrJjCh7bHFqRFJz9iDHrgAuL5HB3p83YfbOlvTzTAXgk8CbtXJCe/DA==
X-Received: by 2002:a81:3791:: with SMTP id e139mr41860697ywa.476.1553881855972;  Fri, 29 Mar 2019 10:50:55 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id d64sm1181269ywb.64.2019.03.29.10.50.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 10:50:54 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <7D105CD4-9C4A-4643-9B8E-0F54B54F5B26@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6D01C6CC-6A7A-4CF6-948B-5A016DF91FFF"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 29 Mar 2019 10:50:52 -0700
In-Reply-To: 
Cc: "netmod@ietf.org" 
To: Robert Wilton 
References: 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 17:51:06 -0000

--Apple-Mail=_6D01C6CC-6A7A-4CF6-948B-5A016DF91FFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Robert,

Thanks for putting the minutes together.=20

> On Mar 28, 2019, at 1:43 AM, Rob Wilton (rwilton)  =
wrote:
>=20
> -        These was agreement that IETF models should be limited to a =
linear revision history, with changes only in the most recent revision.  =
It was agreed that in some cases it is necessary to make NBC changes (in =
a new most recent revision) in IETF YANG modules to fix bugs.
> =20
> -        There was discussion that an applicability statement could be =
added, or some of the requirements could be split between SDO vs Vendor =
requirements, but there did not seem to be strong consensus either for =
or against this change.  In anything, there seemed to be a slight =
preference to trying not to make this split.
> =20
> -        It was agreed that YANG should have a single versioning =
scheme that is capable of covering both SDO requirements and vendor =
requirements.  There was agreement that guidelines text could be used to =
provide guidance on how IETF models should be versioned.


The combination of these bullet items, and maybe other bullet items does =
not make clear if there was any consensus in allowing (or maybe even =
preventing) vendors from using a versioning system to keep track of NBC =
changes on other (non-latest) branches of the model. I think I heard =
from multiple vendors (outside of this meeting) that making NBC changes =
was needed on the non-latest branches, whatever IETF or other SDOs =
decide. Has that sentiment changed?

If it is the case, the split between the requirements of SDO and the =
vendors is inevitable.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_6D01C6CC-6A7A-4CF6-948B-5A016DF91FFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Robert,

Thanks for =
putting the minutes together. 

On Mar 28, 2019, at 1:43 AM, Rob Wilton =
(rwilton) <rwilton@cisco.com> wrote:

-        These was =
agreement that IETF models should be limited to a linear revision =
history, with changes only in the most recent revision.  It was =
agreed that in some cases it is necessary to make NBC changes (in a new =
most recent revision) in IETF YANG modules to fix bugs.
 
-        There was =
discussion that an applicability statement could be added, or some of =
the requirements could be split between SDO vs Vendor requirements, but =
there did not seem to be strong consensus either for or against this =
change.  In anything, there seemed to be a slight preference to =
trying not to make this split.
 
-        It was agreed =
that YANG should have a single versioning scheme that is capable of =
covering both SDO requirements and vendor requirements.  There was =
agreement that guidelines text could be used to provide guidance on how =
IETF models should be versioned.

The combination of these =
bullet items, and maybe other bullet items does not make clear if there =
was any consensus in allowing (or maybe even preventing) vendors from =
using a versioning system to keep track of NBC changes on other =
(non-latest) branches of the model. I think I heard from multiple =
vendors (outside of this meeting) that making NBC changes was needed on =
the non-latest branches, whatever IETF or other SDOs decide. Has that =
sentiment changed?

If it is the case, the split between the requirements of SDO =
and the vendors is inevitable.

Thanks.



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_6D01C6CC-6A7A-4CF6-948B-5A016DF91FFF--


From nobody Fri Mar 29 11:31:41 2019
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 D1DE8120340 for ; Fri, 29 Mar 2019 11:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 kfNNK1dWPKpl for ; Fri, 29 Mar 2019 11:31:37 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC88D120408 for ; Fri, 29 Mar 2019 11:31:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5DAAC37; Fri, 29 Mar 2019 19:31:35 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id tTkDo0v7Y9Yf; Fri, 29 Mar 2019 19:31:35 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 19:31:35 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DF30200A8; Fri, 29 Mar 2019 19:31:35 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id f0qm37HTH3SN; Fri, 29 Mar 2019 19:31:34 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id B676E200A7; Fri, 29 Mar 2019 19:31:34 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 29 Mar 2019 19:31:33 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 78D313007A3C89; Fri, 29 Mar 2019 19:31:32 +0100 (CET)
Date: Fri, 29 Mar 2019 19:31:32 +0100
From: Juergen Schoenwaelder 
To: Mahesh Jethanandani 
CC: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20190329183132.7t75vbtbtxostah2@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Mahesh Jethanandani , Robert Wilton , "netmod@ietf.org" 
References:  <7D105CD4-9C4A-4643-9B8E-0F54B54F5B26@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7D105CD4-9C4A-4643-9B8E-0F54B54F5B26@gmail.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 18:31:39 -0000

On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:
> 
> The combination of these bullet items, and maybe other bullet items does not make clear if there was any consensus in allowing (or maybe even preventing) vendors from using a versioning system to keep track of NBC changes on other (non-latest) branches of the model. I think I heard from multiple vendors (outside of this meeting) that making NBC changes was needed on the non-latest branches, whatever IETF or other SDOs decide. Has that sentiment changed?
> 
> If it is the case, the split between the requirements of SDO and the vendors is inevitable.
>

If there is a solution that can handle multiple branches, then the
same solution should work for SDOs that choose to use only a single
branch. I do not see why a split is inevitable.

/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 Mar 29 11:46:38 2019
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 72DF41202C4 for ; Fri, 29 Mar 2019 11:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 6tGYBM3BwxzA for ; Fri, 29 Mar 2019 11:46:31 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D251202E5 for ; Fri, 29 Mar 2019 11:46:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C67F06CF; Fri, 29 Mar 2019 19:46:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id vZOHGV3lpgLn; Fri, 29 Mar 2019 19:46:26 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Mar 2019 19:46:26 +0100 (CET)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85C4D200AB; Fri, 29 Mar 2019 19:46:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 8os7y3BCQ4GB; Fri, 29 Mar 2019 19:46:26 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0C7F2200A8; Fri, 29 Mar 2019 19:46:26 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 29 Mar 2019 19:46:25 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 460FF3007A3D06; Fri, 29 Mar 2019 19:46:24 +0100 (CET)
Date: Fri, 29 Mar 2019 19:46:24 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: NetMod WG 
Message-ID: <20190329184624.4sg6lbasv5b5u4hw@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , NetMod WG 
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>  <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 18:46:37 -0000

On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > > Hi,
> > > >
> > > > this is issue is closed but I wonder whether this is correct. I have
> > > > several questions looking at the issue on github:
> > > >
> > > > - Why is this not a YANG issue?
> > > > - Which workaround is better?
> > > > - Why is this tagged as a NETCONF issue?
> > > >
> > > >
> > > Did you mean this should be NETCONF issue?
> > > It is more of a protocol problem then a modeling problem.
> > > The goal is to use the model unaltered.
> >
> > I think it would be valuable if say the definition of ipv4-address
> > could state that a canonical binary representation is of type binary {
> > length 4; }. Doing this is only meaningful for some types but it would
> > allow to add more binary representations over time.
> >
> > > > If we want to support binary encodings, we need to allow modelers to
> > > > define which types map to a canonical binary representation in
> > > > addition to the canonical string representation. As stated in the
> > > > issue description, hard-wiring some types in the encoding
> > > > specifications is very limited.
> > > >
> > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > high (adding binary encoding for some types does not cause any
> > > > backwards compatibility problem since so far we have only strings).
> > > >
> > > >
> > > Not so sure.
> > > The base64 encoding could look like a valid string.
> > > The receiver must know a binary type is being sent (XML and JSON both
> > fail
> > > here, but not CBOR).
> >
> > I am talking about CBOR, not about XML or JSON. I want to provide
> > hints to CBOR (or similar binary encodings) that values can be
> > represented in a different format. I do not expect these hints to be
> > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > instead of JSON.
> >
> > > > While I do not have a solution proposal, I think this issue is worth
> > > > to look at and we should not close it right now.
> > > >
> > > >
> > > I have a solution proposal, but I have not implemented it yet, so it it
> > not
> > > detailed...
> > >
> > > Both sender and receiver need to agree on the binary encoding and how the
> > > data is tagged as binary.
> > >
> > > This expired draft should address that problem:
> > > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> > >
> > > For every type T that they agree on, there are standard T.b2y() and
> > T.y2b()
> > > conversion functions.
> > > There are also some extensions to define conversion templates so vendors
> > > can add their own types.
> > >
> > > The YANG modules do not need to actually be altered.  The peers will
> > > negotiate the
> > > set of types that will be sent as binary when the session starts.
> > > The receiver knows T and the SID for each object, and will accept either
> > > the YANG or binary encoding.
> >
> > Sounds complex for me to negotiate this. I rather say once that a
> > binary encoding can ship an IPv6 address as type binary { length 16; }
> > and then CBOR will simply do the right thing.
> >
> >
> OK, but this would require new type names.
> You cannot simply change some standard type to be a union with a binary
> type.
>
> This forces all implementations of that type to support the binary variant.
> That breaks old clients that worked with the version before the binary
> variant.
> 
> The ripple effect on the models changing types would be non-trivial.
> Using this union-type approach forces every protocol to support the binary
> encoding,
> yet base64 in a union with strings is very error-prone.
> 

I am not proposing do change the type definitions we have. My idea was
to have an optional additional definition for binary encodings. Here
is an ad-hoc example (I do not like the details of the syntax, but
perhaps this helps to understand the idea):

     typedef ipv4-address {
       type string {
         pattern
           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
       }
       description
         "The ipv4-address type represents an IPv4 address in
          dotted-quad notation.";

       binary-representation {
         type binary {
	   length 4;
	 }
	 description
	   "The binary representation uses as 4-byte binary string
	    in network byte ordering.";
       }
     }

The CBOR encoder (or other binary encoders) would then encode the
value as a 4 byte binary value, the XML and JSON encoder would use the
canonical string representation.  If the binary-representation is not
specified, then the generic CBOR encoding rules apply. I assume that
additional binary representation definitions will only be needed for a
couple of types (and I might even be fine to restrict that to
typedefs). Anyway, details need work, but if we want to support more
efficient binary encodings, then I think we should keep the issue #46
open.

/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 Mar 29 11:57:54 2019
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 083081202CB for ; Fri, 29 Mar 2019 11:57: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 u_7cjKVwU5f7 for ; Fri, 29 Mar 2019 11:57:48 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3241202C4 for ; Fri, 29 Mar 2019 11:57:47 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id q66so2885889ljq.7 for ; Fri, 29 Mar 2019 11:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eOtZ/aqxgDjLyIwdqUlgs/ZhNFf42HiUj4m1WVJDzDs=; b=dDYCZeMGuarx9APbjjOuKxrL2B32DUvZMUjRe+43gmwHA8LzrVJc76BrzirTDXTTMg h+LPtE0BeClvJaXhZkKZ59M/BuAMl71i79Cd0w5rfRTDDW0XkWS1ySkSnNuX3SeCkaPr GNBkquRDH7VrmJLm94b9zjHVYLNvjyCxHkiVxuVFhwIldjTFH2X1dAMOQ9BqqH7Nrogr b6qzPmL7p7+n12D6brsPKLtbEYwvTQlqMIiyTP0nDYxjNYbHqgngV+tfvqfvH4/bGcWr PRFNqQqlf7Q8iCKvZKZZos/IIpUuyymGDwNpHyDOdbzgfgDQKShGp43sN+Ptd2EfPvD0 AZNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eOtZ/aqxgDjLyIwdqUlgs/ZhNFf42HiUj4m1WVJDzDs=; b=ahwgmLJ3GQdwrlMNxL0sERm/71GYwRpwJNHhxZdlryNsU2HuI/ZrrFboD3CnNgjMco SrxL3gSKBeZWwUYamrL6pBNgjMm8l14003sIV/UkrL93kppAsU+zrE1K5KfR1PpVtgSX fyyX8sc2/EXJGHpR/471v3p7ge4C5I/YDEGW3srbYXAXU0sHrS6DDjS48GNQsUcVIkdL 2IxZ2GdovlwNtWE9sNrMNHvFGfamWLAyccTfXe0aIokLWBhxyI8H/ESyPztSIrJmZxKS rWVQxa77Gui+2tPedMSLt+hqXHf9EvRMeG6WiOtAPdz/UNerp8c3NPnXqc1L5w3D08KR impA==
X-Gm-Message-State: APjAAAXRu1JGlbspbJJTjCpCcgAzGZHbk3VHG6mjCgi6WQGZk2frFJuI DojMUgQv45zjVJ3jLv30EMbomZL8Xu8JS44h264Krw==
X-Google-Smtp-Source: APXvYqwaKCN+lJVfGedOXVQlRwVYbBy/3tS6K8HkkK4mLF+A/uBPqtM2p4UUQ5ezVvBiZbAeoWt265Qv4EhXSjl5XLE=
X-Received: by 2002:a2e:844a:: with SMTP id u10mr15984802ljh.41.1553885865825;  Fri, 29 Mar 2019 11:57:45 -0700 (PDT)
MIME-Version: 1.0
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>  <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de>  <20190329184624.4sg6lbasv5b5u4hw@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190329184624.4sg6lbasv5b5u4hw@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 29 Mar 2019 11:57:34 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000000de30e0585403f57"
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 18:57:53 -0000

--0000000000000de30e0585403f57
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. I
> have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type binary {
> > > length 4; }. Doing this is only meaningful for some types but it would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow modelers
> to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be
> tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to be
> > > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is
> worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, so it
> it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding and
> how the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> > > >
> > > > For every type T that they agree on, there are standard T.b2y() and
> > > T.y2b()
> > > > conversion functions.
> > > > There are also some extensions to define conversion templates so
> vendors
> > > > can add their own types.
> > > >
> > > > The YANG modules do not need to actually be altered.  The peers will
> > > > negotiate the
> > > > set of types that will be sent as binary when the session starts.
> > > > The receiver knows T and the SID for each object, and will accept
> either
> > > > the YANG or binary encoding.
> > >
> > > Sounds complex for me to negotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length 16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a binary
> > type.
> >
> > This forces all implementations of that type to support the binary
> variant.
> > That breaks old clients that worked with the version before the binary
> > variant.
> >
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the
> binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> >
>
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
>
>      typedef ipv4-address {
>        type string {
>          pattern
>            '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>          +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>        }
>        description
>          "The ipv4-address type represents an IPv4 address in
>           dotted-quad notation.";
>
>        binary-representation {
>          type binary {
>            length 4;
>          }
>          description
>            "The binary representation uses as 4-byte binary string
>             in network byte ordering.";
>        }
>      }
>
> The CBOR encoder (or other binary encoders) would then encode the
> value as a 4 byte binary value, the XML and JSON encoder would use the
> canonical string representation.  If the binary-representation is not
> specified, then the generic CBOR encoding rules apply. I assume that
> additional binary representation definitions will only be needed for a
> couple of types (and I might even be fine to restrict that to
> typedefs). Anyway, details need work, but if we want to support more
> efficient binary encodings, then I think we should keep the issue #46
> open.
>
>

OK -- this is what I had in mind but off to the side, like a deviations
module.
If the client and server agree on the module containing the standard
extension usages
it will not be that complex in the protocol.

  ex:binary-representation ietf-inet-types:ipv4-address {
     ex:binary-length 4;
     ex:binary-pattern "b0.b1.b2.b3";
  }

I agree YANG 1.2 should have real statements instead of extensions.




> /js
>
>
Andy



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

--0000000000000de30e0585403f57
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Mar 29, 2019 at 11:46 AM Juer=
gen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Mar 29, 2019 at 09:30:19AM -=
0700, Andy Bierman wrote:

> On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <

> j.schoenwaelder@jacobs-university.de> wrote:

> 

> > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:

> > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:

> > >

> > > > Hi,

> > > >

> > > > this is issue is closed but I wonder whether this is co=
rrect. I have

> > > > several questions looking at the issue on github:

> > > >

> > > > - Why is this not a YANG issue?

> > > > - Which workaround is better?

> > > > - Why is this tagged as a NETCONF issue?

> > > >

> > > >

> > > Did you mean this should be NETCONF issue?

> > > It is more of a protocol problem then a modeling problem.
> > > The goal is to use the model unaltered.

> >

> > I think it would be valuable if say the definition of ipv4-addres=
s

> > could state that a canonical binary representation is of type bin=
ary {

> > length 4; }. Doing this is only meaningful for some types but it =
would

> > allow to add more binary representations over time.

> >

> > > > If we want to support binary encodings, we need to allo=
w modelers to

> > > > define which types map to a canonical binary representa=
tion in

> > > > addition to the canonical string representation. As sta=
ted in the

> > > > issue description, hard-wiring some types in the encodi=
ng

> > > > specifications is very limited.

> > > >

> > > > In terms of backwards compatibility, this issue should =
IMHO be tagged

> > > > high (adding binary encoding for some types does not ca=
use any

> > > > backwards compatibility problem since so far we have on=
ly strings).

> > > >

> > > >

> > > Not so sure.

> > > The base64 encoding could look like a valid string.

> > > The receiver must know a binary type is being sent (XML and =
JSON both

> > fail

> > > here, but not CBOR).

> >

> > I am talking about CBOR, not about XML or JSON. I want to provide=


> > hints to CBOR (or similar binary encodings) that values can be
> > represented in a different format. I do not expect these hints to=
 be

> > used by XML or JSON. If you need binary encoding efficiency, use =
CBOR

> > instead of JSON.

> >

> > > > While I do not have a solution proposal, I think this i=
ssue is worth

> > > > to look at and we should not close it right now.

> > > >

> > > >

> > > I have a solution proposal, but I have not implemented it ye=
t, so it it

> > not

> > > detailed...

> > >

> > > Both sender and receiver need to agree on the binary encodin=
g and how the

> > > data is tagged as binary.

> > >

> > > This expired draft should address that problem:

> > > https://tools.ietf=
.org/html/draft-mahesh-netconf-binary-encoding-01

> > >

> > > For every type T that they agree on, there are standard T.b2=
y() and

> > T.y2b()

> > > conversion functions.

> > > There are also some extensions to define conversion template=
s so vendors

> > > can add their own types.

> > >

> > > The YANG modules do not need to actually be altered.=C2=A0 T=
he peers will

> > > negotiate the

> > > set of types that will be sent as binary when the session st=
arts.

> > > The receiver knows T and the SID for each object, and will a=
ccept either

> > > the YANG or binary encoding.

> >

> > Sounds complex for me to negotiate this. I rather say once that a=


> > binary encoding can ship an IPv6 address as type binary { length =
16; }

> > and then CBOR will simply do the right thing.

> >

> >

> OK, but this would require new type names.

> You cannot simply change some standard type to be a union with a binar=
y

> type.

>

> This forces all implementations of that type to support the binary var=
iant.

> That breaks old clients that worked with the version before the binary=


> variant.

> 

> The ripple effect on the models changing types would be non-trivial.
> Using this union-type approach forces every protocol to support the bi=
nary

> encoding,

> yet base64 in a union with strings is very error-prone.

> 



I am not proposing do change the type definitions we have. My idea was

to have an optional additional definition for binary encodings. Here

is an ad-hoc example (I do not like the details of the syntax, but

perhaps this helps to understand the idea):



=C2=A0 =C2=A0 =C2=A0typedef ipv4-address {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'(([0-9]|[1-9][0-9]|1[0-9][0-9=
]|2[0-4][0-9]|25[0-5])\.){3}'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 '([0-9]|[1-9][0-9]|1[0-9][0-9=
]|2[0-4][0-9]|25[0-5])';

=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The ipv4-address type represents an=
 IPv4 address in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dotted-quad notation.";



=C2=A0 =C2=A0 =C2=A0 =C2=A0binary-representation {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type binary {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length 4;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The binary representation us=
es as 4-byte binary string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in network byte ordering.";<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0}



The CBOR encoder (or other binary encoders) would then encode the

value as a 4 byte binary value, the XML and JSON encoder would use the

canonical string representation.=C2=A0 If the binary-representation is not<=
br>
specified, then the generic CBOR encoding rules apply. I assume that

additional binary representation definitions will only be needed for a

couple of types (and I might even be fine to restrict that to

typedefs). Anyway, details need work, but if we want to support more

efficient binary encodings, then I think we should keep the issue #46

open.




OK -- this is what I ha=
d in mind but off to the side, like a deviations module.
If the c=
lient and server agree on the module containing the standard extension usag=
es
it will not be that complex in the protocol.

=C2=A0 ex:binary-representation ietf-inet-types:ipv4-address {
=C2=A0 =C2=A0 =C2=A0ex:binary-length 4;
=C2=A0 =C2=A0 =C2=
=A0ex:binary-pattern "b0.b1.b2.b3";
=C2=A0 }
=

I agree YANG 1.2 should have real statements instead of exte=
nsions.


=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<https://www.jacobs-university.de/>




--0000000000000de30e0585403f57--


From nobody Fri Mar 29 14:16:57 2019
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 448BF12002F for ; Fri, 29 Mar 2019 14:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BtcM6Vec0hhv for ; Fri, 29 Mar 2019 14:16:51 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 D062A120005 for ; Fri, 29 Mar 2019 14:16:51 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id r15so1610452pfn.9 for ; Fri, 29 Mar 2019 14:16:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bdWgHQZu6E+ebIXqirZTJiF+IC/NHg75PWNew8I5SI4=; b=baYxBX2Hbl/Ut49GwVSFZhYY4SHplvb4KwpgrELMJZFQfBoh6mHRTLPtXO2gXVzTCr Mvw1W64o4mBi4qt24dGJ6MOr/wEpBxUnlUsZ7I6JjCmNTIoNc5G89wuc6JKTMNNzH784 3hVPi2umuHd4kPlYS33vFrYKWzEMF0oRmM4JfIPEocwbIfDpFRMIX6zqZ6hRAgVzxLa1 lxhXTFx0/IXQ9KtB+Vs+380cj9C2OGrvH75BtpkjYxVeZe31e2j4MZvP9ZZNjEDfP0PO 2gOWldG3Uk9C1M3KtEAb9dY9NH2K2co7WWxTVJPoCBLAXXbbnErtnX/kjZGc6YhR2UKf LBiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bdWgHQZu6E+ebIXqirZTJiF+IC/NHg75PWNew8I5SI4=; b=YVrKvm5S/tZPnOGA6CL0Fd1W8FnxRLQeahVyYSCBAgUDqq9YXQw5fKGgXqJvYmRg6X F99YtQshPJcFj1vbOrpgZ68mEZ44T7z//n5Wxk7X++e18itcGxrP2iC11yl/DUZgq2cx o+iM+ZKTxFYrp264lyjJtzXpXhtso2oo4OnB31x0dEWN5NakFeFVgMRaRnltklNTwMgD zIx2QXmf2X1qbs/vhUwmmBG7sL1NpRvoRldTgaB0NvGWTvJzoAieSiRjWdnfnwlJg7xV js73J+1syzoIMuULVKolxyXwf/EeSG7uSWsEF1Qqsg+euuLyUD74wvfbiKIQHpmo5eko 6mUw==
X-Gm-Message-State: APjAAAUFHQ/H7zfJqinKUororH1r60TlwyrJe4H/pPjYJZyouCRhSSe6 4Y/X5GRFGvYVGhbuXza5WTg=
X-Google-Smtp-Source: APXvYqzxmnBchD+GfztRtalmhbHURDm5GZmHREvLOxRstNe6hSohjJPGGPgzhf4Kk1NROXirE2DFUw==
X-Received: by 2002:a63:1064:: with SMTP id 36mr20489508pgq.155.1553894211370;  Fri, 29 Mar 2019 14:16:51 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id b15sm4079562pgg.90.2019.03.29.14.16.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 14:16:50 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CCFEF47F-261B-4748-8EAE-C1B01440A43F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 29 Mar 2019 14:16:49 -0700
In-Reply-To: <20190329183132.7t75vbtbtxostah2@anna.jacobs.jacobs-university.de>
Cc: Robert Wilton , "netmod@ietf.org" 
To: Juergen Schoenwaelder 
References:  <7D105CD4-9C4A-4643-9B8E-0F54B54F5B26@gmail.com> <20190329183132.7t75vbtbtxostah2@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 21:16:55 -0000

--Apple-Mail=_CCFEF47F-261B-4748-8EAE-C1B01440A43F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:
>>=20
>> The combination of these bullet items, and maybe other bullet items =
does not make clear if there was any consensus in allowing (or maybe =
even preventing) vendors from using a versioning system to keep track of =
NBC changes on other (non-latest) branches of the model. I think I heard =
from multiple vendors (outside of this meeting) that making NBC changes =
was needed on the non-latest branches, whatever IETF or other SDOs =
decide. Has that sentiment changed?
>>=20
>> If it is the case, the split between the requirements of SDO and the =
vendors is inevitable.
>>=20
>=20
> If there is a solution that can handle multiple branches, then the
> same solution should work for SDOs that choose to use only a single
> branch. I do not see why a split is inevitable.

If a single solution works for both SDO and the vendor, that is great. =
And I think that was the point of the third bullet in the list I send.

But that does mean the requirements of SDO and the vendor community =
cannot be different. There is a strong requirement that SDOs make NBC =
changes only on the most recent version of the YANG models. In the =
vendor community, NBC changes are going to be made on non-latest =
branches also.

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

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_CCFEF47F-261B-4748-8EAE-C1B01440A43F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On =
Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:

The =
combination of these bullet items, and maybe other bullet items does not =
make clear if there was any consensus in allowing (or maybe even =
preventing) vendors from using a versioning system to keep track of NBC =
changes on other (non-latest) branches of the model. I think I heard =
from multiple vendors (outside of this meeting) that making NBC changes =
was needed on the non-latest branches, whatever IETF or other SDOs =
decide. Has that sentiment changed?

If it =
is the case, the split between the requirements of SDO and the vendors =
is inevitable.


If=
 there is a solution that can handle multiple branches, then the
same solution should work for SDOs that choose to use only a =
single
branch. I do not see why a split is inevitable.

If a =
single solution works for both SDO and the vendor, =
that is great. And I think that was the point of the third bullet in the =
list I send.

But that does mean the =
requirements of SDO and the vendor community cannot be =
different. There is a strong requirement that SDOs make NBC changes only =
on the most recent version of the YANG models. In the vendor community, =
NBC changes are going to be made on non-latest branches =
also.


/js

-- 
Juergen Schoenwaelder =
          Jacobs =
University Bremen gGmbH
Phone: +49 421 200 3587 =
        Campus Ring 1 | 28759 =
Bremen | Germany
Fax:   +49 421 200 3103 =
        <https://www.jacobs-university.de/>



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_CCFEF47F-261B-4748-8EAE-C1B01440A43F--


From nobody Fri Mar 29 14:38:18 2019
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 58FD71202F5 for ; Fri, 29 Mar 2019 14:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b7DGHQNB6i4G for ; Fri, 29 Mar 2019 14:38:13 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 1F8841202C0 for ; Fri, 29 Mar 2019 14:38:13 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id g37so1607326plb.5 for ; Fri, 29 Mar 2019 14:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6XJ12zKPeWK4eFbX7gIqsb9ADtfxwrzTOHGGOU5UmXA=; b=pSPR0+N+yMxg4EMiZdWzQCZR5wbpTV2nyCYphClyQp/hZ9c5DNiI7wA/DTBYK7pNAe v/kF78cGHEOoJFaVVxyOEKGkDHFBsNw/BXOYnHf5tAepbqOketqpuGL1diBn23P92nzD dFJMDYSMW3mmQ3O3SOcj8aW6ejfKNvMVUWgkJSJOD97m/uqgI4dKtzqrV6ZkJFS7lttb 8PAAFcHZNrdG88gz2lcbr4BkuxugCAe2JOTMLV7n2dTuJ8AGli79ACABnfwZ0pzM1yXS ExC9xLHoDHIaWG3iP7CEO6UszEN5dI4+ADxWuDdxlOLdcptw1HvgRC1maDD3ZxBvsybZ N4LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6XJ12zKPeWK4eFbX7gIqsb9ADtfxwrzTOHGGOU5UmXA=; b=Du3HrDc6iO0rdbm/FjddBpax2geAP0Ru7xpTNcCET8BVIKM3bg8JIP0e1oOidSnBq6 /mr3cmdchSNIkCilqkZ+UBa47V2BRrep0cHWmC45mGKhbenTMGZQRWxmd9+z+Z/yf1tZ l+4Vc9sxxqXDSmsXCFQ8t2ddEErD09MpLUMjhVbMBu+A4NPBYuWoXqbnNCuS22g2rZ6P ZbXDA+NHBJ0VZ3deJTAuOlMpaSV0zrPz4QemNLqWMQkFkUrRp9oX+HC33v1IMgFQO5bh /kmfm+MCbSCo2ZtweKB/48BkUZEaGUT6D1x5QggADr8C0kkTxqlyhBfcsyYQ2QSe+sLD fMHQ==
X-Gm-Message-State: APjAAAVhPA3l4Qhy5EeradYF9U7qn4Y8r7uNa9zwr7J4Mk0PRe1eLbKU OXF2deYJZbKG5KWTWCU96C7UQVlQ
X-Google-Smtp-Source: APXvYqzJnRSaFdA8V0pWIvYwDRb79hM4VkZ693vEVZcJ/bsmv1OEWKRPvryF1xL3l8shGPBIAVjXWw==
X-Received: by 2002:a17:902:bb90:: with SMTP id m16mr52887502pls.49.1553895492570;  Fri, 29 Mar 2019 14:38:12 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id h65sm3743557pgc.93.2019.03.29.14.38.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 14:38:11 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_082B2769-7D62-4C1C-89AF-DC3F9059D5E7"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 29 Mar 2019 14:38:10 -0700
In-Reply-To: 
Cc: Juergen Schoenwaelder , NetMod WG 
To: Andy Bierman 
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>  <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de>  <20190329184624.4sg6lbasv5b5u4hw@anna.jacobs.jacobs-university.de> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 21:38:17 -0000

--Apple-Mail=_082B2769-7D62-4C1C-89AF-DC3F9059D5E7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Based on this discussion, I think we should reopen and change the title =
of this issue as =E2=80=9Cbinary encoding in YANG support=E2=80=9D, =
while I open a new issue in netconf-next for =E2=80=9Csupport for binary =
encoding in NETCONF=E2=80=9D.

> On Mar 29, 2019, at 11:57 AM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder =
> wrote:
> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de =
> wrote:
> >=20
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de =
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. =
I have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type =
binary {
> > > length 4; }. Doing this is only meaningful for some types but it =
would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow =
modelers to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in =
the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be =
tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only =
strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON =
both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to =
be
> > > used by XML or JSON. If you need binary encoding efficiency, use =
CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is =
worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, =
so it it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding =
and how the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > =
https://tools.ietf..org/html/draft-mahesh-netconf-binary-encoding-01 =

> > > >
> > > > For every type T that they agree on, there are standard T.b2y() =
and
> > > T.y2b()
> > > > conversion functions.
> > > > There are also some extensions to define conversion templates so =
vendors
> > > > can add their own types.
> > > >
> > > > The YANG modules do not need to actually be altered.  The peers =
will
> > > > negotiate the
> > > > set of types that will be sent as binary when the session =
starts.
> > > > The receiver knows T and the SID for each object, and will =
accept either
> > > > the YANG or binary encoding.
> > >
> > > Sounds complex for me to negotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length =
16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a =
binary
> > type.
> >
> > This forces all implementations of that type to support the binary =
variant.
> > That breaks old clients that worked with the version before the =
binary
> > variant.
> >=20
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the =
binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> >=20
>=20
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
>=20
>      typedef ipv4-address {
>        type string {
>          pattern
>            '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>          +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>        }
>        description
>          "The ipv4-address type represents an IPv4 address in
>           dotted-quad notation.";
>=20
>        binary-representation {
>          type binary {
>            length 4;
>          }
>          description
>            "The binary representation uses as 4-byte binary string
>             in network byte ordering.";
>        }
>      }
>=20
> The CBOR encoder (or other binary encoders) would then encode the
> value as a 4 byte binary value, the XML and JSON encoder would use the
> canonical string representation.  If the binary-representation is not
> specified, then the generic CBOR encoding rules apply. I assume that
> additional binary representation definitions will only be needed for a
> couple of types (and I might even be fine to restrict that to
> typedefs). Anyway, details need work, but if we want to support more
> efficient binary encodings, then I think we should keep the issue #46
> open.
>=20
>=20
>=20
> OK -- this is what I had in mind but off to the side, like a =
deviations module.
> If the client and server agree on the module containing the standard =
extension usages
> it will not be that complex in the protocol.
>=20
>   ex:binary-representation ietf-inet-types:ipv4-address {
>      ex:binary-length 4;
>      ex:binary-pattern "b0.b1.b2.b3";
>   }
>=20
> I agree YANG 1.2 should have real statements instead of extensions.
>=20
>=20
> =20
> /js
>=20
>=20
> Andy
>=20
> =20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_082B2769-7D62-4C1C-89AF-DC3F9059D5E7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Based=
 on this discussion, I think we should reopen and change the title of =
this issue as =E2=80=9Cbinary encoding in YANG support=E2=80=9D, while I =
open a new issue in netconf-next for =E2=80=9Csupport for binary =
encoding in NETCONF=E2=80=9D.

On Mar =
29, 2019, at 11:57 AM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Fri, Mar 29, 2019 at 11:46 AM Juergen =
Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Mar =
29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> On =
Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy =
Bierman wrote:
> > > On Fri, Mar 29, 2019 at 4:19 =
AM Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > > Hi,
> > > >
> > > > this is =
issue is closed but I wonder whether this is correct. I have
> > > > several questions looking at the issue on =
github:
> > > >
> > > =
> - Why is this not a YANG issue?
> > > > - =
Which workaround is better?
> > > > - Why is =
this tagged as a NETCONF issue?
> > > >
> > > >
> > > Did you mean =
this should be NETCONF issue?
> > > It is more of =
a protocol problem then a modeling problem.
> > > =
The goal is to use the model unaltered.
> >
> > I think it would be valuable if say the definition =
of ipv4-address
> > could state that a canonical =
binary representation is of type binary {
> > length =
4; }. Doing this is only meaningful for some types but it would
> > allow to add more binary representations over =
time.
> >
> > > > If we =
want to support binary encodings, we need to allow modelers to
> > > > define which types map to a canonical =
binary representation in
> > > > addition to =
the canonical string representation. As stated in the
> =
> > > issue description, hard-wiring some types in the =
encoding
> > > > specifications is very =
limited.
> > > >
> > > =
> In terms of backwards compatibility, this issue should IMHO be =
tagged
> > > > high (adding binary encoding =
for some types does not cause any
> > > > =
backwards compatibility problem since so far we have only strings).
> > > >
> > > >
> > > Not so sure.
> > > The =
base64 encoding could look like a valid string.
> > =
> The receiver must know a binary type is being sent (XML and JSON =
both
> > fail
> > > here, but =
not CBOR).
> >
> > I am talking =
about CBOR, not about XML or JSON. I want to provide
> =
> hints to CBOR (or similar binary encodings) that values can be
> > represented in a different format. I do not expect =
these hints to be
> > used by XML or JSON. If you =
need binary encoding efficiency, use CBOR
> > =
instead of JSON.
> >
> > > =
> While I do not have a solution proposal, I think this issue is =
worth
> > > > to look at and we should not =
close it right now.
> > > >
> =
> > >
> > > I have a solution proposal, =
but I have not implemented it yet, so it it
> > =
not
> > > detailed...
> > =
>
> > > Both sender and receiver need to agree =
on the binary encoding and how the
> > > data is =
tagged as binary.
> > >
> > =
> This expired draft should address that problem:
> =
> > https://tools.ietf..org/html/draft-mahesh-netconf-binary-encodi=
ng-01
> > >
> > > For =
every type T that they agree on, there are standard T.b2y() and
> > T.y2b()
> > > conversion =
functions.
> > > There are also some extensions =
to define conversion templates so vendors
> > > =
can add their own types.
> > >
> =
> > The YANG modules do not need to actually be altered.  The =
peers will
> > > negotiate the
> =
> > set of types that will be sent as binary when the session =
starts.
> > > The receiver knows T and the SID =
for each object, and will accept either
> > > the =
YANG or binary encoding.
> >
> > =
Sounds complex for me to negotiate this. I rather say once that a
> > binary encoding can ship an IPv6 address as type =
binary { length 16; }
> > and then CBOR will simply =
do the right thing.
> >
> >
> OK, but this would require new type names.
> You cannot simply change some standard type to be a =
union with a binary
> type.
>
> This forces all implementations of that type to support =
the binary variant.
> That breaks old clients that =
worked with the version before the binary
> variant.
> 
> The ripple effect on the models changing types would be =
non-trivial.
> Using this union-type approach forces =
every protocol to support the binary
> encoding,
> yet base64 in a union with strings is very =
error-prone.
> 

I am not proposing do change the type definitions we have. My =
idea was
to have an optional additional definition for =
binary encodings. Here
is an ad-hoc example (I do not like =
the details of the syntax, but
perhaps this helps to =
understand the idea):

    =
 typedef ipv4-address {
      =
 type string {
        =
 pattern
          =
 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
         +  =
'([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
 =
      }
      =
 description
         "The =
ipv4-address type represents an IPv4 address in
  =
        dotted-quad notation.";

      =
 binary-representation {
        =
 type binary {
          =
 length 4;
         }
         description
           "The binary =
representation uses as 4-byte binary string
    =
        in network byte =
ordering.";
       }
     }

The CBOR =
encoder (or other binary encoders) would then encode the
value as a 4 byte binary value, the XML and JSON encoder =
would use the
canonical string representation.  If =
the binary-representation is not
specified, then the =
generic CBOR encoding rules apply. I assume that
additional =
binary representation definitions will only be needed for a
couple of types (and I might even be fine to restrict that =
to
typedefs). Anyway, details need work, but if we want to =
support more
efficient binary encodings, then I think we =
should keep the issue #46
open.



OK -- this is what I had =
in mind but off to the side, like a deviations module.
If the client and server agree on the module containing the =
standard extension usages
it will not be that =
complex in the protocol.

  ex:binary-representation ietf-inet-types:ipv4-address =
{
     ex:binary-length 4;
     ex:binary-pattern =
"b0.b1.b2.b3";
  }

I agree YANG 1.2 should have real =
statements instead of extensions.


 
/js


Andy

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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_082B2769-7D62-4C1C-89AF-DC3F9059D5E7--


From nobody Fri Mar 29 15:27:04 2019
Return-Path: <01000169cb9038fe-447e56a9-ba5a-4bb4-8aaa-9ef946185702-000000@amazonses.watsen.net>
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 0E3DC1200A3 for ; Fri, 29 Mar 2019 15:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 zsYJeXPWXHZs for ; Fri, 29 Mar 2019 15:27:02 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE4A1200E0 for ; Fri, 29 Mar 2019 15:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553898420; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=9ADhqtmxWU3pTM6p0WGgID6xaHWMjYTMXS2vx9KvE9k=; b=hTim26ewqtBPghp/2taCOrweZ1jbQ26f6+Z7HPvLkDwtX2hKPcKWADxZ+fk4VJb+ 02OAIbdhHZkZ1tfoOZ6tz2hy6L21oPtDdprAvT4z+978FK9CCpWYowi3G065mTT9pxM utB2aTkAb+KU8ij0kZb8MyeEGpV76Zc5O/6rUcPY=
From: Kent Watsen 
Content-Type: multipart/alternative; boundary="Apple-Mail=_5945C597-70B2-4FCF-B66F-9D3B610A3D64"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-ID: <01000169cb9038fe-447e56a9-ba5a-4bb4-8aaa-9ef946185702-000000@email.amazonses.com>
Date: Fri, 29 Mar 2019 22:27:00 +0000
To: netmod@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.03.29-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: [netmod] minutes from Wednesday's YANG Next meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Mar 2019 22:27:04 -0000

--Apple-Mail=_5945C597-70B2-4FCF-B66F-9D3B610A3D64
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


Attendees:

  - Martin Bjorklund
  - Mahesh Jethanandani
  - Balazs Lengyel
  - Reshad Rahman
  - Xufeng Lu
  - Juergen Schoenwaelder
  - Kent Watsen
  - Robert Wilton
  - Qin Wu

We quickly scored four new issues, and then spent remaining time placing =
issues into four categories:

  - Definitely Dos (MUST Solve)
  - Further Discuss
  - If Time/Energy Left
  - Not Now

We are using a GitHub "Project" to help with this part of the analysis:
    - https://github.com/netmod-wg/yang-next/projects/2 =



Cheers,
Kent



--Apple-Mail=_5945C597-70B2-4FCF-B66F-9D3B610A3D64
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



Attendees:

  - Martin =
Bjorklund
  - Mahesh Jethanandani
  - Balazs Lengyel
  - Reshad Rahman
  - Xufeng =
Lu
  - Juergen Schoenwaelder
  - =
Kent Watsen
  - Robert =
Wilton
  - Qin Wu

We quickly scored four =
new issues, and then spent remaining time placing issues into four =
categories:

  - Definitely Dos (MUST Solve)
  - Further Discuss
  - If =
Time/Energy Left
  - Not Now

We are using a GitHub =
"Project" to help with this part of the analysis:
    - https://github.com/netmod-wg/yang-next/projects/2


Cheers,
Kent


=

--Apple-Mail=_5945C597-70B2-4FCF-B66F-9D3B610A3D64--


From nobody Sun Mar 31 03:32:14 2019
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 6C686120188 for ; Sun, 31 Mar 2019 03:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 zsoWSkJl6b30 for ; Sun, 31 Mar 2019 03:32:10 -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 A5CE912017B for ; Sun, 31 Mar 2019 03:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37170; q=dns/txt; s=iport; t=1554028329; x=1555237929; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uMWosl4URUnb+sYmaNBswpgTnELUAv0Qotuxvio5Sb0=; b=f+7ASCjPLb4smU2Juzj5OL4ddceqFGLwsWdXhL/4/JjSj6gnad1rJOHM eTjDhVoWngaC7nDgfVLUkCH5U6V7E5dAL3lvXBETsezl66PGIYFYs/arl 1737AZcHpgUkpr2kiFLUCOgR452Dp32LTa8ngRWky5YTCELMc6cX0GSZy U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAACJlqBc/5RdJa1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYEOgQJogQMnCoQElVOJOI8FgXsOAQE?= =?us-ascii?q?YAQqEA0YCF4UgIjUIDQEBAwEBCQEDAm0cDIVKAQEBBAEBIQpBCw4CAgEIDgI?= =?us-ascii?q?BBAEBASAHAwICAhkGBgsUCQgCBAENBQgTgwiBEUwDFQ+oSoEvhDUCg0INgho?= =?us-ascii?q?FBYEqAYsyF4FAP4ERgxI+ghpHAQEDgTcRLQoVEYJDglcDijkGgkGEI4IJkWg?= =?us-ascii?q?2CQKHb4gvgzgilCyLP4YRgTyMAQIRFYEuIAE2gVZwFRohgmyBZjAXg36EYYU?= =?us-ascii?q?/QTGODoEugR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,292,1549929600";  d="scan'208,217";a="252290077"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 10:32:08 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VAW7HZ026356 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 10:32:08 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 05:32:07 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Sun, 31 Mar 2019 05:32:07 -0500
From: "Rob Wilton (rwilton)" 
To: Mahesh Jethanandani , Andy Bierman 
CC: NetMod WG 
Thread-Topic: [netmod] yang next issue #46 binary encoding support
Thread-Index: AQHU5iFVCJpun3mXh0SXqXlmbRjEP6YjGoYAgAAC0YCAAAOdgIAAJgUAgAADHwCAACzfAIACFdEQ
Date: Sun, 31 Mar 2019 10:32:07 +0000
Message-ID: <24cd67f42eab465a90c33ff37ece5919@XCH-RCD-007.cisco.com>
References: <20190329111930.k2dt6wctsazxa7rp@anna.jacobs.jacobs-university.de>  <20190329161723.xuh3avyrdepdw3px@anna.jacobs.jacobs-university.de>  <20190329184624.4sg6lbasv5b5u4hw@anna.jacobs.jacobs-university.de>  
In-Reply-To: 
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.61.93.191]
Content-Type: multipart/alternative; boundary="_000_24cd67f42eab465a90c33ff37ece5919XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: 
Subject: Re: [netmod] yang next issue #46 binary encoding support
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Mar 2019 10:32:13 -0000

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

SSBhbHNvIGFncmVlIHRoYXQgd2Ugc2hvdWxkIHJlb3BlbiB0aGlzIGlzc3VlIHRvIGZ1cnRoZXIg
ZGlzY3VzcyBhbnkgbGFuZ3VhZ2UgaW1wbGljYXRpb25zLCBhbmQgYWRkIGl0IHRvIHRoZSDigJxG
dXJ0aGVyIERpc2N1c3PigJ0gYnVja2V0Lg0KDQpJIHN1Z2dlc3QgdGhhdCB3ZSBqdXN0IGRvIHRo
aXMsIHVubGVzcyBzb21lb25lIG9iamVjdHMuDQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IG5l
dG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFu
YW5kYW5pDQpTZW50OiAyOSBNYXJjaCAyMDE5IDIxOjM4DQpUbzogQW5keSBCaWVybWFuIDxhbmR5
QHl1bWF3b3Jrcy5jb20+DQpDYzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW25ldG1vZF0geWFuZyBuZXh0IGlzc3VlICM0NiBiaW5hcnkgZW5jb2Rpbmcgc3VwcG9y
dA0KDQpCYXNlZCBvbiB0aGlzIGRpc2N1c3Npb24sIEkgdGhpbmsgd2Ugc2hvdWxkIHJlb3BlbiBh
bmQgY2hhbmdlIHRoZSB0aXRsZSBvZiB0aGlzIGlzc3VlIGFzIOKAnGJpbmFyeSBlbmNvZGluZyBp
biBZQU5HIHN1cHBvcnTigJ0sIHdoaWxlIEkgb3BlbiBhIG5ldyBpc3N1ZSBpbiBuZXRjb25mLW5l
eHQgZm9yIOKAnHN1cHBvcnQgZm9yIGJpbmFyeSBlbmNvZGluZyBpbiBORVRDT05G4oCdLg0KDQoN
Ck9uIE1hciAyOSwgMjAxOSwgYXQgMTE6NTcgQU0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29y
a3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90ZToNCg0KDQpPbiBGcmksIE1h
ciAyOSwgMjAxOSBhdCAxMTo0NiBBTSBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2Fl
bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11
bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBGcmksIE1hciAyOSwgMjAxOSBhdCAwOTozMDoxOUFN
IC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+IE9uIEZyaSwgTWFyIDI5LCAyMDE5IGF0IDk6
MTcgQU0gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDwNCj4gai5zY2hvZW53YWVsZGVyQGphY29icy11
bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+
PiB3cm90ZToNCj4NCj4gPiBPbiBGcmksIE1hciAyOSwgMjAxOSBhdCAwOTowNzoxOEFNIC0wNzAw
LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4gPiBPbiBGcmksIE1hciAyOSwgMjAxOSBhdCA0OjE5
IEFNIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8DQo+ID4gPiBqLnNjaG9lbndhZWxkZXJAamFjb2Jz
LXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k
ZT4+IHdyb3RlOg0KPiA+ID4NCj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IHRoaXMgaXMg
aXNzdWUgaXMgY2xvc2VkIGJ1dCBJIHdvbmRlciB3aGV0aGVyIHRoaXMgaXMgY29ycmVjdC4gSSBo
YXZlDQo+ID4gPiA+IHNldmVyYWwgcXVlc3Rpb25zIGxvb2tpbmcgYXQgdGhlIGlzc3VlIG9uIGdp
dGh1YjoNCj4gPiA+ID4NCj4gPiA+ID4gLSBXaHkgaXMgdGhpcyBub3QgYSBZQU5HIGlzc3VlPw0K
PiA+ID4gPiAtIFdoaWNoIHdvcmthcm91bmQgaXMgYmV0dGVyPw0KPiA+ID4gPiAtIFdoeSBpcyB0
aGlzIHRhZ2dlZCBhcyBhIE5FVENPTkYgaXNzdWU/DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiBE
aWQgeW91IG1lYW4gdGhpcyBzaG91bGQgYmUgTkVUQ09ORiBpc3N1ZT8NCj4gPiA+IEl0IGlzIG1v
cmUgb2YgYSBwcm90b2NvbCBwcm9ibGVtIHRoZW4gYSBtb2RlbGluZyBwcm9ibGVtLg0KPiA+ID4g
VGhlIGdvYWwgaXMgdG8gdXNlIHRoZSBtb2RlbCB1bmFsdGVyZWQuDQo+ID4NCj4gPiBJIHRoaW5r
IGl0IHdvdWxkIGJlIHZhbHVhYmxlIGlmIHNheSB0aGUgZGVmaW5pdGlvbiBvZiBpcHY0LWFkZHJl
c3MNCj4gPiBjb3VsZCBzdGF0ZSB0aGF0IGEgY2Fub25pY2FsIGJpbmFyeSByZXByZXNlbnRhdGlv
biBpcyBvZiB0eXBlIGJpbmFyeSB7DQo+ID4gbGVuZ3RoIDQ7IH0uIERvaW5nIHRoaXMgaXMgb25s
eSBtZWFuaW5nZnVsIGZvciBzb21lIHR5cGVzIGJ1dCBpdCB3b3VsZA0KPiA+IGFsbG93IHRvIGFk
ZCBtb3JlIGJpbmFyeSByZXByZXNlbnRhdGlvbnMgb3ZlciB0aW1lLg0KPiA+DQo+ID4gPiA+IElm
IHdlIHdhbnQgdG8gc3VwcG9ydCBiaW5hcnkgZW5jb2RpbmdzLCB3ZSBuZWVkIHRvIGFsbG93IG1v
ZGVsZXJzIHRvDQo+ID4gPiA+IGRlZmluZSB3aGljaCB0eXBlcyBtYXAgdG8gYSBjYW5vbmljYWwg
YmluYXJ5IHJlcHJlc2VudGF0aW9uIGluDQo+ID4gPiA+IGFkZGl0aW9uIHRvIHRoZSBjYW5vbmlj
YWwgc3RyaW5nIHJlcHJlc2VudGF0aW9uLiBBcyBzdGF0ZWQgaW4gdGhlDQo+ID4gPiA+IGlzc3Vl
IGRlc2NyaXB0aW9uLCBoYXJkLXdpcmluZyBzb21lIHR5cGVzIGluIHRoZSBlbmNvZGluZw0KPiA+
ID4gPiBzcGVjaWZpY2F0aW9ucyBpcyB2ZXJ5IGxpbWl0ZWQuDQo+ID4gPiA+DQo+ID4gPiA+IElu
IHRlcm1zIG9mIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LCB0aGlzIGlzc3VlIHNob3VsZCBJTUhP
IGJlIHRhZ2dlZA0KPiA+ID4gPiBoaWdoIChhZGRpbmcgYmluYXJ5IGVuY29kaW5nIGZvciBzb21l
IHR5cGVzIGRvZXMgbm90IGNhdXNlIGFueQ0KPiA+ID4gPiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0
eSBwcm9ibGVtIHNpbmNlIHNvIGZhciB3ZSBoYXZlIG9ubHkgc3RyaW5ncykuDQo+ID4gPiA+DQo+
ID4gPiA+DQo+ID4gPiBOb3Qgc28gc3VyZS4NCj4gPiA+IFRoZSBiYXNlNjQgZW5jb2RpbmcgY291
bGQgbG9vayBsaWtlIGEgdmFsaWQgc3RyaW5nLg0KPiA+ID4gVGhlIHJlY2VpdmVyIG11c3Qga25v
dyBhIGJpbmFyeSB0eXBlIGlzIGJlaW5nIHNlbnQgKFhNTCBhbmQgSlNPTiBib3RoDQo+ID4gZmFp
bA0KPiA+ID4gaGVyZSwgYnV0IG5vdCBDQk9SKS4NCj4gPg0KPiA+IEkgYW0gdGFsa2luZyBhYm91
dCBDQk9SLCBub3QgYWJvdXQgWE1MIG9yIEpTT04uIEkgd2FudCB0byBwcm92aWRlDQo+ID4gaGlu
dHMgdG8gQ0JPUiAob3Igc2ltaWxhciBiaW5hcnkgZW5jb2RpbmdzKSB0aGF0IHZhbHVlcyBjYW4g
YmUNCj4gPiByZXByZXNlbnRlZCBpbiBhIGRpZmZlcmVudCBmb3JtYXQuIEkgZG8gbm90IGV4cGVj
dCB0aGVzZSBoaW50cyB0byBiZQ0KPiA+IHVzZWQgYnkgWE1MIG9yIEpTT04uIElmIHlvdSBuZWVk
IGJpbmFyeSBlbmNvZGluZyBlZmZpY2llbmN5LCB1c2UgQ0JPUg0KPiA+IGluc3RlYWQgb2YgSlNP
Ti4NCj4gPg0KPiA+ID4gPiBXaGlsZSBJIGRvIG5vdCBoYXZlIGEgc29sdXRpb24gcHJvcG9zYWws
IEkgdGhpbmsgdGhpcyBpc3N1ZSBpcyB3b3J0aA0KPiA+ID4gPiB0byBsb29rIGF0IGFuZCB3ZSBz
aG91bGQgbm90IGNsb3NlIGl0IHJpZ2h0IG5vdy4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+IEkg
aGF2ZSBhIHNvbHV0aW9uIHByb3Bvc2FsLCBidXQgSSBoYXZlIG5vdCBpbXBsZW1lbnRlZCBpdCB5
ZXQsIHNvIGl0IGl0DQo+ID4gbm90DQo+ID4gPiBkZXRhaWxlZC4uLg0KPiA+ID4NCj4gPiA+IEJv
dGggc2VuZGVyIGFuZCByZWNlaXZlciBuZWVkIHRvIGFncmVlIG9uIHRoZSBiaW5hcnkgZW5jb2Rp
bmcgYW5kIGhvdyB0aGUNCj4gPiA+IGRhdGEgaXMgdGFnZ2VkIGFzIGJpbmFyeS4NCj4gPiA+DQo+
ID4gPiBUaGlzIGV4cGlyZWQgZHJhZnQgc2hvdWxkIGFkZHJlc3MgdGhhdCBwcm9ibGVtOg0KPiA+
ID4gaHR0cHM6Ly90b29scy5pZXRmLi5vcmcvaHRtbC9kcmFmdC1tYWhlc2gtbmV0Y29uZi1iaW5h
cnktZW5jb2RpbmctMDE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1haGVzaC1u
ZXRjb25mLWJpbmFyeS1lbmNvZGluZy0wMT4NCj4gPiA+DQo+ID4gPiBGb3IgZXZlcnkgdHlwZSBU
IHRoYXQgdGhleSBhZ3JlZSBvbiwgdGhlcmUgYXJlIHN0YW5kYXJkIFQuYjJ5KCkgYW5kDQo+ID4g
VC55MmIoKQ0KPiA+ID4gY29udmVyc2lvbiBmdW5jdGlvbnMuDQo+ID4gPiBUaGVyZSBhcmUgYWxz
byBzb21lIGV4dGVuc2lvbnMgdG8gZGVmaW5lIGNvbnZlcnNpb24gdGVtcGxhdGVzIHNvIHZlbmRv
cnMNCj4gPiA+IGNhbiBhZGQgdGhlaXIgb3duIHR5cGVzLg0KPiA+ID4NCj4gPiA+IFRoZSBZQU5H
IG1vZHVsZXMgZG8gbm90IG5lZWQgdG8gYWN0dWFsbHkgYmUgYWx0ZXJlZC4gIFRoZSBwZWVycyB3
aWxsDQo+ID4gPiBuZWdvdGlhdGUgdGhlDQo+ID4gPiBzZXQgb2YgdHlwZXMgdGhhdCB3aWxsIGJl
IHNlbnQgYXMgYmluYXJ5IHdoZW4gdGhlIHNlc3Npb24gc3RhcnRzLg0KPiA+ID4gVGhlIHJlY2Vp
dmVyIGtub3dzIFQgYW5kIHRoZSBTSUQgZm9yIGVhY2ggb2JqZWN0LCBhbmQgd2lsbCBhY2NlcHQg
ZWl0aGVyDQo+ID4gPiB0aGUgWUFORyBvciBiaW5hcnkgZW5jb2RpbmcuDQo+ID4NCj4gPiBTb3Vu
ZHMgY29tcGxleCBmb3IgbWUgdG8gbmVnb3RpYXRlIHRoaXMuIEkgcmF0aGVyIHNheSBvbmNlIHRo
YXQgYQ0KPiA+IGJpbmFyeSBlbmNvZGluZyBjYW4gc2hpcCBhbiBJUHY2IGFkZHJlc3MgYXMgdHlw
ZSBiaW5hcnkgeyBsZW5ndGggMTY7IH0NCj4gPiBhbmQgdGhlbiBDQk9SIHdpbGwgc2ltcGx5IGRv
IHRoZSByaWdodCB0aGluZy4NCj4gPg0KPiA+DQo+IE9LLCBidXQgdGhpcyB3b3VsZCByZXF1aXJl
IG5ldyB0eXBlIG5hbWVzLg0KPiBZb3UgY2Fubm90IHNpbXBseSBjaGFuZ2Ugc29tZSBzdGFuZGFy
ZCB0eXBlIHRvIGJlIGEgdW5pb24gd2l0aCBhIGJpbmFyeQ0KPiB0eXBlLg0KPg0KPiBUaGlzIGZv
cmNlcyBhbGwgaW1wbGVtZW50YXRpb25zIG9mIHRoYXQgdHlwZSB0byBzdXBwb3J0IHRoZSBiaW5h
cnkgdmFyaWFudC4NCj4gVGhhdCBicmVha3Mgb2xkIGNsaWVudHMgdGhhdCB3b3JrZWQgd2l0aCB0
aGUgdmVyc2lvbiBiZWZvcmUgdGhlIGJpbmFyeQ0KPiB2YXJpYW50Lg0KPg0KPiBUaGUgcmlwcGxl
IGVmZmVjdCBvbiB0aGUgbW9kZWxzIGNoYW5naW5nIHR5cGVzIHdvdWxkIGJlIG5vbi10cml2aWFs
Lg0KPiBVc2luZyB0aGlzIHVuaW9uLXR5cGUgYXBwcm9hY2ggZm9yY2VzIGV2ZXJ5IHByb3RvY29s
IHRvIHN1cHBvcnQgdGhlIGJpbmFyeQ0KPiBlbmNvZGluZywNCj4geWV0IGJhc2U2NCBpbiBhIHVu
aW9uIHdpdGggc3RyaW5ncyBpcyB2ZXJ5IGVycm9yLXByb25lLg0KPg0KDQpJIGFtIG5vdCBwcm9w
b3NpbmcgZG8gY2hhbmdlIHRoZSB0eXBlIGRlZmluaXRpb25zIHdlIGhhdmUuIE15IGlkZWEgd2Fz
DQp0byBoYXZlIGFuIG9wdGlvbmFsIGFkZGl0aW9uYWwgZGVmaW5pdGlvbiBmb3IgYmluYXJ5IGVu
Y29kaW5ncy4gSGVyZQ0KaXMgYW4gYWQtaG9jIGV4YW1wbGUgKEkgZG8gbm90IGxpa2UgdGhlIGRl
dGFpbHMgb2YgdGhlIHN5bnRheCwgYnV0DQpwZXJoYXBzIHRoaXMgaGVscHMgdG8gdW5kZXJzdGFu
ZCB0aGUgaWRlYSk6DQoNCiAgICAgdHlwZWRlZiBpcHY0LWFkZHJlc3Mgew0KICAgICAgIHR5cGUg
c3RyaW5nIHsNCiAgICAgICAgIHBhdHRlcm4NCiAgICAgICAgICAgJygoWzAtOV18WzEtOV1bMC05
XXwxWzAtOV1bMC05XXwyWzAtNF1bMC05XXwyNVswLTVdKVwuKXszfScNCiAgICAgICAgICsgICco
WzAtOV18WzEtOV1bMC05XXwxWzAtOV1bMC05XXwyWzAtNF1bMC05XXwyNVswLTVdKSc7DQogICAg
ICAgfQ0KICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAiVGhlIGlwdjQtYWRkcmVzcyB0eXBl
IHJlcHJlc2VudHMgYW4gSVB2NCBhZGRyZXNzIGluDQogICAgICAgICAgZG90dGVkLXF1YWQgbm90
YXRpb24uIjsNCg0KICAgICAgIGJpbmFyeS1yZXByZXNlbnRhdGlvbiB7DQogICAgICAgICB0eXBl
IGJpbmFyeSB7DQogICAgICAgICAgIGxlbmd0aCA0Ow0KICAgICAgICAgfQ0KICAgICAgICAgZGVz
Y3JpcHRpb24NCiAgICAgICAgICAgIlRoZSBiaW5hcnkgcmVwcmVzZW50YXRpb24gdXNlcyBhcyA0
LWJ5dGUgYmluYXJ5IHN0cmluZw0KICAgICAgICAgICAgaW4gbmV0d29yayBieXRlIG9yZGVyaW5n
LiI7DQogICAgICAgfQ0KICAgICB9DQoNClRoZSBDQk9SIGVuY29kZXIgKG9yIG90aGVyIGJpbmFy
eSBlbmNvZGVycykgd291bGQgdGhlbiBlbmNvZGUgdGhlDQp2YWx1ZSBhcyBhIDQgYnl0ZSBiaW5h
cnkgdmFsdWUsIHRoZSBYTUwgYW5kIEpTT04gZW5jb2RlciB3b3VsZCB1c2UgdGhlDQpjYW5vbmlj
YWwgc3RyaW5nIHJlcHJlc2VudGF0aW9uLiAgSWYgdGhlIGJpbmFyeS1yZXByZXNlbnRhdGlvbiBp
cyBub3QNCnNwZWNpZmllZCwgdGhlbiB0aGUgZ2VuZXJpYyBDQk9SIGVuY29kaW5nIHJ1bGVzIGFw
cGx5LiBJIGFzc3VtZSB0aGF0DQphZGRpdGlvbmFsIGJpbmFyeSByZXByZXNlbnRhdGlvbiBkZWZp
bml0aW9ucyB3aWxsIG9ubHkgYmUgbmVlZGVkIGZvciBhDQpjb3VwbGUgb2YgdHlwZXMgKGFuZCBJ
IG1pZ2h0IGV2ZW4gYmUgZmluZSB0byByZXN0cmljdCB0aGF0IHRvDQp0eXBlZGVmcykuIEFueXdh
eSwgZGV0YWlscyBuZWVkIHdvcmssIGJ1dCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQgbW9yZQ0KZWZm
aWNpZW50IGJpbmFyeSBlbmNvZGluZ3MsIHRoZW4gSSB0aGluayB3ZSBzaG91bGQga2VlcCB0aGUg
aXNzdWUgIzQ2DQpvcGVuLg0KDQoNCk9LIC0tIHRoaXMgaXMgd2hhdCBJIGhhZCBpbiBtaW5kIGJ1
dCBvZmYgdG8gdGhlIHNpZGUsIGxpa2UgYSBkZXZpYXRpb25zIG1vZHVsZS4NCklmIHRoZSBjbGll
bnQgYW5kIHNlcnZlciBhZ3JlZSBvbiB0aGUgbW9kdWxlIGNvbnRhaW5pbmcgdGhlIHN0YW5kYXJk
IGV4dGVuc2lvbiB1c2FnZXMNCml0IHdpbGwgbm90IGJlIHRoYXQgY29tcGxleCBpbiB0aGUgcHJv
dG9jb2wuDQoNCiAgZXg6YmluYXJ5LXJlcHJlc2VudGF0aW9uIGlldGYtaW5ldC10eXBlczppcHY0
LWFkZHJlc3Mgew0KICAgICBleDpiaW5hcnktbGVuZ3RoIDQ7DQogICAgIGV4OmJpbmFyeS1wYXR0
ZXJuICJiMC5iMS5iMi5iMyI7DQogIH0NCg0KSSBhZ3JlZSBZQU5HIDEuMiBzaG91bGQgaGF2ZSBy
ZWFsIHN0YXRlbWVudHMgaW5zdGVhZCBvZiBleHRlbnNpb25zLg0KDQoNCg0KL2pzDQoNCkFuZHkN
Cg0KDQotLQ0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0
eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp
bmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAg
ICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpu
ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRo
YW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoN
Cg==

--_000_24cd67f42eab465a90c33ff37ece5919XCHRCD007ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l
Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw
YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl
ZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE
O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0
Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgYWxzbyBhZ3JlZSB0aGF0IHdlIHNob3VsZCByZW9wZW4g
dGhpcyBpc3N1ZSB0byBmdXJ0aGVyIGRpc2N1c3MgYW55IGxhbmd1YWdlIGltcGxpY2F0aW9ucywg
YW5kIGFkZCBpdCB0byB0aGUg4oCcRnVydGhlciBEaXNjdXNz4oCdIGJ1Y2tldC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc3VnZ2VzdCB0aGF0IHdlIGp1c3QgZG8g
dGhpcywgdW5sZXNzIHNvbWVvbmUgb2JqZWN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+Um9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj4gbmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxi
Pk9uIEJlaGFsZiBPZiA8L2I+TWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCjxiPlNlbnQ6PC9iPiAy
OSBNYXJjaCAyMDE5IDIxOjM4PGJyPg0KPGI+VG86PC9iPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlA
eXVtYXdvcmtzLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldE1vZCBXRyAmbHQ7bmV0bW9kQGll
dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0geWFuZyBuZXh0IGlz
c3VlICM0NiBiaW5hcnkgZW5jb2Rpbmcgc3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhc2VkIG9uIHRoaXMgZGlzY3Vzc2lvbiwgSSB0aGluayB3
ZSBzaG91bGQgcmVvcGVuIGFuZCBjaGFuZ2UgdGhlIHRpdGxlIG9mIHRoaXMgaXNzdWUgYXMg4oCc
YmluYXJ5IGVuY29kaW5nIGluIFlBTkcgc3VwcG9ydOKAnSwgd2hpbGUgSSBvcGVuIGEgbmV3IGlz
c3VlIGluIG5ldGNvbmYtbmV4dCBmb3Ig4oCcc3VwcG9ydCBmb3IgYmluYXJ5IGVuY29kaW5nIGlu
IE5FVENPTkbigJ0uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBNYXIgMjksIDIwMTksIGF0IDExOjU3IEFNLCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9
Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPk9uIEZyaSwgTWFyIDI5LCAyMDE5IGF0IDExOjQ2IEFNIEp1ZXJnZW4gU2Nob2Vu
d2FlbGRlciAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2Jz
LXVuaXZlcnNpdHkuZGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KIHdyb3RlOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEZyaSwgTWFyIDI5LCAyMDE5IGF0
IDA5OjMwOjE5QU0gLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+DQomZ3Q7IE9uIEZyaSwg
TWFyIDI5LCAyMDE5IGF0IDk6MTcgQU0gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YnI+DQom
Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh
bj48YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0
YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ai5zY2hvZW53YWVsZGVyQGphY29icy11
bml2ZXJzaXR5LmRlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQogd3JvdGU6PGJy
Pg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
YnI+DQomZ3Q7ICZndDsgT24gRnJpLCBNYXIgMjksIDIwMTkgYXQgMDk6MDc6MThBTSAtMDcwMCwg
QW5keSBCaWVybWFuIHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIEZyaSwgTWFyIDI5LCAy
MDE5IGF0IDQ6MTkgQU0gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YnI+DQomZ3Q7ICZndDsg
Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KIHdyb3RlOjxi
cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGlzIGlzIGlzc3VlIGlz
IGNsb3NlZCBidXQgSSB3b25kZXIgd2hldGhlciB0aGlzIGlzIGNvcnJlY3QuIEkgaGF2ZTxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgc2V2ZXJhbCBxdWVzdGlvbnMgbG9va2luZyBhdCB0aGUgaXNz
dWUgb24gZ2l0aHViOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IC0gV2h5IGlzIHRoaXMgbm90IGEgWUFORyBpc3N1ZT88YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IC0gV2hpY2ggd29ya2Fyb3VuZCBpcyBiZXR0ZXI/PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAtIFdoeSBpcyB0aGlzIHRhZ2dlZCBhcyBhIE5FVENPTkYgaXNzdWU/PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0
OyBEaWQgeW91IG1lYW4gdGhpcyBzaG91bGQgYmUgTkVUQ09ORiBpc3N1ZT88YnI+DQomZ3Q7ICZn
dDsgJmd0OyBJdCBpcyBtb3JlIG9mIGEgcHJvdG9jb2wgcHJvYmxlbSB0aGVuIGEgbW9kZWxpbmcg
cHJvYmxlbS48YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgZ29hbCBpcyB0byB1c2UgdGhlIG1vZGVs
IHVuYWx0ZXJlZC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSB0aGluayBpdCB3b3Vs
ZCBiZSB2YWx1YWJsZSBpZiBzYXkgdGhlIGRlZmluaXRpb24gb2YgaXB2NC1hZGRyZXNzPGJyPg0K
Jmd0OyAmZ3Q7IGNvdWxkIHN0YXRlIHRoYXQgYSBjYW5vbmljYWwgYmluYXJ5IHJlcHJlc2VudGF0
aW9uIGlzIG9mIHR5cGUgYmluYXJ5IHs8YnI+DQomZ3Q7ICZndDsgbGVuZ3RoIDQ7IH0uIERvaW5n
IHRoaXMgaXMgb25seSBtZWFuaW5nZnVsIGZvciBzb21lIHR5cGVzIGJ1dCBpdCB3b3VsZDxicj4N
CiZndDsgJmd0OyBhbGxvdyB0byBhZGQgbW9yZSBiaW5hcnkgcmVwcmVzZW50YXRpb25zIG92ZXIg
dGltZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElmIHdlIHdhbnQg
dG8gc3VwcG9ydCBiaW5hcnkgZW5jb2RpbmdzLCB3ZSBuZWVkIHRvIGFsbG93IG1vZGVsZXJzIHRv
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBkZWZpbmUgd2hpY2ggdHlwZXMgbWFwIHRvIGEgY2Fu
b25pY2FsIGJpbmFyeSByZXByZXNlbnRhdGlvbiBpbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
YWRkaXRpb24gdG8gdGhlIGNhbm9uaWNhbCBzdHJpbmcgcmVwcmVzZW50YXRpb24uIEFzIHN0YXRl
ZCBpbiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGlzc3VlIGRlc2NyaXB0aW9uLCBoYXJk
LXdpcmluZyBzb21lIHR5cGVzIGluIHRoZSBlbmNvZGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgc3BlY2lmaWNhdGlvbnMgaXMgdmVyeSBsaW1pdGVkLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIHRlcm1zIG9mIGJhY2t3YXJkcyBjb21wYXRp
YmlsaXR5LCB0aGlzIGlzc3VlIHNob3VsZCBJTUhPIGJlIHRhZ2dlZDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgaGlnaCAoYWRkaW5nIGJpbmFyeSBlbmNvZGluZyBmb3Igc29tZSB0eXBlcyBkb2Vz
IG5vdCBjYXVzZSBhbnk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJhY2t3YXJkcyBjb21wYXRp
YmlsaXR5IHByb2JsZW0gc2luY2Ugc28gZmFyIHdlIGhhdmUgb25seSBzdHJpbmdzKS48YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7IE5vdCBzbyBzdXJlLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSBiYXNlNjQgZW5jb2Rp
bmcgY291bGQgbG9vayBsaWtlIGEgdmFsaWQgc3RyaW5nLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRo
ZSByZWNlaXZlciBtdXN0IGtub3cgYSBiaW5hcnkgdHlwZSBpcyBiZWluZyBzZW50IChYTUwgYW5k
IEpTT04gYm90aDxicj4NCiZndDsgJmd0OyBmYWlsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaGVyZSwg
YnV0IG5vdCBDQk9SKS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhbSB0YWxraW5n
IGFib3V0IENCT1IsIG5vdCBhYm91dCBYTUwgb3IgSlNPTi4gSSB3YW50IHRvIHByb3ZpZGU8YnI+
DQomZ3Q7ICZndDsgaGludHMgdG8gQ0JPUiAob3Igc2ltaWxhciBiaW5hcnkgZW5jb2RpbmdzKSB0
aGF0IHZhbHVlcyBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgcmVwcmVzZW50ZWQgaW4gYSBkaWZmZXJl
bnQgZm9ybWF0LiBJIGRvIG5vdCBleHBlY3QgdGhlc2UgaGludHMgdG8gYmU8YnI+DQomZ3Q7ICZn
dDsgdXNlZCBieSBYTUwgb3IgSlNPTi4gSWYgeW91IG5lZWQgYmluYXJ5IGVuY29kaW5nIGVmZmlj
aWVuY3ksIHVzZSBDQk9SPGJyPg0KJmd0OyAmZ3Q7IGluc3RlYWQgb2YgSlNPTi48YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFdoaWxlIEkgZG8gbm90IGhhdmUgYSBzb2x1
dGlvbiBwcm9wb3NhbCwgSSB0aGluayB0aGlzIGlzc3VlIGlzIHdvcnRoPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyB0byBsb29rIGF0IGFuZCB3ZSBzaG91bGQgbm90IGNsb3NlIGl0IHJpZ2h0IG5v
dy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4N
CiZndDsgJmd0OyAmZ3Q7IEkgaGF2ZSBhIHNvbHV0aW9uIHByb3Bvc2FsLCBidXQgSSBoYXZlIG5v
dCBpbXBsZW1lbnRlZCBpdCB5ZXQsIHNvIGl0IGl0PGJyPg0KJmd0OyAmZ3Q7IG5vdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGRldGFpbGVkLi4uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBCb3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIgbmVlZCB0byBhZ3JlZSBvbiB0aGUgYmlu
YXJ5IGVuY29kaW5nIGFuZCBob3cgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGF0YSBpcyB0YWdn
ZWQgYXMgYmluYXJ5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhp
cyBleHBpcmVkIGRyYWZ0IHNob3VsZCBhZGRyZXNzIHRoYXQgcHJvYmxlbTo8YnI+DQomZ3Q7ICZn
dDsgJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1haGVzaC1u
ZXRjb25mLWJpbmFyeS1lbmNvZGluZy0wMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPmh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwvZHJhZnQtbWFoZXNoLW5ldGNvbmYtYmlu
YXJ5LWVuY29kaW5nLTAxPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQomZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEZvciBldmVyeSB0eXBlIFQgdGhhdCB0aGV5IGFn
cmVlIG9uLCB0aGVyZSBhcmUgc3RhbmRhcmQgVC5iMnkoKSBhbmQ8YnI+DQomZ3Q7ICZndDsgVC55
MmIoKTxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbnZlcnNpb24gZnVuY3Rpb25zLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7IFRoZXJlIGFyZSBhbHNvIHNvbWUgZXh0ZW5zaW9ucyB0byBkZWZpbmUgY29udmVy
c2lvbiB0ZW1wbGF0ZXMgc28gdmVuZG9yczxicj4NCiZndDsgJmd0OyAmZ3Q7IGNhbiBhZGQgdGhl
aXIgb3duIHR5cGVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhl
IFlBTkcgbW9kdWxlcyBkbyBub3QgbmVlZCB0byBhY3R1YWxseSBiZSBhbHRlcmVkLiZuYnNwOyBU
aGUgcGVlcnMgd2lsbDxicj4NCiZndDsgJmd0OyAmZ3Q7IG5lZ290aWF0ZSB0aGU8YnI+DQomZ3Q7
ICZndDsgJmd0OyBzZXQgb2YgdHlwZXMgdGhhdCB3aWxsIGJlIHNlbnQgYXMgYmluYXJ5IHdoZW4g
dGhlIHNlc3Npb24gc3RhcnRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSByZWNlaXZlciBrbm93
cyBUIGFuZCB0aGUgU0lEIGZvciBlYWNoIG9iamVjdCwgYW5kIHdpbGwgYWNjZXB0IGVpdGhlcjxi
cj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBZQU5HIG9yIGJpbmFyeSBlbmNvZGluZy48YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDsgU291bmRzIGNvbXBsZXggZm9yIG1lIHRvIG5lZ290aWF0ZSB0
aGlzLiBJIHJhdGhlciBzYXkgb25jZSB0aGF0IGE8YnI+DQomZ3Q7ICZndDsgYmluYXJ5IGVuY29k
aW5nIGNhbiBzaGlwIGFuIElQdjYgYWRkcmVzcyBhcyB0eXBlIGJpbmFyeSB7IGxlbmd0aCAxNjsg
fTxicj4NCiZndDsgJmd0OyBhbmQgdGhlbiBDQk9SIHdpbGwgc2ltcGx5IGRvIHRoZSByaWdodCB0
aGluZy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IE9LLCBidXQgdGhp
cyB3b3VsZCByZXF1aXJlIG5ldyB0eXBlIG5hbWVzLjxicj4NCiZndDsgWW91IGNhbm5vdCBzaW1w
bHkgY2hhbmdlIHNvbWUgc3RhbmRhcmQgdHlwZSB0byBiZSBhIHVuaW9uIHdpdGggYSBiaW5hcnk8
YnI+DQomZ3Q7IHR5cGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBmb3JjZXMgYWxsIGltcGxl
bWVudGF0aW9ucyBvZiB0aGF0IHR5cGUgdG8gc3VwcG9ydCB0aGUgYmluYXJ5IHZhcmlhbnQuPGJy
Pg0KJmd0OyBUaGF0IGJyZWFrcyBvbGQgY2xpZW50cyB0aGF0IHdvcmtlZCB3aXRoIHRoZSB2ZXJz
aW9uIGJlZm9yZSB0aGUgYmluYXJ5PGJyPg0KJmd0OyB2YXJpYW50Ljxicj4NCiZndDs8c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBUaGUg
cmlwcGxlIGVmZmVjdCBvbiB0aGUgbW9kZWxzIGNoYW5naW5nIHR5cGVzIHdvdWxkIGJlIG5vbi10
cml2aWFsLjxicj4NCiZndDsgVXNpbmcgdGhpcyB1bmlvbi10eXBlIGFwcHJvYWNoIGZvcmNlcyBl
dmVyeSBwcm90b2NvbCB0byBzdXBwb3J0IHRoZSBiaW5hcnk8YnI+DQomZ3Q7IGVuY29kaW5nLDxi
cj4NCiZndDsgeWV0IGJhc2U2NCBpbiBhIHVuaW9uIHdpdGggc3RyaW5ncyBpcyB2ZXJ5IGVycm9y
LXByb25lLjxicj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGJyPg0KPGJyPg0KSSBhbSBub3QgcHJvcG9zaW5nIGRvIGNoYW5nZSB0aGUgdHlw
ZSBkZWZpbml0aW9ucyB3ZSBoYXZlLiBNeSBpZGVhIHdhczxicj4NCnRvIGhhdmUgYW4gb3B0aW9u
YWwgYWRkaXRpb25hbCBkZWZpbml0aW9uIGZvciBiaW5hcnkgZW5jb2RpbmdzLiBIZXJlPGJyPg0K
aXMgYW4gYWQtaG9jIGV4YW1wbGUgKEkgZG8gbm90IGxpa2UgdGhlIGRldGFpbHMgb2YgdGhlIHN5
bnRheCwgYnV0PGJyPg0KcGVyaGFwcyB0aGlzIGhlbHBzIHRvIHVuZGVyc3RhbmQgdGhlIGlkZWEp
Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZWRlZiBpcHY0LWFkZHJlc3Mgezxi
cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgc3RyaW5nIHs8YnI+DQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF0dGVybjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JygoWzAtOV18WzEtOV1bMC05XXwxWzAtOV1bMC05XXwy
WzAtNF1bMC05XXwyNVswLTVdKVwuKXszfSc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7JiM0MzsmbmJzcDsgJyhbMC05XXxbMS05XVswLTldfDFbMC05XVswLTldfDJbMC00
XVswLTldfDI1WzAtNV0pJzs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb248YnI+DQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7VGhlIGlwdjQtYWRkcmVzcyB0eXBlIHJlcHJlc2Vu
dHMgYW4gSVB2NCBhZGRyZXNzIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kb3R0
ZWQtcXVhZCBub3RhdGlvbi4mcXVvdDs7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7YmluYXJ5LXJlcHJlc2VudGF0aW9uIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7dHlwZSBiaW5hcnkgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7bGVuZ3RoIDQ7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO308YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRp
b248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O1Ro
ZSBiaW5hcnkgcmVwcmVzZW50YXRpb24gdXNlcyBhcyA0LWJ5dGUgYmluYXJ5IHN0cmluZzxicj4N
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmluIG5ldHdvcmsgYnl0ZSBvcmRlcmlu
Zy4mcXVvdDs7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZuYnNwOyAm
bmJzcDsgJm5ic3A7fTxicj4NCjxicj4NClRoZSBDQk9SIGVuY29kZXIgKG9yIG90aGVyIGJpbmFy
eSBlbmNvZGVycykgd291bGQgdGhlbiBlbmNvZGUgdGhlPGJyPg0KdmFsdWUgYXMgYSA0IGJ5dGUg
YmluYXJ5IHZhbHVlLCB0aGUgWE1MIGFuZCBKU09OIGVuY29kZXIgd291bGQgdXNlIHRoZTxicj4N
CmNhbm9uaWNhbCBzdHJpbmcgcmVwcmVzZW50YXRpb24uJm5ic3A7IElmIHRoZSBiaW5hcnktcmVw
cmVzZW50YXRpb24gaXMgbm90PGJyPg0Kc3BlY2lmaWVkLCB0aGVuIHRoZSBnZW5lcmljIENCT1Ig
ZW5jb2RpbmcgcnVsZXMgYXBwbHkuIEkgYXNzdW1lIHRoYXQ8YnI+DQphZGRpdGlvbmFsIGJpbmFy
eSByZXByZXNlbnRhdGlvbiBkZWZpbml0aW9ucyB3aWxsIG9ubHkgYmUgbmVlZGVkIGZvciBhPGJy
Pg0KY291cGxlIG9mIHR5cGVzIChhbmQgSSBtaWdodCBldmVuIGJlIGZpbmUgdG8gcmVzdHJpY3Qg
dGhhdCB0bzxicj4NCnR5cGVkZWZzKS4gQW55d2F5LCBkZXRhaWxzIG5lZWQgd29yaywgYnV0IGlm
IHdlIHdhbnQgdG8gc3VwcG9ydCBtb3JlPGJyPg0KZWZmaWNpZW50IGJpbmFyeSBlbmNvZGluZ3Ms
IHRoZW4gSSB0aGluayB3ZSBzaG91bGQga2VlcCB0aGUgaXNzdWUgIzQ2PGJyPg0Kb3Blbi48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+T0sgLS0gdGhpcyBpcyB3aGF0IEkgaGFkIGluIG1pbmQgYnV0
IG9mZiB0byB0aGUgc2lkZSwgbGlrZSBhIGRldmlhdGlvbnMgbW9kdWxlLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPklmIHRoZSBjbGllbnQgYW5kIHNlcnZlciBhZ3JlZSBvbiB0aGUgbW9kdWxlIGNvbnRh
aW5pbmcgdGhlIHN0YW5kYXJkIGV4dGVuc2lvbiB1c2FnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5p
dCB3aWxsIG5vdCBiZSB0aGF0IGNvbXBsZXggaW4gdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyBleDpiaW5hcnktcmVwcmVz
ZW50YXRpb24gaWV0Zi1pbmV0LXR5cGVzOmlwdjQtYWRkcmVzcyB7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtleDpiaW5hcnktbGVuZ3RoIDQ7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtleDpiaW5hcnktcGF0dGVybiAmcXVvdDtiMC5iMS5i
Mi5iMyZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgWUFORyAxLjIgc2hvdWxkIGhhdmUgcmVhbCBz
dGF0ZW1lbnRzIGluc3RlYWQgb2YgZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4vanM8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QW5keTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tLTxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpKdWVyZ2VuIFNjaG9l
bndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBV
bml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NClBob25lOiAmIzQzOzQ5IDQyMSAyMDAgMzU4NyZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl
bWVuIHwgR2VybWFueTxicj4NCkZheDombmJzcDsgJm5ic3A7JiM0Mzs0OSA0MjEgMjAwIDMxMDMm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Ozwvc3Bhbj48YSBocmVmPSJodHRw
czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5odHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2Qg
bWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmci
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRo
YW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFu
aUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_24cd67f42eab465a90c33ff37ece5919XCHRCD007ciscocom_--