From nobody Fri Feb 1 03:25: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 6A27412DF72 for ; Fri, 1 Feb 2019 03:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.053 X-Spam-Level: X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 STTnos9NQ1J8 for ; Fri, 1 Feb 2019 03:25:44 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753A513121D for ; Fri, 1 Feb 2019 03:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8365; q=dns/txt; s=iport; t=1549020343; x=1550229943; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ABAN3w4Xd+KkVjVorlGjLRFGKUn70AXu7a/8u0o1VLU=; b=dBWe0j6hQQWr+ujtTWYCvQrjjfrawMwYsLpX9UREJLc2MrfMryMGRyk9 3YolSwQkpKdu591vFa+Nfdng1A+4za5YNgNkOivq6JERLuS0QtdDugHrJ +lSfZEH1PqvT4ncE0XfA7YrCN7EebJ67S8dQJV/4KS7MK0UFol/JGx5Rv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAAULFRc/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGCalABMieEA4h5jSCYDoF7DRgLhANGAoMyNgc?= =?us-ascii?q?NAQMBAQIBAQJtHAyFSgEBAQMBAQEhDwEFNhsLGAICJgICJzATBgIBAReDBwG?= =?us-ascii?q?BeQgPqgaBL4VDhG4FgQuLTIFAP4ERJ4Jrgx4BAYFLgx+CVwKKJoxki1kJkjA?= =?us-ascii?q?GGYpBh36UW4cegU0BMIFWMxoIGxU7gmyCJxeIX4U/PwMwjHYBAQ?= X-IronPort-AV: E=Sophos;i="5.56,548,1539648000"; d="scan'208";a="9745865" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2019 11:25:41 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x11BPenX011459 for ; Fri, 1 Feb 2019 11:25:41 GMT To: netmod@ietf.org References: <877eemjj2g.fsf@nic.cz> <87zhrhncyy.fsf@nic.cz> From: Robert Wilton Message-ID: <1ce25f88-671a-de6f-826e-645b70b753f2@cisco.com> Date: Fri, 1 Feb 2019 11:25:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <87zhrhncyy.fsf@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] LL comments on draft-rwilton-netmod-yang-packages-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, 01 Feb 2019 11:25:47 -0000 Hi Lada, On 31/01/2019 14:00, Ladislav Lhotka wrote: > Robert Wilton writes: > >> Hi Lada, >> >> Thanks for the review and comments ... >> >> I've added some thoughts inline ... >> >> On 30/01/2019 14:50, Ladislav Lhotka wrote: >>> Hi, >>> >>> I think it is a good start, here are my comments (some of them were >>> already raised by Jason): >>> >>> - I like the fact that this work doesn't require any changes to YANG, >>> except perhaps semver. >> RW: OK. >> >> >>> - I think the augments to YANG library is a separate problem that should >>> perhaps be addressed in a different document. Servers supporting >>> multiple package revisions may not be that common. >> RW: >> >> I completely agree that servers supporting multiple package revisions >> may not be that common, and I agree that any specification on how a >> server could support multiple packages, and perform package selection >> should be in a separate draft. >> >> But the YANG library augmentations aren't there only to support this use >> case.  My intention is to make it easier for devices to advertise a >> package representing what each datastore schema is rather than having to >> fetch the full contents of YANG library. >> >> E.g. a server might implement 900+ modules/sub-modules for a given >> release.  Different hardware will mostly implement the same modules, but >> there might be some differences.  If bugs have been patched then there >> might be some differences.  I'm aiming for a solution where a client >> doesn't have to fetch the full list of YANG modules for each server to >> figure out the schema for the device, which is probably the same as >> another 1000 devices in the network. >> >> Instead, I would like the vendor to publish a package for that >> particular release, with variants depending on the hardware.  The device >> can then advertise that it uses that base package, along with the small >> set of differences (e.g. due to bug fixes). >> > OK, I missed this purpose. Perhaps one of the examples can be expanded > to illustrate this situation. RW: Yes, that is a good suggestion.  I will try and make this more clear in the draft. > > But doesn't it defeat the purpose of packages? Even if I know that my client > works with package X, it needn't be the case with the vendor's changes. RW: So packages cannot themselves magically help vendor devices more faithfully implement the standard YANG models.  I think that over time this will likely improve, but probably is somewhat hampered by having two competing sets of industry standard YANG models. But there are a couple of ways that I feel that packages that they can help: 1) They can help indicate what functionality a server is trying to conform to, better than just a flat list of modules.  E.g. through the package inclusion, the client could see that a vendor is attempting to implement ietf-l2vpn-pkg@v1.0.0. 2) The package definition should aim to make it more clear where the server deviates from the package. On that second point, Jason was querying whether the package definition should list deviations for each module, but thinking about this a bit more, I wonder whether it would be helpful if when a package was imported, any deviations, or module version down revs, are explicitly listed at the point where the package import is defined.  I.e. to make the package deviations really explicit. >>> - I was expecting that a package could specify a range of revisions for >>> some modules that may be used together with teh others. This doesn't >>> seem to be the case. If so, it would be somewhat unwieldy because every >>> combination of module revisions would require a separate package >>> revision. >> RW: >> >> Yes, this is an interesting point. >> >> My intention is that there is a roughly linear history of package >> versions.  E.g. if there was a package of all IETF modules, then every >> time a new version of an IETF module is published, the package >> definition would be updated to a new version that includes the new >> published module revision. I think that we need to try and somewhat >> constraint the versions of modules that can sensibly be used together. >> > With semver, would it make sense to be able to specify only a major > version number of a module? The "yang-sem-ver" type requires the > complete version number. So, I don't think that this would quite work, but the effective behavior might be what you desire anyway. Consider the following:   (i) module A, at version 1.0.0, defines some functionality.   (ii )module A, at version 2.0.0, fixes some issues in version 1.0.0   (ii) module A, at version 2.1.0, defines some new (backwards compatible) functionality. If a package only listed module A's major version number (e.g. 2) then a client cannot know whether or not it can use the new functionality added in version 2.1.0 of the module, because it won't know whether the server implements it until is queries the module set in YANG library. But, I think that listing exact versions is probably OK.  - pkg-P, at version 1.0.0, uses module A@V2.0.0  - pkg-P, at version 1.1.0, uses module A@V2.1.0 If the client requires pkg-P@V1.0.0 then it will work with a server that supports pkg-p@V2.0.0 or pkg-p@V2.1.0. Further, if there is a third version of module A defined, e.g. 1.2.0, but that hasn't yet been included in an updated pkg-p revision, then the server can still indicate that it implements pkg-p@V1.1.0, but also indicate that is has updated module A to version 1.2.0.  The semver rules indicate that this is all OK and backwards compatible, and clients expecting to work with Pkg-P@1.0.0 or 1.1.0 would still work fine. Finally, I also want to be able to build an exact schema from a package definition, and that is only possible if the exact module versions/revisions are known. So, in summary, I think that package definitions should indicate precise version numbers of the modules defined by those packages, but the semver rules allow for newer backwards compatible implementations of the package, or newer backwards compatible implementations of some of the modules in the package. > >>> - As Jason pointed out, there seems to be no use for the package >>> namespace, as packages don't define any names on their own. >> Yes, I will remove the text about namespaces.  Globally unique package >> names should be sufficient. >> >> >>> - I would also prefer mandatory-features to be bundled with each >>> module. >>> >>> - This draft nicely shows that there is really no need for any >>> "yang-data" extensions. But I also don't see any benefit from using >>> ietf-yang-instance-data in this case. It would IMO be perfectly fine >>> to get rid of two levels of data hierarchy: >>> >>> { "ietf-yang-package:yang-package": { >>> ... >>> } >>> } >> That's an interesting point.  My thought is that all at rest YANG data >> would be encoded in YANG instance data documents to make them more >> easily machine parse-able. > I don't see how the two extra levels make the JSON more easy to parse. So, my interpretation is that draft-ietf-netmod-yang-instance-file-format-01 is intended to be the standard way of representing YANG data at rest (which is what this YANG package definition is meant to be).  If we shouldn't use draft-ietf-netmod-yang-instance-file-format-01 for YANG packages, then when should it be used? > > If we want to have some standard metadata for inclusion in standalone > instance document, it would be probably better to define the metadata as > a grouping that can be used right under > "ietf-yang-package:yang-package". In the DSDL schemas (RFC 6110) we used > Dublin Core metadata for a similar purpose. OK, perhaps this issue should be discussed in the context of the YANG instance data draft. But I will add this as an open issue. Thanks, Rob > > Lada > >> Thanks, >> Rob >> >> >>> Thanks, Lada >>> >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Feb 4 21:44: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 D1C1213107D for ; Mon, 4 Feb 2019 21:44:29 -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 0CctneztwPdz for ; Mon, 4 Feb 2019 21:44:27 -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 51F1E131088 for ; Mon, 4 Feb 2019 21:44:22 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D3F2F16739DAD23EE833 for ; Tue, 5 Feb 2019 05:44:19 +0000 (GMT) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Feb 2019 05:44:19 +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; Tue, 5 Feb 2019 05:44:19 +0000 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) 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; Tue, 5 Feb 2019 05:44:19 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Tue, 5 Feb 2019 13:44:08 +0800 From: Rohit R Ranade To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-ranade-netmod-yang-push-extension-02.txt Thread-Index: AQHUvRVLBoIBNXUxq0mKXgxq7ug2XKXQsIpA Date: Tue, 5 Feb 2019 05:44:07 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCEE151@dggeml510-mbx.china.huawei.com> References: <154934522074.28956.2043880952827175544.idtracker@ietfa.amsl.com> In-Reply-To: <154934522074.28956.2043880952827175544.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] New Version Notification for draft-ranade-netmod-yang-push-extension-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: Tue, 05 Feb 2019 05:44:30 -0000 SGkgQWxsLA0KDQpJIGhhdmUgcG9zdGVkIGEgZHJhZnQgd2hpY2ggcHJvdmlkZXMgc29tZSBleHRl bnNpb25zIHRvIFlhbmcgcHVzaCBkcmFmdCB3LnIudCB0byB0cmFja2luZyBjb25maWd1cmF0aW9u cyBhbmQgdGhlaXIgb3JpZ2lucy4NClRoaXMgZHJhZnQgaGFzIG1haW5seSBib3Jyb3dlZCB0aGUg Y29uZmlnLWZpbHRlciBhbmQgd2l0aC1vcmlnaW4gcGFyYW1ldGVycyBmcm9tIFJFU1RDT05GIC8g TkVUQ09ORiBOTURBIGRyYWZ0cyBhbmQgYXBwbGllZCB0byBZQU5HIHB1c2guDQogDQpLaW5kbHkg aGF2ZSBhIGxvb2sgYXQgaXQgYW5kIHByb3ZpZGUgeW91ciBvcGluaW9ucy4gQW55IGNvbW1lbnRz IGFyZSBhcHByZWNpYXRlZC4NCg0KV2l0aCBSZWdhcmRzLA0KUm9oaXQNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAwNSBGZWJydWFyeSAyMDE5IDExOjEwDQpU bzogUm9oaXQgUiBSYW5hZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPjsgUm9oaXQgUiBSYW5h ZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1yYW5hZGUtbmV0bW9kLXlhbmctcHVzaC1leHRlbnNpb24tMDIudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJhbmFkZS1uZXRtb2QteWFuZy1wdXNo LWV4dGVuc2lvbi0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9o aXQgUiBSYW5hZGUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtcmFuYWRlLW5ldG1vZC15YW5nLXB1c2gtZXh0ZW5zaW9uDQpSZXZpc2lvbjoJMDINClRp dGxlOgkJRXh0ZW5zaW9ucyB0byBZYW5nIFB1c2gNCkRvY3VtZW50IGRhdGU6CTIwMTktMDItMDUN Ckdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhbmFkZS1uZXRt b2QteWFuZy1wdXNoLWV4dGVuc2lvbi0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYW5hZGUtbmV0bW9kLXlhbmctcHVzaC1leHRl bnNpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXJhbmFkZS1uZXRtb2QteWFuZy1wdXNoLWV4dGVuc2lvbi0wMg0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcmFuYWRlLW5ldG1vZC15 YW5nLXB1c2gtZXh0ZW5zaW9uDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LXJhbmFkZS1uZXRtb2QteWFuZy1wdXNoLWV4dGVuc2lvbi0wMg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBleHRlbnNpb25zIHRvIHRoZSB5 YW5nIHB1c2ggc3Vic2NyaXB0aW9uDQogICBtZWNoYW5pc20sIHdoaWNoIGNhbiBwcm92aWRlIG1v cmUgZ3JhbnVsYXJpdHkgaW4gdHJhY2tpbmcNCiAgIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyBpbiBk YXRhc3RvcmVzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Feb 5 07:42:14 2019 Return-Path: <01000168be52dddc-c376dd05-9884-45b1-a9e8-b591bd416442-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 9EB99130E0A for ; Tue, 5 Feb 2019 07:42: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 D8NJ29MhePhi for ; Tue, 5 Feb 2019 07:42:10 -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 2A56712DF71 for ; Tue, 5 Feb 2019 07:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1549381328; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=Zp8Agwszcp1bkDg3NPt+Q64rQQYq7sR3umIFDXZATUI=; b=ONKVnsJDgjd5IB9pdS6chiXPJ+VSv6Di3mljBq5YmEwRlulGUSOujmS6JrbYqnZt gHz02/PgGpbBwc+QTy0/YrDYQ+cehJnYqpiELi896CThasnt07AgSOrHxsejZF/NY9d PrPofTWCkaUv58z1WLbPoeqGSMkWJPhrJjLwFtCw= 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, 5 Feb 2019 15:42:08 +0000 References: <154836207489.29316.10261924074846695076@ietfa.amsl.com> To: netmod@ietf.org In-Reply-To: <154836207489.29316.10261924074846695076@ietfa.amsl.com> Message-ID: <01000168be52dddc-c376dd05-9884-45b1-a9e8-b591bd416442-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.05-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2019-02-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: Tue, 05 Feb 2019 15:42:13 -0000 Reminder: the virtual interim to continue scoring the YANG Next items is = tomorrow. Kent > On Jan 24, 2019, at 3:34 PM, IESG Secretary = wrote: >=20 > The Network Modeling (netmod) Working Group will hold > a virtual interim meeting on 2019-02-06 from 10:00 to 12:00 = America/New_York. >=20 > Agenda: > Goal: To continue scoring the YANG Next feature requests listed here: = https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aissue+is%3Aopen+sor= t%3Acreated-asc. =20 >=20 > Non-Goal: This is NOT a YANG-next planning meeting. We only want to = score the items in preparation for a planning meeting to take place at = IETF 104 in Prague. >=20 >=20 > Meeting Link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm43c8c25cbece0879a425f3cab6bff338= > Early joins may occur 5-minutes before start. > Meeting number: 646 020 675 > Meeting password: 5p45ZVKa >=20 > Audio connection: > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 646 020 675 >=20 > Information about remote participation: > Remote participation via WebEx >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 6 13:43:22 2019 Return-Path: <01000168c4c3c3f7-609ca8a3-a2c8-4d67-84de-dd277a2e0d62-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 E277E130EE0 for ; Wed, 6 Feb 2019 13:43:15 -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 VLZSbV6SwAGH for ; Wed, 6 Feb 2019 13:43:12 -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 C69EB130ECD for ; Wed, 6 Feb 2019 13:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1549489390; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=5Yq2csU5Zia2vpoPYb6TP0uEyI/GWO5rukIjTdzIDCc=; b=gc3qZVVAIHNU2iMqeC99M0CFBX/9iUEG9zWC1TdabbsbcqUycs3HMR03i3LBUbyS 3x3slAw6RQZIdGURcxVSl9opTGA7AH1EIRHfexHJhTIXchDQcC13v34Jjx3bf88xk0s zCFVENJsPWplcqSQBZ3oe5z8xPoBhTKfvigJhiE8= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_A98DEC3E-0E93-4175-AC76-96FF0E62AE43" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Feb 2019 21:43:10 +0000 References: <154836207489.29316.10261924074846695076@ietfa.amsl.com> <01000168be52dddc-c376dd05-9884-45b1-a9e8-b591bd416442-000000@email.amazonses.com> To: netmod@ietf.org In-Reply-To: <01000168be52dddc-c376dd05-9884-45b1-a9e8-b591bd416442-000000@email.amazonses.com> Message-ID: <01000168c4c3c3f7-609ca8a3-a2c8-4d67-84de-dd277a2e0d62-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.06-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] Meeting Minutes 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 Feb 2019 21:43:16 -0000 --Apple-Mail=_A98DEC3E-0E93-4175-AC76-96FF0E62AE43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The minutes are also posted here: = https://datatracker.ietf.org/meeting/interim-2019-netmod-01/materials/minu= tes-interim-2019-netmod-01-201902061000 = Meeting Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NETMOD Virtual Interim February 6th, 2019 Attendees: - Kent Watsen - Acee Linden - Andy Bierman - Juergen Schoenwaelder - Ladislav Lhotka - Mahesh Jethanandani - Martin Bjorklund - Reshad Rahman - Robert Wilton Agenda: The purpose of this meeting was to continue scoring the YANG Next = feature requests [1]. This was NOT a YANG-next planning meeting. The scoring = of the items was/is in preparation for a planning meeting to take place at=20= IETF 104 in Prague. Overview of results follows. For details, please see the YANG-next = issue tracker [1]. Start : 42 issues (un-scored)=20 Reviewed : 26 issues Scored: : 15 issues Closed: : 11 issues Remaining : 16 issues We plan to schedule a continuation virtual interim meeting to occur on=20= February 20th (invite will be sent shortly).=20 [1] = https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aissue+is%3Aopen+sor= t%3Acreated-asc Kent // as co-chair > On Feb 5, 2019, at 10:42 AM, Kent Watsen wrote: >=20 >=20 > Reminder: the virtual interim to continue scoring the YANG Next items = is tomorrow. >=20 > Kent >=20 >=20 >> On Jan 24, 2019, at 3:34 PM, IESG Secretary = wrote: >>=20 >> The Network Modeling (netmod) Working Group will hold >> a virtual interim meeting on 2019-02-06 from 10:00 to 12:00 = America/New_York. >>=20 >> Agenda: >> Goal: To continue scoring the YANG Next feature requests listed here: = https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aissue+is%3Aopen+sor= t%3Acreated-asc. =20 >>=20 >> Non-Goal: This is NOT a YANG-next planning meeting. We only want to = score the items in preparation for a planning meeting to take place at = IETF 104 in Prague. >>=20 >>=20 >> Meeting Link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm43c8c25cbece0879a425f3cab6bff338= >> Early joins may occur 5-minutes before start. >> Meeting number: 646 020 675 >> Meeting password: 5p45ZVKa >>=20 >> Audio connection: >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 646 020 675 >>=20 >> Information about remote participation: >> Remote participation via WebEx >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_A98DEC3E-0E93-4175-AC76-96FF0E62AE43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The minutes are also posted here:  https://datatracker.ietf.org/meeting/interim-2019-netmod-01/mat= erials/minutes-interim-2019-netmod-01-201902061000


Meeting Minutes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

NETMOD Virtual Interim
February 6th, 2019

Attendees:
  - Kent Watsen
  - Acee Linden
  - Andy Bierman
  - Juergen Schoenwaelder
  - Ladislav Lhotka
  - Mahesh Jethanandani
  - Martin Bjorklund
  - Reshad Rahman
  - Robert Wilton

Agenda:

The purpose of this meeting was to continue scoring the YANG Next =
feature
requests [1].  This was NOT a YANG-next planning meeting.  The scoring =
of
the items was/is in preparation for a planning meeting to take place at=20=

IETF 104 in Prague.

Overview of results follows.  For details, please see the YANG-next =
issue
tracker [1].

  Start     : 42 issues (un-scored)=20
  Reviewed  : 26 issues
  Scored:   : 15 issues
  Closed:   : 11 issues
  Remaining : 16 issues

We plan to schedule a continuation virtual interim meeting to occur on=20=

February 20th (invite will be sent shortly).=20

[1] https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aissue+is=
%3Aopen+sort%3Acreated-asc


Kent // as co-chair






On Feb = 5, 2019, at 10:42 AM, Kent Watsen <kent@watsen.net> wrote:


Reminder: the virtual interim to continue scoring the YANG = Next items is tomorrow.

Kent


On Jan 24, 2019, at 3:34 PM, IESG Secretary <iesg-secretary@ietf.org> wrote:

The Network Modeling (netmod) Working Group will hold
a virtual interim meeting on 2019-02-06 from 10:00 to 12:00 = America/New_York.

Agenda:
Goal:= To continue scoring the YANG Next feature requests listed here: https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aissue+is= %3Aopen+sort%3Acreated-asc.  

Non-Goal: This is NOT a YANG-next planning meeting.  We = only want to score the items in preparation for a planning meeting to = take place at IETF 104 in Prague.


Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=3Dm43c8c25cbece0879a425f= 3cab6bff338
Early joins may occur 5-minutes before = start.
Meeting number: 646 020 675
Meeting = password: 5p45ZVKa

Audio connection:
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 646 020 675

Information about remote participation:
Remote = participation via WebEx

_______________________________________________
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=_A98DEC3E-0E93-4175-AC76-96FF0E62AE43-- From nobody Wed Feb 6 14:02:17 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 8202C12D4F3; Wed, 6 Feb 2019 14:02:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netmod-chairs@ietf.org, ibagdona@gmail.com, kent+ietf@watsen.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154949053447.32684.3268962361823703218.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2019 14:02:14 -0800 Archived-At: Subject: [netmod] netmod - Update to a Meeting Session Request 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: Wed, 06 Feb 2019 22:02:15 -0000 An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf Second Priority: teas i2rs anima rtgwg 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 beginning of week (ideally Mon; Tue morning is OK). SHOULD schedule 2nd session for Tuesday but, if not possible, than any day W-F OK (just will be one chair down). --------------------------------------------------------- From nobody Wed Feb 6 14:05: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 2E2D512D4F3; Wed, 6 Feb 2019 14:05:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netmod-chairs@ietf.org, ibagdona@gmail.com, kent+ietf@watsen.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154949070318.424.15528962033149682833.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2019 14:05:03 -0800 Archived-At: Subject: [netmod] netmod - Update to a Meeting Session Request 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: Wed, 06 Feb 2019 22:05:03 -0000 An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf Second Priority: teas i2rs rtgwg 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 beginning of week (ideally Mon; Tue morning is OK). SHOULD schedule 2nd session for Tuesday but, if not possible, than any day W-F OK (just will be one chair down). --------------------------------------------------------- From nobody Wed Feb 6 14:09:18 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 9901D130FA2; Wed, 6 Feb 2019 14:09:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netmod-chairs@ietf.org, ibagdona@gmail.com, kent+ietf@watsen.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154949094861.404.2149595372944766161.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2019 14:09:08 -0800 Archived-At: Subject: [netmod] netmod - Update to a Meeting Session Request 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: Wed, 06 Feb 2019 22:09:16 -0000 An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Kent Watsen 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 Wed Feb 6 15:53:02 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 9C7F312D4F3; Wed, 6 Feb 2019 15:52:54 -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.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154949717453.32719.8586247155278114345@ietfa.amsl.com> Date: Wed, 06 Feb 2019 15:52:54 -0800 Archived-At: Subject: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2019-02-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: Wed, 06 Feb 2019 23:52:55 -0000 The Network Modeling (netmod) Working Group will hold a virtual interim meeting on 2019-02-20 from 10:00 to 12:00 America/New_York. Agenda: To finish scoring the YANG-next feature requests. This is NOT a YANG-next planning meeting. We only want to score the items in preparation for a planning meeting to take place at IETF 104 in Prague. YANG-next issue tracker: https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc. Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=mf0fd98065981bfc08c6076295642f7d5 Early joins may occur 5-minutes before start. Meeting number: 649 730 322 Meeting password: BQ3JJrF9 Audio connection: 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 730 322 Information about remote participation: Remote participation via WebEx Information about remote participation: See WebEx details above. From nobody Thu Feb 7 04:10: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 BD288131111 for ; Thu, 7 Feb 2019 04:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.641 X-Spam-Level: X-Spam-Status: No, score=-14.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 ZeqLYAKsKeEq for ; Thu, 7 Feb 2019 04:10:24 -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 C738C12D4F2 for ; Thu, 7 Feb 2019 04:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16479; q=dns/txt; s=iport; t=1549541424; x=1550751024; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=F6zPw9ejPM+D6eaz4eXCAs2XbyTf44/Se8gKZyO9eoY=; b=DNRLhJofb+tFZlo1nVPBOqEYiHr4apJ/flR/Ow3Pro97zLgYSQrHXB63 MptZep0EioRZLbjtZ5I8J6vRTJ5K8Zaqjv0AHV3ePXB4XQOwr60Hr1XSj vIp1OjgwDV6EZXV7J4RA3JJdC0PRP9mMxKVF8Pfe/L57FrI0tuX1klCpx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAD/Hlxc/xbLJq0ZAUoZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFRBAEBAQEBCwEBgmlQASASJ4QDiBpfjHAIJXyRJoV?= =?us-ascii?q?vFIFnDRgBDIQBRgKDQzQJDQEDAQECAQECbRwMhUoBAQEEAQEhSwkSCQIRAwE?= =?us-ascii?q?CASoCAicoCAYBDAYCAQEXgwkBggEPjiiCe5thgS8fhBQCDkFAhGeMWoFAP4E?= =?us-ascii?q?RJwyCKjWDHgEBAgEBFoEUARIBCTaCaYI1IgKJWysCBYYoklsJhnNEiwgGGYF?= =?us-ascii?q?tUoR0gxcmh2WKLYEOhCqFHIcigUY4ZXEzGggbFRohgmwJgh8XE4hMhT8/AzA?= =?us-ascii?q?BjDuCPgEB?= X-IronPort-AV: E=Sophos;i="5.58,344,1544486400"; d="scan'208,217";a="9931662" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2019 12:10:21 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x17CAJQZ026261; Thu, 7 Feb 2019 12:10:20 GMT To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , "netmod@ietf.org" References: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> From: Robert Wilton Message-ID: Date: Thu, 7 Feb 2019 12:10:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> Content-Type: multipart/alternative; boundary="------------75B8BF7C7906B8957659A015" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.64, dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-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: Thu, 07 Feb 2019 12:10:28 -0000 This is a multi-part message in MIME format. --------------75B8BF7C7906B8957659A015 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Balazs, Regarding identifying the instance data using a YANG package. If the YANG packages work is liked by the WG and progresses, then it seems plausible that a YANG package could become a better way of identifying the set of modules rather than using YANG library for a couple of reasons:  1) It will allow modules to be identified via semantic version rather than just revision date.  This will likely be more meaningful to readers.  2) It allows for a much more concise definition.  Rather than having to try and infer what schema a particular set of YANG modules related to from the list of modules, it can instead refer to a single package definition and version number.  3) YANG library (certainly RFC7895bis) defines the schema in terms of the datastore, so if this version of YANG library is being used then it is a bit more confusing as to which datastore is being referred to.  I appreciate that there is a datastore leaf in the instance data that can help mitigate this. I also note that the draft currently binds that the only allowed inline schema is YANG library, but that seems somewhat overly restrictive, and perhaps this could be loosened to a leaf-list of inline module@revision definitions? I also appreciate that you don't want to delay the instance data draft for YANG packages, bit I wonder whether the draft can easily facilitate using a YANG package definition in future if required. Hence, rather than using a union for the "target pointer", I wonder whether it wouldn't be better to use a choice statement instead. E.g. the choice statement could be something like this:  choice "schema"    leaf-list inline {      type string {        pattern '\w+@\d{4}-\d{2}-\d{2}\.yang';      }    }    leaf yang-library-ref { type uri } // Points to a instance data document YANG library content.  } In future, the package draft could then augment (or update the revision) with something like this :    container package-ref {      leaf "name" { type string; }      leaf "version" { type yang-semver; }      leaf-list "url" { type uri; }// Points to a instance data document containing YANG package content.    } Thanks, Rob On 06/12/2018 10:15, Balázs Lengyel wrote: > > Hello, > > We uploaded a new version of the instance data draft. We tried to > address all comments and also to rework the format chapter to make it > easier to read. We omitted 2 comments: > > Rob commented that YANG packages could be used for defining the target > modules for instance data: I would like to avoid that because: > > * Packages are not defined for YANG. Currently they are not part of > the versioning solution even though they were discussed and are > generally a good idea. > * IMHO as deviations/features are set on module level, just > specifying packages would not be enough. If we start using > package+module level deviations/features we may end up with a more > complicated hybrid solution. > * Module level YANG target definitions as described in the draft are > simple and need no new design > > Jürgen stated that it would be better to use the YANG XML/JSON > encoding as a format instead of referencing the get operation/request. > I might even agree with him, but for 2 reasons I did not follow his idea: > > * Currently there is no RFC I could reference either for XML or > JSON. AFAIK even RFC7951 does not define how multiple modules > should be encoded side by side. > * It is not the job of the instance data draft to dictate how to > encode YANG data generally e.g. on the wire. > * The contents of the get operation/request are well defined > > regards Balazs > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-ietf-netmod-yang-instance-file-format-01.txt > Date: Thu, 6 Dec 2018 02:12:12 -0800 > From: internet-drafts@ietf.org > To: Benoit Claise , Balazs Lengyel > > > > > > A new version of I-D, draft-ietf-netmod-yang-instance-file-format-01.txt > has been successfully submitted by Balazs Lengyel and posted to the > IETF repository. > > Name: draft-ietf-netmod-yang-instance-file-format > Revision: 01 > Title: YANG Instance Data File Format > Document date: 2018-12-06 > Group: netmod > Pages: 21 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01 > > Abstract: > There is a need to document data defined in YANG models when a live > YANG server is not available. Data is often needed already in design > time or needed by groups that do not have a live running YANG server > available. This document specifies a standard file format for YANG > instance data, which follows the syntax and semantic from existing > YANG models, re-using existing formats from operation/request > and decorates them with metadata. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email:Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------75B8BF7C7906B8957659A015 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Balazs,

Regarding identifying the instance data using a YANG package.

If the YANG packages work is liked by the WG and progresses, then it seems plausible that a YANG package could become a better way of identifying the set of modules rather than using YANG library for a couple of reasons:
 1) It will allow modules to be identified via semantic version rather than just revision date.  This will likely be more meaningful to readers.
 2) It allows for a much more concise definition.  Rather than having to try and infer what schema a particular set of YANG modules related to from the list of modules, it can instead refer to a single package definition and version number.
 3) YANG library (certainly RFC7895bis) defines the schema in terms of the datastore, so if this version of YANG library is being used then it is a bit more confusing as to which datastore is being referred to.  I appreciate that there is a datastore leaf in the instance data that can help mitigate this.

I also note that the draft currently binds that the only allowed inline schema is YANG library, but that seems somewhat overly restrictive, and perhaps this could be loosened to a leaf-list of inline module@revision definitions?

I also appreciate that you don't want to delay the instance data draft for YANG packages, bit I wonder whether the draft can easily facilitate using a YANG package definition in future if required.

Hence, rather than using a union for the "target pointer", I wonder whether it wouldn't be better to use a choice statement instead.

E.g. the choice statement could be something like this:

 choice "schema"
   leaf-list inline {
     type string {
       pattern '\w+@\d{4}-\d{2}-\d{2}\.yang';
     }
   }
   leaf yang-library-ref { type uri } // Points to a instance data document YANG library content.
 }

In future, the package draft could then augment (or update the revision) with something like this :

   container package-ref {
     leaf "name" { type string; }
     leaf "version" { type yang-semver; }
     leaf-list "url" { type uri; } // Points to a instance data document containing YANG package content.
   }

Thanks,
Rob

On 06/12/2018 10:15, Balázs Lengyel wrote:

Hello,

We uploaded a new version of the instance data draft. We tried to address all comments and also to rework the format chapter to make it easier to read. We omitted 2 comments:

Rob commented that YANG packages could be used for defining the target modules for instance data: I would like to avoid that because:

  • Packages are not defined for YANG. Currently they are not part of the versioning solution even though they were discussed and are generally a good idea.
  • IMHO as deviations/features are set on module level, just specifying packages would not be enough. If we start using package+module level deviations/features we may end up with a more complicated hybrid solution.
  • Module level YANG target definitions as described in the draft are simple and need no new design

Jürgen stated that it would be better to use the YANG XML/JSON encoding as a format instead of referencing the get operation/request. I might even agree with him, but for 2 reasons I did not follow his idea:

  • Currently there is no RFC I could reference either for XML or JSON. AFAIK even RFC7951 does not define how multiple modules should be encoded side by side.
  • It is not the job of the instance data draft to dictate how to encode YANG data generally e.g. on the wire.
  • The contents of the get operation/request are well defined

regards Balazs



-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt
Date: Thu, 6 Dec 2018 02:12:12 -0800
From: internet-drafts@ietf.org
To: Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>



A new version of I-D, draft-ietf-netmod-yang-instance-file-format-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format
Revision: 01
Title: YANG Instance Data File Format
Document date: 2018-12-06
Group: netmod
Pages: 21
URL: https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01

Abstract:
There is a need to document data defined in YANG models when a live
YANG server is not available. Data is often needed already in design
time or needed by groups that do not have a live running YANG server
available. This document specifies a standard file format for YANG
instance data, which follows the syntax and semantic from existing
YANG models, re-using existing formats from <get> operation/request
and decorates them with metadata.



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

The IETF Secretariat

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------75B8BF7C7906B8957659A015-- From nobody Thu Feb 7 07:32: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 7AA02124C04 for ; Thu, 7 Feb 2019 07:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 rsEhZLnxlEXZ for ; Thu, 7 Feb 2019 07:32:16 -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 D1C6D12008F for ; Thu, 7 Feb 2019 07:32:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8D7916A2 for ; Thu, 7 Feb 2019 16:32:14 +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 odzBOelfBUCu for ; Thu, 7 Feb 2019 16:32:14 +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 ; Thu, 7 Feb 2019 16:32:14 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DD3820053 for ; Thu, 7 Feb 2019 16:32:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id geN49C5_IL50 for ; Thu, 7 Feb 2019 16:32:14 +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 1ACA220051 for ; Thu, 7 Feb 2019 16:32:13 +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 Feb 2019 16:32:13 +0100 Received: by anna.localdomain (Postfix, from userid 501) id D1A0530063960A; Thu, 7 Feb 2019 16:32:12 +0100 (CET) Date: Thu, 7 Feb 2019 16:32:12 +0100 From: Juergen Schoenwaelder To: Message-ID: <20190207153212.wttlorfwpoy6mpe6@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: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: [netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology 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 Feb 2019 15:32:18 -0000 Hi, I just stumbled across the terminology defined in draft-ietf-netmod-yang-instance-file-format-01 and I have several questions: Design time: A time during which a YANG model and the implementation behind it is created. Sometimes in other documents this period is divided into design and implementation time. Assuming that design time and implementation time are the same seems to be odd. In the IETF, it is quite common that there is a significant difference between design time and implementation time. So what is mean here? Since the term is rarely used (I found two occurances), perhaps clarify what is meant where this term is used and do not introduce a new term. However, if the term is defined, then I suggest that we use semantics that align with the common use of the term. Instance Data Set: A named set of data items that can be used as instance data in a YANG data tree. Why do we need this term? How is this different from data tree defined in RFC 7950? o data tree: An instantiated tree of any data modeled with YANG, e.g., configuration data, state data, combined configuration and state data, RPC or action input, RPC or action output, or notification. In which sense is this a 'named set'? Or is the intention here to define a named set of YANG data trees? If a term is needed, would 'Instance Data' not be simpler and align better with Instance Data File? Also note that 'instance data' is defined later as 'data that could be stored in a datastore and whose syntax and semantics is defined by YANG models'. So how does 'instance data' related to 'instance data set' and 'data tree'? Can we simplify things? Target YANG Module: A YANG module for which the instance data set contains instance data, like ietf-yang-library in the examples. I am not sure I like 'target'. It seems to me that instance data is expected to conform to a schema defined by a collection of YANG modules and you probably want to express that (but 'target' I find misleading - data does not target a module). Whatever we choose at the end, we need to make sure that the terminology across related documents (YANG, NMDA, YANG Library, ...) is consistent. The leaf target-ptr triggers questions as well. If there is a choice between two things, perhaps using a YANG choice is a more natural way of expressing this than inventing special notations. I am also not sure if it is a good idea to hardcode the name ietf-yang-library. Why can I not just refer to any schema defining YANG modules? This way, we have the freedom to create ietf-yang-library-2 if we ever want to. Do implementations have to follow target-ptr arbitrarily deep? Do they have to detect circular references (well they better do I guess). /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 Feb 12 15:50:10 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 261EB130DD8; Tue, 12 Feb 2019 15:50:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Jaeggli To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, iesg-secretary@ietf.org, joelja@gmail.com, Joel Jaeggli , netmod@ietf.org Message-ID: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 15:50:08 -0800 Archived-At: Subject: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04 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, 12 Feb 2019 23:50:08 -0000 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/ From nobody Tue Feb 12 22:53: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 007F512D4EF for ; Tue, 12 Feb 2019 22:53:17 -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 d2Ju0KxubLVD for ; Tue, 12 Feb 2019 22:53:14 -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 0B8C012D4E6 for ; Tue, 12 Feb 2019 22:53:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CB3F2B31; Wed, 13 Feb 2019 07:53: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 KLmcWSEO3NKl; Wed, 13 Feb 2019 07:53: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; Wed, 13 Feb 2019 07:53:11 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B448F20054; Wed, 13 Feb 2019 07:53:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W-Zulzmsta6K; Wed, 13 Feb 2019 07:53:11 +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 4698420055; Wed, 13 Feb 2019 07:53:11 +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; Wed, 13 Feb 2019 07:53:10 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 747C3300655A2F; Wed, 13 Feb 2019 07:53:09 +0100 (CET) Date: Wed, 13 Feb 2019 07:53:09 +0100 From: Juergen Schoenwaelder To: Joel Jaeggli CC: Message-ID: <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Joel Jaeggli , netmod@ietf.org References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 06:53:17 -0000 On Tue, Feb 12, 2019 at 03:50:08PM -0800, Joel Jaeggli wrote: > 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/ > I just looked at the latest diff and I stumbled over the example using tags like ietf:rfc8199-element and ietf:routing and while I had an intuitive idea what ietf:routing may mean, I was pretty clueless what ietf:rfc8199-element is. Back in the old SNMP days, we actually learned that using RFC numbers in labels is not always a good idea because definitions sometimes get replaced or moved to other RFCs. If the idea is to further scope IETF defined tags (there may be multiple 'element' tags), why does this additional scoping need not apply to ietf:routing? So bottom line, should the tags _all_ be of the form - ietf:rfcxxxx:label or - ietf:rfcxxxx-label or - ietf:scope-label or - ietf:scope:label or - ietf:label where scope indicates the topic of the RFC defining the label (avoiding the embedding of the RFC number). I think it will be good if the ietf: namespace is somewhat organized from the start and it is not so good if the initial document is already using different forms. /js PS: I also wonder why this document defines ietf:lmp or more precisely what exactly this is. When do I use ietf:protocol? When does it apply and when not? Does it apply to ietf-system.yang since it among other things sets parameters for ntp? I also wonder what the life cycle management of these tag definitions is. If it turns out that tags are underspecified, can I deprecate or obsolete them? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 13 01:01: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 7D0EE12DD85 for ; Wed, 13 Feb 2019 01:01: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, 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 MT6md4SH7MSf for ; Wed, 13 Feb 2019 01:00:58 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6C302131031 for ; Wed, 13 Feb 2019 01:00:58 -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 8E7D760158; Wed, 13 Feb 2019 04:00:57 -0500 (EST) References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Juergen Schoenwaelder Cc: Joel Jaeggli , netmod@ietf.org Date: Wed, 13 Feb 2019 04:00:01 -0500 Message-ID: In-reply-to: <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 09:01:06 -0000 --=-=-= Content-Type: text/plain; format=flowed Juergen Schoenwaelder writes: > On Tue, Feb 12, 2019 at 03:50:08PM -0800, Joel Jaeggli wrote: >> 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/ >> > > I just looked at the latest diff and I stumbled over the example using > tags like ietf:rfc8199-element and ietf:routing and while I had an > intuitive idea what ietf:routing may mean, I was pretty clueless what > ietf:rfc8199-element is. Back in the old SNMP days, we actually > learned that using RFC numbers in labels is not always a good idea > because definitions sometimes get replaced or moved to other RFCs. If You were clueless after you read RFC8199? :) We could change the tag names to: ietf-class-service ietf-class-element And point at RFC8199 in the document for their definition. However, this only seems to further obfuscate the meaning from the user requiring 2 hops to reach the meaning vs. 1 hop. Repeating RFC8199 inside the modules tag draft to remove the reference seems ill-advised if that was your intention. In any case this is general purpose meta-data after all, while some data may be immediately recognizable (e.g., ietf:routing) other data may require looking at a specification to determine it's meaning. All that said, if these RFC8199 are inappropriate for inclusion in this document or confusing, I'd rather remove them than stall the work. To use a routing analogy, the intent of this work is to create a method for "signaling" values, not to define the "values" themselves. > the idea is to further scope IETF defined tags (there may be multiple > 'element' tags), why does this additional scoping need not apply to There is no intent to add additional scoping. Indeed this was part of the motivation behind the addition of the final sentence in the "Tag Value" text in v3 of the document: All tags 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. Thanks, Chris. > ietf:routing? So bottom line, should the tags _all_ be of the form > > - ietf:rfcxxxx:label or > - ietf:rfcxxxx-label or > - ietf:scope-label or > - ietf:scope:label or > - ietf:label > > where scope indicates the topic of the RFC defining the label > (avoiding the embedding of the RFC number). I think it will be good if > the ietf: namespace is somewhat organized from the start and it is not > so good if the initial document is already using different forms. > > /js > > PS: I also wonder why this document defines ietf:lmp or more precisely > what exactly this is. When do I use ietf:protocol? When does it > apply and when not? Does it apply to ietf-system.yang since it > among other things sets parameters for ntp? I also wonder what the > life cycle management of these tag definitions is. If it turns out > that tags are underspecified, can I deprecate or obsolete them? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxj3MgACgkQLh2DDte4 MCXUGw/8DbWf8PRHQzV22bk9303oD7zm2Sdq4NtcQp1/89y/LFDWAeoLCHzvDroE D+LZFo/ZgIyN6nR0nXnfzNT3boZ2as4r20DcfxPY+a5c56kvNBzlzDbKaLkW7/XA Mo3tRkfoCh8/kO6HGzI3dWu6+nWvzQ4N1DdTI/arffXLod/eIIkY9gzdHtLz/bSb 4UEPw8O7NGdgEPwBHveDl7/mfBzo1LWnrAIQmLKjXM1SpQ2M12vzBEHLSqoG8vd1 XhrZyVnDn6WFU5lc5ns8MgGqd70jcC82AbA2dK1lM/WuU8XHw2NBZF5PneW/wERF EO/T19LbM+Wie1k+H/LR+VTDHTEp0I5yvbcSwg2QZUhXKba6sP5lE0NYmrus9KVb UrE5hiNZNG8BDbMJzSqIt+MKNV4pPBFZ+JzWChwqmeu/kemq/pgJ6wbvEJ4COJ10 WQrWmiqpLB/TJ6d5cni1W1l5a8QVVO9tPjLJexI+n3ljaG+/qa2ZHy20BaPdq4Ei M74HL7CCX5yF32ppNLoV/jWUFjHET+e+z9n87ScgjMtJ6ql46IkpipDLgUFPHG9d IcimhHK9E4YGEK7su86nc7hBK2TlC4wKayG0kWOGDcXikBEYFpvV6SzcPQsrAVW+ YH5RnHccGO4Sml1Qo73Z/rjJER1/FItVf73pozNf6vXtep60ElI= =/6ts -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 13 01:49: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 F3C26130F65 for ; Wed, 13 Feb 2019 01:49:45 -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 mFbpWuILL-Ls for ; Wed, 13 Feb 2019 01:49:44 -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 EEDA5124408 for ; Wed, 13 Feb 2019 01:49:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9692E1F; Wed, 13 Feb 2019 10:49: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 aOEmpVi9gp-w; Wed, 13 Feb 2019 10:49: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; Wed, 13 Feb 2019 10:49:41 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E9B520057; Wed, 13 Feb 2019 10:49:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FkEsrp1XCZyb; Wed, 13 Feb 2019 10:49:41 +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 089EB20055; Wed, 13 Feb 2019 10:49: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; Wed, 13 Feb 2019 10:49:40 +0100 Received: by anna.localdomain (Postfix, from userid 501) id DD78730065E298; Wed, 13 Feb 2019 10:49:38 +0100 (CET) Date: Wed, 13 Feb 2019 10:49:38 +0100 From: Juergen Schoenwaelder To: Christian Hopps CC: Joel Jaeggli , Message-ID: <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Christian Hopps , Joel Jaeggli , netmod@ietf.org References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@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: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 09:49:46 -0000 On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote: > > In any case this is general purpose meta-data after all, while some data may be immediately recognizable (e.g., ietf:routing) other data may require looking at a specification to determine it's meaning. > Frankly, I can't really tell where ietf:protocol applies or not or what exactly is ietf:signaling vs some of the other closely related tags. The descriptions are rather open ended. > All that said, if these RFC8199 are inappropriate for inclusion in this document or confusing, I'd rather remove them than stall the work. To use a routing analogy, the intent of this work is to create a method for "signaling" values, not to define the "values" themselves. Section 8.2 defines values, this section is not a signaling mechanism alone anymore. > > the idea is to further scope IETF defined tags (there may be multiple > > 'element' tags), why does this additional scoping need not apply to > > There is no intent to add additional scoping. Indeed this was part of the motivation behind the addition of the final sentence in the "Tag Value" text in v3 of the document: > > All tags 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. The 'rfc8199-' part in some of the tags does look to me like an attempt to scope 'service', 'element' etc. If this is being used, you will see that labels will use ad-hoc forms of scoping. The networking vocabulary is small and reuse of terms with different meanings in different contexts is common. If scopes are not needed, then I would argue 'rfc8199-' is not needed. Or it is needed and then it would be useful as well for ietf-qos and friends. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 13 02:19: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 278971274D0 for ; Wed, 13 Feb 2019 02:19:21 -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 1YrpHnr8lj_o for ; Wed, 13 Feb 2019 02:19:19 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 85DB7124BAA for ; Wed, 13 Feb 2019 02:19:19 -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 7711E60428; Wed, 13 Feb 2019 05:19:18 -0500 (EST) References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Juergen Schoenwaelder Cc: Christian Hopps , Joel Jaeggli , netmod@ietf.org In-reply-to: <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> Date: Wed, 13 Feb 2019 05:19:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 10:19:21 -0000 --=-=-= Content-Type: text/plain; format=flowed Juergen Schoenwaelder writes: > On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote: >> >> In any case this is general purpose meta-data after all, while some data may be immediately recognizable (e.g., ietf:routing) other data may require looking at a specification to determine it's meaning. > > Frankly, I can't really tell where ietf:protocol applies or not or > what exactly is ietf:signaling vs some of the other closely related > tags. The descriptions are rather open ended. Please make suggestions (descriptive text, remove the tag, etc) on how to fix things to clear your objections. >> All that said, if these RFC8199 are inappropriate for inclusion in this document or confusing, I'd rather remove them than stall the work. To use a routing analogy, the intent of this work is to create a method for "signaling" values, not to define the "values" themselves. > > Section 8.2 defines values, this section is not a signaling mechanism > alone anymore. Section 8.2 is there to help get things started. I'd rather remove it than perfect it. Perfect is not possible IMO, and TBH in netmod it often feels like good enough is ridiculously hard to come by. >> > the idea is to further scope IETF defined tags (there may be multiple >> > 'element' tags), why does this additional scoping need not apply to >> >> There is no intent to add additional scoping. Indeed this was part of the motivation behind the addition of the final sentence in the "Tag Value" text in v3 of the document: >> >> All tags 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. > > The 'rfc8199-' part in some of the tags does look to me like an > attempt to scope 'service', 'element' etc. If this is being used, you > will see that labels will use ad-hoc forms of scoping. The networking > vocabulary is small and reuse of terms with different meanings in > different contexts is common. If scopes are not needed, then I would > argue 'rfc8199-' is not needed. Or it is needed and then it would be > useful as well for ietf-qos and friends. RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection? Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well. Thanks, Chris. > > /js --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxj7yUACgkQLh2DDte4 MCWT5Q//VAW2iCdYToC4N5MPGFeanwfrV4sEmlTM41v+znznu+l0FJRsJDzdmk5B 30HHVVJ5quWnKsWPxFH7RF3ktGOH+SGaZJsdwKC6nFaJo7ZWfiE0z//ileBzVkQL E6AT6gXasu3LkbtT1doHBc0E8mxmvhTYrC+YTX5sREFGK+bSZfxupcY227aDX483 b0WUFIzzgciftXd2RvXjSCysU3NYYB8p9SdHEG6uNdMCHyBL+cqPN+tJ6E3K7Eoz GmlmOq1Mvuz8Xh41DCmH2IiB6gaupOv1bPRB/8HPqy9hmvVxT28qgBpHmLf+Mc3x kJ7PLKELW+8tKhVdbiyOLU+s+FQwplgRVlW4yntUkuM5uIieIZeG96/ezStRZUQQ R7HfE4B7YfAsRoLoXMdJlXKGABc4v4E5cqT3yyY89+T4K65EPa2hBAJRube3WfF8 sLLUYaA8oxFqYZgUHtJ6GibL+g5zHOa6MdQBEEu+Jh0j1d/fl2Ln3UDRx9ovbahV OH/z4jIZBI48rTeBAG/LnOcX2RjIbwdk9Ctp4y09Gy+JpWw4niS1SvVf4J3pvnVM fCaIRu5T+VOqdvn9jhzss0iqe9BYRF/IbBagkwlfDAmNbYjuWA5eret5hJn9BcAZ 3P4RVPvkaIXWDWLU9Y8RJ3hV27hCxJIWFgXmQrn4jdt3o8GJ6YY= =kWtm -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 13 03:04: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 D68D112894E; Wed, 13 Feb 2019 03:04:45 -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 YsAUm6zprC6F; Wed, 13 Feb 2019 03:04:43 -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 7D1171274D0; Wed, 13 Feb 2019 03:04:43 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id AC0C8AAC9CAE9C7CB149; Wed, 13 Feb 2019 11:04:40 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Feb 2019 11:04:40 +0000 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 13 Feb 2019 11:04:40 +0000 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml708-chm.china.huawei.com (10.201.108.57) 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; Wed, 13 Feb 2019 11:04:39 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Wed, 13 Feb 2019 19:04:30 +0800 From: Rohit R Ranade To: Joel Jaeggli , "ibagdona@gmail.com" CC: "netmod-chairs@ietf.org" , "iesg-secretary@ietf.org" , "netmod@ietf.org" Thread-Topic: Few Comments //RE: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04 Thread-Index: AdTDhJb0gYn04JakSz6JOcuemg5oyg== Date: Wed, 13 Feb 2019 11:04:29 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@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] 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: Wed, 13 Feb 2019 11:04:46 -0000 Editorial Comments: 1. Section 1, refers to RFC6020 for Yang Module, but since this document u= ses Yang Version 1.1, I feel it should refer to RFC7950 2. Section 4.3, " removed with using normal configuration", can use "remov= ed by using normal configuration" 3. Description of statement "leaf-list tag", in the Step 1), " System adde= d tags are added" can be replaced with "tags of 'system' origin are added" = as it associates System with "system" origin in a better way. 4. Description of statement "leaf-list tag", " The operational view of thi= s list", can be replaced with "The applied configuration of this list", as = it uses is a well-known term from RFC 8342. =20 5. Description of statement "leaf-list tag", " User configured tags" can b= e replaced with "tags of 'intended' origin" as it uses a well-known NMDA te= rm from RFC8342 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. 2. In the description of Yang statement "leaf-list tag", is there any reaso= n why System tags should be added first and then User configured tags ? Not= clear. 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 .=20 Suggested description " The list of tags that will not be applied to this module. By adding tags to this list, the user can prevent=20 such tags from being applied. It is not an error to add=20 tags to this list that are not associated with the module." 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-modu= le-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/draf= t-ietf-netmod-module-tags/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 13 03:22: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 85BA3128B01 for ; Wed, 13 Feb 2019 03:22: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 IocDhpxin1IA for ; Wed, 13 Feb 2019 03:22:26 -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 667261274D0 for ; Wed, 13 Feb 2019 03:22:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0C2243B; Wed, 13 Feb 2019 12:22: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 MjoWwIqfSViu; Wed, 13 Feb 2019 12:22: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; Wed, 13 Feb 2019 12:22:24 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6B9E20054; Wed, 13 Feb 2019 12:22:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GiqJdGzP3YJ3; Wed, 13 Feb 2019 12:22:24 +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 6F5C920055; Wed, 13 Feb 2019 12:22: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; Wed, 13 Feb 2019 12:22:23 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 475EA30065E783; Wed, 13 Feb 2019 12:22:21 +0100 (CET) Date: Wed, 13 Feb 2019 12:22:21 +0100 From: Juergen Schoenwaelder To: Christian Hopps CC: Joel Jaeggli , Message-ID: <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Christian Hopps , Joel Jaeggli , netmod@ietf.org References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@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] 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: Wed, 13 Feb 2019 11:22:30 -0000 First of all, let me clarify that I submitted comments, I did not raise objections. There is a difference I think. On Wed, Feb 13, 2019 at 05:19:17AM -0500, Christian Hopps wrote: > > Juergen Schoenwaelder writes: > > > On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote: > > > > > > In any case this is general purpose meta-data after all, while some data may be immediately recognizable (e.g., ietf:routing) other data may require looking at a specification to determine it's meaning. > > > > Frankly, I can't really tell where ietf:protocol applies or not or > > what exactly is ietf:signaling vs some of the other closely related > > tags. The descriptions are rather open ended. > > Please make suggestions (descriptive text, remove the tag, etc) on how to fix things to clear your objections. I generally prefer meaningful hopefully unambiguous definition. (That is multiple readers should have a high chance to come to the same conclusion when to use a tag or when to not use a tag.) I am fine with tags that do not have such a definition being removed, I am also find if someone provides a proper definition. I am not the one to provide definitions for things where I do not know what they actually mean. > > > > 'element' tags), why does this additional scoping need not apply to > > > > > > There is no intent to add additional scoping. Indeed this was part of the motivation behind the addition of the final sentence in the "Tag Value" text in v3 of the document: > > > > > > All tags 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. > > > > The 'rfc8199-' part in some of the tags does look to me like an > > attempt to scope 'service', 'element' etc. If this is being used, you > > will see that labels will use ad-hoc forms of scoping. The networking > > vocabulary is small and reuse of terms with different meanings in > > different contexts is common. If scopes are not needed, then I would > > argue 'rfc8199-' is not needed. Or it is needed and then it would be > > useful as well for ietf-qos and friends. > > RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection? I simply asked why we are inconsistent with the initial tags that we allocate. Others will want to allocate tags in the future, what do we tell them how to do it? If the idea is to go with a true flat namespace, then simply remove 'rfc8199-' from the tags and we have ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user, which lines up with ietf:routing and the like. > Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well. I am not raising objections. I asked a question. And it is fine to be told that I should shut up because we are past WG last call and the WG likes what we have (and the WG or the IETF we will later figure out what lets say ietf:protocol is really good for or whether scopes like 'rfc8199-' are a good or bad 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 Wed Feb 13 04:05:00 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 95EFE130F65; Wed, 13 Feb 2019 04:04:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton To: Cc: draft-ietf-netmod-module-tags.all@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155005949957.9572.9759688529698051075@ietfa.amsl.com> Date: Wed, 13 Feb 2019 04:04:59 -0800 Archived-At: Subject: [netmod] Yangdoctors last call review of draft-ietf-netmod-module-tags-04 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, 13 Feb 2019 12:04:59 -0000 Reviewer: Robert Wilton Review result: Ready with Nits I have reviewed this document as part of the YANG doctors directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I've already reviewed the previous revision of this document as part of WG LC, and any significant comments have already been addressed. What remains are minor nits, that would probably be spotted/addressed by the RFC editor, and I leave it to the authors discretion as to whether/how they address these: 1. It may be helpful for the introduction to state that the module conforms to NMDA (from YANG guidelines section 3.5). I.e. add the following text + reference. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. 2. Paragraph 4.1, perhaps "will be" => "is"? 3. Section 4.3, "removed with using" => "removed using" 4. The YANG module itself: 4i) NetMod => NETMOD (two places) 4ii) The RFC 2119 boilerplate should probably be updated to cover RFC 8174. 4iii) Line length is a bit long in places. I checked using pyang against 69 chars and got this, so at least line 89 should be fixed (but the RFC editor will also fix this): ietf-module-tags@2018-10-17.yang:56: warning: line length 72 exceeds 69 characters ietf-module-tags@2018-10-17.yang:57: warning: line length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:63: warning: line length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:64: warning: line length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:86: warning: line length 72 exceeds 69 characters ietf-module-tags@2018-10-17.yang:89: warning: line length 86 exceeds 69 characters 4iv) Possibly add ", but they have no operational effect" to the end of the description of masked-tag. Although, it is pretty obvious to me that they would just be ignored. 5) Section 6. - Suggest "It's" => "It is", "2" => "two", "3" => "three". - Suggest "is classifying modules in only a logical manner" => "only classifies modules in a logical manner" 6) Section 7.1. - Since these are guidelines, I suggest "can" => "MAY". 7) Section 8.1. - I note that this section uses "SHOULD", and section 3.4 just says reserved. Should section 3.4 also use RFC2119 language to be aigned at all? From nobody Wed Feb 13 05:38: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 340C01310C6 for ; Wed, 13 Feb 2019 05:38:03 -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 x4muR0tEH4Nd for ; Wed, 13 Feb 2019 05:38:01 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 39FFB13108B for ; Wed, 13 Feb 2019 05:38:01 -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 39D6A60428; Wed, 13 Feb 2019 08:38:00 -0500 (EST) References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Juergen Schoenwaelder Cc: Christian Hopps , Joel Jaeggli , netmod@ietf.org In-reply-to: <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> Date: Wed, 13 Feb 2019 08:37:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 13:38:10 -0000 --=-=-= Content-Type: text/plain; format=flowed Juergen Schoenwaelder writes: >> > The 'rfc8199-' part in some of the tags does look to me like an >> > attempt to scope 'service', 'element' etc. If this is being used, you >> > will see that labels will use ad-hoc forms of scoping. The networking >> > vocabulary is small and reuse of terms with different meanings in >> > different contexts is common. If scopes are not needed, then I would >> > argue 'rfc8199-' is not needed. Or it is needed and then it would be >> > useful as well for ietf-qos and friends. >> >> RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection? > > I simply asked why we are inconsistent with the initial tags that we > allocate. Others will want to allocate tags in the future, what do we > tell them how to do it? If the idea is to go with a true flat > namespace, then simply remove 'rfc8199-' from the tags and we have > ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user, > which lines up with ietf:routing and the like. But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is what "rfc8199-element" is supposed to be. It'll need to be something like "ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess. I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up this introducing scope stuff. What if there was no "-" symbol used (i.e., "ietf:rfc8199element"? The normative text says that we are defining no structure outside the prefix (i.e., it's flat). I believe what your saying is that if you ignore this normative text and just look at the "ietf:rfc8199-element" tags by themselves, one might imagine some meaning of scope. Do we need to repeat or reword the fact we are defining no structure beyond the prefix to make this more clear so people don't start imagining structures where we've normatively said they don't exist? >> Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well. > > I am not raising objections. I asked a question. And it is fine to be > told that I should shut up because we are past WG last call and the WG > likes what we have (and the WG or the IETF we will later figure out > what lets say ietf:protocol is really good for or whether scopes like > 'rfc8199-' are a good or bad idea). Your opinion rightly carries a lot of weight in this group, and so your questions need to be addressed even though they are coming late in the process. Thanks, Chris. > > /js --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxkHbcACgkQLh2DDte4 MCUh2w/+L6ssINDFrAVM/ngb2dBaIupApDwQ1AqtyZF82nKsyhZkM8SW96Sz5SyL rYmG1fJYXdJi1RvdvcJccMXgc9NAhZwsDs6rjiYwCXcaLlqWGy0+bS9tD2rA6C4Q MyeZRXW0jGgmN3n7RYC9YA/8oMjIhfYbvu3RAF7AlRlEx3pHJHUHLh3MuulfFIW6 k6Rli/rDe3bMVNJbZ1Ivg3caLfbtIUsb3mLiR+XFt8wntwYBB9Y19ylXJNiwou2M KiUDfstL5N8knPx+KVCNCxqYEmiGMrwal+xTMEDHEHt798SL+pJDHnuP/MbQNSZH tMVyuIWqu0nthtVvhEzK1bsQhM5XlUVEsS0KOU/GXbXGrpNXpq9u+J3Bg+juI/+T PAQCK6eEFpFOdFGOHDgaoH/KWvcdUUnKEywV4XmXDtkv6OhT7j0ytc+lJXK4zLuW frMro7idnVFFdcbcRZxsElUek3J/XxZa8T+FWZpE3iUOzUFv/EVRvjQ/K9O2Azc+ HxSGuQpGgdzp2PauifV/WoL5Qgzgu++x445JwQ9X7P2MuytG65TMmK/Y9atrzWLG Vly+Wcd7vOyjVgy7jHdzfHtnWk5hcdf4ykmXFedDJkCjBaXoYifT1gJ1dM5+7wr6 a9jJ8pKMXS7yZeTs9jzZYRyFIApVeMzMUOytElnzs7/Ipzp4U4A= =0vwb -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 13 05:43: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 3F67A131067 for ; Wed, 13 Feb 2019 05:43: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 JCMscGx4h8BX for ; Wed, 13 Feb 2019 05:43:40 -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 220E913107B for ; Wed, 13 Feb 2019 05:43:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 891AA9A; Wed, 13 Feb 2019 14:43:37 +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 l0ySwTEHUrst; Wed, 13 Feb 2019 14:43:37 +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; Wed, 13 Feb 2019 14:43:37 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7165A20055; Wed, 13 Feb 2019 14:43:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kh5yM37XnH52; Wed, 13 Feb 2019 14:43:37 +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 EB43920054; Wed, 13 Feb 2019 14:43:36 +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; Wed, 13 Feb 2019 14:43:36 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 22AF230065F195; Wed, 13 Feb 2019 14:43:34 +0100 (CET) Date: Wed, 13 Feb 2019 14:43:34 +0100 From: Juergen Schoenwaelder To: Christian Hopps CC: Joel Jaeggli , Message-ID: <20190213134334.p2cr7a4yp77ydxq2@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Christian Hopps , Joel Jaeggli , netmod@ietf.org References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> <20190213112221.j5s7uwm2jnlmv6sz@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] 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: Wed, 13 Feb 2019 13:43:49 -0000 On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote: > > Juergen Schoenwaelder writes: > > > > > The 'rfc8199-' part in some of the tags does look to me like an > > > > attempt to scope 'service', 'element' etc. If this is being used, you > > > > will see that labels will use ad-hoc forms of scoping. The networking > > > > vocabulary is small and reuse of terms with different meanings in > > > > different contexts is common. If scopes are not needed, then I would > > > > argue 'rfc8199-' is not needed. Or it is needed and then it would be > > > > useful as well for ietf-qos and friends. > > > > > > RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection? > > > > I simply asked why we are inconsistent with the initial tags that we > > allocate. Others will want to allocate tags in the future, what do we > > tell them how to do it? If the idea is to go with a true flat > > namespace, then simply remove 'rfc8199-' from the tags and we have > > ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user, > > which lines up with ietf:routing and the like. > > But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is what "rfc8199-element" is supposed to be. It'll need to be something like "ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess. Seems arbitrary what we call too generic and what not. To me, ietf:protocol is also quite generic. > I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up this introducing scope stuff. What if there was no "-" symbol used (i.e., "ietf:rfc8199element"? You may miss the point I am making. > The normative text says that we are defining no structure outside the prefix (i.e., it's flat). I believe what your saying is that if you ignore this normative text and just look at the "ietf:rfc8199-element" tags by themselves, one might imagine some meaning of scope. Do we need to repeat or reword the fact we are defining no structure beyond the prefix to make this more clear so people don't start imagining structures where we've normatively said they don't exist? > You apparently use rfc8199- to scope 'element'... > > > Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well. > > > > I am not raising objections. I asked a question. And it is fine to be > > told that I should shut up because we are past WG last call and the WG > > likes what we have (and the WG or the IETF we will later figure out > > what lets say ietf:protocol is really good for or whether scopes like > > 'rfc8199-' are a good or bad idea). > > Your opinion rightly carries a lot of weight in this group, and so your questions need to be addressed even though they are coming late in the process. > Not true. I am happy to be shut down. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 13 06:15: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 E23B612D827 for ; Wed, 13 Feb 2019 06:15:50 -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 hX5XnpiVG0tb for ; Wed, 13 Feb 2019 06:15:49 -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 D10D71274D0 for ; Wed, 13 Feb 2019 06:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4747; q=dns/txt; s=iport; t=1550067347; x=1551276947; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=mRJ8AuQZrila6YDMUIIym39yS11Vl1mHVTajCDBso+I=; b=HwJDYPQd2KAhUceQEhVESCw7IEEMZFwmJcL7FaBJ3ojwSQywVVy/vJl2 KTBTvs+zE/rDfyZKzmIYnOP62i4nuqVHbalAMINU0xtVfJY5KoZGFx9sK UQBZOrsgAzYLeUxR1USJSzeWs2sUCnVOeF32Dd3tFRAjSJ1U8NcmSIYr1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAABQJWRc/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYFbgWEgEieEBYh5jHQIJXyXK4FnDYRsAoN7OBIBAwEBAgE?= =?us-ascii?q?BAm0ohUsBBSMPAQUvBQgCEwsOAggCAiYCAlcGAQwGAgEBgyCCAqlMgS+FRIR?= =?us-ascii?q?ngQuLUIFAP4ERJwyCKjWBQQGDJ4MhglcCijSYcwmSTQYCF4FthVKDGIgYijW?= =?us-ascii?q?KaoclgV0hgVYzGggbFYMngigMCxNtAQKNGz8DMJAAAQE?= X-IronPort-AV: E=Sophos;i="5.58,365,1544486400"; d="scan'208";a="10065861" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2019 14:15:44 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x1DEFgh5013596; Wed, 13 Feb 2019 14:15:43 GMT To: Christian Hopps , Joel Jaeggli , netmod@ietf.org References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> From: Robert Wilton Message-ID: <49911142-303e-53d3-8dd9-cdfec36c253f@cisco.com> Date: Wed, 13 Feb 2019 14:15:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.84, dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 14:15:51 -0000 My opinion is that we should just push the doc as it stands now. I don't know whether we have the perfect set of base tags defined in section 8.2, but I don't think that this really matters.  One of the things that I prefer about tags, compared to the alternative approach of having a rigid structure that all YANG modules have to fit into, is that the set of tags can evolve over time, and if a user doesn't like the set of tags, then they can just fix them via config.  If the "ietf:lmp" tag turns out not to be quite right, or not useful, then we just stop using it, and perhaps mark it as deprecated in IANA. I think that it is more important to get the draft finished, particularly standardizing the YANG model and semantics.  Once folks start to tag YANG modules, we will gain experience figuring out what the right/useful tags are, and they can be documented in whatever way is most appropriate. Thanks, Rob On 13/02/2019 11:22, Juergen Schoenwaelder wrote: > First of all, let me clarify that I submitted comments, I did not > raise objections. There is a difference I think. > > On Wed, Feb 13, 2019 at 05:19:17AM -0500, Christian Hopps wrote: >> Juergen Schoenwaelder writes: >> >>> On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote: >>>> In any case this is general purpose meta-data after all, while some data may be immediately recognizable (e.g., ietf:routing) other data may require looking at a specification to determine it's meaning. >>> Frankly, I can't really tell where ietf:protocol applies or not or >>> what exactly is ietf:signaling vs some of the other closely related >>> tags. The descriptions are rather open ended. >> Please make suggestions (descriptive text, remove the tag, etc) on how to fix things to clear your objections. > I generally prefer meaningful hopefully unambiguous definition. (That > is multiple readers should have a high chance to come to the same > conclusion when to use a tag or when to not use a tag.) I am fine with > tags that do not have such a definition being removed, I am also find > if someone provides a proper definition. I am not the one to provide > definitions for things where I do not know what they actually mean. > >>>>> 'element' tags), why does this additional scoping need not apply to >>>> There is no intent to add additional scoping. Indeed this was part of the motivation behind the addition of the final sentence in the "Tag Value" text in v3 of the document: >>>> >>>> All tags 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. >>> The 'rfc8199-' part in some of the tags does look to me like an >>> attempt to scope 'service', 'element' etc. If this is being used, you >>> will see that labels will use ad-hoc forms of scoping. The networking >>> vocabulary is small and reuse of terms with different meanings in >>> different contexts is common. If scopes are not needed, then I would >>> argue 'rfc8199-' is not needed. Or it is needed and then it would be >>> useful as well for ietf-qos and friends. >> RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection? > I simply asked why we are inconsistent with the initial tags that we > allocate. Others will want to allocate tags in the future, what do we > tell them how to do it? If the idea is to go with a true flat > namespace, then simply remove 'rfc8199-' from the tags and we have > ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user, > which lines up with ietf:routing and the like. > >> Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well. > > I am not raising objections. I asked a question. And it is fine to be > told that I should shut up because we are past WG last call and the WG > likes what we have (and the WG or the IETF we will later figure out > what lets say ietf:protocol is really good for or whether scopes like > 'rfc8199-' are a good or bad idea). > > /js > From nobody Wed Feb 13 06:40: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 001A612D827 for ; Wed, 13 Feb 2019 06:40:55 -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 kVQdir4snXeX for ; Wed, 13 Feb 2019 06:40:54 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF4129441 for ; Wed, 13 Feb 2019 06:40:54 -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 A439260428; Wed, 13 Feb 2019 09:40:53 -0500 (EST) References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> <20190213134334.p2cr7a4yp77ydxq2@anna.jacobs.jacobs-university.de> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Juergen Schoenwaelder Cc: Christian Hopps , Joel Jaeggli , netmod@ietf.org In-reply-to: <20190213134334.p2cr7a4yp77ydxq2@anna.jacobs.jacobs-university.de> Date: Wed, 13 Feb 2019 09:40:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 14:40:56 -0000 --=-=-= Content-Type: text/plain; format=flowed Juergen Schoenwaelder writes: > On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote: >> >> Juergen Schoenwaelder writes: >> >> But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is what "rfc8199-element" is supposed to be. It'll need to be something like "ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess. > > Seems arbitrary what we call too generic and what not. To me, > ietf:protocol is also quite generic. But, "ietf:protocol" is in fact intended and defined to be generic, "ietf:rfc8199-element" is not defined as generic at all. It's defined very clearly in RFC8199. Using a broad tag "ietf:element" for such a narrow definition is not appropriate. Again the normative text should take precedence here, so I'm inclined to leave things as they are, unless you'd like a more restricted alternative. >> I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up this introducing scope stuff. What if there was no "-" symbol used (i.e., "ietf:rfc8199element"? > > You may miss the point I am making. > >> The normative text says that we are defining no structure outside the prefix (i.e., it's flat). I believe what your saying is that if you ignore this normative text and just look at the "ietf:rfc8199-element" tags by themselves, one might imagine some meaning of scope. Do we need to repeat or reword the fact we are defining no structure beyond the prefix to make this more clear so people don't start imagining structures where we've normatively said they don't exist? >> > > You apparently use rfc8199- to scope 'element'... This is getting a bit too abstract for me. Its a tag with a defined meaning. I actually think its very clear and informative as written. I think someone seeing it will immediately open RFC8199 and find the definition for what it means. And, if that's what happens then it's a good choice, not a bad one. >> > > Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well. >> > >> > I am not raising objections. I asked a question. And it is fine to be >> > told that I should shut up because we are past WG last call and the WG >> > likes what we have (and the WG or the IETF we will later figure out >> > what lets say ietf:protocol is really good for or whether scopes like >> > 'rfc8199-' are a good or bad idea). >> >> Your opinion rightly carries a lot of weight in this group, and so your questions need to be addressed even though they are coming late in the process. > > Not true. I am happy to be shut down. In that case, seeing as we have normative text that directly addresses the flatness of the space, unless you have some suggestions on simple changes I'd like to move on. :) Thanks, Chris. > > /js --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxkLHQACgkQLh2DDte4 MCVjVw/+L2X/nElRfaV2oMA7rQfQROoXy+8k57+bCbfLyeGzrP0kvabNzegHHaLf 6RjD8rQvAHIkMIfTULhMjLJsZIzmBYodeEj4sEvy5LbCM1XoBNHRONeBUu9YQ2D3 bHZwUeixY3Db9t4rHSnvoOxP22AfYwRVqkGdIvmvoE9+gTrZNjNMx2LDKpIn2h/B ELhZ6ryrXPEzCKOTRx/tzzuF3RX5+rk2ppM4xDqzypNUTzifYBbiaAEqFo70/p5n 3zlYTc8g8aIoCM96NWSdd5lUa8nAgNNvp/cPrSRNjW/UrWHfxf/WSDKoFGEUWyU4 ai1JwUpz9DtoVl1uodgxwfiEkfNUsIV5j3nHxO82qHskwtIEFMwGooJHnyqoWfoW za6x6bmRsVyZDspY88bnRnKGYKcY5SUo67lP46IdwopRrUHalSkbLebrgEo0Gy0L 8wrL+9KxqtKOM2EhdzQkdenD7J8ptmb/+E9qZ2lY5B8Zya5W0JnTzgjcM8x4v1gz ZGcsXdCb67dXSQRtcDFLcvXtdQXdojG8XRPRjptBNv9u+v0JEtjEE+yAWEmdpUZZ sq6twah7CFuiQj9Zd+be/pck0mmwUg396EFJB40tfWjArvYMiloJj3TPEsW+cylz e7pA85FaZeVP2ZtB2163nfg4D0iPI+Q08XkIIVqdYTDzQPUqWwM= =ruZI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 13 07:16: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 A0C30126C7E for ; Wed, 13 Feb 2019 07:16:10 -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 2KrsZLjoPgj1 for ; Wed, 13 Feb 2019 07:16:07 -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 67D8A1274D0 for ; Wed, 13 Feb 2019 07:16:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 133F837; Wed, 13 Feb 2019 16:16:06 +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 3_yjH0rhXohI; Wed, 13 Feb 2019 16:16:06 +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; Wed, 13 Feb 2019 16:16:06 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0AA520056; Wed, 13 Feb 2019 16:16:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sDxM7FzjSpz1; Wed, 13 Feb 2019 16:16: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 B97DE20054; Wed, 13 Feb 2019 16:16: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; Wed, 13 Feb 2019 16:16:05 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 05D0030065F483; Wed, 13 Feb 2019 16:16:03 +0100 (CET) Date: Wed, 13 Feb 2019 16:16:03 +0100 From: Juergen Schoenwaelder To: Christian Hopps CC: Joel Jaeggli , Message-ID: <20190213151603.xbpdfrioqruf3lmm@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Christian Hopps , Joel Jaeggli , netmod@ietf.org References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de> <20190213134334.p2cr7a4yp77ydxq2@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] 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: Wed, 13 Feb 2019 15:16:11 -0000 On Wed, Feb 13, 2019 at 09:40:52AM -0500, Christian Hopps wrote: > > But, "ietf:protocol" is in fact intended and defined to be generic, "ietf:rfc8199-element" is not defined as generic at all. It's defined very clearly in RFC8199. Using a broad tag "ietf:element" for such a narrow definition is not appropriate. > For me, ietf:element has a much more concrete definition than ietf:protocol. I can probably decide when to tag a module with ietf:element, I have much less an idea when to tag a module with ietf:protocol. But I will shut up, my concerns have been recorded in the archives, the future will tell whether we get into tagging debates or not and whether the base tags defined in the document provide a decent example for people defining more tags in the future. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 13 09:12: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 3E122130E7A for ; Wed, 13 Feb 2019 09:11:55 -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 XyJx107KgpkU for ; Wed, 13 Feb 2019 09:11:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 08D0F1289FA for ; Wed, 13 Feb 2019 09:11:52 -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 F3EDC1AE0141; Wed, 13 Feb 2019 18:11:50 +0100 (CET) Date: Wed, 13 Feb 2019 18:11:50 +0100 (CET) Message-Id: <20190213.181150.458815026514737950.mbj@tail-f.com> To: chopps@chopps.org Cc: j.schoenwaelder@jacobs-university.de, joelja@gmail.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190213134334.p2cr7a4yp77ydxq2@anna.jacobs.jacobs-university.de> 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] 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: Wed, 13 Feb 2019 17:11:57 -0000 Hi, I think one concern with "rfc8199-xxx" is that if this RFC gets reved, the name will be misleading. I also agree that "element" is too vague. Since 8199 doesn't use the terms "element" and "service", but "network element" and "network service", how about these changes: ietf:rfc8199-element --> ietf:network-element ietf:rfc8199-service --> ietf:network-service ietf:rfc8199-vendor --> ietf:vendor-defined ietf:rfc8199-user --> ietf:user-defined ietf:rfc8199-standard --> ietf:standard-defined (or sdo-defined?) If we make these changes, we have to revise the current "ietf:network-service". Maybe "ietf:network-service-protocol". /martin Christian Hopps wrote: > > Juergen Schoenwaelder writes: > > > On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote: > >> > >> Juergen Schoenwaelder writes: > >> > >> But, ietf:element is too generic to assign the meaning "RFC8199 module > >> classification of element" which is what "rfc8199-element" is supposed > >> to be. It'll need to be something like "ietf:module-class-element" or > >> "ietf:an-rfc8199-elemenet" or nothing I guess. > > > > Seems arbitrary what we call too generic and what not. To me, > > ietf:protocol is also quite generic. > > But, "ietf:protocol" is in fact intended and defined to be generic, > "ietf:rfc8199-element" is not defined as generic at all. It's defined > very clearly in RFC8199. Using a broad tag "ietf:element" for such a > narrow definition is not appropriate. > > Again the normative text should take precedence here, so I'm inclined > to leave things as they are, unless you'd like a more restricted > alternative. > > >> I have this suspicion that if it had been "ietf:an-rfc8199-element" > >> you might not have brought up this introducing scope stuff. What if > >> there was no "-" symbol used (i.e., "ietf:rfc8199element"? > > > > You may miss the point I am making. > > > >> The normative text says that we are defining no structure outside the > >> prefix (i.e., it's flat). I believe what your saying is that if you > >> ignore this normative text and just look at the "ietf:rfc8199-element" > >> tags by themselves, one might imagine some meaning of scope. Do we > >> need to repeat or reword the fact we are defining no structure beyond > >> the prefix to make this more clear so people don't start imagining > >> structures where we've normatively said they don't exist? > >> > > > > You apparently use rfc8199- to scope 'element'... > > This is getting a bit too abstract for me. Its a tag with a defined > meaning. I actually think its very clear and informative as written. I > think someone seeing it will immediately open RFC8199 and find the > definition for what it means. And, if that's what happens then it's a > good choice, not a bad one. > > >> > > Please help clear your objections here as we're in the final stages of > >> > > publication, and raising objections now I think should be accompanied > >> > > with suggestions on how to clear them as well. > >> > > >> > I am not raising objections. I asked a question. And it is fine to be > >> > told that I should shut up because we are past WG last call and the WG > >> > likes what we have (and the WG or the IETF we will later figure out > >> > what lets say ietf:protocol is really good for or whether scopes like > >> > 'rfc8199-' are a good or bad idea). > >> > >> Your opinion rightly carries a lot of weight in this group, and so > >> your questions need to be addressed even though they are coming late > >> in the process. > > > > Not true. I am happy to be shut down. > > In that case, seeing as we have normative text that directly addresses > the flatness of the space, > unless you have some suggestions on simple changes I'd like to move > on. :) > > Thanks, > Chris. > > > > > /js > From nobody Wed Feb 13 12:31: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 2449B12DF71 for ; Wed, 13 Feb 2019 12:31:14 -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 4N9wABpjWz3b for ; Wed, 13 Feb 2019 12:31:10 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9683B1200B3 for ; Wed, 13 Feb 2019 12:31:10 -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 81AEE604CC; Wed, 13 Feb 2019 15:31:09 -0500 (EST) References: <20190213134334.p2cr7a4yp77ydxq2@anna.jacobs.jacobs-university.de> <20190213.181150.458815026514737950.mbj@tail-f.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Martin Bjorklund Cc: chopps@chopps.org, j.schoenwaelder@jacobs-university.de, joelja@gmail.com, netmod@ietf.org Date: Wed, 13 Feb 2019 15:28:54 -0500 Message-ID: In-reply-to: <20190213.181150.458815026514737950.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] 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: Wed, 13 Feb 2019 20:31:14 -0000 --=-=-= Content-Type: text/plain; format=flowed Martin Bjorklund writes: > Hi, > > I think one concern with "rfc8199-xxx" is that if this RFC gets reved, > the name will be misleading. I also agree that "element" is too > vague. Isn't this why we have "Updates" and "Obsoletes" for? If this all didn't work we could never refer to our standards by RFC number anywhere, right? Also, the value in the registry is going to point at us and us to RFC8199 no matter what string we end up with. I'm not stuck on this though, so if you still think we need to change I'll take your suggestion, but add the suffix "-class" to be more specific and avoid conflicting with "ietf:network-service" at the same time. Also can change to "sdo-defined-class". Thanks, Chris. > Since 8199 doesn't use the terms "element" and "service", but "network > element" and "network service", how about these changes: > > ietf:rfc8199-element --> ietf:network-element > ietf:rfc8199-service --> ietf:network-service > ietf:rfc8199-vendor --> ietf:vendor-defined > ietf:rfc8199-user --> ietf:user-defined > ietf:rfc8199-standard --> ietf:standard-defined (or sdo-defined?) > > If we make these changes, we have to revise the current > "ietf:network-service". Maybe "ietf:network-service-protocol". > > > > /martin > > > Christian Hopps wrote: >> >> Juergen Schoenwaelder writes: >> >> > On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote: >> >> >> >> Juergen Schoenwaelder writes: >> >> >> >> But, ietf:element is too generic to assign the meaning "RFC8199 module >> >> classification of element" which is what "rfc8199-element" is supposed >> >> to be. It'll need to be something like "ietf:module-class-element" or >> >> "ietf:an-rfc8199-elemenet" or nothing I guess. >> > >> > Seems arbitrary what we call too generic and what not. To me, >> > ietf:protocol is also quite generic. >> >> But, "ietf:protocol" is in fact intended and defined to be generic, >> "ietf:rfc8199-element" is not defined as generic at all. It's defined >> very clearly in RFC8199. Using a broad tag "ietf:element" for such a >> narrow definition is not appropriate. >> >> Again the normative text should take precedence here, so I'm inclined >> to leave things as they are, unless you'd like a more restricted >> alternative. >> >> >> I have this suspicion that if it had been "ietf:an-rfc8199-element" >> >> you might not have brought up this introducing scope stuff. What if >> >> there was no "-" symbol used (i.e., "ietf:rfc8199element"? >> > >> > You may miss the point I am making. >> > >> >> The normative text says that we are defining no structure outside the >> >> prefix (i.e., it's flat). I believe what your saying is that if you >> >> ignore this normative text and just look at the "ietf:rfc8199-element" >> >> tags by themselves, one might imagine some meaning of scope. Do we >> >> need to repeat or reword the fact we are defining no structure beyond >> >> the prefix to make this more clear so people don't start imagining >> >> structures where we've normatively said they don't exist? >> >> >> > >> > You apparently use rfc8199- to scope 'element'... >> >> This is getting a bit too abstract for me. Its a tag with a defined >> meaning. I actually think its very clear and informative as written. I >> think someone seeing it will immediately open RFC8199 and find the >> definition for what it means. And, if that's what happens then it's a >> good choice, not a bad one. >> >> >> > > Please help clear your objections here as we're in the final stages of >> >> > > publication, and raising objections now I think should be accompanied >> >> > > with suggestions on how to clear them as well. >> >> > >> >> > I am not raising objections. I asked a question. And it is fine to be >> >> > told that I should shut up because we are past WG last call and the WG >> >> > likes what we have (and the WG or the IETF we will later figure out >> >> > what lets say ietf:protocol is really good for or whether scopes like >> >> > 'rfc8199-' are a good or bad idea). >> >> >> >> Your opinion rightly carries a lot of weight in this group, and so >> >> your questions need to be addressed even though they are coming late >> >> in the process. >> > >> > Not true. I am happy to be shut down. >> >> In that case, seeing as we have normative text that directly addresses >> the flatness of the space, >> unless you have some suggestions on simple changes I'd like to move >> on. :) >> >> Thanks, >> Chris. >> >> > >> > /js >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxkfowACgkQLh2DDte4 MCXJ9hAApUT8BcaTRxqObF/KPentpxtt7lV1l8fz9M7Qj88PYP0aN0TarI7VAs8/ qB/6LdLp/Vyke3NFE/iHecmFp18fG6gxE4iSNjv7cwxjJNQevuhMpNtgprvHcp70 OoL5uoqXKaICf48EOIWWGKU/D1olBgh4Zg5hvimo/VALHTe8sOjWdVgVKxko2aw6 cjY/FZJV98TdDyKxXgPIj75vsGoQPEG36BVHQMIgOVUgvaYzM4oONZkSFbQwolGS sW2fxw1ml4pzfT/8/DSGfo05DfymgerMV/YlgAx2xDURZk7ZhudU/WOmhZ1xm71J 4VXnAfXxaTIyn5bUNIi6fg9NaJUIQo6GVkv1i/5k5tSPuZKlhe+3uj6aHCAFvjI6 79UE62rLqvsf9KswpN1tJbREndmSHrr4nPg2WIxFZeA04qjREqBZ4dh+zqdJjhOY 1TCYRDgcipCEXYq2K+liOTeLyDA8nLN0qNoLrM/wSnOtoZ4vxA3Jk5+6tjypS5f+ kXFREQIt8XDEhRB38QkAxSofYTawIzyA+hpb/BXGhiz7EhjScC++NoN5xJr0bngV o3eyT6IUjhqmAo85ocPoLZa+LRvBwZ5THQ5ZTKCTYde0o+ZMpqSiIG6jMmGhrn+8 6X8gGr/nIzvlZNo18uLEUjUCXQyB/MLxewdI0UG5cwrIEkwDb10= =/EfC -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 13 12:40: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 6AEFF128B01 for ; Wed, 13 Feb 2019 12:40: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 MBrbPgkjmMmJ for ; Wed, 13 Feb 2019 12:40: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 1EE161200B3 for ; Wed, 13 Feb 2019 12:40: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 EC4141AE0451; Wed, 13 Feb 2019 21:40:22 +0100 (CET) Date: Wed, 13 Feb 2019 21:40:22 +0100 (CET) Message-Id: <20190213.214022.2185430687328905888.mbj@tail-f.com> To: chopps@chopps.org Cc: j.schoenwaelder@jacobs-university.de, joelja@gmail.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190213.181150.458815026514737950.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] 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: Wed, 13 Feb 2019 20:40:27 -0000 Hi, Christian Hopps wrote: > > Martin Bjorklund writes: > > > Hi, > > > > I think one concern with "rfc8199-xxx" is that if this RFC gets reved, > > the name will be misleading. I also agree that "element" is too > > vague. > > Isn't this why we have "Updates" and "Obsoletes" for? If this all > didn't work we could never refer to our standards by RFC number > anywhere, right? Also, the value in the registry is going to point at > us and us to RFC8199 no matter what string we end up with. I'm not > stuck on this though, so if you still think we need to change I'll > take your suggestion, but add the suffix "-class" to be more specific > and avoid conflicting with "ietf:network-service" at the same > time. Also can change to "sdo-defined-class". I really don't have a strong opinion; this was just a suggestion to solve the issue. /martin > > Thanks, > Chris. > > > Since 8199 doesn't use the terms "element" and "service", but "network > > element" and "network service", how about these changes: > > > > ietf:rfc8199-element --> ietf:network-element > > ietf:rfc8199-service --> ietf:network-service > > ietf:rfc8199-vendor --> ietf:vendor-defined > > ietf:rfc8199-user --> ietf:user-defined > > ietf:rfc8199-standard --> ietf:standard-defined (or sdo-defined?) > > > > If we make these changes, we have to revise the current > > "ietf:network-service". Maybe "ietf:network-service-protocol". > > > > > > > > /martin > > > > > > Christian Hopps wrote: > >> > >> Juergen Schoenwaelder writes: > >> > >> > On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote: > >> >> > >> >> Juergen Schoenwaelder writes: > >> >> > >> >> But, ietf:element is too generic to assign the meaning "RFC8199 module > >> >> classification of element" which is what "rfc8199-element" is supposed > >> >> to be. It'll need to be something like "ietf:module-class-element" or > >> >> "ietf:an-rfc8199-elemenet" or nothing I guess. > >> > > >> > Seems arbitrary what we call too generic and what not. To me, > >> > ietf:protocol is also quite generic. > >> > >> But, "ietf:protocol" is in fact intended and defined to be generic, > >> "ietf:rfc8199-element" is not defined as generic at all. It's defined > >> very clearly in RFC8199. Using a broad tag "ietf:element" for such a > >> narrow definition is not appropriate. > >> > >> Again the normative text should take precedence here, so I'm inclined > >> to leave things as they are, unless you'd like a more restricted > >> alternative. > >> > >> >> I have this suspicion that if it had been "ietf:an-rfc8199-element" > >> >> you might not have brought up this introducing scope stuff. What if > >> >> there was no "-" symbol used (i.e., "ietf:rfc8199element"? > >> > > >> > You may miss the point I am making. > >> > > >> >> The normative text says that we are defining no structure outside the > >> >> prefix (i.e., it's flat). I believe what your saying is that if you > >> >> ignore this normative text and just look at the "ietf:rfc8199-element" > >> >> tags by themselves, one might imagine some meaning of scope. Do we > >> >> need to repeat or reword the fact we are defining no structure beyond > >> >> the prefix to make this more clear so people don't start imagining > >> >> structures where we've normatively said they don't exist? > >> >> > >> > > >> > You apparently use rfc8199- to scope 'element'... > >> > >> This is getting a bit too abstract for me. Its a tag with a defined > >> meaning. I actually think its very clear and informative as written. I > >> think someone seeing it will immediately open RFC8199 and find the > >> definition for what it means. And, if that's what happens then it's a > >> good choice, not a bad one. > >> > >> >> > > Please help clear your objections here as we're in the final stages > >> >> > > of > >> >> > > publication, and raising objections now I think should be accompanied > >> >> > > with suggestions on how to clear them as well. > >> >> > > >> >> > I am not raising objections. I asked a question. And it is fine to be > >> >> > told that I should shut up because we are past WG last call and the WG > >> >> > likes what we have (and the WG or the IETF we will later figure out > >> >> > what lets say ietf:protocol is really good for or whether scopes like > >> >> > 'rfc8199-' are a good or bad idea). > >> >> > >> >> Your opinion rightly carries a lot of weight in this group, and so > >> >> your questions need to be addressed even though they are coming late > >> >> in the process. > >> > > >> > Not true. I am happy to be shut down. > >> > >> In that case, seeing as we have normative text that directly addresses > >> the flatness of the space, > >> unless you have some suggestions on simple changes I'd like to move > >> on. :) > >> > >> Thanks, > >> Chris. > >> > >> > > >> > /js > >> From nobody Wed Feb 13 22:49: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 8CD87130FFE for ; Wed, 13 Feb 2019 22:49:37 -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, FREEMAIL_FROM=0.001, 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=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 0dGIM_lxFrC0 for ; Wed, 13 Feb 2019 22:49:36 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 B2FDC130FFC for ; Wed, 13 Feb 2019 22:49:35 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id e5so5669003qtr.12 for ; Wed, 13 Feb 2019 22:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Umx2vB80LFjP8YJmQujtmsXsGeimlVVAcxrv45IerOI=; b=qWOsC250OIekng08OKTejuc45sV1l1faFmafbJY20pdzmYT1YoE78aSqBf5bL4md8o zFaDfesWcisY84j1j7UU6fj8BH3Q+F/0vGIaESpmt+DK4OerUobHLm7cYyILcwg9mv5P bEw6aapHFOHRddCU11RlWLyLD0xGMqwYBongOwGS5SfFw/gk4AtAN6vlGe1B1NEEJVcG +r2Q+MQBiis99Pqw2hq9vejGCT5qRHA3bl+5239PRwijkDI1BOUjbWoZXlz1lMto8O7i Ge3hnisejavwcNsm9HWjMmsIy8wWESWBhB06gpVNynrFNln0ixKm6JU/v0k+sK2748lc 2+jg== 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=Umx2vB80LFjP8YJmQujtmsXsGeimlVVAcxrv45IerOI=; b=S+HGtFjqm10ud47EmNxY2sj/Hxlz7aToQggoKp/3L41FaApaIRh6N3aInxWOir1mkN WHzKbgbjUUHEqOG5O+PNwUbZIY7frV7gTDCO8+xK2WZErtjL/AChFO8bPCpOH8e3hlF9 r9LR3pM3YOQF0b7nXmAa0zNliYlq7wmJ7nnNydzvUEj45Kx6JFxSkH4pJBnwIo7EQ5Sg MCb41Bk7DPPASZt1Owb6KQunmA7z4Kbj8K+5PXyM1uQO4R87fIuxRvPZVyHjzBaypGO8 cY5nLzRYr07indz+uja8L48Ubu1b0GsQkABVviqxFvCkd4mgbsyjHdV1/EmbIBkkKmzQ 0/kg== X-Gm-Message-State: AHQUAuZFFKrePPbuvKMk1/fwxND5BUcZ1dOmvf0M+4HJGLaLSrnSXCi+ Zd0xrpAgvP+qeux/x12Qehi3xdk3EquoKpFhP2NR3A== X-Google-Smtp-Source: AHgI3Ibbo0j/6ELe8nR8o9eJWsAm0JlBEwpea1DfwXnUKM8eK/u1WsIBkJljUINYGuVQFosjhmAJMpRuHBqpcv4RCr8= X-Received: by 2002:a0c:ad0d:: with SMTP id u13mr1650175qvc.231.1550126974277; Wed, 13 Feb 2019 22:49:34 -0800 (PST) MIME-Version: 1.0 From: Amar Jadagoud Date: Thu, 14 Feb 2019 12:19:22 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000a89f240581d50f07" Archived-At: Subject: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 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 Feb 2019 06:49:38 -0000 --000000000000a89f240581d50f07 Content-Type: text/plain; charset="UTF-8" Hi All, I have a question regarding encoding of origin annotation along with other annotation (with-defaults) in JSON metadata encoding format. Suppose if below is the GET method : GET /restconf/ds/ietf-datastores:operational/ietf-interface:interfaces/interface=eth1?with-defaults=report-all-tagged&with-origin HTTP/1.1 How both origin and with-defaults annotations should be encoded in the JSON metadata encoding format? Currently in restconf RFC 8040, in section 5.3.2, example with only one annotation is provided. Refering to this example, whether multiple annotation representation should be like below? { "example:interface" : [ { "name" : "eth1", "mtu" : 1500, "@mtu" : { "ietf-netconf-with-defaults:default" : true }, { "ietf-origin:origin" : intended }, "status" : "up" } ] } Thanks, Amar --000000000000a89f240581d50f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I ha= ve a question regarding encoding of origin annotation along with other anno= tation (with-defaults) in JSON metadata encoding format.=C2=A0

Suppose if below is the GET method :=

GET /restconf/ds/ietf-d= atastores:operational/ietf-interface:interfaces/interface=3Deth1?with-defau= lts=3Dreport-all-tagged&with-origin HTTP/1.1
How both origin and with-defaults annotations shou= ld be encoded in the JSON metadata encoding format?=C2=A0

Currently in restconf RFC 8040, in sectio= n 5.3.2, example with only one annotation is provided.

=C2=A0Refering to this example, whether mult= iple annotation representation should be like below?=C2=A0

{
=C2=A0 =C2=A0 &= quot;example:interface" : [
=C2=A0 =C2=A0 =C2= =A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"name" : "eth1",=C2=A0
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mtu" : 1500,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"@mtu" : {
<= div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "ietf-netconf-with-defaults:default" : true
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "ietf-origin:origin" : intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "status" = : "up"=C2=A0
=C2=A0 =C2=A0 =C2=A0 }=C2=A0<= /div>
=C2=A0 ]=C2=A0
}=C2=A0
<= div dir=3D"auto">
Thanks,=C2=A0
Amar
--000000000000a89f240581d50f07-- From nobody Thu Feb 14 02:23: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 C52DC131029 for ; Thu, 14 Feb 2019 02:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_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=V6G6SqsF; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lFF6AEBj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWhnoVJtVzzv for ; Thu, 14 Feb 2019 02:23:15 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1C4D112870E for ; Thu, 14 Feb 2019 02:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550139793; x=1552731793; 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=8JbqW3NRsTh1YATH5l7XYeqm6wNoHiIW3rjcQO2GvSI=; b=V6G6SqsFxG9AF8zQ6iiNCBWF5qgLMG1dSSb8KthGKoPQn8exwzUS9Wvbxc+8yi9h wnngvzYYZiX4TeUF6xYV+rW83G4TRYFtBBxqcnPB9XrqXESkKxhy+nWxV6KaViaC JqxVgZhSt3oicck91Hhq4FKNDe3a6v5FeBTEfrzz5go=; X-AuditID: c1b4fb25-209009e000005ff7-e8-5c654191f69d Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 32.EE.24567.191456C5; Thu, 14 Feb 2019 11:23:13 +0100 (CET) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESSMB501.ericsson.se (153.88.183.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Feb 2019 11:23:11 +0100 Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Feb 2019 11:23:11 +0100 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) 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 Feb 2019 11:23:11 +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=8JbqW3NRsTh1YATH5l7XYeqm6wNoHiIW3rjcQO2GvSI=; b=lFF6AEBj1Pqz7BB2DipUCUvDQWyK78Tn4IrccZIlHcdnAG2cFGyu4u3+FJFyfojpHgyJZ2ERiC/txGI91ErBrwPWnoKr7MKhqVVeafeh2nqJhs7+CjHLwBIoI18SgkLFfFIhW98qsnc+TNQO9uHMLnyiTku4gfEABdzKe8ENCo4= Received: from AM6PR07MB5191.eurprd07.prod.outlook.com (20.177.198.29) by AM6PR07MB5494.eurprd07.prod.outlook.com (20.178.90.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.11; Thu, 14 Feb 2019 10:23:09 +0000 Received: from AM6PR07MB5191.eurprd07.prod.outlook.com ([fe80::6cdc:aca5:83de:5461]) by AM6PR07MB5191.eurprd07.prod.outlook.com ([fe80::6cdc:aca5:83de:5461%2]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 10:23:09 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt Thread-Index: AQHUjUw5mF7qxDuqckaqOirCD9H9ZQ== Date: Thu, 14 Feb 2019 10:23:09 +0000 Message-ID: <5d82fbf6-6c6a-3bc8-8dbb-06503ff95dab@ericsson.com> References: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> In-Reply-To: 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.0 x-clientproxiedby: HE1PR05CA0137.eurprd05.prod.outlook.com (2603:10a6:7:28::24) To AM6PR07MB5191.eurprd07.prod.outlook.com (2603:10a6:20b:69::29) 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: 24b062e9-b064-41f9-434c-08d692666a89 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5494; x-ms-traffictypediagnostic: AM6PR07MB5494: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTZQUjA3TUI1NDk0OzIzOklKOFUrYXJVM0QvNHdtaUJOTWE1ZGpTLy8r?= =?utf-8?B?U05xbmNqVHdlYmYvRCs5MmtwdjI2ZjRhd0lIQ0pXVUFQTWpuUFdnQ2NoTERF?= =?utf-8?B?VEgydUJDRW1LU0Z4NzFqR1lVVHdCTVZuWWZUbTVyeGI3ZGl5bVpsMjZ4bEo2?= =?utf-8?B?VjNhZHZoVE9hV2syVDVVMWhSTzZMWXdqWVdnMnNsa0EzVEtjckNaRkZCK0Vj?= =?utf-8?B?RWR4RE1JWnp5b0xtTUR3WnpnYzNBSnFqUDljOWpXZ3liVTBBYnBzZjQ5aVZ1?= =?utf-8?B?K1NJL0F1cWozMGNvTnZxTzI2M3JvMXQ3YWh4Y25SdmxnUnRyclhTYkRUSXY5?= =?utf-8?B?Yno1bmdEcVZlcUtDd2dhRHJ6N1Q0WW9UZXRCNWhndUZkTWlVd1Q4RVdkMCtD?= =?utf-8?B?NlA3Y3hueUxhUzZBeWNEWW9RY1U0YTdudG9QMVhET0tYNm0zU3ZRVWppWTNX?= =?utf-8?B?T1pSL2tRN2FaUC8rQmsrZ0I3b1hINXBITm90WlNrWkpaUm9zN3JKYkZXalFv?= =?utf-8?B?eUFpVTVVeW1KM3dZK2Q2Y1hjc0FHZ2FRK3EvRXg1eThBRzJWVlNjRm5ySEY5?= =?utf-8?B?R0VKTTVkbVRadFNRQmtEbmlJMGQ1MUhKK3FURWhoSG1iQ0ZiRVV0RUxPVWlk?= =?utf-8?B?RkRhc2hPNHhyMUNUTkZwQTlCZ1o0Wk9nY2FXaGc1L0JIQTRPdVFpUDJRK3JN?= =?utf-8?B?UFRZQjQ4YTUzUEtrRDYxWG9oV05La3JBOGJCSVpIb1M3QS92U1poNEVHWTF1?= =?utf-8?B?MHE1RllrbjhIR3czU3BYZGtmNFEzMEhVSE9uL28zRENSUERuamJWNU5taGJm?= =?utf-8?B?OFZyWm96Yllsc3VSSW9sVS9CY3d5QWVvUG9GZ2Y4a0xLVlM4UG5IUXFUVElU?= =?utf-8?B?SXJqUzZnSWVEaTM5SGdQYmFlLzM4U0JnaHJONDZ3U1FaQzlyRmJlNU04Qk1t?= =?utf-8?B?K2wvcFQ1QUhndTlZMVVubStnUEJVYWdFMDE5U3ZlNUNUcGtLVE5zSWFHNzlW?= =?utf-8?B?Z2ZrQ2p6ZnBJWmpmRzVkRnMvSlhZNENnaFFSYU0yTzVrckdFTFJhMU1RSk1Q?= =?utf-8?B?OGtOb0lRYnprQ0l5NFpHVFMweEFZZWZoZlIya3NTNER1Z3lOOEZtT2ZUU3h6?= =?utf-8?B?MXJMNnVKS1Q3MVpocWNTTTU3VTVlVlVpQ2pLL0daT3ZDMTI3RFY5citqNkF6?= =?utf-8?B?a1V4YjJKUk1kMVNZOEo0eTNVa21DemNBL0h4OVVFckpDb2NQTVpBeXFiaGYx?= =?utf-8?B?cHR0ZXNId2VScW9qWUZPVEw5Y2crOGZSM3VreHlhTWRTYzdnYkF5MmthQ1ky?= =?utf-8?B?WGdOaGtwTEhlTDA3Mmt6VW9wS1FjUWttNzVWazBBbnZMMFROQVc1b09Hd2xK?= =?utf-8?B?NTNmV256VFlTcERrZTVubkRZOEFsSi9YcDVQeWQ0NnN2eVZkbnVnNjZhUzN6?= =?utf-8?B?T0M2aXFsZ2tLK21Za2FjUDlCS05mNUhueFM0M2NOemhMbWxSNEF1ZDJUcGk4?= =?utf-8?B?d01NVkIrai9OOEtTQmc5YWZyeU8vVlhpTTFKQ0htWWo5OXhWS1k0NmpYcWVE?= =?utf-8?B?c0JBV3RINCtpTUxsUkQ5eWhONFVjS1plVTBNNk1TNUtmWmVQNGphY0JVMWE5?= =?utf-8?B?NWFnaHYydy9VOXF3R0tZOHRVS1RMekR6R0VFbjA4a0k2WHViOG42OUh4cWxS?= =?utf-8?B?Q2lPT2pVdjdUZ2VsREVqQVc4SDJvdmdOcVlDd21wWS9UQldXU01sbHkyM0R2?= =?utf-8?B?RGpRRHd3UEdsUEtOd1lQWHI0c0NhS0VSUGRYZU5LYzV0ZzZoakljcEwxSGIy?= =?utf-8?B?bkZDSG1vMW0yYWFHVm0xWGttOE0wNUJyOGM4Tm4zT3JMY3lhTEdwQk5zUWww?= =?utf-8?B?L0t0OTNXL1JBcGVHeHpSQmpoc2RuTTBGSDY4OGdwUngvQWw4QU84UkEraVd0?= =?utf-8?B?NklZcE01eTBSWVg1dEhBUHJMTWNNTzVqenE1YWlkQlFnSWtHQURrV2x6L0pJ?= =?utf-8?B?U2hmbFptNzFhdVZCQ20xVHJrbks5b3lrUEVtdFBVK0NERnYwaTBTejVoeHBK?= =?utf-8?Q?6wkKTs+c4v4dz1TW/gZgKamCL?= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(136003)(346002)(376002)(189003)(199004)(81166006)(8676002)(81156014)(14454004)(64126003)(99936001)(476003)(966005)(606006)(446003)(236005)(6306002)(97736004)(6116002)(54896002)(105586002)(106356001)(2616005)(85202003)(478600001)(3846002)(8936002)(66574012)(11346002)(26005)(6512007)(7736002)(6246003)(229853002)(186003)(6506007)(86362001)(6486002)(85182001)(65826007)(386003)(102836004)(31696002)(53546011)(486006)(2906002)(15650500001)(76176011)(256004)(65956001)(66066001)(65806001)(2501003)(110136005)(58126008)(6436002)(68736007)(53936002)(14444005)(36756003)(316002)(99286004)(52116002)(25786009)(71200400001)(31686004)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5494; H:AM6PR07MB5191.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: +TpqFBlT7Ctera53AmLOPT0h3JdhhItixjGvzsRKCdBpB8cRM2UrKBrOTN0jxZdKR5cP/uXVPQ2k9kbPeRvk68crOFeY6hRhYXq08CaZ1/1vsYjTSRMLPYs8wQq1TgPsdAlqrRhPl5ya/sK9x2OlXBpsA0NwoO9YnyGXswSafZdvFKgvgkNd+BjWCeNzg55hWz3A89ZpG5COdv+g+gCvaBqu6DhGDkeozhz90bZoMkRewYxa2IKBw7VWpGujpIzMOCCvAP5bPwZw6eQIIShEjGrD2n+LfHhY/pVT5RpyPkpmwmmmLlJBGtdc8Y85JZbHm6QQZU9YF8vCUtY3MpQKBak9hMC6pUuopZUpUx9gGImwmAyWfIS7fSHbnqDzzDxc8IPADrA5VBavyS19jAH1fMb2iZ8emEITjbs14d7205s= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050104050006040700020307" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 24b062e9-b064-41f9-434c-08d692666a89 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 10:23:08.5880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5494 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSeUiTYRzHed5je10NHpfOH0ZQI/vD2WodZGQn/WGBHdAfHXasfFNrR+w1 05DSosOs3FBJF2smOiy7dB1SSW0p5NlUYqlZ6EZgh5lJxyrt3d4V9d/n93yP5/nBw5Cyfjqa SddnsEa9RqsQSaiyzfcOzTavZJPnjnrk8bbOPDr+acd5cgWRWPyjlk6srPxObCC2ShJSWG16 Jmucs2yXJM17apA+4LiEsjo+tFK5aPDIGRTGAF4A5dfbxWeQhJHhRgTOzyOUMHxB4Kt+Qf8d /F114kBEhisJuPtAHhAobCLhQqlbJLiKCKi7VksKwyCC2n4PGYiI8Go4NfyICHAEXgs1bS+p AE/BWuhpnuDvYPhzHbT9lAkWFTSYzUE7hWOg0PSIDrAUL+cvbkFC/10Ejr7jwf4wvBRO1o8H GWE5fG25FgyTOAp6fTZC2DQCBjpbRQJHwpB3nBZYAaVve4McibeD+YM1uADgEgRuewkhlO6A h69Oh8Jx0O7xIYGnQZetIMRJYOm/Hwp7EYz1jZGCEAvPrjcgQWiIgKraY6HEfmj3OZAJzbH8 81oL7yNxPoJfPRWUJbh3ODSX+XhmeGEW2E8o/vcHWAn2y+9IgZdAqd8pEngGFBcMiAVeCO+a PiGB54P9xi9ROZJcRZEcy+3Wpc6br2KN6Xs4zqBX6dmMOsR/NOftHzH1qPv9ShfCDFJMluYt YpNltCaTy9a50Ey+Z/BWjRtFU3qDnlVESMeX8LI0RZN9mDUadhoPalnOhaYylCJK+lMWnizD qZoMdj/LHmCNf1SCCYvORVlrGM/kfVVvnEtv2VZNxG1U3eOWR6nVrrMt/jzxcLt309tG5bfP lsfO/JSmKd8KFnvOGfyFOW1FOuuTCauDqJirfJ2kix8pGVrfO3q0enid+6LJmisbMT+vv5Og fLNwVE6kbZmeY9DK97ocat2xSe/9aTedrduGrnR/ZB6Iw3sUFJemUceSRk7zGyDLypVwAwAA Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-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: Thu, 14 Feb 2019 10:23:18 -0000 --------------ms050104050006040700020307 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable


On 2019. 02. 07. 13:10, Robert Wilton wrote:

Hi Balazs,

Regarding identifying the instance data using a YANG package.

If the YANG packages work is liked by the WG and progresses, then it seems plausible that a YANG package could become a better way of identifying the set of modules rather than using YANG library for a couple of reasons:
=C2=A01) It will allow modules to be identified via semantic vers= ion rather than just revision date.=C2=A0 This will likely be more meaningful to readers.

BALAZS: The nice thing about using yang-library is that when the semver work augment the library with the module-version it will be available for instance-data for free.

=C2=A02) It allows for a much more concise definition.=C2=A0 Ra= ther than having to try and infer what schema a particular set of YANG modules related to from the list of modules, it can instead refer to a single package definition and version number.

BALAZS: Using packages would be more, concise however in some cases you might not want to declare a package. E.g. we use a modular architecture where one design group might be responsible for only one YANG module (YAM). They need to deliver some instance-data related to that YAM, but they don't want to declare a package that contains just one YAM. Also some modules are packaged in so many ways that it is easier to define their instance data just for that module. So while packages are an interesting idea they will never completely replace the module level, hence we need a module level solution too. One packages are agreed, I will be happy to expand this specification.

=C2=A03) YANG library (certainly RFC7895bis) defines the schema= in terms of the datastore, so if this version of YANG library is being used then it is a bit more confusing as to which datastore is being referred to.=C2=A0 I appreciate that there is a datastor= e leaf in the instance data that can help mitigate this.

I also note that the draft currently binds that the only allowed inline schema is YANG library, but that seems somewhat overly restrictive, and perhaps this could be loosened to a leaf-list of inline module@revision definitions?

BALAZS: IMHO ietf-yang-library contains ll the data we need in a well defined format (and some we don't always need). So why define a new format when we already have one. Also by using YANG library we get for free any new data in it e.g.module-version. We also need the info about leafs and deviations.

I also appreciate that you don't want to delay the instance data draft for YANG packages, bit I wonder whether the draft can easily facilitate using a YANG package definition in future if required.

BALAZS: As I agree with your comment about choice (see below) that a package reference can be easily included in that.

Hence, rather than using a union for the "target pointer", I wonder whether it wouldn't be better to use a choice statement instead.

E.g. the choice statement could be something like this:

=C2=A0choice "schema"
=C2=A0=C2=A0 leaf-list inline {
=C2=A0=C2=A0=C2=A0=C2=A0 type string {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pattern '\w+@\d{4}-= \d{2}-\d{2}\.yang';
=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0 }
=C2=A0=C2=A0 leaf yang-library-ref { type uri } // Point= s to a instance data document YANG library content.
=C2=A0}

In future, the package draft could then augment (or update the revision) with something like this :

=C2=A0=C2=A0 container package-ref {
=C2=A0=C2=A0=C2=A0=C2=A0 leaf "name" { type string; }
=C2=A0=C2=A0=C2=A0=C2=A0 leaf "version" { type yang-semv= er; }
=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list "url" { type uri; } // Points to a instance data document containing YANG package content.
=C2=A0=C2=A0 }

BALAZS: OK, choice maybe a better choice because it is easier to extend and because it explicitly states the method used. So how about:

 choice "target-specification"
   leaf inline {
     type string { pattern 'ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang'; }=
   // I still want to use the library=20
   }
   leaf yang-library-ref { type uri }=20
 }

Later we can augment this choice with container package-ref.

Thanks,
Rob

On 06/12/2018 10:15, Bal=C3=A1zs Len= gyel wrote:

Hello,

We uploaded a new version of the instance data draft. We tried to address all comments and also to rework the format chapter to make it easier to read. We omitted 2 comments:

Rob commented that YANG packages could be used for defining the target modules for instance data: I would like to avoid that because:

  • Packages are not defined for YANG. Currently they are not part of the versioning solution even though they were discussed and are generally a good idea.
  • IMHO as deviations/features are set on module level, just specifying packages would not be enough. If we start using package+module level deviations/features we may end up with a more complicated hybrid solution.
  • Module level YANG target definitions as described in the draft are simple and need no new design

J=C3=BCrgen stated that it would be better to use the YANG XML/JSON encoding as a format instead of referencing the get operation/request. I might even agree with him, but for 2 reasons I did not follow his idea:

  • Currently there is no RFC I could reference either for XML or JSON. AFAIK even RFC7951 does not define how multiple modules should be encoded side by side.
  • It is not the job of the instance data draft to dictate how to encode YANG data generally e.g. on the wire.
  • The contents of the get operation/request are well defined<= br>

regards Balazs



-------- Forwarded Message -------- =
Subject: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt
Date: Thu, 6 Dec 2018 02:12:12 -0800
From: internet-drafts@ietf.org=
To: Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.= com>



A new version of I-D, draft-ietf-netmod-yang-instance-file-format-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format
Revision: 01
Title: YANG Instance Data File Format
Document date: 2018-12-06
Group: netmod
Pages: 21
URL: https://www.ietf.org/internet-drafts= /draft-ietf-netmod-yang-instance-file-format-01.txt
Status: https://datatracker.ietf.org/doc/dra= ft-ietf-netmod-yang-instance-file-format/
Htmlized: https://tools.ietf.org/html/draft-ie= tf-netmod-yang-instance-file-format-01
Htmlized: https://datatracker.ietf.org/doc/htm= l/draft-ietf-netmod-yang-instance-file-format
Diff: https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-netmod-yang-instance-file-format-01

Abstract:
There is a need to document data defined in YANG models when a live
YANG server is not available. Data is often needed already in design
time or needed by groups that do not have a live running YANG server
available. This document specifies a standard file format for YANG
instance data, which follows the syntax and semantic from existing
YANG models, re-using existing formats from <get> operation/request
and decorates them with metadata.



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

The IETF Secretariat

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


__________________________=
_____________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/netmod

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms050104050006040700020307 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIxNDEwMjMwNlow LwYJKoZIhvcNAQkEMSIEICsvnEZWzxn/mNYBH/bhcz80R/JzgOsChBFVbf0ATJEMMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAEr1X/3MXGADty6vYVcXB/upZlI0BwtsrsO2lsaBJ18s89pt vjdZ+wljMV3KScqVavSIkfCU+chNA29YRwCL1VZ66FSpuJOyZUfY/4Rg44NzLAyiI7Fv1FE7 SKhPNc7E/zME1CpEGmTtFVgJOIUZh7zi39zI2pAq44Sciuarfl+jgoORcWwjeJaWgCHE8aEx oobKHaQ4AjbHToWznURIigsHFicqjha1TPlj4I7Rt46xPMS4aoCt8Mo9aDV+hn8GpuZYTo66 GRn+63/RhrdElrIVK9peUggDxHN/LL27pxC8uurjsKJU8XTZy273peA0gFHJBc6ZLqWWMBBM FraNulMAAAAAAAA= --------------ms050104050006040700020307-- From nobody Thu Feb 14 03:12: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 5C7FC131160 for ; Thu, 14 Feb 2019 03:12:30 -0800 (PST) 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 drpBH7biiMnK for ; Thu, 14 Feb 2019 03:12:27 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7561A131060 for ; Thu, 14 Feb 2019 03:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29555; q=dns/txt; s=iport; t=1550142746; x=1551352346; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=PLu3YKrJ3O0yUW3UTYq+HVHXANAdndDx4nDjSzEcRYE=; b=CjhNfR07N2a9+E/ihwwYbjncQdNaA6IPowoxKM/goAqdcyQidiSeI7eE U/dm8/fTdDWIqM3sl6xM1v/MTqGHIqyVLjeUk8/5oITXAWGjBQk79lK3n MNrscqYw91AKgrSxdyRHC74bhY7wby55tHum56QBYJ1nJBVJeCSaWwZxQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAITGVc/xbLJq0YAUAKGgEBAQE?= =?us-ascii?q?BAgEBAQEHAgEBAQGBUQUBAQEBCwEBgVOBFXESJ4QGiBpfjHolfJcXFIFnDRg?= =?us-ascii?q?BDIQBRgKEAjQJDQEDAQECAQECbRwMhUoBAQEDAQEBIUsJEgkCEQECAQIBIAo?= =?us-ascii?q?CAiciBggGAQwGAgEBF4MFAYFqCA+LSYIlm2GBLx+EFAIOQUCEdYV6hmGBQD+?= =?us-ascii?q?BEScMgio1gx4BAQIBARaBFAEHCwEJNoJpgjUiAolhIAsCBYYtkm4JhnZEixQ?= =?us-ascii?q?GGYFuVoR+gxgmhF2DFoo6gQ+ENIUuhyeBRjhlcTMaCBsVGiGCbAmCHxcTiEy?= =?us-ascii?q?FPz8DMAGMc4I+AQE?= X-IronPort-AV: E=Sophos; i="5.58,368,1544486400"; d="scan'208,217"; a="10032067" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 11:12:23 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x1EBCMQZ011728; Thu, 14 Feb 2019 11:12:23 GMT To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , "netmod@ietf.org" References: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> <5d82fbf6-6c6a-3bc8-8dbb-06503ff95dab@ericsson.com> From: Robert Wilton Message-ID: Date: Thu, 14 Feb 2019 11:12:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <5d82fbf6-6c6a-3bc8-8dbb-06503ff95dab@ericsson.com> Content-Type: multipart/alternative; boundary="------------7AEDD7A835E59060E694D5AD" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.84, dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-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: Thu, 14 Feb 2019 11:12:30 -0000 This is a multi-part message in MIME format. --------------7AEDD7A835E59060E694D5AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Balazs, I think that every instance data document logically has a YANG schema associated with it (i.e. a set of YANG modules, deviations, and enabled features). YANG library defines this schema on a per datastore basis, along with other information. My YANG packages is another attempt to construct these schema in a hierarchical way. Directly embedding the necessary information to facilitate a client reading the YANG instance data also makes sense. Please see inline ... On 14/02/2019 10:23, Balázs Lengyel wrote: > > > On 2019. 02. 07. 13:10, Robert Wilton wrote: >> >> Hi Balazs, >> >> Regarding identifying the instance data using a YANG package. >> >> If the YANG packages work is liked by the WG and progresses, then it >> seems plausible that a YANG package could become a better way of >> identifying the set of modules rather than using YANG library for a >> couple of reasons: >>  1) It will allow modules to be identified via semantic version >> rather than just revision date.  This will likely be more meaningful >> to readers. >> > BALAZS: The nice thing about using yang-library is that when the > semver work augment the library with the module-version it will be > available for instance-data for free. RW: This only works if the reference to the schema includes the semver augmentation.  Your current approach of "ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang';" doesn't allow this, unless the semver work produces a new version of YANG library rather than an augmentation. I have no opposition to YANG library being one of the mechanisms to construct the schema, but I think that it should also be possible to define the schema inline, or use YANG packages (in future). >>  2) It allows for a much more concise definition.  Rather than having >> to try and infer what schema a particular set of YANG modules related >> to from the list of modules, it can instead refer to a single package >> definition and version number. >> > BALAZS: Using packages would be more, concise however in some cases > you might not want to declare a package. E.g. we use a modular > architecture where one design group might be responsible for only one > YANG module (YAM). They need to deliver some instance-data related to > that YAM, but they don't want to declare a package that contains just > one YAM. Also some modules are packaged in so many ways that it is > easier to define their instance data just for that module. So while > packages are an interesting idea they will never completely replace > the module level, hence we need a module level solution too. One > packages are agreed, I will be happy to expand this specification. RW: But if I understand your approach correctly then to handle this case the instance data would need to reference a separate instance data file that uses YANG library to define the one YANG module that is uses. If the schema is just a single YANG module then I think that it would be better to define that schema inline in the instance data document, and avoid the redirection.  Perhaps to keep it simple we restrict the list of YANG modules that can be used to define to define the schema inline to state that sub-modules cannot be used, and all features are assumed to be enabled.  If either of these conditions are not met then an external schema definition must be used. >>  3) YANG library (certainly RFC7895bis) defines the schema in terms >> of the datastore, so if this version of YANG library is being used >> then it is a bit more confusing as to which datastore is being >> referred to.  I appreciate that there is a datastore leaf in the >> instance data that can help mitigate this. >> >> I also note that the draft currently binds that the only allowed >> inline schema is YANG library, but that seems somewhat overly >> restrictive, and perhaps this could be loosened to a leaf-list of >> inline module@revision definitions? >> > BALAZS: IMHO ietf-yang-library contains ll the data we need in a well > defined format (and some we don't always need). So why define a new > format when we already have one. Also by using YANG library we get for > free any new data in it e.g.module-version. We also need the info > about leafs and deviations. RW: Because YANG library isn't really the right format, and the goal of YANG library isn't to define this instance data file, but actually to define the capabilities of a server. E.g. RFC 7895bis contains the information on how to build multiple datastore schema rather than just one.  So, if 7895bis is being used to construct a schema, then you also need to identify which datastore in YANG library represents the schema associated with the instance data. I also don't think that you get augmentations from free.  How would a client know which augmentations to YANG library are being used unless that is defined somewhere? >> I also appreciate that you don't want to delay the instance data >> draft for YANG packages, bit I wonder whether the draft can easily >> facilitate using a YANG package definition in future if required. >> > BALAZS: As I agree with your comment about choice (see below) that a > package reference can be easily included in that. >> >> Hence, rather than using a union for the "target pointer", I wonder >> whether it wouldn't be better to use a choice statement instead. >> >> E.g. the choice statement could be something like this: >> >>  choice "schema" >>    leaf-list inline { >>      type string { >>        pattern '\w+@\d{4}-\d{2}-\d{2}\.yang'; >>      } >>    } >>    leaf yang-library-ref { type uri } // Points to a instance data >> document YANG library content. >>  } >> >> In future, the package draft could then augment (or update the >> revision) with something like this : >> >>    container package-ref { >>      leaf "name" { type string; } >>      leaf "version" { type yang-semver; } >>      leaf-list "url" { type uri; }// Points to a instance data >> document containing YANG package content. >>    } >> > BALAZS: OK, choice maybe a better choice because it is easier to > extend and because it explicitly states the method used. So how about: > > choice "target-specification" > leaf inline { > type string { pattern 'ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang'; } // I still want to use the library > } > leaf yang-library-ref { type uri } > } RW: I still think that binding "inline" to YANG library is too restrictive.  This effectively means that there is a version of instance data documents that the only thing that they can contain is YANG library information (without augmentation). Thanks, Rob > > Later we can augment this choice with container package-ref. > >> Thanks, >> Rob >> >> On 06/12/2018 10:15, Balázs Lengyel wrote: >>> >>> Hello, >>> >>> We uploaded a new version of the instance data draft. We tried to >>> address all comments and also to rework the format chapter to make >>> it easier to read. We omitted 2 comments: >>> >>> Rob commented that YANG packages could be used for defining the >>> target modules for instance data: I would like to avoid that because: >>> >>> * Packages are not defined for YANG. Currently they are not part >>> of the versioning solution even though they were discussed and >>> are generally a good idea. >>> * IMHO as deviations/features are set on module level, just >>> specifying packages would not be enough. If we start using >>> package+module level deviations/features we may end up with a >>> more complicated hybrid solution. >>> * Module level YANG target definitions as described in the draft >>> are simple and need no new design >>> >>> Jürgen stated that it would be better to use the YANG XML/JSON >>> encoding as a format instead of referencing the get >>> operation/request. I might even agree with him, but for 2 reasons I >>> did not follow his idea: >>> >>> * Currently there is no RFC I could reference either for XML or >>> JSON. AFAIK even RFC7951 does not define how multiple modules >>> should be encoded side by side. >>> * It is not the job of the instance data draft to dictate how to >>> encode YANG data generally e.g. on the wire. >>> * The contents of the get operation/request are well defined >>> >>> regards Balazs >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-ietf-netmod-yang-instance-file-format-01.txt >>> Date: Thu, 6 Dec 2018 02:12:12 -0800 >>> From: internet-drafts@ietf.org >>> To: Benoit Claise , Balazs Lengyel >>> >>> >>> >>> >>> >>> A new version of I-D, draft-ietf-netmod-yang-instance-file-format-01.txt >>> has been successfully submitted by Balazs Lengyel and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-netmod-yang-instance-file-format >>> Revision: 01 >>> Title: YANG Instance Data File Format >>> Document date: 2018-12-06 >>> Group: netmod >>> Pages: 21 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01 >>> >>> Abstract: >>> There is a need to document data defined in YANG models when a live >>> YANG server is not available. Data is often needed already in design >>> time or needed by groups that do not have a live running YANG server >>> available. This document specifies a standard file format for YANG >>> instance data, which follows the syntax and semantic from existing >>> YANG models, re-using existing formats from operation/request >>> and decorates them with metadata. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> Mobile: +36-70-330-7909 email:Balazs.Lengyel@ericsson.com >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email:Balazs.Lengyel@ericsson.com --------------7AEDD7A835E59060E694D5AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Balazs,

I think that every instance data document logically has a YANG schema associated with it (i.e. a set of YANG modules, deviations, and enabled features).

YANG library defines this schema on a per datastore basis, along with other information.

My YANG packages is another attempt to construct these schema in a hierarchical way.

Directly embedding the necessary information to facilitate a client reading the YANG instance data also makes sense.


Please see inline ...

On 14/02/2019 10:23, Balázs Lengyel wrote:


On 2019. 02. 07. 13:10, Robert Wilton wrote:

Hi Balazs,

Regarding identifying the instance data using a YANG package.

If the YANG packages work is liked by the WG and progresses, then it seems plausible that a YANG package could become a better way of identifying the set of modules rather than using YANG library for a couple of reasons:
 1) It will allow modules to be identified via semantic version rather than just revision date.  This will likely be more meaningful to readers.

BALAZS: The nice thing about using yang-library is that when the semver work augment the library with the module-version it will be available for instance-data for free.

RW:

This only works if the reference to the schema includes the semver augmentation.  Your current approach of "ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang';" doesn't allow this, unless the semver work produces a new version of YANG library rather than an augmentation.

I have no opposition to YANG library being one of the mechanisms to construct the schema, but I think that it should also be possible to define the schema inline, or use YANG packages (in future).


 2) It allows for a much more concise definition.  Rather than having to try and infer what schema a particular set of YANG modules related to from the list of modules, it can instead refer to a single package definition and version number.

BALAZS: Using packages would be more, concise however in some cases you might not want to declare a package. E.g. we use a modular architecture where one design group might be responsible for only one YANG module (YAM). They need to deliver some instance-data related to that YAM, but they don't want to declare a package that contains just one YAM. Also some modules are packaged in so many ways that it is easier to define their instance data just for that module. So while packages are an interesting idea they will never completely replace the module level, hence we need a module level solution too. One packages are agreed, I will be happy to expand this specification.

RW:

But if I understand your approach correctly then to handle this case the instance data would need to reference a separate instance data file that uses YANG library to define the one YANG module that is uses.

If the schema is just a single YANG module then I think that it would be better to define that schema inline in the instance data document, and avoid the redirection.  Perhaps to keep it simple we restrict the list of YANG modules that can be used to define to define the schema inline to state that sub-modules cannot be used, and all features are assumed to be enabled.  If either of these conditions are not met then an external schema definition must be used.


 3) YANG library (certainly RFC7895bis) defines the schema in terms of the datastore, so if this version of YANG library is being used then it is a bit more confusing as to which datastore is being referred to.  I appreciate that there is a datastore leaf in the instance data that can help mitigate this.

I also note that the draft currently binds that the only allowed inline schema is YANG library, but that seems somewhat overly restrictive, and perhaps this could be loosened to a leaf-list of inline module@revision definitions?

BALAZS: IMHO ietf-yang-library contains ll the data we need in a well defined format (and some we don't always need). So why define a new format when we already have one. Also by using YANG library we get for free any new data in it e.g.module-version. We also need the info about leafs and deviations.

RW:

Because YANG library isn't really the right format, and the goal of YANG library isn't to define this instance data file, but actually to define the capabilities of a server.

E.g. RFC 7895bis contains the information on how to build multiple datastore schema rather than just one.  So, if 7895bis is being used to construct a schema, then you also need to identify which datastore in YANG library represents the schema associated with the instance data.

I also don't think that you get augmentations from free.  How would a client know which augmentations to YANG library are being used unless that is defined somewhere?


I also appreciate that you don't want to delay the instance data draft for YANG packages, bit I wonder whether the draft can easily facilitate using a YANG package definition in future if required.

BALAZS: As I agree with your comment about choice (see below) that a package reference can be easily included in that.

Hence, rather than using a union for the "target pointer", I wonder whether it wouldn't be better to use a choice statement instead.

E.g. the choice statement could be something like this:

 choice "schema"
   leaf-list inline {
     type string {
       pattern '\w+@\d{4}-\d{2}-\d{2}\.yang';
     }
   }
   leaf yang-library-ref { type uri } // Points to a instance data document YANG library content.
 }

In future, the package draft could then augment (or update the revision) with something like this :

   container package-ref {
     leaf "name" { type string; }
     leaf "version" { type yang-semver; }
     leaf-list "url" { type uri; } // Points to a instance data document containing YANG package content.
   }

BALAZS: OK, choice maybe a better choice because it is easier to extend and because it explicitly states the method used. So how about:

 choice "target-specification"
   leaf inline {
     type string { pattern 'ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang'; }   // I still want to use the library 
   }
   leaf yang-library-ref { type uri } 
 }

RW:

I still think that binding "inline" to YANG library is too restrictive.  This effectively means that there is a version of instance data documents that the only thing that they can contain is YANG library information (without augmentation).

Thanks,
Rob



Later we can augment this choice with container package-ref.

Thanks,
Rob

On 06/12/2018 10:15, Balázs Lengyel wrote:

Hello,

We uploaded a new version of the instance data draft. We tried to address all comments and also to rework the format chapter to make it easier to read. We omitted 2 comments:

Rob commented that YANG packages could be used for defining the target modules for instance data: I would like to avoid that because:

  • Packages are not defined for YANG. Currently they are not part of the versioning solution even though they were discussed and are generally a good idea.
  • IMHO as deviations/features are set on module level, just specifying packages would not be enough. If we start using package+module level deviations/features we may end up with a more complicated hybrid solution.
  • Module level YANG target definitions as described in the draft are simple and need no new design

Jürgen stated that it would be better to use the YANG XML/JSON encoding as a format instead of referencing the get operation/request. I might even agree with him, but for 2 reasons I did not follow his idea:

  • Currently there is no RFC I could reference either for XML or JSON. AFAIK even RFC7951 does not define how multiple modules should be encoded side by side.
  • It is not the job of the instance data draft to dictate how to encode YANG data generally e.g. on the wire.
  • The contents of the get operation/request are well defined

regards Balazs



-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt
Date: Thu, 6 Dec 2018 02:12:12 -0800
From: internet-drafts@ietf.org
To: Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>



A new version of I-D, draft-ietf-netmod-yang-instance-file-format-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format
Revision: 01
Title: YANG Instance Data File Format
Document date: 2018-12-06
Group: netmod
Pages: 21
URL: https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01

Abstract:
There is a need to document data defined in YANG models when a live
YANG server is not available. Data is often needed already in design
time or needed by groups that do not have a live running YANG server
available. This document specifies a standard file format for YANG
instance data, which follows the syntax and semantic from existing
YANG models, re-using existing formats from <get> operation/request
and decorates them with metadata.



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

The IETF Secretariat

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
--------------7AEDD7A835E59060E694D5AD-- From nobody Thu Feb 14 03: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 647EB131160 for ; Thu, 14 Feb 2019 03:26:40 -0800 (PST) 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 2eS91jXPSVAO for ; Thu, 14 Feb 2019 03:26:38 -0800 (PST) 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 4A27E131055 for ; Thu, 14 Feb 2019 03:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6197; q=dns/txt; s=iport; t=1550143598; x=1551353198; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=CbjOAf4HXVb5lZpS4RdxNVotXd7lt5lyZK5tYo5lxE8=; b=f5gal7yr8E5OUT8e2pa1Sp3UQIGFEl9Q2AdpZ5dBm00mXdshl2R6Y2Th ZE1FrYo3yjn3xjLPsSQU/Lc517F88SFpED7Jjk/1H9WiX8aJvf2SmrmaJ mV4fHWY2ExFGUGvtT245B/FW1I9O3FUQ+vw8denI9+VXY7N65pmQMLAeT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAACnT2Vc/xbLJq0YAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFTAwEBAQELAQGCaHESJ4QGiHmNH5IkhW+Bew0YAQqEA0Y?= =?us-ascii?q?ChAI2Bw0BAwEBAgEBAm0cDIVLAQEEAQEhSxsJAg4KKgICJzAGAQwGAgEBgxw?= =?us-ascii?q?BgXIPi0mCIZthgS8fhSWEcAWMW4FAP4E4gmuDHgEBhGqCVwKQQJJuCZJOBhm?= =?us-ascii?q?KWogZh1KCaIpxhyeBTQQtgVYzGggbFTuCbIJSiEyFPz8DMI8yAQE?= X-IronPort-AV: E=Sophos; i="5.58,368,1544486400"; d="scan'208,217"; a="10030140" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 11:26:36 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x1EBQZRc004951; Thu, 14 Feb 2019 11:26:35 GMT To: Amar Jadagoud , netmod@ietf.org References: From: Robert Wilton Message-ID: Date: Thu, 14 Feb 2019 11:26:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0845B1AD9659C1BC114FAE36" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.84, dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 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 Feb 2019 11:26:40 -0000 This is a multi-part message in MIME format. --------------0845B1AD9659C1BC114FAE36 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Amar, Based on RFC 7952 section 5.2.1, I think that it would look like this: {     "example:interface" : [        {            "name" : "eth1",            "mtu" : 1500,            "@mtu" : {                   "ietf-netconf-with-defaults:default" : true,   "ietf-origin:origin" : intended               },            "status" : "up"       }   ] } Thanks, Rob On 14/02/2019 06:49, Amar Jadagoud wrote: > Hi All, > > I have a question regarding encoding of origin annotation along with > other annotation (with-defaults) in JSON metadata encoding format. > > Suppose if below is the GET method : > > GET > /restconf/ds/ietf-datastores:operational/ietf-interface:interfaces/interface=eth1?with-defaults=report-all-tagged&with-origin > HTTP/1.1 > > How both origin and with-defaults annotations should be encoded in the > JSON metadata encoding format? > > Currently in restconf RFC 8040, in section 5.3.2, example with only > one annotation is provided. > >  Refering to this example, whether multiple annotation representation > should be like below? > > { >     "example:interface" : [ >        { >            "name" : "eth1", >            "mtu" : 1500, >            "@mtu" : { > "ietf-netconf-with-defaults:default" : true >               }, >               { >                     "ietf-origin:origin" : intended >               }, >               "status" : "up" >       } >   ] > } > > Thanks, > Amar > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------0845B1AD9659C1BC114FAE36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Amar,

Based on RFC 7952 section 5.2.1, I think that it would look like this:

{
    "example:interface" : [
       {
           "name" : "eth1",
           "mtu" : 1500,
           "@mtu" : {
                  "ietf-netconf-with-defaults:default" : true,
                  "ietf-origin:origin" : intended
              },
           "status" : "up"
      }
  ]
}

Thanks,
Rob


On 14/02/2019 06:49, Amar Jadagoud wrote:
Hi All,

I have a question regarding encoding of origin annotation along with other annotation (with-defaults) in JSON metadata encoding format. 

Suppose if below is the GET method :

GET /restconf/ds/ietf-datastores:operational/ietf-interface:interfaces/interface=eth1?with-defaults=report-all-tagged&with-origin HTTP/1.1

How both origin and with-defaults annotations should be encoded in the JSON metadata encoding format? 

Currently in restconf RFC 8040, in section 5.3.2, example with only one annotation is provided.

 Refering to this example, whether multiple annotation representation should be like below? 

{
    "example:interface" : [
       {
           "name" : "eth1", 
           "mtu" : 1500,
           "@mtu" : {
                  "ietf-netconf-with-defaults:default" : true
              }, 
              {
                    "ietf-origin:origin" : intended
              }, 
              "status" : "up" 
      } 
  ] 
} 

Thanks, 
Amar

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------0845B1AD9659C1BC114FAE36-- From nobody Thu Feb 14 03:40: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 4F584131166 for ; Thu, 14 Feb 2019 03:40:48 -0800 (PST) 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 K34pUYDKJzq2 for ; Thu, 14 Feb 2019 03:40:45 -0800 (PST) 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 4DBBF131162 for ; Thu, 14 Feb 2019 03:40:45 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 79B3A60611; Thu, 14 Feb 2019 12:40:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1550144442; bh=2RK/Y4PH+HREcIJUVXFKgZHd8hlRWGZou51uaArUk0Y=; h=From:To:Date; b=u8XjnRGF1HD93pSFeDMeSpJRAsGjI6ixmUW2qj/vwOf4MF6Ma+oIXdQiynXebOnTZ Tp7ACv+8+YMyvWF3IzaQtLVy7BWpLi7QUcOGZBdDTzwkB6rQMi6YVEf4kHHi8JKQf8 dendIQfgu6AIPPerYhVs/DBYJCTFHhyl2PiPeCvw= Message-ID: From: Ladislav Lhotka To: Robert Wilton , Amar Jadagoud , netmod@ietf.org Date: Thu, 14 Feb 2019 12:40:42 +0100 In-Reply-To: References: Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 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] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 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 Feb 2019 11:40:48 -0000 On Thu, 2019-02-14 at 11:26 +0000, Robert Wilton wrote: > Hi Amar, > Based on RFC 7952 section 5.2.1, I think that it would look like this: > { > "example:interface" : [ > { > "name" : "eth1", > "mtu" : 1500, > "@mtu" : { > "ietf-netconf-with-defaults:default" : true, > "ietf-origin:origin" : intended > }, > "status" : "up" > } > ] > } > Thanks, > Rob It depends. The version above is correct but both annotations are attached to the "mtu" leaf. If the idea was to attach the origin annotation to the interface entry, then it should be encoded like this: { "example:interface" : [ { "name" : "eth1", "mtu" : 1500, "@mtu" : { "ietf-netconf-with-defaults:default" : true }, "@" : { "ietf-origin:origin" : intended }, "status" : "up" } ] } Lada > > On 14/02/2019 06:49, Amar Jadagoud wrote: > > Hi All, > > > > I have a question regarding encoding of origin annotation along with other > > annotation (with-defaults) in JSON metadata encoding format. > > > > Suppose if below is the GET method : > > > > GET /restconf/ds/ietf-datastores:operational/ietf- > > interface:interfaces/interface=eth1?with-defaults=report-all-tagged&with- > > origin HTTP/1.1 > > > > How both origin and with-defaults annotations should be encoded in the JSON > > metadata encoding format? > > > > Currently in restconf RFC 8040, in section 5.3.2, example with only one > > annotation is provided. > > > > Refering to this example, whether multiple annotation representation should > > be like below? > > > > { > > "example:interface" : [ > > { > > "name" : "eth1", > > "mtu" : 1500, > > "@mtu" : { > > "ietf-netconf-with-defaults:default" : true > > }, > > { > > "ietf-origin:origin" : intended > > }, > > "status" : "up" > > } > > ] > > } > > > > Thanks, > > Amar > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Feb 14 04:14: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 E99EF13106D for ; Thu, 14 Feb 2019 04:14:41 -0800 (PST) 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 FeJKuZ85TSdu for ; Thu, 14 Feb 2019 04:14:39 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 A664F130EB3 for ; Thu, 14 Feb 2019 04:14:39 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id p48so6555025qtk.2 for ; Thu, 14 Feb 2019 04:14:39 -0800 (PST) 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; bh=krZmIKJcwKcvnY/QqfLLtvFVWmlMxTQ+PgJSRL6NOnk=; b=UAiE+ThLTUOrN/bNmaeoXrYXlmPpIFqFlXFI+iyegZhk5f/udtb+5kExvIA/7i9B1i phSFcvglj7Gc7Id/Hh5KvY9JGtghKmKG+HFXJRkDw6sJ2eXayKoDVCgPhE/sR1ozM0IL HHYoRCcPZcEFFP2vPC+QqlRZUhrecbPDgfYPS5ZX0TfvXZrUp+xrY3Hp7tGO4G6MQyOH yf9tPgMure47fIH0/JQbACvCaVDFHPG54jT6as6rHiWg4cnmevPQmjURl99c2BMEmjA4 xMpQBLhnxfhowvyTPk3FiL3p3axCd25uDeuBND11UbfydFYo/Av0pa0RGDNPT6489rah H1sA== 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=krZmIKJcwKcvnY/QqfLLtvFVWmlMxTQ+PgJSRL6NOnk=; b=O0ODYAAWDiXPiCszvNjQxnMNzUH5M/yKAXsh0/hDiE8K/H9BGy8LR55Opwc1hZ1pWP 8mHdoPHSR0vK4/dKidMct4UKlWX6LfUIVmzrTjHo1GbrbXXd1ztbjQ9J2CyJTD5H8B1C s366IvqUqdaY2RFBJgTxlmn08cNgXK6BTf6oc4VeMXt6LrBo1kUoP7CpHLfj622cU0wc pPuYxGvNQ02aS95WePPqsNZ61aMrRQGdQqYQHKBkXuLF4vPO1QNP8urEsYESK9CxY5/H EYsVL32sQssRxzmeVt6D9/vqdvFs3Bb/7DdR9q6O8s6UjZG5HFRTVfLubK0T3Er0xMV6 68vg== X-Gm-Message-State: AHQUAuabNmPFhueoGZloR0i7+pogJEXE9+/Hi3Y9npdYwsPlfEEp7IPH eD0urFBio55oe9rqE6XB/xx0LCKhBJJSzXYPGvuuBQ== X-Google-Smtp-Source: AHgI3IbKOed9ahIiATLjPgU5R73JatWBV01p58oQCN/BYn/mdw5tqJbFdjH/iQ7KhecXPu2+49kwE9CwPVM1C2w8sVs= X-Received: by 2002:a0c:9a4c:: with SMTP id q12mr2630086qvd.58.1550146478640; Thu, 14 Feb 2019 04:14:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amar Jadagoud Date: Thu, 14 Feb 2019 17:44:26 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="00000000000035917b0581d99aa4" Archived-At: Subject: Re: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 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 Feb 2019 12:14:42 -0000 --00000000000035917b0581d99aa4 Content-Type: text/plain; charset="UTF-8" Hi Robert, Ladislav, Thanks for the clarification. I think it would be helpful if an example of encoding multiple annotations in JSON metadata encoding is mentioned in any of the related drafts. Thanks, Amar On Thu 14 Feb, 2019, 5:10 PM Ladislav Lhotka On Thu, 2019-02-14 at 11:26 +0000, Robert Wilton wrote: > > Hi Amar, > > Based on RFC 7952 section 5.2.1, I think that it would look like this: > > { > > "example:interface" : [ > > { > > "name" : "eth1", > > "mtu" : 1500, > > "@mtu" : { > > "ietf-netconf-with-defaults:default" : true, > > "ietf-origin:origin" : intended > > }, > > "status" : "up" > > } > > ] > > } > > Thanks, > > Rob > > It depends. The version above is correct but both annotations are attached > to > the "mtu" leaf. If the idea was to attach the origin annotation to the > interface > entry, then it should be encoded like this: > > { > "example:interface" : [ > { > "name" : "eth1", > "mtu" : 1500, > "@mtu" : { > "ietf-netconf-with-defaults:default" : true > }, > "@" : { > "ietf-origin:origin" : intended > }, > "status" : "up" > } > ] > } > > Lada > > > > > On 14/02/2019 06:49, Amar Jadagoud wrote: > > > Hi All, > > > > > > I have a question regarding encoding of origin annotation along with > other > > > annotation (with-defaults) in JSON metadata encoding format. > > > > > > Suppose if below is the GET method : > > > > > > GET /restconf/ds/ietf-datastores:operational/ietf- > > > > interface:interfaces/interface=eth1?with-defaults=report-all-tagged&with- > > > origin HTTP/1.1 > > > > > > How both origin and with-defaults annotations should be encoded in the > JSON > > > metadata encoding format? > > > > > > Currently in restconf RFC 8040, in section 5.3.2, example with only one > > > annotation is provided. > > > > > > Refering to this example, whether multiple annotation representation > should > > > be like below? > > > > > > { > > > "example:interface" : [ > > > { > > > "name" : "eth1", > > > "mtu" : 1500, > > > "@mtu" : { > > > "ietf-netconf-with-defaults:default" : true > > > }, > > > { > > > "ietf-origin:origin" : intended > > > }, > > > "status" : "up" > > > } > > > ] > > > } > > > > > > Thanks, > > > Amar > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > --00000000000035917b0581d99aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert, Ladislav,

Thanks for the clarification. I think it would be helpful if an e= xample of encoding multiple annotations in JSON metadata encoding is mentio= ned in any of the related drafts.=C2=A0

Thanks,=C2=A0
Amar

On Thu 14 Feb, 2019, 5:10 PM Ladi= slav Lhotka <lhotka@nic.cz wrote:
On Thu, 2019-02-14 at 11:26 +0000, R= obert Wilton wrote:
> Hi Amar,
> Based on RFC 7952 section 5.2.1, I think that it would look like this:=
> {
>=C2=A0 =C2=A0 =C2=A0"example:interface" : [
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" : "eth1= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "mtu" : 1500,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "@mtu" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;ietf-netconf-with-defaults:default" : true,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;ietf-origin:origin" : intended
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "status" : "up= "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0]
> }
> Thanks,
> Rob

It depends. The version above is correct but both annotations are attached = to
the "mtu" leaf. If the idea was to attach the origin annotation t= o the interface
entry, then it should be encoded like this:

{
=C2=A0 =C2=A0 "example:interface" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"name" : "eth1"= ;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"mtu" : 1500,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"@mtu" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-n= etconf-with-defaults:default" : true
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "@" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;ietf-origin:origin" : intended
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "status" : "= ;up"
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 ]
}

Lada

>
> On 14/02/2019 06:49, Amar Jadagoud wrote:
> > Hi All,
> >
> > I have a question regarding encoding of origin annotation along w= ith other
> > annotation (with-defaults) in JSON metadata encoding format.
> >
> > Suppose if below is the GET method :
> >
> > GET /restconf/ds/ietf-datastores:operational/ietf-
> > interface:interfaces/interface=3Deth1?with-defaults=3Dreport-all-= tagged&with-
> > origin HTTP/1.1
> >
> > How both origin and with-defaults annotations should be encoded i= n the JSON
> > metadata encoding format?
> >
> > Currently in restconf RFC 8040, in section 5.3.2, example with on= ly one
> > annotation is provided.
> >
> >=C2=A0 Refering to this example, whether multiple annotation repre= sentation should
> > be like below?
> >
> > {
> >=C2=A0 =C2=A0 =C2=A0"example:interface" : [
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" : "= ;eth1",
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "mtu" : 1500,<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "@mtu" : {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"ietf-netconf-with-defaults:default" : true
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"ietf-origin:origin" : intended
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"statu= s" : "up"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0]
> > }
> >
> > Thanks,
> > Amar
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listin= fo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/ne= tmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

--00000000000035917b0581d99aa4-- From nobody Thu Feb 14 13:18:05 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 0BD57130E82 for ; Thu, 14 Feb 2019 13:18:04 -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 uc9k5G-4YTEs for ; Thu, 14 Feb 2019 13:18:01 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680061.outbound.protection.outlook.com [40.107.68.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF8D129BBF for ; Thu, 14 Feb 2019 13:18:00 -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=9nSUWDprV/QNmFmoPxBX6vyDiBLaRXJUzvwLwjwpIMQ=; b=ELXfEDJgR4TSFEkh7AR/UjVY2ljNUxsielcoFLcBkeCkNnNzsUUF6HiZfZy8VJiJUzeXqap23oCE0llrDXqvQoAinrgUHgs2a/sZ76ZOJk5A1/A4uvYlgEZ4whEZ9+j5RGSrYlFxrkU6K8br2uHhneCSxr1AXvI2I7u29B70Cnw= Received: from CY4PR2201CA0010.namprd22.prod.outlook.com (2603:10b6:910:5f::20) by BN6PR22MB0596.namprd22.prod.outlook.com (2603:10b6:404:da::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Thu, 14 Feb 2019 21:17:59 +0000 Received: from DM3NAM03FT008.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::206) by CY4PR2201CA0010.outlook.office365.com (2603:10b6:910:5f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Thu, 14 Feb 2019 21:17:58 +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 DM3NAM03FT008.mail.protection.outlook.com (10.152.82.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Thu, 14 Feb 2019 21:17:58 +0000 From: Alex Campbell To: Amar Jadagoud CC: "netmod@ietf.org" Thread-Topic: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 Thread-Index: AQHUxKrBk92aPIM/b0ykjjn3Fs3TlA== Date: Thu, 14 Feb 2019 21:17:56 +0000 Message-ID: <1550179076775.3994@Aviatnet.com> References: 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.9] Content-Type: multipart/alternative; boundary="_000_15501790767753994Aviatnetcom_" 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)(346002)(39850400004)(396003)(2980300002)(53754006)(199004)(189003)(106466001)(4326008)(30436002)(117636001)(71190400001)(53416004)(16586007)(6246003)(229853002)(7736002)(97876018)(7636002)(54896002)(7596002)(25786009)(118246002)(356004)(316002)(36736006)(4546004)(3846002)(186003)(8936002)(446003)(8676002)(7696005)(76176011)(6116002)(19627405001)(72206003)(11346002)(478600001)(106002)(102836004)(2906002)(956004)(36756003)(26005)(6486002)(486006)(53546011)(246002)(2616005)(336012)(6916009)(84326002)(476003)(126002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR22MB0596; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT008; 1:zUMlTfRBpjL+1jRy4HDYR7dRCUZ2FtnqomqWTh6jy1Y/DMumil75o2VBhSUHGbTI6Bu39ixQ+UfsxY3NKf3xOr3T6rRW8woEOQ2n/qAKCdp1bBM42uYi401bjg9CJXS1A/spT1ClSj/y9dkaP8e7dtf3AtCEzfbXjMI1FAim2QU= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b8e2183a-c255-462c-19e9-08d692c1e4e5 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060)(7193020); SRVR:BN6PR22MB0596; X-MS-TrafficTypeDiagnostic: BN6PR22MB0596: X-Microsoft-Exchange-Diagnostics: 1; BN6PR22MB0596; 20:2ejRRU+cn20xx/CzfGjd7hda/r/GZdHePUKMAlg1eSIa0b5ykxZTlVltNrSWEGML/b21pli2khZaYmFo0bh4u6ejQpMBoPXahWLJ1F6y2ycwM0inYoJb1UdGevzV+1Nx3gG/HNbQ3Ou2aFYu2DVrm5z0YDpPKyT4WafAiw42r60eEKYpZbaeiTPxQdINcjzZlHhycVp7BHcW1bEYVQQTXa4nma+pi+rKPDs23oA7H2O3ubjDSDUPhE+6f9Hk5lkwiK/q/C9CX4S8NJ9gAliah+Anyhs/SfQEnCoj8FylGmZCb+giM5Nln2dP5i5fJMTNaDB97u9dlrnxUJjcTtzhJj1Mq1KFeJKYGwXXcTS8CfiIAhEle1GUZG9+5Qh2GZ+GRZgckAyrXRqIeHvDjBNAmfetjlU/wJ+Oc9Mc4KZ1Bjc1OL1koAaBPTLo8I700Lxf7coS3CXV5Z1OX86jxjbRWDhHTommSJk8AyhIfFA3mwDCAcZzibRXKGNAZ2ApklRK X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09480768F8 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR22MB0596; 23:PiFCESRvwcuU/cVparkYqAh3Hdxv/qyi86MfkBo2j?= =?us-ascii?Q?BtLtv3lutu5zRWM4/4ZZyF7VB0DS40gLhB3V4CHPcwymNn8Ly+LF7X1lsF0S?= =?us-ascii?Q?i5K/JofMY/RvXrIT08PONcHavu/gohdy3IVoQykuDdxbQVR45B8SlWeJQBDm?= =?us-ascii?Q?VLoG7ao8Zvg91kwTmvLbklXlmWMcOTUXWYEW1Zx/6N5kW6IwLfLMPbYe88SJ?= =?us-ascii?Q?FkgH4Ffped8jwoIDxXCc1b/mcoENU9hgHaSiju3gSvib8IYE8iI8jrkHVfio?= =?us-ascii?Q?5OO3vDRYjpudBywsvsHzBnfkgUYfXXR4aEgPrDecL/b1CLJHA8oCADml1PLo?= =?us-ascii?Q?eiWhzTMkpw6audoQcgcjxVK+FVtuQrnBLe6rzZKh8XAM+WJuPNk1+X3PyXjZ?= =?us-ascii?Q?NSmnhqp+HvVHNNSYiORfqbAFAMEdQ76Bi+2Vg++Bm0SLxS1aXWGkhubPYEIk?= =?us-ascii?Q?7NbCGWNgm64kzhesPH9EKyhZntxtlzToTGAXDl6kBOtsZrFjte2EyL34aePj?= =?us-ascii?Q?1rHtHpV733Uap4x0rgY7uX+Jha/33DwhbnrEcnovHFZ1wr6TXfTQeaHjKVKU?= =?us-ascii?Q?UrDYtDXPr1Mo3QqjhdxSqZSN5tNMo7eKkkTr61lVPMj7uCcn23gxXbahqvtU?= =?us-ascii?Q?E5Vhurnra8RxZyJBdhZQy3162LGChGIc/u3PpRUGjMOcsFCT5xzI6GfLh9w+?= =?us-ascii?Q?az05MCM0UZhyxxPkcCqUIIiS//X6+Z3xeVuPoax4Nns2AqqQydEGmYmiHd6g?= =?us-ascii?Q?5IUWELnMvPVek+Kb16lvXtFIy966pevqaw5pGT1dd5IeW+KnWS+25bK5pjww?= =?us-ascii?Q?74zEIQCTCdaxt3HeasATiy25WrDnOxBFAoPxQGzXJnPw65r5IdTSj7uCmM5m?= =?us-ascii?Q?oQwQuLgQEEf88lFvbCtmYBuJ6De+oSDpWVjDqY4W9MeNlBjy3dFMVWTmuqm1?= =?us-ascii?Q?wMdZiKoZjxvgRw3q1lij3iAb0KyQhYbSup6/B4c2n6tew1JKJoarm8c34u9A?= =?us-ascii?Q?C4zMSBEWoJ9qGqjIzgaVj5dxPcMc9vw8ktQ1J+JT3YHEJCZk5wxfmJqRnlKX?= =?us-ascii?Q?jr2ohjf0wlIa/3GAPDWamu3FQe8cPD+/1DD9tKJnX93Q9+MR0+/ndntekzrK?= =?us-ascii?Q?UBQfwajfA79zfvmj5hwQZ+1SY9jX9eU3mV/hxx06jSuA0wCKZRiotVYSRILL?= =?us-ascii?Q?ByPo9aIkU4lomFuKKRUdcXE2RlfmD5Q/+PBx2JFyBt35+aw839unxBKhx+MN?= =?us-ascii?Q?HD8LLLOKcYn7x9RlKhCbYLGWGCqINvOtPImrAkC?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 9d663r0H1pc04ZJjHY0yxkD1bB5w5zwyalAEljs1pdHeqOp08QXZI374RsW/yciik/crpiNes4CICk/jd7nu93/p2pZ2ABoJyb7bORS+ViRdxQjh/pcLvX/DnZWKUWrL0PyS+aWfHXIsx6xwQ4nVLjRHQN60XKKa2FxXrjV6nW6vrQR/fKY1QvXdjy4Gm9qUCLkrWjx2Nh0bJ2P5kQHKR92xsGuKvMqIbMmZOj4YzuZLgcV36lTeCi0Ay3mo/QrcSBJujjaZycHU0HxtVB4vjtggyTp7iUx0VTEUbFyXLK8EmKSbj/1ALo67ReHQ1AglXk+LpUy/SUEePLO43fjzm4+lI/vn30XYPJdHc7QotwFGyWGlP9xa7twq6ErQakEPxw6wyPz7raD3FPYxcqFhJA1wxb4pxArajGf8zGaa9tk= X-OriginatorOrg: aviatnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2019 21:17:58.3645 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b8e2183a-c255-462c-19e9-08d692c1e4e5 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: BN6PR22MB0596 Archived-At: Subject: Re: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 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 Feb 2019 21:18:04 -0000 --_000_15501790767753994Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, By my understanding both annotations should be included in one JSON object,= like this. { "example:interface" : [ { "name" : "eth1", "mtu" : 1500, "@mtu" : { "ietf-netconf-with-defaults:default" : true, "ietf-origin:origin" : "intended" }, "status" : "up" } ] } ________________________________ From: netmod on behalf of Amar Jadagoud Sent: Thursday, 14 February 2019 7:49 p.m. To: netmod@ietf.org Subject: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda= -restconf-05 Hi All, I have a question regarding encoding of origin annotation along with other = annotation (with-defaults) in JSON metadata encoding format. Suppose if below is the GET method : GET /restconf/ds/ietf-datastores:operational/ietf-interface:interfaces/inte= rface=3Deth1?with-defaults=3Dreport-all-tagged&with-origin HTTP/1.1 How both origin and with-defaults annotations should be encoded in the JSON= metadata encoding format? Currently in restconf RFC 8040, in section 5.3.2, example with only one ann= otation is provided. Refering to this example, whether multiple annotation representation shoul= d be like below? { "example:interface" : [ { "name" : "eth1", "mtu" : 1500, "@mtu" : { "ietf-netconf-with-defaults:default" : true }, { "ietf-origin:origin" : intended }, "status" : "up" } ] } Thanks, Amar --_000_15501790767753994Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


By my understanding both annotations should be included in one JSON obje= ct, like this.

{
    "example:interface" : [
       {
           "name"= : "eth1", 
           "mtu" = : 1500,
           "@mtu"= : {
                &= nbsp; "ietf-netconf-with-defaults:default" : true,
                &= nbsp; "ietf-origin:origin" : "intended"
            }, 
            "status&qu= ot; : "up" 
      } 
  ] 
}



From: netmod <netmod-b= ounces@ietf.org> on behalf of Amar Jadagoud <ammys.vas@gmail.com><= br> Sent: Thursday, 14 February 2019 7:49 p.m.
To: netmod@ietf.org
Subject: [netmod] Regarding origin annotation encoding in ietf-netco= nf-nmda-restconf-05
 
Hi All,

I have a question regarding encoding of origin annotation= along with other annotation (with-defaults) in JSON metadata encoding form= at. 

Suppose if below is the GET method :

GET /restconf/ds/ietf-datastores:operational/ietf-interfa= ce:interfaces/interface=3Deth1?with-defaults=3Dreport-all-tagged&with-o= rigin HTTP/1.1

How both origin and with-defaults annotations should be e= ncoded in the JSON metadata encoding format? 

Currently in restconf RFC 8040, in section 5.3.2, example= with only one annotation is provided.

 Refering to this example, whether multiple annotati= on representation should be like below? 

{
    "example:interface" : [
       {
           "name"= : "eth1", 
           "mtu" = : 1500,
           "@mtu"= : {
                &= nbsp; "ietf-netconf-with-defaults:default" : true
              }, =
              {
                &= nbsp;   "ietf-origin:origin" : intended
              }, =
              "st= atus" : "up" 
      } 
  ] 
} 

Thanks, 
Amar
--_000_15501790767753994Aviatnetcom_-- From nobody Thu Feb 14 19:27: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 8E504130E92 for ; Thu, 14 Feb 2019 19:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 v4OibOMJcTqV for ; Thu, 14 Feb 2019 19:27:27 -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 AB4BE130E7D for ; Thu, 14 Feb 2019 19:27:26 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6A91B7D6B28FEA05EA1D for ; Fri, 15 Feb 2019 03:27:24 +0000 (GMT) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 15 Feb 2019 03:27:22 +0000 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 15 Feb 2019 03:27:22 +0000 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml708-chm.china.huawei.com (10.201.108.57) 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, 15 Feb 2019 03:27:21 +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, 15 Feb 2019 11:27:11 +0800 From: Rohit R Ranade To: Robert Wilton , Amar Jadagoud , "netmod@ietf.org" Thread-Topic: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 Thread-Index: AQHUxDGG4DkfFamfa0SWfA5SnmCb+KXeocmAgAGQMvA= Date: Fri, 15 Feb 2019 03:27:10 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCF8947@dggeml510-mbx.china.huawei.com> References: In-Reply-To: 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_991B70D8B4112A4699D5C00DDBBF878A6BCF8947dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Regarding origin annotation encoding in ietf-netconf-nmda-restconf-05 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 Feb 2019 03:27:29 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6BCF8947dggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgdmFsdWUg4oCYaW50ZW5kZWTigJkgc2hvdWxkIGJlIG5hbWVzcGFjZSBxdWFs aWZpZWQgdG8gZW5zdXJlIHVuaXF1ZW5lc3MuDQoNClNlY3Rpb24gNS4yLjEgaW4gUkZDIDc5NTI6 DQrigJxUaGUgdmFsdWUgb2YgYSBtZXRhZGF0YSBhbm5vdGF0aW9uIFNIQUxMIGJlIGVuY29kZWQg aW4gZXhhY3RseSB0aGUNCiAgIHNhbWUgd2F5IGFzIHRoZSB2YWx1ZSBvZiBhIFlBTkcgbGVhZiBu b2RlIGhhdmluZyB0aGUgc2FtZSB0eXBlIGFzIHRoZQ0KICAgYW5ub3RhdGlvbuKAnQ0KDQoNCg0K ew0KICAgICJleGFtcGxlOmludGVyZmFjZSIgOiBbDQogICAgICAgew0KICAgICAgICAgICAibmFt ZSIgOiAiZXRoMSIsDQogICAgICAgICAgICJtdHUiIDogMTUwMCwNCiAgICAgICAgICAgIkBtdHUi IDogew0KICAgICAgICAgICAgICAgICAgImlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzOmRlZmF1 bHQiIDogdHJ1ZSwNCiAgICAgICAgICAgICAgICAgICJpZXRmLW9yaWdpbjpvcmlnaW4iIDog4oCc aWV0Zi1vcmlnaW46aW50ZW5kZWTigJ0NCiAgICAgICAgICAgICAgfSwNCiAgICAgICAgICAgInN0 YXR1cyIgOiAidXAiDQogICAgICB9DQogIF0NCn0NCg0KV2l0aCBSZWdhcmRzLA0KUm9oaXQgUg0K DQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDogMTQgRmVicnVhcnkgMjAxOSAxNjo1Nw0KVG86IEFt YXIgSmFkYWdvdWQgPGFtbXlzLnZhc0BnbWFpbC5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBSZWdhcmRpbmcgb3JpZ2luIGFubm90YXRpb24gZW5jb2RpbmcgaW4g aWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUNCg0KDQpIaSBBbWFyLA0KDQpCYXNlZCBvbiBS RkMgNzk1MiBzZWN0aW9uIDUuMi4xLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgbG9vayBsaWtlIHRo aXM6DQoNCnsNCiAgICAiZXhhbXBsZTppbnRlcmZhY2UiIDogWw0KICAgICAgIHsNCiAgICAgICAg ICAgIm5hbWUiIDogImV0aDEiLA0KICAgICAgICAgICAibXR1IiA6IDE1MDAsDQogICAgICAgICAg ICJAbXR1IiA6IHsNCiAgICAgICAgICAgICAgICAgICJpZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0 czpkZWZhdWx0IiA6IHRydWUsDQogICAgICAgICAgICAgICAgICAiaWV0Zi1vcmlnaW46b3JpZ2lu IiA6IGludGVuZGVkDQogICAgICAgICAgICAgIH0sDQogICAgICAgICAgICJzdGF0dXMiIDogInVw Ig0KICAgICAgfQ0KICBdDQp9DQoNClRoYW5rcywNClJvYg0KDQoNCk9uIDE0LzAyLzIwMTkgMDY6 NDksIEFtYXIgSmFkYWdvdWQgd3JvdGU6DQpIaSBBbGwsDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIHJl Z2FyZGluZyBlbmNvZGluZyBvZiBvcmlnaW4gYW5ub3RhdGlvbiBhbG9uZyB3aXRoIG90aGVyIGFu bm90YXRpb24gKHdpdGgtZGVmYXVsdHMpIGluIEpTT04gbWV0YWRhdGEgZW5jb2RpbmcgZm9ybWF0 Lg0KDQpTdXBwb3NlIGlmIGJlbG93IGlzIHRoZSBHRVQgbWV0aG9kIDoNCg0KR0VUIC9yZXN0Y29u Zi9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwvaWV0Zi1pbnRlcmZhY2U6aW50ZXJmYWNl cy9pbnRlcmZhY2U9ZXRoMT93aXRoLWRlZmF1bHRzPXJlcG9ydC1hbGwtdGFnZ2VkJndpdGgtb3Jp Z2luIEhUVFAvMS4xDQoNCkhvdyBib3RoIG9yaWdpbiBhbmQgd2l0aC1kZWZhdWx0cyBhbm5vdGF0 aW9ucyBzaG91bGQgYmUgZW5jb2RlZCBpbiB0aGUgSlNPTiBtZXRhZGF0YSBlbmNvZGluZyBmb3Jt YXQ/DQoNCkN1cnJlbnRseSBpbiByZXN0Y29uZiBSRkMgODA0MCwgaW4gc2VjdGlvbiA1LjMuMiwg ZXhhbXBsZSB3aXRoIG9ubHkgb25lIGFubm90YXRpb24gaXMgcHJvdmlkZWQuDQoNCiBSZWZlcmlu ZyB0byB0aGlzIGV4YW1wbGUsIHdoZXRoZXIgbXVsdGlwbGUgYW5ub3RhdGlvbiByZXByZXNlbnRh dGlvbiBzaG91bGQgYmUgbGlrZSBiZWxvdz8NCg0Kew0KICAgICJleGFtcGxlOmludGVyZmFjZSIg OiBbDQogICAgICAgew0KICAgICAgICAgICAibmFtZSIgOiAiZXRoMSIsDQogICAgICAgICAgICJt dHUiIDogMTUwMCwNCiAgICAgICAgICAgIkBtdHUiIDogew0KICAgICAgICAgICAgICAgICAgImll dGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzOmRlZmF1bHQiIDogdHJ1ZQ0KICAgICAgICAgICAgICB9 LA0KICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICJpZXRmLW9yaWdpbjpvcmln aW4iIDogaW50ZW5kZWQNCiAgICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICAgInN0YXR1cyIg OiAidXAiDQogICAgICB9DQogIF0NCn0NCg0KVGhhbmtzLA0KQW1hcg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbmV0bW9kIG1haWxpbmcg bGlzdA0KDQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== --_000_991B70D8B4112A4699D5C00DDBBF878A6BCF8947dggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7 DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6 YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6 YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OuWui+S9 kzt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSB2YWx1ZSDigJhpbnRlbmRlZOKA mSBzaG91bGQgYmUgbmFtZXNwYWNlIHF1YWxpZmllZCB0byBlbnN1cmUgdW5pcXVlbmVzcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+U2VjdGlvbg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDAwMzIiPjUuMi4x IGluIFJGQyA3OTUyOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgdmFsdWUg b2YgYSBtZXRhZGF0YSBhbm5vdGF0aW9uIFNIQUxMDQogYmUgZW5jb2RlZCBpbiBleGFjdGx5IHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzYW1l IHdheSBhcyB0aGUgdmFsdWUgb2YgYSBZQU5HIGxlYWYgbm9kZSBoYXZpbmcgdGhlIHNhbWUgdHlw ZSBhcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hbm5vdGF0 aW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCd DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHR0PjxzcGFu IGxhbmc9IkVOLVVTIj57PC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjx0dD4m bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZXhhbXBsZTppbnRlcmZhY2UmcXVvdDsgOiBbPC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7bmFtZSZxdW90OyA6ICZxdW90O2V0aDEmcXVvdDssIDwvdHQ+PGJyPg0K PHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDttdHUmcXVvdDsgOiAxNTAwLDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtA bXR1JnF1b3Q7IDogezwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0czpkZWZhdWx0 JnF1b3Q7IDogdHJ1ZSw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aWV0Zi1vcmlnaW46b3JpZ2luJnF1b3Q7IDog4oCcaWV0 Zi1vcmlnaW46aW50ZW5kZWTigJ08L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fSwgPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3N0YXR1cyZxdW90OyA6ICZxdW90O3VwJnF1b3Q7 IDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9IDwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyBdIDwvdHQ+PGJyPg0KPHR0Pn08bzpwPjwvbzpwPjwvdHQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaXRoIFJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb2hpdCBSPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFdpbHRvbjxicj4NCjxiPlNl bnQ6PC9iPiAxNCBGZWJydWFyeSAyMDE5IDE2OjU3PGJyPg0KPGI+VG86PC9iPiBBbWFyIEphZGFn b3VkICZsdDthbW15cy52YXNAZ21haWwuY29tJmd0OzsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBSZWdhcmRpbmcgb3JpZ2luIGFubm90YXRpb24gZW5j b2RpbmcgaW4gaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5I aSBBbWFyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5CYXNl ZCBvbiBSRkMgNzk1MiBzZWN0aW9uIDUuMi4xLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgbG9vayBs aWtlIHRoaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHR0PjxzcGFuIGxhbmc9IkVOLVVT Ij57PC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7ZXhhbXBsZTppbnRlcmZhY2UmcXVvdDsgOiBbPC90dD48YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7bmFtZSZxdW90OyA6ICZxdW90O2V0aDEmcXVvdDssIDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDttdHUmcXVvdDsgOiAxNTAwLDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtAbXR1JnF1b3Q7IDog ezwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtpZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0czpkZWZhdWx0JnF1b3Q7IDogdHJ1 ZSw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJnF1b3Q7aWV0Zi1vcmlnaW46b3JpZ2luJnF1b3Q7IDogaW50ZW5kZWQ8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSwgPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3N0 YXR1cyZxdW90OyA6ICZxdW90O3VwJnF1b3Q7IDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB9IDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyBdIDwvdHQ+PGJyPg0KPHR0 Pn08L3R0PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFu a3MsPGJyPg0KUm9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gMTQvMDIvMjAxOSAwNjo0OSwgQW1hciBKYWRhZ291ZCB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBBbGwsIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyBlbmNvZGlu ZyBvZiBvcmlnaW4gYW5ub3RhdGlvbiBhbG9uZyB3aXRoIG90aGVyIGFubm90YXRpb24gKHdpdGgt ZGVmYXVsdHMpIGluIEpTT04gbWV0YWRhdGEgZW5jb2RpbmcgZm9ybWF0LiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3VwcG9zZSBpZiBiZWxv dyBpcyB0aGUgR0VUIG1ldGhvZCA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5HRVQgL3Jlc3Rjb25mL2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25h bC9pZXRmLWludGVyZmFjZTppbnRlcmZhY2VzL2ludGVyZmFjZT1ldGgxP3dpdGgtZGVmYXVsdHM9 cmVwb3J0LWFsbC10YWdnZWQmYW1wO3dpdGgtb3JpZ2luIEhUVFAvMS4xPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3cgYm90aCBvcmlnaW4gYW5kIHdp dGgtZGVmYXVsdHMgYW5ub3RhdGlvbnMgc2hvdWxkIGJlIGVuY29kZWQgaW4gdGhlIEpTT04gbWV0 YWRhdGEgZW5jb2RpbmcgZm9ybWF0PyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q3VycmVudGx5IGluIHJlc3Rjb25mIFJGQyA4MDQwLCBpbiBz ZWN0aW9uIDUuMy4yLCBleGFtcGxlIHdpdGggb25seSBvbmUgYW5ub3RhdGlvbiBpcyBwcm92aWRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw O1JlZmVyaW5nIHRvIHRoaXMgZXhhbXBsZSwgd2hldGhlciBtdWx0aXBsZSBhbm5vdGF0aW9uIHJl cHJlc2VudGF0aW9uIHNob3VsZCBiZSBsaWtlIGJlbG93PyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsgJm5ic3A7ICZxdW90O2V4YW1wbGU6aW50ZXJmYWNlJnF1b3Q7IDogWzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7bmFtZSZx dW90OyA6ICZxdW90O2V0aDEmcXVvdDssJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7bXR1JnF1b3Q7IDogMTUw MCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmcXVvdDtAbXR1JnF1b3Q7IDogezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm cXVvdDtpZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0czpkZWZhdWx0JnF1b3Q7IDogdHJ1ZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfSwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZxdW90O2lldGYtb3JpZ2luOm9yaWdpbiZxdW90OyA6IGludGVuZGVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB9LCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3RhdHVzJnF1b3Q7IDogJnF1b3Q7 dXAmcXVvdDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg fSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgXSZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj59Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFua3MsJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFtYXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5u ZXRtb2QgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_991B70D8B4112A4699D5C00DDBBF878A6BCF8947dggeml510mbxchi_-- From nobody Fri Feb 15 01:12: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 BF452130F5F for ; Fri, 15 Feb 2019 01:12: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, 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 WF1DQTZ8lUA7 for ; Fri, 15 Feb 2019 01:12:41 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140092.outbound.protection.outlook.com [40.107.14.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB40130F28 for ; Fri, 15 Feb 2019 01:12:41 -0800 (PST) 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=Uy1QTll3yjsipuSjO4bLj5kH1d68Mbr0zy4QEyUWxlE=; b=Lm75rQ5euxUXRsu/bjFn9eYStChGjj6KiC5wZqc2Z4T7lBtCl9BS9aUwd49PsHHM77ySmx7jNhi4b2GmgcfZULk4vai1blLp93B3yurQbExpJpqwvamqNeOLZDVvQqyG+P5YsEo7WvE5r+rju9RXtCvFVPk2xzsjHeDv8p5fuBU= Received: from VI1PR07MB5792.eurprd07.prod.outlook.com (20.178.121.222) by VI1PR07MB4559.eurprd07.prod.outlook.com (20.177.56.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.12; Fri, 15 Feb 2019 09:12:26 +0000 Received: from VI1PR07MB5792.eurprd07.prod.outlook.com ([fe80::b1cf:d9b9:6654:e6bf]) by VI1PR07MB5792.eurprd07.prod.outlook.com ([fe80::b1cf:d9b9:6654:e6bf%4]) with mapi id 15.20.1643.008; Fri, 15 Feb 2019 09:12:26 +0000 From: "Beauville, Yves (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Augmentation with a mandatory leaf in a submodule - Is the following legal? Thread-Index: AQHUxQ6Rb/ufk4ALnEO3ok4pna4OcQ== Date: Fri, 15 Feb 2019 09:12:25 +0000 Message-ID: <6b988ca0-7634-6a57-e984-6553f8f706b7@nokia.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.32.166] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 x-clientproxiedby: LO2P265CA0189.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::33) To VI1PR07MB5792.eurprd07.prod.outlook.com (2603:10a6:803:cf::30) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b4c25855-47a9-4e12-9bc4-08d69325b3a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7193020); SRVR:VI1PR07MB4559; x-ms-traffictypediagnostic: VI1PR07MB4559: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUI0NTU5OzIzOkJpQmF3WnErOSthcWk2UjZ0SXJjelE0MUdo?= =?utf-8?B?emp5Tm0xRHFyVDZLUG5FczEyYlg3eE1VMjBkWDRnMHhpcnNBdkJpMmg0cXY3?= =?utf-8?B?Q21pWkdkYTlhTEZYRUptb2Z6OVgra1BETUlteEZaZXU1a2gxcXowNXlGU1FE?= =?utf-8?B?elpXb3FtUm0wWk9Qd1dqNWZKSjhia05mZnBGS2l1dFhTMXJVVzRzOE15d0lJ?= =?utf-8?B?dWQ0a041K1M5UXQxbC9xQm1IKzNOcnlJc3BsVkx0dEZrT1IxRmpWZTdzSGNs?= =?utf-8?B?enpUbHdZVzR1WnU1TVNYQmVScTV0bmwwajZRd2U5SWgwdTI4QWRyTHY1eUMv?= =?utf-8?B?SExxQXBXbnZLa21DWUFHOFVSVlc0eWRTK2RZcjhMR25lNDlDdlZIaDlCSElK?= =?utf-8?B?Nzd2aDBReW05OEtNQmFkdm5kM1pRRGJVU0tiZUsxTGFEdHBDS0srZzA5TlEz?= =?utf-8?B?bGp6M1J3c3Noelg4SXYwVGtmZ21lWWFBamt3VS9NR29qK2RKZHVxR0tvUTZn?= =?utf-8?B?NTl6Vjk3WUZjT3VrTFBxcXNvYm1Ud0JrbWh0MkZQRjlDNjNvMFM0Q3QvY1M0?= =?utf-8?B?MTB1Q2xWeDhuSHpaQmVNMEQvekNMQTl4NGt4U2RCNUZCb1pIZXE1dWxRclZh?= =?utf-8?B?M2Q1V3lsa3c1UExadVprM1Q5K2FxcmkwMFFQV2hkUEhmZDRHYWk5ajJ5N0xo?= =?utf-8?B?ZVh4anRLWnZ5b04ybVphK1Z4VmhhWjhnc2NjSThvVDBOQk02aFJIZ1pZUXQy?= =?utf-8?B?K3NocVM1RGFSUit0OWtMS0dEWE5CVFBKdDBMYjljSGlPSjBseWJoNkFzNU8r?= =?utf-8?B?L01XSWhuOTBseU5heDZGRFk0ZHZocHQzY1o5Q1ZnZThpSXg2MlQrZW40RjFt?= =?utf-8?B?OVR2RnJWSWZPc01jVldmUFlZdGJIaWhOOCtzbEhUbWJDSjJKVkN6Z2gwTUNG?= =?utf-8?B?Ykk5aVpmUS9BOGJpNFdzL0o3c3h1b2d1cUF3Uy9YTzY3QmlYOXZ5dkFzKzhS?= =?utf-8?B?VlluWWZIaDZYdlRheEpPREh5WHdMQzB2UkRoYVQ5YjB5VlMxWHlzSC93VXRL?= =?utf-8?B?REdyNEI5c3BjUjkxcjRPUEQwRm1DWEhLS3pvS0tCZklMaVQ4bTF5UStyS2hj?= =?utf-8?B?VThLOVlpMEtHL2lqMXNacDh6blJiOGt1TU96a1l2Z3ZaZTl1aE1NcjVGZGx5?= =?utf-8?B?VFZRVk9DaTZEWUZFSzNhMW95bERLKzlPMXhmNFZ1Z3M0VE9yTGlRVmxsV3Vh?= =?utf-8?B?RXFNZGl0WEE3Wlk0UFZzSEJvT2o0WEwyYUcySFdFU2ZPN2ZNT3VhQWJHaFNo?= =?utf-8?B?c0ljdkM4UHBEY2UrM1kwVmQ5YnNScmhudDdoN2xkTVY5SGdSdUNlcGxsRE5n?= =?utf-8?B?TzVrYlUyQkFWaHdQMEsvdFNJZzlpaEFGRWIyVkVYbnBnVTk1S3JXbzIvZDVz?= =?utf-8?B?eGFUMm1URDN1bHhTemsvc3pYRmlaZ2NMb1k3L3lYaXA2N2hraVhsSDhQcTlQ?= =?utf-8?B?NzRzMnpIWm5OdGNOV2RuV1U4SkwwMmE2ZEczbzJlOUZObGZMTC9UZ1ZVaUxu?= =?utf-8?B?QWNaYU9nQldMbEtKeTZJSzVESTJBQ0RjaUJycGdVWTU5Q1hEVFBuSGtiR0Fh?= =?utf-8?B?aHNONDBlN1lVQjRQQnlWZXhFZ1p3VDdFNHVKZmhreUtaeDROQ0lqdU5OcUFw?= =?utf-8?B?R3Zndk9RZ1cwWkRUREM3QUR6YWdYMWQzdXZsaDE2eHBQL0tjQi96bW9LNVlB?= =?utf-8?B?cUg4R2VSMkk4QmhkbHBDZmk1RzBZSFo3djh1QzY3WUtBSSsxYWJ6YllaNjZO?= =?utf-8?B?UWJBRkNEeWFLbkpEb3ZzSUQ5Z3haU01FaVFtUytETmJMV3M1U3k0ZENnWFMv?= =?utf-8?Q?7Qdu0PQAbGI=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09497C15EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(366004)(396003)(189003)(199004)(2906002)(8936002)(2351001)(26005)(102836004)(7736002)(8676002)(81156014)(486006)(476003)(2616005)(316002)(81166006)(1730700003)(58126008)(6346003)(186003)(106356001)(386003)(52116002)(6506007)(65956001)(65806001)(99286004)(606006)(66066001)(71190400001)(256004)(5640700003)(54896002)(31686004)(105586002)(6116002)(71200400001)(64126003)(2501003)(3846002)(65826007)(36756003)(6916009)(68736007)(86362001)(6306002)(6512007)(14444005)(6486002)(478600001)(25786009)(966005)(31696002)(14454004)(53936002)(6436002)(97736004)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4559; H:VI1PR07MB5792.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yves.beauville@nokia.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bFiabZ9zIm7sciQ8UzqGbX4ZuMvWSID2pNGXE6lEKsoTfV3wM8FrLawhhlURULh98jyqxDlX6liKuvHefsPIUxvXg1nSgUycn97x0NICO6xxAGNkTk5ELdC1xQXp5bF+VCv56fqAHfKuz88a5vBuzOqXFgxe4kQ85MWr8o3HKeXUZHirGU+Qjtdhh3BtxzQaDTt2J9yjxBg9FijSRK2gFCQGlSj+4h350ijOdbshLmZv6qTct6iSJhcX1kNxZX/SUMXmdN2koDDTzUH4/lDLAXI+inBZj6qBq91ynA43Xjc+usYUCUjDYqCY260YvnT6fWFrQwC2IDIY8AxAq6xMeHk1YR8D/+g4uVUUq7EaVhNXMZ/r36dWL0zLRKlYQ+36Uge9Kv86KuZkJ6u8LQev+X6DkYOY+5ngKD0PVN/8MKc= Content-Type: multipart/alternative; boundary="_000_6b988ca076346a57e9846553f8f706b7nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4c25855-47a9-4e12-9bc4-08d69325b3a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 09:12:25.3590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4559 Archived-At: Subject: [netmod] Augmentation with a mandatory leaf in a submodule - Is the following legal? 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 Feb 2019 09:12:45 -0000 --_000_6b988ca076346a57e9846553f8f706b7nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGFyZSB3b3JraW5nIHdpdGggYSBzdWJtb2R1bGUgaW4gd2hpY2ggd2UgYXJlIGF1 Z21lbnRpbmcgYSBjb250YWluZXIgb2YgdGhlIHNhbWUgbW9kdWxlIHdpdGggYSBtYW5kYXRvcnkg bm9kZS4gVGhlcmUgaXMgYSBzbWFsbCBjYXRjaCB0aG91Z2guDQoNCk91ciBZQU5HIG1vZHVsZXMg YXJlIGFjdHVhbGx5IHN1cHBvcnRpbmcgdHdvIGF1Z21lbnRhdGlvbnMgLSBJIGhhdmUgY29waWVk IGEgdHJpbW1lZCBkb3duIHZlcnNpb24gb2Ygb3VyIG1vZHVsZXMgYXQgdGhlIGVuZCBvZiB0aGlz IG1haWwgLToNCg0KKiBGcm9tIGNvbnRhaW5lciAndG9wJyBpbiAnbW9kdWxlLWEnIHRvIGNvbnRh aW5lciAnZmlyc3QtYXVnbWVudCcgaW4gJ21vZHVsZS1iJyAoc3ViLW1vZHVsZS0xKSA9PiBUaGlz IGF1Z21lbnRhdGlvbiBpcyBtYWRlIGNvbmRpdGlvbmFsIHdpdGggYSAnd2hlbicgc3RhdGVtZW50 Lg0KDQoqIEZyb20gY29udGFpbmVyICdmaXJzdC1hdWdtZW50JyB0byBsZWFmICdtYW5kYXRvcnkt bGVhZicuIFRoaXMgaXMgZG9uZSB3aXRoaW4gdHdvIHN1Ym1vZHVsZXMgb2YgdGhlIHNhbWUgbW9k dWxlICdtb2R1bGUtYicgPT4gVGhpcyBhdWdtZW50YXRpb24gaXMgTk9UIGNvbmRpdGlvbmFsLg0K DQpUaGUgT3BlbiBEYXlsaWdodCBwYXJzZXIgcmVqZWN0cyBvdXIgWUFORyBtb2R1bGVzIHdpdGgg dGhlIGZvbGxvd2luZyBlcnJvcjoNCg0KICAgRmFpbGVkIHRvIGFkZCBhdWdtZW50YXRpb24gc3Vi LW1vZHVsZS0xYi55YW5nIGRlZmluZWQgYXQgc3ViLW1vZHVsZS0yYi55YW5nIG9yZy5vcGVuZGF5 bGlnaHQueWFuZ3Rvb2xzLnlhbmcucGFyc2VyLnNwaS5tZXRhLkluZmVyZW5jZUV4Y2VwdGlvbjog QW4gYXVnbWVudCBjYW5ub3QgYWRkIG5vZGUgJ21hbmRhdG9yeS1sZWFmJyBiZWNhdXNlIGl0IGlz IG1hbmRhdG9yeSBhbmQgaW4gbW9kdWxlIGRpZmZlcmVudCB0aGFuIHRhcmdldCBbYXQgc3ViLW1v ZHVsZS0yYi55YW5nXQ0KDQpBcyBwZXIgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5 NTAjc2VjdGlvbi03LjE3LCB3ZSBiZWxpZXZlIHRoZXNlIGF1Z21lbnRhdGlvbnMgYXJlIGJvdGgg bGVnYWwnLg0KDQpXZSBoYXZlIHJhaXNlZCBhIHRpY2tldCBZQU5HVE9PTFMtOTU2IGF0IE9wZW4g RGF5bGlnaHQgYnV0IGZvbGtzIGF0IE9ETCBhcmUgYXNraW5nIHVzIHRvIGNoZWNrIHdpdGggZXhw ZXJ0cyBpbiB0aGlzIG1haWxpbmcgbGlzdC4NCg0KQ2FuIG9uZSBhc3Nlc3MgaWYgdGhlc2UgbW9k ZWxzIGFyZSBtYWtpbmcgYSAnbGVnYWwnIHVzZSBvZiBhdWdtZW50YXRpb25zIG9yIG5vdD8NCg0K WXZlcw0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQptb2R1bGUgbW9kdWxl LWEgew0KICB5YW5nLXZlcnNpb24gMS4xOw0KICAgIG5hbWVzcGFjZSAiaHR0cDovL3d3dy5leGFt cGxlLmNvbS9hbm90aGVybW9kdWxlIjxodHRwOi8vd3d3LmV4YW1wbGUuY29tL2Fub3RoZXJtb2R1 bGU+Ow0KICAgIHByZWZpeCBhbTsNCiAgICBjb250YWluZXIgdG9wIHsNCiAgICAgIGxlYWYgdHlw ZSB7DQogICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICAg IH0NCiAgfQ0KfQ0KbW9kdWxlIG1vZHVsZS1iIHsNCiAgeWFuZy12ZXJzaW9uIDEuMTsNCiAgICBu YW1lc3BhY2UgImh0dHA6Ly93d3cuZXhhbXBsZS5jb20vbW9kdWxlLWIiPGh0dHA6Ly93d3cuZXhh bXBsZS5jb20vbW9kdWxlLWI+Ow0KICAgcHJlZml4IG1tOw0KICAgaW5jbHVkZSBzdWItbW9kdWxl LTE7DQogICBpbmNsdWRlIHN1Yi1tb2R1bGUtMjsNCn0NCnN1Ym1vZHVsZSBzdWItbW9kdWxlLTEg ew0KICAgeWFuZy12ZXJzaW9uIDEuMTsNCiAgIGJlbG9uZ3MtdG8gbW9kdWxlLWIgew0KICAgIHBy ZWZpeCBtbTsNCiAgfQ0KICAgIGltcG9ydCBtb2R1bGUtYSB7DQogICAgcHJlZml4IGFtOw0KICB9 DQogIGF1Z21lbnQgJy9hbTp0b3AnIHsNCiAgICB3aGVuICJhbTp0eXBlID0gJ3Rlc3QnIjsNCiAg ICBjb250YWluZXIgZmlyc3QtYXVnbWVudCB7DQogICAgfQ0KICB9DQp9DQpzdWJtb2R1bGUgc3Vi LW1vZHVsZS0yIHsNCiAgeWFuZy12ZXJzaW9uIDEuMTsNCiAgYmVsb25ncy10byBtb2R1bGUtYiB7 DQogICAgcHJlZml4IG1tOw0KICB9DQogICAgaW1wb3J0IG1vZHVsZS1hIHsNCiAgICBwcmVmaXgg YW07DQogIH0NCiAgaW5jbHVkZSBzdWItbW9kdWxlLTE7DQogIGdyb3VwaW5nIGR1bW15Z3JvdXBp bmcgew0KICAgIGxlYWYgbWFuZGF0b3J5LWxlYWYgew0KICAgICAgdHlwZSBzdHJpbmc7DQogICAg ICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICAgfQ0KICB9DQogIGF1Z21lbnQgJy9hbTp0b3AvbW06Zmly c3QtYXVnbWVudCcgew0KICAgIHVzZXMgZHVtbXlncm91cGluZzsNCiAgfQ0KfQ0K --_000_6b988ca076346a57e9846553f8f706b7nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <166D8730739F254CA70B767A7999895C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHRleHQ9IiMwMDAwMDAi IGJnY29sb3I9IiNGRkZGRkYiPg0KSGksPGJyPg0KPHA+V2UgYXJlIHdvcmtpbmcgd2l0aCBhIHN1 Ym1vZHVsZSBpbiB3aGljaCB3ZSBhcmUgYXVnbWVudGluZyBhIGNvbnRhaW5lciBvZiB0aGUgc2Ft ZSBtb2R1bGUgd2l0aCBhIG1hbmRhdG9yeSBub2RlLiBUaGVyZSBpcyBhIHNtYWxsIGNhdGNoIHRo b3VnaC48YnI+DQo8L3A+DQpPdXIgWUFORyBtb2R1bGVzIGFyZSBhY3R1YWxseSBzdXBwb3J0aW5n IHR3byBhdWdtZW50YXRpb25zIC0gSSBoYXZlIGNvcGllZCBhIHRyaW1tZWQgZG93biB2ZXJzaW9u IG9mIG91ciBtb2R1bGVzIGF0IHRoZSBlbmQgb2YgdGhpcyBtYWlsIC06DQo8cD4qIEZyb20gY29u dGFpbmVyICd0b3AnIGluICdtb2R1bGUtYScgdG8gY29udGFpbmVyICdmaXJzdC1hdWdtZW50JyBp biAnbW9kdWxlLWInIChzdWItbW9kdWxlLTEpID0mZ3Q7IFRoaXMgYXVnbWVudGF0aW9uIGlzIG1h ZGUgY29uZGl0aW9uYWwgd2l0aCBhICd3aGVuJyBzdGF0ZW1lbnQuPC9wPg0KPHA+KiBGcm9tIGNv bnRhaW5lciAnZmlyc3QtYXVnbWVudCcgdG8gbGVhZiAnbWFuZGF0b3J5LWxlYWYnLiBUaGlzIGlz IGRvbmUgd2l0aGluIHR3byBzdWJtb2R1bGVzIG9mIHRoZSBzYW1lIG1vZHVsZSAnbW9kdWxlLWIn ID0mZ3Q7IFRoaXMgYXVnbWVudGF0aW9uIGlzIE5PVCBjb25kaXRpb25hbC48L3A+DQpUaGUgT3Bl biBEYXlsaWdodCBwYXJzZXIgcmVqZWN0cyBvdXIgWUFORyBtb2R1bGVzIHdpdGggdGhlIGZvbGxv d2luZyBlcnJvcjoNCjxwPiZuYnNwOyZuYnNwOyBGYWlsZWQgdG8gYWRkIGF1Z21lbnRhdGlvbiBz dWItbW9kdWxlLTFiLnlhbmcgZGVmaW5lZCBhdCBzdWItbW9kdWxlLTJiLnlhbmcgb3JnLm9wZW5k YXlsaWdodC55YW5ndG9vbHMueWFuZy5wYXJzZXIuc3BpLm1ldGEuSW5mZXJlbmNlRXhjZXB0aW9u OiBBbiBhdWdtZW50IGNhbm5vdCBhZGQgbm9kZSAnbWFuZGF0b3J5LWxlYWYnIGJlY2F1c2UgaXQg aXMgbWFuZGF0b3J5IGFuZCBpbiBtb2R1bGUgZGlmZmVyZW50IHRoYW4gdGFyZ2V0IFthdA0KIHN1 Yi1tb2R1bGUtMmIueWFuZ108L3A+DQo8cD5BcyBwZXIgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi03LjE3IiBjbGFzcz0iZXh0ZXJuYWwtbGluayIg cmVsPSJub2ZvbGxvdyI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0 aW9uLTcuMTc8L2E+LCB3ZSBiZWxpZXZlIHRoZXNlIGF1Z21lbnRhdGlvbnMgYXJlIGJvdGggbGVn YWwnLg0KPGJyPg0KPC9wPg0KPHA+V2UgaGF2ZSByYWlzZWQgYSB0aWNrZXQgWUFOR1RPT0xTLTk1 NiBhdCBPcGVuIERheWxpZ2h0IGJ1dCBmb2xrcyBhdCBPREwgYXJlIGFza2luZyB1cyB0byBjaGVj ayB3aXRoIGV4cGVydHMgaW4gdGhpcyBtYWlsaW5nIGxpc3QuPC9wPg0KPHA+Q2FuIG9uZSBhc3Nl c3MgaWYgdGhlc2UgbW9kZWxzIGFyZSBtYWtpbmcgYSAnbGVnYWwnIHVzZSBvZiBhdWdtZW50YXRp b25zIG9yIG5vdD88YnI+DQo8L3A+DQo8cD5ZdmVzPGJyPg0KPC9wPg0KPHA+PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQo8L3A+DQptb2R1bGUgbW9kdWxlLWEgezxicj4NCiZu YnNwOyB5YW5nLXZlcnNpb24gMS4xOzxicj4NCiZuYnNwOyZuYnNwOyAmbmJzcDtuYW1lc3BhY2Ug PGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0iaHR0cDovL3d3dy5leGFtcGxl LmNvbS9hbm90aGVybW9kdWxlIj4NCiZxdW90O2h0dHA6Ly93d3cuZXhhbXBsZS5jb20vYW5vdGhl cm1vZHVsZSZxdW90OzwvYT47PGJyPg0KJm5ic3A7ICZuYnNwOyBwcmVmaXggYW07PGJyPg0KJm5i c3A7ICZuYnNwOyBjb250YWluZXIgdG9wIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbGVhZiB0eXBlIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdHlwZSBzdHJpbmc7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG1hbmRhdG9yeSB0cnVlOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB9IDxicj4NCiZuYnNwOyB9PGJyPg0KfTxicj4NCm1vZHVsZSBtb2R1bGUtYiB7PGJy Pg0KJm5ic3A7IHlhbmctdmVyc2lvbiAxLjE7PGJyPg0KJm5ic3A7Jm5ic3A7ICZuYnNwO25hbWVz cGFjZSA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJodHRwOi8vd3d3LmV4 YW1wbGUuY29tL21vZHVsZS1iIj4NCiZxdW90O2h0dHA6Ly93d3cuZXhhbXBsZS5jb20vbW9kdWxl LWImcXVvdDs8L2E+Ozxicj4NCiZuYnNwOyZuYnNwOyBwcmVmaXggbW07PGJyPg0KJm5ic3A7Jm5i c3A7IGluY2x1ZGUgc3ViLW1vZHVsZS0xOzxicj4NCiZuYnNwOyZuYnNwOyBpbmNsdWRlIHN1Yi1t b2R1bGUtMjs8YnI+DQp9PGJyPg0Kc3VibW9kdWxlIHN1Yi1tb2R1bGUtMSB7PGJyPg0KJm5ic3A7 Jm5ic3A7IHlhbmctdmVyc2lvbiAxLjE7PGJyPg0KJm5ic3A7Jm5ic3A7IGJlbG9uZ3MtdG8gbW9k dWxlLWIgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBwcmVmaXggbW07PGJyPg0KJm5ic3A7IH08 YnI+DQombmJzcDsmbmJzcDsgJm5ic3A7aW1wb3J0IG1vZHVsZS1hIHs8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgcHJlZml4IGFtOzxicj4NCiZuYnNwOyB9PGJyPg0KJm5ic3A7IGF1Z21lbnQgJy9h bTp0b3AnIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgd2hlbiAmcXVvdDthbTp0eXBlID0gJ3Rl c3QnJnF1b3Q7Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBjb250YWluZXIgZmlyc3QtYXVnbWVu dCB7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPg0KJm5i c3A7IH08YnI+DQp9PGJyPg0Kc3VibW9kdWxlIHN1Yi1tb2R1bGUtMiB7PGJyPg0KJm5ic3A7IHlh bmctdmVyc2lvbiAxLjE7PGJyPg0KJm5ic3A7IGJlbG9uZ3MtdG8gbW9kdWxlLWIgezxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyBwcmVmaXggbW07PGJyPg0KJm5ic3A7IH0mbmJzcDsmbmJzcDsmbmJz cDsgPGJyPg0KJm5ic3A7Jm5ic3A7ICZuYnNwO2ltcG9ydCBtb2R1bGUtYSB7PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IHByZWZpeCBhbTs8YnI+DQombmJzcDsgfTxicj4NCiZuYnNwOyBpbmNsdWRl IHN1Yi1tb2R1bGUtMTs8YnI+DQombmJzcDsgZ3JvdXBpbmcgZHVtbXlncm91cGluZyB7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIG1hbmRhdG9yeS1sZWFm IHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJpbmc7PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmRhdG9yeSB0cnVlOzxicj4NCiZuYnNw OyZuYnNwOyAmbmJzcDsgfTxicj4NCiZuYnNwOyB9PGJyPg0KJm5ic3A7IGF1Z21lbnQgJy9hbTp0 b3AvbW06Zmlyc3QtYXVnbWVudCcgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyB1c2VzIGR1bW15 Z3JvdXBpbmc7PGJyPg0KJm5ic3A7IH08YnI+DQp9DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6b988ca076346a57e9846553f8f706b7nokiacom_-- From nobody Fri Feb 15 02:08: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 1EB89130F9F for ; Fri, 15 Feb 2019 02:08:28 -0800 (PST) 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 FEj2EdZyrla3 for ; Fri, 15 Feb 2019 02:08:25 -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 708F2130F8E for ; Fri, 15 Feb 2019 02:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11545; q=dns/txt; s=iport; t=1550225304; x=1551434904; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=U04mDLg9AF1rZQU+BoeoZ+5TiWQLXl8yGlBo5ZjYb0M=; b=FvPEYLX8Tcs/whCYtGZnDHQ0LMsAP9DRkC7A9Msf/V2Er3va4TwNpt/S suPPOUqRQxFpUAikBWQC3MtKlH9/2s/Qb8TuQl+UnFVAygWjqA7o/IjfE QxNQt8BbsOm0ma8hUxUBoMwB/RrKsx9pxyskB+3E2cBjjkYnbEi5F9ize E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAAOj2Zc/xbLJq0ZAUoZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFTAgEBAQEBCwEBgmhQASASJ4QGiHmMay2SJ4VwgXs?= =?us-ascii?q?NGAEKhANGAoQKNgcNAQMBAQIBAQJtHAyFSwEBAQMBASFIAxsJAhgqAgInMAY?= =?us-ascii?q?BDAYCAQGDHAGBcg+MOYJpm2GBLx+FJYRtjFuBQD+BOII2By6DEwsBAQIBgT4?= =?us-ascii?q?BAQ6DGYJXAol9iCWRFAmHPIsTBhmKXIgdgyeHGYVGgzaBeYcogU0NJIE/Dwg?= =?us-ascii?q?zGggbFTuCbAmCSYM4hRSFPz8DMAGNe4I+AQE?= X-IronPort-AV: E=Sophos; i="5.58,372,1544486400"; d="scan'208,217"; a="10115716" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2019 10:08:21 +0000 Received: from [10.63.23.84] (dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com [10.63.23.84]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x1FA8LCI008472; Fri, 15 Feb 2019 10:08:21 GMT To: "Beauville, Yves (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <6b988ca0-7634-6a57-e984-6553f8f706b7@nokia.com> From: Robert Wilton Message-ID: Date: Fri, 15 Feb 2019 10:08:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <6b988ca0-7634-6a57-e984-6553f8f706b7@nokia.com> Content-Type: multipart/alternative; boundary="------------31FFA7F6A0273F5D9091A6EA" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.84, dhcp-ensft1-uk-vla370-10-63-23-84.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] Augmentation with a mandatory leaf in a submodule - Is the following legal? 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 Feb 2019 10:08:28 -0000 This is a multi-part message in MIME format. --------------31FFA7F6A0273F5D9091A6EA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yves, My interpretation of the spirit of the RFC is that this should be allowed, and I don't think that any text in 7.17 specifically prevents this. However, this seems like a corner case, and I am also not surprised that a YANG compiler would fail on this.  This issue could perhaps be easily mitigated by making the second augmentation also conditional on the same when statement. Note that the use of sub-modules doesn't really matter, in that a compiler can treat them as one module.  So, I think that the problem is equivalent to: module module-a {   yang-version 1.1;   namespace "http://www.example.com/anothermodule";   prefix am;   container top {     leaf type {       type string;       mandatory true;     }   } } module module-b {   yang-version 1.1;   namespace "http://www.example.com/module-b";   prefix mm;   augment '/am:top' {     when "am:type = 'test'";     container first-augment {     }   augment '/am:top/mm:first-augment' {     leaf mandatory-leaf {       type string;       mandatory true;      }   } } Thanks, Rob On 15/02/2019 09:12, Beauville, Yves (Nokia - BE/Antwerp) wrote: > Hi, > > We are working with a submodule in which we are augmenting a container > of the same module with a mandatory node. There is a small catch though. > > Our YANG modules are actually supporting two augmentations - I have > copied a trimmed down version of our modules at the end of this mail -: > > * From container 'top' in 'module-a' to container 'first-augment' in > 'module-b' (sub-module-1) => This augmentation is made conditional > with a 'when' statement. > > * From container 'first-augment' to leaf 'mandatory-leaf'. This is > done within two submodules of the same module 'module-b' => This > augmentation is NOT conditional. > > The Open Daylight parser rejects our YANG modules with the following > error: > >    Failed to add augmentation sub-module-1b.yang defined at > sub-module-2b.yang > org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException: An > augment cannot add node 'mandatory-leaf' because it is mandatory and > in module different than target [at sub-module-2b.yang] > > As per https://tools.ietf.org/html/rfc7950#section-7.17 > , we believe these > augmentations are both legal'. > > We have raised a ticket YANGTOOLS-956 at Open Daylight but folks at > ODL are asking us to check with experts in this mailing list. > > Can one assess if these models are making a 'legal' use of > augmentations or not? > > Yves > > ================================ > > module module-a { >   yang-version 1.1; >     namespace "http://www.example.com/anothermodule"; >     prefix am; >     container top { >       leaf type { >         type string; >         mandatory true; >       } >   } > } > module module-b { >   yang-version 1.1; >     namespace "http://www.example.com/module-b"; >    prefix mm; >    include sub-module-1; >    include sub-module-2; > } > submodule sub-module-1 { >    yang-version 1.1; >    belongs-to module-b { >     prefix mm; >   } >     import module-a { >     prefix am; >   } >   augment '/am:top' { >     when "am:type = 'test'"; >     container first-augment { >     } >   } > } > submodule sub-module-2 { >   yang-version 1.1; >   belongs-to module-b { >     prefix mm; >   } >     import module-a { >     prefix am; >   } >   include sub-module-1; >   grouping dummygrouping { >     leaf mandatory-leaf { >       type string; >       mandatory true; >      } >   } >   augment '/am:top/mm:first-augment' { >     uses dummygrouping; >   } > } > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------31FFA7F6A0273F5D9091A6EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Yves,

My interpretation of the spirit of the RFC is that this should be allowed, and I don't think that any text in 7.17 specifically prevents this.

However, this seems like a corner case, and I am also not surprised that a YANG compiler would fail on this.  This issue could perhaps be easily mitigated by making the second augmentation also conditional on the same when statement.

Note that the use of sub-modules doesn't really matter, in that a compiler can treat them as one module.  So, I think that the problem is equivalent to:

module module-a {
   yang-version 1.1;
   namespace "http://www.example.com/anothermodule";
   prefix am;

   container top {
     leaf type {
       type string;
      mandatory true;
     }
  }
 }

module module-b {
   yang-version 1.1;
   namespace "http://www.example.com/module-b";
   prefix mm;

  augment '/am:top' {
     when "am:type = 'test'";
     container first-augment {   
    }

   augment '/am:top/mm:first-augment' {
    leaf mandatory-leaf {
       type string;
       mandatory true;
      }
   }
 }

Thanks,
Rob


On 15/02/2019 09:12, Beauville, Yves (Nokia - BE/Antwerp) wrote:
Hi,

We are working with a submodule in which we are augmenting a container of the same module with a mandatory node. There is a small catch though.

Our YANG modules are actually supporting two augmentations - I have copied a trimmed down version of our modules at the end of this mail -:

* From container 'top' in 'module-a' to container 'first-augment' in 'module-b' (sub-module-1) => This augmentation is made conditional with a 'when' statement.

* From container 'first-augment' to leaf 'mandatory-leaf'. This is done within two submodules of the same module 'module-b' => This augmentation is NOT conditional.

The Open Daylight parser rejects our YANG modules with the following error:

   Failed to add augmentation sub-module-1b.yang defined at sub-module-2b.yang org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException: An augment cannot add node 'mandatory-leaf' because it is mandatory and in module different than target [at sub-module-2b.yang]

As per https://tools.ietf.org/html/rfc7950#section-7.17, we believe these augmentations are both legal'.

We have raised a ticket YANGTOOLS-956 at Open Daylight but folks at ODL are asking us to check with experts in this mailing list.

Can one assess if these models are making a 'legal' use of augmentations or not?

Yves

================================

module module-a {
  yang-version 1.1;
    namespace "http://www.example.com/anothermodule";
    prefix am;
    container top {
      leaf type {
        type string;
        mandatory true;
      }
  }
}
module module-b {
  yang-version 1.1;
    namespace "http://www.example.com/module-b";
   prefix mm;
   include sub-module-1;
   include sub-module-2;
}
submodule sub-module-1 {
   yang-version 1.1;
   belongs-to module-b {
    prefix mm;
  }
    import module-a {
    prefix am;
  }
  augment '/am:top' {
    when "am:type = 'test'";
    container first-augment {   
    }
  }
}
submodule sub-module-2 {
  yang-version 1.1;
  belongs-to module-b {
    prefix mm;
  }   
    import module-a {
    prefix am;
  }
  include sub-module-1;
  grouping dummygrouping {   
    leaf mandatory-leaf {
      type string;
      mandatory true;
     }
  }
  augment '/am:top/mm:first-augment' {
    uses dummygrouping;
  }
} 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--------------31FFA7F6A0273F5D9091A6EA-- From nobody Fri Feb 15 03:51: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 3548F130DC9 for ; Fri, 15 Feb 2019 03:51: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, 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 0Udqjg071I0k for ; Fri, 15 Feb 2019 03:51:41 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50092.outbound.protection.outlook.com [40.107.5.92]) (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 2AEC6130FB1 for ; Fri, 15 Feb 2019 03:51:41 -0800 (PST) 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=XgpcWOVFFEac1qrzd3F5jQwBn3bquuzBF6JPlXtgxaM=; b=Z+oP/jboEaMgEKGNdAI7BbT/1Bssaww/Cx6y1HX81O+o7YyaQOecVajxippYJ2bLc+/wxLDIFf7J3sNiwcalRgVOacii82YcG1UeWdGeJpPg736pg1PTRraI1xi0nspys9NaA6RfB1okCGjzGn8fMHdqq6idCitGwFqFlk8OeEY= Received: from VI1PR07MB5792.eurprd07.prod.outlook.com (20.178.121.222) by VI1PR07MB4845.eurprd07.prod.outlook.com (20.177.63.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.8; Fri, 15 Feb 2019 11:51:38 +0000 Received: from VI1PR07MB5792.eurprd07.prod.outlook.com ([fe80::b1cf:d9b9:6654:e6bf]) by VI1PR07MB5792.eurprd07.prod.outlook.com ([fe80::b1cf:d9b9:6654:e6bf%4]) with mapi id 15.20.1643.008; Fri, 15 Feb 2019 11:51:38 +0000 From: "Beauville, Yves (Nokia - BE/Antwerp)" To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] Augmentation with a mandatory leaf in a submodule - Is the following legal? Thread-Index: AQHUxQ6Rb/ufk4ALnEO3ok4pna4OcaXgoqMAgAAc2YA= Date: Fri, 15 Feb 2019 11:51:38 +0000 Message-ID: <4d8d77d8-f576-c4e1-754e-04ad4eaf09f8@nokia.com> References: <6b988ca0-7634-6a57-e984-6553f8f706b7@nokia.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.32.166] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 x-clientproxiedby: LNXP123CA0002.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::14) To VI1PR07MB5792.eurprd07.prod.outlook.com (2603:10a6:803:cf::30) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yves.beauville@nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f6d8953-d62a-46aa-d09f-08d6933bf152 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7193020); SRVR:VI1PR07MB4845; x-ms-traffictypediagnostic: VI1PR07MB4845: x-ms-exchange-purlcount: 4 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUI0ODQ1OzIzOmo2d000S1A5a2lxK0xBbUFoTThQR1pxNkpM?= =?utf-8?B?ODNPUXc5di9kdE9oMEYxc2gwYmVtZUlQRzR1TzNzVjBuZkRLVlpURWpTVHh6?= =?utf-8?B?RTVZUTZqNjkraEpqRzNPVlBFU09VUWw3bDc0TGdDR0JHVm12VVB1bUE2NGtO?= =?utf-8?B?eDlJUGZDaWppMzBpa0tMdjZkNi8zeDFQU1I2eis3L29wUFNNUm80ZGxiMnYy?= =?utf-8?B?TEUyakNJMytXcGpGVzRZSzJCSTRIditRUnBaVGlOUVNQUFR1UnY5N09oeTBL?= =?utf-8?B?dUF3YkpuOVUrYVhnSXZGV0lRdStKNVkvVmsvaVRiSWFlaFJpYW04ZTh4UExl?= =?utf-8?B?bEpzdTBqbzVWZnQ4Rjl0Z0FRQWp1RU9XcEVJdGkwNlJVMGUzY1hOeitWZ0M3?= =?utf-8?B?bzZqWVRjVkx0OXVwZUFNbWcrVTVoSWQ5alUyMFJGQ2pVelAyeUUrcGI0cUhN?= =?utf-8?B?aENyWVJuUmszMmhlbkFSbHRwOS9peEdtSGRzZDN3eFVSLzVaRWFlQjQ1N1Fl?= =?utf-8?B?MDVMSFhJZTBkT0lsdnRlaUJYeTByTEE2cVZhWUwyRFZ3NENGWFVzUURRdU83?= =?utf-8?B?RFUvd3VRZEpESTBaL3RndU1kbW9mK2o0RG9xQ2tJbjVTcUpFb3kwb2JDTm1a?= =?utf-8?B?ejdGR3hXcTlJaGNsUG9HS1lYQk5OVGdFcnUyTUFTcER4cm0yOWdrNkNTbmpl?= =?utf-8?B?SVFtWUZYQ3lHdk91Q2ZYZ0hKSklvWDJUMm1qMUtCWjRoRWRlK2xRTzlnMlc5?= =?utf-8?B?YmUwdmpHY1V4ZXBXN24xdWcrOXhDSUZQbTYzZVNGaDY0TElSQ3hTdnBWSkVW?= =?utf-8?B?RjVoRCt4dE9QdHlvTlQ1R3plYWhxaUtDSDhpNFh3eWJTdFZyWkIvNm1TRlAy?= =?utf-8?B?YmF2b056NjlPTVc0NjY2S0RoNDYzN2ZSRldVdGhxQVlEaHZQbUNrUEtacVNt?= =?utf-8?B?TnU1SkpTMEpCY1hFcHY5VUVHNlF1UmV1Z1c4dTZkWmxHaTY3Z0tMd3VNU0pk?= =?utf-8?B?Qnl3RnBkdkNLS01jZXlIMnE5Yk85YjgxVjZpWExsNXVlNEFXY2VBeGxjSHRl?= =?utf-8?B?aExKOFVWWVdXREhyMHR5VzFldEVlUUFaQVRPNStQS3FCRWZ2dExLMDc0aGkr?= =?utf-8?B?UUlzMStERzIyaWR5cmUzZklYMHc2L2UyUzJYWmFnd0FPUDVIdlJtVXJrM2da?= =?utf-8?B?eXdRdW1YYTdzdUlKRGNTcEs4eHovb0NYdUEzZXI0bXpCcWhZTHFxRkJMZW1Z?= =?utf-8?B?RFFCMDBnc3pwRXZQcU5zb1hrR0VnWDMzVEs2dEd0YU1uTUpvd25zZGgxZUpL?= =?utf-8?B?bXFxdDgzdjR3V2NsQ0J5VEcyZW1OQVJaWlp4T3FlOW43dmhBVGQzczd5eVlL?= =?utf-8?B?cXhKMzRUK2k2QkhHVmU3bnFiWkhjMDB4NTVuZHhwSUVZeHpRMm0waGttNVEw?= =?utf-8?B?aE1XYmhCRGtOVGlBZDNraDQwVXZuYS9JWWJqS2k1KzFNeC90S1VPMjJXbjNy?= =?utf-8?B?dG00WkpXaVRFLzV4MDdKTENvVGR1K0k3NlV0c0M2VnYzaVpycTBzVjBtWGh5?= =?utf-8?B?TERsL1hWUEVXOHg4WUN3aWtHWHFIQVRzZ3cxS1VUWFZCdnJNRE0vV3hoeU5n?= =?utf-8?B?R0dYdy9UOURBMnlUM3R1d1J3cWZpOU9Ta2VuNlhrMm9JUU1rSk5CVVJBSlE3?= =?utf-8?B?SGNvcVlLSDlQcE9sc2RxV2JQa1hHajByaGFNbnh6NkJJTkRyL2dQc2g3ZHNj?= =?utf-8?B?OXNhNkNRWjN3Y1JYQTlybkVXTXQrVW44ZVIvQVNCOWkzUitHVk1CYXU3bmNW?= =?utf-8?B?dUQ4TGlKUTR2eGIzMGpNOGJXaTF5MjZha3Z6dllISDZyRzRqeHM4bFo4WWVi?= =?utf-8?B?eU8xcHlVNGRNNStJcmRyNGZhMjNKZCtCZWNDZkMwU0VmWUJRc0xYUlptT1lT?= =?utf-8?Q?2zxzGfpFc6qb/LAPqZnRhEvkjIFU00=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09497C15EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(396003)(366004)(346002)(189003)(51444003)(199004)(476003)(26005)(14454004)(53936002)(31686004)(186003)(52116002)(256004)(14444005)(65806001)(86362001)(3846002)(11346002)(8936002)(966005)(53546011)(606006)(25786009)(2616005)(106356001)(6506007)(81156014)(105586002)(446003)(8676002)(81166006)(6116002)(2906002)(58126008)(386003)(486006)(71200400001)(110136005)(71190400001)(102836004)(31696002)(66066001)(65956001)(7736002)(97736004)(68736007)(65826007)(76176011)(229853002)(316002)(6246003)(6486002)(6436002)(99286004)(6306002)(54896002)(36756003)(64126003)(6512007)(478600001)(236005)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4845; H:VI1PR07MB5792.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: q7mjY+9len1IQaQ1tDSnDzYHuDM/hVQ6xqESeSA7gcyVtp210lxJPBGBYvTtA0tUMNQkE+QXFvJjkZQhcVDJLJrxI5AgmlS7VOcUVvhewmAzKDSA13YyZrVZP6XP3/Tc0YpTiuAhBOqtqxu5kF+8HB5KIVL7TWjGA4aqZ0Zm1QXwIc0zOWJ/DrOSCMhTMtjLkER3e3bAdTDUZQTI/1XiucUavMVxyjburRGK3+2jgueNCSc8JEzdAp2j9Et11O5PWKdA2/+SKaCGvXhIPd+vll/3hcmppwUBClGJF3pFuELnVaHw6xVDtTvkhVUML+YQJ1pV9Xnma7CJWX/faLKmPC0GGkj2mPzucUR0gN0sdWZ82qT5yQwThcPEo9/wsA35Gx0RQo1sLRVnlj8L0FAk2gRrNqXsMokZOJU10N+H/KA= Content-Type: multipart/alternative; boundary="_000_4d8d77d8f576c4e1754e04ad4eaf09f8nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f6d8953-d62a-46aa-d09f-08d6933bf152 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 11:51:37.6591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4845 Archived-At: Subject: Re: [netmod] Augmentation with a mandatory leaf in a submodule - Is the following legal? 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 Feb 2019 11:51:49 -0000 --_000_4d8d77d8f576c4e1754e04ad4eaf09f8nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGZhc3QgcmVwbHksIGZvciBw cm9wb3NpbmcgYSBtaXRpZ2F0aW9uLCBhbmQgZm9yICdyZWR1Y2luZycgb3VyIHNldCBvZiBZQU5H IG1vZHVsZXMgdG8gcGluLXBvaW50IHRoZSBjYXVzZSBvZiB0aGUgaXNzdWUuDQoNCkkgYW0gYWxp Z25lZCB3aXRoIHlvdS4gSXQgaXMgaW5kZWVkIGEgY29ybmVyIGNhc2UuIFdlIHdpbGwgZm9yd2Fy ZCB5b3VyIGZlZWRiYWNrIHRvIE9wZW5EYXlsaWdodCBhcyB3ZWxsLg0KDQpUaGFuayB5b3UsDQoN Cll2ZXMNCg0KT24gMTUtMDItMTkgMTE6MDgsIFJvYmVydCBXaWx0b24gd3JvdGU6DQoNCkhpIFl2 ZXMsDQoNCk15IGludGVycHJldGF0aW9uIG9mIHRoZSBzcGlyaXQgb2YgdGhlIFJGQyBpcyB0aGF0 IHRoaXMgc2hvdWxkIGJlIGFsbG93ZWQsIGFuZCBJIGRvbid0IHRoaW5rIHRoYXQgYW55IHRleHQg aW4gNy4xNyBzcGVjaWZpY2FsbHkgcHJldmVudHMgdGhpcy4NCg0KSG93ZXZlciwgdGhpcyBzZWVt cyBsaWtlIGEgY29ybmVyIGNhc2UsIGFuZCBJIGFtIGFsc28gbm90IHN1cnByaXNlZCB0aGF0IGEg WUFORyBjb21waWxlciB3b3VsZCBmYWlsIG9uIHRoaXMuICBUaGlzIGlzc3VlIGNvdWxkIHBlcmhh cHMgYmUgZWFzaWx5IG1pdGlnYXRlZCBieSBtYWtpbmcgdGhlIHNlY29uZCBhdWdtZW50YXRpb24g YWxzbyBjb25kaXRpb25hbCBvbiB0aGUgc2FtZSB3aGVuIHN0YXRlbWVudC4NCg0KTm90ZSB0aGF0 IHRoZSB1c2Ugb2Ygc3ViLW1vZHVsZXMgZG9lc24ndCByZWFsbHkgbWF0dGVyLCBpbiB0aGF0IGEg Y29tcGlsZXIgY2FuIHRyZWF0IHRoZW0gYXMgb25lIG1vZHVsZS4gIFNvLCBJIHRoaW5rIHRoYXQg dGhlIHByb2JsZW0gaXMgZXF1aXZhbGVudCB0bzoNCg0KbW9kdWxlIG1vZHVsZS1hIHsNCiAgeWFu Zy12ZXJzaW9uIDEuMTsNCiAgbmFtZXNwYWNlICJodHRwOi8vd3d3LmV4YW1wbGUuY29tL2Fub3Ro ZXJtb2R1bGUiPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYW5vdGhlcm1vZHVsZT47DQogIHByZWZp eCBhbTsNCg0KICBjb250YWluZXIgdG9wIHsNCiAgICBsZWFmIHR5cGUgew0KICAgICAgdHlwZSBz dHJpbmc7DQogICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICB9DQogIH0NCn0NCg0KbW9kdWxlIG1v ZHVsZS1iIHsNCiAgeWFuZy12ZXJzaW9uIDEuMTsNCiAgbmFtZXNwYWNlICJodHRwOi8vd3d3LmV4 YW1wbGUuY29tL21vZHVsZS1iIjxodHRwOi8vd3d3LmV4YW1wbGUuY29tL21vZHVsZS1iPjsNCiAg cHJlZml4IG1tOw0KDQogIGF1Z21lbnQgJy9hbTp0b3AnIHsNCiAgICB3aGVuICJhbTp0eXBlID0g J3Rlc3QnIjsNCiAgICBjb250YWluZXIgZmlyc3QtYXVnbWVudCB7DQogICAgfQ0KDQogIGF1Z21l bnQgJy9hbTp0b3AvbW06Zmlyc3QtYXVnbWVudCcgew0KICAgIGxlYWYgbWFuZGF0b3J5LWxlYWYg ew0KICAgICAgdHlwZSBzdHJpbmc7DQogICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICAgfQ0KICB9 DQp9DQoNClRoYW5rcywNClJvYg0KDQoNCk9uIDE1LzAyLzIwMTkgMDk6MTIsIEJlYXV2aWxsZSwg WXZlcyAoTm9raWEgLSBCRS9BbnR3ZXJwKSB3cm90ZToNCkhpLA0KDQpXZSBhcmUgd29ya2luZyB3 aXRoIGEgc3VibW9kdWxlIGluIHdoaWNoIHdlIGFyZSBhdWdtZW50aW5nIGEgY29udGFpbmVyIG9m IHRoZSBzYW1lIG1vZHVsZSB3aXRoIGEgbWFuZGF0b3J5IG5vZGUuIFRoZXJlIGlzIGEgc21hbGwg Y2F0Y2ggdGhvdWdoLg0KDQpPdXIgWUFORyBtb2R1bGVzIGFyZSBhY3R1YWxseSBzdXBwb3J0aW5n IHR3byBhdWdtZW50YXRpb25zIC0gSSBoYXZlIGNvcGllZCBhIHRyaW1tZWQgZG93biB2ZXJzaW9u IG9mIG91ciBtb2R1bGVzIGF0IHRoZSBlbmQgb2YgdGhpcyBtYWlsIC06DQoNCiogRnJvbSBjb250 YWluZXIgJ3RvcCcgaW4gJ21vZHVsZS1hJyB0byBjb250YWluZXIgJ2ZpcnN0LWF1Z21lbnQnIGlu ICdtb2R1bGUtYicgKHN1Yi1tb2R1bGUtMSkgPT4gVGhpcyBhdWdtZW50YXRpb24gaXMgbWFkZSBj b25kaXRpb25hbCB3aXRoIGEgJ3doZW4nIHN0YXRlbWVudC4NCg0KKiBGcm9tIGNvbnRhaW5lciAn Zmlyc3QtYXVnbWVudCcgdG8gbGVhZiAnbWFuZGF0b3J5LWxlYWYnLiBUaGlzIGlzIGRvbmUgd2l0 aGluIHR3byBzdWJtb2R1bGVzIG9mIHRoZSBzYW1lIG1vZHVsZSAnbW9kdWxlLWInID0+IFRoaXMg YXVnbWVudGF0aW9uIGlzIE5PVCBjb25kaXRpb25hbC4NCg0KVGhlIE9wZW4gRGF5bGlnaHQgcGFy c2VyIHJlamVjdHMgb3VyIFlBTkcgbW9kdWxlcyB3aXRoIHRoZSBmb2xsb3dpbmcgZXJyb3I6DQoN CiAgIEZhaWxlZCB0byBhZGQgYXVnbWVudGF0aW9uIHN1Yi1tb2R1bGUtMWIueWFuZyBkZWZpbmVk IGF0IHN1Yi1tb2R1bGUtMmIueWFuZyBvcmcub3BlbmRheWxpZ2h0Lnlhbmd0b29scy55YW5nLnBh cnNlci5zcGkubWV0YS5JbmZlcmVuY2VFeGNlcHRpb246IEFuIGF1Z21lbnQgY2Fubm90IGFkZCBu b2RlICdtYW5kYXRvcnktbGVhZicgYmVjYXVzZSBpdCBpcyBtYW5kYXRvcnkgYW5kIGluIG1vZHVs ZSBkaWZmZXJlbnQgdGhhbiB0YXJnZXQgW2F0IHN1Yi1tb2R1bGUtMmIueWFuZ10NCg0KQXMgcGVy IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNy4xNywgd2UgYmVs aWV2ZSB0aGVzZSBhdWdtZW50YXRpb25zIGFyZSBib3RoIGxlZ2FsJy4NCg0KV2UgaGF2ZSByYWlz ZWQgYSB0aWNrZXQgWUFOR1RPT0xTLTk1NiBhdCBPcGVuIERheWxpZ2h0IGJ1dCBmb2xrcyBhdCBP REwgYXJlIGFza2luZyB1cyB0byBjaGVjayB3aXRoIGV4cGVydHMgaW4gdGhpcyBtYWlsaW5nIGxp c3QuDQoNCkNhbiBvbmUgYXNzZXNzIGlmIHRoZXNlIG1vZGVscyBhcmUgbWFraW5nIGEgJ2xlZ2Fs JyB1c2Ugb2YgYXVnbWVudGF0aW9ucyBvciBub3Q/DQoNCll2ZXMNCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KbW9kdWxlIG1vZHVsZS1hIHsNCiAgeWFuZy12ZXJzaW9uIDEu MTsNCiAgICBuYW1lc3BhY2UgImh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYW5vdGhlcm1vZHVsZSI8 aHR0cDovL3d3dy5leGFtcGxlLmNvbS9hbm90aGVybW9kdWxlPjsNCiAgICBwcmVmaXggYW07DQog ICAgY29udGFpbmVyIHRvcCB7DQogICAgICBsZWFmIHR5cGUgew0KICAgICAgICB0eXBlIHN0cmlu ZzsNCiAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICB9DQogIH0NCn0NCm1vZHVsZSBtb2R1 bGUtYiB7DQogIHlhbmctdmVyc2lvbiAxLjE7DQogICAgbmFtZXNwYWNlICJodHRwOi8vd3d3LmV4 YW1wbGUuY29tL21vZHVsZS1iIjxodHRwOi8vd3d3LmV4YW1wbGUuY29tL21vZHVsZS1iPjsNCiAg IHByZWZpeCBtbTsNCiAgIGluY2x1ZGUgc3ViLW1vZHVsZS0xOw0KICAgaW5jbHVkZSBzdWItbW9k dWxlLTI7DQp9DQpzdWJtb2R1bGUgc3ViLW1vZHVsZS0xIHsNCiAgIHlhbmctdmVyc2lvbiAxLjE7 DQogICBiZWxvbmdzLXRvIG1vZHVsZS1iIHsNCiAgICBwcmVmaXggbW07DQogIH0NCiAgICBpbXBv cnQgbW9kdWxlLWEgew0KICAgIHByZWZpeCBhbTsNCiAgfQ0KICBhdWdtZW50ICcvYW06dG9wJyB7 DQogICAgd2hlbiAiYW06dHlwZSA9ICd0ZXN0JyI7DQogICAgY29udGFpbmVyIGZpcnN0LWF1Z21l bnQgew0KICAgIH0NCiAgfQ0KfQ0Kc3VibW9kdWxlIHN1Yi1tb2R1bGUtMiB7DQogIHlhbmctdmVy c2lvbiAxLjE7DQogIGJlbG9uZ3MtdG8gbW9kdWxlLWIgew0KICAgIHByZWZpeCBtbTsNCiAgfQ0K ICAgIGltcG9ydCBtb2R1bGUtYSB7DQogICAgcHJlZml4IGFtOw0KICB9DQogIGluY2x1ZGUgc3Vi LW1vZHVsZS0xOw0KICBncm91cGluZyBkdW1teWdyb3VwaW5nIHsNCiAgICBsZWFmIG1hbmRhdG9y eS1sZWFmIHsNCiAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAg IH0NCiAgfQ0KICBhdWdtZW50ICcvYW06dG9wL21tOmZpcnN0LWF1Z21lbnQnIHsNCiAgICB1c2Vz IGR1bW15Z3JvdXBpbmc7DQogIH0NCn0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KDQo= --_000_4d8d77d8f576c4e1754e04ad4eaf09f8nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5ECDA938AF8E384C9157B841F0FC959B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHRleHQ9IiMwMDAwMDAi IGJnY29sb3I9IiNGRkZGRkYiPg0KPHA+SGkgUm9iLDwvcD4NCjxwPlRoYW5rIHlvdSB2ZXJ5IG11 Y2ggZm9yIHlvdXIgZmFzdCByZXBseSwgZm9yIHByb3Bvc2luZyBhIG1pdGlnYXRpb24sIGFuZCBm b3IgJ3JlZHVjaW5nJyBvdXIgc2V0IG9mIFlBTkcgbW9kdWxlcyB0byBwaW4tcG9pbnQgdGhlIGNh dXNlIG9mIHRoZSBpc3N1ZS48L3A+DQo8cD5JIGFtIGFsaWduZWQgd2l0aCB5b3UuIEl0IGlzIGlu ZGVlZCBhIGNvcm5lciBjYXNlLiBXZSB3aWxsIGZvcndhcmQgeW91ciBmZWVkYmFjayB0byBPcGVu RGF5bGlnaHQgYXMgd2VsbC48YnI+DQo8L3A+DQo8cD5UaGFuayB5b3UsPC9wPg0KPHA+WXZlczxi cj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMTUtMDItMTkgMTE6MDgs IFJvYmVydCBXaWx0b24gd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjaXRlPSJtaWQ6Yjk3YTVmODktYjU0Ny0yMDNjLWQwM2YtYmE2OGY4MzcwOGU1QGNpc2NvLmNv bSI+DQo8cD5IaSBZdmVzLDwvcD4NCjxwPk15IGludGVycHJldGF0aW9uIG9mIHRoZSBzcGlyaXQg b2YgdGhlIFJGQyBpcyB0aGF0IHRoaXMgc2hvdWxkIGJlIGFsbG93ZWQsIGFuZCBJIGRvbid0IHRo aW5rIHRoYXQgYW55IHRleHQgaW4gNy4xNyBzcGVjaWZpY2FsbHkgcHJldmVudHMgdGhpcy48L3A+ DQo8cD5Ib3dldmVyLCB0aGlzIHNlZW1zIGxpa2UgYSBjb3JuZXIgY2FzZSwgYW5kIEkgYW0gYWxz byBub3Qgc3VycHJpc2VkIHRoYXQgYSBZQU5HIGNvbXBpbGVyIHdvdWxkIGZhaWwgb24gdGhpcy4m bmJzcDsgVGhpcyBpc3N1ZSBjb3VsZCBwZXJoYXBzIGJlIGVhc2lseSBtaXRpZ2F0ZWQgYnkgbWFr aW5nIHRoZSBzZWNvbmQgYXVnbWVudGF0aW9uIGFsc28gY29uZGl0aW9uYWwgb24gdGhlIHNhbWUg d2hlbiBzdGF0ZW1lbnQuPGJyPg0KPC9wPg0KPHA+Tm90ZSB0aGF0IHRoZSB1c2Ugb2Ygc3ViLW1v ZHVsZXMgZG9lc24ndCByZWFsbHkgbWF0dGVyLCBpbiB0aGF0IGEgY29tcGlsZXIgY2FuIHRyZWF0 IHRoZW0gYXMgb25lIG1vZHVsZS4mbmJzcDsgU28sIEkgdGhpbmsgdGhhdCB0aGUgcHJvYmxlbSBp cyBlcXVpdmFsZW50IHRvOjxicj4NCjwvcD4NCjxwPjx0dD5tb2R1bGUgbW9kdWxlLWEgezwvdHQ+ PHR0Pjxicj4NCjwvdHQ+PHR0PiZuYnNwOyB5YW5nLXZlcnNpb24gMS4xOzwvdHQ+PHR0Pjxicj4N CjwvdHQ+PHR0PiZuYnNwOyBuYW1lc3BhY2UgPC90dD48dHQ+PGEgY2xhc3M9Im1vei10eHQtbGlu ay1yZmMyMzk2RSIgaHJlZj0iaHR0cDovL3d3dy5leGFtcGxlLmNvbS9hbm90aGVybW9kdWxlIiBt b3otZG8tbm90LXNlbmQ9InRydWUiPiZxdW90O2h0dHA6Ly93d3cuZXhhbXBsZS5jb20vYW5vdGhl cm1vZHVsZSZxdW90OzwvYT48L3R0Pjx0dD47PC90dD48dHQ+PGJyPg0KPC90dD48dHQ+Jm5ic3A7 IHByZWZpeCBhbTs8YnI+DQo8YnI+DQo8L3R0Pjx0dD4mbmJzcDsgY29udGFpbmVyIHRvcCB7PC90 dD48dHQ+PGJyPg0KPC90dD48dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgdHlwZSB7PC90dD48 dHQ+PGJyPg0KPC90dD48dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3Ry aW5nOzwvdHQ+PHR0Pjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5kYXRv cnkgdHJ1ZTs8L3R0Pjx0dD48YnI+DQo8L3R0Pjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgfSA8L3R0 Pjx0dD48YnI+DQo8L3R0Pjx0dD4mbmJzcDsgfTwvdHQ+PHR0Pjxicj4NCjwvdHQ+PHR0Pn08L3R0 PjwvcD4NCjxwPjx0dD5tb2R1bGUgbW9kdWxlLWIgezwvdHQ+PHR0Pjxicj4NCjwvdHQ+PHR0PiZu YnNwOyB5YW5nLXZlcnNpb24gMS4xOzwvdHQ+PHR0Pjxicj4NCjwvdHQ+PHR0PiZuYnNwOyBuYW1l c3BhY2UgPC90dD48dHQ+PGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0iaHR0 cDovL3d3dy5leGFtcGxlLmNvbS9tb2R1bGUtYiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj4mcXVv dDtodHRwOi8vd3d3LmV4YW1wbGUuY29tL21vZHVsZS1iJnF1b3Q7PC9hPjwvdHQ+PHR0Pjs8L3R0 Pjx0dD48YnI+DQo8L3R0Pjx0dD4mbmJzcDsgcHJlZml4IG1tOzx0dD48YnI+DQo8L3R0PjwvdHQ+ PC9wPg0KPHA+PHR0PiZuYnNwOyBhdWdtZW50ICcvYW06dG9wJyB7PC90dD48dHQ+PGJyPg0KPC90 dD48dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZW4gJnF1b3Q7YW06dHlwZSA9ICd0ZXN0JyZxdW90 Ozs8L3R0Pjx0dD48YnI+DQo8L3R0Pjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIGZp cnN0LWF1Z21lbnQgeyZuYnNwOyZuYnNwOyZuYnNwOyA8L3R0Pjx0dD48YnI+DQo8L3R0Pjx0dD4m bmJzcDsmbmJzcDsmbmJzcDsgfTwvdHQ+PHR0Pjxicj4NCjwvdHQ+PHR0Pjxicj4NCjwvdHQ+PHR0 PiZuYnNwOyBhdWdtZW50ICcvYW06dG9wL21tOmZpcnN0LWF1Z21lbnQnIHs8L3R0Pjx0dD48YnI+ DQo8L3R0Pjx0dD48dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgbWFuZGF0b3J5LWxlYWYgezwv dHQ+PHR0Pjxicj4NCjwvdHQ+PHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBl IHN0cmluZzs8L3R0Pjx0dD48YnI+DQo8L3R0Pjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbWFuZGF0b3J5IHRydWU7PC90dD48dHQ+PGJyPg0KPC90dD48dHQ+Jm5ic3A7Jm5ic3A7 ICZuYnNwOyB9PC90dD48L3R0Pjx0dD48YnI+DQo8L3R0Pjx0dD4mbmJzcDsgfTwvdHQ+PHR0Pjxi cj4NCjwvdHQ+PHR0Pn0gPC90dD48L3A+DQo8cD5UaGFua3MsPGJyPg0KUm9iPC9wPg0KPHA+PGJy Pg0KPC9wPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNS8wMi8yMDE5IDA5OjEy LCBCZWF1dmlsbGUsIFl2ZXMgKE5va2lhIC0gQkUvQW50d2VycCkgd3JvdGU6PGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6NmI5ODhjYTAtNzYzNC02YTU3LWU5 ODQtNjU1M2Y4ZjcwNmI3QG5va2lhLmNvbSI+DQpIaSw8YnI+DQo8cD5XZSBhcmUgd29ya2luZyB3 aXRoIGEgc3VibW9kdWxlIGluIHdoaWNoIHdlIGFyZSBhdWdtZW50aW5nIGEgY29udGFpbmVyIG9m IHRoZSBzYW1lIG1vZHVsZSB3aXRoIGEgbWFuZGF0b3J5IG5vZGUuIFRoZXJlIGlzIGEgc21hbGwg Y2F0Y2ggdGhvdWdoLjxicj4NCjwvcD4NCk91ciBZQU5HIG1vZHVsZXMgYXJlIGFjdHVhbGx5IHN1 cHBvcnRpbmcgdHdvIGF1Z21lbnRhdGlvbnMgLSBJIGhhdmUgY29waWVkIGEgdHJpbW1lZCBkb3du IHZlcnNpb24gb2Ygb3VyIG1vZHVsZXMgYXQgdGhlIGVuZCBvZiB0aGlzIG1haWwgLToNCjxwPiog RnJvbSBjb250YWluZXIgJ3RvcCcgaW4gJ21vZHVsZS1hJyB0byBjb250YWluZXIgJ2ZpcnN0LWF1 Z21lbnQnIGluICdtb2R1bGUtYicgKHN1Yi1tb2R1bGUtMSkgPSZndDsgVGhpcyBhdWdtZW50YXRp b24gaXMgbWFkZSBjb25kaXRpb25hbCB3aXRoIGEgJ3doZW4nIHN0YXRlbWVudC48L3A+DQo8cD4q IEZyb20gY29udGFpbmVyICdmaXJzdC1hdWdtZW50JyB0byBsZWFmICdtYW5kYXRvcnktbGVhZicu IFRoaXMgaXMgZG9uZSB3aXRoaW4gdHdvIHN1Ym1vZHVsZXMgb2YgdGhlIHNhbWUgbW9kdWxlICdt b2R1bGUtYicgPSZndDsgVGhpcyBhdWdtZW50YXRpb24gaXMgTk9UIGNvbmRpdGlvbmFsLjwvcD4N ClRoZSBPcGVuIERheWxpZ2h0IHBhcnNlciByZWplY3RzIG91ciBZQU5HIG1vZHVsZXMgd2l0aCB0 aGUgZm9sbG93aW5nIGVycm9yOg0KPHA+Jm5ic3A7Jm5ic3A7IEZhaWxlZCB0byBhZGQgYXVnbWVu dGF0aW9uIHN1Yi1tb2R1bGUtMWIueWFuZyBkZWZpbmVkIGF0IHN1Yi1tb2R1bGUtMmIueWFuZyBv cmcub3BlbmRheWxpZ2h0Lnlhbmd0b29scy55YW5nLnBhcnNlci5zcGkubWV0YS5JbmZlcmVuY2VF eGNlcHRpb246IEFuIGF1Z21lbnQgY2Fubm90IGFkZCBub2RlICdtYW5kYXRvcnktbGVhZicgYmVj YXVzZSBpdCBpcyBtYW5kYXRvcnkgYW5kIGluIG1vZHVsZSBkaWZmZXJlbnQgdGhhbiB0YXJnZXQg W2F0DQogc3ViLW1vZHVsZS0yYi55YW5nXTwvcD4NCjxwPkFzIHBlciA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTcuMTciIGNsYXNzPSJleHRlcm5h bC1saW5rIiByZWw9Im5vZm9sbG93IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi03LjE3PC9hPiwgd2UgYmVsaWV2ZSB0 aGVzZSBhdWdtZW50YXRpb25zIGFyZSBib3RoIGxlZ2FsJy4NCjxicj4NCjwvcD4NCjxwPldlIGhh dmUgcmFpc2VkIGEgdGlja2V0IFlBTkdUT09MUy05NTYgYXQgT3BlbiBEYXlsaWdodCBidXQgZm9s a3MgYXQgT0RMIGFyZSBhc2tpbmcgdXMgdG8gY2hlY2sgd2l0aCBleHBlcnRzIGluIHRoaXMgbWFp bGluZyBsaXN0LjwvcD4NCjxwPkNhbiBvbmUgYXNzZXNzIGlmIHRoZXNlIG1vZGVscyBhcmUgbWFr aW5nIGEgJ2xlZ2FsJyB1c2Ugb2YgYXVnbWVudGF0aW9ucyBvciBub3Q/PGJyPg0KPC9wPg0KPHA+ WXZlczxicj4NCjwvcD4NCjxwPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K PC9wPg0KbW9kdWxlIG1vZHVsZS1hIHs8YnI+DQombmJzcDsgeWFuZy12ZXJzaW9uIDEuMTs8YnI+ DQombmJzcDsmbmJzcDsgJm5ic3A7bmFtZXNwYWNlIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZj MjM5NkUiIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vYW5vdGhlcm1vZHVsZSIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj4NCiZxdW90O2h0dHA6Ly93d3cuZXhhbXBsZS5jb20vYW5vdGhlcm1v ZHVsZSZxdW90OzwvYT47PGJyPg0KJm5ic3A7ICZuYnNwOyBwcmVmaXggYW07PGJyPg0KJm5ic3A7 ICZuYnNwOyBjb250YWluZXIgdG9wIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbGVhZiB0eXBlIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdHlwZSBzdHJpbmc7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG1hbmRhdG9yeSB0cnVlOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB9IDxicj4NCiZuYnNwOyB9PGJyPg0KfTxicj4NCm1vZHVsZSBtb2R1bGUtYiB7PGJyPg0K Jm5ic3A7IHlhbmctdmVyc2lvbiAxLjE7PGJyPg0KJm5ic3A7Jm5ic3A7ICZuYnNwO25hbWVzcGFj ZSA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJodHRwOi8vd3d3LmV4YW1w bGUuY29tL21vZHVsZS1iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPg0KJnF1b3Q7aHR0cDovL3d3 dy5leGFtcGxlLmNvbS9tb2R1bGUtYiZxdW90OzwvYT47PGJyPg0KJm5ic3A7Jm5ic3A7IHByZWZp eCBtbTs8YnI+DQombmJzcDsmbmJzcDsgaW5jbHVkZSBzdWItbW9kdWxlLTE7PGJyPg0KJm5ic3A7 Jm5ic3A7IGluY2x1ZGUgc3ViLW1vZHVsZS0yOzxicj4NCn08YnI+DQpzdWJtb2R1bGUgc3ViLW1v ZHVsZS0xIHs8YnI+DQombmJzcDsmbmJzcDsgeWFuZy12ZXJzaW9uIDEuMTs8YnI+DQombmJzcDsm bmJzcDsgYmVsb25ncy10byBtb2R1bGUtYiB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHByZWZp eCBtbTs8YnI+DQombmJzcDsgfTxicj4NCiZuYnNwOyZuYnNwOyAmbmJzcDtpbXBvcnQgbW9kdWxl LWEgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBwcmVmaXggYW07PGJyPg0KJm5ic3A7IH08YnI+ DQombmJzcDsgYXVnbWVudCAnL2FtOnRvcCcgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyB3aGVu ICZxdW90O2FtOnR5cGUgPSAndGVzdCcmcXVvdDs7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGNv bnRhaW5lciBmaXJzdC1hdWdtZW50IHsmbmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IH08YnI+DQombmJzcDsgfTxicj4NCn08YnI+DQpzdWJtb2R1bGUgc3ViLW1vZHVs ZS0yIHs8YnI+DQombmJzcDsgeWFuZy12ZXJzaW9uIDEuMTs8YnI+DQombmJzcDsgYmVsb25ncy10 byBtb2R1bGUtYiB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHByZWZpeCBtbTs8YnI+DQombmJz cDsgfSZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsgJm5ic3A7aW1wb3J0IG1v ZHVsZS1hIHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgcHJlZml4IGFtOzxicj4NCiZuYnNwOyB9 PGJyPg0KJm5ic3A7IGluY2x1ZGUgc3ViLW1vZHVsZS0xOzxicj4NCiZuYnNwOyBncm91cGluZyBk dW1teWdyb3VwaW5nIHsmbmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 IGxlYWYgbWFuZGF0b3J5LWxlYWYgezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0eXBlIHN0cmluZzs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFuZGF0 b3J5IHRydWU7PGJyPg0KJm5ic3A7Jm5ic3A7ICZuYnNwOyB9PGJyPg0KJm5ic3A7IH08YnI+DQom bmJzcDsgYXVnbWVudCAnL2FtOnRvcC9tbTpmaXJzdC1hdWdtZW50JyB7PGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IHVzZXMgZHVtbXlncm91cGluZzs8YnI+DQombmJzcDsgfTxicj4NCn0gPGJyPg0K PGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4NCjxwcmUg Y2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3ot dHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSI+bmV0bW9kQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4d8d77d8f576c4e1754e04ad4eaf09f8nokiacom_-- From nobody Fri Feb 15 10:57: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 A25751271FF; Fri, 15 Feb 2019 10:57:33 -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 WEK-ygSJ1fNJ; Fri, 15 Feb 2019 10:57:31 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E0C00124BAA; Fri, 15 Feb 2019 10:57:30 -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 AC059604D0; Fri, 15 Feb 2019 13:57:29 -0500 (EST) From: Christian Hopps Message-Id: <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_74200E9E-C4A5-4964-B70E-847221EC9546"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 15 Feb 2019 13:57:28 -0500 In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> Cc: Christian Hopps , Joel Jaeggli , "ibagdona@gmail.com" , "netmod-chairs@ietf.org" , "iesg-secretary@ietf.org" , "netmod@ietf.org" To: Rohit R Ranade References: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netmod] 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, 15 Feb 2019 18:57:34 -0000 --Apple-Mail=_74200E9E-C4A5-4964-B70E-847221EC9546 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 13, 2019, at 6:04 AM, Rohit R Ranade = wrote: >=20 > 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. >=20 >=20 > With Regards, > Rohit R >=20 >=20 > -----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 >=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 = 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 --Apple-Mail=_74200E9E-C4A5-4964-B70E-847221EC9546 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+m1FHa6lLh2DDte4MCUFAlxnC5gACgkQLh2DDte4 MCXARBAAkczC9JdR2XIemTfOj79Szo1Tb1W42dpdEUl4S0vYMXjz9hgPwQuIrnVZ tqvOCZ10UUeJHNSXtNoCdUKYgImMZJmXZFbheiYG7pxOmGli6mv7f/UgqgoG/o61 EJxQg/46V12rcHTpwis1qiRgZ6AqmaatE2ZmdI3EXfvHdAjloNLS0ZoyKR4wutlC LyfcHXpuwJr9frdrb8YOJifTIK/PDR6xL5mwol43/QDy4QoessMMJnww+FmYwHpS 2SuX6ZQoXTc/AUFjIhm1xNyy1WQ3pNAbGv/n5MVz4zMB4a4amffEsw4hxhWrqett DcetZG8zMsxRVMy9eSXZEaoh5JQM1b2xDorPRT9tW29tNM15nLR2qdQfYHuEe1Hz l9go4UJYogxcenirpi1EkPBMNL6dayiXfP6cG0dc+XqUj7QLlDtUn5wHgYyJ/4kM yYzWbCy1KTkpEZiCC8AynqFc7VrdMlYwC5u2El2mMSO6+L/0ZEVdN1E05IjqIOGP bFtQ2chSvFqBw4V6ad3vIqrLUObiCG2EVlrT9TgwQ5YwV2e0Vbfr8StlR7wJaFz5 775bPrGHl9ULYs/Pmdo4rf4KlOoGwxC7sRE5ieih+4d2+yn41/Lxl6Uqpx3coE5I z4x79XKXqGONBlJQPWtvPZLKuoJf5cPGQkFhtFeazSt2m6rXsmc= =1cNV -----END PGP SIGNATURE----- --Apple-Mail=_74200E9E-C4A5-4964-B70E-847221EC9546-- From nobody Fri Feb 15 10:59: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 3FBCA12D4E6; Fri, 15 Feb 2019 10:59: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 caso0uCReh1H; Fri, 15 Feb 2019 10:59:41 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id ED1A612F1A2; Fri, 15 Feb 2019 10:59:37 -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 2A074604D0; Fri, 15 Feb 2019 13:59:37 -0500 (EST) From: Christian Hopps Message-Id: <4A8FEF81-8B14-4BC2-9BC4-58B0583D67E9@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EC3687D0-8EAE-44F5-B4D4-FB650118A517"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 15 Feb 2019 13:59:36 -0500 In-Reply-To: <155005949957.9572.9759688529698051075@ietfa.amsl.com> Cc: Christian Hopps , yang-doctors@ietf.org, draft-ietf-netmod-module-tags.all@ietf.org, netmod@ietf.org To: Robert Wilton References: <155005949957.9572.9759688529698051075@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netmod] Yangdoctors last call review of 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, 15 Feb 2019 18:59:43 -0000 --Apple-Mail=_EC3687D0-8EAE-44F5-B4D4-FB650118A517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Robert, I've adopted all your suggestion. Thanks for the review! Chris. > On Feb 13, 2019, at 7:04 AM, Robert Wilton wrote: >=20 > Reviewer: Robert Wilton > Review result: Ready with Nits >=20 > I have reviewed this document as part of the YANG doctors = directorate's > ongoing effort to review all IETF documents being processed by the = IESG. These > comments were written with the intent of improving the operational = aspects of > the IETF drafts. Comments that are not addressed in last call may be = included > in AD reviews during the IESG review. Document editors and WG chairs = should > treat these comments just like any other last call comments. >=20 > I've already reviewed the previous revision of this document as part = of WG LC, > and any significant comments have already been addressed. What = remains are > minor nits, that would probably be spotted/addressed by the RFC = editor, and I > leave it to the authors discretion as to whether/how they address = these: >=20 > 1. It may be helpful for the introduction to state that the module = conforms to > NMDA (from YANG guidelines section 3.5). I.e. add the following text = + > reference. >=20 > The YANG data model in this document conforms to the Network > Management Datastore Architecture defined in > RFC 8342. >=20 > 2. Paragraph 4.1, perhaps "will be" =3D> "is"? >=20 > 3. Section 4.3, "removed with using" =3D> "removed using" >=20 > 4. The YANG module itself: >=20 > 4i) NetMod =3D> NETMOD (two places) >=20 > 4ii) The RFC 2119 boilerplate should probably be updated to cover RFC = 8174. >=20 > 4iii) Line length is a bit long in places. I checked using pyang = against 69 > chars and got this, so at least line 89 should be fixed (but the RFC = editor > will also fix this): ietf-module-tags@2018-10-17.yang:56: warning: = line length > 72 exceeds 69 characters ietf-module-tags@2018-10-17.yang:57: warning: = line > length 71 exceeds 69 characters ietf-module-tags@2018-10-17.yang:63: = warning: > line length 71 exceeds 69 characters = ietf-module-tags@2018-10-17.yang:64: > warning: line length 71 exceeds 69 characters > ietf-module-tags@2018-10-17.yang:86: warning: line length 72 exceeds = 69 > characters ietf-module-tags@2018-10-17.yang:89: warning: line length = 86 exceeds > 69 characters >=20 > 4iv) Possibly add ", but they have no operational effect" to the end = of the > description of masked-tag. Although, it is pretty obvious to me that = they > would just be ignored. >=20 > 5) Section 6. > - Suggest "It's" =3D> "It is", "2" =3D> "two", "3" =3D> "three". > - Suggest "is classifying modules in only a logical manner" =3D> = "only > classifies modules in a logical manner" >=20 > 6) Section 7.1. > - Since these are guidelines, I suggest "can" =3D> "MAY". >=20 > 7) Section 8.1. > - I note that this section uses "SHOULD", and section 3.4 just says = reserved. > Should section 3.4 also use RFC2119 language to be aigned at all? >=20 --Apple-Mail=_EC3687D0-8EAE-44F5-B4D4-FB650118A517 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+m1FHa6lLh2DDte4MCUFAlxnDBgACgkQLh2DDte4 MCW8TA/+J/U+XE+gJkvznjgJ/1/KCFLuXLBWki/nkUYKvRHeuF+ojYtjQONscnsh QHnpdZqyBJh3s6AYTYMYmkEAyxgo3tE2Uxb5ajKgKuBFUHCWG22fCdqOB5sBovQk 0/2jQEDQCW+cLttiXs3H2SJPLv4mopMJCvh6gxvrc/7YoQ72tszhq3AN2PXtzrvJ ZbshAnw7APSVMiJ9u8U77PAqt8mSR62LoEE5/h/DTmWRTpNfOFSPlRIT73eGEqgN tGR+k/+hFWaGNfQCjm/FVUggCutK7fz9BLeIiQDQtp0LZz2DwdDVAiI0tr8XJh5c M5hcfig3twFz78r9iBb+O1iG7OcUcgJNqdodYR9caz+Ce+nj8cL1T0zPKVsTRt7O gmAyNlLfkLNQLHRWRnq9X6O6JD9GH1b22VkI5z7Nemmw5J9HoR5WrCAa3F3Lku79 hT1A7KzTfVqy2Xa7IZ31USUgWZ9KlhzJ5LFHkxDN8pTWZABtL8d0LyHDUstnxNnJ bP7VeEGxG0G9uhjApANckCxcf7utDCEl9+AMjJkibH+MV5xTmjkBlL7O7+xqOMLR mfrstB1pnb16oyX+FwfXsbRG8JkAU8BUsAdS8lGQRIj1Mim4LaokwIzIsshJwZlX n9ATSkLpLQ9lnZUGq83rMefuqhACHaBsPjGZUTjeGB0dFzCw61U= =d51a -----END PGP SIGNATURE----- --Apple-Mail=_EC3687D0-8EAE-44F5-B4D4-FB650118A517-- From nobody Fri Feb 15 11:23:00 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 65B0B130F93; Fri, 15 Feb 2019 11:22:52 -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.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155025857237.4718.190569194621098545@ietfa.amsl.com> Date: Fri, 15 Feb 2019 11:22:52 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-module-tags-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: Fri, 15 Feb 2019 19:22:52 -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 : Christan Hopps Lou Berger Dean Bogdanovic Filename : draft-ietf-netmod-module-tags-05.txt Pages : 13 Date : 2019-02-15 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 provides guidance to future model writers and, 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-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 Sun Feb 17 18:57: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 7B1CD130EB1; Sun, 17 Feb 2019 18:57:46 -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 G0fMnGbjukVO; Sun, 17 Feb 2019 18:57:44 -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 24365130EB0; Sun, 17 Feb 2019 18:57:44 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4E71AAE9D674CD3C844F; Mon, 18 Feb 2019 02:57:42 +0000 (GMT) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Feb 2019 02:57:41 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0415.000; Mon, 18 Feb 2019 10:57: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: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 Thread-Index: AQHUxWBST4whJ9bV6kO/PWNMC6m5PKXk2PSg Date: Mon, 18 Feb 2019 02:57:30 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCFB4AC@dggeml510-mbx.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> In-Reply-To: <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> 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: Re: [netmod] 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: Mon, 18 Feb 2019 02:57:46 -0000 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. 2. Why should the prefix contain ietf: , vendor:, user: ? I think the seco= nd part of the prefix is more important for classification because most of = the vendors / sdo already define their own prefixes for their module-name b= ased on RFC7950 guideline in Section 5.1. By adding the prefix, I feel it w= ill reduce the re-usability by other SDO / vendors. 3. Consider we have defined a module example-bgp which is similar to ietf-b= gp. 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 ?=20 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 st= andard tags ? =20 Consider a module which has some part of vendor and some part of IETF proto= col , whether vendor can use "ietf:" tags then ? I suggest adding one more example in this document which may indicate/clari= fy your stand regarding this point. 4. By defining a module tag as an extension, there is no way to validate th= is extension's argument during YANG compilation (even though a pattern is d= efined). 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 thi= s document for clarity ?=20 Please not that all these points originated in my mind, by thinking as to h= ow I will use these tags. On the whole, I like the idea and thank you and t= he co-authors for documenting this. With Regards, Rohit R -----Original Message----- From: Christian Hopps [mailto:chopps@chopps.org]=20 Sent: 16 February 2019 00:27 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 13, 2019, at 6:04 AM, Rohit R Ranade wro= te: >=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. Sec= tion 4.3, " removed with using normal configuration", can use "removed by u= sing normal configuration" Done > 3. Description of statement "leaf-list tag", in the Step 1), " System ad= ded 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 we= ll 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 t= his list", can be replaced with "The applied configuration of this list", a= s 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"=20 > can be replaced with "tags of 'intended' origin" as it uses a=20 > 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". Do= es 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 rea= son why System tags should be added first and then User configured tags ? N= ot clear. This is just the way it worked out on the mailing list. Doesn't hurt to spe= cify an order. > 3. Description of statement "leaf-list masked-tag", " This user can remov= e (mask) tags", I think we need to clarify that it will not "apply" the tag= s which have been configured as "masked-tags", because they are not "remove= d" from any configuration datastore. > The tags which have been masked will be present in , but will n= ot be present in . > Suggested description > " The list of tags that will not be applied to this module. By adding=20 > tags to this list, the user can prevent such tags from being applied.=20 > It is not an error to add tags to this list that are not associated=20 > 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 deepl= y 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 "Sys= tem" and "User", and in the spirit of your suggestion, I did change it to b= e 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. >=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=20 > draft-ietf-netmod-module-tags-04 >=20 > Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-0= 4 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 From nobody Sun Feb 17 19:49:46 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 2B08D1311D1; Sun, 17 Feb 2019 19:49:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk CC: ibagdona@gmail.com, netmod-chairs@ietf.org, draft-ietf-netmod-module-tags@ietf.org, netmod@ietf.org, joelja@gmail.com, Joel Jaeggli Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <155046177009.4059.13560986764723643834.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2019 19:49:30 -0800 Archived-At: Subject: [netmod] Last Call: (YANG Module Tags) to Proposed Standard 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: Mon, 18 Feb 2019 03:49:37 -0000 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 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 provides guidance to future model writers and, as such, this document updates [RFC8407]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 18 01:27: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 E5763130EE0; Mon, 18 Feb 2019 01:27:13 -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 l_8PtLEp0Q7i; Mon, 18 Feb 2019 01:27:11 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 45543130EEC; Mon, 18 Feb 2019 01:27:10 -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 13BB560467; Mon, 18 Feb 2019 04:27:09 -0500 (EST) References: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> <991B70D8B4112A4699D5C00DDBBF878A6BCFB4AC@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: <991B70D8B4112A4699D5C00DDBBF878A6BCFB4AC@dggeml510-mbx.china.huawei.com> Date: Mon, 18 Feb 2019 04:27:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] 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: Mon, 18 Feb 2019 09:27:14 -0000 --=-=-= Content-Type: text/plain; format=flowed 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+m1FHa6lLh2DDte4MCUFAlxqemwACgkQLh2DDte4 MCXohBAAk4hggS/nDQciC//AnZwelF5OmgM5+4s03E5VfGjx0qCqbkdFIXjXHhn7 qy4qLe4stst0tejLx6oYpgAHnE642Q8/OX65UYCIEBSwe+fnCBzeRfRdSoZUm+zb cAw9UZWELchMnopfgWitrf7VsmlXqUR6hJUaHNTmy+B2oH0RvSkObJLBxCBwl73K e9coZhUPRWhjgLeIffvCABkru2b4fIS4P9qp+ddmD0o+CVEGZKKYp8TWUITeU6iL cxE5rK7wOPGyCsguhnL7bBBagCa/eIp0JiBaW+fjiUhMIpAdpbXE/Tw2IQS1xmwW t7mkcGH6k+rrcZptQTLnCLOIqvALhKCjfeBnWP8hnEz7hXsMK7nroj/FwhHQj3/c IXgkRQzDUZfld6zo2rJyVQeW7sTWjKFxTpb9q4toGiSC9ddtPiOPZrfhMHdSH8OV tyIodvkZeaTvoFvXOEHr9nOUi/lSSJP4wd+FDZqz1b8FfdP9RIxZmQ+3N//eb2T2 1qNzd20c7oNhU+yxFb/uNWG6v9iVCJ1Q5YLPiqTP/p0VJ5Sv2iBxZMMuQp68wkJk vb3wPi7voof7X9pw6bi/iNqetK5QGyxrg6mjSF/SnxWkskn7zd9eKZf2ZcNpjHo8 Shw61fyAebhz78kS7YSuJcqstwYYSh0slXlGh1t0JhFN4zreyPs= =5xj0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 19 05:13: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 60B17130EE0 for ; Tue, 19 Feb 2019 05:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_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=ayTa/Y5K; dkim=pass (1024-bit key) header.d=ericsson.com header.b=H1xuYMVc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2CcOQoskOa5 for ; Tue, 19 Feb 2019 05:13:47 -0800 (PST) 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 A9371130ED7 for ; Tue, 19 Feb 2019 05:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550582024; x=1553174024; 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=ScG0sKqqXn0ySD+2BBidVNufOH0pCmnVR6MFDRAjMn8=; b=ayTa/Y5KjlfxMC/4pIupc1Uupz1DlyF/+3yg8Vw5KpUfLDdujoTskHv8KDpBBHKj SMBKfhm+ZwqlzA3E3QgOyypmjrF9/6ClpJbWEXWQaOCe18esJ/Rsr98SRbwkYJ4j CXyfqnHJGuOXR6cxg90y/nrW0W9Q5hZ3GYcrTvzU/HU=; X-AuditID: c1b4fb2d-2198b9e00000062f-4b-5c6c0108ae1d Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.1B.01583.8010C6C5; Tue, 19 Feb 2019 14:13:44 +0100 (CET) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 19 Feb 2019 14:13:42 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) 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; Tue, 19 Feb 2019 14:13:42 +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=ScG0sKqqXn0ySD+2BBidVNufOH0pCmnVR6MFDRAjMn8=; b=H1xuYMVcTbLMIdOwHReesO0UtlSIriPMsX8TUs8hTns5/Tnsy1qu1seHp7jUP7O/K+gD/feNgLU6F2Q3aTTldXAJCXTC1JRFtPbO9o0Vf+ygiPYNO5l7kXG/03sBJePuYLJNAKanMcesA+v7YW63ICqLj17mg/ldYu+dq65yGpA= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB4324.eurprd07.prod.outlook.com (52.133.56.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.10; Tue, 19 Feb 2019 13:13:42 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::9027:886e:9046:b251]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::9027:886e:9046:b251%4]) with mapi id 15.20.1643.008; Tue, 19 Feb 2019 13:13:42 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: [netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology Thread-Index: AQHUyFTvY1P2Up6kTkuobB2P69vrYw== Date: Tue, 19 Feb 2019 13:13:42 +0000 Message-ID: <68804c28-0748-dbdd-6e1f-278804d27795@ericsson.com> References: <20190207153212.wttlorfwpoy6mpe6@anna.jacobs.jacobs-university.de> In-Reply-To: <20190207153212.wttlorfwpoy6mpe6@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: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 x-clientproxiedby: HE1PR05CA0332.eurprd05.prod.outlook.com (2603:10a6:7:92::27) 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: 38121583-951f-4fc9-5448-08d6966c11db x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM0PR07MB4324; x-ms-traffictypediagnostic: AM0PR07MB4324: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA3TUI0MzI0OzIzOkxuTzNHWUZtV253NUtlN3pyNjNkSkJ4UHV6?= =?utf-8?B?anlEK000cXdIWmswSmwvblNaUDMwUEpqbmFPVHVCd1BHclFZU2hVWjBrTENn?= =?utf-8?B?MUlxTnRyQTNBOTJjVFBQVkNGUnAxdFBZTVpranNrQzFVQ0hjYmhTYndNZm9w?= =?utf-8?B?bFBzQ0F2QzFyNDYxLytTSjM1UnU2c2FLTHBMdzZHRUJZZW5UU1BUemVTZTB6?= =?utf-8?B?dnRVUGFHZldLbmN1Y1lqamR0eWhTbjZvaXNjY1BXWFZqRmcyRUh2MENWdzlr?= =?utf-8?B?bVIwcmJmNE83dStVRGxNeGZPU1N6bmVtRWJrYTNSbnVqUEdIcXA3ZHMwTkx2?= =?utf-8?B?UXZESDM2NStPSitvOHNjcFYwc2pZQlFoaEJwVHlyNFUybklzbHNMMkRnSDhQ?= =?utf-8?B?cm05VGVENDVZelQ3OEo3Ny9SZmJYSENhdm5KNi9iVEUwdnNQZUxBWkxuckwv?= =?utf-8?B?R0hkWUowbEo3cUVDNlErMk94WTc2Z1BUemgzTDMyTFFXMjBwMngrZm9VQzNr?= =?utf-8?B?SE96LzJwYXQwVVZscHY5b2xhYzBGMEFmRjlqeUo5MXg4YUhRTzhJbHBWTlpF?= =?utf-8?B?bzZiQ1RETW9vWklWdm1hd2pDU1hFUnFVLzY4ODB1Z0thS1NUbjgvdnFpcEJr?= =?utf-8?B?N01NdHJFOVozRGIrV3NDajlEaVZBbitwMFhIblAwZ0Q5TEpjbzdNSVNyY3VY?= =?utf-8?B?N283eE5VV3FzYmp3N1NzeWM2OXpORUZ2L2F2Z0JBQVk1aktkTzRKbmlNQUJv?= =?utf-8?B?NjRCRVoxQzhFS0ZBT05SRWVGeHBTcS80UHdBaGVtUWZGYzA5M0tUV2VRNEVV?= =?utf-8?B?Z0N0cXd5R0RPcU83UHZiZFhKTlg4LzBOTU56Q0FVWnVvU2dvdmlCV0Jtc1Bo?= =?utf-8?B?a2FuakJ2TTB0SGphZkdZRC9FVmlBd2l2S2x0T0M3NENFRjVKb3NjdkFwb0Vs?= =?utf-8?B?UXJldnkvdzNlcUhkdmkrNjZvTm95WFdQL0JvRjdBYlF0ZEEyeVlDTFkyYXBp?= =?utf-8?B?b21GVVIvWjMvdWswL2I2Ui9yNFBaR3VDa2ozTzJCNWRDaE9kNmJCNmhTaHhk?= =?utf-8?B?ZlRvaU0ybm1MekY5MEhSUjJPTmFSdUtiaHNCV0FJTHFiNGVpeG1maVpaTzVZ?= =?utf-8?B?czdtVXI3bUliMy93bWtyZFdoUmFpWnVsNkhRWmRnWmVzTEF0RkhzL1BTZEY3?= =?utf-8?B?TWMrWms5ZGFEWXFVQUlqKzRFcG91WENiOW93M3Nub3UrVVBUZExEQ2lkYUNE?= =?utf-8?B?aEQzT01ldTVibXE1RDN4akhRNlRBaS9KeEQ5akF4N08zRjF4R2w5WUFGZFBh?= =?utf-8?B?SjNVcTVuUW9hcU9ucjNZUjR2MEJoeUQyMEJrQ2t3em5uNEdPS3Qra004Y0Jn?= =?utf-8?B?ei80NkF1UWhFMWI1K0NFRnhJS2FoT0lna055NC9vRWVSRCtGay83K3Zrc1FM?= =?utf-8?B?T0JEVGpjcUNwSURJV0ZmVkFSNHh4dWluMENtVHpLcVlYc2VkWHVmeTlXWm1L?= =?utf-8?B?ME5mRTRiaDlCMWNOK3h3ZEJ6ekVoK0tWUklQbDNoeWtIZkVYb3JXcUdsS09o?= =?utf-8?B?MkJxQTRKRVZFQUNCRE9hRVRMaThZR3hpMWFScVNGd2FCei8vYXZSb1dxdVY2?= =?utf-8?B?L1ZsZjhMUnN5UGlFM1M2TjhNQldhbGxSSEU4d25CN2lOTWpLTmpKcjZHM242?= =?utf-8?B?TGkva3lXSnZZendoNGtQcjR0Q0RPU3Q2cDlPOW4rWUpqVTdFT0pFV1hER2cz?= =?utf-8?B?d0c5eEM1amJCVW1OYzNNb2N0RHpCbnJZQnNGZzhyV0YxeUJGbFNmb3JsSzFq?= =?utf-8?B?WUZ5Y1Q2MmlOZWl2Y2JEUzlmRUp0UUhzODdnSGtOMUNmY2diYlVudGQ5WndF?= =?utf-8?B?TjAzQWRxQnRFRXRTMHk1UHdieCtlU25mSjlZNTVOZkFxOXhPcUt4L0M3Q3Nq?= =?utf-8?B?SHdBek1RR3h2cGxVNmFNR3ZucU5IM2kwTkVJbTJWYWNZcUkwOW1vSVRZU0VZ?= =?utf-8?B?M3lNWjI2VDdSc1NyN2VZTnhmM1Rkd2NYOXVQSVBIZTdOMEtxd3FnK1VOSENQ?= =?utf-8?B?ZmtkbGo1ZStkREZGd0hobXIwZjJxWEhnL0lKVDRiRGQwa1IrRWdzUDlpQ09t?= =?utf-8?B?N1E9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(396003)(136003)(366004)(189003)(199004)(51914003)(236005)(8936002)(2906002)(65826007)(256004)(14444005)(66066001)(65956001)(65806001)(6916009)(6512007)(8676002)(1730700003)(5640700003)(54896002)(97736004)(76176011)(7736002)(31686004)(14454004)(3846002)(6116002)(478600001)(2351001)(86362001)(6436002)(386003)(6506007)(25786009)(6346003)(31696002)(52116002)(53936002)(102836004)(99936001)(476003)(2616005)(229853002)(316002)(85182001)(11346002)(68736007)(6486002)(6246003)(99286004)(71200400001)(2501003)(64126003)(36756003)(105586002)(106356001)(81166006)(81156014)(71190400001)(186003)(486006)(26005)(85202003)(446003)(58126008)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4324; 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: BwVTHpvB+ojRtDMug0dHDaEOdSHN2gP6M9fUkp3OEbVRyFoxpL5WYQO8gG2b4c8o/dogm1jE9BjjjEUUFnATSd/UVCZuGAmAXy8fIGKBkqCuPohc4ALOAbJ+WZNJtoMqV2svXBec1/ni26aBxcxFWdBWLYLQxLUloZZisUb/qNk7ihvbFmmNL9HpOObAPHYzUrNc5cOwpm2AVhdKYCTjhcQAIZZ8gn7SukpB/DsmNGj3sQH+foDGA7bbpnkKYmurx1UTUm5Pq3fmSmFujU+GVsLDOT1M0N7KxcT7/2pGCAJwXTQq5iCnbwmddmdQCLqnmBIrPY2K+kpMCBbWiscOWQH4C3pB3WO4jI6SpfhOKauGbk6rMecE+z8EI8YqDB00WP3FGsxWHzNB7aFattaFuelU7dIfWxXaQsT3Jm3igow= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020106020206070706050702" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 38121583-951f-4fc9-5448-08d6966c11db X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 13:13:41.5992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4324 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSeUhUURTGufPevHlODtymMQ+alK9Vc6lUKIxK8o8IWjQKt6hBHyrqKPPM JYpsw1wKs2QcydFUJmpELQ2tBHFyMBVDLZKUCnUSl4qUchkXmuc1qP9+537fOd89l8tSyh6p CxuvSeW1GnUix8hpfVhjujeLEqN2Ddk27S3rvSo9hI5UVc1LTqII+f4YPjE+jdf6Hjgvj5tq KpSlzEZn/GytkWSh5TO5yIEF7A83Xt6jc5GcVeI2BL/y3yJSzCDI/2JgSFElAcsnw4qNxgUU dA7Uy4hSKIHr429ocZgSDyMo13MiMzgYsn+0SERW4e2gf1HLiLwOh0JX9gRFzk9Brc4sI+wD RX3Zdj9rT9gKX037RFTgg2Ab2UymH4cKS85KkgM+AQ2fK6UiI7weZjurV5Io7AwD1jIJWU0F Q71dDGEnGB9ZlhLmoHhiYIWd8Fm4+72UElcBXITAmNssIyYv6O63IsJu0FeWt8rHwDImDhIb RhA8H3xKE8ETKswmRIRZFTwyjK7GJcB4nWm1ewMMdulW4z4y8MBmlRYgn5J/rl5i1yicg6Cj 14JEQYHXQofeSpfYn4PC28B4k/vfL/JOMD6cpAgHQrGtlSHsDvfzhmSEA2DSMoUI+4GxZokp R/InyEngBSEpdo+fD6+NjxaEZI2Phk99hux/q7VhwbsJmSaDzAiziHNUlI0mRCml6jQhM8mM ttjnDNeZepALrUnW8JxK0fbBLiti1JkXeW3yOe2FRF4wI1eW5pwVi8q1UUocq07lE3g+hdf+ VSWsg0sWcs153e1uMxeGtBq8mh9Pj+quXXGubqyPr/T3Dni3Yz6kSOlwe6Y4QxF5Zy7cHOYW ar7s4RvBLXzz1CeHronuX/xN56a3l1zy663KCrSVSoPa5hjHsT5/N/mtjXz5ZPjSq/CZln4r 39Q+nckF57ifnsvwgMO6o1F9hhhB934gkqOFOPVuT0orqP8An+uRpWMDAAA= Archived-At: Subject: Re: [netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology 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 Feb 2019 13:13:49 -0000 --------------ms020106020206070706050702 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Thanks for the comments. See below!

On 2019. 02. 07. 16:32, Juergen Schoenwaelder wrote:
Hi,

I just stumbled across the terminology defined in
draft-ietf-netmod-yang-instance-file-format-01 and I have several
questions:

   Design time: A time during which a YANG model and the implementation
   behind it is created.  Sometimes in other documents this period is
   divided into design and implementation time.

Assuming that design time and implementation time are the same seems
to be odd. In the IETF, it is quite common that there is a significant
difference between design time and implementation time. So what is
mean here? Since the term is rarely used (I found two occurances),
perhaps clarify what is meant where this term is used and do not
introduce a new term. However, if the term is defined, then I suggest
that we use semantics that align with the common use of the term.
BALAZS: Following your suggestion I removed the term.
(I do not know if we really have a "common use". For me (Ericsson) anything from specification, to SW development to testing is considered design time.)

   Instance Data Set: A named set of data items that can be used as
   instance data in a YANG data tree.

Why do we need this term? How is this different from data tree defined
in RFC 7950?

BALAZS: Instance data set is more than jus= t a data tree: it includes metadata and MAY include additional items
like XML attributes for implementation specific use. Also the validation rules are less strict as partial data sets are allowed. 

   o  data tree: An instanti=
ated tree of any data modeled with YANG,
      e.g., configuration data, state data, combined configuration and
      state data, RPC or action input, RPC or action output, or
      notification.

In which sense is this a 'named set'? Or is the intention here to
define a named set of YANG data trees? If a term is needed, would
'Instance Data' not be simpler and align better with Instance Data
File? Also note that 'instance data' is defined later as 'data that
could be stored in a datastore and whose syntax and semantics is
defined by YANG models'. So how does 'instance data' related to
'instance data set' and 'data tree'? Can we simplify things?

BALAZS: Instance data is used as a general= term. "Instance data set" is a specific representation of instance data, that

  • has a specific format (XML or JSON)
  • must be decorated with specific meta data and
  • must have an identity (name + revision-date/timestamp)
  • has a specific scope (partial data sets= are allowed)

Even for an unchanged data tree, you may record different instance data sets e.g. representing the same data tree at different times, thus signifying it has not changed. 


   Target YANG Module: A YANG module for which the instance data set
   contains instance data, like ietf-yang-library in the examples.

I am not sure I like 'target'. It seems to me that instance data is
expected to conform to a schema defined by a collection of YANG
modules and you probably want to express that (but 'target' I find
misleading - data does not target a module).  Whatever we choose at
the end, we need to make sure that the terminology across related
documents (YANG, NMDA, YANG Library, ...) is consistent.

The leaf target-ptr triggers questions as well. If there is a choice
between two things, perhaps using a YANG choice is a more natural way
of expressing this than inventing special notations. I am also not
sure if it is a good idea to hardcode the name ietf-yang-library. Why
can I not just refer to any schema defining YANG modules? This way, we
have the freedom to create ietf-yang-library-2 if we ever want to. Do
implementations have to follow target-ptr arbitrarily deep? Do they
have to detect circular references (well they better do I guess).

BALAZS: Agreeing with you, it will be changed to choice. That also makes finding the
used method explicit. It also makes it easier to add new methods later.

I will make it possible to use other YANG modules.

Could you propose a better name instead of= "target"? IMO the concept is needed. It could be called "target" or "instantiated" or "data-defining" or=C2=A0 ???
IMHO terms like "used", "referenced", "relevant" are to generic and used for too many ways. 


/js


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms020106020206070706050702 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIxOTEzMTMzOVow LwYJKoZIhvcNAQkEMSIEIGCCNXLndw0VfXXbNLrSNNJeUpEIIY9GdzX4wwfKDKSQMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAA28fu5VHZRC885yVg3PierVRdiSZSJxp5gleOS3Mg2iSeKh 3HoivxrVGdalJgGV7cP7+9HHztK9rw4cbhZYmH2+8aKO0wA6B2lwAHPonzT1xz55AxoSvrnk 4EvczpMG/okPlr0oxER57i5vaVqGC4pR6ksicxwx6w8WyZ4ZSYVzJ1d8qHFWRgi02u5yoc1v Hagr7Pfetxn8U8BlmyQVjXCjtrt1ikLOcYk5HWW94xKwrGZPpNyI88H7p24avnPKhVxTQ1ue dlIJW44yxP5VVGamgz26Kvi0pfXefzjnnQZZWOQMiEhhE8WrWALisiB0hoKl47kK8FHGC7mK NjULY2oAAAAAAAA= --------------ms020106020206070706050702-- From nobody Tue Feb 19 05:41: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 542D0130EEF for ; Tue, 19 Feb 2019 05:41: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, FREEMAIL_FROM=0.001, 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=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 3di2pD-vw7LI for ; Tue, 19 Feb 2019 05:41:14 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 B56F1130EEB for ; Tue, 19 Feb 2019 05:41:13 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id m1so2878763wml.2 for ; Tue, 19 Feb 2019 05:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BdL3+rRYaZeAxs+iTB23ksNQcc2iKwFl/tC1S6HoRBo=; b=W7aBOjtf/+aX+DGvkvooxyGv4iDqLqdgmqn0mZSMrELeKbR3SfZLwWgsjlZMH8EsGs 2WU7EN0Mpl9foB9H/4MdJ5Mr6PmS8WaVi+BgAfgNEhzlsSYB+ie1pKmOcOZLRdJGrQp3 a+W3KIUN6ao/YKlMK5SPluaW/1oV8yboizMyjbc17Zh8rJROxrD9Zvb3Wzw5OakcY/BJ 3+KCltO7xpUJrMoDNAroS0QPhSk6dZakthBmplsI4xAymiQ/yUhpGFpeahSGPgkbrMhN CjCOVvZ04A5hKEYBcFelmyB0wrKbrpXuNWi2LXBNKn0eyfdpmiLIEUXWFws6TB5PiLji YiuQ== 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=BdL3+rRYaZeAxs+iTB23ksNQcc2iKwFl/tC1S6HoRBo=; b=i2IH2rBExKgtTtWn66I5EXVOSUy+JI6JLawpFM6ovLa8NL8J3Q4NputM7NvAFLuDUd yizBF2l0dt+EFHHVJySAP13lR3JCZP7Onqk3XmyDWRf/W2xrOjnma2hW5F5jCONaxjWV OpuvIe3TJ15Wh+9ta8JX0gMP/hGSNkZY3h84eKmWb1rFw6ChoMykB7nhWaf77wt7Y9rv PsnY7K7DMfGJ0pqPskCWNIinVMxvm+WAGdMH1TcZE8bJaHYUUAT6EIZJ9vzpJD8JFfv8 P6BFiV9E37caXiFFx02FaqqTgd3hkEdSTN4gmAzeK4krvMKyCpS7ASYLm0opo3dUNDJe SoyQ== X-Gm-Message-State: AHQUAubhTxvads/TkyuPj2ZV8f4+3lQnxmBLVbmy4uPN2tb+TFvFKf1P z/7Li8coiAoO7ZJSbvlKVNJ7S7NUnGkxwD5gF7j7Sg== X-Google-Smtp-Source: AHgI3IZhlaLcCWJq85wgANohJ+v+hSlQVgujFj/tdxYGJNjCKy4KjSQvp13zXZA73zWhrcwJZq1RSvUYE8xzgiVDCCA= X-Received: by 2002:a1c:9692:: with SMTP id y140mr3055509wmd.67.1550583671696; Tue, 19 Feb 2019 05:41:11 -0800 (PST) MIME-Version: 1.0 From: Shiva Kumar Pathori Date: Tue, 19 Feb 2019 19:10:59 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2391105823f64c3" Archived-At: Subject: [netmod] Yang model for setting system startup information for software upgrade 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 Feb 2019 13:41:16 -0000 --000000000000f2391105823f64c3 Content-Type: text/plain; charset="UTF-8" Hi All, I think there is a need to extend the ietf-system.yang or have new model to get the current system startup information(like current system software name, configuration file name, paf file name and patch file name etc..) from the device and also set the next startup information for upgrade. This can help the device administrator during system upgrade scenario to operate with the YANG model. So first step will be copying these files(image, config file, paf file and patch file) to the device and then set the next startup information. After this YANG RPC "/ietf-system/system-restart" can be used to reboot the system to upgrade to the new version. I request the WG to provide the opinion on this. Regards, Shiva --000000000000f2391105823f64c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I think th= ere is a need to extend the ietf-system.yang or have new model to get the c= urrent system startup information(like current system software name, config= uration file name, paf file name and patch file name etc..) from the device= and also set the next startup information for upgrade. This can help the d= evice administrator during system upgrade scenario to operate with the YANG= model. So first step will be copying these files(image, config file, paf f= ile and patch file) to the device and then set the next startup information= . After this=C2=A0 YANG RPC "/ietf-system/system-restart"=C2=A0 c= an be used to reboot the system to upgrade to the new version.

I request the WG to provide the opin= ion on this.

Regards,
Shiva
--000000000000f2391105823f64c3-- From nobody Tue Feb 19 18:09:02 2019 Return-Path: <0100016908a9c089-b29f5167-8c45-4a2f-87e4-86472671123d-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 1F36A124D68 for ; Tue, 19 Feb 2019 18:09:01 -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 zmbov5QspusY for ; Tue, 19 Feb 2019 18:08:58 -0800 (PST) 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 954B8126D00 for ; Tue, 19 Feb 2019 18:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1550628536; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=9Qfk5gek4lJ3VTDA0CccgnT/cI6tAyzsWUsp3Atj4pA=; b=B0XpwYfPrbqzS5RStmlCZ3sClzsSl9i6rsgejwXqAHiyTx265FmZXSBjUNP7HzYy s6dtQ3fNDZ5BjLkwDkI8wU6gfA8nyPHYKFGCER7pgRAMWy6y7q0TNPgXCiBs1eYOWnN zz0K2uKyXcPvMBeVsfBc02SVHLTL2rcu1/f/wBAg= 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: Wed, 20 Feb 2019 02:08:56 +0000 References: <154949717453.32719.8586247155278114345@ietfa.amsl.com> To: netmod@ietf.org In-Reply-To: <154949717453.32719.8586247155278114345@ietfa.amsl.com> Message-ID: <0100016908a9c089-b29f5167-8c45-4a2f-87e4-86472671123d-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.20-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2019-02-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 Feb 2019 02:09:01 -0000 Reminder: the virtual interim to continue scoring the YANG Next items is = tomorrow. Kent > On Feb 6, 2019, at 6:52 PM, IESG Secretary = wrote: >=20 > The Network Modeling (netmod) Working Group will hold > a virtual interim meeting on 2019-02-20 from 10:00 to 12:00 = America/New_York. >=20 > Agenda: > To finish scoring the YANG-next feature requests. This is NOT a = YANG-next planning meeting. We only want to score the items in = preparation for a planning meeting to take place at IETF 104 in Prague. = YANG-next issue tracker: = https://github.com/netmod-wg/yang-next/issues?q=3Dis%3Aissue+is%3Aopen+sor= t%3Acreated-asc. >=20 > Meeting Link: = https://ietf.webex.com/ietf/j.php?MTID=3Dmf0fd98065981bfc08c6076295642f7d5= > Early joins may occur 5-minutes before start. > Meeting number: 649 730 322 > Meeting password: BQ3JJrF9 >=20 > Audio connection: > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 649 730 322 >=20 > Information about remote participation: > Remote participation via WebEx >=20 >=20 > Information about remote participation: > See WebEx details above. >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 20 02:29: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 09A86130DEC for ; Wed, 20 Feb 2019 02:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, 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=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 JwA_cMyrq-sh for ; Wed, 20 Feb 2019 02:29:24 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::716]) (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 00847130DE5 for ; Wed, 20 Feb 2019 02:29:23 -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=G6v+3mgFRlfq1o5OvS+RAqlU0uGxo+cpXMv89t/uv/U=; b=LLsuuBHafQB5UatFProeTn8Ulziaapxw6bMBQOmSaG7vaZhWZPDldue13AhmhFIewghGE2QaI8BZqstaNeUS7VIQRfId5PMc/fDSMRhlbp4aKsu6WFKH4lmoNKZdFsjEELpM4PpWPIouDquJUr2WMbQ2jceFUe8wqoB8yrd2Gl0= Received: from VI1PR07MB4768.eurprd07.prod.outlook.com (20.177.57.155) by VI1PR07MB5838.eurprd07.prod.outlook.com (20.178.122.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.5; Wed, 20 Feb 2019 10:29:21 +0000 Received: from VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::a8c3:4982:8378:9a45]) by VI1PR07MB4768.eurprd07.prod.outlook.com ([fe80::a8c3:4982:8378:9a45%3]) with mapi id 15.20.1643.014; Wed, 20 Feb 2019 10:29:21 +0000 From: tom petch To: Shiva Kumar Pathori , "netmod@ietf.org" Thread-Topic: [netmod] Yang model for setting system startup information for software upgrade Thread-Index: AQHUyQckdPZ1rnDhs0KCWC9Sditiqg== Date: Wed, 20 Feb 2019 10:29:21 +0000 Message-ID: <019501d4c906$e6fcc920$4001a8c0@gateway.2wire.net> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0244.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::16) To VI1PR07MB4768.eurprd07.prod.outlook.com (2603:10a6:803:76::27) 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: 9b5aeba8-cdd9-4187-3c43-08d6971e46c7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5838; x-ms-traffictypediagnostic: VI1PR07MB5838: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(136003)(396003)(13464003)(189003)(199004)(14496001)(66574012)(97736004)(52116002)(71200400001)(99286004)(71190400001)(14454004)(966005)(2906002)(84392002)(1556002)(50226002)(6246003)(25786009)(478600001)(68736007)(2501003)(105586002)(106356001)(76176011)(81816011)(81686011)(33896004)(102836004)(14444005)(256004)(61296003)(386003)(6506007)(305945005)(6346003)(316002)(110136005)(7736002)(26005)(186003)(446003)(4720700003)(6436002)(3846002)(6116002)(81166006)(81156014)(8936002)(476003)(229853002)(44736005)(5660300002)(6486002)(86152003)(66066001)(8676002)(86362001)(6306002)(53936002)(6512007)(9686003)(44716002)(62236002)(486006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5838; H:VI1PR07MB4768.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUI1ODM4OzIzOjEvMmQ0dXUvZFBqajMyTnM4alV1dHJRM1Qw?= =?utf-8?B?Rnk3RTlha2RyckJTNzZoMHBtMHBTN2NnZ2R1Wk5yVkZtNUhCeEx5NnlINDls?= =?utf-8?B?S2lNd1hxditSNExsMXNLVXdXTFNLcjFycWkxQkN1bG1yUld1SXMzMTNOem5s?= =?utf-8?B?ZXEvZGJwNG5pZmwzOHZITmZYVjZXNWlobmw3UlpCaWxjMmI5ZXlaZWZjb2NY?= =?utf-8?B?TTBydDdFdlNtbDNPQkUrVkpCa1Fpa0dxeTVlelNuK0tlc01ZVzlpckhoY3dK?= =?utf-8?B?bW52MEpxOHQvNkVxMndsU29Nd2pkekcrSjZzRnJ6aEQrTFdWcFI1REhXT0Mz?= =?utf-8?B?M09rUTZUaXE5VlFwVzFLL1NzZmpuUjQzekQvL2p0SHh3UkxZVjhENVY3NFhn?= =?utf-8?B?RFhPbHZlemh3ektnbDgyeTJLWUhPVVJrUVVaS1ppaFowcWlEU1l1enkrdFVO?= =?utf-8?B?QVl6UGZjTzZzOVhwdzJHcEdKSWlJeEVXWENPUmpxZG5uQ1Mwb25wT0RVUitw?= =?utf-8?B?WGRWSTJaQzJKM0ZlUlIwV256Z0I3Vy9SRVIxeWJvMnE0d25BcVBBa2hvOHFk?= =?utf-8?B?TWtsUldqZDhleTZBNGdxMGxjcUlKMG91b3E5UzNZY0hpZ25ydzRQaWFCd1p1?= =?utf-8?B?eGJ2OHkxUGd5dEtndXNYb0dUemYyMldqVDNwQUVuNlZzMFlhbitVbFRlYmt0?= =?utf-8?B?cnZFVHlsN29vcVRqSkxVaWxwd3lUbjdiUDJQQytnTmdBV2xESHNnSXhld1ht?= =?utf-8?B?RXRMU084UWx1SENHdUc5MEkzNG85V29GRVpMemtnR0Rha0c5K2JNZU1iOGU0?= =?utf-8?B?bHo2OURTeGNCcDExN2NJL0tZQ2xIT2pLVVlrQWEwbVlkMkhORzd1cU5Qbi90?= =?utf-8?B?Sm1oUTRtWHB4amovdDFmUWNBWHNyNHJpa3FYeDB2WE1ldXlXVmY1TmN2UG1s?= =?utf-8?B?UEZPMmFtcG5wSU81TzQ4WU5UVkh1bjdBOTMwREpDRG04WHp2eWJ2N0dPOWpG?= =?utf-8?B?SW9hMEg4SEZ1cmNScjhCR1FTM2V5Q3hRb3hWZE04VG9QNno1N21lcldCaGdx?= =?utf-8?B?aExBMDZ1QUw5c1BIejREbklCTzdjVjFiTW5IRjdPSGFZTEdBYlAxc0ErblNi?= =?utf-8?B?eFhxeXNBUHAxb1VzVHFjVGZOYUZQM3F3VXJNTmQrMlFOR0YzRDhPdlJFU0VE?= =?utf-8?B?ZmMyYWpDOUNYOGoweEt1dUZmVWhBTWhYZFY4RWFjQng5ZW9oUlg1MTNKZ1g1?= =?utf-8?B?L0dpd1RHU3g5OGQxdTFRNTc5OS9zWGs1S3pvRkZiS3ExdUh1eUxXQU5zVkVj?= =?utf-8?B?M0xWcW1pVzBpVU1ERGZ1TXlobXkrRlNjQkFwenlJcWV4VjVoR2NpS0MyVVhk?= =?utf-8?B?RFc2bzdRSFlxMU9kNDZvNzhmZWFmem16VzlUczhsQUtiRjNvYWdzQkxUV0pQ?= =?utf-8?B?NFZBOXAzRC9qWVRWbHdzRk1qV3ZXd2pIbDhlb1duYTY0YlduWEdaQTlEOTRx?= =?utf-8?B?Ty9GUlBoTkhaT00wRHFMZys1c2dyU3hmTGM3b3VQWGVQYWFiQTN1OXZIaWpY?= =?utf-8?B?YU9mQitpOWFiNWZTWHN2YkFVZng4aGtoME5UMFZWNDlLTXJZSTVyOGtwZUlj?= =?utf-8?B?SktEVk1DZUxiYUlUN21tSDdUR1lhRFBjdGdSb0szcGxjUGVwZXFJSXY3NXhj?= =?utf-8?B?MXJuQURVNjZ5Z0hvS1RnN0JTbU1abllzSTJJMWlvNnJMS0xnS1VvNXBXZWN2?= =?utf-8?B?Q0p1cUlpYXNjT3ZhRHpvM3U2WGZVSGRabisxdGZtbGM1RVpnejR1VGtNdUZ4?= =?utf-8?B?T09id2UwTktXd2xDZ1F1LyttZlBPMlU1SVBtV2dUNXUzR0lRN2JvQTF4YkR6?= =?utf-8?B?NnFlN0FtelN2Z1U2amYyMDhiZkVKNDg1NGlybG12VmhGbHorSXZLN3lxZWJR?= =?utf-8?B?a2Rsb0lYaDNtazFIM3dmRlE0eWhEUFprUzlHWEVFRFR6UUNDT25NcFB3Sjdz?= =?utf-8?B?RGR4NmIxL2ZueDhPSEQ5WkVQTzhsdlpaYTJiNkduL3h4T01KTkhEMnJaSER3?= =?utf-8?B?SVViWVlPdThHajBRSDg5Y2FuZXFBWlI4b0doZEZ3ZEtlekpLLzAvU1M0QVBx?= =?utf-8?Q?29rfzAbI1nr1Of16ZjquxYA=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: C891VZgOQtWgENRzCjhXXWsvYmB/tsUuIA92v3iwYB3+IFEmI06q+YrLn5K7kMk3/DSI1jgPq9TJQe21bDUMBAS8FeHd8T8EM/fr9X1K+iirqTPV1qL/swPS1KsvuEPiy6yGSrqNdZGJobMX5K43LrVjZpkdIQIgha6TX/JWmVU2/jXQXQKA7iyE4fyEJNtVdwSWChraRG56S7wBaSuBVL2/PxTfS+d0SdoGxUY082RYrqqGA8r51ECfPM+8pbecVz1lHEMJ/tW8mstV0kBLS4H2pdeJBaLkuptadzhIzivdCbBCM1Zm0IUH/deQ3WCIfVE8rt91Fccpr9z5Xe1eRkZBcexfVItZ34zsp0zV2TX60jXXZJvGLJ+nG6GVw/RDi4bEdQHZmBbIoh2WlutbLll3Lg1nSZwsc7KtIUqqlcI= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b5aeba8-cdd9-4187-3c43-08d6971e46c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 10:29:20.9067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5838 Archived-At: Subject: Re: [netmod] Yang model for setting system startup information for software upgrade 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 Feb 2019 10:29:27 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiU2hpdmEgS3VtYXIgUGF0aG9y aSIgPHBhdGhvcmlAZ21haWwuY29tPg0KVG86IDxuZXRtb2RAaWV0Zi5vcmc+DQpTZW50OiBUdWVz ZGF5LCBGZWJydWFyeSAxOSwgMjAxOSAxOjQwIFBNDQoNCj4gSSB0aGluayB0aGVyZSBpcyBhIG5l ZWQgdG8gZXh0ZW5kIHRoZSBpZXRmLXN5c3RlbS55YW5nIG9yIGhhdmUgbmV3DQptb2RlbCB0bw0K PiBnZXQgdGhlIGN1cnJlbnQgc3lzdGVtIHN0YXJ0dXAgaW5mb3JtYXRpb24obGlrZSBjdXJyZW50 IHN5c3RlbQ0Kc29mdHdhcmUNCj4gbmFtZSwgY29uZmlndXJhdGlvbiBmaWxlIG5hbWUsIHBhZiBm aWxlIG5hbWUgYW5kIHBhdGNoIGZpbGUgbmFtZQ0KZXRjLi4pDQo+IGZyb20gdGhlIGRldmljZSBh bmQgYWxzbyBzZXQgdGhlIG5leHQgc3RhcnR1cCBpbmZvcm1hdGlvbiBmb3IgdXBncmFkZS4NClRo aXMNCj4gY2FuIGhlbHAgdGhlIGRldmljZSBhZG1pbmlzdHJhdG9yIGR1cmluZyBzeXN0ZW0gdXBn cmFkZSBzY2VuYXJpbyB0bw0Kb3BlcmF0ZQ0KPiB3aXRoIHRoZSBZQU5HIG1vZGVsLiBTbyBmaXJz dCBzdGVwIHdpbGwgYmUgY29weWluZyB0aGVzZSBmaWxlcyhpbWFnZSwNCj4gY29uZmlnIGZpbGUs IHBhZiBmaWxlIGFuZCBwYXRjaCBmaWxlKSB0byB0aGUgZGV2aWNlIGFuZCB0aGVuIHNldCB0aGUN Cm5leHQNCj4gc3RhcnR1cCBpbmZvcm1hdGlvbi4gQWZ0ZXIgdGhpcyAgWUFORyBSUEMNCiIvaWV0 Zi1zeXN0ZW0vc3lzdGVtLXJlc3RhcnQiDQo+IGNhbiBiZSB1c2VkIHRvIHJlYm9vdCB0aGUgc3lz dGVtIHRvIHVwZ3JhZGUgdG8gdGhlIG5ldyB2ZXJzaW9uLg0KPg0KPiBJIHJlcXVlc3QgdGhlIFdH IHRvIHByb3ZpZGUgdGhlIG9waW5pb24gb24gdGhpcy4NCg0KU2hpdmENCg0KVGhlIElFVEYgaXMg Z29vZCBhdCBwcm90b2NvbHMsIHdoYXQgbXVzdCBnbyBvbiBiZXR3ZWVuIGJveGVzIG9mDQpkaWZm ZXJlbnQgb3JpZ2lucyBlbHNlIHRoZXkgZG8gbm90IHdvcmsuICBUaGUgaW50ZXJuYWxzIG9mIHRo b3NlIGJveGVzDQpoYXZlIG5vIHN1Y2ggbmVlZCB0byBiZSBzdGFuZGFyZGlzZWQgYW5kIHdoaWxl IHRoZSBJRVRGIGRvZXMgZGVsdmUgaW50bw0KdGhvc2UgYXJlYXMsIGUuZy4gSG9zdCBNSUIgbW9k dWxlIG9yLCBhcmd1YWJseSwgbXVjaCBvZiB0aGUgcm91dGluZyBZQU5HDQptb2R1bGUsIGl0IGlz IGxlc3Mgc3VjY2Vzc2Z1bCBiZWNhdXNlLCB3ZWxsLCB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGVt DQp0byBiZSBzdGFuZGFyZGlzZWQgZm9yIHRoZSBJbnRlcm5ldCB0byB3b3JrLg0KDQpTbywgYSBZ QU5HIG1vZHVsZSBmb3Igc3RhcnR1cCBpbmZvcm1hdGlvbiB3b3VsZCBuZWVkIGZpbmQgY29tbW9u IGdyb3VuZA0KYmV0d2Vlbiwgc2F5LCBpUGhvbmUsIEp1bmlwZXIgcm91dGVyLCBXaW5kb3dzIDEw LCBMaW51eCBkaXN0cm8gYW5kIHNvIG9uDQp3aGVuIHRob3NlIHByb2R1Y3RzIHdvcmsgcXVpdGUg aGFwcGlseSB3aXRoIHJhZGljYWxseSBkaWZmZXJlbnQgdmlld3Mgb2YNCndoYXQgaXMgbmVlZGVk LiAgSSByZWNhbGwgb25lIGRpc2N1c3Npb24gd2hpY2ggZmFpbGVkIHRvIGdldCBhZ3JlZW1lbnQN Cm9uIHdoYXQgdGhlIG9yZGVyIG9mIHByZWNlZGVuY2Ugb2YgdGhlIGZpZWxkcyB2ZXJzaW9uLCBy ZWxlYXNlLCBsZXZlbDsNCmRpZmZlcmVudCBtYW51ZmFjdHVyZXJzIGhhdmUgZGlmZmVyZW50IGlu dGVycHJldGF0aW9ucyB0aGVyZW9mIHdoaWxlIGFueQ0Kb25lIG1hbnVmYWN0dXJlciB3aWxsIGxp a2VseSBiZSBjb25zaXN0ZW50IGluIHRoZWlyIHVzYWdlIGFjcm9zcyBhIHdpZGUNCnJhbmdlIG9m IGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSBwcm9kdWN0cy4NCg0KVGh1cyBpdCBzZWVtcyBtb3JlIGxp a2VseSBhbiBhcmVhIGZvciBwcm9wcmlldGFyeSBleHRlbnNpb25zIHRoYW4gZm9yDQp0aGUgSUVU Ri4NCg0KVG9tIFBldGNoDQoNCj4gUmVnYXJkcywNCj4gU2hpdmENCj4NCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCi0tLS0tLS0tDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KDQo= From nobody Wed Feb 20 14:34:38 2019 Return-Path: <010001690d0bd810-4be66f02-1e04-458d-9cba-d9962a9b2df5-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 2FC0F12D4F0 for ; Wed, 20 Feb 2019 14:34: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, 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 nfV5I3NuaHBQ for ; Wed, 20 Feb 2019 14:34:35 -0800 (PST) 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 6F415129508 for ; Wed, 20 Feb 2019 14:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1550702074; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=VzyJI1xovT5HI+2Mj4qR5YNrD8ZSjeuicb0GssDaGv0=; b=d5QXSj/rWuIheQOvykpeYr6c9axELDdcKVCmUegncLFuvvbBUxd3YqCvF2p6V22c KFm/JOaNvbLwHLbELhmYn4c5H5mkvSXk5ZUc8vGiVh+YcxXVh3SmbRxZ0OEqErDleA3 jCgPOxKusV8U386pXAxK6XwarAUTxO65VRICqVj0= 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: <010001690d0bd810-4be66f02-1e04-458d-9cba-d9962a9b2df5-000000@email.amazonses.com> Date: Wed, 20 Feb 2019 22:34:33 +0000 To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.20-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] Meeting minutes for virtual interim on Feb 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 Feb 2019 22:34:37 -0000 Meeting Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NETMOD Virtual Interim February 20th, 2019 Agenda: The purpose of this meeting was to continue scoring the YANG Next = feature requests. This was NOT a YANG-next planning meeting. The scoring of = the items was/is in preparation for a planning meeting to take place at IETF 104 in Prague. Attendees: - Kent Watsen - Acee Linden - Andy Bierman - Juergen Schoenwaelder - Ladislav Lhotka - Martin Bjorklund - Robert Wilton - Charles Eckel - Lou Berger - Mehmet Ersue Results: Overview of results follows. For details, please see the YANG-next = issue tracker: https://github.com/netmod-wg/yang-next/issues. Start : 17 issues (un-scored)=20 Reviewed : 17 issues Scored: : 12 issues Closed: : 5 issues Remaining : 0 issues An analysis of the results will be presented at the IETF 104 meeting in = Prague. Kent // as co-chair From nobody Wed Feb 20 19:40:51 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 87DBE12DF71; Wed, 20 Feb 2019 19:40:49 -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 Y6VSfGBtAKCC; Wed, 20 Feb 2019 19:40:46 -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 EDA9F128D52; Wed, 20 Feb 2019 19:40:45 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0702980BFECB7ABC597B; Thu, 21 Feb 2019 03:40:44 +0000 (GMT) Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 21 Feb 2019 03:40:43 +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.1591.10; Thu, 21 Feb 2019 03:40:43 +0000 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) 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.1591.10 via Frontend Transport; Thu, 21 Feb 2019 03:40:43 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0415.000; Thu, 21 Feb 2019 11:40:33 +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: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 Thread-Index: AQHUxWBST4whJ9bV6kO/PWNMC6m5PKXk2PSg///uawCABNpQsA== Date: Thu, 21 Feb 2019 03:40:33 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCFD79E@dggeml510-mbx.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> <991B70D8B4112A4699D5C00DDBBF878A6BCFB4AC@dggeml510-mbx.china.huawei.com> In-Reply-To: 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: Re: [netmod] 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: Thu, 21 Feb 2019 03:40:50 -0000 Hi Christian, 2 points are missing from the IANA registry, "Updates to the IETF XML Regis= try" and "Updates to the YANG Module Names Registry", you can refer to RFC = 8342 section 8 for registering the new module and namespace. Also w.r.t "ietf:", whether we can make it "sdo:" and ask ietf modules to s= tart 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.=20 With Regards, Rohit -----Original Message----- From: Christian Hopps [mailto:chopps@chopps.org]=20 Sent: 18 February 2019 14:57 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 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 n= o concept of top-level prefix now. I think this is a remnant of the version= s 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 se= cond part of the prefix is more important for classification because most o= f 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 the= re to avoid collision between the module authors in various SDOs, the modul= e 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 p= olicy "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 sa= ys). > 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 pro= tocol , whether vendor can use "ietf:" tags then ? > I suggest adding one more example in this document which may indicate/cla= rify your stand regarding this point. Again, if you are creating your own module then you can choose whatever tag= s 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 p= art 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-codin= g for this. Whether there should be a note to Yang Compiler Developers in t= his 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 gr= oup 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=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 > > > >> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade wr= ote: >> >> 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. Se= ction 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 a= dded tags are added" can be replaced with "tags of 'system' origin are adde= d" 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=20 >> 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". D= oes 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 specif= ic prefix. > >> 2. In the description of Yang statement "leaf-list tag", is there any re= ason 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 s= pecify an order. > >> 3. Description of statement "leaf-list masked-tag", " This user can remo= ve (mask) tags", I think we need to clarify that it will not "apply" the ta= gs which have been configured as "masked-tags", because they are not "remov= ed" 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=20 >> 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=20 >> with the module." > > I'm not sure about making these changes. I think the current text (with t= he modification below) is pretty clear in what is meant, and delving so dee= ply 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 "S= ystem" 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=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 >> >> 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=20 >> 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 >> From nobody Thu Feb 21 00:24: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 EFDCD12EB11; Thu, 21 Feb 2019 00:24:20 -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 3LC4LhZ_9PJu; Thu, 21 Feb 2019 00:24:18 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D7E5612426A; Thu, 21 Feb 2019 00:24: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 E6F90604E4; Thu, 21 Feb 2019 03:24:16 -0500 (EST) From: Christian Hopps Message-Id: <67C3DBDF-E72A-4495-8FAE-22033004C64B@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F64587C5-4D92-47FB-BC2B-87A7B5A7F6E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 21 Feb 2019 03:24:15 -0500 In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCFD79E@dggeml510-mbx.china.huawei.com> Cc: Christian Hopps , Joel Jaeggli , "ibagdona@gmail.com" , "netmod-chairs@ietf.org" , "iesg-secretary@ietf.org" , "netmod@ietf.org" To: Rohit R Ranade References: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> <991B70D8B4112A4699D5C00DDBBF878A6BCFB4AC@dggeml510-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6BCFD79E@dggeml510-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [netmod] 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: Thu, 21 Feb 2019 08:24:21 -0000 --Apple-Mail=_F64587C5-4D92-47FB-BC2B-87A7B5A7F6E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 20, 2019, at 10:40 PM, Rohit R Ranade = wrote: >=20 > Hi Christian, >=20 > 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. 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 = ; 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 >=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 = versions 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 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. >=20 > 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. >=20 >> 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 ? >=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 = designer 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 = "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. >=20 > Again, if you are creating your own module then you can choose = whatever tags 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 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 ? >=20 > 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. :) >=20 >> 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. >=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 >> ; 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 >>=20 >>=20 >>=20 >>> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade = wrote: >>>=20 >>> 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" >>=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 added" 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 >>> 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 = specific prefix. >>=20 >>> 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. >>=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 = 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." >>=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 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). >>=20 >> 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. >>=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 >>> 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 >>>=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 >>> 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 --Apple-Mail=_F64587C5-4D92-47FB-BC2B-87A7B5A7F6E7 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+m1FHa6lLh2DDte4MCUFAlxuYC8ACgkQLh2DDte4 MCXftg/9F8F5/mrh1zcqARjCOwKfJ+fm2idduPSJg62fjKdTpSE+MVzKQtAhMbbg ilVES7EXZeeJHPEs6/fx9K72mK8rd2IeQcOftTtDvGxUEbFdJk6hGLiWdUi7VwCo x5CBI3y/QstVJoRMkm9VZASM6yIqerv/mF5yiIm7jY109Ybd7OdWl389Z1UUlSdA 3FqnJMvEO97YR+BR5dIUYYawsz1aewRIko4SdObw0/VsEtOrbuAdTBgkJzRiozBX BDNpg+kAW+55NR4tynB1q+wbGMo438g3FMNbEVpHjPWGhopDtY36oaUlHztT+avE fkHy6OOrB7w2Oo48e9/gbgkRDtzlI9gK1t1j0UaP7hHq7iOOdQ3kMmRicmF4udT3 SgYtielpBCSAAU9BbAKe9UQUocQPhWmtMWcft/31N1kPrp1d9KetROqqx4WVGq3P eHI+HDFg18ol+bIu9TPo4RCLd3ZW1+2HEmvkx7NcG3GqSfRWKa6OLdS3KBnqKher 1jkD3mUi6SWNtNYQsLV6eVRcdlGj/kU03ZHLxFKWxycFTZHvdx1AQaZqCY6VSpLs n30R6Xl7WvOXMV4yKzUxzavCk0ZM0k+X5HVUBAoZby6WHHTYEzlgNmSCRMBcFe0b bE4Flb6fjYXwv9tGzCzP/UTrO8bHnuJx0O6DixOUgq7HaNnrsBU= =1W71 -----END PGP SIGNATURE----- --Apple-Mail=_F64587C5-4D92-47FB-BC2B-87A7B5A7F6E7-- From nobody Thu Feb 21 00:44: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 C1698130E69; Thu, 21 Feb 2019 00:44:43 -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 m5N62Hv1grIJ; Thu, 21 Feb 2019 00:44:41 -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 397BE124BF6; Thu, 21 Feb 2019 00:44:41 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 27E64FEC1528AD3D790A; Thu, 21 Feb 2019 08:44:39 +0000 (GMT) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 21 Feb 2019 08:44:38 +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; Thu, 21 Feb 2019 08:44:38 +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; Thu, 21 Feb 2019 08:44:38 +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; Thu, 21 Feb 2019 16:44: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: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 Thread-Index: AQHUxWBST4whJ9bV6kO/PWNMC6m5PKXk2PSg///uawCABNpQsP//yx2AgACK0cA= Date: Thu, 21 Feb 2019 08:44:30 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCFD95B@dggeml510-mbx.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A6BCF6258@dggeml510-mbx.china.huawei.com> <035AC7EA-C09F-450D-91B8-989EC665B70C@chopps.org> <991B70D8B4112A4699D5C00DDBBF878A6BCFB4AC@dggeml510-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6BCFD79E@dggeml510-mbx.china.huawei.com> <67C3DBDF-E72A-4495-8FAE-22033004C64B@chopps.org> In-Reply-To: <67C3DBDF-E72A-4495-8FAE-22033004C64B@chopps.org> 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: Re: [netmod] 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: Thu, 21 Feb 2019 08:44:44 -0000 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 Feb 21 03:00: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 B0CF1130F19; Thu, 21 Feb 2019 03:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 nEoa8hNKzHce; Thu, 21 Feb 2019 03:00:18 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00107.outbound.protection.outlook.com [40.107.0.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3781276D0; Thu, 21 Feb 2019 03:00:17 -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=LuZxVnucQUsQbxUWh0hxKzQcH9CbCnIw3HMa5Kc1z/g=; b=EdSgMs2dWjCJ6e+cq2K+DWbLQTWYqQ/M/tBrulYd7Pv+40jSta5azONhLrXhmgps/08mzPCgLC7/qHts5J5IrVde+X/AvYAnXVkgfKAbrEroGEMYA7FSHQYC+yqMdVRIfPPQqJrNtGVjButAO0SyKJU8ULBcJvFi6rowYxRVnRg= Received: from DB6PR07MB3495.eurprd07.prod.outlook.com (10.170.219.159) by DB6PR07MB3158.eurprd07.prod.outlook.com (10.170.221.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Thu, 21 Feb 2019 11:00:15 +0000 Received: from DB6PR07MB3495.eurprd07.prod.outlook.com ([fe80::b896:de79:6dec:a4eb]) by DB6PR07MB3495.eurprd07.prod.outlook.com ([fe80::b896:de79:6dec:a4eb%5]) with mapi id 15.20.1643.014; Thu, 21 Feb 2019 11:00:15 +0000 From: tom petch To: "ietf@ietf.org" CC: "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: Thu, 21 Feb 2019 11:00:14 +0000 Message-ID: <02d801d4c9d4$615cabe0$4001a8c0@gateway.2wire.net> References: <155046177009.4059.13560986764723643834.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0242.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::14) To DB6PR07MB3495.eurprd07.prod.outlook.com (2603:10a6:6:17::31) 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: ae960b67-c0f2-4e0d-3f2e-08d697ebc1fc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB6PR07MB3158; x-ms-traffictypediagnostic: DB6PR07MB3158: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(376002)(396003)(346002)(13464003)(189003)(199004)(97736004)(9686003)(66066001)(54906003)(2351001)(4326008)(86152003)(316002)(3846002)(5640700003)(2501003)(44736005)(6512007)(44716002)(106356001)(1556002)(6116002)(14496001)(62236002)(6306002)(229853002)(6486002)(105586002)(53936002)(6436002)(4720700003)(25786009)(6916009)(386003)(71200400001)(6246003)(76176011)(52116002)(81686011)(81816011)(6506007)(33896004)(84392002)(186003)(102836004)(61296003)(7736002)(26005)(14454004)(66574012)(486006)(99286004)(966005)(478600001)(5660300002)(81156014)(81166006)(8676002)(476003)(50226002)(446003)(1730700003)(68736007)(86362001)(71190400001)(14444005)(8936002)(305945005)(2906002)(256004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB3158; H:DB6PR07MB3495.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: =?utf-8?B?MTtEQjZQUjA3TUIzMTU4OzIzOjB0c1hVUFdBSisxc3pxcHgvMWpuc0o1Q1cv?= =?utf-8?B?Umx2Z1d0QkphMXZNRVQvU0grV2NTK2JxVlR2SFJ6dlYrQjVRVjRkbTZmMFdw?= =?utf-8?B?U2pKaFhBWTRPZHBEVzNkTDZwek5TTEcrRTlCd1N6aElLNUFZUjNLTXpmWlkr?= =?utf-8?B?Sm5DcXpLdmh1SGRGUnozUzlOTFZaRHI0M29VL2ZldHBSV3RhR3hCVTNmWjcv?= =?utf-8?B?Tjc5TTJJSzZOOFlOT0VwdC9FVEpoRWQ2ZXBXc3lTb3pHbHdvV3FFeDlSd0N6?= =?utf-8?B?S1Z0aFlNV2JwMzlDMXk4N0NpNmpYbEpYTlZYR0hucDk0Wk13K0UwM05qakRT?= =?utf-8?B?SThnU0paMnZRTXFmWm1PeXplT2xhd2kxUVc0UWpvUENtc04rTS94eHRGQ1E3?= =?utf-8?B?SWI3eERwdTAvS3J0cWZpYk5iWDY2ZzNUT2ZhVHJ2Q3ViVndaY3J3djdpc0hJ?= =?utf-8?B?Vy94NXhLUjhyeitLT2pBaFhyRFpjaXpHemZiRFBnaUNhajNyRGk0T3QzVTJH?= =?utf-8?B?MzVlVG15d0xHcWNKbGl0TXQ0dXlNTUZMcDRxUlB2RmY3Qk5wVUQxSVY3Sm9O?= =?utf-8?B?TUoveGFOczlUVTJnbmJ2S3I1VTNuQ1VNYzlEWklyK1NWcHoxdkt0aE1jWk4w?= =?utf-8?B?RXhLOUZadnh1MENzNUgxdUtFcnlicndxNlgwaVRtNStpN09UNTRxeEg1TzVU?= =?utf-8?B?dkx6RlIxUjRYaVUrb1hKdU83K1NKQTBMOEpJaTRDaG5yQlJIRGFGODRlRHpY?= =?utf-8?B?bFkxYy9ZK1dEeEFPS1oxNHBsTnNST1NLeHIrTm14UUV1TlhVS0xtbkpxR0g3?= =?utf-8?B?MHJZeURwOHBRV215a0FUeENacnU2UzR5VHVNeEtLbUV0T1hPcGlRd0F6Z1hU?= =?utf-8?B?eTU4R1ZYN2hpUGF3aURUNEFaRFhCVVZ2U2ZZWjg2VjNPKzdRdUgvZm5jRks0?= =?utf-8?B?OXRJRkFYRThnRG5ISzZZN3ZZNGtXVmJsR1lhRXhTNTNCbVNCUGRYRFFKNWhZ?= =?utf-8?B?WlVzZXZqSWlRQ0g5S0l4clBhTG5LS3ZpVXFlQm1HaFkxNkdPM0NKaVBBTDRQ?= =?utf-8?B?WDVPLzg3MytHUnVHVGJNQlZ2Yk9DUkUzZkttdmw4N2dqQlFjVzVhRzRDK3E3?= =?utf-8?B?d3E1cHBNaTJLU3NEUG04OCtrSGN5dUF5NUpOVVJ2a3FjeXRwUTM5djJhaWJY?= =?utf-8?B?QVNrVnN2Y29Zb1pZT0NSSlVXT1VCYjJUT3ZFc24zN2FldFZzdjJpK0YwL2cr?= =?utf-8?B?My84aEhreWVQRlpON1pzcm84MERaVGdicGRuS1VKWTI4dnpMNmNmWlNjelFX?= =?utf-8?B?QnMyc3JyZnUraUJ3VHVoTmJKaGRBak82cm9xZUxBQnA0c0JMc21QY3ZaVUpF?= =?utf-8?B?WEFqQktsUzh0Q1ZoYXI3cmFtTUhiWjREMDlLdjFLb1c2N212TDNnQWtRT2w4?= =?utf-8?B?aHU1ck1uNWtueWhBNk5oV2RYRXpvSlBtOUJHbm9rMUdJdnRmSk94S2NpdWxS?= =?utf-8?B?NTVwQTJxNHRiQ1pDR1I2MGdOcTJDZWMwd2F1bGhORG5PQklyTVAxcWF3b0Fh?= =?utf-8?B?SGh3NjNMSFUwVVp3KzNDSXV0dWlwT1UxSmFxcWdhUW02ZDc2MHA2c3JrNTA0?= =?utf-8?B?bEJVQStzeDFYTHJTcWZibFYzUEZsM3hzMEowVXFaZXYyQ2VCTVRwcVluOW5K?= =?utf-8?B?cmhMTUlwVVNGakRhbGczU0kzeVhnSS9CTW85NHYzNEFLeDBNaEwxU3k0QjNt?= =?utf-8?B?QVBuRmpJMlFFejdPdXJtamE5R3ZUeUlMcExkOUV1ckx3MXpza3htT1Znc1Ax?= =?utf-8?B?N0JDd2QrbHVMOXoyTGFYMWw3Q3pxc0NORmI0Vkc5TFFmZ213VFZ6UEg2Zmh6?= =?utf-8?B?cmtDLzRWL3NoTHA4WExyK0RaWS9lbWhWU2RRanAybUtOdnIwYk1iQ2tIaDJE?= =?utf-8?B?VG1CWDFYTm5BQStoV3RsNG03UWYxOCt4SW9VcG1ZTUJtSXF4RkZBNWs5OThH?= =?utf-8?B?UVcxWk5UMVY0eTVHOXl1SXlJNWR1QlpaT3NYR1VCYjVmbUFTWktKL3gva3dM?= =?utf-8?B?L1dKUFpiaEI1VDI4MTYwWm1uWXE5c0N1RjFmZXY2V2VpNGhtbFVoSTZPUjBr?= =?utf-8?B?SytzSmt6Y0IzSXJ5YkFVK0J2Q3ZIVnRRaDlwalVlTUIyVk51SGQ5OFBjNzdp?= =?utf-8?B?aVdHbXB6TVZueitML1lGSUVUaDRVNyt3a2hKZWpkRjkzQk1lSjIzN3BYY29s?= =?utf-8?Q?hBcgV1HNLsB32E27ar?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: O/G/Rf36/HIgreODwAyHpKEThlaD0J2V2q/ayVxcBehIiJyx1vJXUvegTQ1gkLORShaxB0NE8dFzK5LOI1V8Kjte+swPxYC/7xZn6ZVPK7It21XRkCIu1of2UgGlFjVy2DBtB72JgqZ2Zi7Gd0oizDbHr9vtdW+Sn0dlQJHlqo7KE43grLceg5oQzI2Uo85JoSf+1csV/Q/Ob4hrq6jz8DHkcRG6oX6ztZYRtHPVfjHE9gAcqrqgNyocPQOoF6VGhheVoblQDeF/VSkGbUmp8S6YE3kizv4Ev4zJvdNPJNmjzYRxBozI0oiCzRslS0v3t0m+NTH2Rr812ALo2KEUkaPt3AashTOQeF61pz3obmI/bwzYxeYrXJGNYZ5IDOphLWJG8q67A9IaJJSB5RpUc8f2yhx2PDhpVfq0VQNbbCE= Content-Type: text/plain; charset="utf-8" Content-ID: <9A4D8B96553E2D44B02BCCD95FB3A6CB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae960b67-c0f2-4e0d-3f2e-08d697ebc1fc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 11:00:14.2543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3158 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: Thu, 21 Feb 2019 11:00:21 -0000 VGhpcyBJLUQgY3JlYXRlcyAgbmV3IHdheSBvZiBzcGVjaWZ5aW5nIG5hbWVzIGZvciBvYmplY3Rz OyB3aHk/DQoNCldlIGhhdmUgc2V2ZXJhbCBleGlzdGluZyB3YXlzLCBzdWNoIGFzIHVybjogKGN1 cnJlbnRseSBiZWluZyB1c2VkIGJ5DQpJUFBNIGZvciBpdHMgcmVnaXN0cnksIGluIGZvcm0gb2Yg dXJuOmlldGY6Li4gKSBhbmQgWUFORyBhbHJlYWR5IG1ha2VzDQpleHRlbnNpdmUgdXNlIG9mIHVy bjogc28gdGhhdCBpcyBwYXJ0IG9mIHRoZSB2b2NhYnVsYXJ5IG9mIFlBTkcgbW9kdWxlcywNCnNv IHdoeSBkbyB3ZSBuZWVkIGEgbmV3IG9uZT8NCg0KQW5kIGZvciBhIG5ldyBvbmUsIHRoZSBzcGVj aWZpY2F0aW9uIHNlZW1zIHZhZ3VlOyBhZ2FpbiwgdXJuIG9yLCBtb3JlDQpnZW5lcmFsbHksIHVy aSBwcm92aWRlcyBhbiBleGFtcGxlIG9mIGhvdyB0byBzcGVjaWZ5IHRoaW5ncy4NCg0KTW9yZSBz cGVjaWZpY2FsbHksDQoNCi0gdGhlIGJvZHkgb2YgdGhlIGRvY3VtZW50IGZhaWxzIHRvIHNwZWNp ZnkgdGhlIHN5bnRheC4gRGVsdmUgaW50byB0aGUNCllBTkcgbW9kdWxlIGFuZCBJIGZpbmQNCiAg ICAgICAgIHBhdHRlcm4gJ1thLXpBLVpfXVthLXpBLVowLTlcLV9dKjpbXFMgXSsnOw0KYnV0IEkg ZXhwZWN0IHNvbWV0aGluZyBpbiB0aGUgYm9keSwgQUJORiBwZXJoYXBzLg0KDQotIHRoYXQgcGF0 dGVybiBhbGxvd3MgYW4gaW5maW5pdGUgZGVwdGggYW5kIGlzIGFjY29tcG5pZWQgYnkNCiAgICAg ICAgIGxlbmd0aCAiMS4ubWF4IjsNCnNvIHdlIGNvdWxkIGhhdmUgdGhvdXNhbmRzIG9mIGNoYXJh Y3RlcnMgYW5kIHRoZSBzdHJ1Y3R1cmUgc2VlbXMgdG8gYmUgYQ0KdHJlZSB5ZXQgdGhlIEktRCBm YWlscyB0byBzcGVjaWZ5IGhvdyB0aGUgdHJlZSBpcyB1c2VkLCB3aG8gY2FuIGNyZWF0ZQ0Kd2hh dCB3aGVyZS4gQ2FuIEksIG9yIHNvbWVvbmUgZWxzZSwgY3JlYXRlDQppZXRmOmhhcmR3YXJlOmNp c2NvOnJvdXRlcjoyNTEzOnRybg0KV2VsbCwgdGhlIEktRCBzYXlzDQoiICAgTm8gZnVydGhlciBz dHJ1Y3R1cmUgaXMgaW1wb3NlZCBieSB0aGlzIGRvY3VtZW50IG9uIHRoZSB2YWx1ZSINCnNvIHRo ZSBhbnN3ZXIgaXMgeWVzOiBub3QgYSBnb29kIHdheSB0byBzdGFydCBJTUhPIC0gYmV0dGVyIHRv IHN0YXJ0DQpzbWFsbCBhbmQgZXhwYW5kIGFzIG5lZWRzIGFyaXNlLiAgVGhlIEktRCBjaXRlcyAj aGFzaHRhZ3MgYXMgcGFydCBvZiBpdHMNCmp1c3RpZmljYXRpb247IGZvciBtZSwgdGhlIG9wcG9z aXRlIGlzIHRydWUsIHdoZXJlIHN0YW5kYXJkcyB3b3JrIGlzDQpjb25jZXJuZWQuDQoNCkluIHRo ZSBzYW1lIHZlaW4sDQoiSWYgdGhlIG1vZHVsZSBkZWZpbml0aW9uIGlzIElFVEYgc3RhbmRhcmRz IHRyYWNrLCB0aGUgdGFncyBNVVNUIGFsc28gYmUNCklFVEYgc3RhbmRhcmQgdGFncyINCmJ1dCBJ IHNlZSBub3RoaW5nIHRvIHN0b3AgcHJvcHJpZXRhcnkgbW9kdWxlcyB1c2luZyBpZXRmOiB0YWdz Lg0KDQotIENSIE5MIHRhYiBhcmUgZXhjbHVkZWQgYnV0IHR5cGUgc3RyaW5nIGFsbG93cw0KYW55 IFVuaWNvZGUgb3IgSVNPL0lFQyAxMDY0NiBjaGFyYWN0ZXINCnNvIHNjb3BlIHRoZXJlIGZvciBp MThuDQoNCi0gdGhlcmUgaXMgd29yayBmb3IgSUFOQSBidXQgdGhlIEktRCByZWZlcmVuY2VzIHRo ZSBvYnNvbGV0ZSBSRkM1MjI2IGFuZA0Kc28sIGUuZy4sIGZhaWxzIHRvIHNwZWNpZnkgYSBHcm91 cCBuYW1lICh3aGljaCBJIGZpbmQgbWFrZXMgdGhlDQpkaWZmZXJlbmNlIGJldHdlZW4gYmVpbmcg YWJsZSB0byBmaW5kIHNvbWV0aGluZyByZWFkaWx5IG9uIHRoZSBJQU5BDQp3ZWJzaXRlIGFuZCBu b3QpLg0KDQotICIgICBPdGhlciBTRE9zIChzdGFuZGFyZCBvcmdhbml6YXRpb25zKSB3aXNoaW5n IHRvIHN0YW5kYXJkaXplIHRoZWlyDQpvd24NCiAgIHNldCBvZiB0YWdzIGNvdWxkIGFsbG9jYXRl IGEgdG9wIGxldmVsIHByZWZpeCBmcm9tIHRoaXMgcmVnaXN0cnkuIg0KSG93PyAgRG9jdW1lbnRz IGxpa2UgdGhvc2Ugb24gVVJJIGdpdmUgZ3VpZGVsaW5lcywgYW4gZS1tYWlsIHRvIElBTkENCnBl cmhhcHMuDQoNCi0gICAiVGhlIGFsbG9jYXRpb24gcG9saWN5IGZvciB0aGlzIHJlZ2lzdHJ5IGlz IFNwZWNpZmljYXRpb24gUmVxdWlyZWQiDQpTbyB3aGF0IHNob3VsZCBhIERlc2lnbmF0ZWQgRXhw ZXJ0IGxvb2sgZm9yPyAgSXQgaXMgY3VzdG9tYXJ5IGZvciBhbiBJLUQNCnRvIGdpdmUgZ3VpZGFu Y2UsIGlmIG9ubHkgdG8gdGhlIElFU0cgd2hvIGhhdmUgdG8gYXBwb2ludCB0aGUgZXhwZXJ0Lg0K DQpUaGVuIHRoZXJlIGFyZSBhIG51bWJlciBvZiBnbGl0Y2hlcy4NCg0KVGhlIEFic3RyYWN0IGNv bnRhaW5zDQogdGhpcyBkb2N1bWVudCB1cGRhdGVzIFtSRkM4NDA3XS4NCndoaWNoIGxvb2tzIGxp a2UgYSByZWZlcmVuY2UsIG5vdCBhbGxvd2VkIGluIEFic3RyYWN0DQoNClRoZSBZQU5HIG1vZHVs ZSBjb250YWlucw0KIiAgICAgIGRlc2NyaWJlZCBpbiBCQ1AgMTQgW1JGQzIxMTldIFtSRkM4MTc0 XSAiDQp3aGljaCBhZ2FpbiBsb29rcyBsaWtlIGEgcmVmZXJlbmNlIHdoZXJlYXMgWUFORyBtb2R1 bGVzIG11c3QgYmUgcGxhaW4NCnRleHQuDQoNCkNvcHlyaWdodCBpcyAyMDE4DQoNCllBTkcgbW9k dWxlIGltcG9ydCBzdGF0ZW1lbnQgbGFja3MgYSByZWZlcmVuY2Ugc3RhdGVtZW50DQoNClRoZSBJ LUQgY29udGFpbnMgYW4gdXBkYXRlIHRvIFJGQzg0MDcgd2hpY2ggc2F5cw0KIlRoZSBtb2R1bGUg d3JpdGVyIGNhbiB1c2UgZXhpc3Rpbmcgc3RhbmRhcmQgdGFncyINClRoZSBwaHJhc2UgIm1vZHVs ZSB3cml0ZXIiIGlzIG5vdCB1c2VkIGJ5IFJGQzg0MDcuDQoNClRvbSBQZXRjaA0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiVGhlIElFU0ciIDxpZXNnLXNlY3JldGFyeUBp ZXRmLm9yZz4NClRvOiAiSUVURi1Bbm5vdW5jZSIgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQpD YzogPGliYWdkb25hQGdtYWlsLmNvbT47IDxuZXRtb2QtY2hhaXJzQGlldGYub3JnPjsgIkpvZWwg SmFlZ2dsaSINCjxqb2VsamFAZ21haWwuY29tPjsgPGRyYWZ0LWlldGYtbmV0bW9kLW1vZHVsZS10 YWdzQGlldGYub3JnPjsNCjxuZXRtb2RAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5 IDE4LCAyMDE5IDM6NDkgQU0NClN1YmplY3Q6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtbmV0bW9k LW1vZHVsZS10YWdzLTA1LnR4dD4gKFlBTkcgTW9kdWxlDQpUYWdzKSB0byBQcm9wb3NlZCBTdGFu ZGFyZA0KDQoNCj4NCj4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBO ZXR3b3JrIE1vZGVsaW5nIFdHIChuZXRtb2QpDQp0bw0KPiBjb25zaWRlciB0aGUgZm9sbG93aW5n IGRvY3VtZW50OiAtICdZQU5HIE1vZHVsZSBUYWdzJw0KPiAgIDxkcmFmdC1pZXRmLW5ldG1vZC1t b2R1bGUtdGFncy0wNS50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+IFRoZSBJRVNHIHBs YW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0 cw0KZmluYWwNCj4gY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50 aXZlIGNvbW1lbnRzIHRvIHRoZQ0KPiBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAx OS0wMy0wMy4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5DQpiZQ0KPiBzZW50IHRvIGllc2dA aWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQpiZWdp bm5pbmcgb2YNCj4gdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4N Cj4NCj4gQWJzdHJhY3QNCj4NCj4NCj4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBmb3IgdGhl IGFzc29jaWF0aW9uIG9mIHRhZ3Mgd2l0aCBZQU5HDQptb2R1bGVzLg0KPiAgICBUaGUgZXhwZWN0 YXRpb24gaXMgZm9yIHN1Y2ggdGFncyB0byBiZSB1c2VkIHRvIGhlbHAgY2xhc3NpZnkgYW5kDQo+ ICAgIG9yZ2FuaXplIG1vZHVsZXMuICBBIG1ldGhvZCBmb3IgZGVmaW5pbmcsIHJlYWRpbmcgYW5k IHdyaXRpbmcgYQ0KPiAgICBtb2R1bGVzIHRhZ3MgaXMgcHJvdmlkZWQuICBUYWdzIG1heSBiZSBz dGFuZGFyZGl6ZWQgYW5kIGFzc2lnbmVkDQo+ICAgIGR1cmluZyBtb2R1bGUgZGVmaW5pdGlvbjsg YXNzaWduZWQgYnkgaW1wbGVtZW50YXRpb25zOyBvcg0KZHluYW1pY2FsbHkNCj4gICAgZGVmaW5l ZCBhbmQgc2V0IGJ5IHVzZXJzLiAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBndWlkYW5jZSB0bw0K ZnV0dXJlDQo+ICAgIG1vZGVsIHdyaXRlcnMgYW5kLCBhcyBzdWNoLCB0aGlzIGRvY3VtZW50IHVw ZGF0ZXMgW1JGQzg0MDddLg0KPg0KPg0KPg0KPg0KPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQg dmlhDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9k LW1vZHVsZS10YWdzLw0KPg0KPiBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLW1vZHVs ZS10YWdzL2JhbGxvdC8NCj4NCj4NCj4gTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3Vi bWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KPg0KPg0KPg0KPg0KDQo= From nobody Thu Feb 21 03:39:02 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 4745F130F86; Thu, 21 Feb 2019 03:39:00 -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 zWjEmXeEHu78; Thu, 21 Feb 2019 03:38:57 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6D130F85; Thu, 21 Feb 2019 03:38:57 -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 D85D0604E7; Thu, 21 Feb 2019 06:38:56 -0500 (EST) References: <155046177009.4059.13560986764723643834.idtracker@ietfa.amsl.com> <02d801d4c9d4$615cabe0$4001a8c0@gateway.2wire.net> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: tom petch Cc: "ietf\@ietf.org" , "ibagdona\@gmail.com" , "netmod-chairs\@ietf.org" , Joel Jaeggli , "draft-ietf-netmod-module-tags\@ietf.org" , "netmod\@ietf.org" In-reply-to: <02d801d4c9d4$615cabe0$4001a8c0@gateway.2wire.net> Date: Thu, 21 Feb 2019 06:38:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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: Thu, 21 Feb 2019 11:39:00 -0000 --=-=-= Content-Type: text/plain; format=flowed 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 >> >> >> 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 provides guidance to > future >> model writers and, as such, this document updates [RFC8407]. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxujdAACgkQLh2DDte4 MCVLGw/+OtA1mw8ibPPbJBCgAvey4aPCyE6oxNNozNPn8UZ6CJKjADKTQ7PFOcY+ iylUp2Nlt2Iv9oAeW0k11K69W5PsoNMXGMn7ysyDguQdvzd3x7lRUUk5LCUhp4xz bj7MFHhUAwTB5bfXC66VcWt+eHUVqcJO5c0EnFlN9Uy6hkVBZ1UNY0tmySmFEkKk jyaa9lRsW/BE3ZDPMbYqaiEYkIiiO9TBItkkll/hSjr2kMiiTlWTqFb3lOhaqrFm cm/QcrnZHof7ao7/5NJNYZFXaMStQJpIJVMVEuoQi+hV1fEL5+HvPXnAPtYHzXYC Pxwsf8SXEztouOPvz/rFnfcJVkmgX33sFrVrP6EcG3Tg3zF35YB4mqkWYTow6+dc j9gVqY4urQh0NffM0TNJk1QUsFIvtCVQ9GpZe6Yn/ZUaZFfiHaqj9kmo/K0uXkux siNJQMn5prQYGQUFx63cg8F38QamB4XG85di7nn0lPIRUtEUWV0uS4tzM267L+CM G8juD9gTBdg2T4EZOyY4l1YAMQLz4puv9FdhzyTEFrgKvpqth7s+OiFE137tHAUz tKB5ririocUDJ5LxsMeQ7OyYZnnvJtkfp+Ipykpb+og3/DY+a7FoXdABA0AW8fdB qtBo5YvuipdavDbA1UBbg7HrV2J2o414BcZnOO5R4Gg4ByNtyL0= =O88B -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 21 04:05: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 4E872130FAC; Thu, 21 Feb 2019 04:05:08 -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 NtWg309N6Ijj; Thu, 21 Feb 2019 04:05:06 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id EBA79130F9D; Thu, 21 Feb 2019 04:05:05 -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 0C33C604E7; Thu, 21 Feb 2019 07:05:05 -0500 (EST) References: <155046177009.4059.13560986764723643834.idtracker@ietfa.amsl.com> <02d801d4c9d4$615cabe0$4001a8c0@gateway.2wire.net> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: tom petch Cc: "ietf\@ietf.org" , "ibagdona\@gmail.com" , "netmod-chairs\@ietf.org" , Joel Jaeggli , "draft-ietf-netmod-module-tags\@ietf.org" , "netmod\@ietf.org" In-reply-to: Date: Thu, 21 Feb 2019 07:05:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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: Thu, 21 Feb 2019 12:05:09 -0000 --=-=-= Content-Type: text/plain; format=flowed 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 >>> >>> >>> 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 provides guidance to >> future >>> model writers and, as such, this document updates [RFC8407]. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlxuk/AACgkQLh2DDte4 MCXSQA/+NPiPVm7JzTePMMurnVxGinaXX+i+SPvhU4zzT++cWrh2BETS362nFqrI 4xwjt0oh4wzEUhWqTMlsUC2DxH7CGlufZnytOp904XO/modN2c06fBbbxjnS6uyg 3yGBY7AYAuBGgOy1Zc7JjHzVXh0T/sdexb8ZrboBUK2h+BbpdFgx0fuLflEvio7l UHBGGZUWhcpEzDEb2b1d8uu8hl24v6HkrXFLvNAY2pxbHAs+9FWjSMu5W2gbENDq nu8PSdGkDvPJ4q4ZQ5pxz9lnI01b+whL3OZb1FgiVP8xw6+Td8iU43cNU4nZL4Gb P+q0GJNuLYermSvoyoP0HiqNoUdBNyM8hWgXnrTTPOI4vGifgsYZHva+gyB2T1wC 8vAGMiGsH7m2iOkNrpmPKrUwqd7kSvIY5RqQI5rE9j5BRfK3ERCDE4n7c9QqHSjQ S5m1rQg2O9uQt0yfEU6Mc7hxqypntxpll/zyGMLyCVero5wWARo+T0QBW6oA78QM //1nGun7lO3plnb1EljRPwilCao90JA3u1zTp6RQ56g59fz+cYUQaPhh2NsOsku+ Ay2Kv47OCPjg1l4279qfe/OfBF6OYlRrEUi5/S/2qWsccA52aYhfXSkN1kF1lKdZ LP5ELxL83qJfXvmW6cwFv9Yw7dnY+WsJv9XgWWwoT5hJmXB+YpU= =bIn0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 21 08:39: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 F2ED41228B7 for ; Thu, 21 Feb 2019 08:39:36 -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 cEu60XxuDd8E for ; Thu, 21 Feb 2019 08:39:35 -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 3E9F3130E2B for ; Thu, 21 Feb 2019 08:39:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5196EB81AF4; Thu, 21 Feb 2019 08:39:19 -0800 (PST) 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: peter.loborg@ericsson.com, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190221163919.5196EB81AF4@rfc-editor.org> Date: Thu, 21 Feb 2019 08:39:19 -0800 (PST) Archived-At: Subject: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 16:39:37 -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/eid5642 -------------------------------------- Type: Editorial Reported by: Peter Loborg Section: 9.6.4 Original Text ------------- It takes as an argument a string that is the assigned name. Corrected Text -------------- It takes as an argument an unquoted string that is the assigned name. Notes ----- Readers are not beeing made aware that careful reading of section 6.1.3 and the detailed definition of string in section 14 must be consulted. For comming versions of this RFC it would be preferable to use a more specialized grammar token for these cases (e.g. unquoted-string). 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 Thu Feb 21 08:53: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 F00EB130DEF for ; Thu, 21 Feb 2019 08:53: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 z4q9nsVSjPYv for ; Thu, 21 Feb 2019 08:53:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95A5C128B01 for ; Thu, 21 Feb 2019 08:53:39 -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 CD05E1AE00A0; Thu, 21 Feb 2019 17:53:36 +0100 (CET) Date: Thu, 21 Feb 2019 17:53:36 +0100 (CET) Message-Id: <20190221.175336.1995849216024607593.mbj@tail-f.com> To: rfc-editor@rfc-editor.org Cc: ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net, peter.loborg@ericsson.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20190221163919.5196EB81AF4@rfc-editor.org> References: <20190221163919.5196EB81AF4@rfc-editor.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] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 16:53:42 -0000 RFC Errata System wrote: > 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/eid5642 > > -------------------------------------- > Type: Editorial > Reported by: Peter Loborg > > Section: 9.6.4 > > Original Text > ------------- > It takes as an argument a string that is the assigned name. > > Corrected Text > -------------- > It takes as an argument an unquoted string that is the assigned name. This is not correct. The enum argument is not different from any other keyword's arguments in YANG. See e.g. the example in 9.12.4: type enumeration { enum "unbounded"; } The following is also legal: enum "unb" + 'ounded'; This errata should be rejected. /martin > > Notes > ----- > Readers are not beeing made aware that careful reading of section 6.1.3 and the detailed definition of string in section 14 must be consulted. > For comming versions of this RFC it would be preferable to use a more specialized grammar token for these cases (e.g. unquoted-string). > > 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 Thu Feb 21 09:01: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 426AF130DEF for ; Thu, 21 Feb 2019 09:01:38 -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 AT_yMvnqXLPQ for ; Thu, 21 Feb 2019 09:01:30 -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 863D61200D7 for ; Thu, 21 Feb 2019 09:01:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9399077B; Thu, 21 Feb 2019 18:01:28 +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 jAB7jQQ6GA8i; Thu, 21 Feb 2019 18:01:28 +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, 21 Feb 2019 18:01:28 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72D822005D; Thu, 21 Feb 2019 18:01:28 +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 ssjc-pApjr2K; Thu, 21 Feb 2019 18:01:28 +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 036E420058; Thu, 21 Feb 2019 18:01:28 +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, 21 Feb 2019 18:01:27 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 33AEE30069A648; Thu, 21 Feb 2019 18:01:26 +0100 (CET) Date: Thu, 21 Feb 2019 18:01:26 +0100 From: Juergen Schoenwaelder To: CC: Message-ID: <20190221170126.2kv5vxhvbsycvwxf@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: peter.loborg@ericsson.com, netmod@ietf.org References: <20190221163919.5196EB81AF4@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190221163919.5196EB81AF4@rfc-editor.org> 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] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 17:01:38 -0000 What makes you believe enum "foo" is illegal? /js On Thu, Feb 21, 2019 at 08:39:19AM -0800, RFC Errata System wrote: > 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/eid5642 > > -------------------------------------- > Type: Editorial > Reported by: Peter Loborg > > Section: 9.6.4 > > Original Text > ------------- > It takes as an argument a string that is the assigned name. > > Corrected Text > -------------- > It takes as an argument an unquoted string that is the assigned name. > > Notes > ----- > Readers are not beeing made aware that careful reading of section 6.1.3 and the detailed definition of string in section 14 must be consulted. > For comming versions of this RFC it would be preferable to use a more specialized grammar token for these cases (e.g. unquoted-string). > > 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 21 09:51: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 7DFF213100F for ; Thu, 21 Feb 2019 09:51:05 -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 jQ_JXOXIoOn8 for ; Thu, 21 Feb 2019 09:51:00 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12F5131070 for ; Thu, 21 Feb 2019 09:45:45 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id j13-v6so24786820ljc.2 for ; Thu, 21 Feb 2019 09:45:45 -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=WVOOeMM+alrieZNiSGjh+HKZ90eoqCx+u6uyexjkVQo=; b=muVca6bkjYtGs+FWN7p+EnsaN9kK2zdAFhQ1CYg/OdGF4nCPjHj9rt9TV7JpR+hbU7 x+/d+zG39D0RnLEx7mGvWTc50T4n/Cr3KivG6tLT4CbWvycgiDNDNRCv9mO9hK0PFJwp LC4aVjNJyK+IgULd5A4sFKEcApcAYPlHeEvBZ9gF5biaW3+cqcd8HzVEmlLrORXD6Ru4 LcrCytqBT1ghilpVXvBbW5/eAVlHadDwRswZoY46ynYcdEBm7mBFx4jTB0Czmg3CfR7g JhMC8MK++948LZm6E0N+lAd1hEYaDZej24fIyaDnwMeRf/NBCHMAsbjCEuQQd0++GAB3 eRKg== 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=WVOOeMM+alrieZNiSGjh+HKZ90eoqCx+u6uyexjkVQo=; b=EVvKycpFmSxc5DsCEQHeyoZv9rE8Ep4ji7u0KNYQUL76y6VKZqmvEgCVSFk71iNFVt 5z2AJOkBzm3ayrtlOS80Me3/GIcwlsHnNy9MHhpOhz6N81FNIXVxz5ysZ0cbOkjhodLC CvX9CGjRZ3Tury31FEsVmg3wUY0gezdyDXEMIHk+s3aQtpPq+pZMDkpoUZ5iqwFJOQwk grHKHLfq+9b7WupBoNBhgDN2FsBvliaxk1UXt5VEDOXZcFB9gfrg4UDUbVfG7dMuU8pS tGA+X8NbpVgQoCQaEnMVaPY9oMVomrJkgHOysIIaniUR+08U0z8kY+huop+60Y3UEX35 OmyQ== X-Gm-Message-State: AHQUAuaFb/LLiFlfOeX84KTzDp4YYuS95zFOj2OrEVY1X0QgMCgm9yHC G9YLr5Dw5iGaA3GeI6r29wk9riW7C1ZmAB5wIhwUsg== X-Google-Smtp-Source: AHgI3IZJvT/M/ZA56XgJO44ukIugRAY8zVCqnzG2FnnYrlYkFE7GATQ9PiaP9HLoTcwyQ/yEmQRoY2D5TUHa2SSM0X8= X-Received: by 2002:a2e:711b:: with SMTP id m27mr19376936ljc.141.1550771139835; Thu, 21 Feb 2019 09:45:39 -0800 (PST) MIME-Version: 1.0 References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> In-Reply-To: <20190221.175336.1995849216024607593.mbj@tail-f.com> From: Andy Bierman Date: Thu, 21 Feb 2019 09:45:22 -0800 Message-ID: To: Martin Bjorklund Cc: RFC Editor , Ignas Bagdonas , NetMod WG , peter.loborg@ericsson.com, Warren Kumari Content-Type: multipart/alternative; boundary="000000000000eb165505826b0a9b" Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 17:51:06 -0000 --000000000000eb165505826b0a9b Content-Type: text/plain; charset="UTF-8" On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund wrote: > RFC Errata System wrote: > > 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/eid5642 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Peter Loborg > > > > Section: 9.6.4 > > > > Original Text > > ------------- > > It takes as an argument a string that is the assigned name. > > > > Corrected Text > > -------------- > > It takes as an argument an unquoted string that is the assigned name. > > This is not correct. The enum argument is not different from any > other keyword's arguments in YANG. See e.g. the example in 9.12.4: > > type enumeration { > enum "unbounded"; > } > > The following is also legal: > > enum "unb" + 'ounded'; > > > enum "This is also legal"; 9.6.4. The "enum" Statement The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string that is the assigned name. *The string MUST NOT be zero-length and MUST NOT have any leading or trailing whitespace characters* (any Unicode character with the "White_Space" property). The use of Unicode control codes SHOULD be avoided. > This errata should be rejected. > > > > /martin > > Andy > > > > > Notes > > ----- > > Readers are not beeing made aware that careful reading of section 6.1.3 > and the detailed definition of string in section 14 must be consulted. > > For comming versions of this RFC it would be preferable to use a more > specialized grammar token for these cases (e.g. unquoted-string). > > > > 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 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000eb165505826b0a9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 21, 2019 at 8:53 AM Marti= n Bjorklund <mbj@tail-f.com> wr= ote:
RFC Errata = System <r= fc-editor@rfc-editor.org> wrote:
> 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/eid5642
>
> --------------------------------------
> Type: Editorial
> Reported by: Peter Loborg <peter.loborg@ericsson.com>
>
> Section: 9.6.4
>
> Original Text
> -------------
> It takes as an argument a string that is the assigned name.
>
> Corrected Text
> --------------
> It takes as an argument an unquoted string that is the assigned name.<= br>
This is not correct.=C2=A0 The enum argument is not different from any
other keyword's arguments in YANG.=C2=A0 See e.g. the example in 9.12.4= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unbounded";
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

The following is also legal:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unb" + 'ounded';<= br>



=C2=A0 enum "This = is also legal";

9.6.4.  The "enum" Statement

   The "enum" statement, which is a substatement to the "typ=
e"
   statement, MUST be present if the type is "enumeration".  It i=
s
   repeatedly used to specify each assigned name of an enumeration type.
   It takes as an argument a string that is the assigned name.  The
   string MUST NOT be zero-length and MUST NOT have any leading or
   trailing whitespace characters (any Unicode character with the
   "White_Space" property).  The use of Unicode control codes SHO=
ULD be
   avoided.

=C2=A0
This errata should be rejected.



/martin



Andy
=C2=A0

>
> Notes
> -----
> Readers are not beeing made aware that careful reading of section 6.1.= 3 and the detailed definition of string in section 14 must be consulted. > For comming versions of this RFC it would be preferable to use a more = specialized grammar token for these cases (e.g. unquoted-string).
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The YANG= 1.1 Data Modeling Language
> Publication Date=C2=A0 =C2=A0 : August 2016
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjorklund, Ed.<= br> > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Model= ing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000eb165505826b0a9b-- From nobody Thu Feb 21 10:15: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 2CEFA1310A2 for ; Thu, 21 Feb 2019 10:15:03 -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 h40EyehA814F for ; Thu, 21 Feb 2019 10:14:59 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3774913109F for ; Thu, 21 Feb 2019 10:14:59 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id m11so21061501lfc.6 for ; Thu, 21 Feb 2019 10:14:59 -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=ERqw5PUaPC0sUS6Nv8ner+sgcDXSPdoqLj3hMBW2ATM=; b=S+Cplxwy1Ay3MpXtK57kky/43WHYl1TK9NiaRxao8LPrX1RCBVvHEMoA5wCKm7g9qY Unta6vtmtuCtxVLTttRaEw0I38dgpfm265NusiZ/TLTVJVzoGswkA5Avik1eY95CXzmd NAcwIwPeohZj6QiU4o5InBpuORP/8hgefXeh8asni55DM54OXZLz14laWHXrB5OGAUit QTAz1xkGOKzmnfJiznEGO6wt8QdGaE8JgrEG4uL2Z5xwhSzAMwRDXTXdeaPSDGOgcjbK IcRRFMNR4EDl9RBtBubpZnu5/+LhHDML64KqZRskfNS2oZnf7ZEb225c1ZRpccv7FsBK jkTw== 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=ERqw5PUaPC0sUS6Nv8ner+sgcDXSPdoqLj3hMBW2ATM=; b=fGoQKeCYyNHhqhh6UcqiXoaU7rtUEkivyHg1YUZ5TPl7I4z4kTjIUhXe/1x8eqTTLo uCKiOKCtKmoYE3bAfYxuNPpYnEFTBywhO8iPV9LQjSvPY07L2aOC49eBgy4BxzfW7Vq0 9YoejggZLKKff0zjPY2wXEjDS+dEqjni5MoKaM3wNLCDR8M8hmPD1ypeWiIN5I/+63dF rBocwcxpBLDxhiCG92CWF6xzVTia5OstxnJ16/Qy9ZuMR+SxQFQ9kgtiS660hgdOMc2h CxqhcUmoGBxkI+GfzWEbkOcHnp8ZdjNvJLp+1IJmO9CKo/BtuN/DlVAA0nReUkSV3rew Qq/g== X-Gm-Message-State: AHQUAub9JQwc6BP4A9NIkHJ8WSWQLxSE+sj+hp8gq7emDKptFHiA48+/ AetkvuI7+NQi6VrFPHMdpFSFq0RJCoDv8rGGiphsWw== X-Google-Smtp-Source: AHgI3Iaadk2lAaS38/4NTpaTvV4kIEEMT3Pmb+g40lfK42OvMx2VWhBXy48zISk7Az7uB1eeJEhLhJR3776fHZH2Ax8= X-Received: by 2002:ac2:5489:: with SMTP id t9mr23899636lfk.49.1550772896787; Thu, 21 Feb 2019 10:14:56 -0800 (PST) MIME-Version: 1.0 References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> In-Reply-To: From: Andy Bierman Date: Thu, 21 Feb 2019 10:14:45 -0800 Message-ID: To: Peter Loborg Cc: Martin Bjorklund , RFC Editor , Ignas Bagdonas , NetMod WG , Warren Kumari Content-Type: multipart/alternative; boundary="000000000000a4210805826b7364" Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 18:15:03 -0000 --000000000000a4210805826b7364 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg wrote: > > > Your example is fine =E2=80=93 but the gammar is ch14 specifies something > different: > > > > enum-stmt =3D enum-keyword sep string optsep > > (";" / > > "{" stmtsep > > ;; these stmts can appear in any order > > *if-feature-stmt > > [value-stmt] > > [status-stmt] > > [description-stmt] > > [reference-stmt] > > "}") stmtsep > > > > It clearly states string, not quoted-string. These two have the followin= g > rules: > > > > quoted-string =3D (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) > > > > string =3D < an unquoted string, as returned by > > > < the scanner, that matches the rule > > > < yang-string > > > > The text in 9.6.4 is correct. The ABNF is wrong. > =E2=80=A6and in 6.1.3 we can read that: > > An unquoted string is any sequence of characters that does not > > contain any space, tab, carriage return, or line feed characters, a > > single or double quote character, a semicolon (";"), braces ("{" or > > "}"), or comment sequences ("//", "/*", or "*/"). > > > > Note that any keyword can legally appear as an unquoted string. > > > > Since the section so clearly writes about single quoted strings and doubl= e > quoted strings, there can unfortunately be no interpretation that would > allow =E2=80=9Cidentifier=E2=80=9D to be called an unquoted string =E2=80= =93 even though it follows > the rules about limited character contents. > > > > Hence =E2=80=93 this is not a matter of opinion =E2=80=93 it=E2=80=99s a = matter of reading what=E2=80=99s > actually written in the RFC. > > > > But on the subject of opinion=E2=80=A6 > > > > enum "This is also legal"; // should definitely always be illegal > > > > =E2=80=A6as we cannot create a language binding to enum constructs in any= major > programming languages. > > > There are many aspects of YANG that do not map directly to programming languages, such as allowing '.' in identifiers. > Br, > > Peter > Andy > > > > > *From:* Andy Bierman > *Sent:* den 21 februari 2019 18:45 > *To:* Martin Bjorklund > *Cc:* RFC Editor ; Ignas Bagdonas < > ibagdona@gmail.com>; NetMod WG ; Peter Loborg < > peter.loborg@ericsson.com>; Warren Kumari > *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) > > > > > > > > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund wrote: > > RFC Errata System wrote: > > 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/eid5642 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Peter Loborg > > > > Section: 9.6.4 > > > > Original Text > > ------------- > > It takes as an argument a string that is the assigned name. > > > > Corrected Text > > -------------- > > It takes as an argument an unquoted string that is the assigned name. > > This is not correct. The enum argument is not different from any > other keyword's arguments in YANG. See e.g. the example in 9.12.4: > > type enumeration { > enum "unbounded"; > } > > The following is also legal: > > enum "unb" + 'ounded'; > > > > > > enum "This is also legal"; > > > > 9.6.4. The "enum" Statement > > > > The "enum" statement, which is a substatement to the "type" > > statement, MUST be present if the type is "enumeration". It is > > repeatedly used to specify each assigned name of an enumeration type. > > It takes as an argument a string that is the assigned name. *The* > > * string MUST NOT be zero-length and MUST NOT have any leading or* > > * trailing whitespace characters* (any Unicode character with the > > "White_Space" property). The use of Unicode control codes SHOULD be > > avoided. > > > > > > This errata should be rejected. > > > > /martin > > > > > > Andy > > > > > > > > Notes > > ----- > > Readers are not beeing made aware that careful reading of section 6.1.3 > and the detailed definition of string in section 14 must be consulted. > > For comming versions of this RFC it would be preferable to use a more > specialized grammar token for these cases (e.g. unquoted-string). > > > > 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 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --000000000000a4210805826b7364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 21, 2019 at 10:07 AM Pete= r Loborg <peter.loborg@eric= sson.com> wrote:

=C2=A0

Your example is fine =E2=80=93 = but the gammar is ch14 specifies something different:<= /p>

=C2=A0

enum-stmt=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D enum-keyword sep string optsep<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (";" /<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "{" stmtsep<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; these= stmts can appear in any order

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *if-feat= ure-stmt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [value-s= tmt]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [status-= stmt]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [descrip= tion-stmt]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [referen= ce-stmt]

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"}") stmtsep

=C2=A0

It clearly states=C2=A0 string,= not quoted-string. These two have the following rules:

=C2=A0

quoted-string=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =3D (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)

=C2=A0

string=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D < an unquoted st= ring, as returned by >

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0< the scanner, that matches the r= ule >

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 < yang-string >

=C2=A0

<= /div>


The text in 9.6.4 is c= orrect.
The ABNF is wrong.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=E2=80=A6and in 6.1.3 we can re= ad that:

=C2=A0=C2=A0 An unquoted string i= s any sequence of characters that does not

=C2=A0=C2=A0 contain any space, t= ab, carriage return, or line feed characters, a

=C2=A0=C2=A0 single or double quo= te character, a semicolon (";"), braces ("{" or<= u>

=C2=A0=C2=A0 "}"), or c= omment sequences ("//", "/*", or "*/").

=C2=A0

=C2=A0=C2=A0 Note that any keywor= d can legally appear as an unquoted string.

=C2=A0

Since the section so clearly wr= ites about single quoted strings and double quoted strings, there can unfor= tunately be no interpretation that would allow =E2=80=9Cidentifier=E2=80=9D= to be called an unquoted string =E2=80=93 even though it follows the rules about limited c= haracter contents.

=C2=A0

Hence =E2=80=93 this is not a m= atter of opinion =E2=80=93 it=E2=80=99s a matter of reading what=E2=80=99s = actually written in the RFC.

=C2=A0

But on the subject of opinion= =E2=80=A6

=C2=A0

=C2=A0=C2=A0=C2=A0 = =C2=A0 enum "This is also legal";=C2=A0=C2=A0 // should definitel= y always be illegal

=C2=A0

=E2=80=A6as we cannot create a = language binding to enum constructs in any major programming languages.<= /u>

=C2=A0

<= /div>

There are many aspects of YANG that d= o not map directly to programming languages,
such as allowing = 9;.' in identifiers.

=C2=A0

Br,

Peter



Andy
=C2=A0

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: den 21 februari 2019 18:45
To: Martin Bjorklund <mbj@tail-f.com>
Cc: RFC Editor <rfc-editor@rfc-editor.org>; Ignas Bagdonas <ibagdona@gmail.com>= ; NetMod WG <netmod= @ietf.org>; Peter Loborg <peter.loborg@ericsson.com>; Warren Kumari &l= t;warren@kumari.net<= /a>>
Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)<= /u>

=C2=A0

=C2=A0

=C2=A0

RF= C Errata System <rfc-editor@rfc-editor.org> wrote:
> 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/eid5642
>
> --------------------------------------
> Type: Editorial
> Reported by: Peter Loborg <peter.loborg@ericsson.co= m>
>
> Section: 9.6.4
>
> Original Text
> -------------
> It takes as an argument a string that is the assigned name.
>
> Corrected Text
> --------------
> It takes as an argument an unquoted string that is the assigned name.<= br>
This is not correct.=C2=A0 The enum argument is not different from any
other keyword's arguments in YANG.=C2=A0 See e.g. the example in 9.12.4= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unbounded";
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

The following is also legal:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unb" + 'ounded';<= br>

=C2=A0

=C2=A0

=C2=A0 enum "This is also = legal";

=C2=A0

9.6.4.=C2=A0 The "enum" Statement
=C2=A0=

=C2=A0=C2=A0 The "enum=
" statement, which is a substatement to the "type"=

=C2=A0=C2=A0 statement, MUS=
T be present if the type is "enumeration".=C2=A0 It is<=
/u>
=C2=A0=C2=A0 repeatedly use=
d to specify each assigned name of an enumeration type.
=C2=A0=C2=A0 It takes as an=
 argument a string that is the assigned name.=C2=A0 The
=C2=A0=C2=A0 string MUST=
 NOT be zero-length and MUST NOT have any leading or
=C2=A0=C2=A0 trailing wh=
itespace characters (=
any Unicode character with the
=C2=A0=C2=A0 "White_Sp=
ace" property).=C2=A0 The use of Unicode control codes SHOULD be
=C2=A0=C2=A0 avoided.

=C2=A0

=C2=A0

Th= is errata should be rejected.



/martin

=C2=A0

=C2=A0

Andy

=C2=A0


>
> Notes
> -----
> Readers are not beeing made aware that careful reading of section 6.1.= 3 and the detailed definition of string in section 14 must be consulted. > For comming versions of this RFC it would be preferable to use a more = specialized grammar token for these cases (e.g. unquoted-string).
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The YANG= 1.1 Data Modeling Language
> Publication Date=C2=A0 =C2=A0 : August 2016
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjorklund, Ed.<= br> > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Model= ing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>

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

--000000000000a4210805826b7364-- From nobody Thu Feb 21 10:33: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 C25791310E6 for ; Thu, 21 Feb 2019 10:33:31 -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 S2HyP_mY2mpo for ; Thu, 21 Feb 2019 10:33:29 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DDFE51310D6 for ; Thu, 21 Feb 2019 10:33:28 -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 E7B4D1AE00A0; Thu, 21 Feb 2019 19:33:25 +0100 (CET) Date: Thu, 21 Feb 2019 19:33:25 +0100 (CET) Message-Id: <20190221.193325.152438307014996574.mbj@tail-f.com> To: andy@yumaworks.com Cc: peter.loborg@ericsson.com, rfc-editor@rfc-editor.org, ibagdona@gmail.com, netmod@ietf.org, warren@kumari.net 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 18:33:32 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIEZlYiAy MSwgMjAxOSBhdCAxMDowNyBBTSBQZXRlciBMb2JvcmcgPHBldGVyLmxvYm9yZ0Blcmljc3Nvbi5j b20+DQo+IHdyb3RlOg0KPiANCj4gPg0KPiA+DQo+ID4gWW91ciBleGFtcGxlIGlzIGZpbmUg4oCT IGJ1dCB0aGUgZ2FtbWFyIGlzIGNoMTQgc3BlY2lmaWVzIHNvbWV0aGluZw0KPiA+IGRpZmZlcmVu dDoNCj4gPg0KPiA+DQo+ID4NCj4gPiBlbnVtLXN0bXQgICAgICAgICAgID0gZW51bS1rZXl3b3Jk IHNlcCBzdHJpbmcgb3B0c2VwDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgKCI7 IiAvDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICJ7IiBzdG10c2VwDQo+ID4N Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7OyB0aGVzZSBzdG10cyBjYW4gYXBw ZWFyIGluIGFueSBvcmRlcg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KmlmLWZlYXR1cmUtc3RtdA0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W3ZhbHVlLXN0bXRdDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3Rh dHVzLXN0bXRdDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbZGVzY3Jp cHRpb24tc3RtdF0NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtyZWZl cmVuY2Utc3RtdF0NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ9Iikgc3Rt dHNlcA0KPiA+DQo+ID4NCj4gPg0KPiA+IEl0IGNsZWFybHkgc3RhdGVzICBzdHJpbmcsIG5vdCBx dW90ZWQtc3RyaW5nLiBUaGVzZSB0d28gaGF2ZSB0aGUgZm9sbG93aW5nDQo+ID4gcnVsZXM6DQo+ ID4NCj4gPg0KPiA+DQo+ID4gcXVvdGVkLXN0cmluZyAgICAgICA9IChEUVVPVEUgc3RyaW5nIERR VU9URSkgLyAoU1FVT1RFIHN0cmluZyBTUVVPVEUpDQo+ID4NCj4gPg0KPiA+DQo+ID4gc3RyaW5n ICAgICAgICAgICAgICA9IDwgYW4gdW5xdW90ZWQgc3RyaW5nLCBhcyByZXR1cm5lZCBieSA+DQo+ ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgPCB0aGUgc2Nhbm5lciwgdGhhdCBtYXRj aGVzIHRoZSBydWxlID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICA8IHlhbmct c3RyaW5nID4NCj4gPg0KPiA+DQo+ID4NCj4gDQo+IA0KPiBUaGUgdGV4dCBpbiA5LjYuNCBpcyBj b3JyZWN0Lg0KPiBUaGUgQUJORiBpcyB3cm9uZy4NCg0KTm8sIHRoZSBBQk5GIGlzIGNvcnJlY3Qu ICBUaGUgQUJORiBkb2Vucyd0IGhhbmRsZSBjb25jYXRlbmF0aW9uIGV0Yy4NClRoZSBpZGVhIGlz IHRoYXQgdGhlIHNjYW5uZXIgaGFuZGxlcyBxdW90ZXMgYW5kIGNvbmNhdGVuYXRpb24gYW5kDQpy ZXR1cm5zIGEgInN0cmluZyIuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gDQo+IA0KPiA+IOKA pmFuZCBpbiA2LjEuMyB3ZSBjYW4gcmVhZCB0aGF0Og0KPiA+DQo+ID4gICAgQW4gdW5xdW90ZWQg c3RyaW5nIGlzIGFueSBzZXF1ZW5jZSBvZiBjaGFyYWN0ZXJzIHRoYXQgZG9lcyBub3QNCj4gPg0K PiA+ICAgIGNvbnRhaW4gYW55IHNwYWNlLCB0YWIsIGNhcnJpYWdlIHJldHVybiwgb3IgbGluZSBm ZWVkIGNoYXJhY3RlcnMsIGENCj4gPg0KPiA+ICAgIHNpbmdsZSBvciBkb3VibGUgcXVvdGUgY2hh cmFjdGVyLCBhIHNlbWljb2xvbiAoIjsiKSwgYnJhY2VzICgieyIgb3INCj4gPg0KPiA+ICAgICJ9 IiksIG9yIGNvbW1lbnQgc2VxdWVuY2VzICgiLy8iLCAiLyoiLCBvciAiKi8iKS4NCj4gPg0KPiA+ DQo+ID4NCj4gPiAgICBOb3RlIHRoYXQgYW55IGtleXdvcmQgY2FuIGxlZ2FsbHkgYXBwZWFyIGFz IGFuIHVucXVvdGVkIHN0cmluZy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBTaW5jZSB0aGUgc2VjdGlv biBzbyBjbGVhcmx5IHdyaXRlcyBhYm91dCBzaW5nbGUgcXVvdGVkIHN0cmluZ3MgYW5kIGRvdWJs ZQ0KPiA+IHF1b3RlZCBzdHJpbmdzLCB0aGVyZSBjYW4gdW5mb3J0dW5hdGVseSBiZSBubyBpbnRl cnByZXRhdGlvbiB0aGF0IHdvdWxkDQo+ID4gYWxsb3cg4oCcaWRlbnRpZmllcuKAnSB0byBiZSBj YWxsZWQgYW4gdW5xdW90ZWQgc3RyaW5nIOKAkyBldmVuIHRob3VnaCBpdCBmb2xsb3dzDQo+ID4g dGhlIHJ1bGVzIGFib3V0IGxpbWl0ZWQgY2hhcmFjdGVyIGNvbnRlbnRzLg0KPiA+DQo+ID4NCj4g Pg0KPiA+IEhlbmNlIOKAkyB0aGlzIGlzIG5vdCBhIG1hdHRlciBvZiBvcGluaW9uIOKAkyBpdOKA mXMgYSBtYXR0ZXIgb2YgcmVhZGluZyB3aGF04oCZcw0KPiA+IGFjdHVhbGx5IHdyaXR0ZW4gaW4g dGhlIFJGQy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBCdXQgb24gdGhlIHN1YmplY3Qgb2Ygb3Bpbmlv buKApg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAgIGVudW0gIlRoaXMgaXMgYWxzbyBsZWdhbCI7 ICAgLy8gc2hvdWxkIGRlZmluaXRlbHkgYWx3YXlzIGJlIGlsbGVnYWwNCj4gPg0KPiA+DQo+ID4N Cj4gPiDigKZhcyB3ZSBjYW5ub3QgY3JlYXRlIGEgbGFuZ3VhZ2UgYmluZGluZyB0byBlbnVtIGNv bnN0cnVjdHMgaW4gYW55IG1ham9yDQo+ID4gcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLg0KPiA+DQo+ ID4NCj4gPg0KPiANCj4gVGhlcmUgYXJlIG1hbnkgYXNwZWN0cyBvZiBZQU5HIHRoYXQgZG8gbm90 IG1hcCBkaXJlY3RseSB0byBwcm9ncmFtbWluZw0KPiBsYW5ndWFnZXMsDQo+IHN1Y2ggYXMgYWxs b3dpbmcgJy4nIGluIGlkZW50aWZpZXJzLg0KPiANCj4gDQo+IA0KPiA+IEJyLA0KPiA+DQo+ID4g UGV0ZXINCj4gPg0KPiANCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4gKkZyb206KiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NCj4gPiAqU2VudDoq IGRlbiAyMSBmZWJydWFyaSAyMDE5IDE4OjQ1DQo+ID4gKlRvOiogTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb20+DQo+ID4gKkNjOiogUkZDIEVkaXRvciA8cmZjLWVkaXRvckByZmMtZWRp dG9yLm9yZz47IElnbmFzIEJhZ2RvbmFzIDwNCj4gPiBpYmFnZG9uYUBnbWFpbC5jb20+OyBOZXRN b2QgV0cgPG5ldG1vZEBpZXRmLm9yZz47IFBldGVyIExvYm9yZyA8DQo+ID4gcGV0ZXIubG9ib3Jn QGVyaWNzc29uLmNvbT47IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0Pg0KPiA+ICpT dWJqZWN0OiogUmU6IFtuZXRtb2RdIFtFZGl0b3JpYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3OTUw ICg1NjQyKQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gVGh1LCBG ZWIgMjEsIDIwMTkgYXQgODo1MyBBTSBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4g d3JvdGU6DQo+ID4NCj4gPiBSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMtZWRpdG9y Lm9yZz4gd3JvdGU6DQo+ID4gPiBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4g c3VibWl0dGVkIGZvciBSRkM3OTUwLA0KPiA+ID4gIlRoZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5n IExhbmd1YWdlIi4NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+ID4gWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+ ID4gPiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1NjQyDQo+ID4gPg0KPiA+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IFR5cGU6IEVk aXRvcmlhbA0KPiA+ID4gUmVwb3J0ZWQgYnk6IFBldGVyIExvYm9yZyA8cGV0ZXIubG9ib3JnQGVy aWNzc29uLmNvbT4NCj4gPiA+DQo+ID4gPiBTZWN0aW9uOiA5LjYuNA0KPiA+ID4NCj4gPiA+IE9y aWdpbmFsIFRleHQNCj4gPiA+IC0tLS0tLS0tLS0tLS0NCj4gPiA+IEl0IHRha2VzIGFzIGFuIGFy Z3VtZW50IGEgc3RyaW5nIHRoYXQgaXMgdGhlIGFzc2lnbmVkIG5hbWUuDQo+ID4gPg0KPiA+ID4g Q29ycmVjdGVkIFRleHQNCj4gPiA+IC0tLS0tLS0tLS0tLS0tDQo+ID4gPiBJdCB0YWtlcyBhcyBh biBhcmd1bWVudCBhbiB1bnF1b3RlZCBzdHJpbmcgdGhhdCBpcyB0aGUgYXNzaWduZWQgbmFtZS4N Cj4gPg0KPiA+IFRoaXMgaXMgbm90IGNvcnJlY3QuICBUaGUgZW51bSBhcmd1bWVudCBpcyBub3Qg ZGlmZmVyZW50IGZyb20gYW55DQo+ID4gb3RoZXIga2V5d29yZCdzIGFyZ3VtZW50cyBpbiBZQU5H LiAgU2VlIGUuZy4gdGhlIGV4YW1wbGUgaW4gOS4xMi40Og0KPiA+DQo+ID4gICAgICAgIHR5cGUg ZW51bWVyYXRpb24gew0KPiA+ICAgICAgICAgIGVudW0gInVuYm91bmRlZCI7DQo+ID4gICAgICAg IH0NCj4gPg0KPiA+IFRoZSBmb2xsb3dpbmcgaXMgYWxzbyBsZWdhbDoNCj4gPg0KPiA+ICAgICAg ICAgIGVudW0gInVuYiIgKyAnb3VuZGVkJzsNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g ICBlbnVtICJUaGlzIGlzIGFsc28gbGVnYWwiOw0KPiA+DQo+ID4NCj4gPg0KPiA+IDkuNi40LiAg VGhlICJlbnVtIiBTdGF0ZW1lbnQNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBUaGUgImVudW0iIHN0 YXRlbWVudCwgd2hpY2ggaXMgYSBzdWJzdGF0ZW1lbnQgdG8gdGhlICJ0eXBlIg0KPiA+DQo+ID4g ICAgc3RhdGVtZW50LCBNVVNUIGJlIHByZXNlbnQgaWYgdGhlIHR5cGUgaXMgImVudW1lcmF0aW9u Ii4gIEl0IGlzDQo+ID4NCj4gPiAgICByZXBlYXRlZGx5IHVzZWQgdG8gc3BlY2lmeSBlYWNoIGFz c2lnbmVkIG5hbWUgb2YgYW4gZW51bWVyYXRpb24gdHlwZS4NCj4gPg0KPiA+ICAgIEl0IHRha2Vz IGFzIGFuIGFyZ3VtZW50IGEgc3RyaW5nIHRoYXQgaXMgdGhlIGFzc2lnbmVkIG5hbWUuICAqVGhl Kg0KPiA+DQo+ID4gKiAgIHN0cmluZyBNVVNUIE5PVCBiZSB6ZXJvLWxlbmd0aCBhbmQgTVVTVCBO T1QgaGF2ZSBhbnkgbGVhZGluZyBvcioNCj4gPg0KPiA+ICogICB0cmFpbGluZyB3aGl0ZXNwYWNl IGNoYXJhY3RlcnMqIChhbnkgVW5pY29kZSBjaGFyYWN0ZXIgd2l0aCB0aGUNCj4gPg0KPiA+ICAg ICJXaGl0ZV9TcGFjZSIgcHJvcGVydHkpLiAgVGhlIHVzZSBvZiBVbmljb2RlIGNvbnRyb2wgY29k ZXMgU0hPVUxEIGJlDQo+ID4NCj4gPiAgICBhdm9pZGVkLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPiBUaGlzIGVycmF0YSBzaG91bGQgYmUgcmVqZWN0ZWQuDQo+ID4NCj4gPg0KPiA+DQo+ ID4gL21hcnRpbg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBbmR5DQo+ID4NCj4gPg0K PiA+DQo+ID4NCj4gPiA+DQo+ID4gPiBOb3Rlcw0KPiA+ID4gLS0tLS0NCj4gPiA+IFJlYWRlcnMg YXJlIG5vdCBiZWVpbmcgbWFkZSBhd2FyZSB0aGF0IGNhcmVmdWwgcmVhZGluZyBvZiBzZWN0aW9u IDYuMS4zDQo+ID4gYW5kIHRoZSBkZXRhaWxlZCBkZWZpbml0aW9uIG9mIHN0cmluZyBpbiBzZWN0 aW9uIDE0IG11c3QgYmUgY29uc3VsdGVkLg0KPiA+ID4gRm9yIGNvbW1pbmcgdmVyc2lvbnMgb2Yg dGhpcyBSRkMgaXQgd291bGQgYmUgcHJlZmVyYWJsZSB0byB1c2UgYSBtb3JlDQo+ID4gc3BlY2lh bGl6ZWQgZ3JhbW1hciB0b2tlbiBmb3IgdGhlc2UgY2FzZXMgKGUuZy4gdW5xdW90ZWQtc3RyaW5n KS4NCj4gPiA+DQo+ID4gPiBJbnN0cnVjdGlvbnM6DQo+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4g PiBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNl c3NhcnksIHBsZWFzZQ0KPiA+ID4gdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBp dCBzaG91bGQgYmUgdmVyaWZpZWQgb3INCj4gPiA+IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24g aXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eQ0KPiA+ID4gY2FuIGxvZyBpbiB0byBjaGFu Z2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQo+ID4gPg0K PiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IFJGQzc5 NTAgKGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwMjBiaXMtMTQpDQo+ID4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gVGl0bGUgICAgICAgICAgICAgICA6IFRo ZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlDQo+ID4gPiBQdWJsaWNhdGlvbiBEYXRl ICAgIDogQXVndXN0IDIwMTYNCj4gPiA+IEF1dGhvcihzKSAgICAgICAgICAgOiBNLiBCam9ya2x1 bmQsIEVkLg0KPiA+ID4gQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQo+ ID4gPiBTb3VyY2UgICAgICAgICAgICAgIDogTmV0d29yayBNb2RlbGluZw0KPiA+ID4gQXJlYSAg ICAgICAgICAgICAgICA6IE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQNCj4gPiA+IFN0cmVhbSAg ICAgICAgICAgICAgOiBJRVRGDQo+ID4gPiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KPiA+ ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gPg0K From nobody Thu Feb 21 10:53: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 0C2E4131123 for ; Thu, 21 Feb 2019 10:53:15 -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 ZtaT3369IzxS for ; Thu, 21 Feb 2019 10:53:13 -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 63DC513111F for ; Thu, 21 Feb 2019 10:53:13 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 26E0937; Thu, 21 Feb 2019 19:53: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 IktqlHooEDW8; Thu, 21 Feb 2019 19:53: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; Thu, 21 Feb 2019 19:53: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 D0C8A20058; Thu, 21 Feb 2019 19:53: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 z7s93RgthVKe; Thu, 21 Feb 2019 19:53: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 73F9B20057; Thu, 21 Feb 2019 19:53:11 +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, 21 Feb 2019 19:53:10 +0100 Received: by anna.localdomain (Postfix, from userid 501) id DC09030069AACC; Thu, 21 Feb 2019 19:53:09 +0100 (CET) Date: Thu, 21 Feb 2019 19:53:09 +0100 From: Juergen Schoenwaelder To: Peter Loborg CC: "netmod@ietf.org" Message-ID: <20190221185309.sh3hegyt5lapm6bb@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Peter Loborg , "netmod@ietf.org" References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221170126.2kv5vxhvbsycvwxf@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: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 18:53:15 -0000 On Thu, Feb 21, 2019 at 05:26:43PM +0000, Peter Loborg wrote: > The following two rules in section 14: > > enum-stmt = enum-keyword sep string optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > [value-stmt] > [status-stmt] > [description-stmt] > [reference-stmt] > "}") stmtsep > > string = < an unquoted string, as returned by > > < the scanner, that matches the rule > > < yang-string > The key here is "as returned by the scanner". > ...and the definition of unquoted string in section 6.1.3 about its content... (not a problem in your example) > > An unquoted string is any sequence of characters that does not > contain any space, tab, carriage return, or line feed characters, a > single or double quote character, a semicolon (";"), braces ("{" or > "}"), or comment sequences ("//", "/*", or "*/"). > > ...and the explicit descriptions of single-quoted strings and double-quoted strings further down in 6.1.3 as being enclosed by said quotes. Section 6.1 defines the lexical rules and what the scanner returns is an unquopted string but it accepts unquoted strings and quoted string and combinations thereof with the "+" concatenation operator as input. The errata should be rejected. /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 Feb 21 10:54: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 049E1131123 for ; Thu, 21 Feb 2019 10:54:03 -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 TWtX_YtOFNfl for ; Thu, 21 Feb 2019 10:53:59 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 AD1D4131120 for ; Thu, 21 Feb 2019 10:53:58 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id n15so21144028lfe.5 for ; Thu, 21 Feb 2019 10:53:58 -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=XIucfG6a1w4NUd5xlFHBWem/lCN+H+Qm47XPfd2sFws=; b=n0CwNuRIHqd7K+YkkoJJ/ilJtMCE9MG2jEv/2sSGkAF9IRHBBXglRQu/iHcrKxFtya wc0s/pLGsQgeCpU5vmtGH6ESX3hAsTZNrXvGsnC15o/rJrAlpoQGCXIsg+1VKKYqWeDn ydG/RvcvZosvxmKnYG2D8bb1hH0pjT+oOE3CgmSrh+YPLYQghxHnS1zQQxj80MreNSpp rjx8y97IrBXxyivgEsOrX5FxjDmes7DC7ozUUYDyv1lo2dWJV9O1y2W6MPiQ6ZUC8ZFp gEbPgYyCAX/KNbLn/wtDSL17A4iO/RFkO4nByCJrMBYdxa2InVf4fEqjyuaCGIBFGG+y kZUQ== 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=XIucfG6a1w4NUd5xlFHBWem/lCN+H+Qm47XPfd2sFws=; b=jZRo5lk6qC3ts+z9YWK8u9VKUcqx1FjmDX61g84TtKImgnqp58LO15dYn8amALCOxc +cnR4JY33gaWhUKG3Asswyu6HhZBRPHW88pyS7C4j9KG8rKUc/LTQBTa20nNJwdVnRED +30jASa12XzLaXsiuZiup8iUdmFyVRhu8/GIZu977187aMcOHyyqH44ah10iotiOWXl4 uedvrQF7gCSTnhOZj61xUSyyy1o/31bQUoNhhL/hgNrWmd1rsnuTDmVvVeYLqOjYNiPj skKpTxh65hXFwxniUPw0S1a2/CB8TWB08Ofai70AvC+n5or59UyZO7P8ltuu5fLSZKXo //VQ== X-Gm-Message-State: AHQUAuZqQIUlr4lt84LTjAHEWnhHp6JS3tSQRQPpo3SiWCssvC/QiSWY W4Fs2DP9E639VsFj+lmMCMF9lZZpKk/JVqgs9MGRZQ== X-Google-Smtp-Source: AHgI3IZQOfBJ5Yj5bcTpprmryrrwASRk30QKbdR1wYkbrot8+U84af1nqHpvTp5CS5wk0zHP0Gw10Ves7y6PDkajYHU= X-Received: by 2002:ac2:54b4:: with SMTP id w20mr19833lfk.24.1550775236584; Thu, 21 Feb 2019 10:53:56 -0800 (PST) MIME-Version: 1.0 References: <20190221.193325.152438307014996574.mbj@tail-f.com> In-Reply-To: <20190221.193325.152438307014996574.mbj@tail-f.com> From: Andy Bierman Date: Thu, 21 Feb 2019 10:53:45 -0800 Message-ID: To: Martin Bjorklund Cc: Peter Loborg , RFC Editor , Ignas Bagdonas , NetMod WG , Warren Kumari Content-Type: multipart/alternative; boundary="0000000000001a7d0205826bff72" Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 18:54:03 -0000 --0000000000001a7d0205826bff72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg > > > wrote: > > > > > > > > > > > Your example is fine =E2=80=93 but the gammar is ch14 specifies somet= hing > > > different: > > > > > > > > > > > > enum-stmt =3D enum-keyword sep string optsep > > > > > > (";" / > > > > > > "{" stmtsep > > > > > > ;; these stmts can appear in any order > > > > > > *if-feature-stmt > > > > > > [value-stmt] > > > > > > [status-stmt] > > > > > > [description-stmt] > > > > > > [reference-stmt] > > > > > > "}") stmtsep > > > > > > > > > > > > It clearly states string, not quoted-string. These two have the > following > > > rules: > > > > > > > > > > > > quoted-string =3D (DQUOTE string DQUOTE) / (SQUOTE string SQUOT= E) > > > > > > > > > > > > string =3D < an unquoted string, as returned by > > > > > > > < the scanner, that matches the rule > > > > > > > < yang-string > > > > > > > > > > > > > > > > The text in 9.6.4 is correct. > > The ABNF is wrong. > > No, the ABNF is correct. The ABNF doens't handle concatenation etc. > The idea is that the scanner handles quotes and concatenation and > returns a "string". > > OK -- it is confusing that the rule quoted-string exists, but it is only for key and leaf-list predicates. > > /martin > > Andy > > > > > > > > > > > =E2=80=A6and in 6.1.3 we can read that: > > > > > > An unquoted string is any sequence of characters that does not > > > > > > contain any space, tab, carriage return, or line feed characters, = a > > > > > > single or double quote character, a semicolon (";"), braces ("{" o= r > > > > > > "}"), or comment sequences ("//", "/*", or "*/"). > > > > > > > > > > > > Note that any keyword can legally appear as an unquoted string. > > > > > > > > > > > > Since the section so clearly writes about single quoted strings and > double > > > quoted strings, there can unfortunately be no interpretation that wou= ld > > > allow =E2=80=9Cidentifier=E2=80=9D to be called an unquoted string = =E2=80=93 even though it > follows > > > the rules about limited character contents. > > > > > > > > > > > > Hence =E2=80=93 this is not a matter of opinion =E2=80=93 it=E2=80=99= s a matter of reading > what=E2=80=99s > > > actually written in the RFC. > > > > > > > > > > > > But on the subject of opinion=E2=80=A6 > > > > > > > > > > > > enum "This is also legal"; // should definitely always be > illegal > > > > > > > > > > > > =E2=80=A6as we cannot create a language binding to enum constructs in= any major > > > programming languages. > > > > > > > > > > > > > There are many aspects of YANG that do not map directly to programming > > languages, > > such as allowing '.' in identifiers. > > > > > > > > > Br, > > > > > > Peter > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > *From:* Andy Bierman > > > *Sent:* den 21 februari 2019 18:45 > > > *To:* Martin Bjorklund > > > *Cc:* RFC Editor ; Ignas Bagdonas < > > > ibagdona@gmail.com>; NetMod WG ; Peter Loborg < > > > peter.loborg@ericsson.com>; Warren Kumari > > > *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund > wrote: > > > > > > RFC Errata System wrote: > > > > 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/eid5642 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Peter Loborg > > > > > > > > Section: 9.6.4 > > > > > > > > Original Text > > > > ------------- > > > > It takes as an argument a string that is the assigned name. > > > > > > > > Corrected Text > > > > -------------- > > > > It takes as an argument an unquoted string that is the assigned nam= e. > > > > > > This is not correct. The enum argument is not different from any > > > other keyword's arguments in YANG. See e.g. the example in 9.12.4: > > > > > > type enumeration { > > > enum "unbounded"; > > > } > > > > > > The following is also legal: > > > > > > enum "unb" + 'ounded'; > > > > > > > > > > > > > > > > > > enum "This is also legal"; > > > > > > > > > > > > 9.6.4. The "enum" Statement > > > > > > > > > > > > The "enum" statement, which is a substatement to the "type" > > > > > > statement, MUST be present if the type is "enumeration". It is > > > > > > repeatedly used to specify each assigned name of an enumeration > type. > > > > > > It takes as an argument a string that is the assigned name. *The* > > > > > > * string MUST NOT be zero-length and MUST NOT have any leading or* > > > > > > * trailing whitespace characters* (any Unicode character with the > > > > > > "White_Space" property). The use of Unicode control codes SHOULD = be > > > > > > avoided. > > > > > > > > > > > > > > > > > > This errata should be rejected. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > Notes > > > > ----- > > > > Readers are not beeing made aware that careful reading of section > 6.1.3 > > > and the detailed definition of string in section 14 must be consulted= . > > > > For comming versions of this RFC it would be preferable to use a mo= re > > > specialized grammar token for these cases (e.g. unquoted-string). > > > > > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, pleas= e > > > > 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 > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > --0000000000001a7d0205826bff72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 21, 2019 at 10:33 AM Mart= in Bjorklund <mbj@tail-f.com> w= rote:
Andy Bierm= an <andy@yumawor= ks.com> wrote:
> On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg <peter.loborg@ericsson.com>= ;
> wrote:
>
> >
> >
> > Your example is fine =E2=80=93 but the gammar is ch14 specifies s= omething
> > different:
> >
> >
> >
> > enum-stmt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D enum-keywor= d sep string optsep
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (";" /
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"{" stmtsep
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; these stmts can appear in a= ny order
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*if-feature-stmt
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[value-stmt]
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[status-stmt]
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[description-stmt]
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[reference-stmt]
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "}") stmtsep
> >
> >
> >
> > It clearly states=C2=A0 string, not quoted-string. These two have= the following
> > rules:
> >
> >
> >
> > quoted-string=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D (DQUOTE string DQUOTE= ) / (SQUOTE string SQUOTE)
> >
> >
> >
> > string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D < a= n unquoted string, as returned by >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 < the scanner, that matches the rule >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 < yang-string >
> >
> >
> >
>
>
> The text in 9.6.4 is correct.
> The ABNF is wrong.

No, the ABNF is correct.=C2=A0 The ABNF doens't handle concatenation et= c.
The idea is that the scanner handles quotes and concatenation and
returns a "string".



OK -- it is confusing t= hat the rule quoted-string exists, but it
is only for key and lea= f-list predicates.

=C2=A0

/martin


Andy
=C2=A0


>
>
>
> > =E2=80=A6and in 6.1.3 we can read that:
> >
> >=C2=A0 =C2=A0 An unquoted string is any sequence of characters tha= t does not
> >
> >=C2=A0 =C2=A0 contain any space, tab, carriage return, or line fee= d characters, a
> >
> >=C2=A0 =C2=A0 single or double quote character, a semicolon ("= ;;"), braces ("{" or
> >
> >=C2=A0 =C2=A0 "}"), or comment sequences ("//"= , "/*", or "*/").
> >
> >
> >
> >=C2=A0 =C2=A0 Note that any keyword can legally appear as an unquo= ted string.
> >
> >
> >
> > Since the section so clearly writes about single quoted strings a= nd double
> > quoted strings, there can unfortunately be no interpretation that= would
> > allow =E2=80=9Cidentifier=E2=80=9D to be called an unquoted strin= g =E2=80=93 even though it follows
> > the rules about limited character contents.
> >
> >
> >
> > Hence =E2=80=93 this is not a matter of opinion =E2=80=93 it=E2= =80=99s a matter of reading what=E2=80=99s
> > actually written in the RFC.
> >
> >
> >
> > But on the subject of opinion=E2=80=A6
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "This is also legal";=C2= =A0 =C2=A0// should definitely always be illegal
> >
> >
> >
> > =E2=80=A6as we cannot create a language binding to enum construct= s in any major
> > programming languages.
> >
> >
> >
>
> There are many aspects of YANG that do not map directly to programming=
> languages,
> such as allowing '.' in identifiers.
>
>
>
> > Br,
> >
> > Peter
> >
>
>
> Andy
>
>
> >
> >
> >
> >
> > *From:* Andy Bierman <andy@yumaworks.com>
> > *Sent:* den 21 februari 2019 18:45
> > *To:* Martin Bjorklund <mbj@tail-f.com>
> > *Cc:* RFC Editor <rfc-editor@rfc-editor.org>; Ignas Bagdonas < > > ibagdona@= gmail.com>; NetMod WG <netmod@ietf.org>; Peter Loborg <
> > pe= ter.loborg@ericsson.com>; Warren Kumari <warren@kumari.net>
> > *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642= )
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> > > The following errata report has been submitted for RFC7950,<= br> > > > "The YANG 1.1 Data Modeling Language".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata/eid5642<= br> > > >
> > > --------------------------------------
> > > Type: Editorial
> > > Reported by: Peter Loborg <peter.loborg@ericsson.com>
> > >
> > > Section: 9.6.4
> > >
> > > Original Text
> > > -------------
> > > It takes as an argument a string that is the assigned name.<= br> > > >
> > > Corrected Text
> > > --------------
> > > It takes as an argument an unquoted string that is the assig= ned name.
> >
> > This is not correct.=C2=A0 The enum argument is not different fro= m any
> > other keyword's arguments in YANG.=C2=A0 See e.g. the example= in 9.12.4:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum "unbounded";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >
> > The following is also legal:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum "unb" + 'oun= ded';
> >
> >
> >
> >
> >
> >=C2=A0 =C2=A0enum "This is also legal";
> >
> >
> >
> > 9.6.4.=C2=A0 The "enum" Statement
> >
> >
> >
> >=C2=A0 =C2=A0 The "enum" statement, which is a substatem= ent to the "type"
> >
> >=C2=A0 =C2=A0 statement, MUST be present if the type is "enum= eration".=C2=A0 It is
> >
> >=C2=A0 =C2=A0 repeatedly used to specify each assigned name of an = enumeration type.
> >
> >=C2=A0 =C2=A0 It takes as an argument a string that is the assigne= d name.=C2=A0 *The*
> >
> > *=C2=A0 =C2=A0string MUST NOT be zero-length and MUST NOT have an= y leading or*
> >
> > *=C2=A0 =C2=A0trailing whitespace characters* (any Unicode charac= ter with the
> >
> >=C2=A0 =C2=A0 "White_Space" property).=C2=A0 The use of = Unicode control codes SHOULD be
> >
> >=C2=A0 =C2=A0 avoided.
> >
> >
> >
> >
> >
> > This errata should be rejected.
> >
> >
> >
> > /martin
> >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> > >
> > > Notes
> > > -----
> > > Readers are not beeing made aware that careful reading of se= ction 6.1.3
> > and the detailed definition of string in section 14 must be consu= lted.
> > > For comming versions of this RFC it would be preferable to u= se a more
> > specialized grammar token for these cases (e.g. unquoted-string).=
> > >
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If= necessary, please
> > > use "Reply All" to discuss whether it should be ve= rified or
> > > rejected. When a decision is reached, the verifying party > > > can log in to change the status and edit the report, if nece= ssary.
> > >
> > > --------------------------------------
> > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > > --------------------------------------
> > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : The YANG 1.1 Data Modeling Language
> > > Publication Date=C2=A0 =C2=A0 : August 2016
> > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjork= lund, Ed.
> > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED= STANDARD
> > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Net= work Modeling
> > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Operations and Management
> > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IET= F
> > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.= org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
--0000000000001a7d0205826bff72-- From nobody Fri Feb 22 01:02: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 F24E3126C15 for ; Fri, 22 Feb 2019 01:02:56 -0800 (PST) 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 9yrBnOKoZ7OH for ; Fri, 22 Feb 2019 01:02:53 -0800 (PST) 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 17177124D68 for ; Fri, 22 Feb 2019 01:02:53 -0800 (PST) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 74977607F8 for ; Fri, 22 Feb 2019 10:02:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1550826170; bh=5oL/Mc5g0/6f/TYa7Nt1rLyRBZaDRBm+SXUUefN9qxg=; h=From:To:Date; b=dPwHKb3VIqKDUG8VkZ9o1IWQUQ3blAYCfOmA91PHkDfDTQF9VNhh1HY5BgM6pTpvP eNK7z5s0T7oZFHsr6/zv4nnUQZilaWFvqklnH9XTcIT0htmlsOIEQ2hmKG7/SpEUCY gVZJx4bwLBOzDGQ/FoQkjp8E+K/7Ekltk7NhnpPA= Message-ID: <0443a07a154d107335f99b8c62874df9f05ec6ad.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 22 Feb 2019 10:02:50 +0100 In-Reply-To: <20190221.193325.152438307014996574.mbj@tail-f.com> References: <20190221.193325.152438307014996574.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 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] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 09:02:57 -0000 On Thu, 2019-02-21 at 19:33 +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg > > wrote: > > > > > > > > Your example is fine – but the gammar is ch14 specifies something > > > different: > > > > > > > > > > > > enum-stmt = enum-keyword sep string optsep > > > > > > (";" / > > > > > > "{" stmtsep > > > > > > ;; these stmts can appear in any order > > > > > > *if-feature-stmt > > > > > > [value-stmt] > > > > > > [status-stmt] > > > > > > [description-stmt] > > > > > > [reference-stmt] > > > > > > "}") stmtsep > > > > > > > > > > > > It clearly states string, not quoted-string. These two have the following > > > rules: > > > > > > > > > > > > quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) > > > > > > > > > > > > string = < an unquoted string, as returned by > > > > > > > < the scanner, that matches the rule > > > > > > > < yang-string > > > > > > > > > > > > > > The text in 9.6.4 is correct. > > The ABNF is wrong. > > No, the ABNF is correct. The ABNF doens't handle concatenation etc. > The idea is that the scanner handles quotes and concatenation and > returns a "string". I guess the explanation could be improved. Section 6.1.3 talks about unquoted, single- and double-quoted strings, but then the term "string" is used in the ABNF to mean the argument string, i.e. the result of scanner preprocessing (concatenation, substitution of escaped characters). Maybe we can use another term, such as "argstring", for the latter. Also, the term scanner only appears in the ABNF appendix. Some explanation of the preprocessing stage in the main text would also help. Lada > > > /martin > > > > > > > > > > …and in 6.1.3 we can read that: > > > > > > An unquoted string is any sequence of characters that does not > > > > > > contain any space, tab, carriage return, or line feed characters, a > > > > > > single or double quote character, a semicolon (";"), braces ("{" or > > > > > > "}"), or comment sequences ("//", "/*", or "*/"). > > > > > > > > > > > > Note that any keyword can legally appear as an unquoted string. > > > > > > > > > > > > Since the section so clearly writes about single quoted strings and double > > > quoted strings, there can unfortunately be no interpretation that would > > > allow “identifier” to be called an unquoted string – even though it > > > follows > > > the rules about limited character contents. > > > > > > > > > > > > Hence – this is not a matter of opinion – it’s a matter of reading what’s > > > actually written in the RFC. > > > > > > > > > > > > But on the subject of opinion… > > > > > > > > > > > > enum "This is also legal"; // should definitely always be illegal > > > > > > > > > > > > …as we cannot create a language binding to enum constructs in any major > > > programming languages. > > > > > > > > > > > > > There are many aspects of YANG that do not map directly to programming > > languages, > > such as allowing '.' in identifiers. > > > > > > > > > Br, > > > > > > Peter > > > > > > > Andy > > > > > > > > > > > > > > > > *From:* Andy Bierman > > > *Sent:* den 21 februari 2019 18:45 > > > *To:* Martin Bjorklund > > > *Cc:* RFC Editor ; Ignas Bagdonas < > > > ibagdona@gmail.com>; NetMod WG ; Peter Loborg < > > > peter.loborg@ericsson.com>; Warren Kumari > > > *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund wrote: > > > > > > RFC Errata System wrote: > > > > 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/eid5642 > > > > > > > > -------------------------------------- > > > > Type: Editorial > > > > Reported by: Peter Loborg > > > > > > > > Section: 9.6.4 > > > > > > > > Original Text > > > > ------------- > > > > It takes as an argument a string that is the assigned name. > > > > > > > > Corrected Text > > > > -------------- > > > > It takes as an argument an unquoted string that is the assigned name. > > > > > > This is not correct. The enum argument is not different from any > > > other keyword's arguments in YANG. See e.g. the example in 9.12.4: > > > > > > type enumeration { > > > enum "unbounded"; > > > } > > > > > > The following is also legal: > > > > > > enum "unb" + 'ounded'; > > > > > > > > > > > > > > > > > > enum "This is also legal"; > > > > > > > > > > > > 9.6.4. The "enum" Statement > > > > > > > > > > > > The "enum" statement, which is a substatement to the "type" > > > > > > statement, MUST be present if the type is "enumeration". It is > > > > > > repeatedly used to specify each assigned name of an enumeration type. > > > > > > It takes as an argument a string that is the assigned name. *The* > > > > > > * string MUST NOT be zero-length and MUST NOT have any leading or* > > > > > > * trailing whitespace characters* (any Unicode character with the > > > > > > "White_Space" property). The use of Unicode control codes SHOULD be > > > > > > avoided. > > > > > > > > > > > > > > > > > > This errata should be rejected. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > Notes > > > > ----- > > > > Readers are not beeing made aware that careful reading of section 6.1.3 > > > and the detailed definition of string in section 14 must be consulted. > > > > For comming versions of this RFC it would be preferable to use a more > > > specialized grammar token for these cases (e.g. unquoted-string). > > > > 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 > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Feb 22 02:55: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 D5AC212E04D for ; Fri, 22 Feb 2019 02:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 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_MED=-2.3, SPF_PASS=-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=Z1iy1QbK; dkim=pass (1024-bit key) header.d=ericsson.com header.b=U7QIqu5f Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rUQtFd9da3r for ; Fri, 22 Feb 2019 02:55:36 -0800 (PST) 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 78262130DC8 for ; Fri, 22 Feb 2019 02:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550832933; x=1553424933; 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=3rPnJxJhgZei9sE89YlsWBvmALH3YqzRGbYPLYmk3ho=; b=Z1iy1QbKybtEHI7yxA0d0g8Ib7vgnHeovRcXKYdImZJuRFVssIDrhVNFmkDbl0v3 2RjCdBVPuTnkB764u2yz+TdqZ/gsGyaQHEXzgwCWX9GbWtMLnpVx64d5nkw/Kgsz sgafcuPYPPHDWnFkYOcB/bA37gcaQEOyLeEYinKSDpM=; X-AuditID: c1b4fb30-fabff7000000355c-30-5c6fd52510b5 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.43.13660.525DF6C5; Fri, 22 Feb 2019 11:55:33 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 22 Feb 2019 11:55:33 +0100 Received: from EUR02-VE1-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; Fri, 22 Feb 2019 11:55:33 +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=3rPnJxJhgZei9sE89YlsWBvmALH3YqzRGbYPLYmk3ho=; b=U7QIqu5feMloGRPXMzOC9PWtWc7P1LJZ50sD13/6scMjoyPFS99PJbdY9PPc6uBYeKZX8jTV+Ewg89MyKfHTbl/82L55et+wDIPKcR0eOvjSnsZxLn3O0NZ2j9FYUZP/kVfdND6SatblB8Lv3/y9Q8FoGozes6EH/K/2tCdnfes= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB5235.eurprd07.prod.outlook.com (20.178.19.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.6; Fri, 22 Feb 2019 10:55:32 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd%2]) with mapi id 15.20.1665.008; Fri, 22 Feb 2019 10:55:32 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Martin Bjorklund CC: Ignas Bagdonas , Peter Loborg , Warren Kumari , NetMod WG , RFC Editor Thread-Topic: [netmod] [Editorial Errata Reported] RFC7950 (5642) Thread-Index: AQHUyp0hpy1TPbcsmEy9OTSaC70r9A== Date: Fri, 22 Feb 2019 10:55:31 +0000 Message-ID: References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> In-Reply-To: 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.1 x-clientproxiedby: HE1PR06CA0137.eurprd06.prod.outlook.com (2603:10a6:7:16::24) To AM0PR07MB3841.eurprd07.prod.outlook.com (2603:10a6:208:45::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: 94cabd74-2223-45f0-8330-08d698b443bb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM0PR07MB5235; x-ms-traffictypediagnostic: AM0PR07MB5235: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA3TUI1MjM1OzIzOlhkZ01DbElXd2VkdHU2SDdqTHJQaDA4V3U5?= =?utf-8?B?OCsxK2dDalFQY0RpSFNwWU4ydHFPZHV4VWc0cU9oVDY5ZFNBeEpuV1d6MkdG?= =?utf-8?B?QytpZHhKU3JJaStQTTV6RkRXeUZCYm1odTByS096NmNTbTFsVXAzb0ZHRGRs?= =?utf-8?B?Y0ZLM0NOSVJuVzRWM1gvK0RYRnNUSmNzbjh6dDhUMk15K1BrTzhFemkzUzIv?= =?utf-8?B?eEJqbDRmalI0dW15VFU4dDJaNXIraVc1cXoxeWRWS2JHdGk2WjRWSEkva2Jl?= =?utf-8?B?bjBBai9JSTJmS0h2dm1vNndxc1ZkUHFWb0dWR2RJdW5PNm1lWjZLTUVjangy?= =?utf-8?B?OTJGc04rZjNiN3BGb0VOcXdBNnJuYVJpZVpsT3hrR3FhbnFKZmRCZTNSVzZr?= =?utf-8?B?ZWlQRDN4eDJUeFNTaW9xRGxRb3pEa1Z4Rjllam5FWkx2bjQvUlJJQ0hwdmpz?= =?utf-8?B?YkIrMUxBSjUrNkpIYi9kaVdwc2tMWXpvUzd1SHhCT3gwZldISjE5NGJBcWc2?= =?utf-8?B?QlBKMzJmUnlQdWRZeFZXNzJybVA1MngrZnc5aEorOEtZNmZCUnVhTXE3eWcx?= =?utf-8?B?b054L2Z4cmd1QzdIYzBzWmJQbjl4Y3l4aVVJUHB0OXpHQmFjbUNlM0ZoZVZB?= =?utf-8?B?Tm9aU0lCWTNXSnFOZmxaaHg0Nzk5a0hGRTNqeS9sUFFqODZRMEI0S0Q3MGlF?= =?utf-8?B?Y1hBRUtWeW9nSHhtUmFkN1VRZXFaL01TemdRUit1N0hPZ1VCK0pjN1pNZmo1?= =?utf-8?B?c2xwM0g2Snp4UzVMaG52QTgrcDg4RzUwbjJ6cEZhV3RlMWg0TGdvaENXMDJM?= =?utf-8?B?YmJBelVWTWszcDNGVFVQcnVjem9vN2pNcFI2NmdBS0Q0bFpydmxEQ3ZIRGdU?= =?utf-8?B?ajBGak1xRGhBZXhUeXJhSERrTjgvT0RpakxaNkNJampiYjFHU29CTkZWVG9p?= =?utf-8?B?amhla1ZaU0hwenpLcXAyRjhUd095eVJhbmRQTjA5OW96YjVpa0FCOXpVZzVI?= =?utf-8?B?Y1F0S08vWVJUdEU5TlRVbGZRT2RmUUtMRklHcVU3NFpUQ2JJUWZLMDBhZW1m?= =?utf-8?B?YlcrbnBxRXdNNUFwc0dCb2xXQUNxT0RUSm9zb2VVdk9kOG53TlZ3emJGY0dV?= =?utf-8?B?NW4zR0NWRzVwQ3cwbzRNU3I0UU9FQmozdFRadGJqK2o0WHlLa2NUUWY1QStm?= =?utf-8?B?K1BnOGw2SFVsU3FGcDBBNk5Ra2R5bEJwbUFGUmNKUEtob0NSc285S0pmdnE4?= =?utf-8?B?UzdJajZ0TFdPVGdpeHR4dnpNdUh2WjVJYThnSXMwL0lpSWxVODVkRWdCM1dE?= =?utf-8?B?dFh4S0MxTGxmRjNNbVhZUVJDRy80SjJsVzVVMElQMHkvTWVUWEFmQmFEeDlZ?= =?utf-8?B?YjNXS2VPV0FkSkdDZmlyZUkyLzVsWTI5dXlaNHk5Mmc3Q1YvT2VTVGhNaFBi?= =?utf-8?B?cDJaR2M1aDRFZUNTSUltVERTb3VTK05TWThsQjJZY0FEbzdLeXZabXpEYzZJ?= =?utf-8?B?S3hNTStzZjhlSkFPUExxWC9nMjRPZFd4bGN0Mld3OGloRWRqNzFCQVFmY3Vu?= =?utf-8?B?SEliUUsxcytvYWhkL28zY2I5ZlR0QXdPN1pNVGVNY1RCb3NmTWprMWdCTWVy?= =?utf-8?B?d3BpSnBNYVQ2Z0phbEdhdE9oSFY4SEN3NDB1T0RvTXdQMFNjSzdFYS9zL1hm?= =?utf-8?B?TGxnaE0zZi9LazJCVnp2clh6UlNIZHphQW4xY0xmLzVQaGl6ZnZFenl6ckhI?= =?utf-8?B?QTJBR3NTWFhQNXZlY0kzQ0VJWVR0eDF1ZnJ6NnNxSTBkYkkrRHRBTzVidkZC?= =?utf-8?B?ZDNKQ0NJd0NxSld1V0RqWUQrcXl3Y3c1SXFLbWNuZ2lPWGZiTVpxTjJEMlhi?= =?utf-8?B?SjFScGUwWHA5ajZadHlEWmdTa0FmVk02a1hWbjRYRFh6cm1IOEo2YlM1RnVR?= =?utf-8?B?Q0drMXROQi8vamJNUEdCNUVBazQreWZUdHE4dllXY2VCaWxwckp3aTk4UmpC?= =?utf-8?B?YVQ2N3k1dnl6SDVldVFBWTY0Uk5OdmJCUjEwb3BFWXUxelUwNDdjZlpaM3dr?= =?utf-8?Q?BSgPObJ0u2l7GPMGdl17GpV0B?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(346002)(136003)(396003)(39860400002)(376002)(199004)(189003)(4744005)(316002)(99286004)(52116002)(97736004)(256004)(229853002)(6436002)(86362001)(54906003)(58126008)(110136005)(71200400001)(14454004)(5660300002)(65956001)(66066001)(65806001)(6512007)(31696002)(6486002)(76176011)(478600001)(71190400001)(305945005)(85182001)(11346002)(476003)(6506007)(81156014)(105586002)(31686004)(106356001)(64126003)(26005)(81166006)(8936002)(486006)(2616005)(446003)(8676002)(7736002)(102836004)(4326008)(36756003)(6246003)(85202003)(386003)(3846002)(186003)(25786009)(68736007)(65826007)(99936001)(6116002)(53936002)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5235; 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) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y5yFfyVdEQhESYos9xqu6DovGIrqeNSEBSpWIGHOr2Mqf3ct3LJBPpEN1d+RMsT4x0Q9fk7NhMXSsVaI0xT+TUyCNLR3vWfo+6LTuGn2+DdwT1g+lnEVcDiYS/SW9SLUADwfobZi7ZpuofdQKQVY9RGHec6oCOO10b6vgBGzXk6qW4sT8iGgsjrtgC06YcnybzpbOeme5lM8KGgXZQY52SquMHAa96eUOkvp+qimoQdj7CXF7hPTuysXpBq+cI0lmlCbHt5jTr7bXWQSdmga8ye12qxhOH07De+tDbCEJ3qx4gr+gCOTOf4c04h83u6tdDaz1vPy96w+ax08fBap1nyQFvnuCPTtZw5oSEcNVTwr9uM3OevjM3dyEXv6idTGBRifB1XPwWF5QS3V3kLxxvBYPlCbqooIWTIT5x222ls= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090403020909020209070303" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 94cabd74-2223-45f0-8330-08d698b443bb X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 10:55:32.0083 (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: AM0PR07MB5235 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSf0yMcRzHfZ/n6Xmebq59XZc+ouFWbCGkOLLQzM6sLT/+MCJHz1yTu9wT E2u7TOk6Ecrqli7rxBIriUilOll+lJOULHVq/ZStmUqq6e45G/+9Pp/3+/P+fj/ffVlSkkR7 sdHqOE6rVsbIaBGVvffx2RW+LZqIVZdy/ORdFiMj/5Gop+QGQy8jN1kTXeTnqn/S8rr6ZmIz rXhi7GAUZvMvQvG5bZJR6JLrXRQlE/mU4vxlKxVO7xNtjOJiok9x2pUhh0SqptpCJjYl6PTN /l5Ch4oDUpErCzgQGlPMRCoSsRJsQTCY3O0sRhG8K0qihcJMQO6dj4y9oHA6CTXWPlJQrhBg 6C132r4iaH5YRtuTabwVLnyvngljWSlWQFHONruHxJUIdE03kN3jjjeDIbOLtLMUb4Hm5A+0 wP4wnHbP0aewL5QUtDB2FuNNUPXtsvPkMgSNHSOEXXDFO2G0odERivBcGHtV5OiT2BPae0yE sKoUbNbXtMAeMNA97SKwDLIG2x3sgQ9AaUam4wDAmQj6flUxQuhBePYlxTm8HN629iCBveG9 yeDkMNAlptHCcDeC0txix/qA/aD7ZajQr5SC+fqoc+AY5E+nk+lopfGfyxodz6RHkFJ1jzA6 1p4DDdk9lGBaC7mlNlLgZVBwc4j8f9jOwZA1UUMLvBgyDDZG4CAYejGCBF4DBfen6DwkKkQe PMcfPn40IMCf00Yf4XmN2l/NxT1AMx+y5uHvVeVooG9LLcIsks0Wyy2aCImL8hQff7wW+czk fC2++w55UWqNmpNJxU8bZmRxlDL+DKfVRGpPxnB8LZrPUjJP8aRkToQEH1XGccc4LpbT/lUJ 1tVLh9z3E6qWcw8W5oXnX6zYVpE3/Hx/a3JemGpkal6g3hr8qEBvO7E97XpNy6fKrKB1qZ0q 713ZL01ufJjJu67NsoFb4rPbZyxw3K08J2hpp95PFbmHbxj7vUgX5j9+zWj7oIhRi68siL26 fUfCrFHf4ITQ249Cbq13uz9RlvNz4E3/DYuM4lXK1X6kllf+ATdpp5aYAwAA Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 10:55:39 -0000 --------------ms090403020909020209070303 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Do people really use enum names with whitespace within? I always had the feeling that the name of the enum is like an=20 identifier, so it should follow maybe not the exact same but at least=20 similar rules. When such an enum name is translated into a programing language AFAIK=20 the translation needs to replace the spaces with something. regards Balazs On 2019. 02. 21. 18:45, Andy Bierman wrote: > enum "This is also legal"; --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms090403020909020209070303 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIyMjEwNTUyM1ow LwYJKoZIhvcNAQkEMSIEIBJtAL4G/aXCCgLMzUU+Q9bNutcllz3EhlcLOLXZAJVPMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAIVh4XyPjubdLo0Pl7aV7b7UcbTSWjDN5eYN0y82tFHTHa1i LGvjAIImEztR+mXnp+swejzXdPJHlVl4QbSkZR0IZRHBG1uQrfxjGqIDvc+Ttu3iu/3uCcAt aBR56cZPR8bZXOmt6SVsgiFWd44R32Ucz/uU7B5OEosghgS/0x/wNo1GyzUINdOz3OvX7/xv M6wT3RnKl2+9PIXAkjFtmR04EmB/L5q8rb/grtrAaQueavwK8W2gN+j4kTWlmAGcZIIaV10n udh9MHFYH6UKm0+YoNFn1Lkft37V9UVWymuoGTT8l6mTF8OzfkS3HZ47+3/WLl+LuNSeeDvF 9umYaRgAAAAAAAA= --------------ms090403020909020209070303-- From nobody Fri Feb 22 03:08: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 A61BB1277CC for ; Fri, 22 Feb 2019 03:08:04 -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 aDbmfCFniLfa for ; Fri, 22 Feb 2019 03:08:02 -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 96662124D68 for ; Fri, 22 Feb 2019 03:08:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3243BBBC; Fri, 22 Feb 2019 12:08:00 +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 vNUSLuPPIHiP; Fri, 22 Feb 2019 12:08:00 +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, 22 Feb 2019 12:08:00 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18D6320057; Fri, 22 Feb 2019 12:08:00 +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 mioti7Ocmb7s; Fri, 22 Feb 2019 12:07:59 +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 8B30C20058; Fri, 22 Feb 2019 12:07:58 +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, 22 Feb 2019 12:07:57 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 44FC930069CCB6; Fri, 22 Feb 2019 12:07:56 +0100 (CET) Date: Fri, 22 Feb 2019 12:07:56 +0100 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel CC: Andy Bierman , Martin Bjorklund , Ignas Bagdonas , Peter Loborg , Warren Kumari , NetMod WG , RFC Editor Message-ID: <20190222110756.bsggrzyxjtft7heg@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , Martin Bjorklund , Ignas Bagdonas , Peter Loborg , Warren Kumari , NetMod WG , RFC Editor References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 11:08:05 -0000 On Fri, Feb 22, 2019 at 10:55:31AM +0000, Bal=E1zs Lengyel wrote: > Do people really use enum names with whitespace within? > I always had the feeling that the name of the enum is like an identifie= r, so > it should follow maybe not the exact same but at least similar rules. >=20 > When such an enum name is translated into a programing language AFAIK t= he > translation needs to replace the spaces with something. Not just spaces. Tool implementors will have to address this and what needs special handling varies from target language to target language (some target languages or implementations of target languages also have interesting length contraints). I think it is fine if BCPs like RFC 8407 provide guidelines that people should avoid characters that are likely to be problematic but the YANG specification is relatively clear that YANG itself puts little constraints on such names (and hence tool makers in charge to handle this). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 22 04:45: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 99769129619 for ; Fri, 22 Feb 2019 04:45:23 -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, 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_MED=-2.3, SPF_PASS=-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=LrCAAXFu; dkim=pass (1024-bit key) header.d=ericsson.com header.b=anTX83C+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cap6gitf1D_w for ; Fri, 22 Feb 2019 04:45:21 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 6B8F4124BF6 for ; Fri, 22 Feb 2019 04:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550839518; x=1553431518; 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=ZIU8itmY5P5WUJPXXIzQsUL7ilj4+WXq9xAIrTeF4EY=; b=LrCAAXFuWjsPFV1qpwR+cEkuzAdC3u3dsC+WvO9B//N4wx5XGVp0dhMkRGRgFQeN sa6IiW+3DAnfmVEd4vdktCo87j55bS4syrWZUQLU3CLgfqHXVkew6maSHIRAixUq nUJARCJL0Qt3KZunQm8aNdr5Po0xLasFRMkqwx/YrHg=; X-AuditID: c1b4fb3a-167ff7000000672c-76-5c6feedefbdf Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1B.2B.26412.EDEEF6C5; Fri, 22 Feb 2019 13:45:18 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESSMB503.ericsson.se (153.88.183.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 22 Feb 2019 13:45:18 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 22 Feb 2019 13:45:18 +0100 Received: from EUR04-HE1-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; Fri, 22 Feb 2019 13:45:18 +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=ZIU8itmY5P5WUJPXXIzQsUL7ilj4+WXq9xAIrTeF4EY=; b=anTX83C+jfQ9LCopI1GqHzeXY77vQnjDnz+bZ/LAXa6Wr0j0d44IuOZzLg5v4AWIxdjGNqs8LdN4bTg5o+zIYjb+VNDkaNY4+wzMHvxU6NK5KaHVGBDrDaMB9Jmgn567xftGFaNsv4e6hLHMu7+HZQl9UoUNc0OSLiNXkjXhqFg= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB4626.eurprd07.prod.outlook.com (52.135.151.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.6; Fri, 22 Feb 2019 12:45:16 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd%2]) with mapi id 15.20.1665.008; Fri, 22 Feb 2019 12:45:16 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Martin Bjorklund , Ignas Bagdonas , Peter Loborg , Warren Kumari , NetMod WG , RFC Editor Thread-Topic: [netmod] [Editorial Errata Reported] RFC7950 (5642) Thread-Index: AQHUyp0hpy1TPbcsmEy9OTSaC70r9KXrqH8AgAAbLQA= Date: Fri, 22 Feb 2019 12:45:16 +0000 Message-ID: References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> <20190222110756.bsggrzyxjtft7heg@anna.jacobs.jacobs-university.de> In-Reply-To: <20190222110756.bsggrzyxjtft7heg@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: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 x-clientproxiedby: HE1PR05CA0282.eurprd05.prod.outlook.com (2603:10a6:3:fc::34) 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: aec92b21-550b-4089-c729-08d698c39885 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM0PR07MB4626; x-ms-traffictypediagnostic: AM0PR07MB4626: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA3TUI0NjI2OzIzOnJYcFVJRlFXTnkzTTZXb1dwYUh5RXZEY1NP?= =?utf-8?B?dHd2aVh3a0JGTHVkbnBYT2FZcUxRVkdyYk9iS0srZHBnaXNOWHV6TXJRSHU3?= =?utf-8?B?R1JoYVJ2bWpzZDJuUVBVUy9vM1lqRk5uNGF0Wm9TRDlDUFJybXVDMzdoZ09C?= =?utf-8?B?NE5SU1prTnJsUElCUFB0SDBlczNoUm1DejlGa2RxcmhxbHM4RWtmdm05cDFH?= =?utf-8?B?RE5Sc0kvNU5vNG9QSTlrZC8yektFYUVvTld3RGZGR2JHSWk4MDFWSkRBaDc1?= =?utf-8?B?eFkvU21RWklMUCtkTWNZdzl2eXNNMVdMc0hoSGFXRkxJYlVxYWFvN2xrMGFa?= =?utf-8?B?ZjFkaFpEUWlZVTdxWWgzUlVubmpJSjNPcW4yNndhWlFReEFvSzk2Wmx2Z0tx?= =?utf-8?B?bTYxdXZ1YncwQXdVclEzQXRxRVI3SkR5RW1KbHFxQityQW9GdTlURTNSWHZo?= =?utf-8?B?U1F2SGlTK0V0L2dxOVIvaEdOa3MzVnA0T3prYXYvenYvWng5ZGVzT0dIRFN1?= =?utf-8?B?UGYrZUs3TklzZzY0eldES2xkVEQwTUI4OEF3dUsweEFRa041SUFuNzk1VUtP?= =?utf-8?B?dkVxK3ByVFYxZGZnM1JKQkg3NHNoSHpxS2Fmc1dpNTlwQ29FWlNZMHFMZ0Fz?= =?utf-8?B?ZGJ1QjNqT0d1enZZN0FNeVgrU3pFRUUzU3dreDlwSU9OTUJJYTZ5SmRyZE9s?= =?utf-8?B?a3IwZWZLZHZuSDE0Q1dxL2lmaS82b3VNa0pGTU9BMFlIUHFVZVVJazc5bEIy?= =?utf-8?B?OE5yU29oRmE1Q0N1YXFrU2hCZWkrZldpaHlQUHBTcEdKVWc4a0ZmQmF1UzBN?= =?utf-8?B?aXp2VGxCMWVMQUJZWG1aQmtzRTJoQlNqdnkwZTNic2M5Z1E2cEIzVEp1ajZu?= =?utf-8?B?N1plWnJ3QjJQdkJBK05lalNTVDg4cGFVZU1mcnFYbWExSXYzZWYyMzY0M1U1?= =?utf-8?B?R0Zpc3FydlBycHgzNFMrditYV2dTeEJDNmpqeVFzUXFXS0F3YXI5M0swYmg5?= =?utf-8?B?aElTQ0R4dnl1Wndodk5hODF2KzNETFRPOGdiTU5vTjIwa1dNUFdNU0FuMjUy?= =?utf-8?B?RlVxZy9ja0JRbDh5RGVGbVVQbTVBcWNrT0dJMTlneW5zeDBxNThmNlpVRlpK?= =?utf-8?B?bkhHQlRHckdPVnNJMHJmYWJ0NXVadVdoalQyb000VTZPUkRJNWhYUy9ZQ2hj?= =?utf-8?B?SktmZ2VsWit4R0kxMzVTOTBYYUR4VDkzQ0RkN2lINms4K0ZKVDYxb3UrOGFt?= =?utf-8?B?eTlzajlLTVNSWXBRSnJvdG5SN0RYdjh6OHB3aDY4cjFvQ2gwM2xYMlV4YlNL?= =?utf-8?B?WlBVa0ErTk5ta25tckM1d3lrZ1JrVXFmYjhIS21takZSeEVBbk1NTG03WGkr?= =?utf-8?B?SmRtY1dRWTRTL0YzQ0ZCM0wzbUprZkFlREpOeDhoTjZFZHhTdW9zbTJHNkFP?= =?utf-8?B?OHpxVS9jQ21UbDBTdFl6L3BIU3dSeDVyRjNUdEJhSy9JbzYwZnNSQ0RmbmFZ?= =?utf-8?B?QmhReEpwdkZ0enRpMnJPQ2o1SVIzTEVpYzhlT3JuaWEvN3c5ODlDVDV0eW1y?= =?utf-8?B?WkFSK2dsN2FkUU9ZVG0yOVpBQjBCM2F5eCtqblppNHJsMmZydDdUbUt3QkY5?= =?utf-8?B?T1RCL1U2bm1mRDNRUGN4Qk9iOFJjM3NOSVh0dCtsWTZMOUN4QjJOUHBualhX?= =?utf-8?B?bHN3dG44NHQwbW9HTlRsNXh1ODdzYnpXaC8xMlRkQ1g0T3JhOFk5a0cycnRR?= =?utf-8?B?TUNHSGdlSVdlZTc1TGlzVjFUN2I4MVRnSTkxVVZtRnh2dkdqaFlwLy9QSkt1?= =?utf-8?B?aFNOVDlGRzg2Tm1iZlhPam50aFVFdUEyS29QTkFzUHphelZzZXFsb1FIbmwr?= =?utf-8?B?bHRRd3ltYzA1RjdPcmpKaHdDS2Q4ZC9Sa1dOeGdzM3ZjTnVIMWk0ajBLTmtv?= =?utf-8?B?WWZscElFdytDTjlVVGFxRnVCWGtJQ3lib1BBM3UzTEh5QkRYelNVM0xJSDhW?= =?utf-8?Q?jWQW/C?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(376002)(346002)(396003)(199004)(189003)(58126008)(66574012)(86362001)(81166006)(81156014)(31696002)(31686004)(85182001)(110136005)(186003)(5660300002)(64126003)(14454004)(316002)(6116002)(85202003)(229853002)(106356001)(3846002)(6486002)(66066001)(65956001)(65806001)(97736004)(256004)(6246003)(76176011)(54896002)(6436002)(105586002)(236005)(6512007)(476003)(446003)(6506007)(7736002)(386003)(11346002)(52116002)(71190400001)(71200400001)(36756003)(2616005)(53936002)(99936001)(6346003)(2906002)(68736007)(102836004)(478600001)(486006)(93886005)(8936002)(26005)(65826007)(25786009)(8676002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4626; 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: cWqiVJtVH54D1w6ff8KgXBfhIMEIYiV/rGeInExE0jdwt9vzU+WfQxUgMLD1J7P038xXvdJYQosNl7furXnNTMu41RuuXul+YLA0E5V+TgxmSAMObe+7D9XqYQsasMYG4bNXl4fk9PAnf86bwgVrVQ1WIRUrY6J1yYTMkmgttxT8m8qdtWnFeGwIZ2JjF0BJ9tqTxidYmo7VO7TttTApQoRayofzc4JiBWVsD20i8B8HsagPNX+U4dVebJdhWG7+1dzsE7aWIZvBW0YDjDI8zX6c7gU6mtJyhZD4inKMPJm2YNjmq/xV8UmmuPW620jUR9cI3Px0pzAKSR9ZZY6Q9nj1m8H/mSIUl7Q6J/00hfBeHbuMkqnPoKA8g43E0p7pFyqMqRnTxy3ZDDmmC18e0YGNYt5MODg4ilkN6/1rBwY= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070701060407000105020800" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aec92b21-550b-4089-c729-08d698c39885 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 12:45:16.6364 (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: AM0PR07MB4626 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/fe3TtXg9Oc+suyx8gQKzN7sB5YasX+KEqCqDBy5C1N3WTX IqVAxQe6xPVQdD10KkPULM3MKLSZvRE0w0yzNJdW4nqolWnZtlNR/32+5/M7v9/5wRHTsgzW Uxylied1GnWMgpUwBbuvJyx9adOG+Z9u8VH2Nhs55UhyJqPU6wc4ZWFbskiZ0jjGKu/ca6c2 sqobxh5OVVo6Tqm6Oyc5VVL6PZGq+nsJo0rNaWN2sHsl6yP4mKijvG5ZYLgkcsRiEMV92HSs 1TDKJqGWwCzkIga8EjLe9IiykEQsw80ImgfqKRK+ILhcPsX8DWbrbURCKQVVBZdYR2CwgYbO FyM0MacpqJts4Eh4jeDt+TzaMYbFmyDD1ujsLMdpFGRXlTmFK94I+txeJ8txELSnP2UJrwXr cCXnYAZ7Q42p33kuxRvggamHJROuUDD+pQE5hAveDubsqyIHI+wOXx9VUg6msQd0WQspsqwc +toes4Td4F3/TxFhBeS/73KyG94HV8/mOvcBnIvAZuumSdESaHlmRYS94Emh/jdvg1dnBhG5 0I+gvPfU766+oB+oZol45QrfOi4wRETDxW81HOE5kJfymDWgZcZ/Xmu036FxJoLUjz84o3Pv mfCwwMoYkdguFoE5TfF/vYMXg9k0RBNeB/nfLSzhBXBW38cRXgVDdz8hwivAXPWDLUKScuQm 8IIQeyggwI/XRR0QBK3GT8PH1yD7l7TUTqytR5bBoCaExUgxQ7r5uTZMJlIfFRJim9BCe5/X VypakSej0Wp4hVw6bdCupRHqhERep92vOxLDC01otphReEgnZTPDZPiQOp6P5vk4XvfHUmIX zySUeWJnUbFJZQjGo6urfOe5HS/piJtfFF0ReTDkXHtec58lduI40x8qNGb47plSjHUG58wK rw3J9j55c3zLxdDq4M0bSor99D7XVPKtc/J+anhXz/qe1jTT2+IVH/P9K4fL5gXfSgxJN8x1 t9Xx4/dnH941PfwlE7TG6+Tqz0nJmZXdCkaIVC/3pXWC+hc1nQQQmgMAAA== Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 12:45:24 -0000 --------------ms070701060407000105020800 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

I am not asking for a change, but ...

IMHO it would be better if YANG would not allow whitespace in enum names.
It is a rarely needed freedom that degrades usability and can lead to mistakes
and higher tool development costs. So it is bad for both people and tools.

regards Balazs

On 2019. 02. 22. 12:07, Juergen Schoenwaelder wrote:
On Fri, Feb 22, 2019 at 10:5=
5:31AM +0000, Bal=C3=A1zs Lengyel wrote:

Do people really use enum =
names with whitespace within?
I always had the feeling that the name of the enum is like an identifier,=
 so
it should follow maybe not the exact same but at least similar rules.

When such an enum name is translated into a programing language AFAIK the=

translation needs to replace the spaces with something.

Not just spaces. Tool implementors will have to address this and what
needs special handling varies from target language to target language
(some target languages or implementations of target languages also
have interesting length contraints).

I think it is fine if BCPs like RFC 8407 provide guidelines that
people should avoid characters that are likely to be problematic but
the YANG specification is relatively clear that YANG itself puts
little constraints on such names (and hence tool makers in charge
to handle this).

/js


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms070701060407000105020800 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIyMjEyNDUxMlow LwYJKoZIhvcNAQkEMSIEIC7AviyPXymriOcj5HT14PhPFBm/oXoFYH0bf9bE/CWvMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAIwIXXN30atDE2lh1iuIzvTnOqQzXxfSAj96aLmqy3P+YTw6 TO1pqyVi8Q8SDz9egFGqqcPQGm4HX/Np32KuUKaQVgI99COq4WJ2IfalBVlecrB8adXEMIEd rDSu/HnGS/UxnBZ1NUxYTYVVe3IIWMSmhX+YPRhpBvHaKYVzE4uCysdqD9y3ahx+iRY7sobj 0i5/4RWWOzxZ/mEC7e2OEpdpD83hEWA82gn0dXoKTBDYZ1fF6QHTqXIZE/jliG/F8dC+wVho Mzxmgj0+ZL+91c0OkcDuSu377l0kTZ1me1hHzRJHKHgP3O0HgfclCS5imDAx/2neRiYcEZz2 ddgRzMEAAAAAAAA= --------------ms070701060407000105020800-- From nobody Fri Feb 22 05: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 53301129619 for ; Fri, 22 Feb 2019 05:15:56 -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 c_UrfeOyBJFJ for ; Fri, 22 Feb 2019 05:15:54 -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 763B1128766 for ; Fri, 22 Feb 2019 05:15:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E6EC56CF; Fri, 22 Feb 2019 14:15:52 +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 G5oBVDizWtaW; Fri, 22 Feb 2019 14:15:52 +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, 22 Feb 2019 14:15:52 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id C95A320058; Fri, 22 Feb 2019 14:15:52 +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 e0t3Y12Yc4Gl; Fri, 22 Feb 2019 14:15:52 +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 4787320057; Fri, 22 Feb 2019 14:15:51 +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, 22 Feb 2019 14:15:50 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 4AE2830069D26F; Fri, 22 Feb 2019 14:15:49 +0100 (CET) Date: Fri, 22 Feb 2019 14:15:49 +0100 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel CC: Andy Bierman , Martin Bjorklund , Ignas Bagdonas , Peter Loborg , Warren Kumari , NetMod WG , RFC Editor Message-ID: <20190222131549.4jetuckdsectna5h@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , Martin Bjorklund , Ignas Bagdonas , Peter Loborg , Warren Kumari , NetMod WG , RFC Editor References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> <20190222110756.bsggrzyxjtft7heg@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: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) 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] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 13:15:56 -0000 On Fri, Feb 22, 2019 at 12:45:16PM +0000, Bal=E1zs Lengyel wrote: > I am not asking for a change, but ... >=20 > IMHO it would be better if YANG would not allow whitespace in enum n= ames. > It is a rarely needed freedom that degrades usability and can lead t= o > mistakes > and higher tool development costs. So it is bad for both people and = tools. >=20 > * It is misleading, as a human user can mistakenly think that "thi= s is > legal" is actually 3 separate values > * Some tools tend to consider spaces as separators > * When creating code from YANG this needs special handling > Banning white space may make you feel better but it does not really solve the problem for tool makers. There are many more restrictions and going for the most restricted minimum gets us back to really limiting results. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 22 06:33: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 CC17412941A for ; Fri, 22 Feb 2019 06:33:50 -0800 (PST) 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 X_OR5QcpPGgG for ; Fri, 22 Feb 2019 06:33:48 -0800 (PST) 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 3F65A1200D7 for ; Fri, 22 Feb 2019 06:33:48 -0800 (PST) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 05ABD6295B; Fri, 22 Feb 2019 15:33:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1550846026; bh=YW0sT5qi9MFdRp11X1WPaveDbsGDN7heWKP5aoJ58zE=; h=From:To:Date; b=lSwC8H8gDBlFV0az9oAw17RQQ6IY2nK0hdKMPbjyILD5PGlsJ8DvixOKtQhYDqQDb RjWYoDc1vQGTaUSj9tbpYdMm4J3OpcqCU1k2MVnmhACenjF9YOuJEBtbgKOO5qdAO+ S/Elu2oMecGw8X55qQ1isiwCuyDf1dRI0bn9zgIM= Message-ID: <3ddcd6b5917b6c93078fcc02ecabd5ec475a25e9.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder , =?ISO-8859-1?Q?Bal=E1zs?= Lengyel Cc: Ignas Bagdonas , NetMod WG , Peter Loborg , Warren Kumari , RFC Editor Date: Fri, 22 Feb 2019 15:33:44 +0100 In-Reply-To: <20190222131549.4jetuckdsectna5h@anna.jacobs.jacobs-university.de> References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> <20190222110756.bsggrzyxjtft7heg@anna.jacobs.jacobs-university.de> <20190222131549.4jetuckdsectna5h@anna.jacobs.jacobs-university.de> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 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] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 14:33:51 -0000 On Fri, 2019-02-22 at 14:15 +0100, Juergen Schoenwaelder wrote: > On Fri, Feb 22, 2019 at 12:45:16PM +0000, Balázs Lengyel wrote: > > I am not asking for a change, but ... > > > > IMHO it would be better if YANG would not allow whitespace in enum names. > > It is a rarely needed freedom that degrades usability and can lead to > > mistakes > > and higher tool development costs. So it is bad for both people and > > tools. > > > > * It is misleading, as a human user can mistakenly think that "this is > > legal" is actually 3 separate values > > * Some tools tend to consider spaces as separators > > * When creating code from YANG this needs special handling > > > > Banning white space may make you feel better but it does not really > solve the problem for tool makers. There are many more restrictions > and going for the most restricted minimum gets us back to really > limiting results. I agree. It is not terribly difficult to support enum names containing spaces in any programming language. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Feb 22 07:26: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 D71C612D7F8 for ; Fri, 22 Feb 2019 07:26:32 -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, FREEMAIL_FROM=0.001, 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=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 ISzWCITFWcXC for ; Fri, 22 Feb 2019 07:26:30 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 A65461276D0 for ; Fri, 22 Feb 2019 07:26:29 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id z84so2326567wmg.4 for ; Fri, 22 Feb 2019 07:26:29 -0800 (PST) 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; bh=5xEv3ivEKQw9LToadteKu7nb0t1vQb6JlxxxNn1U+Lc=; b=aU8vFNaLv7MqsA4Uj3R2wXcdIUyabeO7OZa0apnN0K3GTb77iXiGxSIOjMcJ309WVO e1ZUWxsfW+BPuV4d/c+PgsStc1AsIQtvU5HRnoWjJ4RI9vlRCD4xTUWcx3jf9IopGs/d jAyM7Ssa8TsJtqtvs/TSkxf5BPuFPgtlXCzpV35ihpsChpM/TujtvbydmowkDi0EP9Wh yT5iEz6qbmIBK/o7uiCabcQtE3xeD8wFdNWE3DJSm8DiMMDLD3+04wX8WcYyfL8br4u5 QP5HLZGwxGZ+1oylT5IxY0zfGoIG3GBX+HztpH+Opq9YYCp+4SfOyAApOS1ZE2Y4IG4u keBw== 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=5xEv3ivEKQw9LToadteKu7nb0t1vQb6JlxxxNn1U+Lc=; b=e8nqrirhGrQmk74e89VHW6DZkSw6ftXJ1HpHhBUTRzDfNerW0ZfGlAZhGQEO0DHxax 5jY9fWnTfKGbDaMxCFgHX3NoJV7RwDKVp8hP/P3lYAeFWakwHdSgizM+KLEL9biywaxv Al9ajiL0CG32kCQIfTe9MZKd+sEHwZP69A0cyo2wGmSai2Z8ORyz4rpP/vDgUoHfLh45 LkVJW2gNKV48o2nH6P5KWLjp0I+mm58efH4eUVN/pSXwFAqnwd+e/RD6jC22NTxC8WpC 1B8gZU9qwd50XF9Fy8+xH2xKct9BjLHkCmPsJV84p0IW3v9AtOPpQIfbe/7uyG+xEp/B FJtA== X-Gm-Message-State: AHQUAubmeUpGyCezZ/z7LlHoZMI/SX+ceq7/qFRvsKqgurU1XkC7lCfK /1v+/qIyBIeppOLh90Rr6RGlpxAnPyKbcx60i5g= X-Google-Smtp-Source: AHgI3IbDct8/KDu2Am3FhnGGkFN/+xGHZkCmSe/9m042qOJX/qUx0tQRdeCbAUPLBsBPERE/kmKA3vHfzZgj0jcY4Z8= X-Received: by 2002:a1c:9692:: with SMTP id y140mr2959109wmd.67.1550849187847; Fri, 22 Feb 2019 07:26:27 -0800 (PST) MIME-Version: 1.0 References: <019501d4c906$e6fcc920$4001a8c0@gateway.2wire.net> In-Reply-To: <019501d4c906$e6fcc920$4001a8c0@gateway.2wire.net> From: Shiva Kumar Pathori Date: Fri, 22 Feb 2019 20:54:32 +0530 Message-ID: To: tom petch , netmod@ietf.org Content-Type: multipart/alternative; boundary="000000000000f1236905827d36a1" Archived-At: Subject: [netmod] Yang model for setting system startup information for software upgrade 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 Feb 2019 15:26:33 -0000 --000000000000f1236905827d36a1 Content-Type: text/plain; charset="UTF-8" Hi Tom, Thanks a lot for providing your opinion. Actually this new YANG model is similar to the one defined in rfc7317( ietf-system@2014-08-06.yang) and mainly will be used for Network node management. This will help the administrator for network automation using the YANG model as current method of upgrade may be through CLI. We have below container in this YANG model that give the information about the current system state > /* > * Operational state data nodes > */ > > container system-state { > config false; > description > "System group operational state."; > > container platform { > description > "Contains vendor-specific information for > identifying the system platform and operating system."; > reference > "IEEE Std 1003.1-2008 - sys/utsname.h"; > leaf os-name { > type string; > description > "The name of the operating system in use - > for example, 'Linux'."; > reference > "IEEE Std 1003.1-2008 - utsname.sysname"; > } > leaf os-release { > type string; > description > "The current release level of the operating > system in use. This string MAY indicate > the OS source code revision."; > reference > "IEEE Std 1003.1-2008 - utsname.release"; > } > leaf os-version { > type string; > description > "The current version level of the operating > system in use. This string MAY indicate > the specific OS build date and target variant > information."; > reference > "IEEE Std 1003.1-2008 - utsname.version"; > } > leaf machine { > type string; > description > "A vendor-specific identifier string representing > the hardware in use."; > reference > "IEEE Std 1003.1-2008 - utsname.machine"; > } > } For example the leaf os-release current value is 2.0(returned by the device through NETCONF operation) and now the system administrator would like to upgrade to a new value 2.4. So I feel the ietf-system@2014-08-06.yang does not provide an option to change to different version. I just thought that the new YANG model can bridge this gap. Also most of the devices will have the same set of information(new image, config file, paf file and patch) as per my knowledge. Regards, Shiva On Wed, 20 Feb 2019 at 15:59, tom petch wrote: > > ----- Original Message ----- > From: "Shiva Kumar Pathori" > To: > Sent: Tuesday, February 19, 2019 1:40 PM > > > I think there is a need to extend the ietf-system.yang or have new > model to > > get the current system startup information(like current system > software > > name, configuration file name, paf file name and patch file name > etc..) > > from the device and also set the next startup information for upgrade. > This > > can help the device administrator during system upgrade scenario to > operate > > with the YANG model. So first step will be copying these files(image, > > config file, paf file and patch file) to the device and then set the > next > > startup information. After this YANG RPC > "/ietf-system/system-restart" > > can be used to reboot the system to upgrade to the new version. > > > > I request the WG to provide the opinion on this. > > Shiva > > The IETF is good at protocols, what must go on between boxes of > different origins else they do not work. The internals of those boxes > have no such need to be standardised and while the IETF does delve into > those areas, e.g. Host MIB module or, arguably, much of the routing YANG > module, it is less successful because, well, there is no need for them > to be standardised for the Internet to work. > > So, a YANG module for startup information would need find common ground > between, say, iPhone, Juniper router, Windows 10, Linux distro and so on > when those products work quite happily with radically different views of > what is needed. I recall one discussion which failed to get agreement > on what the order of precedence of the fields version, release, level; > different manufacturers have different interpretations thereof while any > one manufacturer will likely be consistent in their usage across a wide > range of hardware and software products. > > Thus it seems more likely an area for proprietary extensions than for > the IETF. > > Tom Petch > > > Regards, > > Shiva > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > --000000000000f1236905827d36a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tom,

=C2=A0

Thanks a lot for providing your opinion.=C2=A0 =

Actually this new YANG model is similar to the = one defined in rfc7317(ietf-system@2014= -08-06.yang) and mainly will be used for Network node management.

This will help the administrator for network au= tomation using the YANG model as current method of upgrade may be through CLI.

=C2=A0

We have below container in this YANG model that= give the information about the current system state

=C2=A0

=C2=A0=C2=A0=C2=A0 /*
= =C2=A0=C2=A0=C2=A0=C2=A0 * Operational state data nodes
=C2=A0=C2=A0=C2=A0=C2=A0 */
=C2=A0
=C2=A0=C2=A0= =C2=A0 container system-state {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config false;
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "S= ystem group operational state.";
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= container platform {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Contains vendor-specific information for
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identifying the system platform and operating system.";
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 reference
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "IEEE Std 1003.1-2008 - sys/utsname.h";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 leaf os-name {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 type string;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "The name of the operating system in use -
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for example, 'Linux'.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 reference
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "IEEE Std 1003.1-2008 - utsname.sysname";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf os-release {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 type string;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "The current release level of the operating
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 system in use.=C2=A0 This string MAY indicate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0the OS source code revision.";=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reference
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "IEEE Std 1003.1-2008 - utsname.release";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf os-version {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type= string;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 descript= ion
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &= quot;The current version level of the operating
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0system in use.=C2=A0 This string MAY indicate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 the specific OS build date and target variant
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 reference
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "IEEE Std 1003.1-2008 - utsname.version";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf machine {=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type string;
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "A vendor-specific identifier string representing
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the hardware in use.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 reference
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "IEEE Std 1003.1-2008 - utsname.machine";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0

For example the leaf = os-release=C2=A0 current value is 2.0(returned by the device through NETCONF <get> operation) and now the system administra= tor would like to upgrade to a new value 2.4.

So I feel the ietf-system@2014-08-06.yang does not provide an option to change to different version.=C2=A0 I just tho= ught that the new YANG model can bridge this gap.

Also most of the devices will have the same set= of information(new image, config file, paf file and patch) as per my knowledge= .

=C2=A0

Regards,

Shiva



=C2=A0


=
On Wed, 20 Feb 2019 at 15:59, tom pet= ch <ietfc@btconnect.com> w= rote:

----- Original Message -----
From: "Shiva Kumar Pathori" <pathori@gmail.com>
To: <netmod@ietf.or= g>
Sent: Tuesday, February 19, 2019 1:40 PM

> I think there is a need to extend the ietf-system.yang or have new
model to
> get the current system startup information(like current system
software
> name, configuration file name, paf file name and patch file name
etc..)
> from the device and also set the next startup information for upgrade.=
This
> can help the device administrator during system upgrade scenario to operate
> with the YANG model. So first step will be copying these files(image,<= br> > config file, paf file and patch file) to the device and then set the next
> startup information. After this=C2=A0 YANG RPC
"/ietf-system/system-restart"
> can be used to reboot the system to upgrade to the new version.
>
> I request the WG to provide the opinion on this.

Shiva

The IETF is good at protocols, what must go on between boxes of
different origins else they do not work.=C2=A0 The internals of those boxes=
have no such need to be standardised and while the IETF does delve into
those areas, e.g. Host MIB module or, arguably, much of the routing YANG module, it is less successful because, well, there is no need for them
to be standardised for the Internet to work.

So, a YANG module for startup information would need find common ground
between, say, iPhone, Juniper router, Windows 10, Linux distro and so on when those products work quite happily with radically different views of what is needed.=C2=A0 I recall one discussion which failed to get agreement=
on what the order of precedence of the fields version, release, level;
different manufacturers have different interpretations thereof while any one manufacturer will likely be consistent in their usage across a wide
range of hardware and software products.

Thus it seems more likely an area for proprietary extensions than for
the IETF.

Tom Petch

> Regards,
> Shiva
>


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


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

--000000000000f1236905827d36a1-- From nobody Mon Feb 25 14:21:50 2019 Return-Path: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-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 B9AE4131112 for ; Mon, 25 Feb 2019 14:21: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, 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 zdkkq4KKtqqr for ; Mon, 25 Feb 2019 14:21:42 -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 D935813113E for ; Mon, 25 Feb 2019 14:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551133300; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=osZ0SPuh1OPDOSo4sI3cuUsCQ227IJCaLO2nEZvKYUw=; b=dp8P/+Y4mvxXw/p0jFFzKM5xKR3K82P9NgKAA8uE65FxY2ImYgNhYkOJONsTnFFG eWQEPpr5csT3ql8ETsrtieh2COibNCVERiEbmvJuer63owwV9V9jUhb5fkx4N6lyA/A 9il0wvCSWiXFKnhIYHWR4Iv+ixy+wAgeu6BQdgG0= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_B5C70942-29B6-420A-A7A1-6AB6D822B392" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> Date: Mon, 25 Feb 2019 22:21:40 +0000 To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.25-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [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, 25 Feb 2019 22:21:49 -0000 --Apple-Mail=_B5C70942-29B6-420A-A7A1-6AB6D822B392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.=20 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 --Apple-Mail=_B5C70942-29B6-420A-A7A1-6AB6D822B392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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).
  • It is misleading, as a human user can mistakenly think that "this is legal" is actually 3 separate values
  • Some tools tend to consider spaces as separators
  • When creating code from YANG this needs special handling

Thoughts?

Kent // contributor


= --Apple-Mail=_B5C70942-29B6-420A-A7A1-6AB6D822B392-- From nobody Tue Feb 26 05:43:43 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 C7318130E5D; Tue, 26 Feb 2019 05:43:34 -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.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <155118861476.11970.14018786711883969894@ietfa.amsl.com> Date: Tue, 26 Feb 2019 05:43:34 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-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: Tue, 26 Feb 2019 13:43:35 -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 Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-02.txt Pages : 24 Date : 2019-02-26 Abstract: There is a need to document data defined in YANG models when a live YANG server is not available. Data is often needed already at design or implementation time or needed by groups that do not have a live running YANG server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the reply to a operation/request) and decorates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-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 Tue Feb 26 05:47: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 0430D130EA2 for ; Tue, 26 Feb 2019 05:47:36 -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, 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_MED=-2.3, SPF_PASS=-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=ZzeYgxEg; dkim=pass (1024-bit key) header.d=ericsson.com header.b=O1khGztx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxdQqtDL1QlP for ; Tue, 26 Feb 2019 05:47:33 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3597E130E5D for ; Tue, 26 Feb 2019 05:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551188851; x=1553780851; 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=GWQgstOwYRAV/L+hCWtdUmqspf/N7VqowHIDewqD6fc=; b=ZzeYgxEgQTP2PSQKrpBfwRoV9LtyyZO/AXnJKO3TV47YMwPJGex61jngAsB8Rdhc nd2kbF+apFtGHei+SheL+Wb6ht0DONLgDURAQpuAxM6Yir4Nwp4JWdyfWStMAWsx fArBltrrfUeAa+kSD3TTEju+HwfHxSX+EQgQm7ads4g=; X-AuditID: c1b4fb25-da1ff70000005ff7-bc-5c754373b49e Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.C1.24567.373457C5; Tue, 26 Feb 2019 14:47:31 +0100 (CET) Received: from ESESSMR501.ericsson.se (153.88.183.108) 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; Tue, 26 Feb 2019 14:47:31 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMR501.ericsson.se (153.88.183.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 26 Feb 2019 14:47:31 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) 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; Tue, 26 Feb 2019 14:47:30 +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=GWQgstOwYRAV/L+hCWtdUmqspf/N7VqowHIDewqD6fc=; b=O1khGztxzwuPtiDh7lMyPd49XdmVWsyt2xF99qmzplr2wRa8P/IZvGm1KmmpbvIgBr6sy2dgRAndl8uV8OjAwgFUSV2MVfpG47niUk4Lr/ZRvW6tsOoRMuAusD4Ye8bAYOHYxBLCNT3OuCYZju/yWeBgs9yVm8px+KxRhgNd2J4= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB6145.eurprd07.prod.outlook.com (20.178.112.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.5; Tue, 26 Feb 2019 13:47:30 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd%2]) with mapi id 15.20.1665.012; Tue, 26 Feb 2019 13:47:30 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-ietf-netmod-yang-instance-file-format-02.txt Thread-Index: AQHUzdlMqHBP1sZm40+XnUZ5jzY+0qXyF+oA Date: Tue, 26 Feb 2019 13:47:30 +0000 Message-ID: <712ffeee-5f0c-640c-6d38-0cd4b9e9e495@ericsson.com> References: <155118861491.11970.7370021759300969602.idtracker@ietfa.amsl.com> In-Reply-To: <155118861491.11970.7370021759300969602.idtracker@ietfa.amsl.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] x-forwarded-message-id: <155118861491.11970.7370021759300969602.idtracker@ietfa.amsl.com> user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 x-clientproxiedby: HE1PR0402CA0023.eurprd04.prod.outlook.com (2603:10a6:3:d0::33) 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: 86eefbe7-42f1-47f1-1b4c-08d69bf0f363 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:AM0PR07MB6145; x-ms-traffictypediagnostic: AM0PR07MB6145: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA3TUI2MTQ1OzIzOmJXNDdwaHpmOE5OY3RFbjhabGVKL1BERlZi?= =?utf-8?B?cmtPelNyYWxLMGp2TkFOckcxNVZOYjhoK1c1R0srZmYzdTZ3YTAxYzhkYnJT?= =?utf-8?B?OUpIRHpGV0c2R2tqSWVJcjVUYjhZbWFDN0s0RUk3bHlxZWExSXZsenEyMDln?= =?utf-8?B?RjF4S3pqOFFpT2Z2bXhHVW5Ia3h4YkVQODVFcWlrV21PMlMvU2Q5Z0VLOGNs?= =?utf-8?B?emlJaWg4NWpnT2RnR1c5dHNGVmNvQ3FnWFpGRGQ4dGtTZjNYZ1lKVGRaZnpj?= =?utf-8?B?L3g2ZlQvOEs3VmpBZGgzRWdEL00xbTU3ellTbTA5TDZaZC9wU1kwbWNVcExW?= =?utf-8?B?aFNmUFNKdVY3ME1jQ2ZCZktDNWZydkdXbDFJYzkxMXFLM2hJWWsvWTcrd3BM?= =?utf-8?B?cmJKR3ZjVklpa21qUVJLd2IzSGNkR09haEFzTXBTbjlsaXFCcU8rUlJCME11?= =?utf-8?B?U29FRVdpQUFETVZxdFZQem41ZVViZnZVNFdHSzlOWjZKVlk2dE1BZUtKcDAr?= =?utf-8?B?TWFsVVE4TmRPamg3UkFGZ1R1TzcwUW1LMGVQVTRkSEUxZWNuSGF6Q2JXemN4?= =?utf-8?B?aThZWHh2MEhEMndmb3hZL3k5TG1sQ3lsajJkOUhFTUxFdlo2VEs5NlFSYW9T?= =?utf-8?B?a1lkT3NVZnU0OXFxOC9FSEVkNE1RQ3dkSFd1aWNNNks3UEIvR3JwbWlXYUJm?= =?utf-8?B?d2VsSm1tT202WFp4RGNNT3I1OGE2THhwUWJTZXcxYjgza2pLOTJWSlpwOUV5?= =?utf-8?B?MTRBMGZkT2dOM21XOXFYcXhCNHF4UWRYVS81REw5Qm5mRTB0dWRnVFJEWnVU?= =?utf-8?B?eHRHRjBFblFFeFBJMnEzOUgxSjZxRGJWblBZemtrQ2NkRW5zb0FPRlY3MFdi?= =?utf-8?B?MFFsN2lpaXAwaGF3azlzcGVMQmgzTms3Sk9peGFIRjNxUkFvWUJSby9zaUFu?= =?utf-8?B?U3hTcVZ0SE1SZzV0Q21SVHVCODhuaUlMaFExbkR2WU9jY3M2Q0lScXBTckxD?= =?utf-8?B?QUxWRVZPeG9oejlwdnpQVHQ3WFRWNzY5VGJvb1M5SW14THZVTFhLZGo2YzQ4?= =?utf-8?B?TDBwNEcrVEVXZ3NteFIvdURmWlhWUWdYcmZ5bUlVL3grZjF3QlZsMlFhbFBx?= =?utf-8?B?SVV2WlFQOWpSVG9Wdmh6bFdpWGM1UlIyVnp4NFdObENXa0Uzc0ZyNVFBRmVy?= =?utf-8?B?b1pEN1paMjVqTXVZTGU3S1hlM3J3SFZ3ekxoaitBeUQwV0dpODh2dlVvZUFG?= =?utf-8?B?R2hZa1VEeFczV2cyYm9OOVN0TCtHbnpUQ1MreFFxM3VPdGFVMkRZUG9xeHVS?= =?utf-8?B?OGF5S3IwVW9ud29HNHFveGwyUHpubXhCRzZWbTRoR3dxdW5XZTVGaXdIMW40?= =?utf-8?B?YXZML1hVelp6SXhOekpmdW5LZFlsdkhqNVBGcmxzMjJXYi9WcERkbXhnd2o5?= =?utf-8?B?UGkyTDR6emF3RDFuK1I4aWhuTE8yUGZWL2JJZkhGRGt1OEduSWpTb3ovYTI5?= =?utf-8?B?RmZDRS9UUTBQN1VqdFlPTFFDMkIrUnF0OFg2ZDloNGlmeitESFJzUlVDVmJw?= =?utf-8?B?alBhbDl5MVpoMllOYjJsQjNFZXNWaXNLaVNYL0k2dTlDQ2d4QzdCQm1oelhU?= =?utf-8?B?cDREbnhxL2h3QUdUeFd2LzI1SU9JTnpLTmhUZHNxWm5ZL2t3V3Y5dXlKOGd3?= =?utf-8?B?OHpsVTlPanhNdUpsRnh3NktIUDMzNGVQL1MzajFXeGdLTWV5S21leitBQnM2?= =?utf-8?B?dlBIU2V3UGF6dFdCV0NVRE5tUHB2YUl1YXNzVzdIUlR5Z0YrMzhSRHNuRjNC?= =?utf-8?B?aEIxYVR6Qmc4YzNXcDhFL2EvUXdwZmU4dkNhUC9OdG5IVGF5Yzkzck84enBl?= =?utf-8?B?UThrN0pSSjZxN3hKTkdtUXdoejRwa0p2aFlQeEc2TlJ5YVNZMWpPSVhPTXpk?= =?utf-8?B?czZjdzJ1eVcxNjNwR21XRFN1Y0NXTFlHYXVFR2gxUjYrY1NkNHR4VHU1WWla?= =?utf-8?B?UnFkRmlTUzQxQ0tDOVl1Nm1nSE5Wa3JvcnFPMFNLYjIzQXJmTG44aFhaZXUy?= =?utf-8?B?bmszWFRvNXpSSU9sbTB6a1lJRGNHbHBsbzMxa2hldnBuUTRyNjB1aTYyM2kz?= =?utf-8?B?a2NYRGdJMXRjUU8zR2oyd1AxTFA5SGl2L253OFF1a21JeExta1p1TGdPQWp6?= =?utf-8?B?SkhLL0ZuNUZiSGpIaGkxUUhqSit3PT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(39860400002)(346002)(376002)(199004)(189003)(97736004)(446003)(8936002)(26005)(6436002)(476003)(6346003)(229853002)(7736002)(486006)(11346002)(386003)(6506007)(6486002)(102836004)(31686004)(99286004)(186003)(106356001)(85202003)(2616005)(2473003)(236005)(85182001)(6512007)(99936001)(65826007)(54896002)(66066001)(53936002)(65806001)(65956001)(5640700003)(105586002)(71200400001)(2351001)(76176011)(6306002)(5660300002)(66574012)(52116002)(71190400001)(2501003)(2906002)(316002)(81166006)(81156014)(478600001)(68736007)(14454004)(86362001)(15650500001)(966005)(3846002)(6116002)(6916009)(36756003)(64126003)(8676002)(14444005)(606006)(256004)(25786009)(58126008)(1730700003)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6145; 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: KBOuCNIxdbq7CbGVR+uTnpGHvucsXBoGxnmbf5NuvhmPYUcgsGKln7VfnSH0HArYCQjXHFBSEibyCku0dvlujgvWt2eOaIIVkzWMN7pNt+oLirby/ZP0hxQOODbdLLiOMg5ArxcfAUrP89G9nJqh5KjiT/gg1PgxjKR0bj0OnaxdhDcirpSO1ROVjCE8exM7o5dY8igmeA2s2XQfb7tSpGw7E6D3nyDUN3NxhsGe53tccRE9/zSWWJS+TI8CX+t8sNfKfVF7CFbQd//adzGiMTNqOjLzuP+PX6/eyMGuuGasBbLEgw4Y6opJHdcbluoLuCv8byTDSOyYBhkPRn4l66xRKhCy1jicALWOknO5p7qRNYLotXEGZjeuQXYumivU9Ypmh2yT/eAwDkTQTYu0GytDWL4lQtLHlOlA9KT3oWY= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080304000705020706050808" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 86eefbe7-42f1-47f1-1b4c-08d69bf0f363 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 13:47:30.0310 (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: AM0PR07MB6145 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0iTYRTHe/a+m3M4fFxOD0YfGmlgZV4qgjJb+SEosyAkb9jUNxXn1L1T UwjMDJsGXpilk7ywKaamqyxTknJkMEtqZZamhs4LzVuWGWpK294F9e13zu88f86Bh0sIjGwP bpJMQcllEqmIwyMrL3Tk7KVPZET55g+4HaoxXmUfQye12lXWWRTBOxJPSZMyKfm+oxd5icXT PZy0+ojLa+WKXHQntBA5cgHvh9K+GVSIeFwBfoHgsa6OsAoBXkGw2ZrOCAuPTLeSTKFlwaSm mmUtSFxCQJ65l8WYUhaMDT5lM8UEgjezetIaxsHBULDwjGVlV7wLKjvbOFbeimOgsWCKZPox cEOz7MCwP9xTTtv6JPaEgWUjsjIfB4FKOWpfMAR6df22TEd8Bgq/m2xvEXaDX30ttj6B3WF4 sobFXOoK48ZXHIaF8NW0yWZYBBXmYTuHw1hXpy1fiKPhoaqcsB4D+DaCpo4R+9Ae6P84iRje Du9qiuwcAsY8FYd5YEJgWnxEMMIbFqs19qRhIXz7UWdfKRkqWgxkCfJV/7Ot2jJHYCWCoZkN pLad7QKGyklSjbgW4QUN10X/z1t5NzTUzRIMH4aKtR4OwztAVTTuwPABmO1dQgwHQEPrBqcW 8ZqQkKbo2JQE/wAfSp4UR9OpMh8ZpXiALJ+rp33d8wl6PyfWI8xFIid+uzgjSsCWZNLZKXq0 05IzoWt+izxIWaqMErnyP3laND9ekp1DyVNj5BlSitajbVxS5M7/LXCJEuAEiYJKpqg0Sv7X sriOHrnofHj33JZzB/0GG8cNDcX3NXNZgaf83FvMhtWp+ebNKOWX6PD5LvHa6bB157AFc2uo KTbAsS+utj5Gxr4WeoUdWf65yln8oeq5MHFdl96p9F8yBrpM5Re33Xp5/FKNdF2RdddrKP/n ijYyaLRLrytLq+pudurMCU5VlxmrVm++rhSRdKLEz5uQ05I/VsHbvGQDAAA= Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-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: Tue, 26 Feb 2019 13:47:36 -0000 --------------ms080304000705020706050808 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

A new version of the=C2=A0 draft YANG Instance Data File Format is= available.

=C2=A0=C2=A0 v01 - v02
=C2=A0=C2=A0 o=C2=A0 Removed design time from terminology
=C2=A0=C2=A0 o=C2=A0 Defined the format of the content-data part by= referencing various
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFCs and drafts instead of the resul= t of the get-data and get
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operations.
=C2=A0=C2=A0 o=C2=A0 Changed target-ptr to a choice
=C2=A0=C2=A0 o=C2=A0 Inline target-ptr may include augmenting modul= es and alternatives
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to ietf-yang-library
=C2=A0=C2=A0 o=C2=A0 Moved list of target modules into a separate <target-modules>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 element.
=C2=A0=C2=A0 o=C2=A0 Added backwards compatibility considerations regards Balazs

-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-ietf-netmod-yang-instance-file-format-02.txt
Dat= e: Tue, 26 Feb 2019 05:43:34 -0800
Fro= m: internet-drafts@ietf.org
To:= Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>



A new version of I-D, draft-ietf-netmod-yang-instance-file-format-02.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format
Revision: 02
Title: YANG Instance Data File Format
Document date: 2019-02-26
Group: netmod
Pages: 24
URL: https://www.ie= tf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-02.txt=
Status: https://datatracker.ietf= =2Eorg/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized: https://tools.ietf.org/html= /draft-ietf-netmod-yang-instance-file-format-02
Htmlized: https://datatracker.= ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Diff: https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-netmod-yang-instance-file-format-02

Abstract:
There is a need to document data defined in YANG models when a live
YANG server is not available. Data is often needed already at design
or implementation time or needed by groups that do not have a live<= br> running YANG server available. This document specifies a standard file format for YANG instance data (which follows the syntax and semantic from existing YANG models, re-using the same format as the
reply to a <get> operation/request) and decorates it with metadata.



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

The IETF Secretariat

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms080304000705020706050808 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIyNjEzNDcyNlow LwYJKoZIhvcNAQkEMSIEIJR3fUUFnGHzZOy3FUyz4brmR8frs5kWvI+5S4DsRVlZMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBACuVulIOqbWie3sArJQBaP5IGz6hHRFM77ZsKgHvyGVDHRRp oA5SRM6K5oXSfQHlo2Y8ODtI0xewdM3TEkRy8rJQLiYJ6rj9/112YepDtrBMijNCm+Ezi8CF gC1UDX4hWRJTcsjQx23BRPriGC7Rdz3llu3Ian9HoxDulWiRozvCdfg6l9bsp6EvuO39lSxS ZNlStqUDSBO5DOkXTIo4ifzijp1oY5+mitA9My4/wVEZC2nL2BTl2MEkdw7YPPt20O+4Ajl/ W+0B2W2Ey8Yt6kC7z4iXQiNig07VOPMlUOxguEa2d3ZcHFEvvdVkglPLFsDvnrmjMhzE6tNp 0pVbHbsAAAAAAAA= --------------ms080304000705020706050808-- From nobody Tue Feb 26 14:26: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 9A61C130EA0 for ; Tue, 26 Feb 2019 14:26:52 -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 8eNhTHc5q87V for ; Tue, 26 Feb 2019 14:26:49 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 3F8C0130E9A for ; Tue, 26 Feb 2019 14:26:49 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1QMQlmi015815; Tue, 26 Feb 2019 22:26:47 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 321CB2203B; Tue, 26 Feb 2019 22:26:47 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id 1CFD12203A; Tue, 26 Feb 2019 22:26:47 +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 x1QMQjoY005559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Feb 2019 22:26:46 GMT Reply-To: From: "Adrian Farrel" To: "'Kent Watsen'" , References: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> In-Reply-To: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> Date: Tue, 26 Feb 2019 22:26:45 -0000 Organization: Old Dog Consulting Message-ID: <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B1_01D4CE22.5BD913F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIdXCwF6+3Dw/Axku1x55iGoJDnF6VhisFw 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-24458.002 X-TM-AS-Result: No--19.531-10.0-31-10 X-imss-scan-details: No--19.531-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24458.002 X-TMASE-Result: 10--19.531400-10.000000 X-TMASE-MatchedRID: Jm7Yxmmj9OnxIbpQ8BhdbFPjo7D4SFg4H181YDtIVarE3grQNcpLWBYR 8SHMAtRe+jMk79vvL8wOwWXaw100i+L5N47U/H9LNNX8HVS75cIrHkgIan9a0f0TP/kikeqnLF9 jbxvK1+1BP2/NT7tdhKPCbIW4ooFkDtZgR42ZNmezI1v7J4hECjFFLhGUD8AWzPV+pffXxU/O/T 5SZgJlwxhq3QN0UjY7YrJsCrWcb8Gt4BGEUg27DVZ14JN9Kx7yf6/Md8Lb2l84kO+ca7VnMYSz4 x6Okmj/NtrqBJtuOX5YFBU0+2PUKWE2dpl/p8cM9TVembY3XZL8BlbXy+O/WjqI/Q1zONHSW+v0 m5ycBq/OQf/S1XvtEBm20HYf5Ey/CRueYusp1xz4pTO56aJ0/MMdI0UcXEHz+5+93dPb6/c3W+9 uVNwsfDXkIGZzDHWYklPOPDP4bOiuEAHkLyBnqm/+RwWenb0YwSJcbRHuoMdT+oAjVn9e0Dyrc+ h5xgzUu7C4hieFwVKAMuqetGVettUTseZWdUYe/sToY2qzpx4DOZGFGsyhFbDszp3K5gqDLVdRl lUTWIUyyNL6ySBa6XVhdBSwY3CvlKi2fr7WheHNooEVx3+DjQ== 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: Tue, 26 Feb 2019 22:26:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B1_01D4CE22.5BD913F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. 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 ------=_NextPart_000_04B1_01D4CE22.5BD913F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

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 = <netmod-bounces@ietf.org> 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

 

 

------=_NextPart_000_04B1_01D4CE22.5BD913F0-- From nobody Tue Feb 26 22:31: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 19336130E2E for ; Tue, 26 Feb 2019 22:31:38 -0800 (PST) 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 7KMfv60DLujg for ; Tue, 26 Feb 2019 22:31:36 -0800 (PST) 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 08D9B12F1A6 for ; Tue, 26 Feb 2019 22:31:35 -0800 (PST) Received: from [192.168.0.111] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x1R6VU1h092028; Wed, 27 Feb 2019 06:31:34 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.111] From: Joel Jaeggli Message-Id: <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7A68FF8B-EDA3-41E6-9E91-EC40F71B58F9" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 26 Feb 2019 22:31:23 -0800 In-Reply-To: <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> Cc: Kent Watsen , netmod@ietf.org To: Adrian Farrel References: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> X-Mailer: Apple Mail (2.3445.102.3) 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: Wed, 27 Feb 2019 06:31:38 -0000 --Apple-Mail=_7A68FF8B-EDA3-41E6-9E91-EC40F71B58F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 26, 2019, at 14:26, Adrian Farrel wrote: >=20 > Hey. > =20 > I=E2=80=99ve been having this discussion with Kent off-line, but = thought it should come to the list. > =20 > I don=E2=80=99t 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. > =20 > It doesn=E2=80=99t 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. > =20 > 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 = =E2=80=98\=E2=80=99 on continuation lines to show which spaces should be = stripped and which retained. > =20 > Cheers, > Adrian > =20 > From: netmod On Behalf Of Kent Watsen > Sent: 25 February 2019 22:22 > To: netmod@ietf.org > Subject: [netmod] artwork folding: dual support modes? > =20 > =20 > 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.=20 > =20 > 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: > =20 > NOTE: '\\' line wrapping per BCP XX (RFC XXXX) > =20 > So why not *also* support a header that reads (note the singe slash): > =20 > NOTE: '\' line wrapping per BCP XX (RFC XXXX) > =20 > Whereby this second form only supports the folded line continuing on = column 1 (no indents). > =20 > Thoughts? > =20 > Kent // contributor > =20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_7A68FF8B-EDA3-41E6-9E91-EC40F71B58F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 26, 2019, at 14:26, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Hey.
 
I=E2=80=99ve been = having this discussion with Kent off-line, but thought it should come to = the list.
 
I don=E2=80=99t 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=E2=80=99t 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 =E2=80=98\=E2=80=99 on = continuation lines to show which spaces should be stripped and which = retained.
 
Cheers,
Adrian
 
From: netmod <netmod-bounces@ietf.org> 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

= --Apple-Mail=_7A68FF8B-EDA3-41E6-9E91-EC40F71B58F9-- From nobody Wed Feb 27 01:40:51 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 D36FD130E8C for ; Wed, 27 Feb 2019 01:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4zsTrPst_Jax for ; Wed, 27 Feb 2019 01:40:46 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 48A8E130E6E for ; Wed, 27 Feb 2019 01:40:46 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1R9eXcH014823; Wed, 27 Feb 2019 09:40:33 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A437722032; Wed, 27 Feb 2019 09:40:33 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 988942203D; Wed, 27 Feb 2019 09:40:33 +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 x1R9eW6J023121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Feb 2019 09:40:33 GMT Reply-To: From: "Adrian Farrel" To: "'Joel Jaeggli'" Cc: "'Kent Watsen'" , References: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> In-Reply-To: <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> Date: Wed, 27 Feb 2019 09:40:31 -0000 Organization: Old Dog Consulting Message-ID: <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0580_01D4CE80.7BC4FC70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIdXCwF6+3Dw/Axku1x55iGoJDnFwKu0UlwAk3IamilOl96UA== 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-24458.005 X-TM-AS-Result: No--28.646-10.0-31-10 X-imss-scan-details: No--28.646-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24458.005 X-TMASE-Result: 10--28.645500-10.000000 X-TMASE-MatchedRID: Ync95tbzDRnxIbpQ8BhdbH4f9De+CyQCU1huRZDI++o4kO+ca7VnMUrt uXn9VDPoCEcZs/o/9lGXM+Lzmod/9gDNPxu11HXjbMGKOuLn5FVK0YCCYqpa5W3D6f6IpbLIS8I aTgdsIrCxHaMfifv71pcyt5zIhxG/o28kkGKrXVrpnOP6QxEGtuzysj4CurnhJLfQYoCQHFZaKh u8tq9RYrdPrkFMalw+VOEyvhz4+EKA4OBLF/NjnFPjo7D4SFg4H181YDtIVarE3grQNcpLWBYR8 SHMAtRe+jMk79vvL8wOwWXaw100i+L5N47U/H9LQpxiLlDD9FXTDXgcUlCNozIZlC8UfsZzqwwJ P5IbqG3rYUe7ynoRVKPCbIW4ooFkDtZgR42ZNmcAKzYLecaUGKGL0wLo4E7C4PMwkTni6j6VIEi 8fvjB8owNKcscIQ/gliXG6TWiBADDTqNelQn9chzwnpmtY/+r31asM/gsp2mpVUR0SvYtSsbK+p u0ZYwRBHVm0xh58VY8LuP+bOkMWt3jF2fVcPdzDB+ErBr0bANar2Wff4KSIaUXswX/xrISOe5BY zkyOSWATHNX4n1dGM63SXqIZW9ISLYOuP0pddff8GJjBXCUiCDmNS0pUbQ0Fz6fOzzqvcbE3G8+ Yjo3Xnb4Bm7FqQnLLXB+vheGgKnA+jwY/tNg22/+RwWenb0YwSJcbRHuoMfDv5dDcuT2eXtKAeF xTY2CKv3xLZTh+FBAnsaTSHT+C7NUVnqixiMODrDTQZ5YEVp9LQinZ4QefK9dKZJ2Vxiasuf7RW bvUtzPvfjkPVP+X9934/rDAK3zhG2qikEpQGX4YSCWMIUFUfNiS+WaRKxgQRYoZxG0FELOIBsEE M8xUdYxFAbKgQ7V 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: Wed, 27 Feb 2019 09:40:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0580_01D4CE80.7BC4FC70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Complete agreement, Joel. =20 What follows may look better in proportional fonts. =20 With a single slash we can wrap as follows =20 1234567 9012345 =20 Goes to=E2=80=A6 =20 1234567 \ 9012345 =20 =E2=80=A6and unwrapping is easy. =20 However, if I want to manually wrap the line with indentation =20 The quick brown fox jumps over the lazy dog =20 ..going to=E2=80=A6 =20 The quick brown fox\ jumps over the lazy dog =20 =E2=80=A6I am going to unfold as=E2=80=A6 =20 The quick brown fox jumps over the lazy dog =20 =20 Conversely, if I resolve this second case by stripping leading spaces I = get=E2=80=A6 =20 The quick brown foxjumps over the lazy dog =20 So I have to fold as=E2=80=A6 =20 The quick brown fox \ jumps over the lazy dog =20 But this causes the first case to unfold as =20 1234567 9012345 =20 =E2=80=A6i.e., with missing spaces. =20 This is what caused the use of the second slash so=E2=80=A6 =20 1234567 \ \ 9012345 =20 =E2=80=A6and=E2=80=A6 =20 The quick brown fox\ \ jumps over the lazy dog =20 =20 So, my point is, if and only if we do not care about these = =E2=80=9Cspaces on the fold=E2=80=9D cases, we can operate with a single = slash. =20 Cheers, Adrian =20 From: Joel Jaeggli =20 Sent: 27 February 2019 06:31 To: Adrian Farrel Cc: Kent Watsen ; netmod@ietf.org Subject: Re: [netmod] artwork folding: dual support modes? =20 =20 On Feb 26, 2019, at 14:26, Adrian Farrel > wrote: =20 Hey. =20 I=E2=80=99ve been having this discussion with Kent off-line, but thought = it should come to the list. =20 I don=E2=80=99t 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. =20 It doesn=E2=80=99t seem to me that both cases are needed. We can pick = one or the other. =20 A single slash has been used to wrap long lines in editors and shells = for decades at this point. =20 and yeah whatever it is one method seems better than two. =20 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 = =E2=80=98\=E2=80=99 on continuation lines to show which spaces should be = stripped and which retained. =20 Cheers, Adrian =20 From: netmod > = On Behalf Of Kent Watsen Sent: 25 February 2019 22:22 To: netmod@ietf.org =20 Subject: [netmod] artwork folding: dual support modes? =20 =20 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.=20 =20 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: =20 NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =20 So why not *also* support a header that reads (note the singe slash): =20 NOTE: '\' line wrapping per BCP XX (RFC XXXX) =20 Whereby this second form only supports the folded line continuing on = column 1 (no indents). =20 Thoughts? =20 Kent // contributor =20 =20 _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 ------=_NextPart_000_0580_01D4CE80.7BC4FC70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Complete = agreement, Joel.

 

What = follows may look better in proportional fonts.

 

With a = single slash we can wrap as follows

 

1234567=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 9012345

 

Goes = to=E2=80=A6

 

1234567=C2=A0=C2=A0=C2=A0 = \

=C2=A0=C2=A0=C2=A0 = 9012345

 

=E2=80=A6and 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=E2=80=A6

 

The quick = brown fox\

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = jumps over the lazy dog

 

=E2=80=A6I = am going to unfold as=E2=80=A6

 

The quick = brown fox=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 jumps over the lazy = dog

 

 

Conversely, = if I resolve this second case by stripping leading spaces I = get=E2=80=A6

 

The quick = brown foxjumps over the lazy dog

 

So I have = to fold as=E2=80=A6

 

The quick = brown fox \

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = jumps over the lazy dog

 

But this = causes the first case to unfold as

 

1234567=C2=A0=C2=A0=C2=A0 = 9012345

 

=E2=80=A6i.e., with missing = spaces.

 

This is = what caused the use of the second slash = so=E2=80=A6

 

1234567=C2=A0=C2=A0=C2=A0 = \

\=C2=A0=C2=A0=C2=A0 = 9012345

 

=E2=80=A6and=E2=80=A6

 

The quick = brown fox\

=C2=A0=C2=A0=C2=A0=C2=A0 \ jumps = over the lazy dog

 

 

So, my = point is, if and only if we do not care about these =E2=80=9Cspaces on = the fold=E2=80=9D cases, we can operate with a single = slash.

 

Cheers,

Adrian

 

From: Joel Jaeggli = <joelja@bogus.com>
Sent: 27 February 2019 = 06:31
To: Adrian Farrel = <adrian@olddog.co.uk>
Cc: Kent Watsen = <kent+ietf@watsen.net>; netmod@ietf.org
Subject: Re: = [netmod] artwork folding: dual support = modes?

 

 



On Feb 26, 2019, at 14:26, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Hey.

 

I=E2=80=99ve been having this discussion with Kent = off-line, but thought it should come to the = list.

 

I = don=E2=80=99t 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=E2=80=99t 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 =E2=80=98\=E2=80=99 on continuation lines to = show which spaces should be stripped and which = retained.

 

Cheers,

Adrian

 

From: netmod <netmod-bounces@ietf.org> 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.or= g/mailman/listinfo/netmod

 

------=_NextPart_000_0580_01D4CE80.7BC4FC70-- From nobody Wed Feb 27 02:10:02 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 87692131027 for ; Wed, 27 Feb 2019 02:09:56 -0800 (PST) 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 mdA8TwGISaz0 for ; Wed, 27 Feb 2019 02:09:53 -0800 (PST) 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 37CDE130FE4 for ; Wed, 27 Feb 2019 02:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36120; q=dns/txt; s=iport; t=1551262193; x=1552471793; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JwErlmtXwFVvbZ1r2btPZ1EhPCdFJXPqL1jv8Uknj0A=; b=CRUQh+43NH7ZpGfgKJpVKc0aOEoO4ZUXtgx3WDZzvLuTnjvo6m9n4VbT G69uDep33OKiCG0qnWyvUMoLXw6vRcdtvOhXr+r6O9nNCgtSoOCKViZV9 t1kRzZxa6wk6wjJ1odQJrQM3iuykmpVFqfdYYajmXgW9zYFETTDyq1eKP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAPYXZc/5BdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgQ1MKmeBAycKg36WA5gggXcECwEBGAE?= =?us-ascii?q?KhANGAheDcSI2Bw0BAwEBAgEBAm0cDIVKAQEBAQMBASEKQQsQAgEGAhEEAQE?= =?us-ascii?q?hAQYDAgICJQsUCQgCBAENBQiDGYEOZA+PU5thgS+KKwWMSBeBQD+BEYMSgx4?= =?us-ascii?q?BAYF4H4JUglcCigoPIIICg3+TKwkCkl4hkxqKXZIWAhEUgSgmAi+BVnAVO4J?= =?us-ascii?q?sgz8BCIdWhT9BMZEsgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,419,1544486400"; d="scan'208,217";a="523191495" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2019 10:09:51 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x1RA9pns012839 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Feb 2019 10:09:51 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.1395.4; Wed, 27 Feb 2019 04:09:51 -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.1395.000; Wed, 27 Feb 2019 04:09:51 -0600 From: "Rob Wilton (rwilton)" To: "adrian@olddog.co.uk" , "'Joel Jaeggli'" CC: "netmod@ietf.org" Thread-Topic: [netmod] artwork folding: dual support modes? Thread-Index: AQHUzViIs88uqV1md0esD7eI1tBXvaXzDpmAgACHaICAADTYgP//oJLA Date: Wed, 27 Feb 2019 10:09:51 +0000 Message-ID: <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> References: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> In-Reply-To: <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> 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_3af58c925ad74fbfaaea299877bf992dXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-8.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: Wed, 27 Feb 2019 10:10:00 -0000 --_000_3af58c925ad74fbfaaea299877bf992dXCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRyaWFuLA0KDQpJIG1vc3RseSBhZ3JlZSB3aXRoIHlvdXIgbGFzdCBzZW50ZW5jZS4NCg0K SSB0aGluayB0aGF0IGlmIHlvdSBhbHdheXMgcHJlc2VydmUgd2hpdGVzcGFjZSB0aGVuIGEgc2lu Z2xlIHNsYXNoIGlzIGZpbmUuICBJLmUuIHRoZSBzaW5nbGUgc2xhc2gganVzdCBicmVha3MgdGhl IGxpbmUsIGFuZCBJIHRoaW5rIHRoYXQgdGhpcyBtYXRjaGVzIGhvdyBlZGl0b3JzLCBwcm9ncmFt bWluZyBsYW5ndWFnZXMsIGV0YyBub3JtYWxseSBiZWhhdmUuDQoNCldoYXQgSeKAmW0gbm90IGtl ZW4gb24gaXMgdXNpbmcgYSBzaW5nbGUgc2xhc2gsIGFuZCB0aGVuIGF1dG9tYXRpY2FsbHkgc3Ry aXBwaW5nIGxlYWRpbmcgd2hpdGVzcGFjZSBvbiB0aGUgbGluZSBmb2xsb3dpbmcgYSBzbGFzaC4N Cg0KSWYgd2Ugd2FudCB0byBoYXZlIGNvbnRyb2wgb2YgbGF5b3V0IGFuZCBiZSBhYmxlIHRvIHN0 cmlwIGV4dHJhIHdoaXRlc3BhY2UgdGhlbiBteSBhcmd1bWVudCBpcyB0aGF0IGl0IGlzIGJldHRl ciB0byBiZSBleHBsaWNpdCwgYW5kIHVzaW5nIHR3byBzbGFzaGVzIGlzIG9uZSB3YXkgb2YgYWNo aWV2aW5nIHRoaXMuDQoNClRoYW5rcywNClJvYg0KDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNClNlbnQ6IDI3IEZl YnJ1YXJ5IDIwMTkgMDk6NDENClRvOiAnSm9lbCBKYWVnZ2xpJyA8am9lbGphQGJvZ3VzLmNvbT4N CkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBhcnR3b3JrIGZvbGRp bmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCg0KQ29tcGxldGUgYWdyZWVtZW50LCBKb2VsLg0KDQpX aGF0IGZvbGxvd3MgbWF5IGxvb2sgYmV0dGVyIGluIHByb3BvcnRpb25hbCBmb250cy4NCg0KV2l0 aCBhIHNpbmdsZSBzbGFzaCB3ZSBjYW4gd3JhcCBhcyBmb2xsb3dzDQoNCjEyMzQ1NjcgICAgICAg IDkwMTIzNDUNCg0KR29lcyB0b+KApg0KDQoxMjM0NTY3ICAgIFwNCiAgICA5MDEyMzQ1DQoNCuKA pmFuZCB1bndyYXBwaW5nIGlzIGVhc3kuDQoNCkhvd2V2ZXIsIGlmIEkgd2FudCB0byBtYW51YWxs eSB3cmFwIHRoZSBsaW5lIHdpdGggaW5kZW50YXRpb24NCg0KVGhlIHF1aWNrIGJyb3duIGZveCBq dW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KDQouLmdvaW5nIHRv4oCmDQoNClRoZSBxdWljayBicm93 biBmb3hcDQogICAgICBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw0KDQrigKZJIGFtIGdvaW5nIHRv IHVuZm9sZCBhc+KApg0KDQpUaGUgcXVpY2sgYnJvd24gZm94ICAgICAganVtcHMgb3ZlciB0aGUg bGF6eSBkb2cNCg0KDQpDb252ZXJzZWx5LCBpZiBJIHJlc29sdmUgdGhpcyBzZWNvbmQgY2FzZSBi eSBzdHJpcHBpbmcgbGVhZGluZyBzcGFjZXMgSSBnZXTigKYNCg0KVGhlIHF1aWNrIGJyb3duIGZv eGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nDQoNClNvIEkgaGF2ZSB0byBmb2xkIGFz4oCmDQoNClRo ZSBxdWljayBicm93biBmb3ggXA0KICAgICAganVtcHMgb3ZlciB0aGUgbGF6eSBkb2cNCg0KQnV0 IHRoaXMgY2F1c2VzIHRoZSBmaXJzdCBjYXNlIHRvIHVuZm9sZCBhcw0KDQoxMjM0NTY3ICAgIDkw MTIzNDUNCg0K4oCmaS5lLiwgd2l0aCBtaXNzaW5nIHNwYWNlcy4NCg0KVGhpcyBpcyB3aGF0IGNh dXNlZCB0aGUgdXNlIG9mIHRoZSBzZWNvbmQgc2xhc2ggc2/igKYNCg0KMTIzNDU2NyAgICBcDQpc ICAgIDkwMTIzNDUNCg0K4oCmYW5k4oCmDQoNClRoZSBxdWljayBicm93biBmb3hcDQogICAgIFwg anVtcHMgb3ZlciB0aGUgbGF6eSBkb2cNCg0KDQpTbywgbXkgcG9pbnQgaXMsIGlmIGFuZCBvbmx5 IGlmIHdlIGRvIG5vdCBjYXJlIGFib3V0IHRoZXNlIOKAnHNwYWNlcyBvbiB0aGUgZm9sZOKAnSBj YXNlcywgd2UgY2FuIG9wZXJhdGUgd2l0aCBhIHNpbmdsZSBzbGFzaC4NCg0KQ2hlZXJzLA0KQWRy aWFuDQoNCkZyb206IEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9lbGph QGJvZ3VzLmNvbT4+DQpTZW50OiAyNyBGZWJydWFyeSAyMDE5IDA2OjMxDQpUbzogQWRyaWFuIEZh cnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+DQpD YzogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50K2lldGZAd2F0 c2VuLm5ldD4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBhcnR3b3JrIGZvbGRpbmc6IGR1YWwgc3VwcG9ydCBtb2Rlcz8NCg0K DQoNCk9uIEZlYiAyNiwgMjAxOSwgYXQgMTQ6MjYsIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRk b2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+PiB3cm90ZToNCg0KSGV5Lg0KDQpJ 4oCZdmUgYmVlbiBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uIHdpdGggS2VudCBvZmYtbGluZSwgYnV0 IHRob3VnaHQgaXQgc2hvdWxkIGNvbWUgdG8gdGhlIGxpc3QuDQoNCkkgZG9u4oCZdCB0aGluayBp dCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIHR3byBhcHByb2FjaGVzLiBXaGlsZSBpdCB3b3VsZCBi ZSByZWxhdGl2ZWx5IGVhc3kgdG8gY29kZSBmb3IgYm90aCBhcHByb2FjaGVzLCBpdCBzZWVtcyB0 byBhZGQgYSBkZWdyZWUgb2YgY29uZnVzaW9uIGlmIGJvdGggaGF2ZSB0byBiZSBoYW5kbGVkIGJ5 IHRoZSBzYW1lIGNvZGUgKGNvbnNpZGVyIGRlY2lkaW5nIHdoZXRoZXIgbGVhZGluZyBzcGFjZSBj aGFyYWN0ZXJzIGFyZSB0byBiZSByZXRhaW5lZCBvciBub3QsIHNvbWV0aGluZyB0aGF0IGNhbiBv bmx5IGJlIGRlY2lkZWQgd2hlbiB0aGUgZmlyc3Qgbm9uLXNwYWNlIGNoYXJhY3RlciBpcyBmb3Vu ZCksIG9yIGJ5IGhhdmluZyBkaWZmZXJlbnQgY29kZSBmb3IgdGhlIHR3byBkaWZmZXJlbnQgY2Fz ZXMuDQoNCkl0IGRvZXNu4oCZdCBzZWVtIHRvIG1lIHRoYXQgYm90aCBjYXNlcyBhcmUgbmVlZGVk LiBXZSBjYW4gcGljayBvbmUgb3IgdGhlIG90aGVyLg0KDQpBIHNpbmdsZSBzbGFzaCBoYXMgYmVl biB1c2VkIHRvIHdyYXAgbG9uZyBsaW5lcyBpbiBlZGl0b3JzIGFuZCBzaGVsbHMgZm9yIGRlY2Fk ZXMgYXQgdGhpcyBwb2ludC4NCg0KYW5kIHllYWggd2hhdGV2ZXIgaXQgaXMgb25lIG1ldGhvZCBz ZWVtcyBiZXR0ZXIgdGhhbiB0d28uDQoNCg0KQW5kICppZiogd2Ugd2FudCB0byBhbGxvdyBtYW51 YWwgZm9sZGluZyBzbyB0aGF0IGluZGVudHMgY2FuIGJlIG1hZGUgdG8gbWFrZSB0aGUgZG9jdW1l bnQgbW9yZSBodW1hbi1yZWFkYWJsZSB0aGVuIHdlIGhhdmUgdG8gdXNlIGEgbGVhZGluZyDigJhc 4oCZIG9uIGNvbnRpbnVhdGlvbiBsaW5lcyB0byBzaG93IHdoaWNoIHNwYWNlcyBzaG91bGQgYmUg c3RyaXBwZWQgYW5kIHdoaWNoIHJldGFpbmVkLg0KDQpDaGVlcnMsDQpBZHJpYW4NCg0KRnJvbTog bmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmc+PiBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NClNlbnQ6IDI1IEZlYnJ1YXJ5IDIwMTkg MjI6MjINClRvOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtuZXRtb2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0IG1vZGVzPw0KDQoNCkkg aGFkIGEgY2hhdCB3aXRoIHRoZSB0b29scyB0ZWFtIHJlY2VudGx5IGFuZCwgaW4gdGhlIGNvdXJz ZSBvZiB0aGluZ3MsIGl0IHdhcyBpbXBsaWVkDQp0aGF0IHRoZSBkb3VibGUgYmFja3NsYXNoIGFw cHJvYWNoIHdlIGhhdmUgbm93IHdhcyBib3RoIHN1cnByaXNpbmcgYW5kIG5vbi1pbnR1aXRpdmUu DQoNClRoaXMgZ290IG1lIHRoaW5raW5nIHRoYXQgd2UgbWF5IGhhdmUgdGhyb3duIHRoZSBwcm92 ZXJiaWFsIGJhYnkgb3V0IHdpdGggdGhlIGJhdGh3YXRlci4NClRoYXQgaXMsIGN1cnJlbnRseSB3 ZSBoYXZlIGEgaGVhZGVyIHRoYXQgcmVhZHM6DQoNCg0KICBOT1RFOiAnXFwnIGxpbmUgd3JhcHBp bmcgcGVyIEJDUCBYWCAoUkZDIFhYWFgpDQoNClNvIHdoeSBub3QgKmFsc28qIHN1cHBvcnQgYSBo ZWFkZXIgdGhhdCByZWFkcyAobm90ZSB0aGUgc2luZ2Ugc2xhc2gpOg0KDQoNCiAgTk9URTogJ1wn IGxpbmUgd3JhcHBpbmcgcGVyIEJDUCBYWCAoUkZDIFhYWFgpDQoNCldoZXJlYnkgdGhpcyBzZWNv bmQgZm9ybSBvbmx5IHN1cHBvcnRzIHRoZSBmb2xkZWQgbGluZSBjb250aW51aW5nIG9uIGNvbHVt biAxIChubyBpbmRlbnRzKS4NCg0KVGhvdWdodHM/DQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9k IG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= --_000_3af58c925ad74fbfaaea299877bf992dXCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJp Zjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SGkgQWRyaWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBtb3N0bHkg YWdyZWUgd2l0aCB5b3VyIGxhc3Qgc2VudGVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5JIHRoaW5rIHRoYXQgaWYgeW91IGFsd2F5cyBwcmVzZXJ2ZSB3aGl0ZXNwYWNlIHRo ZW4gYSBzaW5nbGUgc2xhc2ggaXMgZmluZS4mbmJzcDsgSS5lLiB0aGUgc2luZ2xlIHNsYXNoIGp1 c3QgYnJlYWtzIHRoZSBsaW5lLCBhbmQgSSB0aGluayB0aGF0IHRoaXMgbWF0Y2hlcyBob3cgZWRp dG9ycywgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLA0KIGV0YyBub3JtYWxseSBiZWhhdmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaGF0IEnigJltIG5vdCBrZWVuIG9uIGlzIHVz aW5nIGEgc2luZ2xlIHNsYXNoLCBhbmQgdGhlbiBhdXRvbWF0aWNhbGx5IHN0cmlwcGluZyBsZWFk aW5nIHdoaXRlc3BhY2Ugb24gdGhlIGxpbmUgZm9sbG93aW5nIGEgc2xhc2guPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JZiB3ZSB3YW50IHRvIGhhdmUgY29udHJvbCBvZiBsYXlv dXQgYW5kIGJlIGFibGUgdG8gc3RyaXAgZXh0cmEgd2hpdGVzcGFjZSB0aGVuIG15IGFyZ3VtZW50 IGlzIHRoYXQgaXQgaXMgYmV0dGVyIHRvIGJlIGV4cGxpY2l0LCBhbmQgdXNpbmcgdHdvIHNsYXNo ZXMgaXMgb25lIHdheSBvZiBhY2hpZXZpbmcgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldG1v ZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFk cmlhbiBGYXJyZWw8YnI+DQo8Yj5TZW50OjwvYj4gMjcgRmVicnVhcnkgMjAxOSAwOTo0MTxicj4N CjxiPlRvOjwvYj4gJ0pvZWwgSmFlZ2dsaScgJmx0O2pvZWxqYUBib2d1cy5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRt b2RdIGFydHdvcmsgZm9sZGluZzogZHVhbCBzdXBwb3J0IG1vZGVzPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Q29tcGxldGUgYWdyZWVtZW50LCBKb2VsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaGF0IGZvbGxvd3MgbWF5 IGxvb2sgYmV0dGVyIGluIHByb3BvcnRpb25hbCBmb250cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2l0aCBhIHNpbmdsZSBzbGFz aCB3ZSBjYW4gd3JhcCBhcyBmb2xsb3dzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjEyMzQ1NjcmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgOTAxMjM0NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Hb2VzIHRv4oCmPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjEyMzQ1NjcmbmJz cDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkwMTIzNDU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+4oCmYW5kIHVud3Jh cHBpbmcgaXMgZWFzeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SG93ZXZlciwgaWYgSSB3YW50IHRvIG1hbnVhbGx5IHdyYXAgdGhl IGxpbmUgd2l0aCBpbmRlbnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgcXVpY2sgYnJvd24gZm94IGp1bXBzIG92ZXIg dGhlIGxhenkgZG9nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPi4uZ29pbmcgdG/igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHF1aWNrIGJyb3duIGZveFw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igKZJ IGFtIGdvaW5nIHRvIHVuZm9sZCBhc+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgcXVpY2sgYnJvd24gZm94Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29u dmVyc2VseSwgaWYgSSByZXNvbHZlIHRoaXMgc2Vjb25kIGNhc2UgYnkgc3RyaXBwaW5nIGxlYWRp bmcgc3BhY2VzIEkgZ2V04oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBxdWljayBicm93biBmb3hqdW1wcyBvdmVyIHRoZSBs YXp5IGRvZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5TbyBJIGhhdmUgdG8gZm9sZCBhc+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgcXVpY2sgYnJvd24gZm94 IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5CdXQgdGhpcyBjYXVzZXMgdGhlIGZpcnN0IGNhc2UgdG8gdW5mb2xkIGFzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjEyMzQ1Njcm bmJzcDsmbmJzcDsmbmJzcDsgOTAxMjM0NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igKZpLmUuLCB3aXRoIG1pc3Npbmcgc3BhY2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UaGlzIGlzIHdoYXQgY2F1c2VkIHRoZSB1c2Ugb2YgdGhlIHNlY29uZCBzbGFzaCBzb+KA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4xMjM0NTY3Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlwmbmJzcDsmbmJzcDsmbmJzcDsgOTAxMjM0 NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj7igKZhbmTigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+VGhlIHF1aWNrIGJyb3duIGZveFw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBcIGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28sIG15IHBvaW50IGlzLCBp ZiBhbmQgb25seSBpZiB3ZSBkbyBub3QgY2FyZSBhYm91dCB0aGVzZSDigJxzcGFjZXMgb24gdGhl IGZvbGTigJ0gY2FzZXMsIHdlIGNhbiBvcGVyYXRlIHdpdGggYSBzaW5nbGUgc2xhc2guPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkFkcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBKb2VsIEphZWdnbGkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86am9lbGphQGJv Z3VzLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPmpvZWxqYUBib2d1cy5jb208L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjcgRmVicnVhcnkgMjAx OSAwNjozMTxicj4NCjxiPlRvOjwvYj4gQWRyaWFuIEZhcnJlbCAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj48c3BhbiBsYW5nPSJFTi1VUyI+YWRyaWFuQG9s ZGRvZy5jby51azwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQo8Yj5DYzo8 L2I+IEtlbnQgV2F0c2VuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmtlbnQmIzQzO2lldGZA d2F0c2VuLm5ldCI+PHNwYW4gbGFuZz0iRU4tVVMiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Om5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPm5ldG1vZEBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1v ZF0gYXJ0d29yayBmb2xkaW5nOiBkdWFsIHN1cHBvcnQgbW9kZXM/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPG86 cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGZWIgMjYsIDIwMTksIGF0IDE0OjI2LCBBZHJpYW4gRmFy cmVsICZsdDs8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRv Zy5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+SGV5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5J4oCZdmUgYmVlbiBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uIHdpdGggS2VudCBvZmYt bGluZSwgYnV0IHRob3VnaHQgaXQgc2hvdWxkIGNvbWUgdG8gdGhlIGxpc3QuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgZG9u4oCZdCB0aGluayBp dCBpcyBhIGdvb2QgaWRlYSB0byBoYXZlIHR3byBhcHByb2FjaGVzLiBXaGlsZSBpdCB3b3VsZCBi ZSByZWxhdGl2ZWx5IGVhc3kgdG8gY29kZSBmb3IgYm90aCBhcHByb2FjaGVzLCBpdCBzZWVtcyB0 byBhZGQgYSBkZWdyZWUgb2YgY29uZnVzaW9uIGlmIGJvdGggaGF2ZSB0byBiZSBoYW5kbGVkIGJ5 IHRoZSBzYW1lIGNvZGUgKGNvbnNpZGVyDQogZGVjaWRpbmcgd2hldGhlciBsZWFkaW5nIHNwYWNl IGNoYXJhY3RlcnMgYXJlIHRvIGJlIHJldGFpbmVkIG9yIG5vdCwgc29tZXRoaW5nIHRoYXQgY2Fu IG9ubHkgYmUgZGVjaWRlZCB3aGVuIHRoZSBmaXJzdCBub24tc3BhY2UgY2hhcmFjdGVyIGlzIGZv dW5kKSwgb3IgYnkgaGF2aW5nIGRpZmZlcmVudCBjb2RlIGZvciB0aGUgdHdvIGRpZmZlcmVudCBj YXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ SXQgZG9lc27igJl0IHNlZW0gdG8gbWUgdGhhdCBib3RoIGNhc2VzIGFyZSBuZWVkZWQuIFdlIGNh biBwaWNrIG9uZSBvciB0aGUgb3RoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QSBzaW5nbGUgc2xhc2gg aGFzIGJlZW4gdXNlZCB0byB3cmFwIGxvbmcgbGluZXMgaW4gZWRpdG9ycyBhbmQgc2hlbGxzIGZv ciBkZWNhZGVzIGF0IHRoaXMgcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPmFuZCB5ZWFoIHdoYXRldmVyIGl0IGlzIG9uZSBtZXRob2Qgc2Vl bXMgYmV0dGVyIHRoYW4gdHdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFuZCAqPGI+aWY8L2I+ KiB3ZSB3YW50IHRvIGFsbG93IG1hbnVhbCBmb2xkaW5nIHNvIHRoYXQgaW5kZW50cyBjYW4gYmUg bWFkZSB0byBtYWtlIHRoZSBkb2N1bWVudCBtb3JlIGh1bWFuLXJlYWRhYmxlIHRoZW4gd2UgaGF2 ZSB0byB1c2UgYSBsZWFkaW5nIOKAmFzigJkgb24gY29udGludWF0aW9uIGxpbmVzIHRvIHNob3cg d2hpY2ggc3BhY2VzIHNob3VsZCBiZSBzdHJpcHBlZA0KIGFuZCB3aGljaCByZXRhaW5lZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWRyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj5uZXRtb2QgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5uZXRtb2QtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPktlbnQgV2F0c2VuPGJy Pg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjI1IEZlYnJ1YXJ5IDIwMTkgMjI6MjI8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWls dG86bmV0bW9kQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+bmV0bW9kQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltuZXRtb2RdIGFydHdvcmsg Zm9sZGluZzogZHVhbCBzdXBwb3J0IG1vZGVzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgaGFkIGEgY2hhdCB3aXRo IHRoZSB0b29scyB0ZWFtIHJlY2VudGx5IGFuZCwgaW4gdGhlIGNvdXJzZSBvZiB0aGluZ3MsIGl0 IHdhcyBpbXBsaWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50aGF0IHRo ZSBkb3VibGUgYmFja3NsYXNoIGFwcHJvYWNoIHdlIGhhdmUgbm93IHdhcyBib3RoIHN1cnByaXNp bmcgYW5kIG5vbi1pbnR1aXRpdmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoaXMg Z290IG1lIHRoaW5raW5nIHRoYXQgd2UgbWF5IGhhdmUgdGhyb3duIHRoZSBwcm92ZXJiaWFsIGJh Ynkgb3V0IHdpdGggdGhlIGJhdGh3YXRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPlRoYXQgaXMsIGN1cnJlbnRseSB3ZSBoYXZlIGEgaGVhZGVyIHRoYXQgcmVhZHM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2Jy ZWFrLWJlZm9yZTogcGFnZSI+Jm5ic3A7IE5PVEU6ICdcXCcgbGluZSB3cmFwcGluZyBwZXIgQkNQ IFhYIChSRkMgWFhYWCk8bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U28gd2h5IG5vdCAqYWxzbyogc3VwcG9y dCBhIGhlYWRlciB0aGF0IHJlYWRzIChub3RlIHRoZSBzaW5nZSBzbGFzaCk6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JyZWFrLWJlZm9y ZTogcGFnZSI+Jm5ic3A7IE5PVEU6ICdcJyBsaW5lIHdyYXBwaW5nIHBlciBCQ1AgWFggKFJGQyBY WFhYKTxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XaGVyZWJ5IHRoaXMgc2Vjb25kIGZvcm0gb25seSBzdXBw b3J0cyB0aGUgZm9sZGVkIGxpbmUgY29udGludWluZyBvbiBjb2x1bW4gMSAobm8gaW5kZW50cyku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRob3VnaHRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5LZW50IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4N Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3af58c925ad74fbfaaea299877bf992dXCHRCD007ciscocom_-- From nobody Wed Feb 27 02:20: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 4C5DB130E27 for ; Wed, 27 Feb 2019 02:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_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=bReSlpi4; dkim=pass (1024-bit key) header.d=ericsson.com header.b=JgVabc3k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8KmZEn8ulyQ for ; Wed, 27 Feb 2019 02:20:06 -0800 (PST) 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 096B61295EC for ; Wed, 27 Feb 2019 02:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551262804; x=1553854804; 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=4n6GaHY71dM7oEnuDv6nJEoUTnLZWhUl0dvZcF3cwgA=; b=bReSlpi4lLE+X4hZFOvauoFjI1abg54j7SAOeQp0HqvwKh/3kj+wC6/KNIzduxqv k2qoob2wP1u9VlxFxWU10Fo/2DDv2eU6nsn1VDyVKURH44CzeAVdasXIo2+zpmyP QITqfkO6UZva1UM/J7CzwJT6IEN+rv1UjVD6iZ0x37Q=; X-AuditID: c1b4fb2d-2198b9e00000062f-43-5c766454ab13 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 18.34.01583.454667C5; Wed, 27 Feb 2019 11:20:04 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) 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; Wed, 27 Feb 2019 11:19:57 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) 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; Wed, 27 Feb 2019 11:19:57 +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=4n6GaHY71dM7oEnuDv6nJEoUTnLZWhUl0dvZcF3cwgA=; b=JgVabc3kxjbraMby1lac0958Xizui5HTk+LjNcDsQWbmKA3PmpKwC7O5HmJha39FoyDwxTr+JPQGIWDaAjpgLDn8l7aKdpeMEkEPIjaoAmjRWPi+KrPLyGQNGC+YeT4yRN/ceki9BWk1ql8ne36Horc2lPFauVq/kRC46wn2WQw= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB5492.eurprd07.prod.outlook.com (20.178.21.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.12; Wed, 27 Feb 2019 10:19:56 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd%2]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 10:19:56 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: Obsolete feature - what does it mean? Thread-Index: AQHUzoX8sLOrgwMKb0+lEXSgf1InRQ== Date: Wed, 27 Feb 2019 10:19:55 +0000 Message-ID: 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.1 x-clientproxiedby: HE1PR0701CA0080.eurprd07.prod.outlook.com (2603:10a6:3:64::24) To AM0PR07MB3841.eurprd07.prod.outlook.com (2603:10a6:208:45::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: ac9e0068-8465-4e8f-6441-08d69c9d1e9c 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:AM0PR07MB5492; x-ms-traffictypediagnostic: AM0PR07MB5492: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA3TUI1NDkyOzIzOkhpbytSRFZVL0g5ajdLOTdQQTBVN2lDQWUr?= =?utf-8?B?NUZrMkZrMmlFbXhxajdrVXQranMreDhpaUxReFp0bjB3cWZtRlo4anphL0xh?= =?utf-8?B?bEJsOEwvNVk3K29vSUZ1azloaHpBN2J5VVRKTGxlSW9vSncyRC9rNjMzS0pI?= =?utf-8?B?SUNzTk56d09ZWnpBZzFCYkF5Q0VlQzBXeVpha0laVTk2VkU0czgxS2R6VjR1?= =?utf-8?B?WjNFUEVZTnM2YWp1Q3FLb3lVdU9oaTlrd010cGdSdWFVL3FPV3pYTHdQRFlp?= =?utf-8?B?R1FGSVNZd2xaSEdFdVZuL09ocjcyL0NyNFE5MTE4ZDYyVnFWd09CMnlVMkJI?= =?utf-8?B?M29NVEIxNC9BZUxyY3dUS1FuenVYc1JYRW9GSjNvc1c1ckJGVjN5VUQvSHhC?= =?utf-8?B?VGlBdld3UWJUNkM5azNpRGhtK0xyTVhOaDZTRWd6bkFaYW9LMHBadXhHUUZn?= =?utf-8?B?WFZWWDdSRFdlUHJXeG9LdWN2MGl6cUJQUWl3L2Z6SUw1OVBUL002djZIWDRr?= =?utf-8?B?ZWZnbnh1TXVvNklTbjU1YU9haEFaZU80UFUvYW9uNTRmT2ZqVE54cDJ2K0FR?= =?utf-8?B?L3FBMDhld24zYTNZRGdSRXFWd3VvRFFuRDZuaWJXazVsNW92YVlHaW1nUW9S?= =?utf-8?B?czlUdlA5dlV6L2FEYWdXZWVjdTFZTEgvWjV1eUVFNC85Q2RLdjFRWGJ3bWFt?= =?utf-8?B?ME5EVEEvczlYNml4K1dleEVlR0RLMzVZWGFiY1dTdGRxdG1BeTIrYjNpTWpj?= =?utf-8?B?ZmQxdkovTXJNOStQVUlnYlFVTzE0cW9abWxHV0F4MnBaZjI1elJ5U0I0Z09N?= =?utf-8?B?NTd6TC9tbyttVkdEZ28yazBjV1dJTVdVY0U2TkRpekpLenYraDN2TUpCVTJh?= =?utf-8?B?QzNUT1MzZVo1Smp4bmFXQ2kvVXozKzZHWTVEa1FYU09jUU96VnhCWlRuaWFE?= =?utf-8?B?Mlcvb20zeDFkc2xXSzRjajNibzhiZTZZaGdVVzAzeUMxZWE4dGc2Q2Q2ck1H?= =?utf-8?B?VFYzV0N0Q081bUNpbENLSEk4SkpFWUpkejg4c09wWURIYkg2UENjRGpjT1l1?= =?utf-8?B?SnJ1STErQUxFZVZKOEQ3cUFEYk9aTkxjODBXcExmd1JHbVNTWElObEVlUHlY?= =?utf-8?B?ZDZXQWYyTEtuUnVveTJ5MVovR1Rzbk9QZ1BiM3Q2SVplTDdSVS9POHE4NUlj?= =?utf-8?B?ejNEaE1XZkJoQlVpTCs1SzJTU0RpamFmYkZOV1FuYkRQUDlNK3d3S0Z5aE8z?= =?utf-8?B?NkZxUFNkK0ZiYTJFU296MW1xOEQ2aGtxUG9NNmMwQmpaK05DWm9ORnRpc3NW?= =?utf-8?B?bTZWY1BLNFBZbzh4Qnowb2cyOUhCS2Noc0VWcDhENmFiQ0VZaElCZ240dGhW?= =?utf-8?B?cE9xdkxSa1owUzQyRk9mempGWXlwK0szSVp2TUVPNUNIeWdqbytzNkZrMCtw?= =?utf-8?B?YjhseFZrdUMxdzN4Rk45a2lrNzcwUzk0KzlSM2wzVlRYYlgzanZxZTVMeWpD?= =?utf-8?B?Y0hlMlRVUFZ2R1RWTHRxaVgrY2toTElNM3BaTGpoZXJRNFBBWDREQkRmU3F6?= =?utf-8?B?ci9MRUpIRlF0VEJZY1VsQmlEaE9KWmQ3NlJtSFI2NEVQblRxOXg3V3IzVUtp?= =?utf-8?B?dit5RWQzaW1ZVi8reFBnZkNETWdUVEJBa0c4N2M4K2Z0RDJWZ0JGNHg4dTVF?= =?utf-8?B?UVIxcVQyT0x4U05mNEJ5eFRLb2pKVGk2OWlQdStrVjRtVkV4RnBMUmZDcU92?= =?utf-8?B?elhPZWhSdm9ZckFYaTVPSjBDWDNQbVArektpL2tWeVRtdlhoei9vU2F0SzZo?= =?utf-8?B?cHorK2ttNGNoRW9BUGswSXFFWlNFMnRHeGptMGVITHBPUStiaE1jdjFDMEZw?= =?utf-8?Q?25xiDF5jQyiM1IzJsyXxqALykRJHz9oB?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(366004)(396003)(376002)(199004)(189003)(97736004)(65826007)(53936002)(6916009)(31696002)(52116002)(71190400001)(71200400001)(186003)(2351001)(105586002)(85202003)(106356001)(5660300002)(26005)(99286004)(54896002)(6512007)(86362001)(6436002)(5640700003)(386003)(6486002)(6506007)(102836004)(36756003)(478600001)(476003)(14454004)(8936002)(7736002)(31686004)(486006)(8676002)(65806001)(66066001)(236005)(6116002)(81166006)(25786009)(3846002)(2616005)(256004)(64126003)(2906002)(4744005)(316002)(2501003)(85182001)(58126008)(68736007)(65956001)(99936001)(81156014)(1730700003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5492; 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) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2agdkBe4joFRr42XMNC514ajlKdPRn9GIwO6bvS8AD4vSOqWoNBUl0ZAm0JUbcRITQRcV8sGMKqRuV2AzOWaypPBp/3W6a8RvtvKfvGBa/JAvJXBsbHCLl6+2Z26MkF1TBpmE0IqzcMacy+JrjF5vO8R8t/7ZpQsqFOX3P8IPFpM8IjpZAqPhPRUD8VmeO9UI8VcPURM1U2v40T8ZNW/DLCet9cZYisF+ojVAUnPsZCx574x0LZ+10vZcccxgGGVInzYg4tXoxPzLUc7T/JRibr44IRvTTe2JLuJ5DbFU1DLT4JWTkDzbgsSnlXvwSBXLfGq8ujibNdr9nQ245UBtlzZMo6RbkZHRfaadKTGMcK2V7AyQyNjIWcGbRoEQSE35qyGKrwP81QjiLMJP4I1q6gd9jalAsi3t5wHyj9KZ+Y= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060104010803040803010902" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac9e0068-8465-4e8f-6441-08d69c9d1e9c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 10:19:55.9469 (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: AM0PR07MB5492 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0iTURjGOfu2b5/DwXFpvmhRfqSBeddEMrpQoARiVJjFTFd+qOim7bOR gaCmrNTIzOso7DKtnJao4QXL3OxiImokpX+YtzI1vFQmplbbjkH993vP+7zPe57DYShZn8iJ SVClcmqVIomlJcLyyCbe81isRu4z0yMJqujPFO1DoXr9suAwOinZHcslJWg4tfeeGEn8yCs9 ndIVdL5p4BqVgeYDcpENAzgAWvtMdC6SMDLciaBk8SUixQ8EH0aGxaTQC2DSpBNZCiEuoCA/ e05gmZfhQgH0ttsQ1RiCxQcvxJYGjQ+CdrbdKrLH26G85ZF5CcNswF4wuOREjv3hysUWRNgL SkzDtIWF2BWKDP1WGyneC9naZasG4Y2w9LrGaklhRxiaqBCQDPYw2t9NE3aAqfFfIsIslE0P WdkBR0FDUTFluSfgUgQ3tM9oYnoK2oYvrQ97QM+7CUR4M7ypyFvnMOjpXhST4XEExsGB9c3u 8FvfvO46LoOvUyQ94ES4/nlOaEkMeBPMX3UlmmIaFrTVYvJ0HNyrzUEFyEP3TyKdWUfhywi+ fHyLdNYnsIOu8gmhzuxFYTeoymH/11t4B1TdnqEIB0PZzw6asAsU5Y2KCe+EmecLiLA/VD1c o28hSTVy4DmeV8b5+Xtx6oQzPJ+s8lJxqfXI/Lc6Glc8m5FhZr8RYQaxttJRuUYuEyk0fJrS iLaZfcbqDH3ISahKVnGsvdQ7xtyWxirSLnDq5Gj1uSSONyJnRsg6SldldnIZjlOkcokcl8Kp /3YFjI1TBvLwGSvorI1qzTrSFagtyfz+ODA0vDTi9M3CkDBlW8QWZ1fn8dUTWe4tDer0zJSF 8JLeyq2V3WsH7qQP3L2vfFpfqfF2m7TdVT/dnaryy02pcfGNHvPM+lbf2GH6ZEB1QSi/0HS2 01l1PPwJFaIsMyzRhxJm37NNq25sbeTKUUMwK+TjFb7ulJpX/AGXIMQkYwMAAA== Archived-At: Subject: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 10:20:08 -0000 --------------ms060104010803040803010902 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

The feature statement may have a status substatement. But what does it mean if a feature is deprecated or obsolete? Some ideas:

  • All if-feature statements using it should be removed. But what to do with "if-feature oldFeature AND otherFeature" ;
  • The feature is always considered true/false
  • this is a bug in rfc7950, there should not be such a substatement
  • something else

regards Balazs

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms060104010803040803010902 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIyNzEwMTk1M1ow LwYJKoZIhvcNAQkEMSIEIEEoMSkxrvCtptCAI1sN1a9k2JFmGoYzlng7FjgfatSIMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAM5KYvozm2uw/X+nCKLSBvPOHP/bjBoA7gmlKJ4T+Wlb4mnV 4KdcutHohHALgJy9ZVXZJc+Zgr1uQ4zRQoNNRZgDaDmOpFZMsCsavKHaE9BNoN79/PLFNraz hmkI0Kdv6LXXP6f4BweMTryn6a8a74nTMP1jwZA58xbaZD58ihN354OzrkHSbJSJjfZotfka uVNDRl5AmZ5vFSI/5Ovh1zHe2hCcZZQOj3If6+lNW9mArAeVJW8TG/+t2dYP/2/pyvbT12nK xl+exxTomNQEA7qhPhTBO5ahvLf7G5xysrle3WYIs3fMn4hB31o92KIT9EV0ViwAWDlh9GjV LIWBRO0AAAAAAAA= --------------ms060104010803040803010902-- From nobody Wed Feb 27 02:24: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 A16B7130EA5 for ; Wed, 27 Feb 2019 02:24:35 -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 wFV1j2ZAxnnF for ; Wed, 27 Feb 2019 02:24:33 -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 D12BD130E27 for ; Wed, 27 Feb 2019 02:24:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6AD953D for ; Wed, 27 Feb 2019 11:24: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 oi3BCbhhNmZm for ; Wed, 27 Feb 2019 11:24: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 ; Wed, 27 Feb 2019 11:24: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 554A120067 for ; Wed, 27 Feb 2019 11:24: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 jzBdfAqPaehi for ; Wed, 27 Feb 2019 11:24:31 +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 1D2ED20064 for ; Wed, 27 Feb 2019 11:24: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; Wed, 27 Feb 2019 11:24:30 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 4BD5C3006D3148; Wed, 27 Feb 2019 11:24:29 +0100 (CET) Date: Wed, 27 Feb 2019 11:24:29 +0100 From: Juergen Schoenwaelder To: Message-ID: <20190227102429.g3dimdyymcr4uldf@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: netmod@ietf.org References: <155126262868.14077.10267839696551631282@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <155126262868.14077.10267839696551631282@ietfa.amsl.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] I-D Action: draft-schoenw-netmod-rfc6991-bis-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, 27 Feb 2019 10:24:35 -0000 Hi, I have posted a baseline I-D for an update of the common YANG datatypes (RFC 6991). There are no content changes yet, this version reflects the content of RFC 6991. The idea is that this -00 version serves as a convenient baseline for the diff tools we have. /js On Wed, Feb 27, 2019 at 02:17:08AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Common YANG Data Types > Author : Juergen Schoenwaelder > Filename : draft-schoenw-netmod-rfc6991-bis-00.txt > Pages : 38 > Date : 2019-02-27 > > Abstract: > This document introduces a collection of common data types to be used > with the YANG data modeling language. This document obsoletes RFC > 6991. > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 27 02:33: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 4B11B130EA9 for ; Wed, 27 Feb 2019 02:33:08 -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 Cqjs4YVJwUJN for ; Wed, 27 Feb 2019 02:33:07 -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 8FDC1128CF3 for ; Wed, 27 Feb 2019 02:33:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1EE9327; Wed, 27 Feb 2019 11:33: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 bs4PiZkrbpLF; Wed, 27 Feb 2019 11:33: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; Wed, 27 Feb 2019 11:33: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 0974F20064; Wed, 27 Feb 2019 11:33: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 kaitCnfbjm0n; Wed, 27 Feb 2019 11:33: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 A9EEC20067; Wed, 27 Feb 2019 11:33:04 +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; Wed, 27 Feb 2019 11:33:04 +0100 Received: by anna.localdomain (Postfix, from userid 501) id CD2413006D3217; Wed, 27 Feb 2019 11:33:03 +0100 (CET) Date: Wed, 27 Feb 2019 11:33:03 +0100 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel CC: "netmod@ietf.org" Message-ID: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 10:33:08 -0000 On Wed, Feb 27, 2019 at 10:19:55AM +0000, Bal=E1zs Lengyel wrote: > Hello, >=20 > The feature statement may have a status substatement. But what does = it > mean if a feature is deprecated or obsolete? Some ideas: >=20 > * All if-feature statements using it should be removed. But what t= o do > with "if-feature oldFeature AND otherFeature" ; > * The feature is always considered true/false > * this is a bug in rfc7950, there should not be such a substatemen= t > * something else > Deprecated means the feature is deprecated, you should not use it in new definitions. A feature is not "true or false", a feature can be implemented or not. A current definition being conditional on a deprecated feature may be something tools should warn about. Obsolete means the feature is obsolete, it likely should only be used in obsolete definitions. A current definition likely should not depend on an obsolete feature and if that happens, then likely brainware needs to look at the situation and resolve it. /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 Wed Feb 27 03:17: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 C8C74128CF3 for ; Wed, 27 Feb 2019 03:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_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=BkbluGrW; dkim=pass (1024-bit key) header.d=ericsson.com header.b=SjWH/XdS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RX13rq8H4Gr for ; Wed, 27 Feb 2019 03:17:09 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 57AF4129741 for ; Wed, 27 Feb 2019 03:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551266227; x=1553858227; 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=rmCGU70m5w6oSD6J4EGg1nVF9EwzTpgf3PK2o8z33jU=; b=BkbluGrWEKDYdUaZZQ2SFhS81Vs7LzCjBIAIlgNDP1SdTwoxKRB/YEK0/H5ZaK9U JeZiSJTqdOeDjuy1Q46DHWTOtlowMFKgxEvzlvX41mvjC0RuPpyECEdCQAY+1F8s 50onLGyVHxOunXmMHZmd7+0lFqMMMT9IdvcT0AIvp/w=; X-AuditID: c1b4fb25-209009e000005ff7-a6-5c7671b38c94 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8F.94.24567.3B1767C5; Wed, 27 Feb 2019 12:17:07 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESBMB502.ericsson.se (153.88.183.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Feb 2019 12:16:56 +0100 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Feb 2019 12:16:56 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Wed, 27 Feb 2019 12:16:56 +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=rmCGU70m5w6oSD6J4EGg1nVF9EwzTpgf3PK2o8z33jU=; b=SjWH/XdShkFlesaU+mbaLKx39BJ3YpAquwGu0PhDDNGTjvekG6qbJgr4grUzOy3tbxSe1C8BuO3tAxZ7qF4okYjLQZrC1uL0ZHvg2gE8ogV62YEB8p65XDKsEXoRCPLgXmknhNENaxgNeTgEa0SaRELJEjf4WT+T2VhGPmcm8C8= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB4625.eurprd07.prod.outlook.com (52.135.151.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.13; Wed, 27 Feb 2019 11:16:55 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd%2]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 11:16:55 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: [netmod] Obsolete feature - what does it mean? Thread-Index: AQHUzoX8sLOrgwMKb0+lEXSgf1InRaXzcpaAgAAMPgA= Date: Wed, 27 Feb 2019 11:16:55 +0000 Message-ID: <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> In-Reply-To: <20190227103303.emm3xj372rb7fx7t@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: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 x-clientproxiedby: HE1PR07CA0045.eurprd07.prod.outlook.com (2603:10a6:7:66::31) To AM0PR07MB3841.eurprd07.prod.outlook.com (2603:10a6:208:45::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: 2da11eb0-dd2c-452f-ec32-08d69ca514f1 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:AM0PR07MB4625; x-ms-traffictypediagnostic: AM0PR07MB4625: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTBQUjA3TUI0NjI1OzIzOjlmRFZHUWltVHNxTzVXaFZOZ2ZoVmRSdE9I?= =?utf-8?B?SCtOSVR2TkFpRWtrcmNsei9uUDZTR0ZhOTBYdDB3TUp4S0x1bkJIL0dya0VR?= =?utf-8?B?ekN2Tm1aUkNuQzl2RnRvbDE1WDhWSEN5L3pKZjJ5ay9Ob3lrbHF2WDBTTWwz?= =?utf-8?B?eno0QVR6bW9FMnhOWHpMWklraFBjUTB6b0JTNStXQitOLzVVNHNodG5IUmlw?= =?utf-8?B?VGlpaitRd1EySldoa2RpdXhleDNvOUp6bnhiRjAyUXdjV0xhc1loay9QVlBy?= =?utf-8?B?VFhZUGFVV1lCNHBseVA4dC95c2hUZ3dKeXF0ZHpjZFJ6bVowWXJEQkZDZC9L?= =?utf-8?B?enhqZytQcnRxN01ZY2tKK29XZEQvaDhZWWNPRTdvQ1FjbkV2K2hQSzhnczZN?= =?utf-8?B?QVd3elkzVHNqTHkxZUI0Z0FRVHFpOWU0QXBaVE5KbzlyRzdJMkZEc3RmRjkw?= =?utf-8?B?dEUxZCswSnA4Z01CMG9pc3hudmNiRzZQeDF0VzFwZWVVL21McW92QkJrbWxU?= =?utf-8?B?QUdTUGlZRWs0dDJ6TDBoTXVZL3hlZ3RKRVd5YmxaVm5EMVNZUUU0TFU1WUM0?= =?utf-8?B?K0o4dzJBNWNhTmFKbHlTcnFWc2srRjVENGFMTUV2NFlsbXAvMGVjbGVjNGtS?= =?utf-8?B?WUthalg4blZOa09VN2dQNHRJWG5nVndTZVVTV25jYXUwQmFvUmdmSS9ET0Nj?= =?utf-8?B?RnVKV1QvSjE1NmVBT3dqckw3MzRpSE5kWjJtNE9HTGsrUXlWUlpienNGcytD?= =?utf-8?B?ZUJEMHJhSlFqUGR2TXVzSXNsVU9TSURpckhaRkdzcEgxY3U2alBIQyt5M0lu?= =?utf-8?B?VGc4L2VQV2k1elFBSDliOVN5Qk10Z1pIME5YWXd5U2ZTYUtVeU45MzZrSEZl?= =?utf-8?B?S0QxTVQxLzMzTmhNRVpqVkUzVXhVMWlXYXVYQ1NBaVAvWW04amZFMzRqU1NQ?= =?utf-8?B?NENVYmNnTTNzekNGaHJydGxYUU5xWUU4Tmp2ZVcxRHpwTUZKQUZRTGJ3RVRY?= =?utf-8?B?ckpYTkN4TmhqaDhSb0ZGYUxLdHhWM3VzYzI0TjltekVXbWUyVHZsTmZEUHN3?= =?utf-8?B?TzRodFFNV0VZUnprcTZUeXZVUXlDbThQekFlSUZUWVpmTmNxU3R4M2lvd0hY?= =?utf-8?B?WmZPb0lkeXpHVlJNcWMrK1RTazk3SVhrc2k0UnlyQVoxTG9EWDNwTmhlbTV0?= =?utf-8?B?WXpKUmNpVVdQZDNrVXdxWEdpU3M4UTVRUVM5ZmRkNlpBRlAxUGI4Y3pEY0p2?= =?utf-8?B?bmpCa1NhenpGSVZTR1NEWVBteStqbVNYdEVFR1ZISVEzdUtaamphSEFVR0Ex?= =?utf-8?B?SkNySWtMbDdFdXBjMk1DdkV1dXM2V1M4SXBoRVYzUG9yTU9mTWYzbURPcWFk?= =?utf-8?B?Q3d6SSs2KzdYZEVuUnZKVDZmZEllZjB4dW9qVzhHTTBIZG9KZC8rR01xSUVO?= =?utf-8?B?VWhXdHZSa1FDOUdCMmJPdnkwNjUwUkIrMVo3VWRtTjhrc3pneXFVYy9PRGNS?= =?utf-8?B?OERtTDJFK05DYllqOUJ2R1QwVWFKd3BRdXVteXBpazI1LzNnbHY3YWoraWtS?= =?utf-8?B?aTZvWG9WMjRwSm16RmcwZHV5cWtHMlVCMDRoQjM5dTg4M05FWjRMYVZFeGI1?= =?utf-8?B?Q2U5Wlo4cFFPYjF5R2Q5d2k1QWw1QWM2WFMwRU5CSVhCUkFBV2tPSDErYitw?= =?utf-8?B?cnFodmVHUU1WQkpsV1YzcWh6K2VjeDlaSUZvRlh2d003d0w5REZycTcwTTRR?= =?utf-8?B?Qk1nZUFHNDE1N29uUnRFQm15WEZPWndmTkdkMkRwN2JvNGl0cGttUUxRaXVJ?= =?utf-8?B?ZXFKMjlkRzVxZEVBK1grOHA2aHN0WCtQK2xwOXNaL1ZoK01pNWh2RndPQzlM?= =?utf-8?B?Zkp6RERIaXZJQTREWU5LbG5xZmczd1l0dXgzbnZQWFBpbXFicHJxVjJBOWJF?= =?utf-8?B?OTdzdldzcllhSmRPMCtRZFFlOGlqcUhGM1k3a0JvRXlYbG5DMDZaU1VYOWxz?= =?utf-8?B?c25VSGlqbDcxb00rTnBsb0dnd0FUbEcvRTl0N2Z6T0VwOU8rV2Z2MWNBRENP?= =?utf-8?Q?g9zE=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(346002)(39860400002)(366004)(189003)(199004)(6246003)(2501003)(36756003)(25786009)(65826007)(54896002)(5640700003)(6916009)(236005)(229853002)(6436002)(6512007)(99936001)(6486002)(86362001)(31696002)(81166006)(64126003)(71190400001)(71200400001)(6116002)(3846002)(85182001)(7736002)(256004)(2906002)(85202003)(106356001)(68736007)(97736004)(105586002)(31686004)(476003)(316002)(386003)(58126008)(5660300002)(6506007)(11346002)(66066001)(26005)(65956001)(65806001)(102836004)(53936002)(478600001)(8676002)(8936002)(14454004)(486006)(1730700003)(76176011)(2351001)(52116002)(81156014)(66574012)(186003)(99286004)(446003)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4625; 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) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dWiIOT0BtQiLRch4Qg743oFcdHPsZOpvTJeNNYykGqJ0NzhE/uTVzEdECtnv3MQRO3KS/FxFneM/JjZnb+ZRhQ4W4U/fq3N6p5bhfWITaUK47cshU/O6wW0gIGTg63Kaja0/thRptijMFeCQKhvSHgyold0KreAPAf6OdFHGY9IMiwv2I7XzUmG5NqelWze28VFqRnc2X7hf7D9Ic+QsfX7m3QACUE7OyNzCaDZfe0+PcWdGJ3ML5VRjUqS8u7d7YsM7lLWAtdR6nIVo6zIDnkUfkPPJElo5MWGnTIhNaH1ytlyB1b7wmtM+STaTFQfWhoaY+xofTZ9WBu1wFrG0CKBi18/GyDJ4sJhkZadbOmm6IxvbdWINtRaS3CcE+D4KEhOiXp1+uiagAU/mDOcuvIZjvV0kee7h45Y8V4pWivU= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090101080900010805030604" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2da11eb0-dd2c-452f-ec32-08d69ca514f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 11:16:55.6801 (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: AM0PR07MB4625 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfSzUcRzH+97vdw9ubvt27vKhlXVLbQpdtJKLpD/8U1qsmqlc+Q3D0f10 i9aGoziUrWNY5SG7NgpDyVJ2wtKNPKwxesL1RzG0NuSx391Xrf57vT/vz8P3891HREkH+K6i OE0Ko9WoExQCMV16roX1bLqii9w3OSs8VD6QwT+KQqqrf/FOoQixKppJiNMxWu+AKHHsu7YR KvlJ8LWVp1NUOrIcMSAHEWBfyHrTSxmQWCTFnQg62nJoIuYRFOjbhX9FUU0dIqKaB/OvKu2C xoUUfLip33Duck7GRwEREwiq7tzm28YI8HG4NdPOs7EM74bS1nqBjZ2wP+Qb1xGJq2CmpIIm fBhejBiENqaxOxR3d1M2luBAGCns5JMBWQgGf7bZDQccCktjw/ZhCG+BhbeP7cMo7Ayj1nIe 2VUG4wMWAWE5fJtc4xNWQMn3UTvL8XloMhbZ/wNwEQKrPktIml6Atk85G8V7oXfYighvg8Hy PI5FHJ+AabOK1E4i6J2+T5G4B5iN0SS9VgbZn2nC8fBoYR0VIu+yf55axpVTOBdBRukcr8y+ 9GboKbXSZVwrCu8CU7bi/3wb7wFT5RRF2B9KlswCwjvAmDcuJHwAprp+IMI+YKpbFVQgcQ2S swx7KTFmv48Xo427zLJJGi8Nk9KIuOMyNy+7P0dD00EdCIuQwlGSyR2alK/WsamJHWgn12ei obYfudKaJA2jkEm8ozhbEq1OTWO0SRe1VxMYtgNtFdEKZ8mKdHOkFMeoU5h4hklmtH9cnsjB NR1FyLvu9fTTIfFjBr7vWoWl3GVT7I0W6+kCua9buD4wZ3usJSkosDEgN6LYOCd1OZnZGxD6 vsuS5rxaNfuwXmPktQfXH1OawlaEqsW+TKf88GezQ/oGx7MvVx3Tix74FUqUzYavNWF6neNr 0/W+8ByV55Rf1eKXVt8zdW5OyuWDCpqNVSs9KC2r/g151/kNZAMAAA== Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 11:17:12 -0000 --------------ms090101080900010805030604 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 
feature oldFeatur=
e {
=C2=A0 status obsolete;
}

leaf myTimer {
  if-feature oldFeature ;
  mandatory true;
  config true;
  status current;
  type string;
}

So should I configure myTimer or not? I assume yes, correct?

regards Balazs


On 2019. 02. 27. 11:33, Juergen Schoenwaelder wrote:
On Wed, Feb 27, 2019 at 10:1=
9:55AM +0000, Bal=C3=A1zs Lengyel wrote:

   Hello,

   The feature statement may have a status substatement. But what does it=

   mean if a feature is deprecated or obsolete? Some ideas:

     * All if-feature statements using it should be removed. But what to =
do
       with "if-feature oldFeature AND otherFeature" ;
     * The feature is always considered true/false
     * this is a bug in rfc7950, there should not be such a substatement
     * something else


Deprecated means the feature is deprecated, you should not use it in
new definitions. A feature is not "true or false", a feature can be
implemented or not. A current definition being conditional on a
deprecated feature may be something tools should warn about.

Obsolete means the feature is obsolete, it likely should only be used
in obsolete definitions. A current definition likely should not depend
on an obsolete feature and if that happens, then likely brainware
needs to look at the situation and resolve it.

/js


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms090101080900010805030604 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIyNzExMTY1Mlow LwYJKoZIhvcNAQkEMSIEIJ/uaRl7OvObAE4lJ+G49tmqri9RrFQwVvi76s56vsE4MGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAJOlAcWvRb6GbM8gR8JxhTP+0blP3OYxW+TbmjPjDgN7jTd/ yxgqHjE1C1/qa7OK/nJ0uV/wATEByeg7txUXCr/0+BY889mwTxIKdwAnFtNbeHGc0v8RuxWC VbhIE2Wd/6N11oDd5nPRTaSzka4Lg2BwgyoHM79vSXhIp0vtrAnfJiXDZxLKalP/4nFOCXeq HC9goQWI1Mgj1np8675k46vneXtrAKVQEzQ3vHiNvRvPDq87HsLI0a6R5LoUogqkRjwXTK39 6ypazNJRd4Xf8/EXysM3qTSzfTH0mqfH0lSMIP7EPM7P1pNs5TgTuuES1PwtUE86Xh5G4S7j YKnOhIcAAAAAAAA= --------------ms090101080900010805030604-- From nobody Wed Feb 27 04:34: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 CACE8130EB8 for ; Wed, 27 Feb 2019 04: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 pXFqS2n29qhx for ; Wed, 27 Feb 2019 04:34:28 -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 3B8D2130EC3 for ; Wed, 27 Feb 2019 04:34:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE5597B7; Wed, 27 Feb 2019 13:34: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 5-i67Z_EU5sA; Wed, 27 Feb 2019 13:34: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; Wed, 27 Feb 2019 13:34: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 B98A920067; Wed, 27 Feb 2019 13:34: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 2TMaKXuutcWa; Wed, 27 Feb 2019 13:34:26 +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 7D42C20064; Wed, 27 Feb 2019 13:34: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; Wed, 27 Feb 2019 13:34:26 +0100 Received: by anna.localdomain (Postfix, from userid 501) id BD5B73006D3560; Wed, 27 Feb 2019 13:34:25 +0100 (CET) Date: Wed, 27 Feb 2019 13:34:25 +0100 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel CC: "netmod@ietf.org" Message-ID: <20190227123425.2gognyc3gh56gby3@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.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) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 12:34:30 -0000 On Wed, Feb 27, 2019 at 11:16:55AM +0000, Bal=E1zs Lengyel wrote: > feature oldFeature { > status obsolete; > } >=20 > leaf myTimer { > if-feature oldFeature ; > mandatory true; > config true; > status current; > type string; > } >=20 > So should I configure myTimer or not? I assume yes, correct? Your server will tell you by announcing the features it implements. The compiler used by the server developer will likely tell him that there is something to look at. /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 Wed Feb 27 08:09:22 2019 Return-Path: <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-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 24FE6130EB2 for ; Wed, 27 Feb 2019 08:09:21 -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 m4b48hBcNFJt for ; Wed, 27 Feb 2019 08:09:19 -0800 (PST) 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 C05E8130E71 for ; Wed, 27 Feb 2019 08:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551283757; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=toIypt9IpP4fYLgPcdCqyIzAzbG70hO+r2rx2ZB/VoA=; b=No3gZ2jZ6tqNqi2sAXgxqJ9cTDutB1mxChpPaHJzo48UOAckqYgb+JfObK5AoUQg tztAZR4QrVAcCNujnxB0GYW0UKbH3SZKdIEIYkqcNtzIhablJaRSg0GqwNXdXX0/4YS pAuosDE7hL1zMycu6kbnFBIyC2ChE96EKaOG0Byw= From: Kent Watsen Message-ID: <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C602F074-EF72-46EE-B461-0EC42A0D9C92" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 27 Feb 2019 16:09:17 +0000 In-Reply-To: <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> Cc: "netmod@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.27-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 16:09:21 -0000 --Apple-Mail=_C602F074-EF72-46EE-B461-0EC42A0D9C92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 27, 2019, at 6:16 AM, Bal=C3=A1zs Lengyel = wrote: >=20 > feature oldFeature { > status obsolete; > } > leaf myTimer { > if-feature oldFeature ; > mandatory true; > config true; > status current; > type string; > } > So should I configure myTimer or not? I assume yes, correct? This issue is captured here: = https://github.com/netmod-wg/yang-next/issues/27, which was updated as = of this morning with this very example. Of course, the problem is in RFC 7950: o "obsolete" means that the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. I recommend replacing "SHOULD NOT be implemented" with "is not = implemented". =20 Then the answer to your question above would be "no", as "if-feature" = takes precedence. Kent --Apple-Mail=_C602F074-EF72-46EE-B461-0EC42A0D9C92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 27, 2019, at 6:16 AM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

=20 =20 
feature oldFeature {
  status obsolete;
}

leaf myTimer {
  if-feature oldFeature ;
  mandatory true;
  config true;
  status current;
  type string;
}

So should I configure myTimer or not? I = assume yes, correct?


This issue is = captured here: https://github.com/netmod-wg/yang-next/issues/27, which = was updated as of this morning with this very example.

Of course, the problem is in RFC 7950:

   o  "obsolete" means that the =
definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

I recommend replacing = "SHOULD NOT be implemented" with "is not implemented". =   

Then the answer to your = question above would be "no", as "if-feature" takes = precedence.

Kent




= --Apple-Mail=_C602F074-EF72-46EE-B461-0EC42A0D9C92-- From nobody Wed Feb 27 08:31:05 2019 Return-Path: <010001692fcb71bc-c5fbb484-a99a-4d1d-84c0-80447b5dead3-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 ABA1E130FF0 for ; Wed, 27 Feb 2019 08:31:01 -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 89_eJqTUquA6 for ; Wed, 27 Feb 2019 08:30:57 -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 39E3E130FFF for ; Wed, 27 Feb 2019 08:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551285056; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=uueRoZR9/3tmmvvb5ccYnvzxZCX6bNgz+P4qG9syZCk=; b=DRf+bflpbOzcXgCGmQXNkZ0ui02Gw1JkqClqSEhgpFePuZ90zUa9W9465r4dREpt utG6kWoqLJk0vGDi6hVPB9b3GR7Q10Sohq63o0Dkjn1MTegolPUC8wMz4QmIKX5D4p8 u+MxfnF+E+IY2rVeMAzX3qSHNqIV9XAXbJLqiMck= From: Kent Watsen Message-ID: <010001692fcb71bc-c5fbb484-a99a-4d1d-84c0-80447b5dead3-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_64365204-9292-43DB-96CB-FDB485F11A33" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 27 Feb 2019 16:30:56 +0000 In-Reply-To: <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> Cc: "adrian@olddog.co.uk" , Joel Jaeggli , "netmod@ietf.org" To: "Rob Wilton (rwilton)" References: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.27-54.240.8.96 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: Wed, 27 Feb 2019 16:31:02 -0000 --Apple-Mail=_64365204-9292-43DB-96CB-FDB485F11A33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, There seems to be some confusion. My original message said: Whereby this second form only supports the folded line = continuing on column 1 (no indents). To be clear, if indents are desired, I strongly support using the = double-backslash approach and do not recommend any other approach. =20 The tools team weren't looking at an indented example. They were = looking at an example where all the continuation lines occurred on column 1. Their = surprising/non-intuitive comment stems from only that experience. Some additional thinking behind this: I believe that tooling/automation = will do the folding most=20 of the time, and smart-indents are unlikely, thus the common-case will = be to begin the continuation line on column 1, in which case the second '\' character is not needed. = =20 I'm hoping to optimize for this common case scenario. I do not agree that having having two folding approaches is an issue. = I would like to see this=20 BCP have the broadest appeal possible. Kent // contributor > On Feb 27, 2019, at 5:09 AM, Rob Wilton (rwilton) = wrote: >=20 > Hi Adrian, > =20 > I mostly agree with your last sentence. > =20 > 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. > =20 > What I=E2=80=99m not keen on is using a single slash, and then = automatically stripping leading whitespace on the line following a = slash. > =20 > 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. > =20 > Thanks, > Rob > =20 > =20 > =20 > 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? > =20 > Complete agreement, Joel. > =20 > What follows may look better in proportional fonts. > =20 > With a single slash we can wrap as follows > =20 > 1234567 9012345 > =20 > Goes to=E2=80=A6 > =20 > 1234567 \ > 9012345 > =20 > =E2=80=A6and unwrapping is easy. > =20 > However, if I want to manually wrap the line with indentation > =20 > The quick brown fox jumps over the lazy dog > =20 > ..going to=E2=80=A6 > =20 > The quick brown fox\ > jumps over the lazy dog > =20 > =E2=80=A6I am going to unfold as=E2=80=A6 > =20 > The quick brown fox jumps over the lazy dog > =20 > =20 > Conversely, if I resolve this second case by stripping leading spaces = I get=E2=80=A6 > =20 > The quick brown foxjumps over the lazy dog > =20 > So I have to fold as=E2=80=A6 > =20 > The quick brown fox \ > jumps over the lazy dog > =20 > But this causes the first case to unfold as > =20 > 1234567 9012345 > =20 > =E2=80=A6i.e., with missing spaces. > =20 > This is what caused the use of the second slash so=E2=80=A6 > =20 > 1234567 \ > \ 9012345 > =20 > =E2=80=A6and=E2=80=A6 > =20 > The quick brown fox\ > \ jumps over the lazy dog > =20 > =20 > So, my point is, if and only if we do not care about these =E2=80=9Cspac= es on the fold=E2=80=9D cases, we can operate with a single slash. > =20 > Cheers, > Adrian > =20 > From: Joel Jaeggli >=20 > Sent: 27 February 2019 06:31 > To: Adrian Farrel > > Cc: Kent Watsen >; = netmod@ietf.org > Subject: Re: [netmod] artwork folding: dual support modes? > =20 > =20 > =20 >=20 > On Feb 26, 2019, at 14:26, Adrian Farrel > wrote: > =20 > Hey. > =20 > I=E2=80=99ve been having this discussion with Kent off-line, but = thought it should come to the list. > =20 > I don=E2=80=99t 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. > =20 > It doesn=E2=80=99t seem to me that both cases are needed. We can pick = one or the other. > =20 > A single slash has been used to wrap long lines in editors and shells = for decades at this point. > =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 = to make the document more human-readable then we have to use a leading = =E2=80=98\=E2=80=99 on continuation lines to show which spaces should be = stripped and which retained. > =20 > Cheers, > Adrian > =20 > From: netmod > On Behalf Of Kent Watsen > Sent: 25 February 2019 22:22 > To: netmod@ietf.org > Subject: [netmod] artwork folding: dual support modes? > =20 > =20 > 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.=20 > =20 > 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: > =20 > NOTE: '\\' line wrapping per BCP XX (RFC XXXX) > =20 > So why not *also* support a header that reads (note the singe slash): > =20 > NOTE: '\' line wrapping per BCP XX (RFC XXXX) > =20 > Whereby this second form only supports the folded line continuing on = column 1 (no indents). > =20 > Thoughts? > =20 > Kent // contributor > =20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_64365204-9292-43DB-96CB-FDB485F11A33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

All,

There seems to be some = confusion.  My original message said:

Whereby this second form only = supports the folded line continuing on column 1 (no indents).

To = be clear, if indents are desired, I strongly support using the = double-backslash approach and
do not recommend any = other approach.  

The tools team weren't looking at an indented example. =  They were looking at an example where
all the = continuation lines occurred on column 1.   Their = surprising/non-intuitive comment stems
from only = that experience.

Some additional thinking behind this:  I believe that = tooling/automation will do the folding most 
of = the time, and smart-indents are unlikely, thus the common-case will be = to begin the continuation
line on column 1, in = which case the second '\' character is not needed. =   

I'm= hoping to optimize for this common case scenario.

I do not agree that = having having two folding approaches is an issue.   I would like to = see this 
BCP have the broadest appeal = possible.

Kent = // contributor


On Feb = 27, 2019, at 5:09 AM, Rob Wilton (rwilton) <rwilton@cisco.com> = 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=E2=80=99m not keen on is using a single slash, and then automatically = stripping leading whitespace on the line following a slash.
 
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 = <netmod-bounces@ietf.org> On Behalf = Of Adrian = Farrel
Sent: 27 February 2019 09:41
To: 'Joel Jaeggli' <joelja@bogus.com>
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=E2=80=A6
 
1234567    \
    9012345
 
=E2=80=A6and 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=E2=80=A6
 
The quick brown fox\
      jumps over the lazy dog
 
=E2=80=A6I am going to unfold = as=E2=80=A6
 
The quick brown = fox      jumps over the lazy dog
 
 
Conversely, if I resolve this second case by = stripping leading spaces I get=E2=80=A6
 
The quick brown foxjumps over = the lazy dog
 
So I have to fold = as=E2=80=A6
 
The quick brown fox = \
      jumps over = the lazy dog
 
But this causes the = first case to unfold as
 
1234567    9012345
 
=E2=80=A6i.e., with missing = spaces.
 
This is what caused = the use of the second slash so=E2=80=A6
 
1234567    \
\    9012345
 
=E2=80=A6and=E2=80=A6
 
The quick brown fox\
     \ jumps over the lazy dog
 
 
So, my point is, if and only if we do not = care about these =E2=80=9Cspaces on the fold=E2=80=9D cases, we can = operate with a single slash.
 
Cheers,
Adrian
 
From: Joel = Jaeggli <joelja@bogus.com> 
Sent: 27 February 2019 06:31
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Kent Watsen <kent+ietf@watsen.net>; netmod@ietf.org
Subject: Re: [netmod] artwork = folding: dual support modes?
 
 

 

On Feb 26, 2019, at 14:26, Adrian Farrel <adrian@olddog.co.uk> = wrote:
 
Hey.
 
I=E2=80=99ve been having this = discussion with Kent off-line, but thought it should come to the = list.
 
I don=E2=80=99t 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=E2=80=99t 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 =E2=80=98\=E2=80=99 on continuation lines to = show which spaces should be stripped and which retained.
 
Cheers,
Adrian
 
From: netmod <netmod-bounces@ietf.org> 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
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_64365204-9292-43DB-96CB-FDB485F11A33-- From peter.loborg@ericsson.com Thu Feb 21 10:07: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 129811310F6 for ; Thu, 21 Feb 2019 10:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_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=SzDk9SLN; dkim=pass (1024-bit key) header.d=ericsson.com header.b=JBDz/Gja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPgYq-IcGbkx for ; Thu, 21 Feb 2019 10:07:05 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 99E6E1310D8 for ; Thu, 21 Feb 2019 10:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550772422; x=1553364422; 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=6Acq1Cq7PttU1OwLcZIIxs3F8k40wRxig/1Ef68W778=; b=SzDk9SLN+344ege7stL4DvPWcfsAthRYytE5yy7x+sDV1e6iF0RrcWXqbADXMp6W wZxagB7zFYoFST+HEXPgRT/dKKSPcgWe3BdyDsvWYsdxHcM8QBmQoIQ+a3wvVVJN Cz3AHkQqEPWWteyHyd/zMxWMjHIcWMm7j6MLr+og64w=; X-AuditID: c1b4fb3a-14fff7000000672c-42-5c6ee8c60925 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 28.5D.26412.6C8EE6C5; Thu, 21 Feb 2019 19:07:02 +0100 (CET) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 21 Feb 2019 19:07:02 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Thu, 21 Feb 2019 19:07:02 +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=6Acq1Cq7PttU1OwLcZIIxs3F8k40wRxig/1Ef68W778=; b=JBDz/GjaHEkprYEtM+bQUmhrRhSC/momDqOchrm6iJ8ttJDfVHCa3r5bzKeIf2U5PdudSoEMXMHrHsNwqkA8WoQvNL97o1JF/oVw7HvEkA4g/2HYxrGoZXuhA2z0hvH+5EmCACU9nLleaGhgSfwZafpxFnST4ZNV1TmFh7OCqAw= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2684.eurprd07.prod.outlook.com (10.168.183.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.5; Thu, 21 Feb 2019 18:07:00 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::1cbb:43e1:d406:1a0a]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::1cbb:43e1:d406:1a0a%6]) with mapi id 15.20.1665.006; Thu, 21 Feb 2019 18:06:59 +0000 From: Peter Loborg To: Andy Bierman , Martin Bjorklund CC: RFC Editor , Ignas Bagdonas , NetMod WG , Warren Kumari Thread-Topic: [netmod] [Editorial Errata Reported] RFC7950 (5642) Thread-Index: AQHUygQR6wP9nfxQokyPEpmnm5zeAqXqd/AAgAAOdwCAAAHjwA== Date: Thu, 21 Feb 2019 18:06:59 +0000 Message-ID: References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.231.235.60] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41fbed53-56d3-46f8-78f2-08d698275fe6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2684; x-ms-traffictypediagnostic: HE1PR0701MB2684: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjI2ODQ7MjM6NTcyL1JRS1JVaFltdzdJRXhsWjltMStZ?= =?utf-8?B?QWhkT240Zzl2SlFhRmtKSEs5NzFMVjhVd00yWjh3ZDFKdXY5d2VVeG9pR1Jz?= =?utf-8?B?ZWR1SWQ5UkRiMXF6R2I1b1VnVnNBN2JDMEZlSEZVWS9jelp3SkR5ZTN2QWIr?= =?utf-8?B?bFg1d2F4Sm5rYkFQZDFpSTIxVnlvSys0RFoya0VGOVB2WEE5Z1BKczE3b0dH?= =?utf-8?B?dVFlRmh0UEd2elRqUmpPekF1QVRHcUdQQS9mTnRxcGtBc2VmRzZ4dXlhc2E3?= =?utf-8?B?MWxjektrWHJqQmtLclJKa2lTK0NnVlpUd1RjUnpjU3VuZGdPRFBYdmNyNFNo?= =?utf-8?B?a0F5NzFaM0U2SFBNZHppK01vSThRYjNJYUx2MG5BTHpWZmJSQWtkUzhPU3Fq?= =?utf-8?B?N3k1UEhjZ3pZTTlKa05NWjRqbk90NmEyaEZYS2pxVmxjUzVURkd2dkhLYlc4?= =?utf-8?B?Sk1heTcyR2lSdkRLaktDUGh6VHQwOUZpT0Z6MjZDU3hsZGtSbkJhUjhES0tl?= =?utf-8?B?WVlUQjlESHFhR0p1RzVleGFQODUzbk00T213VUR6VjJmYXRtVXE3bHFZVUZy?= =?utf-8?B?SDV1RkJoVWx1SDVvYk85STAzL0dVanJYakFJWFo3MjBMeDBoYW84amxvYzJa?= =?utf-8?B?L01pdmo0emJKTWVxaXBXNW9LVlgwOGpvRWJIYWlqRXlPVlVtamVZUnVRRG80?= =?utf-8?B?VmR1b1NBTFNjVnpDUytsMHkwNHpWRkJneDdNY2Iyc1I1TVVYblNCOVh0WG5R?= =?utf-8?B?NTZmOU4zQnJrRGpTNXBobVMyOVQ5U0UySXcwckROYTV4UmRGU1l3V0VTL1Yv?= =?utf-8?B?REJWa2x4LzM4bnJPTjlnaXd2VFRhTVBIM3o0dWV0cElIbGp2dEdmRlIzMGEw?= =?utf-8?B?ZStjREFyWnZjOThFKzZuM1dCZ3NvcmwyWlE3T2FsRTRzaXRwVzhIYU9Nb3hQ?= =?utf-8?B?dnY1aXJYaEMyQnJJOHowU3l4bjhTM3Rjckl6Uit5cUtQdzhlWFR3aTFZTVFo?= =?utf-8?B?V1QyNU5PZDBadyt2Um5kRDI4UmJFOTY5cHE2eHFuWE13ZTByb0VZemVFU3pI?= =?utf-8?B?QkVreFVhV1E1bjFERExmNUhsVEFhb2ExcmNHWStRMkM2VE5hUkFTTmR4NFR0?= =?utf-8?B?L0pyeGlkVDVBZndWQTRPT3RBb3lleW1lNWJzVERodVNnSU5pMzZZc2doOU1F?= =?utf-8?B?UVZ6bXptcXd1c2M3MHdMb2xuazlvemxOK21pS0pqM0ZhY3NMdngzOG1PdnhC?= =?utf-8?B?NjZRSk5USTJTbEFqNExNZFl4d2UwV01iYXdpNzY0MTBZdVVvdExqczY4ZGE2?= =?utf-8?B?S2pZb2pOT2Y4a3V5eFU1MmI2dktKb2UvQmF0aEtlOXZSeXlNbzNRdkJvM0pn?= =?utf-8?B?OFlRYjZNdDJYTUlEOUQ2RFJRQUFlZFFDbSs5RkxuYmFQVW43Qi9LeXd0SjI5?= =?utf-8?B?T3hZdVhUck1YMGtZN1VGaVJwTGpBaGZTcncvN0NzeFQvczkvUkcwSkNsZlY4?= =?utf-8?B?MWoxSHFwUG41T3VuYThTYTJQNUdKVm1GS1J6eGlKeWVGbDNVUys2ZGFkeW9O?= =?utf-8?B?SDc3T1NzZ2pEMW9yQWZjNEhuUEx4VFJsazEwaHZLcGpBeWozbDBsNWxESU9F?= =?utf-8?B?b2lVM3NHNTQvZVkxUGV1R0ppcmowZGZnU3lSWnNMY000NnZiZTJlc1RMSE9x?= =?utf-8?B?MTNwUTZoY21oS3FSY2lqYjY3cDlKQVprdGJRTlRGbXFMdlNYQ2MyRjg1Q3RR?= =?utf-8?B?Ym5ubWZ6cE14eTV3b2JXdW9WUWlvNzY0R0dCd2lKRHJ1WVNQd2hCQUY3bFJ4?= =?utf-8?B?QVlsbGpVc2xkelg2Yk4vR3pLdnJGa1FicGZhUGVOWEJDZTJtZz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(376002)(366004)(39860400002)(396003)(189003)(199004)(33656002)(81156014)(97736004)(8936002)(66066001)(7736002)(186003)(476003)(446003)(81166006)(11346002)(105586002)(26005)(6346003)(102836004)(3846002)(790700001)(8676002)(229853002)(106356001)(14444005)(99286004)(6116002)(7696005)(606006)(6436002)(256004)(4326008)(55016002)(5660300002)(68736007)(6306002)(54896002)(9686003)(76176011)(236005)(6506007)(53546011)(74316002)(966005)(2906002)(6246003)(478600001)(486006)(86362001)(44832011)(110136005)(54906003)(25786009)(53936002)(71200400001)(71190400001)(14454004)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2684; H:HE1PR0701MB2905.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=peter.loborg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BL9l5x8NvIdq9oEsY3eVxppIWDqftMXjxOeXuB30ktdlQIE+UkZIvvhd9crAPtEAmFKiqp+tgZO8Mm6DUh2Xxaes3/cG4Ik2XXzKDRKGi+84lDlMK9Ep+I75StDE1AjdbGnKKjmioEtpiGuCAigM+HLQ5PFNy2cAYT2xtihZHJZhn4YWVU8BxQ/8d78HFfzSpNyQhP7nhTtWpqPA3eHkZ/vxAuG8zylOlgh0p/4sPSa1CkJFMhFvBCN1dpBedbG+Ud8x1tgnuQUH2zJKIc6xFe2Hhj2WNJjLTvpF3BKiQ1vR09vYhnfPjoI8sI2Ct672WVP/70SPch0tjqumWRSu4JoP+5JxA0CoxHy9QRLFNbOzFEuNjVv7c/foLV0MXcocBdLg/4KrT+p//A4KvjGqSk0nRbEFkU08ORL3lkGCbgE= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB29053FE1EC7A4F199C688050EA7E0HE1PR0701MB2905_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41fbed53-56d3-46f8-78f2-08d698275fe6 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 18:06:59.7728 (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: HE1PR0701MB2684 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe++9u/dutHpbRgdrgYNCo1la1Igyk6hBBCVJX6NcefF7k3tN 0yjsQyuXaCwIl7LUgVmGFn6kGOUSTQMtlbDEsjRdKpmUqRXWttfA/37nnOc8z3vg5WlVl8yX jzUlC6LJmKBhFUz+4dpUbbPLZNhwz75K199k43TfL1xjdBbLEKezv74g0118Osnqnjd3UaGs vs7Wx+kdjhlK39vzh9NnZDXL9A9/lTD6y7mvmf3sUcW2KCEhNkUQ14dEKmLyBqxUUnY2dWa4 5jebga5forKRnAe8Cd7Yf7hZwatwE4LJyVKaFD8R/H2VJSOFg4KCgjaZZ4XBeTRkT58lg1sU OPvus6QYQlA328B5VCwOhH5nk9uL532wHsoLdns0NLYi+Pbjvjd8KQ6F2ZkRxsM+eCd0ZXWz hMOguuItRdJWw+fKNq+nEkeCPacEkbBqBO19E16RHB+An63tyMMIq+HD1HuvKY2Xw7tB+9yl GBwNHTThZfBlYFZG2A86ukcQYTV02i1zvA/qxysYTxjgXgSF3ePIcw3gdfDiSRjR+MLUwARH NOUqsBb3zJma4drwFY7wSqgZLaKIyMLCRWuxN0GFBSh9kInykNY277E2dwbt3v/lQDbv0Uug NX+QIe0AqKhfT9R+cNPykSPsD5kFhdz8/h3E3UPLJEGSEqODgwMFMfaUJJlNgSYh+RFyf7XG qt9bH6PG4Z1OhHmkWag0dJsMKpkxRUpLdCLgaY2PcvqVu6WMMqalC6L5hHg6QZCcaAXPaJYr /6iWGFQ42pgsxAtCkiD+n1K83DcD8WsmDEkB8Wl7NleNhLvC+hR7D6U1KKjEZ11xx561JrT5 V9wqUo6E1bYuyI3P3Nh7A39Njai8+3K31hV9snaUtmwSlbefR+86PpPREvLhnFw7FpK6yM98 siVcXWaN3e4oTC87pg3aEVG1svH8Ylf/1SMHOw+ox/Lli/P/Fsdtqcz5pGGkGGPQWlqUjP8A 4uhU8mYDAAA= Archived-At: X-Mailman-Approved-At: Wed, 27 Feb 2019 08:33:21 -0800 Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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, 21 Feb 2019 21:03:22 -0000 --_000_HE1PR0701MB29053FE1EC7A4F199C688050EA7E0HE1PR0701MB2905_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpZb3VyIGV4YW1wbGUgaXMgZmluZSDigJMgYnV0IHRoZSBnYW1tYXIgaXMgY2gxNCBzcGVjaWZp ZXMgc29tZXRoaW5nIGRpZmZlcmVudDoNCg0KZW51bS1zdG10ICAgICAgICAgICA9IGVudW0ta2V5 d29yZCBzZXAgc3RyaW5nIG9wdHNlcA0KICAgICAgICAgICAgICAgICAgICAgICAgICgiOyIgLw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAieyIgc3RtdHNlcA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgOzsgdGhlc2Ugc3RtdHMgY2FuIGFwcGVhciBpbiBhbnkgb3JkZXINCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICppZi1mZWF0dXJlLXN0bXQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFt2YWx1ZS1zdG10XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW3N0YXR1cy1zdG10XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2Rlc2NyaXB0 aW9uLXN0bXRdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbcmVmZXJlbmNlLXN0bXRd DQogICAgICAgICAgICAgICAgICAgICAgICAgICAifSIpIHN0bXRzZXANCg0KSXQgY2xlYXJseSBz dGF0ZXMgIHN0cmluZywgbm90IHF1b3RlZC1zdHJpbmcuIFRoZXNlIHR3byBoYXZlIHRoZSBmb2xs b3dpbmcgcnVsZXM6DQoNCnF1b3RlZC1zdHJpbmcgICAgICAgPSAoRFFVT1RFIHN0cmluZyBEUVVP VEUpIC8gKFNRVU9URSBzdHJpbmcgU1FVT1RFKQ0KDQpzdHJpbmcgICAgICAgICAgICAgID0gPCBh biB1bnF1b3RlZCBzdHJpbmcsIGFzIHJldHVybmVkIGJ5ID4NCiAgICAgICAgICAgICAgICAgICAg ICAgICA8IHRoZSBzY2FubmVyLCB0aGF0IG1hdGNoZXMgdGhlIHJ1bGUgPg0KICAgICAgICAgICAg ICAgICAgICAgICAgIDwgeWFuZy1zdHJpbmcgPg0KDQrigKZhbmQgaW4gNi4xLjMgd2UgY2FuIHJl YWQgdGhhdDoNCiAgIEFuIHVucXVvdGVkIHN0cmluZyBpcyBhbnkgc2VxdWVuY2Ugb2YgY2hhcmFj dGVycyB0aGF0IGRvZXMgbm90DQogICBjb250YWluIGFueSBzcGFjZSwgdGFiLCBjYXJyaWFnZSBy ZXR1cm4sIG9yIGxpbmUgZmVlZCBjaGFyYWN0ZXJzLCBhDQogICBzaW5nbGUgb3IgZG91YmxlIHF1 b3RlIGNoYXJhY3RlciwgYSBzZW1pY29sb24gKCI7IiksIGJyYWNlcyAoInsiIG9yDQogICAifSIp LCBvciBjb21tZW50IHNlcXVlbmNlcyAoIi8vIiwgIi8qIiwgb3IgIiovIikuDQoNCiAgIE5vdGUg dGhhdCBhbnkga2V5d29yZCBjYW4gbGVnYWxseSBhcHBlYXIgYXMgYW4gdW5xdW90ZWQgc3RyaW5n Lg0KDQpTaW5jZSB0aGUgc2VjdGlvbiBzbyBjbGVhcmx5IHdyaXRlcyBhYm91dCBzaW5nbGUgcXVv dGVkIHN0cmluZ3MgYW5kIGRvdWJsZSBxdW90ZWQgc3RyaW5ncywgdGhlcmUgY2FuIHVuZm9ydHVu YXRlbHkgYmUgbm8gaW50ZXJwcmV0YXRpb24gdGhhdCB3b3VsZCBhbGxvdyDigJxpZGVudGlmaWVy 4oCdIHRvIGJlIGNhbGxlZCBhbiB1bnF1b3RlZCBzdHJpbmcg4oCTIGV2ZW4gdGhvdWdoIGl0IGZv bGxvd3MgdGhlIHJ1bGVzIGFib3V0IGxpbWl0ZWQgY2hhcmFjdGVyIGNvbnRlbnRzLg0KDQpIZW5j ZSDigJMgdGhpcyBpcyBub3QgYSBtYXR0ZXIgb2Ygb3BpbmlvbiDigJMgaXTigJlzIGEgbWF0dGVy IG9mIHJlYWRpbmcgd2hhdOKAmXMgYWN0dWFsbHkgd3JpdHRlbiBpbiB0aGUgUkZDLg0KDQpCdXQg b24gdGhlIHN1YmplY3Qgb2Ygb3BpbmlvbuKApg0KDQogICAgICBlbnVtICJUaGlzIGlzIGFsc28g bGVnYWwiOyAgIC8vIHNob3VsZCBkZWZpbml0ZWx5IGFsd2F5cyBiZSBpbGxlZ2FsDQoNCuKApmFz IHdlIGNhbm5vdCBjcmVhdGUgYSBsYW5ndWFnZSBiaW5kaW5nIHRvIGVudW0gY29uc3RydWN0cyBp biBhbnkgbWFqb3IgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzLg0KDQpCciwNClBldGVyDQoNCg0KRnJv bTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50OiBkZW4gMjEgZmVicnVh cmkgMjAxOSAxODo0NQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPg0KQ2M6 IFJGQyBFZGl0b3IgPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+OyBJZ25hcyBCYWdkb25hcyA8 aWJhZ2RvbmFAZ21haWwuY29tPjsgTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+OyBQZXRlciBM b2JvcmcgPHBldGVyLmxvYm9yZ0Blcmljc3Nvbi5jb20+OyBXYXJyZW4gS3VtYXJpIDx3YXJyZW5A a3VtYXJpLm5ldD4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBbRWRpdG9yaWFsIEVycmF0YSBSZXBv cnRlZF0gUkZDNzk1MCAoNTY0MikNCg0KDQoNCk9uIFRodSwgRmViIDIxLCAyMDE5IGF0IDg6NTMg QU0gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29t Pj4gd3JvdGU6DQpSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzxt YWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4+IHdyb3RlOg0KPiBUaGUgZm9sbG93aW5n IGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM3OTUwLA0KPiAiVGhlIFlB TkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UiLg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFu ZCBhdDoNCj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTY0Mg0KPg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUeXBlOiBFZGl0b3JpYWwN Cj4gUmVwb3J0ZWQgYnk6IFBldGVyIExvYm9yZyA8cGV0ZXIubG9ib3JnQGVyaWNzc29uLmNvbTxt YWlsdG86cGV0ZXIubG9ib3JnQGVyaWNzc29uLmNvbT4+DQo+DQo+IFNlY3Rpb246IDkuNi40DQo+ DQo+IE9yaWdpbmFsIFRleHQNCj4gLS0tLS0tLS0tLS0tLQ0KPiBJdCB0YWtlcyBhcyBhbiBhcmd1 bWVudCBhIHN0cmluZyB0aGF0IGlzIHRoZSBhc3NpZ25lZCBuYW1lLg0KPg0KPiBDb3JyZWN0ZWQg VGV4dA0KPiAtLS0tLS0tLS0tLS0tLQ0KPiBJdCB0YWtlcyBhcyBhbiBhcmd1bWVudCBhbiB1bnF1 b3RlZCBzdHJpbmcgdGhhdCBpcyB0aGUgYXNzaWduZWQgbmFtZS4NCg0KVGhpcyBpcyBub3QgY29y cmVjdC4gIFRoZSBlbnVtIGFyZ3VtZW50IGlzIG5vdCBkaWZmZXJlbnQgZnJvbSBhbnkNCm90aGVy IGtleXdvcmQncyBhcmd1bWVudHMgaW4gWUFORy4gIFNlZSBlLmcuIHRoZSBleGFtcGxlIGluIDku MTIuNDoNCg0KICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICAgZW51bSAidW5ib3Vu ZGVkIjsNCiAgICAgICB9DQoNClRoZSBmb2xsb3dpbmcgaXMgYWxzbyBsZWdhbDoNCg0KICAgICAg ICAgZW51bSAidW5iIiArICdvdW5kZWQnOw0KDQoNCg0KICBlbnVtICJUaGlzIGlzIGFsc28gbGVn YWwiOw0KDQoNCjkuNi40LiAgVGhlICJlbnVtIiBTdGF0ZW1lbnQNCg0KDQoNCiAgIFRoZSAiZW51 bSIgc3RhdGVtZW50LCB3aGljaCBpcyBhIHN1YnN0YXRlbWVudCB0byB0aGUgInR5cGUiDQoNCiAg IHN0YXRlbWVudCwgTVVTVCBiZSBwcmVzZW50IGlmIHRoZSB0eXBlIGlzICJlbnVtZXJhdGlvbiIu ICBJdCBpcw0KDQogICByZXBlYXRlZGx5IHVzZWQgdG8gc3BlY2lmeSBlYWNoIGFzc2lnbmVkIG5h bWUgb2YgYW4gZW51bWVyYXRpb24gdHlwZS4NCg0KICAgSXQgdGFrZXMgYXMgYW4gYXJndW1lbnQg YSBzdHJpbmcgdGhhdCBpcyB0aGUgYXNzaWduZWQgbmFtZS4gIFRoZQ0KDQogICBzdHJpbmcgTVVT VCBOT1QgYmUgemVyby1sZW5ndGggYW5kIE1VU1QgTk9UIGhhdmUgYW55IGxlYWRpbmcgb3INCg0K ICAgdHJhaWxpbmcgd2hpdGVzcGFjZSBjaGFyYWN0ZXJzIChhbnkgVW5pY29kZSBjaGFyYWN0ZXIg d2l0aCB0aGUNCg0KICAgIldoaXRlX1NwYWNlIiBwcm9wZXJ0eSkuICBUaGUgdXNlIG9mIFVuaWNv ZGUgY29udHJvbCBjb2RlcyBTSE9VTEQgYmUNCg0KICAgYXZvaWRlZC4NCg0KDQpUaGlzIGVycmF0 YSBzaG91bGQgYmUgcmVqZWN0ZWQuDQoNCg0KDQovbWFydGluDQoNCg0KQW5keQ0KDQoNCj4NCj4g Tm90ZXMNCj4gLS0tLS0NCj4gUmVhZGVycyBhcmUgbm90IGJlZWluZyBtYWRlIGF3YXJlIHRoYXQg Y2FyZWZ1bCByZWFkaW5nIG9mIHNlY3Rpb24gNi4xLjMgYW5kIHRoZSBkZXRhaWxlZCBkZWZpbml0 aW9uIG9mIHN0cmluZyBpbiBzZWN0aW9uIDE0IG11c3QgYmUgY29uc3VsdGVkLg0KPiBGb3IgY29t bWluZyB2ZXJzaW9ucyBvZiB0aGlzIFJGQyBpdCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvIHVzZSBh IG1vcmUgc3BlY2lhbGl6ZWQgZ3JhbW1hciB0b2tlbiBmb3IgdGhlc2UgY2FzZXMgKGUuZy4gdW5x dW90ZWQtc3RyaW5nKS4NCj4NCj4gSW5zdHJ1Y3Rpb25zOg0KPiAtLS0tLS0tLS0tLS0tDQo+IFRo aXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5lY2Vzc2Fy eSwgcGxlYXNlDQo+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxk IGJlIHZlcmlmaWVkIG9yDQo+IHJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwg dGhlIHZlcmlmeWluZyBwYXJ0eQ0KPiBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFu ZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gUkZDNzk1MCAoZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAy MGJpcy0xNCkNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGl0 bGUgICAgICAgICAgICAgICA6IFRoZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlDQo+ IFB1YmxpY2F0aW9uIERhdGUgICAgOiBBdWd1c3QgMjAxNg0KPiBBdXRob3IocykgICAgICAgICAg IDogTS4gQmpvcmtsdW5kLCBFZC4NCj4gQ2F0ZWdvcnkgICAgICAgICAgICA6IFBST1BPU0VEIFNU QU5EQVJEDQo+IFNvdXJjZSAgICAgICAgICAgICAgOiBOZXR3b3JrIE1vZGVsaW5nDQo+IEFyZWEg ICAgICAgICAgICAgICAgOiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50DQo+IFN0cmVhbSAgICAg ICAgICAgICAgOiBJRVRGDQo+IFZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGlu ZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_HE1PR0701MB29053FE1EC7A4F199C688050EA7E0HE1PR0701MB2905_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlNWO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBMQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiUEwgQ2hhciI7DQoJbXNvLXN0eWxlLWxpbms6UEw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLlBMLCBsaS5QTCwgZGl2LlBMDQoJe21zby1zdHls ZS1uYW1lOlBMOw0KCW1zby1zdHlsZS1saW5rOiJQTCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglwdW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNCgl0ZXh0LWF1 dG9zcGFjZTpub25lOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iU1YiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WW91ciBleGFtcGxlIGlzIGZpbmUg 4oCTIGJ1dCB0aGUgZ2FtbWFyIGlzIGNoMTQgc3BlY2lmaWVzIHNvbWV0aGluZyBkaWZmZXJlbnQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5lbnVtLXN0bXQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSBlbnVtLWtleXdvcmQgc2VwIHN0cmluZyBvcHRz ZXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAo JnF1b3Q7OyZxdW90OyAvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7eyZxdW90OyBzdG10c2VwPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgOzsgdGhlc2Ugc3RtdHMgY2FuIGFwcGVhciBpbiBhbnkgb3JkZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqaWYtZmVhdHVyZS1zdG10PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW3ZhbHVlLXN0bXRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW3N0YXR1cy1zdG10XTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtkZXNjcmlwdGlvbi1zdG10XTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFtyZWZlcmVuY2Utc3RtdF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDt9JnF1b3Q7KSBzdG10 c2VwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXQgY2xlYXJseSBzdGF0ZXMmbmJz cDsgc3RyaW5nLCBub3QgcXVvdGVkLXN0cmluZy4gVGhlc2UgdHdvIGhhdmUgdGhlIGZvbGxvd2lu ZyBydWxlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPnF1b3RlZC1zdHJpbmcmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPSAoRFFVT1RFIHN0cmluZyBEUVVPVEUpIC8gKFNRVU9URSBzdHJpbmcg U1FVT1RFKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+c3RyaW5nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gJmx0OyBh biB1bnF1b3RlZCBzdHJpbmcsIGFzIHJldHVybmVkIGJ5ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7IHRoZSBzY2FubmVyLCB0aGF0 IG1hdGNoZXMgdGhlIHJ1bGUgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsgeWFuZy1zdHJpbmcgJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPuKApmFuZCBpbiA2LjEuMyB3ZSBjYW4gcmVhZCB0aGF0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEFuIHVucXVvdGVkIHN0cmluZyBpcyBhbnkgc2Vx dWVuY2Ugb2YgY2hhcmFjdGVycyB0aGF0IGRvZXMgbm90PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgY29udGFpbiBhbnkgc3BhY2UsIHRhYiwgY2FycmlhZ2UgcmV0dXJuLCBvciBs aW5lIGZlZWQgY2hhcmFjdGVycywgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHNpbmdsZSBvciBkb3VibGUgcXVvdGUgY2hhcmFjdGVyLCBhIHNlbWljb2xvbiAoJnF1b3Q7OyZx dW90OyksIGJyYWNlcyAoJnF1b3Q7eyZxdW90OyBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7ICZxdW90O30mcXVvdDspLCBvciBjb21tZW50IHNlcXVlbmNlcyAoJnF1b3Q7Ly8m cXVvdDssICZxdW90Oy8qJnF1b3Q7LCBvciAmcXVvdDsqLyZxdW90OykuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBOb3RlIHRo YXQgYW55IGtleXdvcmQgY2FuIGxlZ2FsbHkgYXBwZWFyIGFzIGFuIHVucXVvdGVkIHN0cmluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TaW5jZSB0aGUgc2VjdGlvbiBzbyBjbGVh cmx5IHdyaXRlcyBhYm91dCBzaW5nbGUgcXVvdGVkIHN0cmluZ3MgYW5kIGRvdWJsZSBxdW90ZWQg c3RyaW5ncywgdGhlcmUgY2FuIHVuZm9ydHVuYXRlbHkgYmUgbm8gaW50ZXJwcmV0YXRpb24gdGhh dCB3b3VsZCBhbGxvdyDigJxpZGVudGlmaWVy4oCdIHRvIGJlIGNhbGxlZCBhbg0KIHVucXVvdGVk IHN0cmluZyDigJMgZXZlbiB0aG91Z2ggaXQgZm9sbG93cyB0aGUgcnVsZXMgYWJvdXQgbGltaXRl ZCBjaGFyYWN0ZXIgY29udGVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGVu Y2Ug4oCTIHRoaXMgaXMgbm90IGEgbWF0dGVyIG9mIG9waW5pb24g4oCTIGl04oCZcyBhIG1hdHRl ciBvZiByZWFkaW5nIHdoYXTigJlzIGFjdHVhbGx5IHdyaXR0ZW4gaW4gdGhlIFJGQy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CdXQgb24gdGhlIHN1YmplY3Qgb2Ygb3BpbmlvbuKA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBlbnVt ICZxdW90O1RoaXMgaXMgYWxzbyBsZWdhbCZxdW90OzsmbmJzcDsmbmJzcDsgLy8gc2hvdWxkIGRl ZmluaXRlbHkgYWx3YXlzIGJlIGlsbGVnYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij7igKZhcyB3ZSBjYW5ub3QgY3JlYXRlIGEgbGFuZ3VhZ2UgYmluZGluZyB0byBlbnVtIGNvbnN0 cnVjdHMgaW4gYW55IG1ham9yIHByb2dyYW1taW5nIGxhbmd1YWdlcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5Cciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5QZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBBbmR5IEJpZXJtYW4gJmx0O2Fu ZHlAeXVtYXdvcmtzLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMjEgZmVicnVhcmkg MjAxOSAxODo0NTxicj4NCjxiPlRvOjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwt Zi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSRkMgRWRpdG9yICZsdDtyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnJmd0OzsgSWduYXMgQmFnZG9uYXMgJmx0O2liYWdkb25hQGdtYWlsLmNvbSZndDs7 IE5ldE1vZCBXRyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0OzsgUGV0ZXIgTG9ib3JnICZsdDtwZXRl ci5sb2JvcmdAZXJpY3Nzb24uY29tJmd0OzsgV2FycmVuIEt1bWFyaSAmbHQ7d2FycmVuQGt1bWFy aS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBbRWRpdG9yaWFsIEVy cmF0YSBSZXBvcnRlZF0gUkZDNzk1MCAoNTY0Mik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g VGh1LCBGZWIgMjEsIDIwMTkgYXQgODo1MyBBTSBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj48c3BhbiBsYW5nPSJFTi1VUyI+bWJqQHRh aWwtZi5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkMgRXJyYXRhIFN5c3RlbSAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gbGFuZz0iRU4tVVMiPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgVGhlIGZvbGxvd2luZyBl cnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNzk1MCw8YnI+DQomZ3Q7ICZx dW90O1RoZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlJnF1b3Q7Ljxicj4NCiZndDsg PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsgWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6PGJyPg0KJmd0OyA8L3Nw YW4+PGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTY0MiIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2VycmF0YS9laWQ1NjQyPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0 OyBUeXBlOiBFZGl0b3JpYWw8YnI+DQomZ3Q7IFJlcG9ydGVkIGJ5OiBQZXRlciBMb2JvcmcgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGV0ZXIubG9ib3JnQGVyaWNzc29uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5wZXRlci5sb2JvcmdAZXJpY3Nzb24uY29tPC9z cGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBTZWN0 aW9uOiA5LjYuNDxicj4NCiZndDsgPGJyPg0KJmd0OyBPcmlnaW5hbCBUZXh0PGJyPg0KJmd0OyAt LS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBJdCB0YWtlcyBhcyBhbiBhcmd1bWVudCBhIHN0cmluZyB0 aGF0IGlzIHRoZSBhc3NpZ25lZCBuYW1lLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ29ycmVjdGVk IFRleHQ8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBJdCB0YWtlcyBhcyBhbiBh cmd1bWVudCBhbiB1bnF1b3RlZCBzdHJpbmcgdGhhdCBpcyB0aGUgYXNzaWduZWQgbmFtZS48YnI+ DQo8YnI+DQpUaGlzIGlzIG5vdCBjb3JyZWN0LiZuYnNwOyBUaGUgZW51bSBhcmd1bWVudCBpcyBu b3QgZGlmZmVyZW50IGZyb20gYW55PGJyPg0Kb3RoZXIga2V5d29yZCdzIGFyZ3VtZW50cyBpbiBZ QU5HLiZuYnNwOyBTZWUgZS5nLiB0aGUgZXhhbXBsZSBpbiA5LjEyLjQ6PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBlbnVtZXJhdGlvbiB7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudW0gJnF1b3Q7dW5ib3VuZGVkJnF1b3Q7Ozxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQo8YnI+DQpUaGUgZm9sbG93aW5nIGlz IGFsc28gbGVnYWw6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2VudW0gJnF1b3Q7dW5iJnF1b3Q7ICYjNDM7ICdvdW5kZWQnOzxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgZW51bSAmcXVvdDtUaGlzIGlzIGFsc28gbGVnYWwm cXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj45LjYuNC4mbmJzcDsgVGhlICZxdW90O2Vu dW0mcXVvdDsgU3RhdGVtZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgVGhlICZxdW90O2VudW0mcXVvdDsgc3RhdGVtZW50LCB3aGljaCBpcyBhIHN1YnN0YXRl bWVudCB0byB0aGUgJnF1b3Q7dHlwZSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc3Rh dGVtZW50LCBNVVNUIGJlIHByZXNlbnQgaWYgdGhlIHR5cGUgaXMgJnF1b3Q7ZW51bWVyYXRpb24m cXVvdDsuJm5ic3A7IEl0IGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZXBlYXRlZGx5IHVz ZWQgdG8gc3BlY2lmeSBlYWNoIGFzc2lnbmVkIG5hbWUgb2YgYW4gZW51bWVyYXRpb24gdHlwZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEl0IHRha2VzIGFzIGFuIGFyZ3VtZW50IGEgc3RyaW5n IHRoYXQgaXMgdGhlIGFzc2lnbmVkIG5hbWUuJm5ic3A7IDxiPlRoZTxvOnA+PC9vOnA+PC9iPjwv c3Bhbj48L3ByZT4NCjxwcmU+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHN0cmluZyBNVVNUIE5PVCBiZSB6ZXJvLWxlbmd0aCBhbmQgTVVTVCBO T1QgaGF2ZSBhbnkgbGVhZGluZyBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3ByZT4NCjxwcmU+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRy YWlsaW5nIHdoaXRlc3BhY2UgY2hhcmFjdGVyczwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+IChhbnkgVW5pY29kZSBjaGFyYWN0ZXIgd2l0aCB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZxdW90O1doaXRlX1NwYWNlJnF1b3Q7IHByb3BlcnR5KS4m bmJzcDsgVGhlIHVzZSBvZiBVbmljb2RlIGNvbnRyb2wgY29kZXMgU0hPVUxEIGJlPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBhdm9pZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+VGhpcyBlcnJhdGEgc2hvdWxkIGJlIHJlamVjdGVkLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCi9tYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3Rlczxicj4NCiZn dDsgLS0tLS08YnI+DQomZ3Q7IFJlYWRlcnMgYXJlIG5vdCBiZWVpbmcgbWFkZSBhd2FyZSB0aGF0 IGNhcmVmdWwgcmVhZGluZyBvZiBzZWN0aW9uIDYuMS4zIGFuZCB0aGUgZGV0YWlsZWQgZGVmaW5p dGlvbiBvZiBzdHJpbmcgaW4gc2VjdGlvbiAxNCBtdXN0IGJlIGNvbnN1bHRlZC48YnI+DQomZ3Q7 IEZvciBjb21taW5nIHZlcnNpb25zIG9mIHRoaXMgUkZDIGl0IHdvdWxkIGJlIHByZWZlcmFibGUg dG8gdXNlIGEgbW9yZSBzcGVjaWFsaXplZCBncmFtbWFyIHRva2VuIGZvciB0aGVzZSBjYXNlcyAo ZS5nLiB1bnF1b3RlZC1zdHJpbmcpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJbnN0cnVjdGlvbnM6 PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBUaGlzIGVycmF0dW0gaXMgY3VycmVu dGx5IHBvc3RlZCBhcyAmcXVvdDtSZXBvcnRlZCZxdW90Oy4gSWYgbmVjZXNzYXJ5LCBwbGVhc2U8 YnI+DQomZ3Q7IHVzZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvcjxicj4NCiZndDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lv biBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5Jm5ic3A7IDxicj4NCiZndDsgY2FuIGxv ZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3Nh cnkuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsgUkZDNzk1MCAoZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJpcy0x NCk8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K Jmd0OyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IFRoZSBZQU5HIDEuMSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlPGJyPg0KJmd0OyBQ dWJsaWNhdGlvbiBEYXRlJm5ic3A7ICZuYnNwOyA6IEF1Z3VzdCAyMDE2PGJyPg0KJmd0OyBBdXRo b3IocykmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogTS4gQmpvcmts dW5kLCBFZC48YnI+DQomZ3Q7IENhdGVnb3J5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgOiBQUk9QT1NFRCBTVEFOREFSRDxicj4NCiZndDsgU291cmNlJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogTmV0d29yayBNb2RlbGlu Zzxicj4NCiZndDsgQXJlYSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50PGJyPg0KJmd0OyBTdHJl YW0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBJRVRG PGJyPg0KJmd0OyBWZXJpZnlpbmcgUGFydHkmbmJzcDsgJm5ic3A7ICZuYnNwOzogSUVTRzxicj4N CiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR0701MB29053FE1EC7A4F199C688050EA7E0HE1PR0701MB2905_-- From nobody Wed Feb 27 08:37:11 2019 Return-Path: <010001692fd110d5-8bc88365-4d0f-4595-9337-1a2b1ce2d6cd-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 7FA18130EE1 for ; Wed, 27 Feb 2019 08:37:08 -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, 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 9u-IeCjYVTPy for ; Wed, 27 Feb 2019 08:37:05 -0800 (PST) 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 97749130EA7 for ; Wed, 27 Feb 2019 08:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551285424; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2a9ilnWMMVqmOYCUU528pjiVrLqEkA//wCQc+zuj2xk=; b=TKZ14MZnCzGB+/PMNiVReGCX0MCfo58ZiBp9RYFigcsgYfHs2d3DnssV+kHzM73s 9bNT0xlWUdVKxWnWAy4c3nUWJQdxgbG4oPM4CN3TWCnm/DaOcS6sev6/ikTY35FeDHg RZ+5EfQYPiWLo/w99rg0OBE6g9Evl63LEQkzjVCQ= From: Kent Watsen Message-ID: <010001692fd110d5-8bc88365-4d0f-4595-9337-1a2b1ce2d6cd-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EB2724F4-B4D9-4442-9405-6989C31296FC" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 27 Feb 2019 16:37:04 +0000 In-Reply-To: Cc: Andy Bierman , Martin Bjorklund , Ignas Bagdonas , Warren Kumari , NetMod WG , RFC Editor To: Peter Loborg References: <20190221163919.5196EB81AF4@rfc-editor.org> <20190221.175336.1995849216024607593.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.27-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) 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 Feb 2019 16:37:09 -0000 --Apple-Mail=_EB2724F4-B4D9-4442-9405-6989C31296FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Note: I just released this this email. =20 Peter sent it on the 22nd, but it was trapped by Mailman: =20 Post by non-member to a members-only list Kent // co-chair > On Feb 21, 2019, at 1:06 PM, Peter Loborg = wrote: >=20 > =20 > Your example is fine =E2=80=93 but the gammar is ch14 specifies = something different: > =20 > enum-stmt =3D enum-keyword sep string optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > *if-feature-stmt > [value-stmt] > [status-stmt] > [description-stmt] > [reference-stmt] > "}") stmtsep > =20 > It clearly states string, not quoted-string. These two have the = following rules: > =20 > quoted-string =3D (DQUOTE string DQUOTE) / (SQUOTE string = SQUOTE) > =20 > string =3D < an unquoted string, as returned by > > < the scanner, that matches the rule > > < yang-string > > =20 > =E2=80=A6and in 6.1.3 we can read that: > An unquoted string is any sequence of characters that does not > contain any space, tab, carriage return, or line feed characters, a > single or double quote character, a semicolon (";"), braces ("{" or > "}"), or comment sequences ("//", "/*", or "*/"). > =20 > Note that any keyword can legally appear as an unquoted string. > =20 > Since the section so clearly writes about single quoted strings and = double quoted strings, there can unfortunately be no interpretation that = would allow =E2=80=9Cidentifier=E2=80=9D to be called an unquoted string = =E2=80=93 even though it follows the rules about limited character = contents. > =20 > Hence =E2=80=93 this is not a matter of opinion =E2=80=93 it=E2=80=99s = a matter of reading what=E2=80=99s actually written in the RFC. > =20 > But on the subject of opinion=E2=80=A6 > =20 > enum "This is also legal"; // should definitely always be = illegal > =20 > =E2=80=A6as we cannot create a language binding to enum constructs in = any major programming languages. > =20 > Br, > Peter > =20 > =20 > From: Andy Bierman >=20 > Sent: den 21 februari 2019 18:45 > To: Martin Bjorklund > > Cc: RFC Editor >; Ignas Bagdonas >; NetMod WG >; Peter Loborg >; Warren Kumari > > Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) > =20 > =20 > =20 > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund > wrote: > RFC Errata System > wrote: > > The following errata report has been submitted for RFC7950, > > "The YANG 1.1 Data Modeling Language". > >=20 > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5642 = > >=20 > > -------------------------------------- > > Type: Editorial > > Reported by: Peter Loborg > > >=20 > > Section: 9.6.4 > >=20 > > Original Text > > ------------- > > It takes as an argument a string that is the assigned name.=20 > >=20 > > Corrected Text > > -------------- > > It takes as an argument an unquoted string that is the assigned = name. >=20 > This is not correct. The enum argument is not different from any > other keyword's arguments in YANG. See e.g. the example in 9.12.4: >=20 > type enumeration { > enum "unbounded"; > } >=20 > The following is also legal: >=20 > enum "unb" + 'ounded'; >=20 >=20 > =20 > =20 > enum "This is also legal"; > =20 > 9.6.4. The "enum" Statement > =20 > The "enum" statement, which is a substatement to the "type" > statement, MUST be present if the type is "enumeration". It is > repeatedly used to specify each assigned name of an enumeration = type. > It takes as an argument a string that is the assigned name. The > string MUST NOT be zero-length and MUST NOT have any leading or > trailing whitespace characters (any Unicode character with the > "White_Space" property). The use of Unicode control codes SHOULD = be > avoided. > =20 > =20 > This errata should be rejected. >=20 >=20 >=20 > /martin >=20 > =20 > =20 > Andy > =20 >=20 > >=20 > > Notes > > ----- > > Readers are not beeing made aware that careful reading of section = 6.1.3 and the detailed definition of string in section 14 must be = consulted. > > For comming versions of this RFC it would be preferable to use a = more specialized grammar token for these cases (e.g. unquoted-string). > >=20 > > 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 =20 > > can log in to change the status and edit the report, if necessary.=20= > >=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 > >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = ____________________________= ___________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_EB2724F4-B4D9-4442-9405-6989C31296FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Note:= I just released this this email.  

Peter sent it on the 22nd, but it was = trapped by Mailman:  

= Post by non-member to a members-only list

Kent // = co-chair



On Feb 21, 2019, at 1:06 PM, Peter Loborg <peter.loborg@ericsson.com> wrote:

 
Your example is fine =E2=80=93 = but the gammar is ch14 specifies something different:
 
enum-stmt         =   =3D enum-keyword sep string optsep
          &nb= sp;            = ;  (";" /
          &nb= sp;            = ;   "{" stmtsep
          &nb= sp;            = ;       ;; these stmts can appear in any = order
          &nb= sp;            = ;       *if-feature-stmt
          &nb= sp;            = ;       [value-stmt]
          &nb= sp;            = ;       [status-stmt]
          &nb= sp;            = ;       [description-stmt]
          &nb= sp;            = ;       [reference-stmt]
  =             &n= bsp;           &nbs= p;"}") stmtsep
 
It clearly states  = string, not quoted-string. These two have the following rules:
 
quoted-string       =3D (DQUOTE = string DQUOTE) / (SQUOTE string SQUOTE)
 
string         &nb= sp;    =3D < an unquoted string, as returned by = >
  =             &n= bsp;          < the = scanner, that matches the rule >
          &nb= sp;            = ;  < yang-string >
 
=E2=80=A6and in 6.1.3 we can = read that:
   An unquoted string is = any sequence of characters that does not
   contain any space, tab, carriage = return, or line feed characters, a
   = single or double quote character, a semicolon (";"), braces ("{" or
   "}"), or comment sequences ("//", = "/*", or "*/").
 
   Note that any keyword = can legally appear as an unquoted string.
 
Since = the section so clearly writes about single quoted strings and double = quoted strings, there can unfortunately be no interpretation that would = allow =E2=80=9Cidentifier=E2=80=9D to be called an unquoted string =E2=80=93= even though it follows the rules about limited character contents.
 
Hence = =E2=80=93 this is not a matter of opinion =E2=80=93 it=E2=80=99s a = matter of reading what=E2=80=99s actually written in the RFC.
 
But on = the subject of opinion=E2=80=A6
 
      enum = "This is also legal";   // should definitely always be = illegal
 
=E2=80=A6as we cannot create = a language binding to enum constructs in any major programming = languages.
 
Br,
Peter
 
 
From: Andy Bierman <andy@yumaworks.com> 
Sent: den= 21 februari 2019 18:45
To: Martin Bjorklund <mbj@tail-f.com>
Cc: RFC = Editor <rfc-editor@rfc-editor.org>; Ignas Bagdonas <ibagdona@gmail.com>; = NetMod WG <netmod@ietf.org>; Peter = Loborg <peter.loborg@ericsson.com>; Warren Kumari <warren@kumari.net>
Subject: Re: [netmod] [Editorial = Errata Reported] RFC7950 (5642)
 
 
 
On Thu, = Feb 21, 2019 at 8:53 AM Martin Bjorklund <mbj@tail-f.com> = wrote:

RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 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/eid5642
> 
> = --------------------------------------
> Type: = Editorial
> Reported by: Peter Loborg <peter.loborg@ericsson.com>
> 
> = Section: 9.6.4
> 
> = Original Text
> -------------
> It = takes as an argument a string that is the assigned name. 
> 
> = Corrected Text
> --------------
> It = takes as an argument an unquoted string that is the assigned name.

This is not correct.  The enum argument = is not different from any
other keyword's arguments in = YANG.  See e.g. the example in 9.12.4:

       type enumeration {
         enum "unbounded";
       }

The = following is also legal:

    =      enum "unb" + 'ounded';

 
 
  enum "This is also legal";
 
9.6.4.  The "enum" =
Statement
 
   The =
"enum" statement, which is a substatement to the "type"
   statement, MUST be =
present if the type is "enumeration".  It is
   repeatedly used to =
specify each assigned name of an enumeration type.
   It takes as an =
argument a string that is the assigned name.  The
   string MUST NOT be zero-length and MUST NOT have =
any leading or
   trailing whitespace characters (any Unicode character with =
the
   =
"White_Space" property).  The use of Unicode control codes SHOULD =
be
   =
avoided.
 
 

This errata should be rejected.



/martin

 
 
Andy
 

> 
> = Notes
> -----
> Readers are not beeing = made aware that careful reading of section 6.1.3 and the detailed = definition of string in section 14 must be consulted.
> = For comming versions of this RFC it would be preferable to use a more = specialized grammar token for these cases (e.g. unquoted-string).
> 
> 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
> 

_______________________________________________
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=_EB2724F4-B4D9-4442-9405-6989C31296FC-- From nobody Wed Feb 27 08:48: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 A002E130EA7 for ; Wed, 27 Feb 2019 08:48:23 -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 A1iFaTQ66lxn for ; Wed, 27 Feb 2019 08:48:21 -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 71C74130EE5 for ; Wed, 27 Feb 2019 08:48:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 293617B7; Wed, 27 Feb 2019 17:48:18 +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 LheQjPBYZACQ; Wed, 27 Feb 2019 17:48:18 +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; Wed, 27 Feb 2019 17:48:18 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1271B20067; Wed, 27 Feb 2019 17:48:18 +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 z9W06yfXVjef; Wed, 27 Feb 2019 17:48:17 +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 B4EBF20064; Wed, 27 Feb 2019 17:48:17 +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; Wed, 27 Feb 2019 17:48:17 +0100 Received: by anna.localdomain (Postfix, from userid 501) id EBFCE3006D411F; Wed, 27 Feb 2019 17:48:16 +0100 (CET) Date: Wed, 27 Feb 2019 17:48:16 +0100 From: Juergen Schoenwaelder To: Kent Watsen CC: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" Message-ID: <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-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) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 16:48:23 -0000 On Wed, Feb 27, 2019 at 04:09:17PM +0000, Kent Watsen wrote: >=20 >=20 > > On Feb 27, 2019, at 6:16 AM, Bal=E1zs Lengyel wrote: > >=20 > > feature oldFeature { > > status obsolete; > > } > > leaf myTimer { > > if-feature oldFeature ; > > mandatory true; > > config true; > > status current; > > type string; > > } > > So should I configure myTimer or not? I assume yes, correct? >=20 > This issue is captured here: https://github.com/netmod-wg/yang-next/iss= ues/27, which was updated as of this morning with this very example. >=20 > Of course, the problem is in RFC 7950: >=20 > o "obsolete" means that the definition is obsolete and SHOULD NOT b= e > implemented and/or can be removed from implementations. >=20 > I recommend replacing "SHOULD NOT be implemented" with "is not implemen= ted". When an IETF WG decides to obsolete something, I am forced to break old clients because of this decision? Note sure this makes business sense (says an academic). There is a huge difference between modules where the implementors have change control over the modules and modules where change control is far outside the implementors hands and where clients and servers are implemented by different organizations in an open and largely uncoordinated way. We always have to keep this in mind when we create rules. The SHOULD NOT allows a server implementor to take a well-informed decision that there are old clients you care about and that this makes a business case for supporting obsolete definitions on a server. Another aspect here is that we do not make a clear distinction between server and client. It can very well be that "deprecated" and "obsolete" mean slightly different things to servers and clients. (Servers tend to have a natural desire to not break clients unnecessarily.) /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 Wed Feb 27 09:27: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 90066130FE9 for ; Wed, 27 Feb 2019 09:27:21 -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 ld_SD2AX8cW6 for ; Wed, 27 Feb 2019 09:27:18 -0800 (PST) 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 3231D130EE1 for ; Wed, 27 Feb 2019 09:27:18 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id v10so14700417lji.3 for ; Wed, 27 Feb 2019 09:27: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; bh=xeV32hxqfl81KDiAWY19kYaql7UciLxRXbZ6ozjRyac=; b=rF04fFpKRV3DMr1NkCMgOpIcbjpwomZ8mbdIYA/O4s1C4H5/HQ8TU2yZw6q3X1aytV 4z2yhQF6xxoTDXlMwazhCjTeqi4gjqz4cxznrooEL/5prUKGHkfWdvlT8pqESHFshYi+ MA5kwXFB+mIgeDWNH3Tdpau3JGJZ5Fd2D00/XLhYKRLiIcQxYjHsJGrRkTE2J+Zs2xVl YpP8a0ttc8CtWwDrBGH8+GjBDuv8A/EaaYMlMtHXtKmDZcUa8ov+MaE7cW2sZqZjIaCR 2lfi2kbMgoD74Shuj8ZQoRIxb1TW6117yzbtdSBjLoszj31GEyzv4Ww7S29VucfmFkTH XnVQ== 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=xeV32hxqfl81KDiAWY19kYaql7UciLxRXbZ6ozjRyac=; b=O6fLNTkVyv28ziI0wEpuBk9jSMuwwyUHT48GH0tOcZKx/e6TXctUueqMwBBie3HTqt tsQhlqh3n0aum97h+w+5xdOu1R2qZXJSxOQ8uOVhEY2tArRM4ByKUGRtIccbPOpFssJb JB7G4z9YbFdPMyauLKTyMxXAOP4hY3zFGx1UtJaaF16GaAWubFLpwFUKZ2XzwAwa1n5B f8x4Gvhrll5Mw+pqgVfKHj4SDvjp76WxReeHOzMoVj/EBVSNOv7AgGJ3yITwMwr0srsc jqptPZipAlg0zn+mmFhPl/7qlRKFjD71NOsv3In1Lz50EZELa5qdE9Cro6bRkS2xYSm7 7Crg== X-Gm-Message-State: APjAAAWkGw0yCoLVL8fi4pOr+lOk04Cn/Y0d5ucQ7yfOC1J/h8FUKYBI AQrPzPwN/NZsX51KpDVuAxC/ZO+rwi/W2vk2tC5p+A== X-Google-Smtp-Source: AHgI3IZ80wB7A6GweU9X2jRJjaZsqNr4MOhXAeK9QXgPcgbxFMhIs+2/RKTEKQQIXcvquLqd5vgU4x2HFFqrLkqUWPE= X-Received: by 2002:a2e:20b:: with SMTP id 11mr2168579ljc.41.1551288435926; Wed, 27 Feb 2019 09:27:15 -0800 (PST) MIME-Version: 1.0 References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> In-Reply-To: <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Wed, 27 Feb 2019 09:27:04 -0800 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b070b0582e37c9a" Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 17:27:22 -0000 --0000000000002b070b0582e37c9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2019 at 8:48 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Feb 27, 2019 at 04:09:17PM +0000, Kent Watsen wrote: > > > > > > > On Feb 27, 2019, at 6:16 AM, Bal=C3=A1zs Lengyel < > balazs.lengyel@ericsson.com> wrote: > > > > > > feature oldFeature { > > > status obsolete; > > > } > > > leaf myTimer { > > > if-feature oldFeature ; > > > mandatory true; > > > config true; > > > status current; > > > type string; > > > } > > > So should I configure myTimer or not? I assume yes, correct? > > > > This issue is captured here: > https://github.com/netmod-wg/yang-next/issues/27, which was updated as of > this morning with this very example. > > > > Of course, the problem is in RFC 7950: > > > > o "obsolete" means that the definition is obsolete and SHOULD NOT b= e > > implemented and/or can be removed from implementations. > > > > I recommend replacing "SHOULD NOT be implemented" with "is not > implemented". > > When an IETF WG decides to obsolete something, I am forced to break > old clients because of this decision? Note sure this makes business > sense (says an academic). > > There is a huge difference between modules where the implementors have > change control over the modules and modules where change control is > far outside the implementors hands and where clients and servers are > implemented by different organizations in an open and largely > uncoordinated way. We always have to keep this in mind when we create > rules. > > There is a huge difference between conformance and server capabilities. The status-stmt is about conformance -- the expected usage for any implementation of the particular statement. Whether a server actually implements something that is deprecated or obsolete is a completely different issue. (It is also another issue that YANG got the deprecated status completely wrong) Andy > The SHOULD NOT allows a server implementor to take a well-informed > decision that there are old clients you care about and that this makes > a business case for supporting obsolete definitions on a server. > > Another aspect here is that we do not make a clear distinction between > server and client. It can very well be that "deprecated" and > "obsolete" mean slightly different things to servers and > clients. (Servers tend to have a natural desire to not break clients > unnecessarily.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000002b070b0582e37c9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 27, 2019 at 8:48 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Feb 27, 2019 at 04:09:17PM +0= 000, Kent Watsen wrote:
>
>
> > On Feb 27, 2019, at 6:16 AM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsso= n.com> wrote:
> >
> > feature oldFeature {
> >=C2=A0 =C2=A0status obsolete;
> > }
> > leaf myTimer {
> >=C2=A0 =C2=A0if-feature oldFeature ;
> >=C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0config true;
> >=C2=A0 =C2=A0status current;
> >=C2=A0 =C2=A0type string;
> > }
> > So should I configure myTimer or not? I assume yes, correct?
>
> This issue is captured here: https://github.com= /netmod-wg/yang-next/issues/27, which was updated as of this morning wi= th this very example.
>
> Of course, the problem is in RFC 7950:
>
>=C2=A0 =C2=A0 o=C2=A0 "obsolete" means that the definition is= obsolete and SHOULD NOT be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented and/or can be removed from imple= mentations.
>
> I recommend replacing "SHOULD NOT be implemented" with "= ;is not implemented".

When an IETF WG decides to obsolete something, I am forced to break
old clients because of this decision? Note sure this makes business
sense (says an academic).

There is a huge difference between modules where the implementors have
change control over the modules and modules where change control is
far outside the implementors hands and where clients and servers are
implemented by different organizations in an open and largely
uncoordinated way. We always have to keep this in mind when we create
rules.



There is a huge differe= nce between conformance and server capabilities.
The status-stmt = is about conformance -- the expected usage for any implementation
of the particular statement.

Whether a server act= ually implements something that is deprecated or obsolete
is a co= mpletely different issue.

(It is also another issu= e that YANG got the deprecated status completely wrong)

Andy
=C2=A0
The SHOULD NOT allows a server implementor to take a well-informed
decision that there are old clients you care about and that this makes
a business case for supporting obsolete definitions on a server.

Another aspect here is that we do not make a clear distinction between
server and client. It can very well be that "deprecated" and
"obsolete" mean slightly different things to servers and
clients. (Servers tend to have a natural desire to not break clients
unnecessarily.)

/js

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

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000002b070b0582e37c9a-- From nobody Wed Feb 27 10:15: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 4C3B513107E for ; Wed, 27 Feb 2019 10:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 zD74JMBnV4Sd for ; Wed, 27 Feb 2019 10:15:11 -0800 (PST) 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 17648131050 for ; Wed, 27 Feb 2019 10:15:11 -0800 (PST) Received: from [192.168.0.103] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x1RIF759097351; Wed, 27 Feb 2019 18:15:08 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.103] Content-Type: multipart/alternative; boundary=Apple-Mail-4A1CC6AB-254D-4AF0-8330-98881E31B1AE Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (16D57) In-Reply-To: <010001692fcb71bc-c5fbb484-a99a-4d1d-84c0-80447b5dead3-000000@email.amazonses.com> Date: Wed, 27 Feb 2019 10:15:00 -0800 Cc: "Rob Wilton (rwilton)" , "adrian@olddog.co.uk" , "netmod@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <70FC384C-1DC2-451F-B978-4D8189522841@bogus.com> References: <0100016926bfd7ac-333fc4ef-98a8-4dc4-98a2-1b3414b35e24-000000@email.amazonses.com> <04b001d4ce22$5bd78d50$1386a7f0$@olddog.co.uk> <6E24D34F-9943-4A71-9F28-4E4548FF30B0@bogus.com> <057f01d4ce80$7bc4fc70$734ef550$@olddog.co.uk> <3af58c925ad74fbfaaea299877bf992d@XCH-RCD-007.cisco.com> <010001692fcb71bc-c5fbb484-a99a-4d1d-84c0-80447b5dead3-000000@email.amazonses.com> To: Kent Watsen 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: Wed, 27 Feb 2019 18:15:15 -0000 --Apple-Mail-4A1CC6AB-254D-4AF0-8330-98881E31B1AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Feb 27, 2019, at 08:30, Kent Watsen wrote: >=20 > I'm hoping to optimize for this common case scenario. >=20 > I do not agree that having having two folding approaches is an issue. I w= ould like to see this=20 > BCP have the broadest appeal possible. It comes up due to the rigor required to preserve white space. In that sense= it is very closely related to interpretation of tabs or the requirement to a= void them entirely. IMHO we should be rigorous about the preservation of whi= tes space in folded artwork so my preference should reflect that. I=E2=80=99= m not convinced that if one rigorous that the second slash is required. >=20 > Kent // contributor >=20 >=20 >> On Feb 27, 2019, at 5:09 AM, Rob Wilton (rwilton) wro= te: >>=20 >> Hi Adrian, >> =20 >> I mostly agree with your last sentence. >> =20 >> I think that if you always preserve whitespace then a single slash is fin= e. I.e. the single slash just breaks the line, and I think that this matche= s how editors, programming languages, etc normally behave. >> =20 >> What I=E2=80=99m not keen on is using a single slash, and then automatica= lly stripping leading whitespace on the line following a slash. >> =20 >> If we want to have control of layout and be able to strip extra whitespac= e then my argument is that it is better to be explicit, and using two slashe= s is one way of achieving this. >> =20 >> Thanks, >> Rob >> =20 >> =20 >> =20 >> 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? >> =20 >> Complete agreement, Joel. >> =20 >> What follows may look better in proportional fonts. >> =20 >> With a single slash we can wrap as follows >> =20 >> 1234567 9012345 >> =20 >> Goes to=E2=80=A6 >> =20 >> 1234567 \ >> 9012345 >> =20 >> =E2=80=A6and unwrapping is easy. >> =20 >> However, if I want to manually wrap the line with indentation >> =20 >> The quick brown fox jumps over the lazy dog >> =20 >> ..going to=E2=80=A6 >> =20 >> The quick brown fox\ >> jumps over the lazy dog >> =20 >> =E2=80=A6I am going to unfold as=E2=80=A6 >> =20 >> The quick brown fox jumps over the lazy dog >> =20 >> =20 >> Conversely, if I resolve this second case by stripping leading spaces I g= et=E2=80=A6 >> =20 >> The quick brown foxjumps over the lazy dog >> =20 >> So I have to fold as=E2=80=A6 >> =20 >> The quick brown fox \ >> jumps over the lazy dog >> =20 >> But this causes the first case to unfold as >> =20 >> 1234567 9012345 >> =20 >> =E2=80=A6i.e., with missing spaces. >> =20 >> This is what caused the use of the second slash so=E2=80=A6 >> =20 >> 1234567 \ >> \ 9012345 >> =20 >> =E2=80=A6and=E2=80=A6 >> =20 >> The quick brown fox\ >> \ jumps over the lazy dog >> =20 >> =20 >> So, my point is, if and only if we do not care about these =E2=80=9Cspace= s on the fold=E2=80=9D cases, we can operate with a single slash. >> =20 >> Cheers, >> Adrian >> =20 >> From: Joel Jaeggli =20 >> Sent: 27 February 2019 06:31 >> To: Adrian Farrel >> Cc: Kent Watsen ; netmod@ietf.org >> Subject: Re: [netmod] artwork folding: dual support modes? >> =20 >> =20 >> =20 >>=20 >> On Feb 26, 2019, at 14:26, Adrian Farrel wrote: >> =20 >> Hey. >> =20 >> I=E2=80=99ve been having this discussion with Kent off-line, but thought i= t should come to the list. >> =20 >> I don=E2=80=99t think it is a good idea to have two approaches. While it w= ould be relatively easy to code for both approaches, it seems to add a degre= e of confusion if both have to be handled by the same code (consider decidin= g 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 hav= ing different code for the two different cases. >> =20 >> It doesn=E2=80=99t seem to me that both cases are needed. We can pick one= or the other. >> =20 >> A single slash has been used to wrap long lines in editors and shells for= decades at this point. >> =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 to m= ake the document more human-readable then we have to use a leading =E2=80=98= \=E2=80=99 on continuation lines to show which spaces should be stripped and= which retained. >> =20 >> Cheers, >> Adrian >> =20 >> From: netmod On Behalf Of Kent Watsen >> Sent: 25 February 2019 22:22 >> To: netmod@ietf.org >> Subject: [netmod] artwork folding: dual support modes? >> =20 >> =20 >> I had a chat with the tools team recently and, in the course of things, i= t was implied >> that the double backslash approach we have now was both surprising and no= n-intuitive.=20 >> =20 >> 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: >> =20 >> NOTE: '\\' line wrapping per BCP XX (RFC XXXX) >> =20 >> So why not *also* support a header that reads (note the singe slash): >> =20 >> NOTE: '\' line wrapping per BCP XX (RFC XXXX) >> =20 >> Whereby this second form only supports the folded line continuing on colu= mn 1 (no indents). >> =20 >> Thoughts? >> =20 >> Kent // contributor >> =20 >> =20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> =20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail-4A1CC6AB-254D-4AF0-8330-98881E31B1AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent from my iPhone

On Feb 27, 2019, at 08:3= 0, Kent Watsen <kent@watsen.net>= ; wrote:
I'm hoping to optimize for this common cas= e scenario.

I do n= ot agree that having having two folding approaches is an issue.   I wou= ld like to see this 
BCP have the broadest appeal p= ossible.

It comes up due to the rigor= required to preserve white space. In that sense it is very closely related t= o interpretation of tabs or the requirement to avoid them entirely. IMHO we s= hould be rigorous about the preservation of whites space in folded artwork s= o my preference should reflect that. I=E2=80=99m not convinced that if one r= igorous that the second slash is required.


Kent /= / contributor


=
On Feb 27, 2019, at 5:0= 9 AM, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Adrian,
 
I mostly agree with your last sentence.
 
I= think that if you always preserve whitespace then a single slash is fine.&n= bsp; I.e. the single slash just breaks the line, and I think that this match= es how editors, programming languages, etc normally behave.<= /o:p>
 
What I=E2=80= =99m not keen on is using a single slash, and then automatically stripping l= eading whitespace on the line following a slash.
 
If we want to have con= trol of layout and be able to strip extra whitespace then my argument is tha= t it is better to be explicit, and using two slashes is one way of achieving= this.
 
Thanks,
Rob
<= o:p class=3D""> 
 
 
From: netmod <netmod-bounces@ietf.org>=  On Behalf O= f Adrian Farrel
Sent: <= /span>27 February 2019 09:41
To: 'Joel Jaeggli' <joelja@bogus.com>
Cc: netmod@ietf.org<= /a>
Subject: Re: [netmod] artwork folding: dual support modes?
 
Complete agreement, Joel.
 
<= div style=3D"margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Ca= libri, sans-serif;" class=3D"">What follows may look better= in proportional fonts.
 
With a single slash we can wrap= as follows
 
1234567      &= nbsp; 9012345
 
Goes to=E2=80=A6
&n= bsp;
1234= 567    \
    9012345
 
=E2=80=A6and unwrapping is easy.
 <= /div>
However, if I want to m= anually wrap the line with indentation
 
The quick brown f= ox jumps over the lazy dog
 
<= div style=3D"margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Ca= libri, sans-serif;" class=3D"">..going to=E2=80=A6
<= o:p class=3D""> 
The quick brown fox\
      jumps= over the lazy dog
=E2=80=A6I am going to unfold as=E2=80= =A6
 
 
Conversely, if I re= solve this second case by stripping leading spaces I get=E2=80=A6
 
The quick brown foxjumps over the lazy dog
&n= bsp;
So I= have to fold as=E2=80=A6
 
The quick brown fox \
=       jumps over the lazy dog=
 
= But this causes the first case to unfold as
 
1234567&nbs= p;   9012345
 
=E2=80=A6i.e., with missing space= s.
 
This is what caused the use of the second slash so=E2=80= =A6
 
1234567    \
\  &nbs= p; 9012345
 
=E2=80=A6and=E2=80=A6<= /span>
 
T= he quick brown fox\
     \ jumps over the lazy dog=
 
 
So, my point is, if and only if we do not c= are about these =E2=80=9Cspaces on the fold=E2=80=9D cases, we can operate w= ith a single slash.
 
Cheers,=
Adrian
 
From: Joel Jaeggli &l= t;joelja@bogu= s.com> 
Sent: 27 February 2019 06:31
To: Adr= ian Farrel <adrian@olddog.co.uk>
Cc: Kent Watsen <kent+ietf@watsen.net>= ;; netmod@ietf.org
Subject: Re: [netmod] artwork folding: dual suppor= t modes?
 
=  

 

On Feb 26, 2019, at 14:26, Adrian Farrel <adrian@olddog.co.uk> wrote:
 
=
Hey.
 
I=E2=80=99= ve been having this discussion with Kent off-line, but thought it should com= e to the list.
 
<= div style=3D"margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Ca= libri, sans-serif;" class=3D"">I don=E2=80=99t think it is a good idea to ha= ve two approaches. While it would be relatively easy to code for both approa= ches, it seems to add a degree of confusion if both have to be handled by th= e same code (consider deciding whether leading space characters are to be re= tained or not, something that can only be decided when the first non-space c= haracter is found), or by having different code for the two different cases.=
 
It doesn=E2=80=99t seem to me that both cases are needed. We c= an pick one or the other.
 
A single slash= has been used to wrap long lines in editors and shells for decades at this p= oint.
 
and yeah whatever it is one method seems better than t= wo.

 

 
And *if* we want to allow manual foldin= g so that indents can be made to make the document more human-readable then w= e have to use a leading =E2=80=98\=E2=80=99 on continuation lines to show wh= ich spaces should be stripped and which retained.
 
Cheers,
Adrian
 
= From: netmod <netmod-bo= unces@ietf.org> On Behalf Of Kent Watsen
Sent: 25 February 2= 019 22:22
To: netmod@ietf.org
Subject: [netmod] artwork folding: dual support modes?
&n= bsp;
 
I had a chat wit= h the tools team recently and, in the course of things, it was implied
that the double backslash approach we have now was bot= h surprising and non-intuitive. 
 
This got me thinking that we may have thrown the prove= rbial baby out with the bathwater.
That is, curre= ntly 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):<= /o:p>
 
  NOTE: '\' l= ine wrapping per BCP XX (RFC XXXX)
 
Whereby this second form only supports the folded line continu= ing on column 1 (no indents).
 
Thoughts?
 
Kent // contributor
 
 
_______________________________________________
netmod mailing list
netmod= @ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 
_______________________________= ________________
netmod mailing lis= t
netmod@ietf.org
https://www.ietf.org/ma= ilman/listinfo/netmod
= --Apple-Mail-4A1CC6AB-254D-4AF0-8330-98881E31B1AE-- From nobody Wed Feb 27 10:17:16 2019 Return-Path: <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-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 BFDE013108E for ; Wed, 27 Feb 2019 10:17:13 -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 a2zJNifW9nxB for ; Wed, 27 Feb 2019 10:17:11 -0800 (PST) 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 383B313109B for ; Wed, 27 Feb 2019 10:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551291429; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=WvCih2vQVVUmjSXitFztRrg7oKL+9llq3So9jqHaJiI=; b=hGamVEgCgzbtlbGDuxr3p5qIL9gTywQ+BrNnpVHboEVBtYeBAG7wVHpIenvGSIwm G/Hu2+vfoApYyPYwVifyC7RH9lp5h711zwmuffjzSd59DbzuMhTQteeOY8ntuiYNLyL 04WhHpYc8BhfBqPk12szzhbPWIVg3+JTMoUGamJc= From: Kent Watsen Message-ID: <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C299E246-400A-4B0A-AD16-870EDBCFE5D4" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 27 Feb 2019 18:17:09 +0000 In-Reply-To: <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> Cc: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" To: Juergen Schoenwaelder References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.27-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 18:17:14 -0000 --Apple-Mail=_C299E246-400A-4B0A-AD16-870EDBCFE5D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 27, 2019, at 11:48 AM, Juergen Schoenwaelder = wrote: >=20 > On Wed, Feb 27, 2019 at 04:09:17PM +0000, Kent Watsen wrote: >>=20 >>=20 >>> On Feb 27, 2019, at 6:16 AM, Bal=C3=A1zs Lengyel = wrote: >>>=20 >>> feature oldFeature { >>> status obsolete; >>> } >>> leaf myTimer { >>> if-feature oldFeature ; >>> mandatory true; >>> config true; >>> status current; >>> type string; >>> } >>> So should I configure myTimer or not? I assume yes, correct? >>=20 >> This issue is captured here: = https://github.com/netmod-wg/yang-next/issues/27, which was updated as = of this morning with this very example. >>=20 >> Of course, the problem is in RFC 7950: >>=20 >> o "obsolete" means that the definition is obsolete and SHOULD NOT = be >> implemented and/or can be removed from implementations. >>=20 >> I recommend replacing "SHOULD NOT be implemented" with "is not = implemented". >=20 > When an IETF WG decides to obsolete something, I am forced to break > old clients because of this decision? Note sure this makes business > sense (says an academic). >=20 > There is a huge difference between modules where the implementors have > change control over the modules and modules where change control is > far outside the implementors hands and where clients and servers are > implemented by different organizations in an open and largely > uncoordinated way. We always have to keep this in mind when we create > rules. >=20 > The SHOULD NOT allows a server implementor to take a well-informed > decision that there are old clients you care about and that this makes > a business case for supporting obsolete definitions on a server. >=20 > Another aspect here is that we do not make a clear distinction between > server and client. It can very well be that "deprecated" and > "obsolete" mean slightly different things to servers and > clients. (Servers tend to have a natural desire to not break clients > unnecessarily.) But a server can choose to not implement that revision of the module or, = with https://github.com/netmod-wg/yang-next/issues/63 = deviate the "status" = statement. I want "obsolete" to mean as it does everywhere else: out of use, no = longer supported, not expected to work, etc. Perhaps there is a line between having "status obsolete" versus = disappearing the node altogether? Maybe within the same "major" = version (to use a sem-ver term), "obsolete" leaves it to the server's = discretion, whereas the next major version disappears the node? If so, then there should be a way for the server to indicate which = discretionary choices it made. I'd suggest that "obsolete" defaults to = "not-implemented" and thus only servers that want to continue support = for the node need to indicate anything. A deviation would be a good fit = for this. Kent // contributor --Apple-Mail=_C299E246-400A-4B0A-AD16-870EDBCFE5D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Feb 27, 2019, at 11:48 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On = Wed, Feb 27, 2019 at 04:09:17PM +0000, Kent Watsen wrote:


On Feb 27, 2019, at 6:16 = AM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

feature oldFeature {
 status obsolete;
}
leaf myTimer {
=  if-feature oldFeature ;
 mandatory true;
 config true;
 status current;
 type string;
}
So should I = configure myTimer or not? I assume yes, correct?

This issue is captured here: https://github.com/netmod-wg/yang-next/issues/27, which = was updated as of this morning with this very example.

Of course, the problem is in RFC 7950:

  o  "obsolete" means that the definition is = obsolete and SHOULD NOT be
=      implemented and/or can be removed from = implementations.

I recommend replacing = "SHOULD NOT be implemented" with "is not implemented".

When an IETF WG decides to = obsolete something, I am forced to break
old clients = because of this decision? Note sure this makes business
sense (says an academic).

There = is a huge difference between modules where the implementors have
change control over the modules and modules where change = control is
far outside the implementors hands and where = clients and servers are
implemented by different = organizations in an open and largely
uncoordinated way. We = always have to keep this in mind when we create
rules.

The SHOULD NOT allows a server implementor to = take a well-informed
decision that there are old clients = you care about and that this makes
a business case for = supporting obsolete definitions on a server.

Another aspect here is that we do not make a clear = distinction between
server and client. It can very well be = that "deprecated" and
"obsolete" mean slightly different = things to servers and
clients. (Servers tend to have a = natural desire to not break clients
unnecessarily.)



But a server can choose to not implement that revision of the = module or, with https://github.com/netmod-wg/yang-next/issues/63 devia= te the "status" statement.

I want "obsolete" to mean as it does everywhere else: out of = use, no longer supported, not expected to work, etc.

Perhaps there is a line = between having "status obsolete" versus disappearing the node = altogether?   Maybe within the same "major" version (to use a = sem-ver term), "obsolete" leaves it to the server's discretion, whereas = the next major version disappears the node?

If so, then there should be a way for = the server to indicate which discretionary choices it made.   I'd = suggest that "obsolete" defaults to "not-implemented" and thus only = servers that want to continue support for the node need to indicate = anything.  A deviation would be a good fit for this.

Kent // = contributor




= --Apple-Mail=_C299E246-400A-4B0A-AD16-870EDBCFE5D4-- From nobody Wed Feb 27 10:42: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 AE19B1310AF for ; Wed, 27 Feb 2019 10:42:09 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wYtrfFzgCVQO for ; Wed, 27 Feb 2019 10:42:08 -0800 (PST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676BD1310AB for ; Wed, 27 Feb 2019 10:42:08 -0800 (PST) Received: by mail-pf1-f178.google.com with SMTP id n22so8425560pfa.3 for ; Wed, 27 Feb 2019 10:42:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nT2kracH2fA39J66t/2ee6ygVaT7UG4HMea+UQgRCiQ=; b=evs6Ix3RoxHyWrbsd8WlIgqepdp5zemY+rC9JH492QpHoHJDDFhRRqegr/Y1TMBKHO OOXaNVefNxX8LBhFfgj0TcFf5jxYylk+M/YV6ixzwCxogMaqoIUxMF7DDHMLd4p5YVWF /7qnbrSMUzPYrkQpKrniCiRLH6M0a0reYMt2Lbio29VG1d5so/RzLDV3X+NGKye8Maa7 5CPMrsHB2r37+YC9xevAigxISUkxtXmSSe9AnAuOEhJNSmoQoFogKdPAS6/4bX9q1jis KMiBl5SqyCQI+IjlfJ9FqMuPrJ9tfNrZCBHIXhOPD1EvakAUuxa6DqXfqB02JC60ukQ1 Hh7w== X-Gm-Message-State: AHQUAuYjC0/ZJoLtCxXRIrGWGjW5IaHgepRsrEnqjfU7hHPN9mButMye C4EYh3Pc4ESNP7IZzmyq7h2GR8xYgyE= X-Google-Smtp-Source: AHgI3IbuGLvDvcJB58cqnDTXPJ/leMTMUeD7mfjADN3HAbKB7oxz5mYBYiR6eINgsqZ1j1cgZ/WCtA== X-Received: by 2002:a62:4793:: with SMTP id p19mr3202730pfi.76.1551292927408; Wed, 27 Feb 2019 10:42:07 -0800 (PST) Received: from [192.168.1.100] (c-69-181-241-121.hsd1.ca.comcast.net. [69.181.241.121]) by smtp.gmail.com with ESMTPSA id f2sm20332552pgn.43.2019.02.27.10.42.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 10:42:06 -0800 (PST) To: netmod@ietf.org References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-000000@email.amazonses.com> From: Randy Presuhn Message-ID: <678ff95c-ecd0-5902-133a-60136af492e3@alumni.stanford.edu> Date: Wed, 27 Feb 2019 10:42:05 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 18:42:10 -0000 Hi - On 2/27/2019 10:17 AM, Kent Watsen wrote: ... > If so, then there should be a way for the server to indicate which > discretionary choices it made.   I'd suggest that "obsolete" defaults to > "not-implemented" and thus only servers that want to continue support > for the node need to indicate anything.  A deviation would be a good fit > for this. Are you saying that legacy boxes sitting in dark closets would somehow be updated to provide this indication? Randy From nobody Wed Feb 27 12:09:50 2019 Return-Path: <010001693093c36e-da710fca-f117-4cf2-b2e6-7882cf74096f-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 616C6127AC2 for ; Wed, 27 Feb 2019 12:09:48 -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 HdzSx8SqgtIZ for ; Wed, 27 Feb 2019 12:09:45 -0800 (PST) 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 7C8BA1310AC for ; Wed, 27 Feb 2019 12:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551298184; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=lMQys1TLZbee1lh3N+orLX6Aaz2xlyCwoiCE61Uuzms=; b=GO5+HRPVs+2HQ4lAHtE7s9tbwwfNRZg+XZAw3ueUNs3/4JxIqToHrsu32mJx2ZXw bMX5fnpE3RDYuXyGMdErYFscUopiYkm7vR323klTqHVNDUWS+GVEAJivzxPJkcy/8T6 V5Z93pGUQYmjTTci2dvx011yE/vkl65OZTwhm80U= 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: <678ff95c-ecd0-5902-133a-60136af492e3@alumni.stanford.edu> Date: Wed, 27 Feb 2019 20:09:44 +0000 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <010001693093c36e-da710fca-f117-4cf2-b2e6-7882cf74096f-000000@email.amazonses.com> References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-000000@email.amazonses.com> <678ff95c-ecd0-5902-133a-60136af492e3@alumni.stanford.edu> To: Randy Presuhn X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.27-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 20:09:48 -0000 Hi Randy, > Are you saying that legacy boxes sitting in dark closets > would somehow be updated to provide this indication? Assuming YANG-next resolves the issue, and there is sufficient = motivation then, yes, sys-admins would need to blow the dust off their = servers (and clients) and update them to YANG-next. Otherwise, the = status-quo prevails, which may be okay for some. Kent From nobody Wed Feb 27 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 A4B61131176 for ; Wed, 27 Feb 2019 14:26:38 -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 c53Dq0ZF61Ye for ; Wed, 27 Feb 2019 14:26:36 -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 9FD03131175 for ; Wed, 27 Feb 2019 14:26:36 -0800 (PST) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id D8D7B242003 for ; Wed, 27 Feb 2019 23:26:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1551306393; bh=yYuoO7xaHMYbp80Wr8ADkDS4wzxtvm1uVYwFUWjBxO4=; h=To:From:Subject:Date; b=XE5tAxlzuMGZwYHkqjN6s2umiLOv//BBL1qZdByi7EUB7/FYuxvy0PXqnag9LsZD2 TgK0sy9ZSWS41Fea2dgzG5eTaBFX7WLuDKhu65cxLGpDHRQwtlbR8QV+7+/NgHncAR T2TN9E9BoZVCWkLNEVpJdJujKN3mhmAstzPIQp1o= To: "netmod@ietf.org" From: Robert Varga Openpgp: preference=signencrypt Message-ID: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> Date: Wed, 27 Feb 2019 23:26:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w8UhVh3W0mV45qlpkkFzDIkfIWEvuKsCN" Archived-At: Subject: [netmod] RFC7952 JSON streaming decoding efficiency? 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 Feb 2019 22:26:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w8UhVh3W0mV45qlpkkFzDIkfIWEvuKsCN Content-Type: multipart/mixed; boundary="2fWeVbyYEkLmLNqJZ8W5VrLi2IdNw3gDe"; protected-headers="v1" From: Robert Varga To: "netmod@ietf.org" Message-ID: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> Subject: RFC7952 JSON streaming decoding efficiency? --2fWeVbyYEkLmLNqJZ8W5VrLi2IdNw3gDe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello, reading RFC7952 sections 5.2.2-5.2.4, it would seem that metadata object (5.2.2) can occur at any position in a JSON object, as well as metadata attachments to leaf/leaf-list/anyxml (5.2.3, 5.2.4) can occur any distance (before or after) from the data element they attach to. The examples list the metadata object as the first item, and attachments immediately after the data element, but I could find no text which would make this required or recommended for document producers. While this is completely workable when the parsing state is received into a mutable structure, it requires full parser event buffering in streaming setups. One example would be JSON->XML transformation using token streaming interfaces (like GSON's JsonReader and javax.xml.stream.XMLStreamWriter): since metadata can occur at any place in JSON, but is required to be emitted just after opening XML element, we must completely parse the JSON document before we can start emitting the XML document. Is this intentional or just an omission? Thanks, Robert --2fWeVbyYEkLmLNqJZ8W5VrLi2IdNw3gDe-- --w8UhVh3W0mV45qlpkkFzDIkfIWEvuKsCN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlx3DpMLHG5pdGVAaHEu c2sACgkQJKB0S2uuNdsgQhAAinNYIF1kSLUt1GdGrt/g0nfbt9TPlgkZTt8t6lIC 4EyRQM6D+cwF2ZPeWDaMm02fWkEyEmuadfvlEb9r2XFlgkwTEzPJhlPtamr/F/re qavd9N7e5ANONvSFVxvHLQw1vRMNxzlwHrdVx+AhrZWx1MtWg1CgQip3z5jCG7nn dkxBMuNU9j26qvLyqly1n7DbUJQVuS8e7m0kXK1UPySOVHqOjbaMJpgS5/Zdk1Pi X12XKYv9n5z1F4eBG7Bp4UnjFqJ+daOmXOgEoq+ecm3yVn48BEHh5FrqtZdKAwPD 8Nfra3ZLg73ElvP2urq1wwnnlTxPVOX7W4jpVMje3K3ztfdLTGFYSpCHr/13Uxe0 +tjqP0ej0d86B2HC4Xz7aXjUjDZK1GKjhyyZ4GZC38TNNKT0nasEmVXfN/BFQmLW e5PN0vd81xClatWkoLxiDMh9MQeohV7ZJm3ZpqofUHDxSk7AbcGAVS7Zalr5y1XN /fvr0808RGsni82A6CpsIU1kFUf4ql+ZHDRepJo9s+ideFXl+vqMqW+ug9vzAgAr MbDPrFB6FEgm8OldvRGK5k7uf+s3Ba2HFEWo8hADOBhCZVTs1ea6x9mpDdgKzv/C FwyMqpwLG6MCfGgLqvhpnz3vdDboUtSMGBkrmRcv48hgM3llYfS9P2bpz3vBngOQ N68= =3txf -----END PGP SIGNATURE----- --w8UhVh3W0mV45qlpkkFzDIkfIWEvuKsCN-- From nobody Wed Feb 27 18:39: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 3C8BA130EE3 for ; Wed, 27 Feb 2019 18:39:38 -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 qdx2-A-P2tnh for ; Wed, 27 Feb 2019 18:39:36 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C0DF5130ECF for ; Wed, 27 Feb 2019 18:39:35 -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 1355F604E3; Wed, 27 Feb 2019 21:39:35 -0500 (EST) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_2F8AD3EB-D46B-4E27-B811-C2CBD0ED52A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 27 Feb 2019 21:39:33 -0500 References: <155121476305.848.1143308532121819978@ietfa.amsl.com> To: NETMOD Working Group Message-Id: <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [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: Thu, 28 Feb 2019 02:39:38 -0000 --Apple-Mail=_2F8AD3EB-D46B-4E27-B811-C2CBD0ED52A5 Content-Type: multipart/alternative; boundary="Apple-Mail=_A3C7A869-2F2E-4901-92DB-521AEB6934BE" --Apple-Mail=_A3C7A869-2F2E-4901-92DB-521AEB6934BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI. > Begin forwarded message: >=20 > 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 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : YANG Geo Location > Author : Christian Hopps > Filename : draft-chopps-netmod-geo-location-00.txt > Pages : 17 > Date : 2019-02-26 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/ >=20 > 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 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 >=20 --Apple-Mail=_A3C7A869-2F2E-4901-92DB-521AEB6934BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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: = <i-d-announce@ietf.org>
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-locati= on/

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-l= ocation-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


= --Apple-Mail=_A3C7A869-2F2E-4901-92DB-521AEB6934BE-- --Apple-Mail=_2F8AD3EB-D46B-4E27-B811-C2CBD0ED52A5 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+m1FHa6lLh2DDte4MCUFAlx3SeUACgkQLh2DDte4 MCXSpBAAnHJiI739zJxrCYcjsQYdel/ojYGjdpqkbiCAyaIDew7ZrbdonaGp0uMO ag/NfHPXj/YiUxsw6ixf87JjbMHKkUb+9LQdfvswj/077OmSs4NNThRvJTGO/RpR 4//65FcMsyW9nzbmuxZe2eGwV83SmXRHQj3L8PIKatyiG2fFCthTC5TL6lGal0Og Gl9a5jgidemoB/UyMPUSiSG43WlEBb28OLKz3poBVjtT9OdiYt0PABYy1WA635TS bUEK0XxFqGxyRXLhqhaLMPAtXrz0Ry5yzqoqjMAsaAaYYRQ7QugxY2v+sJo6xdtL /A3d7TuTwbKM3VoPQ30Gvvu7usX3Vf38le3EgQsPWvpZ50awl1qbAi2A8hsOxabr Ac0Vu4yfqvngda14DT+NxR9oqcMVq6neDjgFgCEkCgPts3rt+9XzHyRIN/GnOnWj s5azABRfCKGnPhEE1VAnjOSg2JzA/QGt27X755qxFkbiH9nl06kCJHaLpvgvgKdb 6nClCX6TS11hVQeS73sUQQ0B8mG1ZiWU4rL60mNC4ggl1a62YHb3tTG54uFBDC1r qqNc07iNHGPYgidh/TIn0wcOvfk242M+RavR2r1R3FejlK5PQMnJjxLE9dSDuiNL AKJZMQMZm2L6kkXnlu/40ai6VMcilX+koAPK0WmQaXuGannIxYE= =VlrM -----END PGP SIGNATURE----- --Apple-Mail=_2F8AD3EB-D46B-4E27-B811-C2CBD0ED52A5-- From nobody Wed Feb 27 19:50:07 2019 Return-Path: <0100016932392dc9-dc03458d-8c40-4a84-8694-276a020f65b5-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 6026612EB11; Wed, 27 Feb 2019 19:50:05 -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 UsgiMHkuvs4Y; Wed, 27 Feb 2019 19:50:03 -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 4F73112F18C; Wed, 27 Feb 2019 19:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551325802; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=6l9jiZBjrPbgxkKEPWlxNwwCK/NyDnmElUS2vuqrjNE=; b=NI+rei0QRKkdRMelwfkgEiIF64JnAFM6qdog82Z8BFK87h6xEAPVIOevobf5XnEQ gVNbCFLP0smjRSgn/JNVQG4Ud/DAfqPMsQBpd64pw5LaczQrxvEEPle5NOaD1aytexR uYcc0NbiQObko2iUG7hRPD97hQJFJFEmdnaabtaM= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_EFFDF9A4-833A-4FFE-A8E6-0F457ADFDE78" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016932392dc9-dc03458d-8c40-4a84-8694-276a020f65b5-000000@email.amazonses.com> Date: Thu, 28 Feb 2019 03:50:02 +0000 Cc: netmod-chairs@ietf.org To: netmod@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.28-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] IETF 104 Presentation Requests 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 Feb 2019 03:50:05 -0000 --Apple-Mail=_EFFDF9A4-833A-4FFE-A8E6-0F457ADFDE78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, The preliminary IETF 104 Agenda has been posted [1]. NETMOD is = currently scheduled to meet twice, 2 hours Tuesday morning and again for = two hours on Friday morning. If you are interested in presenting to the WG, please send your = presentation requests to the "netmod-chairs" alias (CC-ed) with the = following information, for each presentation request, if more than one: - name of the drafts (if any) - name of presentation (usually same as the name of the draft) - name of the presenters - desired time request in minutes. [1] https://datatracker.ietf.org/meeting/104/agenda.html = PS: *please* respond to *this* thread, even if you sent a request to the = chairs already. Thanks! Kent (and Lou and Joel) --Apple-Mail=_EFFDF9A4-833A-4FFE-A8E6-0F457ADFDE78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
Dear WG,

The preliminary IETF 104 Agenda has been posted [1].  NETMOD is =
currently scheduled to meet twice, 2 hours Tuesday morning and again for =
two hours on Friday morning.
If you are interested in presenting to the WG, please =
send your presentation requests to the "netmod-chairs" alias (CC-ed) =
with the following information, for each presentation request, if more =
than one:

  - name of the drafts (if any)
  - name of presentation (usually same as the name of the draft)
  - name of the presenters
  - desired time request in minutes.

[1] https://datatracker.ietf.org/meeting/104/agenda.html
PS: =
*please* respond to *this* thread, even if you sent a request to the =
chairs already.
Thanks!
Kent (and Lou and Joel)

= --Apple-Mail=_EFFDF9A4-833A-4FFE-A8E6-0F457ADFDE78-- From nobody Wed Feb 27 23:18: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 EF190130DEF; Wed, 27 Feb 2019 23:18:46 -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 90Puvw2r51lp; Wed, 27 Feb 2019 23:18:44 -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 1B569130DF6; Wed, 27 Feb 2019 23:18:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8303E731; Thu, 28 Feb 2019 08:18:42 +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 hP9eHV8usYVU; Thu, 28 Feb 2019 08:18:42 +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, 28 Feb 2019 08:18:42 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45E3220067; Thu, 28 Feb 2019 08:18:42 +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 RiR9HFW6Rx_S; Thu, 28 Feb 2019 08:18:42 +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 F34B820064; Thu, 28 Feb 2019 08:18: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; Thu, 28 Feb 2019 08:18:41 +0100 Received: by anna.localdomain (Postfix, from userid 501) id C967E3006E8D64; Thu, 28 Feb 2019 08:18:40 +0100 (CET) Date: Thu, 28 Feb 2019 08:18:40 +0100 From: Juergen Schoenwaelder To: Kent Watsen CC: , Message-ID: <20190228071840.fyhdtocip3gyvmap@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , netmod@ietf.org, netmod-chairs@ietf.org References: <0100016932392dc9-dc03458d-8c40-4a84-8694-276a020f65b5-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016932392dc9-dc03458d-8c40-4a84-8694-276a020f65b5-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] IETF 104 Presentation Requests 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 Feb 2019 07:18:47 -0000 On Thu, Feb 28, 2019 at 03:50:02AM +0000, Kent Watsen wrote: > If you are interested in presenting to the WG, please send your presentation requests to the "netmod-chairs" alias (CC-ed) with the following information, for each presentation request, if more than one: > > - name of the drafts (if any) > - name of presentation (usually same as the name of the draft) > - name of the presenters > - desired time request in minutes. I started a personal I-D for a revision of RFC 6991, our collection of common YANG data types. The goal is to discuss issues with the proposed new definitions, the scope of this work, and whether it should be done at all. - name of the drafts: draft-schoenw-netmod-rfc6991-bis-00 (to be updated) - name of presentation: Update of Common YANG Data Types (RFC 6991) - name of presenters: Juergen Schoenwaelder - desired time: 15 minutes /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 Feb 28 00:58: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 BF682130E74 for ; Thu, 28 Feb 2019 00:58:51 -0800 (PST) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Qy7U+h+X; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gEVKt1GB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z66Z27iTLKk for ; Thu, 28 Feb 2019 00:58:50 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1810E130E7D for ; Thu, 28 Feb 2019 00:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551344327; x=1553936327; 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=6hYfeZRhg0hZpZFWdpJeELXZABfGDIc+Fa9Ltm1VpbY=; b=Qy7U+h+X0fKbYuBHWMOblcH9/zV95QeGFNndHLp3vkGcnhC59Okxer/NDFiCGHIs JRtaMDZuAn8KEq2PTlYVGZtKqbk351Ff24fT+ARobCvH7iZu6uF7p9xe0f5rkc/f v64lswGvsCk8vlOn0x8JO5Tb9zTZo5R30hxZz2pMLXE=; X-AuditID: c1b4fb25-da1ff70000005ff7-03-5c77a2c64b1f Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.92.24567.6C2A77C5; Thu, 28 Feb 2019 09:58:47 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 28 Feb 2019 09:58:46 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) 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, 28 Feb 2019 09:58:46 +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=6hYfeZRhg0hZpZFWdpJeELXZABfGDIc+Fa9Ltm1VpbY=; b=gEVKt1GBHgXY50SnM8yzMNj9EdcEj91d93XrKF30FcP8/wniqmbvHwopTcTPmILC5YGvSbINI3ynEL4YkGAl7/Jloi0eNqg7cAIW+vw4eXDvZ/iSnQHhXHxSZ1Ms5pv0sAwT5dQT4H1CpVfW4tlPjcYY8kriiWMvqWPpATtL2KM= Received: from AM0PR07MB3841.eurprd07.prod.outlook.com (52.134.82.16) by AM0PR07MB4163.eurprd07.prod.outlook.com (52.133.59.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Thu, 28 Feb 2019 08:58:45 +0000 Received: from AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd]) by AM0PR07MB3841.eurprd07.prod.outlook.com ([fe80::e1db:cd5a:d70f:32bd%2]) with mapi id 15.20.1665.012; Thu, 28 Feb 2019 08:58:45 +0000 From: =?Windows-1252?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: [netmod] IETF 104 Presentation Requests Thread-Index: AQHUzxi4mKzaLQTefEW80Ztqcx6TU6X06WaA Date: Thu, 28 Feb 2019 08:58:45 +0000 Message-ID: References: <0100016932392dc9-dc03458d-8c40-4a84-8694-276a020f65b5-000000@email.amazonses.com> In-Reply-To: <0100016932392dc9-dc03458d-8c40-4a84-8694-276a020f65b5-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.1 x-clientproxiedby: HE1PR0402CA0007.eurprd04.prod.outlook.com (2603:10a6:3:d0::17) To AM0PR07MB3841.eurprd07.prod.outlook.com (2603:10a6:208:45::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: 78fce0f5-1b8b-4aaf-8ad1-08d69d5af1eb 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:AM0PR07MB4163; x-ms-traffictypediagnostic: AM0PR07MB4163: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; AM0PR07MB4163; 23:hBdU27qOiliW2RaODWzNyHBeFjHGwZyTpy801?= =?Windows-1252?Q?2w9KmRRt2UsrEJZzbTSxqOncUg2Rig8id6W+jwDqt5TFwPDlvKR3dfd/?= =?Windows-1252?Q?sbzvsx9OCtibVHM8ajbyrI85Cmt2Y+um9hNphoNAl466lEh3sLbTlob2?= =?Windows-1252?Q?bz3hRAv2kazzqvGuouk7ZmtxEIML9AgyVN5nD2rZKFX5k4kU9M2JBQ3K?= =?Windows-1252?Q?nwdVsRCyyqumRF6Vt46eBpomxGPAsD9d0JPFFpamDn/QZNonZv1kqI5o?= =?Windows-1252?Q?cGqmrbzE+OtAzRFRdrx2kD+jVgQGs/2MvhM+2hD/fc5kI6lvHUKX4Znj?= =?Windows-1252?Q?9V1TAx73skzjpyhwTJzRTT1SHEjB9JqwSMai7c/wDlXctGqBO/wehChl?= =?Windows-1252?Q?yqeCqi8o6u4ESvq1utRvDgcMqLJmB7Mgsx3LnsOr2jorN1KY+10XS2E9?= =?Windows-1252?Q?GoOA/nR3RQ/l2GgYVSfu/TKU8ZqJNC4rt8Ctkz3bKiM1o+Z0QWrAR9NJ?= =?Windows-1252?Q?yxslRPmO+AYVowGQQgVmskV//qV3byT2qq2XK1l0I7P2KQQehhrHdpyI?= =?Windows-1252?Q?xXI61daEBsFOZfbCPLytHoHit+U9yybul0NmTBKJ5enVaxWPIDgR16rV?= =?Windows-1252?Q?oN8NaaE0gvLjxGCr07UFaqTuL1AaOjmdUPhyfKwIECiqL7/GGRY9pCOf?= =?Windows-1252?Q?dnOyPdw8WrAKu7hsIOEM3JNExmbT19SAIi9HxyBmGSj0ECPKvzebxlkk?= =?Windows-1252?Q?FKnAdQkOBQcgKRbw1RNs1bpyu0HYD9w6k6E9CfPCQobrB2tpO3rjtpT2?= =?Windows-1252?Q?yWaVU5Eb4FKtQIPg3+Knk9828JYVDDZCblplYF+fdBnFMBAk0aiZs4X7?= =?Windows-1252?Q?2Nn2OYkTJl3cKfV9pR0nt60e/TBJ8HISI+9yA48KmBUDXTfLEE+b9wcI?= =?Windows-1252?Q?u9ABSt00o2n69/g1la3lY9imKlEwUIsH4lu7pqq1l2NQLsI9S94jc+qq?= =?Windows-1252?Q?eSRI0/IQAEspQRGkSBbHxT9X6z7CIvVtJJqPbruq7ol/vuKUI1v6UGhd?= =?Windows-1252?Q?9Q6PzGPyskhYtaYbfBJ75MAROqvqB8U+HXDjHyJfVZOAWaPAUzmecjY/?= =?Windows-1252?Q?SefRpXJPsP84q4iZyHEkElF1ARtlsZoHh82lb4dK3WV/KAq9Apmi4v56?= =?Windows-1252?Q?2OkZx1bHp0ys0cSOnc97FpdB3lsG5eiI1TQONs5DwAY3CIyvMGsvdqhV?= =?Windows-1252?Q?/C11cYcAdFRYvLldc9ewY1yiSALsyi9PFxP4UTGZI/n7/czMcEZ1EfKl?= =?Windows-1252?Q?OPVEZos6eAuzY++FN3eEZjEZMg6C6Xji4bTsv1ffWgwjv8MBt0+Stvub?= =?Windows-1252?Q?79AzEEe6RmBRHRksV/sA/tDdLTPw4ZqEceElFWmr6z9A0AiXPRgpd+1t?= =?Windows-1252?Q?9UtpU+xOWChU1DG6ZozePi3VziqJkmbUy9JgLISlJM9YSRusvIlqFuwH?= =?Windows-1252?Q?z0l+O61IfLIwilVFjt8AArAFuoYHwLYo6Kd2OJgazhQwY57VahDVceY8?= =?Windows-1252?Q?z2ZoZ/dl+8F2d/DzYmaCROp+aQXo5qmcsYNbhCMyaZsd7CqMjZlvGirg?= =?Windows-1252?B?UT09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(376002)(396003)(39860400002)(366004)(189003)(199004)(68736007)(6486002)(8676002)(81166006)(236005)(102836004)(81156014)(6506007)(54896002)(386003)(6306002)(2501003)(606006)(76176011)(6436002)(6512007)(11346002)(106356001)(186003)(476003)(26005)(316002)(2616005)(110136005)(229853002)(58126008)(105586002)(446003)(31686004)(52116002)(21615005)(99286004)(99936001)(486006)(8936002)(64126003)(966005)(478600001)(65826007)(3846002)(6116002)(7736002)(71190400001)(71200400001)(6246003)(5660300002)(14454004)(65956001)(66066001)(65806001)(4326008)(25786009)(31696002)(86362001)(53936002)(2906002)(256004)(14444005)(97736004)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4163; 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) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ny7owYtLpdvdAm2/1/U5PY2c2rJCm+FZTR7eiyoFSvN4dnn/PRFpWRUh4coEFjf9tIeFZly6ZwRZFglfIth4VSNLQ+m1YJu5klmS5LkfGNwrScS4EZFFwm8eBu/cQfx8Mcu1/YG/iTC6WKr35aUKg9EKGIhsuEpAHlVTLLQoHw+ujnd9+SqU9gpKygCbwJZbrV74nokhPALmbUimk2rn8Lu3EEypZXxx7zN1AF4XuMVtxbam/SsRRtFtXi/kPwBznwVrEdRdlzf51wo2o7qJtpBcxR5Q0Jrj38/yoB+tECv2RmkHsQ7h4/Idqv76R/mASY/dOouRqDev1y4+KoMKqG9/Jf8N70nuvNo9BPYeORaF9DVI6bCmxzt+MkMG0qp489DtmyTyc/UV0OjJuBB2675LvXWhrNTzR6bXZJbzndU= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020306010908070009060508" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 78fce0f5-1b8b-4aaf-8ad1-08d69d5af1eb X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 08:58:45.3678 (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: AM0PR07MB4163 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHec85O5vDweuc+bCoaK170/ISg27Wl6QwKoJELFt1UnFNOWdp 1odWYKUmahrlkViFzPKyxFmZXSC7Z6FmV6PZbmmukrAW1bpsOwvq2+95///n/zwPvBJS7hAp JbkGI8MadHoVLaXq0i/t1dw9U5Q5v6kGaT+6fyNtc8UMrbl/vyiFTG1o+Eakuu6VidcSGdLF 2xl9biHDxi/dIs2pLGlFBVc27LY6TaQJVaeVoQgJ4CToco+Jy5BUIse3EDz9XU4KhQ9Br28o XDQQ8KLjXMhG4SoS+PoDtKBUE8D33QoHOBG0dPlFwWQar4Rq+1cqyAq8Gro+HxYHmcTJ0GR7 RQQ5OjD9h71KLHiSwedpJwROAHdtR4gpPB1qrj8JsQwvg9aX10Isx5vhIW9HQY7AWVA3fjL0 jvAE+PqghRBmxcKg20wIlyrA0d9DCxwD71y/RAKr4MToYIhj8Caw1R4L3Qz4OIKBF+Zw6Ga4 aj8cbp4Hj567kcCT4LG5PMxp4Bv1hJtdCKyNzvDkOdB7wUwLwjiG8dERShDyoGXkPKpC8fw/ 2/IBH4lLEXSOfUB86OwouF/npgSTBs5cPCv+vyHIc8Fy2ksKvAhOfL9BCzwVassdYX8yeG9/ QgIngsX6kz6FpE0ohmO4rTuzExLjGDZ3G8flG+IMjLEdBT7bjY4f0zvRwPvl3QhLkCpS5j9a lCkX6Qq54p3dSB3IcbY19yElZcg3MCqFbJgPyLLtuuI9DJufxe7SM1w3miihVLEyvzwqU46z dUYmj2EKGPavSkgilCYUY1RM8Z3LoLU4qqgv9e1l3rZKHfemJHLjiobom7MtJfUVL3saKznF MXnN4OvEtpTJFqV+EmorvhmNjl5jDcOOg894zayh79Pa7xz64qmfMKV0XblqvWax2niwJGnE tobZd51mFy1J83sdGV5lrDU9IV20496zsZlHGtULXSaPiuJydAvmkCyn+wPcIKcIdAMAAA== Archived-At: Subject: Re: [netmod] IETF 104 Presentation Requests 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 Feb 2019 08:58:52 -0000 --------------ms020306010908070009060508 Content-Type: text/html; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

I would like to present our draft:

=A0 - name of the drafts (if any)=A0=A0 draft-ietf-netmod-yang-instance-file-format
=A0 - name of presentation (usually same as the name of the draft)=A0= =A0 draft-ietf-netmod-yang-instance-file-format
=A0 - name of the presenters=A0 Balazs Lengyel
=A0 - desired time request in minutes.=A0=A0 10-15

regards Balazs

On 2019. 02. 28. 4:50, Kent Watsen wrote:
Dear WG,

The preliminary IETF 104 Agenda has been posted [1].  NETMOD is currently=
 scheduled to meet twice, 2 hours Tuesday morning and again for two hours=
 on Friday morning.
If you are interested in presenting to the WG, plea=
se send your presentation requests to the "netmod-chairs" alias (CC-ed) w=
ith the following information, for each presentation request, if more tha=
n one:

  - name of the drafts (if any)
  - name of presentation (usually same as the name of the draft)
  - name of the presenters
  - desired time request in minutes.

[1] https://datatracker.ietf.org/meeting/104/agenda.ht=
ml

PS: *please* respond to *this* thread, even if you =
sent a request to the chairs already.
Thanks!
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
--------------ms020306010908070009060508 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 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDIyODA4NTgzOVow LwYJKoZIhvcNAQkEMSIEIGfkqlG5hYtLrjwiRCrCOubbj2h4Irra5j01d+eQqvP0MGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAFJRpaZqStCYmn5QsiBfAFdkZUcDVi3mfXUdGTg6NrMdpiaU aflxFgkL163ZeZjBdzeFC2XfzBr8zZ/KHOt1i8bjvNXCmQZPl5ucAix+xX33eFwJcslyuIo+ VM0/kOpi1QqJpIJJbUqkaIkbChUgBrvTk+FlloBM+bx3gT4jAjTuK6aFwfCh/ldAgOL1mlUp Cb12bcLJgaggRMcUsDkgHPwKaxLDTExItsKCMU9koAt3Mjizi5kDqVenX4pb4e+CsKeW2R1D KDC8vn11XQW8U1DNGfV61KsKX5NoD8Id+/tvVYJVpOGiJb64xBGw8mWSPzMWyGJH3LTgGFfk Ku81M8MAAAAAAAA= --------------ms020306010908070009060508-- From nobody Thu Feb 28 01:29: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 6C17E130F16 for ; Thu, 28 Feb 2019 01:29:15 -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 bf0Gear1NnzN for ; Thu, 28 Feb 2019 01:29:13 -0800 (PST) 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 730CF130E25 for ; Thu, 28 Feb 2019 01:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1551346153; x=1552555753; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=W12yq7mZ5NQ1SkGA1MfTBm6EhmX4huc+/ZCMSZjtfHM=; b=fCOtOivKdV4u5PvkdiCgPEOh12qtkHC8KKFQA4bGkKSayQeWux6m+7x4 bQs6TyxXT/klclmYOjxBEm68NT9xCxWVxfE8NtEuewK2EHqPQNEYv2X6G doInzUt2EDceh5mFjOEzR6GkxSt1mcECrUurUZp0Ue6BcKWCcwaLKMk/q U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAA5qXdc/4MNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBWiqBaycKg36IGotNgg2YIIF7CwEBhGwCF4N?= =?us-ascii?q?5IjQJDQEDAQEDAQMCbSiFSgEBAQQjBA1RBAIBCA4DBAEBAwImAgICMBUICAI?= =?us-ascii?q?EARIIgk+CPKwQfDOKK4ELhHCGTReBQD+BEYMSgUGGSoJXAooWgiaXLgkChnu?= =?us-ascii?q?LZSGTHIpdkhcCERSBKB84gVZwFTuCbJBdQTGRLYEfAQE?= X-IronPort-AV: E=Sophos;i="5.58,422,1544486400"; d="scan'208";a="240686693" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 09:29:12 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x1S9TCj3007627 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Feb 2019 09:29:12 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.1395.4; Thu, 28 Feb 2019 03:29:11 -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.1395.000; Thu, 28 Feb 2019 03:29:11 -0600 From: "Rob Wilton (rwilton)" To: Robert Varga , "netmod@ietf.org" Thread-Topic: [netmod] RFC7952 JSON streaming decoding efficiency? Thread-Index: AQHUzuuJVNQCQ66ge0a+WQBULprZtqX08KGA Date: Thu, 28 Feb 2019 09:29:11 +0000 Message-ID: <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> References: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> In-Reply-To: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> 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: 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: alln-core-1.cisco.com Archived-At: Subject: Re: [netmod] RFC7952 JSON streaming decoding efficiency? 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 Feb 2019 09:29:22 -0000 SGkgUm9iZXJ0LA0KDQpJc24ndCB0aGlzIGp1c3QgYSBsaW1pdGF0aW9uIG9mIEpTT04sIGluIHRo YXQgdGhlIGVsZW1lbnRzIGluIGFuIG9iamVjdCBhcmUgdW5vcmRlcmVkIChSRkMgODI1OSk/DQoN ClRoYW5rcywNClJvYg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9k IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJvYmVydCBWYXJnYQ0KU2Vu dDogMjcgRmVicnVhcnkgMjAxOSAyMjoyNg0KVG86IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDog W25ldG1vZF0gUkZDNzk1MiBKU09OIHN0cmVhbWluZyBkZWNvZGluZyBlZmZpY2llbmN5Pw0KDQpI ZWxsbywNCg0KcmVhZGluZyBSRkM3OTUyIHNlY3Rpb25zIDUuMi4yLTUuMi40LCBpdCB3b3VsZCBz ZWVtIHRoYXQgbWV0YWRhdGEgb2JqZWN0DQooNS4yLjIpIGNhbiBvY2N1ciBhdCBhbnkgcG9zaXRp b24gaW4gYSBKU09OIG9iamVjdCwgYXMgd2VsbCBhcyBtZXRhZGF0YSBhdHRhY2htZW50cyB0byBs ZWFmL2xlYWYtbGlzdC9hbnl4bWwgKDUuMi4zLCA1LjIuNCkgY2FuIG9jY3VyIGFueSBkaXN0YW5j ZSAoYmVmb3JlIG9yIGFmdGVyKSBmcm9tIHRoZSBkYXRhIGVsZW1lbnQgdGhleSBhdHRhY2ggdG8u DQoNClRoZSBleGFtcGxlcyBsaXN0IHRoZSBtZXRhZGF0YSBvYmplY3QgYXMgdGhlIGZpcnN0IGl0 ZW0sIGFuZCBhdHRhY2htZW50cyBpbW1lZGlhdGVseSBhZnRlciB0aGUgZGF0YSBlbGVtZW50LCBi dXQgSSBjb3VsZCBmaW5kIG5vIHRleHQgd2hpY2ggd291bGQgbWFrZSB0aGlzIHJlcXVpcmVkIG9y IHJlY29tbWVuZGVkIGZvciBkb2N1bWVudCBwcm9kdWNlcnMuDQoNCldoaWxlIHRoaXMgaXMgY29t cGxldGVseSB3b3JrYWJsZSB3aGVuIHRoZSBwYXJzaW5nIHN0YXRlIGlzIHJlY2VpdmVkIGludG8g YSBtdXRhYmxlIHN0cnVjdHVyZSwgaXQgcmVxdWlyZXMgZnVsbCBwYXJzZXIgZXZlbnQgYnVmZmVy aW5nIGluIHN0cmVhbWluZyBzZXR1cHMuDQoNCk9uZSBleGFtcGxlIHdvdWxkIGJlIEpTT04tPlhN TCB0cmFuc2Zvcm1hdGlvbiB1c2luZyB0b2tlbiBzdHJlYW1pbmcgaW50ZXJmYWNlcyAobGlrZSBH U09OJ3MgSnNvblJlYWRlciBhbmQNCmphdmF4LnhtbC5zdHJlYW0uWE1MU3RyZWFtV3JpdGVyKTog c2luY2UgbWV0YWRhdGEgY2FuIG9jY3VyIGF0IGFueSBwbGFjZSBpbiBKU09OLCBidXQgaXMgcmVx dWlyZWQgdG8gYmUgZW1pdHRlZCBqdXN0IGFmdGVyIG9wZW5pbmcgWE1MIGVsZW1lbnQsIHdlIG11 c3QgY29tcGxldGVseSBwYXJzZSB0aGUgSlNPTiBkb2N1bWVudCBiZWZvcmUgd2UgY2FuIHN0YXJ0 IGVtaXR0aW5nIHRoZSBYTUwgZG9jdW1lbnQuDQoNCklzIHRoaXMgaW50ZW50aW9uYWwgb3IganVz dCBhbiBvbWlzc2lvbj8NCg0KVGhhbmtzLA0KUm9iZXJ0DQoNCg== From nobody Thu Feb 28 01:40: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 9CFE1130E7D for ; Thu, 28 Feb 2019 01:40:58 -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 MVK0V81Xh6en for ; Thu, 28 Feb 2019 01:40:56 -0800 (PST) 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 B1FF8128B33 for ; Thu, 28 Feb 2019 01:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1812; q=dns/txt; s=iport; t=1551346856; x=1552556456; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=T1iOJ7Lb8B9HlW4ep3T363zJc4Gf9N2tk3GJHyvtwbc=; b=Rt60dp+kHbrkBb90ELT91rYLGE07E7+ns3u7MkbundEP9mBBKgXm1/Rj iahD7BMfrWMcLM4XZI3SL322bZOdd/9h7PGAGjHmAJj4YYb8nMY+cEHKa 4suMltaZ1u+E8RV2t382aMiYeIZ9wb3IUBqXPmdquoOZnfMatfknBltUM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAABIrHdc/5xdJa1kDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMDAQEBAQsBggRogQMnCoN+k2eCDZgggXsLAQEYC4FUgi9?= =?us-ascii?q?GAheDeSI2Bw0BAwEBAwEDAm0cDIVKAQEBBAEBIRE6FwQCAQgRBAEBAwImAgI?= =?us-ascii?q?CJQsVCAgCBAESCIMZgXIPq3yBL4omBYELiz0XgUA/g3Uugx4BAYFLLYJzglc?= =?us-ascii?q?CjDyXLgkCkmAhgXOFX4tKgzOHKoESkQUCERSBKCYDLoFWcBU7gmyLHoUEO0E?= =?us-ascii?q?xkS2BHwEB?= X-IronPort-AV: E=Sophos;i="5.58,423,1544486400"; d="scan'208";a="441277711" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 09:40:55 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x1S9etLJ009895 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Feb 2019 09:40:55 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.1395.4; Thu, 28 Feb 2019 03:40:54 -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.1395.000; Thu, 28 Feb 2019 03:40:54 -0600 From: "Rob Wilton (rwilton)" To: Randy Presuhn , "netmod@ietf.org" Thread-Topic: [netmod] Obsolete feature - what does it mean? Thread-Index: AQHUzoX8sLOrgwMKb0+lEXSgf1InRaXz1yyAgAAMQYCAAFGwgIAACuQAgAAY1oCAAAb3gIAAlVKQ Date: Thu, 28 Feb 2019 09:40:54 +0000 Message-ID: <60430011988f4b899874407312d55ee6@XCH-RCD-007.cisco.com> References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-000000@email.amazonses.com> <678ff95c-ecd0-5902-133a-60136af492e3@alumni.stanford.edu> In-Reply-To: <678ff95c-ecd0-5902-133a-60136af492e3@alumni.stanford.edu> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netmod] Obsolete feature - what does it mean? 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 Feb 2019 09:40:59 -0000 SGkgUmFuZHksDQoNClBsZWFzZSBzZWUgaW5saW5lIHdpdGggW1JXXSAuLi4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBSYW5keSBQcmVzdWhuDQpTZW50OiAyNyBGZWJydWFyeSAyMDE5IDE4OjQy DQpUbzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gT2Jzb2xldGUgZmVh dHVyZSAtIHdoYXQgZG9lcyBpdCBtZWFuPw0KDQpIaSAtDQoNCk9uIDIvMjcvMjAxOSAxMDoxNyBB TSwgS2VudCBXYXRzZW4gd3JvdGU6DQouLi4NCj4gSWYgc28sIHRoZW4gdGhlcmUgc2hvdWxkIGJl IGEgd2F5IGZvciB0aGUgc2VydmVyIHRvIGluZGljYXRlIHdoaWNoIA0KPiBkaXNjcmV0aW9uYXJ5 IGNob2ljZXMgaXQgbWFkZS4gwqAgSSdkIHN1Z2dlc3QgdGhhdCAib2Jzb2xldGUiIGRlZmF1bHRz IA0KPiB0byAibm90LWltcGxlbWVudGVkIiBhbmQgdGh1cyBvbmx5IHNlcnZlcnMgdGhhdCB3YW50 IHRvIGNvbnRpbnVlIA0KPiBzdXBwb3J0IGZvciB0aGUgbm9kZSBuZWVkIHRvIGluZGljYXRlIGFu eXRoaW5nLiDCoEEgZGV2aWF0aW9uIHdvdWxkIGJlIA0KPiBhIGdvb2QgZml0IGZvciB0aGlzLg0K DQpBcmUgeW91IHNheWluZyB0aGF0IGxlZ2FjeSBib3hlcyBzaXR0aW5nIGluIGRhcmsgY2xvc2V0 cyB3b3VsZCBzb21laG93IGJlIHVwZGF0ZWQgdG8gcHJvdmlkZSB0aGlzIGluZGljYXRpb24/DQoN CltSV10gDQpBY3R1YWxseSwgSSBkb24ndCB0aGluayB0aGF0IHdvdWxkIGJlIHJlcXVpcmVkLiAg T2Jzb2xldGluZyBhIG5vZGUgcmVxdWlyZXMgYSBuZXcgcmV2aXNpb24gb2YgdGhlIFlBTkcgbW9k dWxlLCBzbyBpdCBvbmx5IGRlcGVuZHMgb24gd2hpY2ggcmV2aXNpb24gb2YgdGhlIFlBTkcgbW9k ZWwgaXMgaW1wbGVtZW50ZWQgYnkgdGhlIGRldmljZS4gIEhlbmNlLCBpZiB5b3UgdXBkYXRlIHRo ZSBsZWdhY3kgYm94IHRvIHVzZSB0aGUgbmV3IFlBTkcgbW9kdWxlIHdoaWNoIG5vdyBjb250YWlu cyBzdGF0dXMgb2Jzb2xldGUgbm9kZXMsIHRoYXQgeW91IHNob3VsZCBhbHNvIHVwZGF0ZSB0aGUg bGVnYWN5IGJveCBzb2Z0d2FyZSBhdCB0aGUgc2FtZSB0aW1lIHRvIG5vdCBpbXBsZW1lbnQgdGhl IG9ic29sZXRlZCBub2Rlcy4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KUmFuZHkNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxp c3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCg== From nobody Thu Feb 28 01:46: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 04F7B130E79 for ; Thu, 28 Feb 2019 01:46: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 TJMrKUiypucL for ; Thu, 28 Feb 2019 01:46: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 D52B9130E6B for ; Thu, 28 Feb 2019 01:46:43 -0800 (PST) Received: from nitebug.nitenet.local (unknown [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 8C430241BD1; Thu, 28 Feb 2019 10:46:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1551347201; bh=LrWS2X7jQOz5TyWrtYl73Kj84azD6ZOi186YsRFDL6M=; h=Subject:To:References:From:Date:In-Reply-To; b=R4UGGKbGZjj1xSLMmdQal3PysQI69wv2iSjlN6Vi9NSiQjTqBS6lmJICs8ahVkGPC KKJbEYmVLseqXo3L5XeE90TCYSFY5vFrCVzCJ2XTP3hLWHh1yCfojDc/tInaWlLZs8 5o26ppWJETU4BcUFUpQTkDU4Oy8kzRQKO1m4lrdU= To: "Rob Wilton (rwilton)" , "netmod@ietf.org" References: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> From: Robert Varga Openpgp: preference=signencrypt Message-ID: Date: Thu, 28 Feb 2019 10:46:29 +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: <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UKpMMzpS5NEfoBbVR1RVPRl9YJjN8wXM0" Archived-At: Subject: Re: [netmod] RFC7952 JSON streaming decoding efficiency? 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 Feb 2019 09:46:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UKpMMzpS5NEfoBbVR1RVPRl9YJjN8wXM0 Content-Type: multipart/mixed; boundary="4Y1DFcMu4IXbv4Ya3k9voiqo1urf3G1EM"; protected-headers="v1" From: Robert Varga To: "Rob Wilton (rwilton)" , "netmod@ietf.org" Message-ID: Subject: Re: [netmod] RFC7952 JSON streaming decoding efficiency? References: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> In-Reply-To: <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> --4Y1DFcMu4IXbv4Ya3k9voiqo1urf3G1EM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 28/02/2019 10:29, Rob Wilton (rwilton) wrote: > Hi Robert, Hey Rob, > Isn't this just a limitation of JSON, in that the elements in an object= are unordered (RFC 8259)? Yes, but I believe this is object semantics leaking to on-wire format: while a JSON object is inherently unordered, when emitting object to the wire, implementations can choose to order the pairs to make receiver-side processing more efficient. I wonder if it would be of value to communicate such assumptions out of band, like separate content-types. In case of RFC7952 the following hints would be useful: - the document does not contain metadata (i.e. plain RFC7951) - "@" occurs as a first element in an object or not at all - "@foo" occurs immediately after "foo" or not at all This, of course, would be purely optional optimization... Regards, Robert --4Y1DFcMu4IXbv4Ya3k9voiqo1urf3G1EM-- --UKpMMzpS5NEfoBbVR1RVPRl9YJjN8wXM0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlx3rfULHG5pdGVAaHEu c2sACgkQJKB0S2uuNdsrIg//SvfP0yhswImkqF5WSz3La8BPoaaotpkv8LRnSnno I8wYn/w0UUaO50iq7/WxAaqxbZ9FNEP0v1N1txDfN5HY/iS8QwnIlT97D2cB7GiC tKcr/w5ZxOB+RQAeeKoLttD2uaNkB+NyDVJmmyVO0CsVmAEZ9Un0eg5zXUXyOwtz 5aM9vZ1JQj8HT15JUqVRtYDQQhziVc6yVNJoTIHiHejUbOTfVvHvcfSn/Pczavpu Y7HrMRCUEnDL5v8rynb+1dtJs6Xho+twOfiW2zI6vZ6tFSNEXScwIMJshrEaEzQH JeWcub4Vh65rcG1PJw1qPrM9iBUr+luJhozdLOTFoJhmiYaNgnVv2//Yvl4sX1DK oR7B5uGgas0cUgF1f3qoyJLcGgkrEzVeo4ujzoaHRGlI+CPZoBbx5vK4VCyHgE9k 7YjkubPp3DFHllwaqkVBOD38HHFzfkWoKIAALE8TXL8Y3F6WND5QD/YAIP77RVub grC67qT90RTq+xJWbLcTGFjmkrLBr2ONtQhBZH+3fFd7UW+CBclY6jUHYQJ+OeUJ JXjNr++6pTfICQTTFNEEGQRU9zwy3joA6453lGfptBK0V4HYTr3KQrHkZJ9R7cAG kZtdUL3SUeJ7Khe9RSnSmAOTrYNbuZfd2RbXS7J+YHo1rCPAaelGzQF6z2GetuiT WLI= =/1PB -----END PGP SIGNATURE----- --UKpMMzpS5NEfoBbVR1RVPRl9YJjN8wXM0-- From nobody Thu Feb 28 01:49: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 7713B130E79 for ; Thu, 28 Feb 2019 01:49:22 -0800 (PST) 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 nx9jq_eDmlMG for ; Thu, 28 Feb 2019 01:49:20 -0800 (PST) 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 CA95F130E5B for ; Thu, 28 Feb 2019 01:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23478; q=dns/txt; s=iport; t=1551347359; x=1552556959; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k7fl+R/8F2F1gtTk21yHzY/jILS3YVa00LwsDmGwsic=; b=bQftO+ofg0CGu0bkULr6zYfW00rqPIydgUM0ZgNS8Rjik+ebmHQZkKzj UhN0ub/CDv1B8TVDMUvG511/C7Eh9phjt4vEarQVYs5UNW+50BCB3zDEF NDdT8U0BNZ8jbAF455QI3cMzEmgZUGXB1EtDKfkpiY7EMlYcwFPsA+td0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAvrndc/4cNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1IL2iBAycKg36IGo1aki6FchSBZws?= =?us-ascii?q?BASOESQIXg3kiNAkNAQMBAQMBAwJtHAyFSgEBAQQjCkwQAgEIEAEEAQEoAwI?= =?us-ascii?q?CAjAUCQgCBAENBQiDGYEOZA+rfoEviiYFjEgXgUA/g3Uugx4CgUkCTIJUglc?= =?us-ascii?q?CigoxggGDf4cKjCUJAodAiyAhjF2GP4MzhyqFVoxBAhEUgSgfOIFWcBWDJ4Y?= =?us-ascii?q?KilNBMZEtgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,423,1544486400"; d="scan'208,217";a="241794533" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 09:49:18 +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 x1S9nIVf008403 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Feb 2019 09:49:18 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.1395.4; Thu, 28 Feb 2019 03:49:17 -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.1395.000; Thu, 28 Feb 2019 03:49:17 -0600 From: "Rob Wilton (rwilton)" To: Kent Watsen , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Obsolete feature - what does it mean? Thread-Index: AQHUzoX8sLOrgwMKb0+lEXSgf1InRaXz1yyAgAAMQYCAAFGwgIAACuQAgAAY1oCAAJ2wAA== Date: Thu, 28 Feb 2019 09:49:17 +0000 Message-ID: <8277e305020d474294a09cb774eedee4@XCH-RCD-007.cisco.com> References: <20190227103303.emm3xj372rb7fx7t@anna.jacobs.jacobs-university.de> <2035f82c-bc0c-e5bb-40f2-efa6dcef6bde@ericsson.com> <010001692fb7a0c6-9a9ecc8c-f0b0-413c-92eb-30ea0d4b1834-000000@email.amazonses.com> <20190227164816.tlfqg4voabtdk7ey@anna.jacobs.jacobs-university.de> <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-000000@email.amazonses.com> In-Reply-To: <01000169302cb03d-acbf34b5-56ba-40f0-8abc-2e938f5b0dfa-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.61] Content-Type: multipart/alternative; boundary="_000_8277e305020d474294a09cb774eedee4XCHRCD007ciscocom_" 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] Obsolete feature - what does it mean? 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 Feb 2019 09:49:22 -0000 --_000_8277e305020d474294a09cb774eedee4XCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5mb3J0dW5hdGVseSBhIGRldmlhdGlvbiBpcyBub3QgYSBnb29kIGZpdCB0byBtYXJrIHRoYXQg YW4gb2Jzb2xldGUgbm9kZSBpcyBpbXBsZW1lbnRlZC4NCg0KQXNzdW1pbmcgdGhhdCBJ4oCZbSBy ZWFkaW5nIFJGQyA3OTUwIGNvcnJlY3RseSwgaXQgZG9lc27igJl0IGFsbG93IHlvdSB0byDigJxk ZXZpYXRlIGFkZOKAnSBhIGRhdGEgbm9kZSwgbm9yIGNhbiB5b3UgY2hhbmdlIHRoZSBzdGF0dXMg KGUuZy4gZnJvbSBvYnNvbGV0ZSB0byBkZXByZWNhdGVkKS4gIFNvLCBJIHRoaW5rIHRoYXQgd2Ug d291bGQgbmVlZCB0byBjaGFuZ2UgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgZGV2aWF0ZSBzdGF0 ZW1lbnQgaW4gWUFORyBOZXh0IGlmIHdlIHdhbnRlZCB0byBnbyBkb3duIHRoaXMgcGF0aC4gIEFs dGhvdWdoLCBJ4oCZbSBub3QgYWN0dWFsbHkgY29udmluY2VkIHRoYXQgaXQgaXMgcmVhbGx5IHJl cXVpcmVkL2hlbHBmdWwuDQoNCk15IHRob3VnaHRzIG9uIHRoaXM6DQoNCjEpIERlcHJlY2F0ZWQg bm9kZXMgc2hvdWxkIGFsd2F5cyBiZSBpbXBsZW1lbnRlZCwgaS5lLiBlZmZlY3RpdmVseSBoYW5k bGVkIHRoZSBzYW1lIGFzIGlmIHRoZXkgd2VyZSBzdGF0dXMgImN1cnJlbnQiIGJ1dCBhbm5vdGF0 ZWQgdGhhdCB0aGV5IHdpbGwgZGlzYXBwZWFyIGluIGZ1dHVyZS4gUGVyaGFwcyB0aGlzIGNhbiBi ZSBjaGFuZ2VkIGJ5IGZpeGluZyB0aGUgbGFuZ3VhZ2UgKGUuZy4gaW4gWUFORyBOZXh0KSBhbmQv b3IgdGhyb3VnaCBhICJkZXByZWNhdGVkLW5vZGVzLWltcGxlbWVudGVkIiBsZWFmIHJlcG9ydGVk IGluIFlBTkcgbGlicmFyeSAoZS5nLiBpbiB0aGUgU2VtdmVyIGRyYWZ0KS4NCg0KMikgT2Jzb2xl dGVkIG5vZGVzIFNIT1VMRCBOT1QgYmUgdXNlZCBieSBhIGNsaWVudCwgYW5kIFNIT1VMRCBOT1Qg YmUgaW1wbGVtZW50ZWQgYnkgYSBzZXJ2ZXIuICBJIHRoaW5rIHRoYXQgUkZDIDc5NTAgcHJldHR5 IG11Y2ggc2F5cyB0aGlzIHRvZGF5IGFueXdheS4NCg0KSSBkb24ndCB0aGluayB0aGF0IGl0IGhl bHBzIHRvIGZvcmNlIGEgc2VydmVyIHRvIHJlbW92ZSB0aGVtLiAgVGhlIFNlbXZlciBkcmFmdCBh bHNvIGhhcyBhIGxlYWYgdG8gaW5kaWNhdGUgd2hldGhlciBvciBub3QgYWxsIG9ic29sZXRlIG5v ZGVzIGFyZSBpbXBsZW1lbnRlZCwgYnV0IEknbSBub3QgdGhhdCBjb252aW5jZWQgdGhhdCBpdCBp cyB0cnVseSB1c2VmdWwuICBJbiB0aGF0IEkgdGhpbmsgdGhhdCB0aGUgcnVsZXMgYWJvdmUgc3Rp bGwgZ2l2ZSBpbXBsZW1lbnRhdGlvbiBmbGV4aWJpbGl0eSBidXQgc2hvdWxkIHN0aWxsIGJlIHN1 ZmZpY2llbnQgZm9yIHJlYXNvbmFibGUgaW50ZXJvcC4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KRnJv bTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEtlbnQgV2F0 c2VuDQpTZW50OiAyNyBGZWJydWFyeSAyMDE5IDE4OjE3DQpUbzogSnVlcmdlbiBTY2hvZW53YWVs ZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQpDYzogbmV0bW9kQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gT2Jzb2xldGUgZmVhdHVyZSAtIHdoYXQgZG9l cyBpdCBtZWFuPw0KDQoNCg0KDQpPbiBGZWIgMjcsIDIwMTksIGF0IDExOjQ4IEFNLCBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWls dG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQoNCk9uIFdl ZCwgRmViIDI3LCAyMDE5IGF0IDA0OjA5OjE3UE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0K DQoNCg0KDQpPbiBGZWIgMjcsIDIwMTksIGF0IDY6MTYgQU0sIEJhbMOhenMgTGVuZ3llbCA8YmFs YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j b20+PiB3cm90ZToNCg0KZmVhdHVyZSBvbGRGZWF0dXJlIHsNCiBzdGF0dXMgb2Jzb2xldGU7DQp9 DQpsZWFmIG15VGltZXIgew0KIGlmLWZlYXR1cmUgb2xkRmVhdHVyZSA7DQogbWFuZGF0b3J5IHRy dWU7DQogY29uZmlnIHRydWU7DQogc3RhdHVzIGN1cnJlbnQ7DQogdHlwZSBzdHJpbmc7DQp9DQpT byBzaG91bGQgSSBjb25maWd1cmUgbXlUaW1lciBvciBub3Q/IEkgYXNzdW1lIHllcywgY29ycmVj dD8NCg0KVGhpcyBpc3N1ZSBpcyBjYXB0dXJlZCBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vbmV0 bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMvMjcsIHdoaWNoIHdhcyB1cGRhdGVkIGFzIG9mIHRoaXMg bW9ybmluZyB3aXRoIHRoaXMgdmVyeSBleGFtcGxlLg0KDQpPZiBjb3Vyc2UsIHRoZSBwcm9ibGVt IGlzIGluIFJGQyA3OTUwOg0KDQogIG8gICJvYnNvbGV0ZSIgbWVhbnMgdGhhdCB0aGUgZGVmaW5p dGlvbiBpcyBvYnNvbGV0ZSBhbmQgU0hPVUxEIE5PVCBiZQ0KICAgICBpbXBsZW1lbnRlZCBhbmQv b3IgY2FuIGJlIHJlbW92ZWQgZnJvbSBpbXBsZW1lbnRhdGlvbnMuDQoNCkkgcmVjb21tZW5kIHJl cGxhY2luZyAiU0hPVUxEIE5PVCBiZSBpbXBsZW1lbnRlZCIgd2l0aCAiaXMgbm90IGltcGxlbWVu dGVkIi4NCg0KV2hlbiBhbiBJRVRGIFdHIGRlY2lkZXMgdG8gb2Jzb2xldGUgc29tZXRoaW5nLCBJ IGFtIGZvcmNlZCB0byBicmVhaw0Kb2xkIGNsaWVudHMgYmVjYXVzZSBvZiB0aGlzIGRlY2lzaW9u PyBOb3RlIHN1cmUgdGhpcyBtYWtlcyBidXNpbmVzcw0Kc2Vuc2UgKHNheXMgYW4gYWNhZGVtaWMp Lg0KDQpUaGVyZSBpcyBhIGh1Z2UgZGlmZmVyZW5jZSBiZXR3ZWVuIG1vZHVsZXMgd2hlcmUgdGhl IGltcGxlbWVudG9ycyBoYXZlDQpjaGFuZ2UgY29udHJvbCBvdmVyIHRoZSBtb2R1bGVzIGFuZCBt b2R1bGVzIHdoZXJlIGNoYW5nZSBjb250cm9sIGlzDQpmYXIgb3V0c2lkZSB0aGUgaW1wbGVtZW50 b3JzIGhhbmRzIGFuZCB3aGVyZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIGFyZQ0KaW1wbGVtZW50ZWQg YnkgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMgaW4gYW4gb3BlbiBhbmQgbGFyZ2VseQ0KdW5jb29y ZGluYXRlZCB3YXkuIFdlIGFsd2F5cyBoYXZlIHRvIGtlZXAgdGhpcyBpbiBtaW5kIHdoZW4gd2Ug Y3JlYXRlDQpydWxlcy4NCg0KVGhlIFNIT1VMRCBOT1QgYWxsb3dzIGEgc2VydmVyIGltcGxlbWVu dG9yIHRvIHRha2UgYSB3ZWxsLWluZm9ybWVkDQpkZWNpc2lvbiB0aGF0IHRoZXJlIGFyZSBvbGQg Y2xpZW50cyB5b3UgY2FyZSBhYm91dCBhbmQgdGhhdCB0aGlzIG1ha2VzDQphIGJ1c2luZXNzIGNh c2UgZm9yIHN1cHBvcnRpbmcgb2Jzb2xldGUgZGVmaW5pdGlvbnMgb24gYSBzZXJ2ZXIuDQoNCkFu b3RoZXIgYXNwZWN0IGhlcmUgaXMgdGhhdCB3ZSBkbyBub3QgbWFrZSBhIGNsZWFyIGRpc3RpbmN0 aW9uIGJldHdlZW4NCnNlcnZlciBhbmQgY2xpZW50LiBJdCBjYW4gdmVyeSB3ZWxsIGJlIHRoYXQg ImRlcHJlY2F0ZWQiIGFuZA0KIm9ic29sZXRlIiBtZWFuIHNsaWdodGx5IGRpZmZlcmVudCB0aGlu Z3MgdG8gc2VydmVycyBhbmQNCmNsaWVudHMuIChTZXJ2ZXJzIHRlbmQgdG8gaGF2ZSBhIG5hdHVy YWwgZGVzaXJlIHRvIG5vdCBicmVhayBjbGllbnRzDQp1bm5lY2Vzc2FyaWx5LikNCg0KDQoNCkJ1 dCBhIHNlcnZlciBjYW4gY2hvb3NlIHRvIG5vdCBpbXBsZW1lbnQgdGhhdCByZXZpc2lvbiBvZiB0 aGUgbW9kdWxlIG9yLCB3aXRoIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0 L2lzc3Vlcy82MyBkZXZpYXRlIHRoZSAic3RhdHVzIiBzdGF0ZW1lbnQuDQoNCkkgd2FudCAib2Jz b2xldGUiIHRvIG1lYW4gYXMgaXQgZG9lcyBldmVyeXdoZXJlIGVsc2U6IG91dCBvZiB1c2UsIG5v IGxvbmdlciBzdXBwb3J0ZWQsIG5vdCBleHBlY3RlZCB0byB3b3JrLCBldGMuDQoNClBlcmhhcHMg dGhlcmUgaXMgYSBsaW5lIGJldHdlZW4gaGF2aW5nICJzdGF0dXMgb2Jzb2xldGUiIHZlcnN1cyBk aXNhcHBlYXJpbmcgdGhlIG5vZGUgYWx0b2dldGhlcj8gICBNYXliZSB3aXRoaW4gdGhlIHNhbWUg Im1ham9yIiB2ZXJzaW9uICh0byB1c2UgYSBzZW0tdmVyIHRlcm0pLCAib2Jzb2xldGUiIGxlYXZl cyBpdCB0byB0aGUgc2VydmVyJ3MgZGlzY3JldGlvbiwgd2hlcmVhcyB0aGUgbmV4dCBtYWpvciB2 ZXJzaW9uIGRpc2FwcGVhcnMgdGhlIG5vZGU/DQoNCklmIHNvLCB0aGVuIHRoZXJlIHNob3VsZCBi ZSBhIHdheSBmb3IgdGhlIHNlcnZlciB0byBpbmRpY2F0ZSB3aGljaCBkaXNjcmV0aW9uYXJ5IGNo b2ljZXMgaXQgbWFkZS4gICBJJ2Qgc3VnZ2VzdCB0aGF0ICJvYnNvbGV0ZSIgZGVmYXVsdHMgdG8g Im5vdC1pbXBsZW1lbnRlZCIgYW5kIHRodXMgb25seSBzZXJ2ZXJzIHRoYXQgd2FudCB0byBjb250 aW51ZSBzdXBwb3J0IGZvciB0aGUgbm9kZSBuZWVkIHRvIGluZGljYXRlIGFueXRoaW5nLiAgQSBk ZXZpYXRpb24gd291bGQgYmUgYSBnb29kIGZpdCBmb3IgdGhpcy4NCg0KS2VudCAvLyBjb250cmli dXRvcg0KDQoNCg0KDQo= --_000_8277e305020d474294a09cb774eedee4XCHRCD007ciscocom_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5VbmZvcnR1bmF0ZWx5IGEgZGV2aWF0aW9uIGlzIG5vdCBhIGdvb2QgZml0 IHRvIG1hcmsgdGhhdCBhbiBvYnNvbGV0ZSBub2RlIGlzIGltcGxlbWVudGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXNzdW1pbmcgdGhhdCBJ4oCZbSByZWFkaW5n IFJGQyA3OTUwIGNvcnJlY3RseSwgaXQgZG9lc27igJl0IGFsbG93IHlvdSB0byDigJxkZXZpYXRl IGFkZOKAnSBhIGRhdGEgbm9kZSwgbm9yIGNhbiB5b3UgY2hhbmdlIHRoZSBzdGF0dXMgKGUuZy4N CiBmcm9tIG9ic29sZXRlIHRvIGRlcHJlY2F0ZWQpLiZuYnNwOyBTbywgSSB0aGluayB0aGF0IHdl IHdvdWxkIG5lZWQgdG8gY2hhbmdlIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGRldmlhdGUgc3Rh dGVtZW50IGluIFlBTkcgTmV4dCBpZiB3ZSB3YW50ZWQgdG8gZ28gZG93biB0aGlzIHBhdGguJm5i c3A7IEFsdGhvdWdoLCBJ4oCZbSBub3QgYWN0dWFsbHkgY29udmluY2VkIHRoYXQgaXQgaXMgcmVh bGx5IHJlcXVpcmVkL2hlbHBmdWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5NeSB0aG91Z2h0cyBvbiB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+MSkgRGVwcmVjYXRlZCBub2RlcyBzaG91bGQgYWx3YXlzIGJlIGltcGxlbWVudGVk LCBpLmUuIGVmZmVjdGl2ZWx5IGhhbmRsZWQgdGhlIHNhbWUgYXMgaWYgdGhleSB3ZXJlIHN0YXR1 cyAmcXVvdDtjdXJyZW50JnF1b3Q7IGJ1dCBhbm5vdGF0ZWQNCiB0aGF0IHRoZXkgd2lsbCBkaXNh cHBlYXIgaW4gZnV0dXJlLiBQZXJoYXBzIHRoaXMgY2FuIGJlIGNoYW5nZWQgYnkgZml4aW5nIHRo ZSBsYW5ndWFnZSAoZS5nLiBpbiBZQU5HIE5leHQpIGFuZC9vciB0aHJvdWdoIGEgJnF1b3Q7ZGVw cmVjYXRlZC1ub2Rlcy1pbXBsZW1lbnRlZCZxdW90OyBsZWFmIHJlcG9ydGVkIGluIFlBTkcgbGli cmFyeSAoZS5nLiBpbiB0aGUgU2VtdmVyIGRyYWZ0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjIpIE9ic29sZXRlZCBub2RlcyBTSE9VTEQgTk9UIGJlIHVzZWQgYnkg YSBjbGllbnQsIGFuZCBTSE9VTEQgTk9UIGJlIGltcGxlbWVudGVkIGJ5IGEgc2VydmVyLiZuYnNw OyBJIHRoaW5rIHRoYXQgUkZDIDc5NTAgcHJldHR5IG11Y2ggc2F5cw0KIHRoaXMgdG9kYXkgYW55 d2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkb24ndCB0aGlu ayB0aGF0IGl0IGhlbHBzIHRvIGZvcmNlIGEgc2VydmVyIHRvIHJlbW92ZSB0aGVtLiAmbmJzcDtU aGUgU2VtdmVyIGRyYWZ0IGFsc28gaGFzIGEgbGVhZiB0byBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5v dCBhbGwgb2Jzb2xldGUNCiBub2RlcyBhcmUgaW1wbGVtZW50ZWQsIGJ1dCBJJ20gbm90IHRoYXQg Y29udmluY2VkIHRoYXQgaXQgaXMgdHJ1bHkgdXNlZnVsLiZuYnNwOyBJbiB0aGF0IEkgdGhpbmsg dGhhdCB0aGUgcnVsZXMgYWJvdmUgc3RpbGwgZ2l2ZSBpbXBsZW1lbnRhdGlvbiBmbGV4aWJpbGl0 eSBidXQgc2hvdWxkIHN0aWxsIGJlIHN1ZmZpY2llbnQgZm9yIHJlYXNvbmFibGUgaW50ZXJvcC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8YnI+DQpSb2I8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IG5ldG1vZCAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYg T2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+IDI3IEZlYnJ1YXJ5IDIwMTkgMTg6 MTc8YnI+DQo8Yj5Ubzo8L2I+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Ozxicj4NCjxiPkNjOjwvYj4gbmV0bW9kQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBPYnNvbGV0ZSBmZWF0dXJlIC0g d2hhdCBkb2VzIGl0IG1lYW4/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+T24gRmViIDI3LCAyMDE5LCBhdCAxMTo0OCBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVy ICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl Ij5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFdlZCwgRmViIDI3LCAy MDE5IGF0IDA0OjA5OjE3UE0gJiM0MzswMDAwLCBLZW50IFdhdHNlbiB3cm90ZTo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIEZlYiAyNywgMjAxOSwg YXQgNjoxNiBBTSwgQmFsw6F6cyBMZW5neWVsICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmxl bmd5ZWxAZXJpY3Nzb24uY29tIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQpmZWF0dXJlIG9sZEZlYXR1cmUgezxicj4NCiZuYnNwO3N0YXR1cyBv YnNvbGV0ZTs8YnI+DQp9PGJyPg0KbGVhZiBteVRpbWVyIHs8YnI+DQombmJzcDtpZi1mZWF0dXJl IG9sZEZlYXR1cmUgOzxicj4NCiZuYnNwO21hbmRhdG9yeSB0cnVlOzxicj4NCiZuYnNwO2NvbmZp ZyB0cnVlOzxicj4NCiZuYnNwO3N0YXR1cyBjdXJyZW50Ozxicj4NCiZuYnNwO3R5cGUgc3RyaW5n Ozxicj4NCn08YnI+DQpTbyBzaG91bGQgSSBjb25maWd1cmUgbXlUaW1lciBvciBub3Q/IEkgYXNz dW1lIHllcywgY29ycmVjdD88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NClRoaXMgaXNzdWUg aXMgY2FwdHVyZWQgaGVyZTogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy95 YW5nLW5leHQvaXNzdWVzLzI3Ij4NCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1u ZXh0L2lzc3Vlcy8yNzwvYT4sIHdoaWNoIHdhcyB1cGRhdGVkIGFzIG9mIHRoaXMgbW9ybmluZyB3 aXRoIHRoaXMgdmVyeSBleGFtcGxlLjxicj4NCjxicj4NCk9mIGNvdXJzZSwgdGhlIHByb2JsZW0g aXMgaW4gUkZDIDc5NTA6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDsmcXVvdDtvYnNv bGV0ZSZxdW90OyBtZWFucyB0aGF0IHRoZSBkZWZpbml0aW9uIGlzIG9ic29sZXRlIGFuZCBTSE9V TEQgTk9UIGJlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW1wbGVtZW50ZWQg YW5kL29yIGNhbiBiZSByZW1vdmVkIGZyb20gaW1wbGVtZW50YXRpb25zLjxicj4NCjxicj4NCkkg cmVjb21tZW5kIHJlcGxhY2luZyAmcXVvdDtTSE9VTEQgTk9UIGJlIGltcGxlbWVudGVkJnF1b3Q7 IHdpdGggJnF1b3Q7aXMgbm90IGltcGxlbWVudGVkJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PGJyPg0KV2hlbiBhbiBJRVRGIFdHIGRlY2lkZXMgdG8gb2Jzb2xldGUgc29tZXRoaW5nLCBJ IGFtIGZvcmNlZCB0byBicmVhazxicj4NCm9sZCBjbGllbnRzIGJlY2F1c2Ugb2YgdGhpcyBkZWNp c2lvbj8gTm90ZSBzdXJlIHRoaXMgbWFrZXMgYnVzaW5lc3M8YnI+DQpzZW5zZSAoc2F5cyBhbiBh Y2FkZW1pYykuPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBodWdlIGRpZmZlcmVuY2UgYmV0d2VlbiBt b2R1bGVzIHdoZXJlIHRoZSBpbXBsZW1lbnRvcnMgaGF2ZTxicj4NCmNoYW5nZSBjb250cm9sIG92 ZXIgdGhlIG1vZHVsZXMgYW5kIG1vZHVsZXMgd2hlcmUgY2hhbmdlIGNvbnRyb2wgaXM8YnI+DQpm YXIgb3V0c2lkZSB0aGUgaW1wbGVtZW50b3JzIGhhbmRzIGFuZCB3aGVyZSBjbGllbnRzIGFuZCBz ZXJ2ZXJzIGFyZTxicj4NCmltcGxlbWVudGVkIGJ5IGRpZmZlcmVudCBvcmdhbml6YXRpb25zIGlu IGFuIG9wZW4gYW5kIGxhcmdlbHk8YnI+DQp1bmNvb3JkaW5hdGVkIHdheS4gV2UgYWx3YXlzIGhh dmUgdG8ga2VlcCB0aGlzIGluIG1pbmQgd2hlbiB3ZSBjcmVhdGU8YnI+DQpydWxlcy48YnI+DQo8 YnI+DQpUaGUgU0hPVUxEIE5PVCBhbGxvd3MgYSBzZXJ2ZXIgaW1wbGVtZW50b3IgdG8gdGFrZSBh IHdlbGwtaW5mb3JtZWQ8YnI+DQpkZWNpc2lvbiB0aGF0IHRoZXJlIGFyZSBvbGQgY2xpZW50cyB5 b3UgY2FyZSBhYm91dCBhbmQgdGhhdCB0aGlzIG1ha2VzPGJyPg0KYSBidXNpbmVzcyBjYXNlIGZv ciBzdXBwb3J0aW5nIG9ic29sZXRlIGRlZmluaXRpb25zIG9uIGEgc2VydmVyLjxicj4NCjxicj4N CkFub3RoZXIgYXNwZWN0IGhlcmUgaXMgdGhhdCB3ZSBkbyBub3QgbWFrZSBhIGNsZWFyIGRpc3Rp bmN0aW9uIGJldHdlZW48YnI+DQpzZXJ2ZXIgYW5kIGNsaWVudC4gSXQgY2FuIHZlcnkgd2VsbCBi ZSB0aGF0ICZxdW90O2RlcHJlY2F0ZWQmcXVvdDsgYW5kPGJyPg0KJnF1b3Q7b2Jzb2xldGUmcXVv dDsgbWVhbiBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzIHRvIHNlcnZlcnMgYW5kPGJyPg0KY2xp ZW50cy4gKFNlcnZlcnMgdGVuZCB0byBoYXZlIGEgbmF0dXJhbCBkZXNpcmUgdG8gbm90IGJyZWFr IGNsaWVudHM8YnI+DQp1bm5lY2Vzc2FyaWx5Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJ1dCBhIHNl cnZlciBjYW4gY2hvb3NlIHRvIG5vdCBpbXBsZW1lbnQgdGhhdCByZXZpc2lvbiBvZiB0aGUgbW9k dWxlIG9yLCB3aXRoDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmct bmV4dC9pc3N1ZXMvNjMiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0L2lz c3Vlcy82MzwvYT4mbmJzcDtkZXZpYXRlIHRoZSAmcXVvdDtzdGF0dXMmcXVvdDsgc3RhdGVtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIHdh bnQgJnF1b3Q7b2Jzb2xldGUmcXVvdDsgdG8gbWVhbiBhcyBpdCBkb2VzIGV2ZXJ5d2hlcmUgZWxz ZTogb3V0IG9mIHVzZSwgbm8gbG9uZ2VyIHN1cHBvcnRlZCwgbm90IGV4cGVjdGVkIHRvIHdvcmss IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ UGVyaGFwcyB0aGVyZSBpcyBhIGxpbmUgYmV0d2VlbiBoYXZpbmcgJnF1b3Q7c3RhdHVzIG9ic29s ZXRlJnF1b3Q7IHZlcnN1cyBkaXNhcHBlYXJpbmcgdGhlIG5vZGUgYWx0b2dldGhlcj8gJm5ic3A7 IE1heWJlIHdpdGhpbiB0aGUgc2FtZSAmcXVvdDttYWpvciZxdW90OyB2ZXJzaW9uICh0byB1c2Ug YSBzZW0tdmVyIHRlcm0pLCAmcXVvdDtvYnNvbGV0ZSZxdW90OyBsZWF2ZXMgaXQgdG8gdGhlIHNl cnZlcidzIGRpc2NyZXRpb24sDQogd2hlcmVhcyB0aGUgbmV4dCBtYWpvciB2ZXJzaW9uIGRpc2Fw cGVhcnMgdGhlIG5vZGU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPklmIHNvLCB0aGVuIHRoZXJlIHNob3VsZCBiZSBhIHdheSBmb3IgdGhlIHNlcnZl ciB0byBpbmRpY2F0ZSB3aGljaCBkaXNjcmV0aW9uYXJ5IGNob2ljZXMgaXQgbWFkZS4gJm5ic3A7 IEknZCBzdWdnZXN0IHRoYXQgJnF1b3Q7b2Jzb2xldGUmcXVvdDsgZGVmYXVsdHMgdG8gJnF1b3Q7 bm90LWltcGxlbWVudGVkJnF1b3Q7IGFuZCB0aHVzIG9ubHkgc2VydmVycyB0aGF0IHdhbnQgdG8g Y29udGludWUgc3VwcG9ydA0KIGZvciB0aGUgbm9kZSBuZWVkIHRvIGluZGljYXRlIGFueXRoaW5n LiAmbmJzcDtBIGRldmlhdGlvbiB3b3VsZCBiZSBhIGdvb2QgZml0IGZvciB0aGlzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+S2VudCAv LyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_8277e305020d474294a09cb774eedee4XCHRCD007ciscocom_-- From nobody Thu Feb 28 01:55:02 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 90959130E94 for ; Thu, 28 Feb 2019 01:55:00 -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 RXSuxVTSfZvX for ; Thu, 28 Feb 2019 01:54:58 -0800 (PST) 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 78B7A130E6B for ; Thu, 28 Feb 2019 01:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1914; q=dns/txt; s=iport; t=1551347698; x=1552557298; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vKKQ5G02nfJvxplJ8C++lUkPG4rQsPEIao81iNcYPu0=; b=ZiCdhYMgMtiEY57tblZbePhZ+Pb8bIaXbLctS8Ye2dTrlKGxXK5/TnAw 2MoChPs535imIA5Svf0MQ3dyTFFXcC4BWAo0RAsRqJMaND1cTn2In0WrR L97ZI2s4r7xGxT9onF7osFaz6R2M2MBUtaz/mH3Lvik4KewGO3+wD+uj3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAir3dc/4oNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCBIFrJwqDfogai02CDZgggXsLAQGEbAIXg3k?= =?us-ascii?q?iNAkNAQMBAQMBAwJtKIVKAQEBAwEjEUoHBAIBCA4DBAEBAQICJgICAjAVCAg?= =?us-ascii?q?CBAESCIUDCKwTgS+KK4ELiz0XgUA/g241gUGDV4JzglcCihSCKJcuCQKLM4c?= =?us-ascii?q?tIZMcil2SFwIRFIEoHziBVnAVO4JskF1BMZEtgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,423,1544486400"; d="scan'208";a="240690478" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 09:54:57 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x1S9svgn023855 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Feb 2019 09:54:57 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.1395.4; Thu, 28 Feb 2019 03:54:57 -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.1395.000; Thu, 28 Feb 2019 03:54:57 -0600 From: "Rob Wilton (rwilton)" To: Robert Varga , "netmod@ietf.org" Thread-Topic: [netmod] RFC7952 JSON streaming decoding efficiency? Thread-Index: AQHUzuuJVNQCQ66ge0a+WQBULprZtqX08KGAgABrEoD//5yWEA== Date: Thu, 28 Feb 2019 09:54:57 +0000 Message-ID: References: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> <822cb25f1b894be9953a49ae12c91df9@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.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netmod] RFC7952 JSON streaming decoding efficiency? 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 Feb 2019 09:55:01 -0000 QnJvYWRseSBzb3VuZHMgbGlrZSBhIHJlYXNvbmFibGUgaWRlYSB0byBtZSwgYnV0IEkgc3VzcGVj dCB0aGF0IG90aGVycyBtYXkgYXJndWUgdGhhdCB5b3UgYXJlIGp1c3QgY3JlYXRpbmcgYSBuZXcg SlNPTiBsaWtlIGxhbmd1YWdlLg0KDQpJZiB3ZSB3ZXJlIHRvIGludmVzdGlnYXRlIGFueXRoaW5n IGxpa2UgdGhpcywgdGhlbiBpdCBtaWdodCBhbHNvIGJlIGEgZ29vZCBpZGVhIHRvIGNvbnNpZGVy IHRoZSBvcmRlcmluZyBvZiBsaXN0IGtleXMgd2l0aGluIGEgbGlzdCBlbnRyeSAoaS5lLiBwdXQg dGhlbSBmaXJzdCkuDQoNClRoYW5rcywNClJvYg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBSb2JlcnQgVmFyZ2EgPG5pdGVAaHEuc2s+IA0KU2VudDogMjggRmVicnVhcnkg MjAxOSAwOTo0Ng0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47 IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFJGQzc5NTIgSlNPTiBzdHJl YW1pbmcgZGVjb2RpbmcgZWZmaWNpZW5jeT8NCg0KT24gMjgvMDIvMjAxOSAxMDoyOSwgUm9iIFdp bHRvbiAocndpbHRvbikgd3JvdGU6DQo+IEhpIFJvYmVydCwNCg0KSGV5IFJvYiwNCg0KPiBJc24n dCB0aGlzIGp1c3QgYSBsaW1pdGF0aW9uIG9mIEpTT04sIGluIHRoYXQgdGhlIGVsZW1lbnRzIGlu IGFuIG9iamVjdCBhcmUgdW5vcmRlcmVkIChSRkMgODI1OSk/DQoNClllcywgYnV0IEkgYmVsaWV2 ZSB0aGlzIGlzIG9iamVjdCBzZW1hbnRpY3MgbGVha2luZyB0byBvbi13aXJlIGZvcm1hdDoNCndo aWxlIGEgSlNPTiBvYmplY3QgaXMgaW5oZXJlbnRseSB1bm9yZGVyZWQsIHdoZW4gZW1pdHRpbmcg b2JqZWN0IHRvIHRoZSB3aXJlLCBpbXBsZW1lbnRhdGlvbnMgY2FuIGNob29zZSB0byBvcmRlciB0 aGUgcGFpcnMgdG8gbWFrZSByZWNlaXZlci1zaWRlIHByb2Nlc3NpbmcgbW9yZSBlZmZpY2llbnQu DQoNCkkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIG9mIHZhbHVlIHRvIGNvbW11bmljYXRlIHN1Y2gg YXNzdW1wdGlvbnMgb3V0IG9mIGJhbmQsIGxpa2Ugc2VwYXJhdGUgY29udGVudC10eXBlcy4gSW4g Y2FzZSBvZiBSRkM3OTUyIHRoZSBmb2xsb3dpbmcgaGludHMgd291bGQgYmUgdXNlZnVsOg0KLSB0 aGUgZG9jdW1lbnQgZG9lcyBub3QgY29udGFpbiBtZXRhZGF0YSAoaS5lLiBwbGFpbiBSRkM3OTUx KQ0KLSAiQCIgb2NjdXJzIGFzIGEgZmlyc3QgZWxlbWVudCBpbiBhbiBvYmplY3Qgb3Igbm90IGF0 IGFsbA0KLSAiQGZvbyIgb2NjdXJzIGltbWVkaWF0ZWx5IGFmdGVyICJmb28iIG9yIG5vdCBhdCBh bGwNCg0KVGhpcywgb2YgY291cnNlLCB3b3VsZCBiZSBwdXJlbHkgb3B0aW9uYWwgb3B0aW1pemF0 aW9uLi4uDQoNClJlZ2FyZHMsDQpSb2JlcnQNCg0K From nobody Thu Feb 28 03:53: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 86264130E9C for ; Thu, 28 Feb 2019 03:53:13 -0800 (PST) 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 pPugQelTUtXZ for ; Thu, 28 Feb 2019 03:53:10 -0800 (PST) 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 D33C2130EA5 for ; Thu, 28 Feb 2019 03:53:09 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a744:2697:a0ec:a420]) by mail.nic.cz (Postfix) with ESMTPSA id D3F9B60134 for ; Thu, 28 Feb 2019 12:53:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1551354785; bh=C8Wn15frkQ9JdJ3Pn3ZNd3AIi5BSW/Cr/XALNoo5SXU=; h=From:To:Date; b=EALKj5tpHi4KMz4G5O1Gerf/DMwVK6Yq6yvir9/4QXJalRu+B3TisbTurNFTpqN9t pXkWgDp/eRxkC1+6W7e/oCH1yuUUmJEgBuNcEEtE0f8Nxm2AHtqlXIE4/pGPv/BiFu hT2xbNYMIDs0t4pZqUsDpM7ZLNSKSFKWxDYB5FnU= Message-ID: From: Ladislav Lhotka To: netmod@ietf.org Date: Thu, 28 Feb 2019 12:53:05 +0100 In-Reply-To: References: <022ede1d-a195-21db-f0b6-0c299a935f42@hq.sk> <822cb25f1b894be9953a49ae12c91df9@XCH-RCD-007.cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 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] RFC7952 JSON streaming decoding efficiency? 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 Feb 2019 11:53:13 -0000 Hi Robert, On Thu, 2019-02-28 at 10:46 +0100, Robert Varga wrote: > On 28/02/2019 10:29, Rob Wilton (rwilton) wrote: > > Hi Robert, > > Hey Rob, > > > Isn't this just a limitation of JSON, in that the elements in an object are > > unordered (RFC 8259)? > > Yes, but I believe this is object semantics leaking to on-wire format: > while a JSON object is inherently unordered, when emitting object to the > wire, implementations can choose to order the pairs to make > receiver-side processing more efficient. While this is possible in principle, it would require custom serializers/deserializers, at least in some programming languages. We tried to adhere to I-JSON [RFC 7494] that states: "The order of object members in an I-JSON message does not change the meaning of an I-JSON message." JSON has other issues when it comes to streaming, so perhaps it would be better to use another representation. Lada > > I wonder if it would be of value to communicate such assumptions out of > band, like separate content-types. In case of RFC7952 the following > hints would be useful: > - the document does not contain metadata (i.e. plain RFC7951) > - "@" occurs as a first element in an object or not at all > - "@foo" occurs immediately after "foo" or not at all > > This, of course, would be purely optional optimization... > > Regards, > 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 Thu Feb 28 07:38:47 2019 Return-Path: <0100016934c1c894-a7e84667-601b-4449-b375-3bfaf9200ba7-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 5FBF7130F23 for ; Thu, 28 Feb 2019 07:38:34 -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 JF2NTXKDInC6 for ; Thu, 28 Feb 2019 07:38:30 -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 7ED75130F25 for ; Thu, 28 Feb 2019 07:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1551368309; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=sRLq5fM96Sar+UfUeC7LVhwj7sgFD5xEVgIpTYnz1Wc=; b=LvbINzQctievxnpaqYwKIbPaWDXsVZqh+t/q4IyCWJoeHKZvNWCKj/Vc+MXbAaYe rCh6VbzvVTylSySHa4z8O8y3jiDmjzq1HRyI0K/SAj/HWXBa7A2im/AjrElVKBY6xTh Y4ruV2NWetf/Sri/WUlS/ac4siYFQ740BDFvs+JQ= From: Kent Watsen Message-ID: <0100016934c1c894-a7e84667-601b-4449-b375-3bfaf9200ba7-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F916CFC-85F8-47CA-93F9-D69201D41767" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 28 Feb 2019 15:38:28 +0000 In-Reply-To: <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> Cc: NETMOD Working Group To: Christian Hopps References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.02.28-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES 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: Thu, 28 Feb 2019 15:38:45 -0000 --Apple-Mail=_3F916CFC-85F8-47CA-93F9-D69201D41767 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a neat draft. Reminds me of when I worked on the Virtual = Reality and real-time simulations. I once wrote a class to convert locations, = vectors, and orientations to and from WGS84 geocentric coordinate space and = topocentric coordinate space systems. I was fresh out of college with a Math = degree, so of course they gave it to the new guy (me) to figure out ;) Anyway, while WGS84 appears to still be applicable, it looks like a lot = of other standards work has occurred since. I'd have to dig into it to provide = a deeper comment. =46rom a gap-perspective, it seems that this module covers = locations, but not vectors or orientations (intentional?) Note: "heading" defines a = value in just a single dimension, so doesn't work for VR. =46rom an = add-perspective, I'm surprised to see "speed" included here, at least we always had 1st (and = 2nd) order temporal information defined elsewhere. Kent // contributor > On Feb 27, 2019, at 9:39 PM, Christian Hopps = wrote: >=20 > FYI. >=20 >> Begin forwarded message: >>=20 >> 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 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : YANG Geo Location >> Author : Christian Hopps >> Filename : draft-chopps-netmod-geo-location-00.txt >> Pages : 17 >> Date : 2019-02-26 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/ = >>=20 >> 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 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_3F916CFC-85F8-47CA-93F9-D69201D41767 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is a neat draft.   Reminds me of when I worked on the Virtual = Reality and
real-time simulations.    I once = wrote a class to convert locations, vectors, and
orientations to and from WGS84 geocentric coordinate = space and topocentric
coordinate space systems. =   I was fresh out of college with a Math degree, so
of course they gave it to the new guy (me) to figure out =  ;)

Anyway, while WGS84 appears to still be applicable, it looks = like a lot of other
standards work has occurred = since.   I'd have to dig into it to provide a deeper
comment.   =46rom a gap-perspective, it seems that this = module covers locations,
but not vectors or = orientations (intentional?) Note: "heading" defines a value in
just a single dimension, so doesn't work for VR.   =46rom = an add-perspective, I'm
surprised to see "speed" = included here, at least we always had 1st (and 2nd)
order temporal information defined elsewhere.

Kent // = contributor


On Feb = 27, 2019, at 9:39 PM, Christian Hopps <chopps@chopps.org> = 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: <i-d-announce@ietf.org>
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-locati= on/

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-l= ocation-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

= --Apple-Mail=_3F916CFC-85F8-47CA-93F9-D69201D41767-- From nobody Thu Feb 28 09:10: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 574DB130EBE for ; Thu, 28 Feb 2019 09:10: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 3O5b109df46P for ; Thu, 28 Feb 2019 09:10:26 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0D712130EB2 for ; Thu, 28 Feb 2019 09:10:26 -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 348C3604F4; Thu, 28 Feb 2019 12:10:25 -0500 (EST) References: <155121476305.848.1143308532121819978@ietfa.amsl.com> <51C97F98-F877-49D4-9250-5213A31B442D@chopps.org> <0100016934c1c894-a7e84667-601b-4449-b375-3bfaf9200ba7-000000@email.amazonses.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Kent Watsen Cc: Christian Hopps , NETMOD Working Group In-reply-to: <0100016934c1c894-a7e84667-601b-4449-b375-3bfaf9200ba7-000000@email.amazonses.com> Date: Thu, 28 Feb 2019 12:10: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: Thu, 28 Feb 2019 17:10:30 -0000 --=-=-= Content-Type: text/plain; format=flowed Kent Watsen writes: > This is a neat draft. Reminds me of when I worked on the Virtual Reality and > real-time simulations. I once wrote a class to convert locations, vectors, and > orientations to and from WGS84 geocentric coordinate space and topocentric > coordinate space systems. I was fresh out of college with a Math degree, so > of course they gave it to the new guy (me) to figure out ;) Thanks. :) > Anyway, while WGS84 appears to still be applicable, it looks like a lot of other > standards work has occurred since. I'd have to dig into it to provide a deeper > comment. From a gap-perspective, it seems that this module covers locations, > but not vectors or orientations (intentional?) Note: "heading" defines a value in > just a single dimension, so doesn't work for VR. From an add-perspective, I'm > surprised to see "speed" included here, at least we always had 1st (and 2nd) > order temporal information defined elsewhere. So yeah, there seems to be limitless amounts of work going on at least related or involving this topic. Regarding WGS84, the WGS84 geoid has been updated multiple times that's what the EGM96 and EGM08 are all about. Each one getting better at handling local gravitational variance, which affects actual sea levels. The original WGS84 was actually very inaccurate. The EGM (earth gravitational model) updates have been fixing this based on data from various satellite missions. Regarding movement: The point here is to define a geographical location -- so there is a concept of stability involved. It seemed reasonable to include relatively stable movement as well, key thing being stable (e.g., continental drift). Once you start trying to describe motion, all bets are off and we aren't really talking about geographical locations anymore. The text specifically mentions it's not trying to handle 2nd and further derivative motion (or I thought it did :) I do think I may need to add a second value to the velocity vector to handle 3d movement though as continents are actually moving in 3 dimensions (rising and sinking as well as moving on the globe). I may also need to add something to indicate the height value being relative to ground (or more). At first I thought this could be captured by a variation of the geodeditc-datum value, but on further thought I think that might not be the right solution -- we also may want to be able to specify multiple different things the height could be relative too (e.g., the ground floor or basement of a building), not just the ground itself. Orientation (e.g., the way a camera is pointed or what it's focal length is, etc) seems out of scope -- those aren't attributes of location they are describing something else. Orientation, etc, are covered with KML though. Thanks, Chris. > > Kent // contributor > > >> On Feb 27, 2019, at 9:39 PM, 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx4FgAACgkQLh2DDte4 MCXdow/+MVrspDDmPffvoHqjb3MpRW5naGZaAoEdMbtMPlfLRTX2T9vw0MWvumvw ue2kcXz6eTw6XxDH3K942CA/bK+gjBaUVPRj7RPQlLs/25j31g3sBD2Tjn7MGixE hHA5DW0eVdwIFIXXZ0F+10TexB6OwfkDB9TQhXwk3f9wZ6Sc+yjGl4cFvQeJW7P1 2RX6Sxz4+eJdJTHyJPps6sttIQgwJKX3B8K70PiGG0FgwPRIeAfiVijLc1nSf4qm kMh73S9l9nGgJNbMxjOIXp+mLFeci+vOJSKFFPQYswxqS9AfkY9z25/e7OjcvWRm k2HlPhKLyI2BrNqS00+Q5gjuk0sYBURuzgtBuoWpbKoaKPK1zf+IFydBNZyDmR3z ro3lfhuCtXbbEuhkI9ukHGKHenm8EqCq+kAyAYYgDX8CIoWDCdjEBa7+a9PUhKvb v9HTjvMmJctsm0mSP4I68BQDdk3gHYZNxeNxuFwwO8FqLTb8sHZduvUCpuarPxHZ CRthTAnOzd/8SmcYYYP7JSWcSjU8hKDZLDzVt1Pc4VvzO5CKkjedoIJ7DUacVnjv AaStQ81e/swOnWTTQ7auRDcNUFeVgNeULhXN3gS5+XMTgTmWCAhn08F45pTXJriR 0ioUx0qqw3yishkqFdZx0XA3XUb/JSQEszd+aiXS3F5qDTPEDcM= =TbXf -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 28 23:54: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 E2B34130DE9 for ; Thu, 28 Feb 2019 23:54:11 -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 7EqcGxqPRwxe for ; Thu, 28 Feb 2019 23:54:10 -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 26FE2126F72 for ; Thu, 28 Feb 2019 23:54:10 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AECD0F77899FC3C26E16 for ; Fri, 1 Mar 2019 07:54:07 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 1 Mar 2019 07:54:07 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.156]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Fri, 1 Mar 2019 15:53:54 +0800 From: Qin Wu To: NETMOD WG Thread-Topic: I-D Action: draft-wu-netmod-base-notification-nmda-02.txt Thread-Index: AdTQA6Y9ogbrdcnAQq+AvRHbhCMlNQ== Date: Fri, 1 Mar 2019 07:53:53 +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-wu-netmod-base-notification-nmda-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, 01 Mar 2019 07:54:12 -0000 SGVyZSBpcyB0aGUgdXBkYXRlIHRvIE5NREEgYmFzZSBldmVudCBkcmFmdCBiYXNlZCBvbiBkaXNj dXNzaW9uIHNpbmNlIGxhc3QgSUVURiBtZWV0aW5nDQoxLiBBZGQgbW9kdWxlIHRhZyBzdXBwb3J0 IHRvIGlkZW50aWZ5IG1hbmFnZW1lbnQgc2Vzc2lvbi4NCjIuIFJlbW92ZSB0d28gYXBwbHktaW50 ZW5kZWQtc3RhcnQgYW5kIGFwcGx5LWludGVuZGVkLWVuZCB0d28gbm90aWZpY2F0aW9ucyB3aGlj aCBhcmUgbm90IG5lZWRlZC4NClRoZSBkaWZmIGlzOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC1iYXNlLW5vdGlmaWNhdGlvbi1ubWRhLTAyDQoNCi1R aW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBJLUQtQW5ub3VuY2UgW21haWx0bzppLWQt YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcN Creiy83KsbzkOiAyMDE5xOoz1MIxyNUgMTU6NTENCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYu b3JnDQrW98ziOiBJLUQgQWN0aW9uOiBkcmFmdC13dS1uZXRtb2QtYmFzZS1ub3RpZmljYXRpb24t bm1kYS0wMi50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNCg0KICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBOTURBIEJhc2UgTm90aWZpY2F0aW9uIGZvciBBcHBsaWVkIEludGVuZGVk IENvbmZpZ3VyYXRpb24NCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUWluIFd1DQogICAgICAg ICAgICAgICAgICAgICAgICAgIENob25nIEZlbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg Um9oaXQgUiBSYW5hZGUNCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC13dS1uZXRtb2QtYmFzZS1u b3RpZmljYXRpb24tbm1kYS0wMi50eHQNCglQYWdlcyAgICAgICAgICAgOiAxNg0KCURhdGUgICAg ICAgICAgICA6IDIwMTktMDItMjgNCg0KQWJzdHJhY3Q6DQogICBUaGUgTmV0d29yayBDb25maWd1 cmF0aW9uIFByb3RvY29sIChORVRDT05GKWFuZCBSRVNUQ09ORiBwcm92aWRlcw0KICAgbWVjaGFu aXNtcyB0byBtYW5pcHVsYXRlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jlcy4gIE5NREEgaW50cm9k dWNlcw0KICAgYWRkaXRpb25hbCBkYXRhc3RvcmVzIGZvciBzeXN0ZW1zIHRoYXQgc3VwcG9ydCBt b3JlIGFkdmFuY2VkDQogICBwcm9jZXNzaW5nIGNoYWlucyBjb252ZXJ0aW5nIGNvbmZpZ3VyYXRp b24gdG8gb3BlcmF0aW9uYWwgc3RhdGUuDQogICBIb3dldmVyLCBjbGllbnQgYXBwbGljYXRpb25z IGFyZSBub3QgYWJsZSB0byBiZSBhd2FyZSBvZiBjb21tb24NCiAgIGV2ZW50cyBpbiB0aGVzZSBh ZGRpdGlvbmFsIGRhdHN0b3JlcyBvZiB0aGUgbWFuYWdlbWVudCBzeXN0ZW0sIHN1Y2gNCiAgIGFz IGEgYXBwbGllZCBjb25maWd1cmF0aW9uIHN0YXRlIGNoYW5nZSBpbiBORVRDT05GIHNlcnZlciBv ciBSRVNUQ09ORg0KICAgc2VydmVyLCB0aGF0IG1heSBpbXBhY3QgbWFuYWdlbWVudCBhcHBsaWNh dGlvbnMuICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmUgYSBZQU5HIG1vZHVsZSB0aGF0IGFsbG93 cyBhIGNsaWVudCB0byByZWNlaXZlIGFkZGl0aW9uYWwNCiAgIG5vdGlmaWNhdGlvbnMgZm9yIHNv bWUgY29tbW9uIHN5c3RlbSBldmVudHMgcGVydGFpbmluZyB0byB0aGUgTmV0d29yaw0KICAgTWFu YWdlbWVudCBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIChOTURBKSBkZWZpbmVkIGluIFtSRkM4MzQy XS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC1iYXNl LW5vdGlmaWNhdGlvbi1ubWRhLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh dmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9k LWJhc2Utbm90aWZpY2F0aW9uLW5tZGEtMDINCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWJhc2Utbm90aWZpY2F0aW9uLW5tZGEtMDINCg0KQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC1iYXNlLW5vdGlmaWNhdGlv bi1ubWRhLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFu bm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kt ZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwgb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50 eHQNCg==