From nobody Wed May 1 03:17:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE41200E0 for ; Wed, 1 May 2019 03:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk0cj26xk-5v for ; Wed, 1 May 2019 03:17:31 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9A21200B9 for ; Wed, 1 May 2019 03:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29232; q=dns/txt; s=iport; t=1556705851; x=1557915451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fLHW35YA2cSI61q0eIk5eLHcijh6eHAybtRksBVTG08=; b=G4GxZ22VogF8QrGsCQ/YFO2EARXGPvZ+KPsUx3KyuTfbhwVODxY82Qbj UtY/Ned8UnESaFT/tEkRw1Jb0DiHTSb6eJ59u0M8954WZsOm19fkBsdnu hWpxOha9IW+4ODyIU3hNUNwu4hPcUbmw6NOcYSGM6qQiOqLQ3uEi7hgxt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAscclc/4gNJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBDoECaYEEKAqEBpUvfpdSFIFnDgEBhG0CF4Y?= =?us-ascii?q?bIzUIDgEDAQEEAQECAQJtKIVKAQEBAQMjCkwQAgEGAhEEAQEhCgICAjAdCAI?= =?us-ascii?q?EDgUIE4MIgR1tkXubZYEvijaBMgGKCIFDF4FAP4ERgl01PoQsgyKCWASLBxq?= =?us-ascii?q?CI4RKh32NCAkCggmSNyOVNYNsnQECERWBMCECNIFWcBWDJ5BRQTGSS4EhAQE?= X-IronPort-AV: E=Sophos;i="5.60,417,1549929600"; d="scan'208,217";a="265805074" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 10:17:28 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x41AHSOt011370 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 10:17:28 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 05:17:27 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 1 May 2019 05:17:27 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "netconf@ietf.org" , Martin Bjorklund Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAL4+PiAAAVM54ADt02zAAAGzCgAAAQfJ4AABQvugADqhRSAAAgkE4AAKD/bgAABK6oAAAGYSwAACr5OgAAWy8EQ Date: Wed, 1 May 2019 10:17:27 +0000 Message-ID: References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> In-Reply-To: <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-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.60] Content-Type: multipart/alternative; boundary="_000_acef56d17fc64102ae24bb8fcb8c828dXCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 10:17:33 -0000 --_000_acef56d17fc64102ae24bb8fcb8c828dXCHRCD007ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KSeKAmW0gc2xpZ2h0bHkgbG9zdCBoZXJlLCBzbyBteSBjb21tZW50cyBtYXkg bm90IGJlIHRoYXQgaGVscGZ1bCDwn5iKDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBkbyB3 ZSBuZWVkIGFuIGV4cGxpY2l0IGFjdGlvbiB0byBjcmVhdGUvaW5zdGFsbCB0aGUga2V5PyAgSW4g cGFydGljdWxhciwgd2h5IGNhbuKAmXQgdGhlcmUganVzdCBiZSBhIHJlZ3VsYXIgKGludGVuZCBi YXNlZCkgY29uZmlndXJhdGlvbiBsZWFmIHRoYXQgaXMg4oCcdXNlLXN5c3RlbS1kZWZpbmVkLWtl eeKAnT8gIFRoZSBrZXkgdmFsdWVzIGNvdWxkIGJlIHJlcG9ydGVkIGluIDxpbnRlbmRlZD4gYW5k L29yIDxvcGVyYXRpb25hbD4sIHN1aXRhYmx5IHByb3RlY3RlZCB2aWEgTkFDTSwgb3IgdGhleSBj b3VsZCBiZSBrZXB0IGVudGlyZWx5IGhpZGRlbi4NCg0KSSBhbHNvIGFncmVlIHdpdGggTWFydGlu L0FuZHkgdGhhdCBpdCBpcyBoaWdobHkgZGVzaXJhYmxlIHRvIGFsbG93IGEgZGV2aWNlIHRvIGJl IGNvbmZpZ3VyZWQgd2l0aCBhIHNpbmdsZSBjb25maWd1cmF0aW9uIGlucHV0IGZpbGUsIHByb3Zp ZGVkIGZyb20gPHN0YXJ0dXA+IG9yIDxlZGl0LWNvbmZpZ3xkYXRhPi4gIEkgdGhpbmsgdGhhdCBh bnl0aGluZyB0aGF0IHdvdWxkIHJlcXVpcmUsIG9yIGVuY291cmFnZSwgbXVsdGlwbGUgUlBDIGlu dGVyYWN0aW9ucyB0byBzZXR1cCB0aGUgZGV2aWNlIHdvdWxkIHNlZW0gdG8gYmUgYSBiaWcgYmFj a3dhcmRzIHN0ZXAgaW4gdGVybXMgb2YgZGV2aWNlIG1hbmFnZW1lbnQuDQoNCknigJltIG5vdCBv cHBvc2VkIHRvIFJQQ3Mgb3IgYWN0aW9ucyB0byBtYW5hZ2UgaGlkZGVuIGtleXMgb24gdGhlIGRl dmljZSBpZjoNCg0KKGkpICAgICAgICAgICAgICAgdGhlc2UgZG9u4oCZdCBnZXQgd3JpdHRlbiB0 byA8cnVubmluZz4gKGJlY2F1c2UgdGhleSBhcmUgbm90IHJlZ3VsYXIgY29uZmlndXJhdGlvbiks IGFuZA0KDQooaWkpICAgICAgICAgICAgICB0aGVyZSBpcyBhIHNlbnNpYmxlL3NlY3VyZSBtZWNo YW5pc20gdG8gY29uZmlndXJlIHRoZSBkZXZpY2Ugd2l0aG91dCByZXF1aXJpbmcgYW55IGV4dHJh IFJQQ3MvYWN0aW9ucyB0byBjb25maWd1cmUgdGhlIGRldmljZS4gIEkuZS4gdGhlIFJQQ3MvYWN0 aW9ucyBzaG91bGQgb25seSBiZSB1c2VkIGZvciBleGNlcHRpb25hbCBtYW5hZ2VtZW50IG9mIHRo ZSBrZXlzIG9uIHRoZSBkZXZpY2UuDQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IG5ldGNvbmYg PG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50 OiAzMCBBcHJpbCAyMDE5IDE4OjU3DQpUbzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5j b20+DQpDYzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBpZXRmIGNy eXB0byB0eXBlcyAtIHBlcm1hbmVudGx5IGhpZGRlbg0KDQoNCg0KDQpJIChzdGlsbCkgb2JqZWN0 IHRvIHRoaXMuICBBY3Rpb25zIHNob3VsZG4ndCBjcmVhdGUgY29uZmlnLiAgV2UNCmFscmVhZHkg aGF2ZSBnZW5lcmljIHByb3Rjb2wgb3BlcmF0aW9ucyB0byBkbyB0aGlzLiAgV2UgZ28gZnJvbSBh DQpkb2N1bWVudC1vcmllbnRlZCBjb25maWd1cmF0aW9uIG1vZGVsIHRvd2FyZHMgYSBjb21tYW5k LW9yaWVudGVkDQptb2RlbC4gIE5vdCBnb29kLiAgSW4gUkVTVENPTkYsIHRoZSBnZW5lcmljIG1l dGhvZHMgc3VwcG9ydCB0aGluZ3MNCmxpa2UgRVRhZ3MsIHdoaWNoIEkgc3VzcGVjdCB5b3UgZG9u J3Qgd2FudCB0byByZXBsaWNhdGUgaW4gdGhpcw0KYWN0aW9uPyAgIFdpbGwgdGhlIGFjdGlvbiBz dXBwb3J0IGFsbCBlcnJvci1vcHRpb25zIG9mIGVkaXQtY29uZmlnLA0KbGlrZSByb2xsYmFjay1v bi1lcnJvcj8NCg0KVGhlIHNwZWNpZmljcyBmb3IgaG93IHRoaXMgY291bGQgd29yayB3b3VsZCBu ZWVkIHRvIGJlIGRlZmluZWQuICBHaXZlbiB0aGF0IGl0IGlzIGEgc3BlY2lhbCBjYXNlLCBJIHRo aW5rIHRoYXQgd2UgY291bGQgY29uc3RyYWluIGl0IGhlYXZpbHkgYW5kIHRhcmdldCBzaW1wbGUg c29sdXRpb24uICAgRGVwZW5kaW5nIGhvdyBtdWNoIHRleHQgaXMgcmVxdWlyZWQgdG8gZGVzY3Jp YmUgaXQsIGl0IG1pZ2h0IGJlIGdvb2QgdG8gZGVmaW5lIGFuIGV4dGVuc2lvbiBzdGF0ZW1lbnQg dGhhdCBjb3VsZCBiZSBwbGFjZWQgb24gdGhlIGFjdGlvbnMuICBXaGlsZSBhbiBleHRlbnNpb24g c3RhdGVtZW50IG1heSBzZWVtIGxpa2UgaXQgb3BlbnMgdGhlIGdhdGVzIGZvciBnZW5lcmFsIHVz ZSwgd2UgY291bGQgZnVydGhlciBkZWZpbmUgdGhlIGV4dGVuc2lvbiBzdGF0ZW1lbnQgYXMgYmVp bmcgc29tZXRoaW5nIHRoYXQgTVVTVCBOT1QgYmUgdXNlZCB3aGVuIGdlbmVyYWwgcHVycG9zZSBv cGVyYXRpb25zIGFyZSBzdWl0YWJsZSBzdWNoIHRoYXQsIGF0IGxlYXN0IHdpdGggdGhlIElFVEYs IGl0IGNvdWxkIG9ubHkgYmUgdXNlZCBpbiBleHRyYW9yZGluYXJ5IGNpcmN1bXN0YW5jZXMuDQoN Cg0KDQpTb21lIGNvbW1lbnRzIG9uIHRoZSBuZXcgdGV4dDoNCg0KSW4gYWN0aW9uIGdlbmVyYXRl LWhpZGRlbi1rZXksIGl0IHNob3VsZCBiZSBzdGF0ZWQgdGhhdCB0aGUgcHVibGljLWtleQ0Kd2ls bCBiZSBwb3B1bGF0ZWQsIGFuZCB0aGF0IHRoZSBwcml2YXRlLWtleSB3aWxsIGV4aXN0IGJ1dCBy ZXBvcnQNCidwZXJtYW5lbnRseS1oaWRkZW4nLg0KDQpPa2F5LCBidXQgYmVmb3JlIG1ha2luZyB0 aGUgZWRpdCwgc2VlIGNvbW1lbnQgYmVsb3cgYWJvdXQgbGlmZXRpbWVzLi4uDQoNCg0KDQoNCklu IGFjdGlvbiBpbnN0YWxsLWhpZGRlbi1rZXksIHNob3VsZG4ndCBib3RoIHB1YmxpYy1rZXkgYW5k DQpwcml2YXRlLWtleSBiZSBtYW5kYXRvcnk/ICBBbHNvIHN0YXRlIHRoYXQgdGhlIHByaXZhdGUt a2V5IHdpbGwgcmVwb3J0DQoncGVybWFuZW50bHktaGlkZGVuJy4NCg0KSW5kZWVkLCBmaXhlZC4N Cg0KDQoNCkluIGxlYWYgcHJpdmF0ZS1rZXksIHRoZSB0eXBlIGJpbmFyeSBwYXJ0IG9mIHRoZSB1 bmlvbiBkb2Vzbid0IGhhdmUgYQ0KZGVzY3JpcHRpb24sIGFuZCB0aGUgZGVzY3JpcHRpb24gZm9y IHRoZSBsZWFmIGl0c2VsZiBzYXlzOg0KDQogICAgICBBIGJpbmFyeSB0aGF0IGNvbnRhaW5zIHRo ZSB2YWx1ZSBvZiB0aGUgcHJpdmF0ZSBrZXkuDQoNCndoaWNoIGlzIG5vdCBxdWl0ZSBjb3JyZWN0 Lg0KDQpJIHRoaW5rIHdlIHNob3VsZCBzdGF0ZSB0aGF0IHRoZSBlbnVtICdwZXJtYW5lbnRseS1o aWRkZW4nIGlzIG9ubHkNCnJlcG9ydGVkIGluIG9wZXJhdGlvbmFsIHN0YXRlLg0KDQpUaGUgJ3R5 cGUnIHN0YXRlbWVudCBkb2Vzbid0IGhhdmUgJ2Rlc2NyaXB0aW9uJyBhcyBhIHN1YnN0YXRlbWVu dCwNCmJ1dCwgcG9pbnQgdGFrZW4sIHR3byB1cGRhdGVzOg0KDQpJbiBsZWFmIHByaXZhdGUta2V5 Og0KICBPTEQ6DQogICAgICBBIGJpbmFyeSB0aGF0IGNvbnRhaW5zIHRoZSB2YWx1ZSBvZiB0aGUg cHJpdmF0ZSBrZXkuDQogIE5FVzoNCiAgICAgIEVpdGhlciBhIGJpbmFyeSB0aGF0IGNvbnRhaW5z IHRoZSB2YWx1ZSBvZiB0aGUgcHJpdmF0ZSBrZXkgb3IsIGluDQogICAgICB0aGUgY2FzZSBvZiBh IGhpZGRlbiBrZXksIHRoZSB2YWx1ZSAncGVybWFuZW50bHktaGlkZGVuJy4NCg0KSW4gZW51bSBw ZXJtYW5lbnRseS1oaWRkZW46DQogIE9MRDoNCiAgICAgICBUaGUgcHJpdmF0ZSBrZXkgaXMgaW5h Y2Nlc3NpYmxlIGR1ZSB0byBiZWluZyBwcm90ZWN0ZWQgYnkgdGhlDQogICAgICAgc3lzdGVtIChl LmcuLCBhIGNyeXB0b2dyYXBoaWMgaGFyZHdhcmUgbW9kdWxlKS4NCiAgTkVXOg0KICAgICAgIFRo ZSBwcml2YXRlIGtleSBpcyBpbmFjY2Vzc2libGUgZHVlIHRvIGJlaW5nIHByb3RlY3RlZCBieSB0 aGUNCiAgICAgICBzeXN0ZW0gKGUuZy4sIGEgY3J5cHRvZ3JhcGhpYyBoYXJkd2FyZSBtb2R1bGUp LiAgU2luY2UgaGlkZGVuDQogICAgICAga2V5cyBhcmUgb25seSBldmVyIHJlcG9ydGVkIGluIDxv cGVyYXRpb25hbD4sIHRoZSB2YWx1ZQ0KICAgICAgICdwZXJtYW5lbnRseS1oaWRkZW4nIG5ldmVy IGFwcGVhcnMgaW4gPGludGVuZGVkPi4NCg0KDQpUaGUgbmV3IGRlc2NyaXB0aW9ucyBzYXk6DQoN CiAgICAgICAgICAgWy4uLl0gcHJlc2VudCBvbmx5IGluDQogICAgICAgICAgIDxvcGVyYXRpb25h bD4gYW5kIGJvdW5kIHRvIHRoZSBsaWZldGltZSBvZiB0aGUgcGFyZW50DQogICAgICAgICAgICdj b25maWcgdHJ1ZScgbm9kZS4NCg0KQXJlbid0IGFsbCBub2RlcyBib3VuZCB0byB0aGUgbGlmZXRp bWUgb2YgdGhlaXIgcGFyZW50Pw0KVGhlIGFjdGlvbiBpcyBpbnZva2VkIGluIGEgbm9kZSB0aGF0 IGV4aXN0cyBpbiA8b3BlcmF0aW9uYWw+IGFuZCBpdA0KY3JlYXRlcyBhIGtleS4gIFdoYXQgZG9l cyB0aGUgc3RhdGVtZW50IHRlbGwgbWU/DQoNClRoaXMgc2VlbXMgbGlrZSBzb21ldGhpbmcgbmV3 IChhbmQgbWF5YmUgd3JvbmcpIGFuZCBoZW5jZSBuZWVkcyB0byBiZSBleHBsYWluZWQuICBUaGlz IHNlZW1zIG5ldyBiZWNhdXNlIHdlIGFyZSBzYXlpbmcgdGhhdCB0aGUgbGlmZXRpbWUgb2YgYW4g b3BlcmF0aW9uYWwgdmFsdWUgaXMgdGllZCB0byB0aGUgbGlmZXRpbWUgb2YgYSBjb25maWd1cmVk IHZhbHVlLiAgTm9ybWFsbHkgd2UgdGFsayBhYm91dCBob3cgb3BlcmF0aW9uYWwgdmFsdWVzIGV4 aXN0IG9uIHRoZWlyIG93biBhbmQgdGhhdCwgaWYgb25lIHdhbnRzIHRvIG92ZXJyaWRlL2V4dGVu ZCB0aGVtIChlLmcuLCBhc3NvY2lhdGUgYSBjZXJ0aWZpY2F0ZSB0byB0aGUgcHJpdmF0ZSBrZXkg Y3JlYXRlZCBieSB0aGUgbWFudWZhY3R1cmVyKSwgY29uZmlndXJhdGlvbiB3b3VsZCBvdmVybGF5 IHRoZSBvcGVyYXRpb25hbCB2YWx1ZXMuICBCeSBleHRlbnNpb24sIGlmIHRoZSBjb25maWd1cmF0 aW9uIGlzIHJlbW92ZWQsIHRoZSBvcGVyYXRpb25hbCB2YWx1ZXMgZ28gYmFjayB0byB0aGVpciBv cmlnaW5hbCBzdGF0ZSAoaS5lLiwgZXhpc3Rpbmcgb24gdGhlaXIgb3duKS4gICBIZXJlIHdlJ3Jl IHNheWluZyB0aGF0LCBpZiB0aGUgY29uZmlndXJhdGlvbiAoZm9yIHRoZSBwYXJlbnQgbm9kZSkg aXMgcmVtb3ZlZCwgdGhlIG9wZXJhdGlvbmFsIHZhbHVlcyBhcmUgcmVtb3ZlZCBhcyB3ZWxsLg0K DQpOb3RlIHRoYXQgdGhpcyBzdGF0ZW1lbnQgd2FzIGFkZGVkIGJlY2F1c2UgSnVlcmdlbiBhc2tl ZCBhYm91dCBob3cgaGlkZGVuIGtleXMgY291bGQgYmUgcmVtb3ZlZC9yZXBsYWNlZC4gICBXZSBp dGVyYXRlZCB0b3dhcmRzIG5vdCB3YW50aW5nIHRvIHN1cHBvcnQgdGhlICJyZXBsYWNlIiBjYXNl LCBhbmQgdGhpcyBzZWVtZWQgbGlrZSBhbiBlYXN5IHdheSB0byBoYW5kbGUgdGhlICJyZW1vdmUi IGNhc2UuICBBbm90aGVyIHdheSB0byBkbyB0aGlzIHdvdWxkIGJlIHZpYSBhbm90aGVyIGFjdGlv biBzdWNoIGFzICdyZW1vdmUtaGlkZGVuLWtleScuICAgV2hhdCBkbyB5b3UgdGhpbmsgd291bGQg YmUgYmVzdD8NCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg== --_000_acef56d17fc64102ae24bb8fcb8c828dXCHRCD007ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo1NTIyMzEwOTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjcxOTczMTY3MCAxNjExMTc3NDIwIDEzNDgwNzU3NyAxMzQ4MDc1Nzkg MTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1 Nzk7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0My44cHQ7 DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjYxLjhwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0Ojk3LjhwdDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMzMuOHB0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjkuOHB0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MjA1LjhwdDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNDEuOHB0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzcuOHB0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MzEzLjhwdDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEtlbnQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPknigJltIHNsaWdodGx5IGxvc3QgaGVyZSwgc28gbXkgY29tbWVudHMgbWF5IG5vdCBi ZSB0aGF0IGhlbHBmdWwNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ JiMxMjg1MjI7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGRvIHdlIG5lZWQgYW4gZXhwbGljaXQg YWN0aW9uIHRvIGNyZWF0ZS9pbnN0YWxsIHRoZSBrZXk/Jm5ic3A7IEluIHBhcnRpY3VsYXIsIHdo eSBjYW7igJl0IHRoZXJlIGp1c3QgYmUgYSByZWd1bGFyIChpbnRlbmQgYmFzZWQpIGNvbmZpZ3Vy YXRpb24gbGVhZiB0aGF0IGlzIOKAnHVzZS1zeXN0ZW0tZGVmaW5lZC1rZXnigJ0/Jm5ic3A7DQog VGhlIGtleSB2YWx1ZXMgY291bGQgYmUgcmVwb3J0ZWQgaW4gJmx0O2ludGVuZGVkJmd0OyBhbmQv b3IgJmx0O29wZXJhdGlvbmFsJmd0Oywgc3VpdGFibHkgcHJvdGVjdGVkIHZpYSBOQUNNLCBvciB0 aGV5IGNvdWxkIGJlIGtlcHQgZW50aXJlbHkgaGlkZGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFsc28gYWdyZWUgd2l0 aCBNYXJ0aW4vQW5keSB0aGF0IGl0IGlzIGhpZ2hseSBkZXNpcmFibGUgdG8gYWxsb3cgYSBkZXZp Y2UgdG8gYmUgY29uZmlndXJlZCB3aXRoIGEgc2luZ2xlIGNvbmZpZ3VyYXRpb24gaW5wdXQgZmls ZSwgcHJvdmlkZWQgZnJvbSAmbHQ7c3RhcnR1cCZndDsgb3IgJmx0O2VkaXQtY29uZmlnfGRhdGEm Z3Q7LiZuYnNwOyBJIHRoaW5rIHRoYXQgYW55dGhpbmcNCiB0aGF0IHdvdWxkIHJlcXVpcmUsIG9y IGVuY291cmFnZSwgbXVsdGlwbGUgUlBDIGludGVyYWN0aW9ucyB0byBzZXR1cCB0aGUgZGV2aWNl IHdvdWxkIHNlZW0gdG8gYmUgYSBiaWcgYmFja3dhcmRzIHN0ZXAgaW4gdGVybXMgb2YgZGV2aWNl IG1hbmFnZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPknigJltIG5vdCBvcHBvc2VkIHRvIFJQQ3Mgb3IgYWN0aW9ucyB0 byBtYW5hZ2UgaGlkZGVuIGtleXMgb24gdGhlIGRldmljZSBpZjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQzLjhw dDt0ZXh0LWluZGVudDotMzYuMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+KGkpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPnRoZXNlIGRvbuKAmXQgZ2V0IHdyaXR0ZW4gdG8gJmx0O3J1bm5pbmcmZ3Q7 IChiZWNhdXNlIHRoZXkgYXJlIG5vdCByZWd1bGFyIGNvbmZpZ3VyYXRpb24pLCBhbmQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjQzLjhwdDt0ZXh0LWluZGVudDotMzYuMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+KGlpKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj50aGVyZSBpcyBhIHNlbnNpYmxlL3NlY3VyZSBtZWNoYW5pc20g dG8gY29uZmlndXJlIHRoZSBkZXZpY2Ugd2l0aG91dCByZXF1aXJpbmcgYW55IGV4dHJhIFJQQ3Mv YWN0aW9ucyB0byBjb25maWd1cmUgdGhlIGRldmljZS4mbmJzcDsgSS5lLiB0aGUgUlBDcy9hY3Rp b25zIHNob3VsZCBvbmx5IGJlIHVzZWQgZm9yIGV4Y2VwdGlvbmFsDQogbWFuYWdlbWVudCBvZiB0 aGUga2V5cyBvbiB0aGUgZGV2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldGNvbmYg Jmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2Vu dCBXYXRzZW48YnI+DQo8Yj5TZW50OjwvYj4gMzAgQXByaWwgMjAxOSAxODo1Nzxicj4NCjxiPlRv OjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0g aWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgKHN0aWxsKSBvYmplY3QgdG8gdGhpcy4gJm5ic3A7 QWN0aW9ucyBzaG91bGRuJ3QgY3JlYXRlIGNvbmZpZy4gJm5ic3A7V2U8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbHJlYWR5IGhhdmUg Z2VuZXJpYyBwcm90Y29sIG9wZXJhdGlvbnMgdG8gZG8gdGhpcy4gJm5ic3A7V2UgZ28gZnJvbSBh PGJyPg0KZG9jdW1lbnQtb3JpZW50ZWQgY29uZmlndXJhdGlvbiBtb2RlbCB0b3dhcmRzIGEgY29t bWFuZC1vcmllbnRlZDxicj4NCm1vZGVsLiAmbmJzcDtOb3QgZ29vZC4gJm5ic3A7SW4gUkVTVENP TkYsIHRoZSBnZW5lcmljIG1ldGhvZHMgc3VwcG9ydCB0aGluZ3M8YnI+DQpsaWtlIEVUYWdzLCB3 aGljaCBJIHN1c3BlY3QgeW91IGRvbid0IHdhbnQgdG8gcmVwbGljYXRlIGluIHRoaXM8YnI+DQph Y3Rpb24/ICZuYnNwOyZuYnNwO1dpbGwgdGhlIGFjdGlvbiBzdXBwb3J0IGFsbCBlcnJvci1vcHRp b25zIG9mIGVkaXQtY29uZmlnLDxicj4NCmxpa2Ugcm9sbGJhY2stb24tZXJyb3I/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHNwZWNpZmljcyBmb3IgaG93IHRoaXMgY291bGQgd29yayB3b3VsZCBu ZWVkIHRvIGJlIGRlZmluZWQuICZuYnNwO0dpdmVuIHRoYXQgaXQgaXMgYSBzcGVjaWFsIGNhc2Us IEkgdGhpbmsgdGhhdCB3ZSBjb3VsZCBjb25zdHJhaW4gaXQgaGVhdmlseSBhbmQgdGFyZ2V0IHNp bXBsZSBzb2x1dGlvbi4gJm5ic3A7IERlcGVuZGluZyBob3cgbXVjaCB0ZXh0IGlzIHJlcXVpcmVk IHRvIGRlc2NyaWJlIGl0LCBpdCBtaWdodCBiZSBnb29kDQogdG8gZGVmaW5lIGFuIGV4dGVuc2lv biBzdGF0ZW1lbnQgdGhhdCBjb3VsZCBiZSBwbGFjZWQgb24gdGhlIGFjdGlvbnMuICZuYnNwO1do aWxlIGFuIGV4dGVuc2lvbiBzdGF0ZW1lbnQgbWF5IHNlZW0gbGlrZSBpdCBvcGVucyB0aGUgZ2F0 ZXMgZm9yIGdlbmVyYWwgdXNlLCB3ZSBjb3VsZCBmdXJ0aGVyIGRlZmluZSB0aGUgZXh0ZW5zaW9u IHN0YXRlbWVudCBhcyBiZWluZyBzb21ldGhpbmcgdGhhdCBNVVNUIE5PVCBiZSB1c2VkIHdoZW4g Z2VuZXJhbCBwdXJwb3NlDQogb3BlcmF0aW9ucyBhcmUgc3VpdGFibGUgc3VjaCB0aGF0LCBhdCBs ZWFzdCB3aXRoIHRoZSBJRVRGLCBpdCBjb3VsZCBvbmx5IGJlIHVzZWQgaW4gZXh0cmFvcmRpbmFy eSBjaXJjdW1zdGFuY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNvbWUgY29tbWVudHMgb24gdGhlIG5ldyB0ZXh0Ojxicj4NCjxicj4N CkluIGFjdGlvbiBnZW5lcmF0ZS1oaWRkZW4ta2V5LCBpdCBzaG91bGQgYmUgc3RhdGVkIHRoYXQg dGhlIHB1YmxpYy1rZXk8YnI+DQp3aWxsIGJlIHBvcHVsYXRlZCwgYW5kIHRoYXQgdGhlIHByaXZh dGUta2V5IHdpbGwgZXhpc3QgYnV0IHJlcG9ydDxicj4NCidwZXJtYW5lbnRseS1oaWRkZW4nLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T2theSwgYnV0IGJlZm9yZSBtYWtpbmcgdGhlIGVkaXQsIHNlZSBjb21tZW50 IGJlbG93IGFib3V0IGxpZmV0aW1lcy4uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkluIGFjdGlvbiBpbnN0YWxsLWhpZGRlbi1rZXksIHNob3VsZG4n dCBib3RoIHB1YmxpYy1rZXkgYW5kPGJyPg0KcHJpdmF0ZS1rZXkgYmUgbWFuZGF0b3J5PyAmbmJz cDtBbHNvIHN0YXRlIHRoYXQgdGhlIHByaXZhdGUta2V5IHdpbGwgcmVwb3J0PGJyPg0KJ3Blcm1h bmVudGx5LWhpZGRlbicuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQsIGZpeGVkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBsZWFm IHByaXZhdGUta2V5LCB0aGUgdHlwZSBiaW5hcnkgcGFydCBvZiB0aGUgdW5pb24gZG9lc24ndCBo YXZlIGE8YnI+DQpkZXNjcmlwdGlvbiwgYW5kIHRoZSBkZXNjcmlwdGlvbiBmb3IgdGhlIGxlYWYg aXRzZWxmIHNheXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7QSBiaW5hcnkgdGhhdCBjb250YWlucyB0aGUgdmFsdWUgb2YgdGhlIHByaXZhdGUga2V5Ljxi cj4NCjxicj4NCndoaWNoIGlzIG5vdCBxdWl0ZSBjb3JyZWN0Ljxicj4NCjxicj4NCkkgdGhpbmsg d2Ugc2hvdWxkIHN0YXRlIHRoYXQgdGhlIGVudW0gJ3Blcm1hbmVudGx5LWhpZGRlbicgaXMgb25s eTxicj4NCnJlcG9ydGVkIGluIG9wZXJhdGlvbmFsIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSAndHlwZScgc3RhdGVtZW50IGRvZXNuJ3QgaGF2ZSAnZGVzY3JpcHRpb24nIGFzIGEgc3Vi c3RhdGVtZW50LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YnV0LCBwb2ludCB0YWtlbiwgdHdvIHVwZGF0ZXM6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluJm5ic3A7bGVhZiZuYnNw O3ByaXZhdGUta2V5OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IE9MRDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEEgYmluYXJ5IHRoYXQgY29udGFp bnMgdGhlIHZhbHVlIG9mIHRoZSBwcml2YXRlIGtleS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBORVc6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBF aXRoZXIgYSBiaW5hcnkgdGhhdCBjb250YWlucyB0aGUgdmFsdWUgb2YgdGhlIHByaXZhdGUmbmJz cDtrZXkgb3IsIGluJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgY2FzZSBvZiBhIGhpZGRlbiBr ZXksIHRoZSB2YWx1ZSZuYnNwOydwZXJtYW5lbnRseS1oaWRkZW4nLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBlbnVtJm5ic3A7cGVybWFu ZW50bHktaGlkZGVuOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7IE9MRDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBwcml2YXRlIGtl eSBpcyBpbmFjY2Vzc2libGUgZHVlIHRvIGJlaW5nJm5ic3A7cHJvdGVjdGVkIGJ5IHRoZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7c3lzdGVtIChlLmcuLCBhIGNyeXB0b2dyYXBoaWMmbmJzcDtoYXJk d2FyZSBtb2R1bGUpLjxicj4NCiZuYnNwOyBORVc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUg cHJpdmF0ZSBrZXkgaXMgaW5hY2Nlc3NpYmxlIGR1ZSB0byBiZWluZyZuYnNwO3Byb3RlY3RlZCBi eSB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N5c3RlbSAoZS5nLiwgYSBjcnlwdG9ncmFwaGlj Jm5ic3A7aGFyZHdhcmUgbW9kdWxlKS4gJm5ic3A7U2luY2UgaGlkZGVuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtrZXlzIGFyZSBvbmx5IGV2ZXIgcmVwb3J0ZWQgaW4gJmx0O29wZXJhdGlvbmFsJmd0 OywgdGhlIHZhbHVlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsncGVybWFuZW50bHktaGlkZGVuJyBu ZXZlciBhcHBlYXJzIGluICZsdDtpbnRlbmRlZCZndDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5ldyBkZXNjcmlw dGlvbnMgc2F5Ojxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1suLi5dIHByZXNlbnQgb25seSBpbjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZsdDtvcGVyYXRpb25hbCZndDsgYW5kIGJvdW5kIHRvIHRoZSBsaWZldGltZSBv ZiB0aGUgcGFyZW50PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7J2NvbmZpZyB0cnVlJyBub2RlLjxicj4NCjxicj4N CkFyZW4ndCBhbGwgbm9kZXMgYm91bmQgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZWlyIHBhcmVudD88 YnI+DQpUaGUgYWN0aW9uIGlzIGludm9rZWQgaW4gYSBub2RlIHRoYXQgZXhpc3RzIGluICZsdDtv cGVyYXRpb25hbCZndDsgYW5kIGl0PGJyPg0KY3JlYXRlcyBhIGtleS4gJm5ic3A7V2hhdCBkb2Vz IHRoZSBzdGF0ZW1lbnQgdGVsbCBtZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2VlbXMgbGlrZSBzb21l dGhpbmcgbmV3IChhbmQgbWF5YmUgd3JvbmcpIGFuZCBoZW5jZSBuZWVkcyB0byBiZSBleHBsYWlu ZWQuICZuYnNwO1RoaXMgc2VlbXMgbmV3IGJlY2F1c2Ugd2UgYXJlIHNheWluZyB0aGF0IHRoZSBs aWZldGltZSBvZiBhbiBvcGVyYXRpb25hbCB2YWx1ZSBpcyB0aWVkIHRvIHRoZSBsaWZldGltZSBv ZiBhIGNvbmZpZ3VyZWQgdmFsdWUuICZuYnNwO05vcm1hbGx5IHdlIHRhbGsgYWJvdXQgaG93DQog b3BlcmF0aW9uYWwgdmFsdWVzIGV4aXN0IG9uIHRoZWlyIG93biBhbmQgdGhhdCwgaWYgb25lIHdh bnRzIHRvIG92ZXJyaWRlL2V4dGVuZCB0aGVtIChlLmcuLCBhc3NvY2lhdGUgYSBjZXJ0aWZpY2F0 ZSB0byB0aGUgcHJpdmF0ZSBrZXkgY3JlYXRlZCBieSB0aGUgbWFudWZhY3R1cmVyKSwgY29uZmln dXJhdGlvbiB3b3VsZCBvdmVybGF5IHRoZSBvcGVyYXRpb25hbCB2YWx1ZXMuICZuYnNwO0J5IGV4 dGVuc2lvbiwgaWYgdGhlIGNvbmZpZ3VyYXRpb24gaXMNCiByZW1vdmVkLCB0aGUgb3BlcmF0aW9u YWwgdmFsdWVzIGdvIGJhY2sgdG8gdGhlaXIgb3JpZ2luYWwgc3RhdGUgKGkuZS4sIGV4aXN0aW5n IG9uIHRoZWlyIG93bikuICZuYnNwOyBIZXJlIHdlJ3JlIHNheWluZyB0aGF0LCBpZiB0aGUgY29u ZmlndXJhdGlvbiAoZm9yIHRoZSBwYXJlbnQgbm9kZSkgaXMgcmVtb3ZlZCwgdGhlIG9wZXJhdGlv bmFsIHZhbHVlcyBhcmUgcmVtb3ZlZCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlIHRoYXQgdGhpcyBzdGF0ZW1lbnQgd2Fz IGFkZGVkIGJlY2F1c2UgSnVlcmdlbiBhc2tlZCBhYm91dCBob3cgaGlkZGVuIGtleXMgY291bGQg YmUgcmVtb3ZlZC9yZXBsYWNlZC4gJm5ic3A7IFdlIGl0ZXJhdGVkIHRvd2FyZHMgbm90IHdhbnRp bmcgdG8gc3VwcG9ydCB0aGUgJnF1b3Q7cmVwbGFjZSZxdW90OyBjYXNlLCBhbmQgdGhpcyBzZWVt ZWQgbGlrZSBhbiBlYXN5IHdheSB0byBoYW5kbGUgdGhlICZxdW90O3JlbW92ZSZxdW90OyBjYXNl LiAmbmJzcDtBbm90aGVyDQogd2F5IHRvIGRvIHRoaXMgd291bGQgYmUgdmlhIGFub3RoZXIgYWN0 aW9uIHN1Y2ggYXMgJ3JlbW92ZS1oaWRkZW4ta2V5Jy4gJm5ic3A7IFdoYXQgZG8geW91IHRoaW5r IHdvdWxkIGJlIGJlc3Q/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_acef56d17fc64102ae24bb8fcb8c828dXCHRCD007ciscocom_-- From nobody Wed May 1 07:23:37 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA9F120122; Wed, 1 May 2019 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf9P-HmcuErX; Wed, 1 May 2019 07:23:27 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 B4F761200CE; Wed, 1 May 2019 07:23:27 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x41ENJcn026216; Wed, 1 May 2019 10:23:19 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x41ENJcn026216 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1556720599; bh=k6oEP43zD4XJ2JoD5V2TFgMSSbwWpmMR0AMSnLgkyPA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=p1ArMVdhOfGxPfb3YOArExG7OjPpt0Yt/zVQgfVTG1+wPqDqqBMg0kADqJCXofLu8 yem3cbi7UcGcW5ddKehSxPzd9Lfl3/UTLkRLRvkYkJMszO+5I67OpdyfEyOtrO2ZS4 NjQc1BVNaHp1KAdVxfmDeJnIuq214dTaFLv6BXnw= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x41ENGb8003420; Wed, 1 May 2019 10:23:16 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 1 May 2019 10:23:16 -0400 From: Roman Danyliw To: "Eric Voit (evoit)" , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) Thread-Index: AQHU/43bdZR/ina0AEW5K8wY2ATR0aZVe5oAgADXmyA= Date: Wed, 1 May 2019 14:23:15 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33508ED@marathon> References: <155665377891.7475.13101015755522983059.idtracker@ietfa.amsl.com> <257ba0408739443e8a1af9d3a888fa8b@XCH-RTP-013.cisco.com> In-Reply-To: <257ba0408739443e8a1af9d3a888fa8b@XCH-RTP-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 14:23:30 -0000 SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRXJpYyBWb2l0IChl dm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDMw LCAyMDE5IDU6MzAgUE0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQt bm90aWZpY2F0aW9uc0BpZXRmLm9yZzsgS2VudCBXYXRzZW4NCj4gPGtlbnQraWV0ZkB3YXRzZW4u bmV0PjsgbmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVj dDogUkU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJz Y3JpYmVkLQ0KPiBub3RpZmljYXRpb25zLTI0OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiANCj4gVGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzIFJvbWFuLiAgICBTb21lIHRo b3VnaHRzIGluLWxpbmUuLi4NCj4gDQo+ID4gRnJvbTogUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRy YWNrZXIgLS0gVHVlc2RheSwgQXByaWwgMzAsIDIwMTkgMzo1MCBQTQ0KPiA+DQo+ID4gUm9tYW4g RGFueWxpdyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4g PiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLTI0OiBEaXNjdXNz DQo+ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCj4gPiB0aGlzIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVhc2UgcmVmZXIgdG8N Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwNCj4gPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLg0KPiA+DQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90 aWZpYw0KPiA+IGF0aW9ucy8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g RElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBTZWN0aW9ucyAyLjQuMi4xIGFu ZCAyLjUuNiBzZWVtcyB0byBkZXNjcmliZSBhIG1lY2hhbmlzbSAocmVwbGF5KSB0bw0KPiA+IGFj Y2VzcyBoaXN0b3JpY2FsIGRhdGEgdGhhdCB3YXMgcG90ZW50aWFsbHkgY29sbGVjdGVkIHByaW9y IHRvIGEgZ2l2ZW4NCj4gPiBzdWJzY3JpYmVyIGhhdmluZyBhY2Nlc3MgdG8gaXQuICBUaGlzIGFw cGVhcnMgdG8gYmUgYW4gZXhwbGljaXRseQ0KPiA+IGRlc2lnbmVkIGZlYXR1cmUuICBObyBwdXNo IGJhY2sgb24gdGhhdC4gIEhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGF0IGV4cGxpY2l0bHkNCj4gc3Rh dGluZyB0aGlzIGFycmFuZ2VtZW50IGlzIHdhcnJhbnRlZC4NCj4gPiBQZXJoYXBzIHNvbWV0aGlu ZyBvbiB0aGUgb3JkZXIgb2YgdGhlIGZvbGxvd2luZyBjb3VsZCBiZSBhZGRlZCB0byB0aGUNCj4g PiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAtLSDigJxUaGUgcmVwbGF5IG1lY2hhbmlzbXMgZGVz Y3JpYmVkIGluDQo+ID4gU2VjdGlvbnMNCj4gPiAyLjQuMi4xIGFuZCAyLjUuNiBwcm92aWRlcyBh Y2Nlc3MgdG8gaGlzdG9yaWNhbCBldmVudCByZWNvcmRzLiAgQnkNCj4gPiBkZXNpZ24sIHRoZSBh Y2Nlc3MgY29udHJvbCBtb2RlbCB0aGF0IHByb3RlY3RzIHRoZXNlIHJlY29yZHMgY291bGQNCj4g PiBlbmFibGUgc3Vic2NyaWJlcnMgdG8gdmlldyBkYXRhIHRvIHdoaWNoIHRoZXkgd2VyZSBub3Qg YXV0aG9yaXplZCBhdCB0aGUNCj4gdGltZSBvZiBjb2xsZWN0aW9uLuKAnQ0KPiANCj4gSSBoYXZl IG5vIHByb2JsZW1zIGF0IGFsbCB3aXRoIHRoaXMgZXhhY3Qgc3RhdGVtZW50IGJlaW5nIHBsYWNl ZCBpbnRvIHRoZQ0KPiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiAgIFNvIEkganVz dCBhZGRlZCBpdCB2ZXJiYXRpbS4gICAoSSBkb24ndCBleHBlY3QNCj4gdGhpcyB0byBiZSBjb250 cm92ZXJzaWFsIGFzIHRoaXMgaXMgdGhlIHNhbWUgYmVoYXZpb3Igd2hpY2ggaXMgYXZhaWxhYmxl IGZyb20NCj4gUkZDLTUyNzcgaW1wbGVtZW50YXRpb25zLikNCg0KVGhhbmtzIGZvciB0aGUgYWRk aW5nIHRoZSB0ZXh0Lg0KDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENPTU1FTlQ6DQo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+DQo+ID4gKDEpIFNlY3Rpb24gMi41LjEuICBQZXIgRmlndXJlIDgsIGlm IGEgbW9kaWZ5IG9wZXJhdGlvbiBmYWlscw0KPiA+IHJlLWV2YWx1YXRpb24gKHRoZSDigJxubyAo MinigJ0gYnJhbmNoKSB3b3VsZG7igJl0IGl0IGdvIGRpcmVjdGx5IHRvDQo+ID4g4oCcaW52YWxp ZOKAnSAoaW5zdGVhZCBvZiB0aHJvdWdoIOKAnHVuc3VwcG9ydGFibGUtPmludmFsaWTigJ0pPw0K PiANCj4gRWZmZWN0aXZlbHkgaXQgZG9lcyBnbyByaWdodCB0byBpbnZhbGlkLCBhcyAndW5zdXBw b3J0YWJsZScgaXNuJ3QgYSBzdGF0ZS4gIFRoZQ0KPiBtZXJnZSB3YXMgYSBzb21ldGhpbmcgaW4g dGhlIGRpYWdyYW0gd2hpY2ggd2FzIGludGVuZGVkIHRvIHNhdmUgc29tZQ0KPiBzcGFjZS4gIEJh c2ljYWxseSBib3RoICgyKSBhbmQgKDMpIGdvIHRocm91Z2ggInVuc3VwcG9ydGFibGUiIHRvIGV4 cGxpY2l0bHkNCj4gc2hvdyB0aGF0IGEgInN1YnNjcmlwdGlvbiB0ZXJtaW5hdGVkIiBtZXNzYWdl IG5lZWRzIHRvIGJlIHNlbnQgdG8gYW55DQo+IGN1cnJlbnRseSBhY3RpdmUgYnV0IHNvb24gZGlz Y29ubmVjdGVkIHJlY2VpdmVycy4NCg0KVW5kZXJzdG9vZC4gIFRoYW5rcyBmb3IgdGhlIGNsYXJp dHkuDQoNCj4gPiAoMikgU2VjdGlvbiAyLjUuMiwgd2hhdCBhcmUg4oCcdHJhbnNwb3J0IHNwZWNp ZmljIGNhbGwtaG9tZSBvcGVyYXRpb25z4oCdPw0KPiANCj4gQSB0cmFuc3BvcnQgc3BlY2lmaWMg ZG9jdW1lbnQgbmVlZHMgdG8gZGVmaW5lIGhvdyB0byBlc3RhYmxpc2ggYSB0cmFuc3BvcnQNCj4g Y29ubmVjdGlvbiBmcm9tIGEgY29uZmlndXJlZCBwdWJsaXNoZXIgdG8gYW4gaW50ZW5kZWQgcmVj ZWl2ZXIuICAgIEFuDQo+IGV4YW1wbGUgb2YgdGhlIG9wZXJhdGlvbnMgd291bGQgYmUgaW4gc2Vj dGlvbnMgMyAmIDQgb2YgIFJGQyA4MDcxIChORVRDT05GDQo+IENhbGwgSG9tZSBhbmQgUkVTVENP TkYgQ2FsbCBIb21lLikNCg0KSSBhcHByZWNpYXRlIHRoZSBjbGFyaWZ5aW5nIHBvaW50ZXIuICAN Cg0KPiA+ICgzKSBTZWN0aW9uIDIuNS42LiAgVHlwb3MNCj4gPg0KPiA+IHMvdGltZWdhcC90aW1l IGdhcC8NCj4gPiBzL3N1Y2Nlc3NmdWxseS9zdWNjZXNzZnVsbHkvDQo+IA0KPiBGaXhlZC4NCg0K VGhhbmtzLg0KDQpSZWdhcmRzLA0KUm9tYW4NCg0KPiBUaGFua3MhDQo+IEVyaWMNCg== From nobody Wed May 1 07:39:32 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860E91200F9; Wed, 1 May 2019 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxlLndRe-XeD; Wed, 1 May 2019 07:39:21 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50050.outbound.protection.outlook.com [40.107.5.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EF61200EB; Wed, 1 May 2019 07:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MiVkMFVpSQnp1/18ZdXWe1AnA09U8tn12917wAifLco=; b=kV8r3PpGTatsfp8mLZ+PootjB6S910gpeOPV9jKLYKzWuGDHU+Oe7WoVnTJ827Y/y9HE/Rjt2PcURhn/vN27ne6vGrC1zJGCuqoOPo7tf+6kcB3x6gpXrvSQXvRcS8rVD8dpgZkVZdoDhH1ykrwW5Ic+8eAt00sxrum8EE9o2E8= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2377.eurprd07.prod.outlook.com (10.168.128.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Wed, 1 May 2019 14:39:17 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1856.008; Wed, 1 May 2019 14:39:17 +0000 From: Magnus Westerlund To: "Eric Voit (evoit)" , Benjamin Kaduk CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf@ietf.org" , Kent Watsen , The IESG , "netconf-chairs@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) Thread-Index: AQHU/rKtCIs3MFSYbUWn2jaVvwTXvw== Date: Wed, 1 May 2019 14:39:17 +0000 Message-ID: References: <155655963180.15870.3650019434718355043.idtracker@ietfa.amsl.com> <717530026d2d4af0a92c318ecbdbb4bd@XCH-RTP-013.cisco.com> <20190429182503.GC60332@kduck.mit.edu> <94d0b3e325ee46e283d84204243bdf69@XCH-RTP-013.cisco.com> <20190430162527.GI60332@kduck.mit.edu> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 607f1866-b1a8-4fb0-234d-08d6ce42ca61 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2377; x-ms-traffictypediagnostic: HE1PR0701MB2377: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(346002)(396003)(366004)(189003)(199004)(5660300002)(26005)(6506007)(186003)(68736007)(6116002)(99286004)(14454004)(8676002)(44832011)(7696005)(73956011)(66476007)(81166006)(76176011)(66946007)(76116006)(102836004)(6436002)(486006)(446003)(66446008)(305945005)(64756008)(74316002)(54906003)(71200400001)(2906002)(316002)(71190400001)(110136005)(25786009)(229853002)(3846002)(4744005)(7736002)(478600001)(6246003)(9686003)(52536014)(81156014)(86362001)(256004)(66066001)(53936002)(476003)(8936002)(4326008)(2171002)(33656002)(55016002)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2377; H:HE1PR0701MB2522.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: uqGljxX/dN5lnTaxps1ORVYSZZ4bTJoxonv+t9U45NG9hCZaPLMEQRYSegP56J9QCzt2zlWi55HqcBt1boPbf8M3OPuZ+cw6seZvXz9PZRPJ8uDYPUpCgOj+maNYsae6w8W0TzfkDTavDMfklx7EaS837tYanWl6I8ODP7gH75EuXe7UYbwEzWGtQiPER+fTGxlbaQ0Xg50+4T626FEu3YyT7sOeh/K7eAyb/cxH61k0PrDtjrLNwvJ7qryVKLsv+D58m/4GqNPnQBovPPN95+cGzgxHqFAZiCAbLfBJTO7mGC2AY8sLE8IEJ5YPccda7LSbCI83O71gJ5VeJrYTex2OiJx3ZZUPEUjJ1u01hxKBpFEdclnPvDREbV8b20PsczCf09Z76yIHgmhQb9dzicH1x9fK9Q50LBhCm1Dqa1c= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 607f1866-b1a8-4fb0-234d-08d6ce42ca61 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2019 14:39:17.6569 (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: HE1PR0701MB2377 Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-23: (with DISCUSS) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 14:39:24 -0000 > Is there a process in the IETF to determine copyright coverage based on a= couple sentence fragments and concept reuse? I don't feel capable of prov= iding a legal opinion here. That is why I l felt converging on the narrowe= r "pre5378Trust200902" boilerplate was safer.=0A= >=0A= To my understanding that do not sound like something that is an issue.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= From nobody Wed May 1 08:37:45 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21E1200FF; Wed, 1 May 2019 08:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 kuddB6H9d-5o; Wed, 1 May 2019 08:37:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6FA64120122; Wed, 1 May 2019 08:37:32 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x41FbQGQ019106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 May 2019 11:37:28 -0400 Date: Wed, 1 May 2019 10:37:26 -0500 From: Benjamin Kaduk To: "Eric Voit (evoit)" Cc: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Message-ID: <20190501153725.GG59871@kduck.mit.edu> References: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 15:37:38 -0000 On Wed, May 01, 2019 at 05:48:45AM +0000, Eric Voit (evoit) wrote: > Hi Benjamin, > > > From: Benjamin Kaduk, April 30, 2019 5:11 PM > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-netconf-subscribed-notifications-24: Discuss > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for this document; I just have a few minor "housekeeping" points that > > should get resolved before publication. (Please also note the substantive > > comments in the COMMENT section as well, particularly those relating to the > > transport requirements and security considerations.) > > > > I'm not sure that we state clearly enough what is required to have a > > specification for a transport for notifications. Specifically (see COMMENT), in > > the module we seem to say that the specification must indicate what the default > > encoding is to be used if not otherwise specified, but that's not enumerated as a > > requirement on such a specification anywhere I see. > > I provide more info in-line below with your comment. But here is a summary... > > For dynamic subscriptions, the default encoding is normally specified by whatever is used within the establish-subscription RPC. So there is not a need for a default here as the subscriber has already encoded in the RPC what it wants. > > For configured subscriptions, the default (and only) encoding is often driven by the transport selection. And this is defined by existing transport RFCs which themselves define supported encodings (e.g., "NETCONF + XML" , "RESTCONF + JSON"). > > But encodings can vary (e.g., the use of CBOR within draft-birkholz-yang-push-coap-problemstatement). Supporting this need is the purpose of the identity "configurable-encoding" in the YANG model. And this identity does say that "Further details for any specific configurable encoding would be explored in a transport document based on this specification." I guess this information could be repeated as a separate requirement in Section 5.3 if you feel this is insufficiently defined. I'm mostly concerned about the case of configured subscriptions and future extensibility. If someone wants to make a new "QUIC + CBOR" transport, do we have a clear list of what details that specification needs to provide? (From my reading of this document, there should be an explicit "this is the default encoding" statement, even if there is only one encoding specified in the transport specification.) > > I also think that we could > > probably require (as opposed to "highly recommend" in the current security > > considerations) that the transport provide message confidentiality and integrity > > protection. > > I for sure like the idea of encryption. And I absolutely like the idea of signatures too. However several years ago on based on work with MSDC / cloud providers desiring telemetry, there were requests for deployments where the volume of telemetry generated could overwhelm the CPU of the host router. And as the telemetry was being delivered within a fully protected MSDC domain/environment, these MSDC providers said they wanted *all* the router data more than they needed message confidentiality and integrity protection. I.e., the wanted to have more data rather than being constrained the host CPU doing functions which reduced the volume of data being delivered. > > So personally, I want low volume telemetry with full security protections applied. But by leaving it at "highly recommend" we don't unintentionally inhibit applicability to MSDC implementations in a protected domain. They explicitly said they didn't want it. We do sometimes have cases where we leave an opening for people to assert that the physical security of their network provides "equivalent protection" to cryptographic confidentiality/integrity protection, if we want to try to wordsmith something. But, given the above, I won't push very hard on this front. > > I'm also unsure that I properly understand the use of the "reset" RPC -- if it has > > no effect when transit connectivity already exists, then what entity is going to > > call "reset" in the case of publisher timeout when trying to reach a receiver? > > Surely not the publisher itself, since that would just be publisher-internal > > functionality with no need for an external-facing RPC. > > The reset RPC of section 2.5.5 is YANG model exposed operational knob based on the YANG 1.1 language construct "action": > https://tools.ietf.org/html/rfc7950#section-7.15 > > An operational interface can call this action. I.e., an entity with the proper administrative privileges can access "reset". This means a REST interface could be exposed upon a controller for that publisher. And when somebody find that the subscription isn't responsive (for a variety of reasons) that REST interface can be called, and the publisher can start trying to make connections (such as RFC 8071 call home connections) to a receiver. Okay, thanks for helping me out here; consider this one resolved. > > > I'm also a little unclear on the mechanics of the list of subscriptions described in > > Section 3.3. Does it provide a way for a low-privilege client (that can only > > access one or a handful of the subscriptions) to enumerate all subscriptions that > > exist, including subscriptions used by high-privilege clients? If so, we may want > > to think about some security considerations text to that effect; if not, we may > > want to say that the access-control will limit which leafs are visible to some > > clients. > > Your functional requirements completely valid. I believe they are covered by a set of other YANG RFC which dictate who/what can access various elements of YANG data. Good example documents to look at here are ones like: > > RFC-8341 - Network Configuration Access Control Model > > An understanding of these documents are assumed, and listed in places like the security considerations in Section 5.4. I admit to having not fully absorbed the NACM, and given the number of documents I have left to ballot on this week, I'll take your word that it's covered well enough there. > > Finally, we have a few instances of "leaf filter-failure-hint" that's of type > > "string", providing > > "Information describing where and/or why a provided filter > > was unsupportable for a subscription."; I don't understand why it's a > > string as opposed to some form of machine-readable data. Is it supposed to be > > human-readable? Does that bring in any internationalization considerations? > > There are many reasons why a filter might fail. The authors didn't believe that there was enough operational experience to sufficiently document the universe of failure types across the set of interested parties. As a result, the option seemed to be to provide no guidance on the failure reason, or to let the vendors provide some guidance (albeit just a 'string'). So at this point with the specification, it would be up to the vendor to determine whether it is human readable, or whether internationalization considerations should be covered. Hopefully with enough deployments this might be revisited at a future date. We should probably think about saying something about how its syntax and semantics are implementation-specific, then -- there doesn't seem to be real guidance for how to use it, at present. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1.3 > > > > Also note that transport specific transport drafts based on this > > specification MUST detail the life cycle of dynamic subscriptions, as > > well as the lifecycle of configured subscriptions (if supported). > > > > I'm not sure I understand what additional specification is needed for the lifecycle > > of configured subscriptions -- doesn't the previous text tightly tie their lifecycle > > to the presence of configuration in the configuration datastore? > > For the most part it does. However there is a relationship for exactly when to establish transport connectivity based on the state of each receiver of a configured subscription. > > As an example of what should be specified, see Section 5.2 of > https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/10/ > Here you can see how NETCONF call home is invoked at the proper points in the configured subscription state machine. Ah, thanks for the pointer. > > nit: please be consistent about "life cycle" vs. "lifecycle" throughout. > > Fixed nit to "lifecycle". > > > Section 2.1 > > > > An event stream is a named entity on a publisher which exposes a > > continuously updating set of YANG encoded event records. [...] > > > > nit: I don't think "YANG encoded" is well-defined (here and below), in that YANG > > structures generate data models but can be encoded into various formats (like > > XML and JSON). > > This is true. I made the two occurrences of "YANG encoded" into "YANG defined". > > > Section 2.3 > > > > If the publisher supports the "dscp" feature, then a subscription > > with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP > > marking being placed within the IP header of any resulting > > notification messages and subscription state change notifications. > > Where TCP is used, a publisher which supports the "dscp" feature > > SHOULD ensure that a subscription's notification messages are > > returned within a single TCP transport session where all traffic > > shares the subscription's "dscp" leaf value. Where this cannot be > > guaranteed, any "establish subscription" RPC request SHOULD be > > rejected with a "dscp-unavailable" error > > > > I can't decide whether we need to be more explicit in the second and/or third > > sentences that this remains contingent on the subscription in question having a > > "dscp" leaf. > > The sentences were already long, it feels to me like it would be more confusing to put in more words here. > > > nit: end sentence with a full stop > > Period added. > > > I share the TSV-ART reviewer's confusion about how the weighting (as well as > > DSCP) functionality is intended to work. > > Short answer: Earlier versions of this draft made explicit parallels of the weighting method to HTTP2 RFC-7450 section 5.3.2. The operation of weighting is exactly the same HTTP2 dependency weighting. There is additional definition of how this is supposed to work in Section 4 of draft-ietf-netconf-restconf-notif (which is also currently up for review). > > Long answer: TSV-ART is absolutely correct that a publisher might generate a lot of traffic. In many ways, high traffic volumes would be a successful outcome for this work. As a result, mitigating different dimensions of this volume risk has been a design goal since this effort’s inception. And this is the reason robust QoS mechanisms were included. This includes both DSCP and weighting. > > Here is a quick summary of some QoS mechanisms available in this draft... > > 1. The publisher is allowed to decline a dynamic subscription. One of these reasons is that the incremental traffic generated by a particular incremental subscription will be too high. There are errors back to the subscriber indicating this condition exist. > 2. A publisher can suspend any subscription for capacity reasons, and a receiver must be able to gracefully accept this suspension. > 3. Much like with HTTP2 streams, higher priority subscriptions intended for a particular receiver can be dequeued first from a publisher. > 4. Much like with HTTP2 streams, proportional subscription dequeuing intended for a particular receiver can be performed a publisher. > 5. DSCP markings can be placed on subscribed data. > 6. Mechanisms for detecting and reacting to different types of subscribed data loss have been embedded. > 7. Methods have been included to ensure a configured receiver “ok’s” information push before subscribed data is sent. (This should reduce one DDoS vector.) > 8. Keep alive mechanisms are established for different transport types, so that subscribed data isn’t being sent when the is no receiver listening. > > Mechanism (4) is in question here. As defined by draft-ietf-netconf-restconf-notif, this is supposed to work identically to HTTP2 RFC-7450 section 5.3.2. However there were WG members who did not want to include a functional requirement normative reference to that HTTP2 transport in this document however. Therefore the reference to HTP2 was removed. > > In the end, I don't think we can afford to get rid of support for (4) from the specification. This weighting capability is quite powerful, and can easily be added to GRPC based subscription alternatives. I don't think I was trying to suggest removing the mechanism entirely. What you've written here includes a mental model of having local queues of messages that get dequeued according to a specific algorithm, and the weights influencing the rate of dequeuing across queues; that mental model (combined with the knowledge that larger weight values get more traffic faster) gives me the picture I wanted for "how it's supposed to work". Maybe we could distill that down a bit and put it in the draft, as the current text had some level of "magic occurs here", to me. > > Section 2.4.2.1 > > > > Replay provides the ability to establish a subscription which is also > > capable of passing recently generated event records. In other words, > > > > nit/editorial: this language could probably be more clear about "recently > > generated" meaning "in the past", that is, records for events that have already > > happened when the subscription is established. > > Tweaked to "event records generated in the recent past" > > > Section 2.4.3 > > > > any number of times. Dynamic subscriptions can only be modified via > > this RPC using a transport session connecting to the subscriber. If > > > > nit(?): is this more readable as "connecting to" or "connecting from" > > the subscriber? (The same wording shows up throughout the document, but I'll > > try to just comment once.) > > I expect that it should be clear enough either way. I believe leaving the current text should not impact implementations. > > > Section 2.4.5 > > > > Is there any distinction between "killing a subscription" and "administratively > > deleting a subscription"? It's unclear to me that we need the extra connotations > > of the word "kill", here. > > We chose to use a different RPC name so that administrative access control permissions differences between the kill-subscription and delete-subscription would be explicit and obvious. And once we had a new RPC name, it seemed easier for the reader to continue using the "kill" word for that RPC. In vacuum, "admin-delete-subscription" seems like a fine name, to me. But this is a non-blocking comment so I'll stop pushing now. > > Section 2.4.6 > > > > As a result of this mixture, how subscription errors are encoded > > > > nit: "mixture" doesn't seem like the right word to me; "variety" or "varied > > population" are the first alternatives that come to mind, though they are not > > perfect either. > > Changed to 'variety'. > > > Is there some sort of "access denied" error that could result from kill- > > subscription RPCs? (The table/artwork only lists > > "no-such-subscription".) > > Access denied when an RPC fails access control is part of the base transport error types for the RPC. I.e., transports like NETCONF and RESTCONF already have non-subscription-specific errors like this one already covered. Ah, of course, and we require processing of transport-level errors before these ones, so it all works out fine. > > Section 2.5 > > > > It's interesting to see a slight dichotomy between dynamic and configured > > subscriptions, in that (IIUC) for dynamic subscriptions, a modification event un- > > suspends a subscription immediately, but for configured subscriptions the > > publisher seems to have some latitude to retain the subscription in the > > suspended state for some time before un-suspending it and sending the > > "subscription-modified" state change message. > > > > In this case, a separate dynamic subscription can be > > established to retransmit the missing event records. > > > > Do you want to put in a pointer to replay-start-time here? > > I thought getting to that level of detail in the intro was confusing for this intro section. Okay. (Maybe a parenthetical "replay" as a search term would help without being confusing, but entirely your call.) > > Section 2.5.1 > > > > Event records are only sent to active receivers. Receivers of > > a configured subscription remain active if both transport > > connectivity can be verified to the receiver, and event records are > > not being dropped due to a publisher buffer overflow. [...] > > > > nit: "buffer overflow" is a technical term in security circles indicating a > > potentially exploitable security flaw; would "publisher buffer capacity being > > reached" be an acceptable substitute (here and below)? > > Change made > > > Section 2.7.7 > > > > This notification indicates that all of the event records prior to > > the current time have been passed to a receiver. It is sent before > > any notification message containing an event record with a timestamp > > later than (1) the "stop-time" or (2) the subscription's start time. > > > > nit(?): this text seems to imply that a notification message with a timestamp > > later than the "stop-time" might actually be sent, which IIUC is not the case. > > You are correct that it is not sent. But the event record does exist on the stream. > > I think it obvious, but if you want I could add the following sentence to the end of the subsequent paragraph. "If a stop-time has been exceed during replay, no subsequent event records are sent following the sending of a "replay-completed" notification." I don't think there's a need to add that sentence, but thanks for offering. > > > Section 2.9 > > > > nit: the name "supports-vrf" for the feature doesn't really parallel the other > > feature names, that don't include a word like "support" and rather just describe > > the actual feature. > > This is true. Several years ago when someone proposed this name, there was a reason. But I can't remember what it is right now. So hopefully we can leave it so as not to break someone's thinking. > > > Section 3.1 > > > > Is there any risk of collision in event stream names from vendor-specific > > streams? (We don't seem to create an IANA registry for them, for example.) > > In theory yes. But it has not proven to be an issue with RFC-5277 streams, so it doesn't seem worth it to do something new now. So in this document, we have one IETF stream "NETCONF" defined in Section 2.1. Hopefully it is enough to hard-code this. We can always revisit if IETF groups want to start defining streams > > > Section 4 > > > > identity subscription-suspended-reason { > > description > > "Problem condition communicated to a receiver as part of a > > 'subscription-terminated' notification."; > > } > > > > identity subscription-terminated-reason { > > description > > "Problem condition communicated to a receiver as part of a > > 'subscription-terminated' notification."; > > } > > > > Are these descriptions supposed to be the same? > > Good catch. Fixed the 'subscription-suspended' description. > > > identity configurable-encoding { > > description > > "If a transport identity derives from this identity, it means > > that it supports configurable encodings. An example of a [...] > > > > Is it intended that such future transports (or future encodings?) will derive from > > both this and the normal base identity (i.e., "transport")? > > I guess I'm asking why this identity does not derive from the corresponding base, > > but that's just a style question and not really a protocol matter, making this > > question a side note. > > Yes. Future identities can derive from configurable-encoding > > > leaf weighting { > > if-feature "qos"; > > type uint8 { > > range "0 .. 255"; > > } > > description > > "Relative weighting for a subscription. Allows an underlying > > transport layer perform informed load balance allocations > > between various subscriptions"; > > reference > > "RFC-7540, section 5.3.2"; > > > > Do we want to chase the reference for readers and say that larger weights get > > more resources? > > I put in "Larger weights get more resources." as sentence two of the description. > > > leaf encoding { > > when 'not(../transport) or derived-from(../transport, > > "sn:configurable-encoding")'; > > type encoding; > > description > > "The type of encoding for notification messages. For a > > dynamic subscription, if not included as part of an establish- > > subscription RPC, the encoding will be populated with the > > encoding used by that RPC. For a configured subscription, if > > not explicitly configured the encoding with be the default > > encoding for an underlying transport."; > > > > Where is the default encoding for an underlying transport specified? > > Section 5.3 does not seem to say that a transport specification must provide this > > information, nor does Section 1.3 (which mentions that transport specifications > > must detail the lifecycle of dynamic subscriptions), nor does Section 2.5.7 (that > > discusses the need for a separate model augmenting > > /subscriptions/subscription/receivers/receiver > > to provide transport details). > > For many transports, the encoding is redundant information. The reason is that transport RFCs themselves define supported encodings (e.g., "NETCONF + XML" , "RESTCONF + JSON"). And WG members who built those transport RFCs did not want to allow operators to misconfigure anything here. (As an aside, this desire to significantly reduce the opportunity for misconfiguration is what drove the interesting 'when' statement above.) > > But encodings can vary. This is the purpose of the identity "configurable-encoding" in the YANG model. And this identity does say that "Further details for any specific configurable encoding would be explored in a transport document based on this specification." I guess this information could be repeated in Section 5.3 if necessary. I think that duplication would be my preference, to get things consolidated in one place. > > choice notification-message-origin { > > if-feature "configured"; > > description > > "Identifies the egress interface on the publisher from which > > notification messages are to be sent."; > > > > nit: given the address-originated case, perhaps "the egress interface" > > is not quite correct anymore. > > Every alternative I come up with seems more problematic. I believe readers should be able to understand based on the cases below. (I don't have any better suggestions, either.) > > enum connecting { > > value 3; > > if-feature "configured"; > > description > > "A subscription has been configured, but a > > 'subscription-started' subscription state change > > notification needs to be successfully received before > > notification messages are sent. > > > > nit: successful receipt happens on the receiver but sending happens on the > > publisher, so there's a bit of a mismatch in the sentence subject here. Perhaps > > we could talk about "successfully sent" state-changes to resolve things. > > This wording is as intended. Basically it is highly desirable for configured receivers will need to acknowledgement of successful receipt of a "subscription-started" before sending event records. This helps prevent DDOS attacks. The mechanism for gaining an acknowledgement varies by transport. As an example of what we have been thinking about here, see > > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/04/ Section 3.1.2 > Hopefully this type of mechanism will be revived in future drafts. I agree that getting explicit acknowledgment of delivery is highly desirable; my qualm here is solely about the grammar of the sentence. Does it preserve the desired meaning to replace "successfully received" with "successfully acknowledged" (or "successfully received and acknowledged")? > > config false; > > mandatory true; > > description > > "Specifies the state of a subscription from the > > perspective of a particular receiver. With this info it > > is possible to determine whether a subscriber is > > currently generating notification messages intended for > > that receiver."; > > > > nit: is it the subscriber that is generating messages or the publisher? > > Good catch. Changed to publisher. > > > Section 5.3 > > > > A secure transport is highly recommended and the publisher MUST > > ensure that the receiver has sufficient authorization to perform the > > function they are requesting against the specific subset of content > > involved. > > > > "secure transport" usually means that it provides message confidentiality, > > integrity protection, and source authenticity (akin to the mutual authentication). > > This is qualitatively different from implementing authorization checks, and it's > > surprising to see them squashed into the same sentence. > > Tweaked to "A secure transport is highly recommended. Beyond this, the publisher MUST". > > > Do we want to say anything about discovery for support of new transports, and > > what workflow would be used to negotiate the use of a new transport? > > Not at this point. Okay. > > Section 5.4 > > > > I can think of a couple other considerations to mention here: > > > > - Using DNS names for receiver "name" lookup can cause situations where > > the name resolves differently on the publisher and subscriber, so the > > recipient would be different than expected. > > > > - Using the publisher's boot time for deduplication protection on > > replayed messages introduces a dependency on accurate time. We don't > > have a great secure time story at present, so this is more of a > > "beware of risk" situation than something we can mitigate, but it does > > seem that an attacker that could (e.g.) spoof the NTP traffic to the > > publisher on boot could cause it to send duplicate notifications to > > recipients that requested historical data. > > I tweaked and inserted the two paragraphs from you... > > "Using DNS names for configured subscription receiver "name" lookup can cause situations where the name resolves unexpectedly differently on the publisher, so the recipient would be different than expected." > > "Using the publisher's boot time for deduplication protection on replayed messages introduces a dependency on accurate time." Can we also say something like "An attacker that can cause the publisher to use an incorrect time can induce message replay by setting the time in the past, and introduce a risk of message loss by setting the time in the future"? > > > Some other comments on what's already there (which is pretty good; thanks for > > it!) follow. > > > > Container: "/filters" > > > > o "stream-subtree-filter": updating a filter could increase the > > computational complexity of all referencing subscriptions. > > > > o "stream-xpath-filter": updating a filter could increase the > > computational complexity of all referencing subscriptions. > > > > Do we want to say anything about modifying either of these causing the set of > > notifications delivered to recipients to shrink (or become unmanageably large)? > > I guess it may not be necessary, since the recipient gets a notification about the > > modification that includes the details of the filter. > > Yes, that was the thinking. > > > Container: "/subscriptions" > > > > o "excluded-event-records": leaf can provide information about > > filtered event records. A network operator should have > > permissions to know about such filtering. > > > > To be clear, this is event records filtered either via explicit filter or via access > > control restrictions. > > Yes. I think that the semantic difference is worth noting. > > Specifically, it can allow a receiver to learn that there exists > > access controls that deny it access to some data, in the case when they did not > > apply any filtering rules explicitly. > > Yes. > > >This potential for information leakage (of the > > existence of > > ACLs) should be mentioned explicitly. > > Added the sentence: "Improper configuration could provide a receiver with information leakage consisting of the dropping of event records." Can I counter-propose: "Improper configuration could allow a receiver to learn that event records were dropped due to an ACL when the existence of that ACL would otherwise be transparent." > > > Appendix A > > > > This example transport module does not specify the life cycle of dynamic > > subscriptions per Section 1.3, and a couple other things required from a > > transport module specification. Perhaps we are okay claiming that since this is > > just an example YANG model and not a full transport example, the omission is > > okay, but it may be worth mentioning the omission for clarity. > > I added as the second sentence > " This example is not intended to be a complete transport model." > > Thanks again for the review, it was excellently done. And thanks for the clear explanations of the parts that I didn't understand, it was very helpful to me. -Ben From nobody Wed May 1 09:19:55 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA1612011A for ; Wed, 1 May 2019 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZu-xwlzNDmW for ; Wed, 1 May 2019 09:19:52 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C347D1200D5 for ; Wed, 1 May 2019 09:19:51 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id z26so15903236ljj.2 for ; Wed, 01 May 2019 09:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=up/c/5eSagQAiB8Rn+M3orN62nDFUpoByFCcyujY0Ko=; b=lQZfMhlZaVmBxCLZhvmMACwAKMs18HL6DF4bBOgI1/m8L9yJcGeTW5VCCRcKD9E70P gop+5zuQFAKy2C8MujB2+KJNdAmIHqB0pc5zIp4Xmcr57TO8JaoTwQdJ8be2BZghG237 lAlzzxDcUFIIaz8/w6rAwj4oLxk3SFe0saUGXAsqFYVmS0OXwWiCng/4t29h4GlaytW+ yNnb4IE3BFyoDTfaWkzEa8cEkf5c5ZSbnsMWpvxSkK9AO9LQP0/9om84rhZwm+zngAk5 Aznmn2vUlJgVxs1jDZ3Bw13UXtzHGQU6gUDy+MS8w0RIXHLYd86e0WNC85P/E0tcW0v1 O5Yw== 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=up/c/5eSagQAiB8Rn+M3orN62nDFUpoByFCcyujY0Ko=; b=gvLU3XiB9c+Z2ycjSQwiJwjhwXF5CzuSpxMIIEcrGTpoMwc7Tfqg/bsg8w5MenadN7 bW1SNeBQSaz6HmL1/MCRlKmyPjbC5+N3ZPss8JJHnF00DipoWcw4aS/Z4jo5zXkuc7Vb KZi/DM/xmlVSMeyTuJXB+MkmKCjeRm8PbxWT+fZfHHZ2Mtra0R/YN3ce52q8iTmaB5rr UudYJf62V/2wi6PQyVZTX8f2mMZGW7SkQxs7JAgXuFHxOSXjLuDmugvYaJV78vzki5ki Ka0tvgI/FEprxemgcGGR+sRl7ifxN8PsJKg7lOCjWh9/X7J193u7HP6ARmARGFytXeHU sWhg== X-Gm-Message-State: APjAAAVvhB2IjRIVAjE/0hBxz96QuFxFSnh2vJ5RI4wgDVSnUIMN/PBR nQPoC4G7cN/i3qdTmw+Ov7EaondTNS5E99RaUV1YoQ== X-Google-Smtp-Source: APXvYqxgmMY5WjI/Ho5UzpgWdQmFDLIaPT460zeyDusp2+/L8v7JCqElDZ8xLji7QNQ9UPzsRZ9ucqquuu4yAsmHsW4= X-Received: by 2002:a2e:9855:: with SMTP id e21mr5287362ljj.180.1556727589742; Wed, 01 May 2019 09:19:49 -0700 (PDT) MIME-Version: 1.0 References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Wed, 1 May 2019 09:19:38 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Kent Watsen , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fffc250587d5e291" Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 16:19:55 -0000 --000000000000fffc250587d5e291 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 1, 2019 at 3:17 AM Rob Wilton (rwilton) wrote: > Hi Kent, > > > > I=E2=80=99m slightly lost here, so my comments may not be that helpful = =F0=9F=98=8A > > > > I don=E2=80=99t understand why do we need an explicit action to create/in= stall the > key? In particular, why can=E2=80=99t there just be a regular (intend ba= sed) > configuration leaf that is =E2=80=9Cuse-system-defined-key=E2=80=9D? The= key values could > be reported in and/or , suitably protected via > NACM, or they could be kept entirely hidden. > > > > I also agree with Martin/Andy that it is highly desirable to allow a > device to be configured with a single configuration input file, provided > from or . I think that anything that would > require, or encourage, multiple RPC interactions to setup the device woul= d > seem to be a big backwards step in terms of device management. > > > > I=E2=80=99m not opposed to RPCs or actions to manage hidden keys on the d= evice if: > > (i) these don=E2=80=99t get written to (because t= hey are > not regular configuration), and > > (ii) there is a sensible/secure mechanism to configure the > device without requiring any extra RPCs/actions to configure the device. > I.e. the RPCs/actions should only be used for exceptional management of t= he > keys on the device. > > The document-oriented configuration came from a requirement identified at the IAB Network Management Workshop (way back when). It is critical for rebooting, swapping out a defective device, etc. This seems to be a good test for whether NMDA is useful as designed. It seems obvious that something has to be stored in and then transformed as it is applied to . I don't see how an action or RPC approach meets the operator requirements identified in RFC 3535. The "server created config" problem could be viewed as an access control problem. There are proprietary YANG extensions that implement this approach. > > Thanks, > Rob > > > Andy > > > *From:* netconf *On Behalf Of *Kent Watsen > *Sent:* 30 April 2019 18:57 > *To:* Martin Bjorklund > *Cc:* netconf@ietf.org > *Subject:* Re: [netconf] ietf crypto types - permanently hidden > > > > > > > > I (still) object to this. Actions shouldn't create config. We > > already have generic protcol operations to do this. We go from a > document-oriented configuration model towards a command-oriented > model. Not good. In RESTCONF, the generic methods support things > like ETags, which I suspect you don't want to replicate in this > action? Will the action support all error-options of edit-config, > like rollback-on-error? > > > > The specifics for how this could work would need to be defined. Given > that it is a special case, I think that we could constrain it heavily and > target simple solution. Depending how much text is required to describe > it, it might be good to define an extension statement that could be place= d > on the actions. While an extension statement may seem like it opens the > gates for general use, we could further define the extension statement as > being something that MUST NOT be used when general purpose operations are > suitable such that, at least with the IETF, it could only be used in > extraordinary circumstances. > > > > > > Some comments on the new text: > > In action generate-hidden-key, it should be stated that the public-key > will be populated, and that the private-key will exist but report > 'permanently-hidden'. > > > > Okay, but before making the edit, see comment below about lifetimes... > > > > > > > > In action install-hidden-key, shouldn't both public-key and > private-key be mandatory? Also state that the private-key will report > 'permanently-hidden'. > > > > Indeed, fixed. > > > > > > In leaf private-key, the type binary part of the union doesn't have a > description, and the description for the leaf itself says: > > A binary that contains the value of the private key. > > which is not quite correct. > > I think we should state that the enum 'permanently-hidden' is only > reported in operational state. > > > > The 'type' statement doesn't have 'description' as a substatement, > > but, point taken, two updates: > > > > In leaf private-key: > > OLD: > > A binary that contains the value of the private key. > > NEW: > > Either a binary that contains the value of the private key or, in > > the case of a hidden key, the value 'permanently-hidden'. > > > > In enum permanently-hidden: > > OLD: > > The private key is inaccessible due to being protected by the > > system (e.g., a cryptographic hardware module). > NEW: > > The private key is inaccessible due to being protected by the > > system (e.g., a cryptographic hardware module). Since hidden > > keys are only ever reported in , the value > > 'permanently-hidden' never appears in . > > > > > > The new descriptions say: > > [...] present only in > and bound to the lifetime of the parent > 'config true' node. > > Aren't all nodes bound to the lifetime of their parent? > The action is invoked in a node that exists in and it > creates a key. What does the statement tell me? > > > > This seems like something new (and maybe wrong) and hence needs to be > explained. This seems new because we are saying that the lifetime of an > operational value is tied to the lifetime of a configured value. Normall= y > we talk about how operational values exist on their own and that, if one > wants to override/extend them (e.g., associate a certificate to the priva= te > key created by the manufacturer), configuration would overlay the > operational values. By extension, if the configuration is removed, the > operational values go back to their original state (i.e., existing on the= ir > own). Here we're saying that, if the configuration (for the parent node= ) > is removed, the operational values are removed as well. > > > > Note that this statement was added because Juergen asked about how hidden > keys could be removed/replaced. We iterated towards not wanting to > support the "replace" case, and this seemed like an easy way to handle th= e > "remove" case. Another way to do this would be via another action such a= s > 'remove-hidden-key'. What do you think would be best? > > > > > > Kent // contributor > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000fffc250587d5e291 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 1, 2019 at 3:17 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:

Hi Kent,

=C2=A0

I=E2=80=99m slightly lost here, so my comments= may not be that helpful = =F0=9F=98=8A

=C2=A0

I don=E2=80=99t understand why do we need an e= xplicit action to create/install the key?=C2=A0 In particular, why can=E2= =80=99t there just be a regular (intend based) configuration leaf that is = =E2=80=9Cuse-system-defined-key=E2=80=9D?=C2=A0 The key values could be reported in <intended> and/or <operationa= l>, suitably protected via NACM, or they could be kept entirely hidden.<= u>

=C2=A0

I also agree with Martin/Andy that it is highl= y desirable to allow a device to be configured with a single configuration = input file, provided from <startup> or <edit-config|data>.=C2= =A0 I think that anything that would require, or encourage, multiple RPC interactions to setup the d= evice would seem to be a big backwards step in terms of device management.<= u>

=C2=A0

I=E2=80=99m not opposed to RPCs or actions to = manage hidden keys on the device if:

(i)= =C2=A0=C2=A0=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 don=E2=80=99t get written to <ru= nning> (because they are not regular configuration), and

(ii)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 there is a sensible/secure mechanism to c= onfigure the device without requiring any extra RPCs/actions to configure t= he device.=C2=A0 I.e. the RPCs/actions should only be used for exceptional management of the keys on the device.




I don't see how an acti= on or RPC approach meets the operator requirements identified in RFC 3535.<= /div>

The "server created config" problem coul= d be viewed as an access control problem.
There are proprietary Y= ANG extensions that implement this approach.

=C2=A0=

Thanks,
Rob

=C2=A0


Andy
=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 30 April 2019 18:57
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden=

=C2=A0

=C2=A0



I (still) object to this.=C2=A0 Actions shouldn'= t create config.=C2=A0 We

already have generic protcol operations to do this.= =C2=A0 We go from a
document-oriented configuration model towards a command-oriented
model.=C2=A0 Not good.=C2=A0 In RESTCONF, the generic methods support thing= s
like ETags, which I suspect you don't want to replicate in this
action? =C2=A0=C2=A0Will the action support all error-options of edit-confi= g,
like rollback-on-error?

=C2=A0

The specifics for how this could work would need to = be defined.=C2=A0 Given that it is a special case, I think that we could co= nstrain it heavily and target simple solution. =C2=A0 Depending how much te= xt is required to describe it, it might be good to define an extension statement that could be placed on the actions.=C2= =A0 While an extension statement may seem like it opens the gates for gener= al use, we could further define the extension statement as being something = that MUST NOT be used when general purpose operations are suitable such that, at least with the IETF, it could only b= e used in extraordinary circumstances.

=C2=A0



Some comments on the new text:

In action generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but report
'permanently-hidden'.

=C2=A0

Okay, but before making the edit, see comment below = about lifetimes...

=C2=A0

=C2=A0



In action install-hidden-key, shouldn't both pub= lic-key and
private-key be mandatory?=C2=A0 Also state that the private-key will report=
'permanently-hidden'.

=C2=A0

Indeed, fixed.

=C2=A0



In leaf private-key, the type binary part of the uni= on doesn't have a
description, and the description for the leaf itself says:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A binary that contains the value of the= private key.

which is not quite correct.

I think we should state that the enum 'permanently-hidden' is only<= br> reported in operational state.

=C2=A0

The 'type' statement doesn't have 'd= escription' as a substatement,=C2=A0

but, point taken, two updates:

=C2=A0

In=C2=A0leaf=C2=A0private-key:

=C2=A0 OLD:

=C2=A0 =C2=A0 =C2=A0 A binary that contains the valu= e of the private key.

=C2=A0 NEW:

=C2=A0 =C2=A0 =C2=A0 Either a binary that contains t= he value of the private=C2=A0key or, in=C2=A0

=C2=A0 =C2=A0 =C2=A0 the case of a hidden key, the v= alue=C2=A0'permanently-hidden'.

=C2=A0

In enum=C2=A0permanently-hidden:

=C2=A0 OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The private key is inacce= ssible due to being=C2=A0protected by the

=C2=A0 =C2=A0 =C2=A0 =C2=A0system (e.g., a cryptogra= phic=C2=A0hardware module).
=C2=A0 NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The private key is inacce= ssible due to being=C2=A0protected by the

=C2=A0 =C2=A0 =C2=A0 =C2=A0system (e.g., a cryptogra= phic=C2=A0hardware module).=C2=A0 Since hidden

=C2=A0 =C2=A0 =C2=A0 =C2=A0keys are only ever report= ed in <operational>, the value

=C2=A0 =C2=A0 =C2=A0 =C2=A0'permanently-hidden&#= 39; never appears in <intended>.

=C2=A0

=C2=A0

The new descriptions say:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[...] pre= sent only in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<opera= tional> and bound to the lifetime of the parent
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0'conf= ig true' node.

Aren't all nodes bound to the lifetime of their parent?
The action is invoked in a node that exists in <operational> and it creates a key.=C2=A0 What does the statement tell me?

=C2=A0

This seems like something new (and maybe wrong) and = hence needs to be explained.=C2=A0 This seems new because we are saying tha= t the lifetime of an operational value is tied to the lifetime of a configu= red value.=C2=A0 Normally we talk about how operational values exist on their own and that, if one wants to override/e= xtend them (e.g., associate a certificate to the private key created by the= manufacturer), configuration would overlay the operational values.=C2=A0 B= y extension, if the configuration is removed, the operational values go back to their original state (i.e., exi= sting on their own). =C2=A0 Here we're saying that, if the configuratio= n (for the parent node) is removed, the operational values are removed as w= ell.

=C2=A0

Note that this statement was added because Juergen a= sked about how hidden keys could be removed/replaced. =C2=A0 We iterated to= wards not wanting to support the "replace" case, and this seemed = like an easy way to handle the "remove" case.=C2=A0 Another way to do this would be via another action such as 'remove-hidden-key&= #39;. =C2=A0 What do you think would be best?

=C2=A0

=C2=A0

Kent // contributor

=C2=A0

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000fffc250587d5e291-- From nobody Wed May 1 10:09:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD6E1200A4; Wed, 1 May 2019 10:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u7t5G4o5sy0; Wed, 1 May 2019 10:09:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17811200A2; Wed, 1 May 2019 10:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46366; q=dns/txt; s=iport; t=1556730555; x=1557940155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=obS29gQaf38yq5DJqdKizNy0P2H3V6dXD4OPMSlIM98=; b=k1qhQzBzz8ALy/vAKyNpnLk/YFBNC4xLxCY6vl8ZmkVC0WlH2QbQv5tg V315McRz+9VTrdDYK1yuJ8Wq1qZnzrWF9B4IYt8zBgbDkFu0mTLtAwJJZ +bZKygobhn9kTXaHI0K+aQfFQvHhOozoaDq4/8j43xj8mWt49EhHB79SA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAACg0clc/5JdJa1cAQIHDgsBAQE?= =?us-ascii?q?BAQEBAQEBAQEHAQEBAQEBgWWBZyppgQQoCoNGQJUvfpdmgWcOAQEjhEoCF4Y?= =?us-ascii?q?bIzgTAQMBAQQBAQIBAm0cDIVKAQEBAQIBDAIMAQgRMQcGBQIFCwIBBgIVAwI?= =?us-ascii?q?CCRYHAgICMBUQAgQODRGCPkyBew8Pkg6bZYEvhEZBhSgGgQsniiGBKxeBQD+?= =?us-ascii?q?BEYIUSTU+gmEBAQIBAYEyAQQOAQSDHYJYBIp2AxImC4IIhGqBbpISZQkCggm?= =?us-ascii?q?CU4NEjCAjgg2GN4xxkleOFgIRFYEwNiGBVnAVO4I4ATSCGhcUbQECBodWhQQ?= =?us-ascii?q?7QTEBkSEBJQOBCIEhAQE?= X-IronPort-AV: E=Sophos;i="5.60,418,1549929600"; d="scan'208";a="267325017" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 17:09:13 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x41H9D7T015899 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 17:09:13 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 13:09:12 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 1 May 2019 13:09:12 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) Thread-Index: AQHU/5lDbPOEHPnGa0+OxIdeqCy7a6ZVXYMAgAFN5gD//8vZMA== Date: Wed, 1 May 2019 17:09:11 +0000 Message-ID: References: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> <20190501153725.GG59871@kduck.mit.edu> In-Reply-To: <20190501153725.GG59871@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:09:21 -0000 PiBGcm9tOiBCZW5qYW1pbiBLYWR1aywgIE1heSAxLCAyMDE5IDExOjM3IEFNDQo+IA0KPiBPbiBX ZWQsIE1heSAwMSwgMjAxOSBhdCAwNTo0ODo0NUFNICswMDAwLCBFcmljIFZvaXQgKGV2b2l0KSB3 cm90ZToNCj4gPiBIaSBCZW5qYW1pbiwNCj4gPg0KPiA+ID4gRnJvbTogQmVuamFtaW4gS2FkdWss IEFwcmlsIDMwLCAyMDE5IDU6MTEgUE0NCj4gPiA+DQo+ID4gPiBCZW5qYW1pbiBLYWR1ayBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiA+IGRyYWZ0LWll dGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMtMjQ6IERpc2N1c3MNCj4gPiA+DQo+ ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPiA+IERJU0NVU1M6DQo+ID4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+ID4gLS0NCj4gPiA+DQo+ID4gPiBUaGFua3MgZm9yIHRoaXMgZG9jdW1lbnQ7IEkg anVzdCBoYXZlIGEgZmV3IG1pbm9yICJob3VzZWtlZXBpbmciDQo+ID4gPiBwb2ludHMgdGhhdCBz aG91bGQgZ2V0IHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4gIChQbGVhc2UgYWxzbw0KPiA+ ID4gbm90ZSB0aGUgc3Vic3RhbnRpdmUgY29tbWVudHMgaW4gdGhlIENPTU1FTlQgc2VjdGlvbiBh cyB3ZWxsLA0KPiA+ID4gcGFydGljdWxhcmx5IHRob3NlIHJlbGF0aW5nIHRvIHRoZSB0cmFuc3Bv cnQgcmVxdWlyZW1lbnRzIGFuZA0KPiA+ID4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuKQ0KPiA+ ID4NCj4gPiA+IEknbSBub3Qgc3VyZSB0aGF0IHdlIHN0YXRlIGNsZWFybHkgZW5vdWdoIHdoYXQg aXMgcmVxdWlyZWQgdG8gaGF2ZSBhDQo+ID4gPiBzcGVjaWZpY2F0aW9uIGZvciBhIHRyYW5zcG9y dCBmb3Igbm90aWZpY2F0aW9ucy4gIFNwZWNpZmljYWxseSAoc2VlDQo+ID4gPiBDT01NRU5UKSwg aW4gdGhlIG1vZHVsZSB3ZSBzZWVtIHRvIHNheSB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIG11c3QN Cj4gPiA+IGluZGljYXRlIHdoYXQgdGhlIGRlZmF1bHQgZW5jb2RpbmcgaXMgdG8gYmUgdXNlZCBp ZiBub3Qgb3RoZXJ3aXNlDQo+ID4gPiBzcGVjaWZpZWQsIGJ1dCB0aGF0J3Mgbm90IGVudW1lcmF0 ZWQgYXMgYSByZXF1aXJlbWVudCBvbiBzdWNoIGEgc3BlY2lmaWNhdGlvbg0KPiBhbnl3aGVyZSBJ IHNlZS4NCj4gPg0KPiA+IEkgcHJvdmlkZSBtb3JlIGluZm8gaW4tbGluZSBiZWxvdyB3aXRoIHlv dXIgY29tbWVudC4gIEJ1dCBoZXJlIGlzIGEgc3VtbWFyeS4uLg0KPiA+DQo+ID4gRm9yIGR5bmFt aWMgc3Vic2NyaXB0aW9ucywgdGhlIGRlZmF1bHQgZW5jb2RpbmcgaXMgbm9ybWFsbHkgc3BlY2lm aWVkIGJ5DQo+IHdoYXRldmVyIGlzIHVzZWQgd2l0aGluIHRoZSBlc3RhYmxpc2gtc3Vic2NyaXB0 aW9uIFJQQy4gIFNvIHRoZXJlIGlzIG5vdCBhIG5lZWQNCj4gZm9yIGEgZGVmYXVsdCBoZXJlIGFz IHRoZSBzdWJzY3JpYmVyIGhhcyBhbHJlYWR5IGVuY29kZWQgaW4gdGhlIFJQQyB3aGF0IGl0DQo+ IHdhbnRzLg0KPiA+DQo+ID4gRm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucywgdGhlIGRlZmF1 bHQgKGFuZCBvbmx5KSBlbmNvZGluZyBpcyBvZnRlbiBkcml2ZW4gYnkNCj4gdGhlIHRyYW5zcG9y dCBzZWxlY3Rpb24uICBBbmQgdGhpcyBpcyBkZWZpbmVkIGJ5IGV4aXN0aW5nIHRyYW5zcG9ydCBS RkNzIHdoaWNoDQo+IHRoZW1zZWx2ZXMgZGVmaW5lIHN1cHBvcnRlZCBlbmNvZGluZ3MgKGUuZy4s ICJORVRDT05GICsgWE1MIiAsICJSRVNUQ09ORiArDQo+IEpTT04iKS4NCj4gPg0KPiA+IEJ1dCBl bmNvZGluZ3MgY2FuIHZhcnkgKGUuZy4sIHRoZSB1c2Ugb2YgQ0JPUiB3aXRoaW4gZHJhZnQtYmly a2hvbHoteWFuZy1wdXNoLQ0KPiBjb2FwLXByb2JsZW1zdGF0ZW1lbnQpLiAgU3VwcG9ydGluZyB0 aGlzIG5lZWQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIGlkZW50aXR5DQo+ICJjb25maWd1cmFibGUt ZW5jb2RpbmciIGluIHRoZSBZQU5HIG1vZGVsLiAgIEFuZCB0aGlzIGlkZW50aXR5IGRvZXMgc2F5 IHRoYXQNCj4gIkZ1cnRoZXIgZGV0YWlscyBmb3IgYW55IHNwZWNpZmljIGNvbmZpZ3VyYWJsZSBl bmNvZGluZyB3b3VsZCBiZSBleHBsb3JlZCBpbiBhDQo+IHRyYW5zcG9ydCBkb2N1bWVudCBiYXNl ZCBvbiB0aGlzIHNwZWNpZmljYXRpb24uIiAgSSBndWVzcyB0aGlzIGluZm9ybWF0aW9uIGNvdWxk DQo+IGJlIHJlcGVhdGVkIGFzIGEgc2VwYXJhdGUgcmVxdWlyZW1lbnQgaW4gU2VjdGlvbiA1LjMg aWYgeW91IGZlZWwgdGhpcyBpcw0KPiBpbnN1ZmZpY2llbnRseSBkZWZpbmVkLg0KPiANCj4gSSdt IG1vc3RseSBjb25jZXJuZWQgYWJvdXQgdGhlIGNhc2Ugb2YgY29uZmlndXJlZCBzdWJzY3JpcHRp b25zIGFuZCBmdXR1cmUNCj4gZXh0ZW5zaWJpbGl0eS4gIElmIHNvbWVvbmUgd2FudHMgdG8gbWFr ZSBhIG5ldyAiUVVJQyArIENCT1IiIHRyYW5zcG9ydCwgZG8gd2UNCj4gaGF2ZSBhIGNsZWFyIGxp c3Qgb2Ygd2hhdCBkZXRhaWxzIHRoYXQgc3BlY2lmaWNhdGlvbiBuZWVkcyB0byBwcm92aWRlPw0K PiAoRnJvbSBteSByZWFkaW5nIG9mIHRoaXMgZG9jdW1lbnQsIHRoZXJlIHNob3VsZCBiZSBhbiBl eHBsaWNpdCAidGhpcyBpcyB0aGUNCj4gZGVmYXVsdCBlbmNvZGluZyIgc3RhdGVtZW50LCBldmVu IGlmIHRoZXJlIGlzIG9ubHkgb25lIGVuY29kaW5nIHNwZWNpZmllZCBpbiB0aGUNCj4gdHJhbnNw b3J0IHNwZWNpZmljYXRpb24uKQ0KDQpJIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1l bnQgdG8gU2VjdGlvbiA1LjMuLi4NCiJBIHNwZWNpZmljIHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9u IE1VU1QgaWRlbnRpdHkgYW55IGVuY29kaW5nIHN1cHBvcnRlZC4gIFdoZXJlIGEgY29uZmlndXJl ZCBzdWJzY3JpcHRpb24ncyB0cmFuc3BvcnQgYWxsb3dzIGRpZmZlcmVudCBlbmNvZGluZ3MsIHRo ZSBzcGVjaWZpY2F0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGRlZmF1bHQgICAgICAgZW5jb2Rpbmcu Ig0KDQogDQo+ID4gPiBJIGFsc28gdGhpbmsgdGhhdCB3ZSBjb3VsZA0KPiA+ID4gcHJvYmFibHkg cmVxdWlyZSAoYXMgb3Bwb3NlZCB0byAiaGlnaGx5IHJlY29tbWVuZCIgaW4gdGhlIGN1cnJlbnQN Cj4gPiA+IHNlY3VyaXR5DQo+ID4gPiBjb25zaWRlcmF0aW9ucykgdGhhdCB0aGUgdHJhbnNwb3J0 IHByb3ZpZGUgbWVzc2FnZSBjb25maWRlbnRpYWxpdHkNCj4gPiA+IGFuZCBpbnRlZ3JpdHkgcHJv dGVjdGlvbi4NCj4gPg0KPiA+IEkgZm9yIHN1cmUgbGlrZSB0aGUgaWRlYSBvZiBlbmNyeXB0aW9u LiBBbmQgSSBhYnNvbHV0ZWx5IGxpa2UgdGhlIGlkZWEgb2YNCj4gc2lnbmF0dXJlcyB0b28uICBI b3dldmVyIHNldmVyYWwgeWVhcnMgYWdvIG9uIGJhc2VkIG9uIHdvcmsgd2l0aCBNU0RDIC8gY2xv dWQNCj4gcHJvdmlkZXJzIGRlc2lyaW5nIHRlbGVtZXRyeSwgdGhlcmUgd2VyZSByZXF1ZXN0cyBm b3IgZGVwbG95bWVudHMgd2hlcmUgdGhlDQo+IHZvbHVtZSBvZiB0ZWxlbWV0cnkgZ2VuZXJhdGVk IGNvdWxkIG92ZXJ3aGVsbSB0aGUgQ1BVIG9mIHRoZSBob3N0IHJvdXRlci4NCj4gQW5kIGFzIHRo ZSB0ZWxlbWV0cnkgd2FzIGJlaW5nIGRlbGl2ZXJlZCB3aXRoaW4gYSBmdWxseSBwcm90ZWN0ZWQg TVNEQw0KPiBkb21haW4vZW52aXJvbm1lbnQsIHRoZXNlIE1TREMgcHJvdmlkZXJzIHNhaWQgdGhl eSB3YW50ZWQgKmFsbCogdGhlIHJvdXRlcg0KPiBkYXRhIG1vcmUgdGhhbiB0aGV5IG5lZWRlZCBt ZXNzYWdlIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24uDQo+IEkuZS4s IHRoZSB3YW50ZWQgdG8gaGF2ZSBtb3JlIGRhdGEgcmF0aGVyIHRoYW4gYmVpbmcgY29uc3RyYWlu ZWQgdGhlIGhvc3QgQ1BVDQo+IGRvaW5nIGZ1bmN0aW9ucyB3aGljaCByZWR1Y2VkIHRoZSB2b2x1 bWUgb2YgZGF0YSBiZWluZyBkZWxpdmVyZWQuDQo+ID4NCj4gPiBTbyBwZXJzb25hbGx5LCBJIHdh bnQgbG93IHZvbHVtZSB0ZWxlbWV0cnkgd2l0aCBmdWxsIHNlY3VyaXR5IHByb3RlY3Rpb25zDQo+ IGFwcGxpZWQuICBCdXQgYnkgbGVhdmluZyBpdCBhdCAiaGlnaGx5IHJlY29tbWVuZCIgd2UgZG9u J3QgdW5pbnRlbnRpb25hbGx5IGluaGliaXQNCj4gYXBwbGljYWJpbGl0eSB0byBNU0RDIGltcGxl bWVudGF0aW9ucyBpbiBhIHByb3RlY3RlZCBkb21haW4uICBUaGV5IGV4cGxpY2l0bHkNCj4gc2Fp ZCB0aGV5IGRpZG4ndCB3YW50IGl0Lg0KPiANCj4gV2UgZG8gc29tZXRpbWVzIGhhdmUgY2FzZXMg d2hlcmUgd2UgbGVhdmUgYW4gb3BlbmluZyBmb3IgcGVvcGxlIHRvIGFzc2VydA0KPiB0aGF0IHRo ZSBwaHlzaWNhbCBzZWN1cml0eSBvZiB0aGVpciBuZXR3b3JrIHByb3ZpZGVzICJlcXVpdmFsZW50 IHByb3RlY3Rpb24iIHRvDQo+IGNyeXB0b2dyYXBoaWMgY29uZmlkZW50aWFsaXR5L2ludGVncml0 eSBwcm90ZWN0aW9uLCBpZiB3ZSB3YW50IHRvIHRyeSB0bw0KPiB3b3Jkc21pdGggc29tZXRoaW5n LiAgQnV0LCBnaXZlbiB0aGUgYWJvdmUsIEkgd29uJ3QgcHVzaCB2ZXJ5IGhhcmQgb24gdGhpcw0K PiBmcm9udC4NCg0KT2ssIHdpbGwgbGVhdmUgYXMgaXMuDQoNCj4gPiA+IEknbSBhbHNvIHVuc3Vy ZSB0aGF0IEkgcHJvcGVybHkgdW5kZXJzdGFuZCB0aGUgdXNlIG9mIHRoZSAicmVzZXQiDQo+ID4g PiBSUEMgLS0gaWYgaXQgaGFzIG5vIGVmZmVjdCB3aGVuIHRyYW5zaXQgY29ubmVjdGl2aXR5IGFs cmVhZHkgZXhpc3RzLA0KPiA+ID4gdGhlbiB3aGF0IGVudGl0eSBpcyBnb2luZyB0byBjYWxsICJy ZXNldCIgaW4gdGhlIGNhc2Ugb2YgcHVibGlzaGVyIHRpbWVvdXQgd2hlbg0KPiB0cnlpbmcgdG8g cmVhY2ggYSByZWNlaXZlcj8NCj4gPiA+IFN1cmVseSBub3QgdGhlIHB1Ymxpc2hlciBpdHNlbGYs IHNpbmNlIHRoYXQgd291bGQganVzdCBiZQ0KPiA+ID4gcHVibGlzaGVyLWludGVybmFsIGZ1bmN0 aW9uYWxpdHkgd2l0aCBubyBuZWVkIGZvciBhbiBleHRlcm5hbC1mYWNpbmcgUlBDLg0KPiA+DQo+ ID4gVGhlIHJlc2V0IFJQQyBvZiBzZWN0aW9uIDIuNS41IGlzIFlBTkcgbW9kZWwgZXhwb3NlZCBv cGVyYXRpb25hbCBrbm9iIGJhc2VkDQo+IG9uIHRoZSBZQU5HIDEuMSBsYW5ndWFnZSBjb25zdHJ1 Y3QgImFjdGlvbiI6DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2Vj dGlvbi03LjE1DQo+ID4NCj4gPiBBbiBvcGVyYXRpb25hbCBpbnRlcmZhY2UgY2FuIGNhbGwgdGhp cyBhY3Rpb24uICBJLmUuLCBhbiBlbnRpdHkgd2l0aCB0aGUgcHJvcGVyDQo+IGFkbWluaXN0cmF0 aXZlIHByaXZpbGVnZXMgY2FuIGFjY2VzcyAicmVzZXQiLiAgICBUaGlzIG1lYW5zIGEgUkVTVCBp bnRlcmZhY2UgY291bGQNCj4gYmUgZXhwb3NlZCB1cG9uIGEgY29udHJvbGxlciBmb3IgdGhhdCBw dWJsaXNoZXIuICBBbmQgd2hlbiBzb21lYm9keSBmaW5kIHRoYXQNCj4gdGhlIHN1YnNjcmlwdGlv biBpc24ndCByZXNwb25zaXZlIChmb3IgYSB2YXJpZXR5IG9mIHJlYXNvbnMpIHRoYXQgUkVTVCBp bnRlcmZhY2UNCj4gY2FuIGJlIGNhbGxlZCwgYW5kIHRoZSBwdWJsaXNoZXIgY2FuIHN0YXJ0IHRy eWluZyB0byBtYWtlIGNvbm5lY3Rpb25zIChzdWNoIGFzDQo+IFJGQyA4MDcxIGNhbGwgaG9tZSBj b25uZWN0aW9ucykgdG8gYSByZWNlaXZlci4NCj4gDQo+IE9rYXksIHRoYW5rcyBmb3IgaGVscGlu ZyBtZSBvdXQgaGVyZTsgY29uc2lkZXIgdGhpcyBvbmUgcmVzb2x2ZWQuDQo+IA0KPiA+DQo+ID4g PiBJJ20gYWxzbyBhIGxpdHRsZSB1bmNsZWFyIG9uIHRoZSBtZWNoYW5pY3Mgb2YgdGhlIGxpc3Qg b2YNCj4gPiA+IHN1YnNjcmlwdGlvbnMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLiAgRG9lcyBp dCBwcm92aWRlIGEgd2F5IGZvciBhDQo+ID4gPiBsb3ctcHJpdmlsZWdlIGNsaWVudCAodGhhdCBj YW4gb25seSBhY2Nlc3Mgb25lIG9yIGEgaGFuZGZ1bCBvZiB0aGUNCj4gPiA+IHN1YnNjcmlwdGlv bnMpIHRvIGVudW1lcmF0ZSBhbGwgc3Vic2NyaXB0aW9ucyB0aGF0IGV4aXN0LCBpbmNsdWRpbmcN Cj4gPiA+IHN1YnNjcmlwdGlvbnMgdXNlZCBieSBoaWdoLXByaXZpbGVnZSBjbGllbnRzPyAgSWYg c28sIHdlIG1heSB3YW50IHRvDQo+ID4gPiB0aGluayBhYm91dCBzb21lIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHRleHQgdG8gdGhhdCBlZmZlY3Q7IGlmDQo+ID4gPiBub3QsIHdlIG1heSB3YW50 IHRvIHNheSB0aGF0IHRoZSBhY2Nlc3MtY29udHJvbCB3aWxsIGxpbWl0IHdoaWNoIGxlYWZzIGFy ZQ0KPiB2aXNpYmxlIHRvIHNvbWUgY2xpZW50cy4NCj4gPg0KPiA+IFlvdXIgZnVuY3Rpb25hbCBy ZXF1aXJlbWVudHMgY29tcGxldGVseSB2YWxpZC4gIEkgYmVsaWV2ZSB0aGV5IGFyZSBjb3ZlcmVk IGJ5IGENCj4gc2V0IG9mIG90aGVyIFlBTkcgUkZDIHdoaWNoIGRpY3RhdGUgd2hvL3doYXQgY2Fu IGFjY2VzcyB2YXJpb3VzIGVsZW1lbnRzIG9mDQo+IFlBTkcgZGF0YS4gIEdvb2QgZXhhbXBsZSBk b2N1bWVudHMgdG8gbG9vayBhdCBoZXJlIGFyZSBvbmVzIGxpa2U6DQo+ID4NCj4gPiBSRkMtODM0 MSAtIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBBY2Nlc3MgQ29udHJvbCBNb2RlbA0KPiA+DQo+ID4g QW4gdW5kZXJzdGFuZGluZyBvZiB0aGVzZSBkb2N1bWVudHMgYXJlIGFzc3VtZWQsIGFuZCBsaXN0 ZWQgaW4gcGxhY2VzIGxpa2UgdGhlDQo+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFNlY3Rp b24gNS40Lg0KPiANCj4gSSBhZG1pdCB0byBoYXZpbmcgbm90IGZ1bGx5IGFic29yYmVkIHRoZSBO QUNNLCBhbmQgZ2l2ZW4gdGhlIG51bWJlciBvZg0KPiBkb2N1bWVudHMgSSBoYXZlIGxlZnQgdG8g YmFsbG90IG9uIHRoaXMgd2VlaywgSSdsbCB0YWtlIHlvdXIgd29yZCB0aGF0IGl0J3MgY292ZXJl ZA0KPiB3ZWxsIGVub3VnaCB0aGVyZS4NCj4gDQo+ID4gPiBGaW5hbGx5LCB3ZSBoYXZlIGEgZmV3 IGluc3RhbmNlcyBvZiAibGVhZiBmaWx0ZXItZmFpbHVyZS1oaW50Ig0KPiA+ID4gdGhhdCdzIG9m IHR5cGUgInN0cmluZyIsIHByb3ZpZGluZw0KPiA+ID4gICAgICAgICAgICAgICJJbmZvcm1hdGlv biBkZXNjcmliaW5nIHdoZXJlIGFuZC9vciB3aHkgYSBwcm92aWRlZCBmaWx0ZXINCj4gPiA+ICAg ICAgICAgICAgICAgd2FzIHVuc3VwcG9ydGFibGUgZm9yIGEgc3Vic2NyaXB0aW9uLiI7IEkgZG9u J3QNCj4gPiA+IHVuZGVyc3RhbmQgd2h5IGl0J3MgYSBzdHJpbmcgYXMgb3Bwb3NlZCB0byBzb21l IGZvcm0gb2YNCj4gPiA+IG1hY2hpbmUtcmVhZGFibGUgZGF0YS4gIElzIGl0IHN1cHBvc2VkIHRv IGJlIGh1bWFuLXJlYWRhYmxlPyAgRG9lcyB0aGF0DQo+IGJyaW5nIGluIGFueSBpbnRlcm5hdGlv bmFsaXphdGlvbiBjb25zaWRlcmF0aW9ucz8NCj4gPg0KPiA+IFRoZXJlIGFyZSBtYW55IHJlYXNv bnMgd2h5IGEgZmlsdGVyIG1pZ2h0IGZhaWwuICBUaGUgYXV0aG9ycyBkaWRuJ3QgYmVsaWV2ZSB0 aGF0DQo+IHRoZXJlIHdhcyBlbm91Z2ggb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB0byBzdWZmaWNp ZW50bHkgZG9jdW1lbnQgdGhlIHVuaXZlcnNlDQo+IG9mIGZhaWx1cmUgdHlwZXMgYWNyb3NzIHRo ZSBzZXQgb2YgaW50ZXJlc3RlZCBwYXJ0aWVzLiAgQXMgYSByZXN1bHQsIHRoZSBvcHRpb24NCj4g c2VlbWVkIHRvIGJlIHRvIHByb3ZpZGUgbm8gZ3VpZGFuY2Ugb24gdGhlIGZhaWx1cmUgcmVhc29u LCBvciB0byBsZXQgdGhlIHZlbmRvcnMNCj4gcHJvdmlkZSBzb21lIGd1aWRhbmNlIChhbGJlaXQg anVzdCBhICdzdHJpbmcnKS4gIFNvIGF0IHRoaXMgcG9pbnQgd2l0aCB0aGUNCj4gc3BlY2lmaWNh dGlvbiwgaXQgd291bGQgYmUgdXAgdG8gdGhlIHZlbmRvciB0byBkZXRlcm1pbmUgd2hldGhlciBp dCBpcyBodW1hbg0KPiByZWFkYWJsZSwgb3Igd2hldGhlciBpbnRlcm5hdGlvbmFsaXphdGlvbiBj b25zaWRlcmF0aW9ucyBzaG91bGQgYmUgY292ZXJlZC4NCj4gSG9wZWZ1bGx5IHdpdGggZW5vdWdo IGRlcGxveW1lbnRzIHRoaXMgbWlnaHQgYmUgcmV2aXNpdGVkIGF0IGEgZnV0dXJlIGRhdGUuDQo+ IA0KPiBXZSBzaG91bGQgcHJvYmFibHkgdGhpbmsgYWJvdXQgc2F5aW5nIHNvbWV0aGluZyBhYm91 dCBob3cgaXRzIHN5bnRheCBhbmQNCj4gc2VtYW50aWNzIGFyZSBpbXBsZW1lbnRhdGlvbi1zcGVj aWZpYywgdGhlbiAtLSB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgcmVhbA0KPiBndWlkYW5jZSBm b3IgaG93IHRvIHVzZSBpdCwgYXQgcHJlc2VudC4NCg0KQWRkZWQgdGV4dCBpbiBsZWFmIHRvIGNs YXJpZnkgdGhpcyBhcHByb2FjaC4uLg0KDQogICAgICBsZWFmIGZpbHRlci1mYWlsdXJlLWhpbnQg eyANCiAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAg ICAgICJJbmZvcm1hdGlvbiBkZXNjcmliaW5nIHdoZXJlIGFuZC9vciB3aHkgYSBwcm92aWRlZCBm aWx0ZXINCiAgICAgICAgICAgICB3YXMgdW5zdXBwb3J0YWJsZSBmb3IgYSBzdWJzY3JpcHRpb24u IFRoZSBzeW50YXggYW5kDQogICAgICAgICAgICAgc2VtYW50aWNzIG9mIHRoaXMgaGludCBhcmUg aW1wbGVtZW50YXRpb24tc3BlY2lmaWMuIjsNCiAgICAgIH0NCg0KPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiA+IC0tDQo+ID4gPiBDT01NRU5UOg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0tDQo+ ID4gPg0KPiA+ID4gU2VjdGlvbiAxLjMNCj4gPiA+DQo+ID4gPiAgICBBbHNvIG5vdGUgdGhhdCB0 cmFuc3BvcnQgc3BlY2lmaWMgdHJhbnNwb3J0IGRyYWZ0cyBiYXNlZCBvbiB0aGlzDQo+ID4gPiAg ICBzcGVjaWZpY2F0aW9uIE1VU1QgZGV0YWlsIHRoZSBsaWZlIGN5Y2xlIG9mIGR5bmFtaWMgc3Vi c2NyaXB0aW9ucywgYXMNCj4gPiA+ICAgIHdlbGwgYXMgdGhlIGxpZmVjeWNsZSBvZiBjb25maWd1 cmVkIHN1YnNjcmlwdGlvbnMgKGlmIHN1cHBvcnRlZCkuDQo+ID4gPg0KPiA+ID4gSSdtIG5vdCBz dXJlIEkgdW5kZXJzdGFuZCB3aGF0IGFkZGl0aW9uYWwgc3BlY2lmaWNhdGlvbiBpcyBuZWVkZWQN Cj4gPiA+IGZvciB0aGUgbGlmZWN5Y2xlIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyAtLSBk b2Vzbid0IHRoZQ0KPiA+ID4gcHJldmlvdXMgdGV4dCB0aWdodGx5IHRpZSB0aGVpciBsaWZlY3lj bGUgdG8gdGhlIHByZXNlbmNlIG9mIGNvbmZpZ3VyYXRpb24gaW4gdGhlDQo+IGNvbmZpZ3VyYXRp b24gZGF0YXN0b3JlPw0KPiA+DQo+ID4gRm9yIHRoZSBtb3N0IHBhcnQgaXQgZG9lcy4gIEhvd2V2 ZXIgdGhlcmUgaXMgYSByZWxhdGlvbnNoaXAgZm9yIGV4YWN0bHkgd2hlbiB0bw0KPiBlc3RhYmxp c2ggdHJhbnNwb3J0IGNvbm5lY3Rpdml0eSBiYXNlZCBvbiB0aGUgc3RhdGUgb2YgZWFjaCByZWNl aXZlciBvZiBhDQo+IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLg0KPiA+DQo+ID4gQXMgYW4gZXhh bXBsZSBvZiB3aGF0IHNob3VsZCBiZSBzcGVjaWZpZWQsIHNlZSBTZWN0aW9uIDUuMiBvZg0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1uZXRj b25mLWV2ZW50LW5vdGkNCj4gPiBmaWNhdGlvbnMvMTAvIEhlcmUgeW91IGNhbiBzZWUgaG93IE5F VENPTkYgY2FsbCBob21lIGlzIGludm9rZWQgYXQgdGhlDQo+ID4gcHJvcGVyIHBvaW50cyBpbiB0 aGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gc3RhdGUgbWFjaGluZS4NCj4gDQo+IEFoLCB0aGFu a3MgZm9yIHRoZSBwb2ludGVyLg0KPiANCj4gPiA+IG5pdDogcGxlYXNlIGJlIGNvbnNpc3RlbnQg YWJvdXQgImxpZmUgY3ljbGUiIHZzLiAibGlmZWN5Y2xlIiB0aHJvdWdob3V0Lg0KPiA+DQo+ID4g Rml4ZWQgbml0IHRvICJsaWZlY3ljbGUiLg0KPiA+DQo+ID4gPiBTZWN0aW9uIDIuMQ0KPiA+ID4N Cj4gPiA+ICAgIEFuIGV2ZW50IHN0cmVhbSBpcyBhIG5hbWVkIGVudGl0eSBvbiBhIHB1Ymxpc2hl ciB3aGljaCBleHBvc2VzIGENCj4gPiA+ICAgIGNvbnRpbnVvdXNseSB1cGRhdGluZyBzZXQgb2Yg WUFORyBlbmNvZGVkIGV2ZW50IHJlY29yZHMuICBbLi4uXQ0KPiA+ID4NCj4gPiA+IG5pdDogSSBk b24ndCB0aGluayAiWUFORyBlbmNvZGVkIiBpcyB3ZWxsLWRlZmluZWQgKGhlcmUgYW5kIGJlbG93 KSwNCj4gPiA+IGluIHRoYXQgWUFORyBzdHJ1Y3R1cmVzIGdlbmVyYXRlIGRhdGEgbW9kZWxzIGJ1 dCBjYW4gYmUgZW5jb2RlZCBpbnRvDQo+ID4gPiB2YXJpb3VzIGZvcm1hdHMgKGxpa2UgWE1MIGFu ZCBKU09OKS4NCj4gPg0KPiA+IFRoaXMgaXMgdHJ1ZS4gIEkgbWFkZSB0aGUgdHdvIG9jY3VycmVu Y2VzIG9mICJZQU5HIGVuY29kZWQiIGludG8gIllBTkcNCj4gZGVmaW5lZCIuDQo+ID4NCj4gPiA+ IFNlY3Rpb24gMi4zDQo+ID4gPg0KPiA+ID4gICAgSWYgdGhlIHB1Ymxpc2hlciBzdXBwb3J0cyB0 aGUgImRzY3AiIGZlYXR1cmUsIHRoZW4gYSBzdWJzY3JpcHRpb24NCj4gPiA+ICAgIHdpdGggYSAi ZHNjcCIgbGVhZiBNVVNUIHJlc3VsdCBpbiBhIGNvcnJlc3BvbmRpbmcgW1JGQzI0NzRdIERTQ1AN Cj4gPiA+ICAgIG1hcmtpbmcgYmVpbmcgcGxhY2VkIHdpdGhpbiB0aGUgSVAgaGVhZGVyIG9mIGFu eSByZXN1bHRpbmcNCj4gPiA+ICAgIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBhbmQgc3Vic2NyaXB0 aW9uIHN0YXRlIGNoYW5nZSBub3RpZmljYXRpb25zLg0KPiA+ID4gICAgV2hlcmUgVENQIGlzIHVz ZWQsIGEgcHVibGlzaGVyIHdoaWNoIHN1cHBvcnRzIHRoZSAiZHNjcCIgZmVhdHVyZQ0KPiA+ID4g ICAgU0hPVUxEIGVuc3VyZSB0aGF0IGEgc3Vic2NyaXB0aW9uJ3Mgbm90aWZpY2F0aW9uIG1lc3Nh Z2VzIGFyZQ0KPiA+ID4gICAgcmV0dXJuZWQgd2l0aGluIGEgc2luZ2xlIFRDUCB0cmFuc3BvcnQg c2Vzc2lvbiB3aGVyZSBhbGwgdHJhZmZpYw0KPiA+ID4gICAgc2hhcmVzIHRoZSBzdWJzY3JpcHRp b24ncyAiZHNjcCIgbGVhZiB2YWx1ZS4gIFdoZXJlIHRoaXMgY2Fubm90IGJlDQo+ID4gPiAgICBn dWFyYW50ZWVkLCBhbnkgImVzdGFibGlzaCBzdWJzY3JpcHRpb24iIFJQQyByZXF1ZXN0IFNIT1VM RCBiZQ0KPiA+ID4gICAgcmVqZWN0ZWQgd2l0aCBhICJkc2NwLXVuYXZhaWxhYmxlIiBlcnJvcg0K PiA+ID4NCj4gPiA+IEkgY2FuJ3QgZGVjaWRlIHdoZXRoZXIgd2UgbmVlZCB0byBiZSBtb3JlIGV4 cGxpY2l0IGluIHRoZSBzZWNvbmQNCj4gPiA+IGFuZC9vciB0aGlyZCBzZW50ZW5jZXMgdGhhdCB0 aGlzIHJlbWFpbnMgY29udGluZ2VudCBvbiB0aGUNCj4gPiA+IHN1YnNjcmlwdGlvbiBpbiBxdWVz dGlvbiBoYXZpbmcgYSAiZHNjcCIgbGVhZi4NCj4gPg0KPiA+IFRoZSBzZW50ZW5jZXMgd2VyZSBh bHJlYWR5IGxvbmcsIGl0IGZlZWxzIHRvIG1lIGxpa2UgaXQgd291bGQgYmUgbW9yZQ0KPiBjb25m dXNpbmcgdG8gcHV0IGluIG1vcmUgd29yZHMgaGVyZS4NCj4gPg0KPiA+ID4gbml0OiBlbmQgc2Vu dGVuY2Ugd2l0aCBhIGZ1bGwgc3RvcA0KPiA+DQo+ID4gUGVyaW9kIGFkZGVkLg0KPiA+DQo+ID4g PiBJIHNoYXJlIHRoZSBUU1YtQVJUIHJldmlld2VyJ3MgY29uZnVzaW9uIGFib3V0IGhvdyB0aGUg d2VpZ2h0aW5nIChhcw0KPiA+ID4gd2VsbCBhcw0KPiA+ID4gRFNDUCkgZnVuY3Rpb25hbGl0eSBp cyBpbnRlbmRlZCB0byB3b3JrLg0KPiA+DQo+ID4gU2hvcnQgYW5zd2VyOiAgRWFybGllciB2ZXJz aW9ucyBvZiB0aGlzIGRyYWZ0IG1hZGUgZXhwbGljaXQgcGFyYWxsZWxzIG9mIHRoZQ0KPiB3ZWln aHRpbmcgbWV0aG9kIHRvIEhUVFAyIFJGQy03NDUwIHNlY3Rpb24gNS4zLjIuICBUaGUgb3BlcmF0 aW9uIG9mIHdlaWdodGluZw0KPiBpcyBleGFjdGx5IHRoZSBzYW1lIEhUVFAyIGRlcGVuZGVuY3kg d2VpZ2h0aW5nLiAgVGhlcmUgaXMgYWRkaXRpb25hbCBkZWZpbml0aW9uDQo+IG9mIGhvdyB0aGlz IGlzIHN1cHBvc2VkIHRvIHdvcmsgaW4gU2VjdGlvbiA0IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1y ZXN0Y29uZi1ub3RpZg0KPiAod2hpY2ggaXMgYWxzbyBjdXJyZW50bHkgdXAgZm9yIHJldmlldyku DQo+ID4NCj4gPiBMb25nIGFuc3dlcjogVFNWLUFSVCBpcyBhYnNvbHV0ZWx5IGNvcnJlY3QgdGhh dCBhIHB1Ymxpc2hlciBtaWdodCBnZW5lcmF0ZSBhDQo+IGxvdCBvZiB0cmFmZmljLiAgSW4gbWFu eSB3YXlzLCBoaWdoIHRyYWZmaWMgdm9sdW1lcyB3b3VsZCBiZSBhIHN1Y2Nlc3NmdWwgb3V0Y29t ZQ0KPiBmb3IgdGhpcyB3b3JrLiAgIEFzIGEgcmVzdWx0LCBtaXRpZ2F0aW5nIGRpZmZlcmVudCBk aW1lbnNpb25zIG9mIHRoaXMgdm9sdW1lIHJpc2sgaGFzDQo+IGJlZW4gYSBkZXNpZ24gZ29hbCBz aW5jZSB0aGlzIGVmZm9ydOKAmXMgaW5jZXB0aW9uLiAgQW5kIHRoaXMgaXMgdGhlIHJlYXNvbiBy b2J1c3QNCj4gUW9TIG1lY2hhbmlzbXMgd2VyZSBpbmNsdWRlZC4gIFRoaXMgaW5jbHVkZXMgYm90 aCBEU0NQIGFuZCB3ZWlnaHRpbmcuDQo+ID4NCj4gPiBIZXJlIGlzIGEgcXVpY2sgc3VtbWFyeSBv ZiBzb21lIFFvUyBtZWNoYW5pc21zIGF2YWlsYWJsZSBpbiB0aGlzIGRyYWZ0Li4uDQo+ID4NCj4g PiAxLiBUaGUgcHVibGlzaGVyIGlzIGFsbG93ZWQgdG8gZGVjbGluZSBhIGR5bmFtaWMgc3Vic2Ny aXB0aW9uLiAgT25lIG9mIHRoZXNlDQo+IHJlYXNvbnMgaXMgdGhhdCB0aGUgaW5jcmVtZW50YWwg dHJhZmZpYyBnZW5lcmF0ZWQgYnkgYSBwYXJ0aWN1bGFyIGluY3JlbWVudGFsDQo+IHN1YnNjcmlw dGlvbiB3aWxsIGJlIHRvbyBoaWdoLiAgVGhlcmUgYXJlIGVycm9ycyBiYWNrIHRvIHRoZSBzdWJz Y3JpYmVyIGluZGljYXRpbmcNCj4gdGhpcyBjb25kaXRpb24gZXhpc3QuDQo+ID4gMi4gQSBwdWJs aXNoZXIgY2FuIHN1c3BlbmQgYW55IHN1YnNjcmlwdGlvbiBmb3IgY2FwYWNpdHkgcmVhc29ucywg YW5kIGENCj4gcmVjZWl2ZXIgbXVzdCBiZSBhYmxlIHRvIGdyYWNlZnVsbHkgYWNjZXB0IHRoaXMg c3VzcGVuc2lvbi4NCj4gPiAzLiBNdWNoIGxpa2Ugd2l0aCBIVFRQMiBzdHJlYW1zLCBoaWdoZXIg cHJpb3JpdHkgc3Vic2NyaXB0aW9ucyBpbnRlbmRlZCBmb3IgYQ0KPiBwYXJ0aWN1bGFyIHJlY2Vp dmVyIGNhbiBiZSBkZXF1ZXVlZCBmaXJzdCBmcm9tIGEgcHVibGlzaGVyLg0KPiA+IDQuIE11Y2gg bGlrZSB3aXRoIEhUVFAyIHN0cmVhbXMsIHByb3BvcnRpb25hbCBzdWJzY3JpcHRpb24gZGVxdWV1 aW5nDQo+IGludGVuZGVkIGZvciBhIHBhcnRpY3VsYXIgcmVjZWl2ZXIgY2FuIGJlIHBlcmZvcm1l ZCBhIHB1Ymxpc2hlci4NCj4gPiA1LiBEU0NQIG1hcmtpbmdzIGNhbiBiZSBwbGFjZWQgb24gc3Vi c2NyaWJlZCBkYXRhLg0KPiA+IDYuIE1lY2hhbmlzbXMgZm9yIGRldGVjdGluZyBhbmQgcmVhY3Rp bmcgdG8gZGlmZmVyZW50IHR5cGVzIG9mIHN1YnNjcmliZWQgZGF0YQ0KPiBsb3NzIGhhdmUgYmVl biBlbWJlZGRlZC4NCj4gPiA3LiBNZXRob2RzIGhhdmUgYmVlbiBpbmNsdWRlZCB0byBlbnN1cmUg YSBjb25maWd1cmVkIHJlY2VpdmVyIOKAnG9r4oCZc+KAnQ0KPiA+IGluZm9ybWF0aW9uIHB1c2gg YmVmb3JlIHN1YnNjcmliZWQgZGF0YSBpcyBzZW50LiAoVGhpcyBzaG91bGQgcmVkdWNlIG9uZSBE RG9TDQo+IHZlY3Rvci4pIDguIEtlZXAgYWxpdmUgbWVjaGFuaXNtcyBhcmUgZXN0YWJsaXNoZWQg Zm9yIGRpZmZlcmVudCB0cmFuc3BvcnQgdHlwZXMsDQo+IHNvIHRoYXQgc3Vic2NyaWJlZCBkYXRh IGlzbuKAmXQgYmVpbmcgc2VudCB3aGVuIHRoZSBpcyBubyByZWNlaXZlciBsaXN0ZW5pbmcuDQo+ ID4NCj4gPiBNZWNoYW5pc20gKDQpIGlzIGluIHF1ZXN0aW9uIGhlcmUuICAgQXMgZGVmaW5lZCBi eSBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtDQo+IG5vdGlmLCB0aGlzIGlzIHN1cHBvc2Vk IHRvIHdvcmsgaWRlbnRpY2FsbHkgdG8gSFRUUDIgUkZDLTc0NTAgc2VjdGlvbiA1LjMuMi4NCj4g SG93ZXZlciB0aGVyZSB3ZXJlIFdHIG1lbWJlcnMgd2hvIGRpZCBub3Qgd2FudCB0byBpbmNsdWRl IGEgZnVuY3Rpb25hbA0KPiByZXF1aXJlbWVudCBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoYXQg SFRUUDIgdHJhbnNwb3J0IGluIHRoaXMgZG9jdW1lbnQNCj4gaG93ZXZlci4gIFRoZXJlZm9yZSB0 aGUgcmVmZXJlbmNlIHRvIEhUUDIgd2FzIHJlbW92ZWQuDQo+ID4NCj4gPiBJbiB0aGUgZW5kLCBJ IGRvbid0IHRoaW5rIHdlIGNhbiBhZmZvcmQgdG8gZ2V0IHJpZCBvZiBzdXBwb3J0IGZvciAoNCkg ZnJvbSB0aGUNCj4gc3BlY2lmaWNhdGlvbi4gICBUaGlzIHdlaWdodGluZyBjYXBhYmlsaXR5IGlz IHF1aXRlIHBvd2VyZnVsLCBhbmQgY2FuIGVhc2lseSBiZQ0KPiBhZGRlZCB0byBHUlBDIGJhc2Vk IHN1YnNjcmlwdGlvbiBhbHRlcm5hdGl2ZXMuDQo+IA0KPiBJIGRvbid0IHRoaW5rIEkgd2FzIHRy eWluZyB0byBzdWdnZXN0IHJlbW92aW5nIHRoZSBtZWNoYW5pc20gZW50aXJlbHkuDQo+IFdoYXQg eW91J3ZlIHdyaXR0ZW4gaGVyZSBpbmNsdWRlcyBhIG1lbnRhbCBtb2RlbCBvZiBoYXZpbmcgbG9j YWwgcXVldWVzIG9mDQo+IG1lc3NhZ2VzIHRoYXQgZ2V0IGRlcXVldWVkIGFjY29yZGluZyB0byBh IHNwZWNpZmljIGFsZ29yaXRobSwgYW5kIHRoZSB3ZWlnaHRzDQo+IGluZmx1ZW5jaW5nIHRoZSBy YXRlIG9mIGRlcXVldWluZyBhY3Jvc3MgcXVldWVzOyB0aGF0IG1lbnRhbCBtb2RlbCAoY29tYmlu ZWQNCj4gd2l0aCB0aGUga25vd2xlZGdlIHRoYXQgbGFyZ2VyIHdlaWdodCB2YWx1ZXMgZ2V0IG1v cmUgdHJhZmZpYw0KPiBmYXN0ZXIpIGdpdmVzIG1lIHRoZSBwaWN0dXJlIEkgd2FudGVkIGZvciAi aG93IGl0J3Mgc3VwcG9zZWQgdG8gd29yayIuDQo+IE1heWJlIHdlIGNvdWxkIGRpc3RpbGwgdGhh dCBkb3duIGEgYml0IGFuZCBwdXQgaXQgaW4gdGhlIGRyYWZ0LCBhcyB0aGUgY3VycmVudCB0ZXh0 DQo+IGhhZCBzb21lIGxldmVsIG9mICJtYWdpYyBvY2N1cnMgaGVyZSIsIHRvIG1lLg0KDQpJIGFt IGhvcGluZyB0byBsZWF2ZSB0aGluZ3MgYXMgdGhleSBhcmUgZm9yIG5vdy4gIEJhc2ljYWxseSB0 aGUgbWFnaWMgdGhhdCBvY2N1cnMgY2FuIGJlIGdsZWFuZWQgZnJvbSBTZWN0aW9uIDQgb2YgZHJh ZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLiAgIEFuZCBub2JvZHkgaW4gdGhlIE5FVENP TkYgd29ybGQgaXMgbGlrZWx5IHRvIGltcGxlbWVudCB0aGlzIHR5cGUgb2YgRGVxdWV1aW5nLCBz byB0aGV5IHNob3VsZG4ndCBoYXZlIHRoZSBleHRyYSB0ZXh0IGluIHRoZSBiYXNlIHNwZWNpZmlj YXRpb24gdHJpcCB0aGVtIHVwLi4gICANCg0KPiA+ID4gU2VjdGlvbiAyLjQuMi4xDQo+ID4gPg0K PiA+ID4gICAgUmVwbGF5IHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIGVzdGFibGlzaCBhIHN1YnNj cmlwdGlvbiB3aGljaCBpcyBhbHNvDQo+ID4gPiAgICBjYXBhYmxlIG9mIHBhc3NpbmcgcmVjZW50 bHkgZ2VuZXJhdGVkIGV2ZW50IHJlY29yZHMuICBJbiBvdGhlcg0KPiA+ID4gd29yZHMsDQo+ID4g Pg0KPiA+ID4gbml0L2VkaXRvcmlhbDogdGhpcyBsYW5ndWFnZSBjb3VsZCBwcm9iYWJseSBiZSBt b3JlIGNsZWFyIGFib3V0DQo+ID4gPiAicmVjZW50bHkgZ2VuZXJhdGVkIiBtZWFuaW5nICJpbiB0 aGUgcGFzdCIsIHRoYXQgaXMsIHJlY29yZHMgZm9yDQo+ID4gPiBldmVudHMgdGhhdCBoYXZlIGFs cmVhZHkgaGFwcGVuZWQgd2hlbiB0aGUgc3Vic2NyaXB0aW9uIGlzIGVzdGFibGlzaGVkLg0KPiA+ DQo+ID4gVHdlYWtlZCB0byAiZXZlbnQgcmVjb3JkcyBnZW5lcmF0ZWQgaW4gdGhlIHJlY2VudCBw YXN0Ig0KPiA+DQo+ID4gPiBTZWN0aW9uIDIuNC4zDQo+ID4gPg0KPiA+ID4gICAgYW55IG51bWJl ciBvZiB0aW1lcy4gIER5bmFtaWMgc3Vic2NyaXB0aW9ucyBjYW4gb25seSBiZSBtb2RpZmllZCB2 aWENCj4gPiA+ICAgIHRoaXMgUlBDIHVzaW5nIGEgdHJhbnNwb3J0IHNlc3Npb24gY29ubmVjdGlu ZyB0byB0aGUgc3Vic2NyaWJlci4NCj4gPiA+IElmDQo+ID4gPg0KPiA+ID4gbml0KD8pOiBpcyB0 aGlzIG1vcmUgcmVhZGFibGUgYXMgImNvbm5lY3RpbmcgdG8iIG9yICJjb25uZWN0aW5nIGZyb20i DQo+ID4gPiB0aGUgc3Vic2NyaWJlcj8gIChUaGUgc2FtZSB3b3JkaW5nIHNob3dzIHVwIHRocm91 Z2hvdXQgdGhlIGRvY3VtZW50LA0KPiA+ID4gYnV0IEknbGwgdHJ5IHRvIGp1c3QgY29tbWVudCBv bmNlLikNCj4gPg0KPiA+IEkgZXhwZWN0IHRoYXQgaXQgc2hvdWxkIGJlIGNsZWFyIGVub3VnaCBl aXRoZXIgd2F5LiAgSSBiZWxpZXZlIGxlYXZpbmcgdGhlIGN1cnJlbnQNCj4gdGV4dCBzaG91bGQg bm90IGltcGFjdCBpbXBsZW1lbnRhdGlvbnMuDQo+ID4NCj4gPiA+IFNlY3Rpb24gMi40LjUNCj4g PiA+DQo+ID4gPiBJcyB0aGVyZSBhbnkgZGlzdGluY3Rpb24gYmV0d2VlbiAia2lsbGluZyBhIHN1 YnNjcmlwdGlvbiIgYW5kDQo+ID4gPiAiYWRtaW5pc3RyYXRpdmVseSBkZWxldGluZyBhIHN1YnNj cmlwdGlvbiI/ICBJdCdzIHVuY2xlYXIgdG8gbWUgdGhhdA0KPiA+ID4gd2UgbmVlZCB0aGUgZXh0 cmEgY29ubm90YXRpb25zIG9mIHRoZSB3b3JkICJraWxsIiwgaGVyZS4NCj4gPg0KPiA+IFdlIGNo b3NlIHRvIHVzZSBhIGRpZmZlcmVudCBSUEMgbmFtZSBzbyB0aGF0IGFkbWluaXN0cmF0aXZlIGFj Y2VzcyBjb250cm9sDQo+IHBlcm1pc3Npb25zIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGtpbGwt c3Vic2NyaXB0aW9uIGFuZCBkZWxldGUtc3Vic2NyaXB0aW9uDQo+IHdvdWxkIGJlIGV4cGxpY2l0 IGFuZCBvYnZpb3VzLiAgQW5kIG9uY2Ugd2UgaGFkIGEgbmV3IFJQQyBuYW1lLCBpdCBzZWVtZWQN Cj4gZWFzaWVyIGZvciB0aGUgcmVhZGVyIHRvIGNvbnRpbnVlIHVzaW5nIHRoZSAia2lsbCIgd29y ZCBmb3IgdGhhdCBSUEMuDQo+IA0KPiBJbiB2YWN1dW0sICJhZG1pbi1kZWxldGUtc3Vic2NyaXB0 aW9uIiBzZWVtcyBsaWtlIGEgZmluZSBuYW1lLCB0byBtZS4gIEJ1dCB0aGlzDQo+IGlzIGEgbm9u LWJsb2NraW5nIGNvbW1lbnQgc28gSSdsbCBzdG9wIHB1c2hpbmcgbm93Lg0KPiANCj4gPiA+IFNl Y3Rpb24gMi40LjYNCj4gPiA+DQo+ID4gPiAgICBBcyBhIHJlc3VsdCBvZiB0aGlzIG1peHR1cmUs IGhvdyBzdWJzY3JpcHRpb24gZXJyb3JzIGFyZSBlbmNvZGVkDQo+ID4gPg0KPiA+ID4gbml0OiAi bWl4dHVyZSIgZG9lc24ndCBzZWVtIGxpa2UgdGhlIHJpZ2h0IHdvcmQgdG8gbWU7ICJ2YXJpZXR5 IiBvcg0KPiA+ID4gInZhcmllZCBwb3B1bGF0aW9uIiBhcmUgdGhlIGZpcnN0IGFsdGVybmF0aXZl cyB0aGF0IGNvbWUgdG8gbWluZCwNCj4gPiA+IHRob3VnaCB0aGV5IGFyZSBub3QgcGVyZmVjdCBl aXRoZXIuDQo+ID4NCj4gPiBDaGFuZ2VkIHRvICd2YXJpZXR5Jy4NCj4gPg0KPiA+ID4gSXMgdGhl cmUgc29tZSBzb3J0IG9mICJhY2Nlc3MgZGVuaWVkIiBlcnJvciB0aGF0IGNvdWxkIHJlc3VsdCBm cm9tDQo+ID4gPiBraWxsLSBzdWJzY3JpcHRpb24gUlBDcz8gIChUaGUgdGFibGUvYXJ0d29yayBv bmx5IGxpc3RzDQo+ID4gPiAibm8tc3VjaC1zdWJzY3JpcHRpb24iLikNCj4gPg0KPiA+IEFjY2Vz cyBkZW5pZWQgd2hlbiBhbiBSUEMgZmFpbHMgYWNjZXNzIGNvbnRyb2wgaXMgcGFydCBvZiB0aGUg YmFzZSB0cmFuc3BvcnQNCj4gZXJyb3IgdHlwZXMgZm9yIHRoZSBSUEMuICAgSS5lLiwgdHJhbnNw b3J0cyBsaWtlIE5FVENPTkYgYW5kIFJFU1RDT05GIGFscmVhZHkNCj4gaGF2ZSBub24tc3Vic2Ny aXB0aW9uLXNwZWNpZmljIGVycm9ycyBsaWtlIHRoaXMgb25lIGFscmVhZHkgY292ZXJlZC4NCj4g DQo+IEFoLCBvZiBjb3Vyc2UsIGFuZCB3ZSByZXF1aXJlIHByb2Nlc3Npbmcgb2YgdHJhbnNwb3J0 LWxldmVsIGVycm9ycyBiZWZvcmUgdGhlc2UNCj4gb25lcywgc28gaXQgYWxsIHdvcmtzIG91dCBm aW5lLg0KPiANCj4gPiA+IFNlY3Rpb24gMi41DQo+ID4gPg0KPiA+ID4gSXQncyBpbnRlcmVzdGlu ZyB0byBzZWUgYSBzbGlnaHQgZGljaG90b215IGJldHdlZW4gZHluYW1pYyBhbmQNCj4gPiA+IGNv bmZpZ3VyZWQgc3Vic2NyaXB0aW9ucywgaW4gdGhhdCAoSUlVQykgZm9yIGR5bmFtaWMgc3Vic2Ny aXB0aW9ucywNCj4gPiA+IGEgbW9kaWZpY2F0aW9uIGV2ZW50IHVuLSBzdXNwZW5kcyBhIHN1YnNj cmlwdGlvbiBpbW1lZGlhdGVseSwgYnV0DQo+ID4gPiBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRp b25zIHRoZSBwdWJsaXNoZXIgc2VlbXMgdG8gaGF2ZSBzb21lDQo+ID4gPiBsYXRpdHVkZSB0byBy ZXRhaW4gdGhlIHN1YnNjcmlwdGlvbiBpbiB0aGUgc3VzcGVuZGVkIHN0YXRlIGZvciBzb21lDQo+ ID4gPiB0aW1lIGJlZm9yZSB1bi1zdXNwZW5kaW5nIGl0IGFuZCBzZW5kaW5nIHRoZSAic3Vic2Ny aXB0aW9uLW1vZGlmaWVkIiBzdGF0ZQ0KPiBjaGFuZ2UgbWVzc2FnZS4NCj4gPiA+DQo+ID4gPiAg ICAgICAgICAgICAgICAgIEluIHRoaXMgY2FzZSwgYSBzZXBhcmF0ZSBkeW5hbWljIHN1YnNjcmlw dGlvbiBjYW4gYmUNCj4gPiA+ICAgIGVzdGFibGlzaGVkIHRvIHJldHJhbnNtaXQgdGhlIG1pc3Np bmcgZXZlbnQgcmVjb3Jkcy4NCj4gPiA+DQo+ID4gPiBEbyB5b3Ugd2FudCB0byBwdXQgaW4gYSBw b2ludGVyIHRvIHJlcGxheS1zdGFydC10aW1lIGhlcmU/DQo+ID4NCj4gPiBJIHRob3VnaHQgZ2V0 dGluZyB0byB0aGF0IGxldmVsIG9mIGRldGFpbCBpbiB0aGUgaW50cm8gd2FzIGNvbmZ1c2luZyBm b3IgdGhpcyBpbnRybw0KPiBzZWN0aW9uLg0KPiANCj4gT2theS4gIChNYXliZSBhIHBhcmVudGhl dGljYWwgInJlcGxheSIgYXMgYSBzZWFyY2ggdGVybSB3b3VsZCBoZWxwIHdpdGhvdXQNCj4gYmVp bmcgY29uZnVzaW5nLCBidXQgZW50aXJlbHkgeW91ciBjYWxsLikNCg0KSSB3aWxsIGxlYXZlIGFz LWlzLg0KDQo+ID4gPiBTZWN0aW9uIDIuNS4xDQo+ID4gPg0KPiA+ID4gICAgICAgICAgRXZlbnQg cmVjb3JkcyBhcmUgb25seSBzZW50IHRvIGFjdGl2ZSByZWNlaXZlcnMuICBSZWNlaXZlcnMgb2YN Cj4gPiA+ICAgIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gcmVtYWluIGFjdGl2ZSBpZiBib3Ro IHRyYW5zcG9ydA0KPiA+ID4gICAgY29ubmVjdGl2aXR5IGNhbiBiZSB2ZXJpZmllZCB0byB0aGUg cmVjZWl2ZXIsIGFuZCBldmVudCByZWNvcmRzIGFyZQ0KPiA+ID4gICAgbm90IGJlaW5nIGRyb3Bw ZWQgZHVlIHRvIGEgcHVibGlzaGVyIGJ1ZmZlciBvdmVyZmxvdy4gIFsuLi5dDQo+ID4gPg0KPiA+ ID4gbml0OiAiYnVmZmVyIG92ZXJmbG93IiBpcyBhIHRlY2huaWNhbCB0ZXJtIGluIHNlY3VyaXR5 IGNpcmNsZXMNCj4gPiA+IGluZGljYXRpbmcgYSBwb3RlbnRpYWxseSBleHBsb2l0YWJsZSBzZWN1 cml0eSBmbGF3OyB3b3VsZCAicHVibGlzaGVyDQo+ID4gPiBidWZmZXIgY2FwYWNpdHkgYmVpbmcg cmVhY2hlZCIgYmUgYW4gYWNjZXB0YWJsZSBzdWJzdGl0dXRlIChoZXJlIGFuZA0KPiBiZWxvdyk/ DQo+ID4NCj4gPiBDaGFuZ2UgbWFkZQ0KPiA+DQo+ID4gPiBTZWN0aW9uIDIuNy43DQo+ID4gPg0K PiA+ID4gICAgVGhpcyBub3RpZmljYXRpb24gaW5kaWNhdGVzIHRoYXQgYWxsIG9mIHRoZSBldmVu dCByZWNvcmRzIHByaW9yIHRvDQo+ID4gPiAgICB0aGUgY3VycmVudCB0aW1lIGhhdmUgYmVlbiBw YXNzZWQgdG8gYSByZWNlaXZlci4gIEl0IGlzIHNlbnQgYmVmb3JlDQo+ID4gPiAgICBhbnkgbm90 aWZpY2F0aW9uIG1lc3NhZ2UgY29udGFpbmluZyBhbiBldmVudCByZWNvcmQgd2l0aCBhIHRpbWVz dGFtcA0KPiA+ID4gICAgbGF0ZXIgdGhhbiAoMSkgdGhlICJzdG9wLXRpbWUiIG9yICgyKSB0aGUg c3Vic2NyaXB0aW9uJ3Mgc3RhcnQgdGltZS4NCj4gPiA+DQo+ID4gPiBuaXQoPyk6IHRoaXMgdGV4 dCBzZWVtcyB0byBpbXBseSB0aGF0IGEgbm90aWZpY2F0aW9uIG1lc3NhZ2Ugd2l0aCBhDQo+ID4g PiB0aW1lc3RhbXAgbGF0ZXIgdGhhbiB0aGUgInN0b3AtdGltZSIgbWlnaHQgYWN0dWFsbHkgYmUg c2VudCwgd2hpY2ggSUlVQyBpcw0KPiBub3QgdGhlIGNhc2UuDQo+ID4NCj4gPiBZb3UgYXJlIGNv cnJlY3QgdGhhdCBpdCBpcyBub3Qgc2VudC4gIEJ1dCB0aGUgZXZlbnQgcmVjb3JkIGRvZXMgZXhp c3Qgb24gdGhlDQo+IHN0cmVhbS4NCj4gPg0KPiA+IEkgdGhpbmsgaXQgb2J2aW91cywgYnV0IGlm IHlvdSB3YW50IEkgY291bGQgYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgdG8gdGhlIGVuZA0K PiBvZiB0aGUgc3Vic2VxdWVudCBwYXJhZ3JhcGguICAiSWYgYSBzdG9wLXRpbWUgaGFzIGJlZW4g ZXhjZWVkIGR1cmluZyByZXBsYXksIG5vDQo+IHN1YnNlcXVlbnQgZXZlbnQgcmVjb3JkcyBhcmUg c2VudCBmb2xsb3dpbmcgdGhlIHNlbmRpbmcgb2YgYSAicmVwbGF5LQ0KPiBjb21wbGV0ZWQiIG5v dGlmaWNhdGlvbi4iDQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYSBuZWVkIHRvIGFkZCB0 aGF0IHNlbnRlbmNlLCBidXQgdGhhbmtzIGZvciBvZmZlcmluZy4NCj4gDQo+ID4NCj4gPiA+IFNl Y3Rpb24gMi45DQo+ID4gPg0KPiA+ID4gbml0OiB0aGUgbmFtZSAic3VwcG9ydHMtdnJmIiBmb3Ig dGhlIGZlYXR1cmUgZG9lc24ndCByZWFsbHkgcGFyYWxsZWwNCj4gPiA+IHRoZSBvdGhlciBmZWF0 dXJlIG5hbWVzLCB0aGF0IGRvbid0IGluY2x1ZGUgYSB3b3JkIGxpa2UgInN1cHBvcnQiDQo+ID4g PiBhbmQgcmF0aGVyIGp1c3QgZGVzY3JpYmUgdGhlIGFjdHVhbCBmZWF0dXJlLg0KPiA+DQo+ID4g VGhpcyBpcyB0cnVlLiAgU2V2ZXJhbCB5ZWFycyBhZ28gd2hlbiBzb21lb25lIHByb3Bvc2VkIHRo aXMgbmFtZSwgdGhlcmUgd2FzDQo+IGEgcmVhc29uLiAgQnV0IEkgY2FuJ3QgcmVtZW1iZXIgd2hh dCBpdCBpcyByaWdodCBub3cuICBTbyBob3BlZnVsbHkgd2UgY2FuIGxlYXZlDQo+IGl0IHNvIGFz IG5vdCB0byBicmVhayBzb21lb25lJ3MgdGhpbmtpbmcuDQo+ID4NCj4gPiA+IFNlY3Rpb24gMy4x DQo+ID4gPg0KPiA+ID4gSXMgdGhlcmUgYW55IHJpc2sgb2YgY29sbGlzaW9uIGluIGV2ZW50IHN0 cmVhbSBuYW1lcyBmcm9tDQo+ID4gPiB2ZW5kb3Itc3BlY2lmaWMgc3RyZWFtcz8gIChXZSBkb24n dCBzZWVtIHRvIGNyZWF0ZSBhbiBJQU5BIHJlZ2lzdHJ5DQo+ID4gPiBmb3IgdGhlbSwgZm9yIGV4 YW1wbGUuKQ0KPiA+DQo+ID4gSW4gdGhlb3J5IHllcy4gIEJ1dCBpdCBoYXMgbm90IHByb3ZlbiB0 byBiZSBhbiBpc3N1ZSB3aXRoIFJGQy01Mjc3IHN0cmVhbXMsIHNvIGl0DQo+IGRvZXNuJ3Qgc2Vl bSB3b3J0aCBpdCB0byBkbyBzb21ldGhpbmcgbmV3IG5vdy4gICBTbyBpbiB0aGlzIGRvY3VtZW50 LCB3ZSBoYXZlDQo+IG9uZSBJRVRGIHN0cmVhbSAiTkVUQ09ORiIgZGVmaW5lZCBpbiBTZWN0aW9u IDIuMS4gIEhvcGVmdWxseSBpdCBpcyBlbm91Z2ggdG8NCj4gaGFyZC1jb2RlIHRoaXMuICAgV2Ug Y2FuIGFsd2F5cyByZXZpc2l0IGlmIElFVEYgZ3JvdXBzIHdhbnQgdG8gc3RhcnQgZGVmaW5pbmcN Cj4gc3RyZWFtcw0KPiA+DQo+ID4gPiBTZWN0aW9uIDQNCj4gPiA+DQo+ID4gPiAgICBpZGVudGl0 eSBzdWJzY3JpcHRpb24tc3VzcGVuZGVkLXJlYXNvbiB7DQo+ID4gPiAgICAgICBkZXNjcmlwdGlv bg0KPiA+ID4gICAgICAgICJQcm9ibGVtIGNvbmRpdGlvbiBjb21tdW5pY2F0ZWQgdG8gYSByZWNl aXZlciBhcyBwYXJ0IG9mIGENCj4gPiA+ICAgICAgICAnc3Vic2NyaXB0aW9uLXRlcm1pbmF0ZWQn IG5vdGlmaWNhdGlvbi4iOw0KPiA+ID4gICAgfQ0KPiA+ID4NCj4gPiA+ICAgIGlkZW50aXR5IHN1 YnNjcmlwdGlvbi10ZXJtaW5hdGVkLXJlYXNvbiB7DQo+ID4gPiAgICAgICBkZXNjcmlwdGlvbg0K PiA+ID4gICAgICAgICJQcm9ibGVtIGNvbmRpdGlvbiBjb21tdW5pY2F0ZWQgdG8gYSByZWNlaXZl ciBhcyBwYXJ0IG9mIGENCj4gPiA+ICAgICAgICAnc3Vic2NyaXB0aW9uLXRlcm1pbmF0ZWQnIG5v dGlmaWNhdGlvbi4iOw0KPiA+ID4gICAgfQ0KPiA+ID4NCj4gPiA+IEFyZSB0aGVzZSBkZXNjcmlw dGlvbnMgc3VwcG9zZWQgdG8gYmUgdGhlIHNhbWU/DQo+ID4NCj4gPiBHb29kIGNhdGNoLiAgIEZp eGVkIHRoZSAnc3Vic2NyaXB0aW9uLXN1c3BlbmRlZCcgZGVzY3JpcHRpb24uDQo+ID4NCj4gPiA+ ICAgIGlkZW50aXR5IGNvbmZpZ3VyYWJsZS1lbmNvZGluZyB7DQo+ID4gPiAgICAgIGRlc2NyaXB0 aW9uDQo+ID4gPiAgICAgICAgIklmIGEgdHJhbnNwb3J0IGlkZW50aXR5IGRlcml2ZXMgZnJvbSB0 aGlzIGlkZW50aXR5LCBpdCBtZWFucw0KPiA+ID4gICAgICAgICB0aGF0IGl0IHN1cHBvcnRzIGNv bmZpZ3VyYWJsZSBlbmNvZGluZ3MuICBBbiBleGFtcGxlIG9mIGENCj4gPiA+IFsuLi5dDQo+ID4g Pg0KPiA+ID4gSXMgaXQgaW50ZW5kZWQgdGhhdCBzdWNoIGZ1dHVyZSB0cmFuc3BvcnRzIChvciBm dXR1cmUgZW5jb2RpbmdzPykNCj4gPiA+IHdpbGwgZGVyaXZlIGZyb20gYm90aCB0aGlzIGFuZCB0 aGUgbm9ybWFsIGJhc2UgaWRlbnRpdHkgKGkuZS4sICJ0cmFuc3BvcnQiKT8NCj4gPiA+IEkgZ3Vl c3MgSSdtIGFza2luZyB3aHkgdGhpcyBpZGVudGl0eSBkb2VzIG5vdCBkZXJpdmUgZnJvbSB0aGUN Cj4gPiA+IGNvcnJlc3BvbmRpbmcgYmFzZSwgYnV0IHRoYXQncyBqdXN0IGEgc3R5bGUgcXVlc3Rp b24gYW5kIG5vdCByZWFsbHkNCj4gPiA+IGEgcHJvdG9jb2wgbWF0dGVyLCBtYWtpbmcgdGhpcyBx dWVzdGlvbiBhIHNpZGUgbm90ZS4NCj4gPg0KPiA+IFllcy4gIEZ1dHVyZSBpZGVudGl0aWVzIGNh biBkZXJpdmUgZnJvbSBjb25maWd1cmFibGUtZW5jb2RpbmcNCj4gPg0KPiA+ID4gICAgICBsZWFm IHdlaWdodGluZyB7DQo+ID4gPiAgICAgICAgaWYtZmVhdHVyZSAicW9zIjsNCj4gPiA+ICAgICAg ICB0eXBlIHVpbnQ4IHsNCj4gPiA+ICAgICAgICAgICByYW5nZSAiMCAuLiAyNTUiOw0KPiA+ID4g ICAgICAgIH0NCj4gPiA+ICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4gICAgICAgICAgIlJlbGF0 aXZlIHdlaWdodGluZyBmb3IgYSBzdWJzY3JpcHRpb24uIEFsbG93cyBhbiB1bmRlcmx5aW5nDQo+ ID4gPiAgICAgICAgICAgdHJhbnNwb3J0IGxheWVyIHBlcmZvcm0gaW5mb3JtZWQgbG9hZCBiYWxh bmNlIGFsbG9jYXRpb25zDQo+ID4gPiAgICAgICAgICAgYmV0d2VlbiB2YXJpb3VzIHN1YnNjcmlw dGlvbnMiOw0KPiA+ID4gICAgICAgIHJlZmVyZW5jZQ0KPiA+ID4gICAgICAgICAgIlJGQy03NTQw LCBzZWN0aW9uIDUuMy4yIjsNCj4gPiA+DQo+ID4gPiBEbyB3ZSB3YW50IHRvIGNoYXNlIHRoZSBy ZWZlcmVuY2UgZm9yIHJlYWRlcnMgYW5kIHNheSB0aGF0IGxhcmdlcg0KPiA+ID4gd2VpZ2h0cyBn ZXQgbW9yZSByZXNvdXJjZXM/DQo+ID4NCj4gPiBJIHB1dCBpbiAiTGFyZ2VyIHdlaWdodHMgZ2V0 IG1vcmUgcmVzb3VyY2VzLiIgYXMgc2VudGVuY2UgdHdvIG9mIHRoZQ0KPiBkZXNjcmlwdGlvbi4N Cj4gPg0KPiA+ID4gICAgICBsZWFmIGVuY29kaW5nIHsNCj4gPiA+ICAgICAgICB3aGVuICdub3Qo Li4vdHJhbnNwb3J0KSBvciBkZXJpdmVkLWZyb20oLi4vdHJhbnNwb3J0LA0KPiA+ID4gICAgICAg ICJzbjpjb25maWd1cmFibGUtZW5jb2RpbmciKSc7DQo+ID4gPiAgICAgICAgdHlwZSBlbmNvZGlu ZzsNCj4gPiA+ICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4gICAgICAgICAgIlRoZSB0eXBlIG9m IGVuY29kaW5nIGZvciBub3RpZmljYXRpb24gbWVzc2FnZXMuICAgRm9yIGENCj4gPiA+ICAgICAg ICAgIGR5bmFtaWMgc3Vic2NyaXB0aW9uLCBpZiBub3QgaW5jbHVkZWQgYXMgcGFydCBvZiBhbiBl c3RhYmxpc2gtDQo+ID4gPiAgICAgICAgICBzdWJzY3JpcHRpb24gUlBDLCB0aGUgZW5jb2Rpbmcg d2lsbCBiZSBwb3B1bGF0ZWQgd2l0aCB0aGUNCj4gPiA+ICAgICAgICAgIGVuY29kaW5nIHVzZWQg YnkgdGhhdCBSUEMuICBGb3IgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiwgaWYNCj4gPiA+ICAg ICAgICAgIG5vdCBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdGhlIGVuY29kaW5nIHdpdGggYmUgdGhl IGRlZmF1bHQNCj4gPiA+ICAgICAgICAgIGVuY29kaW5nIGZvciBhbiB1bmRlcmx5aW5nIHRyYW5z cG9ydC4iOw0KPiA+ID4NCj4gPiA+IFdoZXJlIGlzIHRoZSBkZWZhdWx0IGVuY29kaW5nIGZvciBh biB1bmRlcmx5aW5nIHRyYW5zcG9ydCBzcGVjaWZpZWQ/DQo+ID4gPiBTZWN0aW9uIDUuMyBkb2Vz IG5vdCBzZWVtIHRvIHNheSB0aGF0IGEgdHJhbnNwb3J0IHNwZWNpZmljYXRpb24gbXVzdA0KPiA+ ID4gcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uLCBub3IgZG9lcyBTZWN0aW9uIDEuMyAod2hpY2gg bWVudGlvbnMgdGhhdA0KPiA+ID4gdHJhbnNwb3J0IHNwZWNpZmljYXRpb25zIG11c3QgZGV0YWls IHRoZSBsaWZlY3ljbGUgb2YgZHluYW1pYw0KPiA+ID4gc3Vic2NyaXB0aW9ucyksIG5vciBkb2Vz IFNlY3Rpb24gMi41LjcgKHRoYXQgZGlzY3Vzc2VzIHRoZSBuZWVkIGZvcg0KPiA+ID4gYSBzZXBh cmF0ZSBtb2RlbCBhdWdtZW50aW5nDQo+ID4gPiAvc3Vic2NyaXB0aW9ucy9zdWJzY3JpcHRpb24v cmVjZWl2ZXJzL3JlY2VpdmVyDQo+ID4gPiB0byBwcm92aWRlIHRyYW5zcG9ydCBkZXRhaWxzKS4N Cj4gPg0KPiA+IEZvciBtYW55IHRyYW5zcG9ydHMsIHRoZSBlbmNvZGluZyBpcyByZWR1bmRhbnQg aW5mb3JtYXRpb24uICBUaGUNCj4gPiByZWFzb24gaXMgdGhhdCB0cmFuc3BvcnQgUkZDcyB0aGVt c2VsdmVzIGRlZmluZSBzdXBwb3J0ZWQgZW5jb2RpbmdzDQo+ID4gKGUuZy4sICJORVRDT05GICsg WE1MIiAsICJSRVNUQ09ORiArIEpTT04iKS4gIEFuZCBXRyBtZW1iZXJzIHdobyBidWlsdA0KPiA+ IHRob3NlIHRyYW5zcG9ydCBSRkNzIGRpZCBub3Qgd2FudCB0byBhbGxvdyBvcGVyYXRvcnMgdG8g bWlzY29uZmlndXJlDQo+ID4gYW55dGhpbmcgaGVyZS4gIChBcyBhbiBhc2lkZSwgdGhpcyBkZXNp cmUgdG8gc2lnbmlmaWNhbnRseSByZWR1Y2UgdGhlDQo+ID4gb3Bwb3J0dW5pdHkgZm9yIG1pc2Nv bmZpZ3VyYXRpb24gaXMgd2hhdCBkcm92ZSB0aGUgaW50ZXJlc3RpbmcgJ3doZW4nDQo+ID4gc3Rh dGVtZW50IGFib3ZlLikNCj4gPg0KPiA+IEJ1dCBlbmNvZGluZ3MgY2FuIHZhcnkuICBUaGlzIGlz IHRoZSBwdXJwb3NlIG9mIHRoZSBpZGVudGl0eSAiY29uZmlndXJhYmxlLQ0KPiBlbmNvZGluZyIg aW4gdGhlIFlBTkcgbW9kZWwuICAgQW5kIHRoaXMgaWRlbnRpdHkgZG9lcyBzYXkgdGhhdCAiRnVy dGhlciBkZXRhaWxzDQo+IGZvciBhbnkgc3BlY2lmaWMgY29uZmlndXJhYmxlIGVuY29kaW5nIHdv dWxkIGJlIGV4cGxvcmVkIGluIGEgdHJhbnNwb3J0DQo+IGRvY3VtZW50IGJhc2VkIG9uIHRoaXMg c3BlY2lmaWNhdGlvbi4iICBJIGd1ZXNzIHRoaXMgaW5mb3JtYXRpb24gY291bGQgYmUNCj4gcmVw ZWF0ZWQgaW4gU2VjdGlvbiA1LjMgaWYgbmVjZXNzYXJ5Lg0KPiANCj4gSSB0aGluayB0aGF0IGR1 cGxpY2F0aW9uIHdvdWxkIGJlIG15IHByZWZlcmVuY2UsIHRvIGdldCB0aGluZ3MgY29uc29saWRh dGVkIGluDQo+IG9uZSBwbGFjZS4NCg0KUGVyIGFib3ZlIGluIHRoZSBkaXNjdXNzLCB0ZXh0IGFk ZGVkIHRvIDUuMy4NCg0KPiA+ID4gICAgICAgIGNob2ljZSBub3RpZmljYXRpb24tbWVzc2FnZS1v cmlnaW4gew0KPiA+ID4gICAgICAgICAgaWYtZmVhdHVyZSAiY29uZmlndXJlZCI7DQo+ID4gPiAg ICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ID4gICAgICAgICAgICAiSWRlbnRpZmllcyB0aGUgZWdy ZXNzIGludGVyZmFjZSBvbiB0aGUgcHVibGlzaGVyIGZyb20gd2hpY2gNCj4gPiA+ICAgICAgICAg ICAgIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBhcmUgdG8gYmUgc2VudC4iOw0KPiA+ID4NCj4gPiA+ IG5pdDogZ2l2ZW4gdGhlIGFkZHJlc3Mtb3JpZ2luYXRlZCBjYXNlLCBwZXJoYXBzICJ0aGUgZWdy ZXNzIGludGVyZmFjZSINCj4gPiA+IGlzIG5vdCBxdWl0ZSBjb3JyZWN0IGFueW1vcmUuDQo+ID4N Cj4gPiBFdmVyeSBhbHRlcm5hdGl2ZSBJIGNvbWUgdXAgd2l0aCBzZWVtcyBtb3JlIHByb2JsZW1h dGljLiAgIEkgYmVsaWV2ZSByZWFkZXJzDQo+IHNob3VsZCBiZSBhYmxlIHRvIHVuZGVyc3RhbmQg YmFzZWQgb24gdGhlIGNhc2VzIGJlbG93Lg0KPiANCj4gKEkgZG9uJ3QgaGF2ZSBhbnkgYmV0dGVy IHN1Z2dlc3Rpb25zLCBlaXRoZXIuKQ0KPiANCj4gPiA+ICAgICAgICAgICAgICAgIGVudW0gY29u bmVjdGluZyB7DQo+ID4gPiAgICAgICAgICAgICAgICAgIHZhbHVlIDM7DQo+ID4gPiAgICAgICAg ICAgICAgICAgIGlmLWZlYXR1cmUgImNvbmZpZ3VyZWQiOw0KPiA+ID4gICAgICAgICAgICAgICAg ICBkZXNjcmlwdGlvbg0KPiA+ID4gICAgICAgICAgICAgICAgICAgICJBIHN1YnNjcmlwdGlvbiBo YXMgYmVlbiBjb25maWd1cmVkLCBidXQgYQ0KPiA+ID4gICAgICAgICAgICAgICAgICAgICdzdWJz Y3JpcHRpb24tc3RhcnRlZCcgc3Vic2NyaXB0aW9uIHN0YXRlIGNoYW5nZQ0KPiA+ID4gICAgICAg ICAgICAgICAgICAgIG5vdGlmaWNhdGlvbiBuZWVkcyB0byBiZSBzdWNjZXNzZnVsbHkgcmVjZWl2 ZWQgYmVmb3JlDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIG1lc3NhZ2Vz IGFyZSBzZW50Lg0KPiA+ID4NCj4gPiA+IG5pdDogc3VjY2Vzc2Z1bCByZWNlaXB0IGhhcHBlbnMg b24gdGhlIHJlY2VpdmVyIGJ1dCBzZW5kaW5nIGhhcHBlbnMNCj4gPiA+IG9uIHRoZSBwdWJsaXNo ZXIsIHNvIHRoZXJlJ3MgYSBiaXQgb2YgYSBtaXNtYXRjaCBpbiB0aGUgc2VudGVuY2UNCj4gPiA+ IHN1YmplY3QgaGVyZS4gIFBlcmhhcHMgd2UgY291bGQgdGFsayBhYm91dCAic3VjY2Vzc2Z1bGx5 IHNlbnQiIHN0YXRlLWNoYW5nZXMNCj4gdG8gcmVzb2x2ZSB0aGluZ3MuDQo+ID4NCj4gPiBUaGlz IHdvcmRpbmcgaXMgYXMgaW50ZW5kZWQuICBCYXNpY2FsbHkgaXQgaXMgaGlnaGx5IGRlc2lyYWJs ZSBmb3INCj4gPiBjb25maWd1cmVkIHJlY2VpdmVycyB3aWxsIG5lZWQgdG8gYWNrbm93bGVkZ2Vt ZW50IG9mIHN1Y2Nlc3NmdWwNCj4gPiByZWNlaXB0IG9mIGEgInN1YnNjcmlwdGlvbi1zdGFydGVk IiBiZWZvcmUgc2VuZGluZyBldmVudCByZWNvcmRzLg0KPiA+IFRoaXMgaGVscHMgcHJldmVudCBE RE9TIGF0dGFja3MuICBUaGUgbWVjaGFuaXNtIGZvciBnYWluaW5nIGFuDQo+ID4gYWNrbm93bGVk Z2VtZW50IHZhcmllcyBieSB0cmFuc3BvcnQuICBBcyBhbiBleGFtcGxlIG9mIHdoYXQgd2UgaGF2 ZQ0KPiA+IGJlZW4gdGhpbmtpbmcgYWJvdXQgaGVyZSwgc2VlDQo+ID4NCj4gPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYv MDQvDQo+IFNlY3Rpb24gMy4xLjINCj4gPiBIb3BlZnVsbHkgdGhpcyB0eXBlIG9mIG1lY2hhbmlz bSB3aWxsIGJlIHJldml2ZWQgaW4gZnV0dXJlIGRyYWZ0cy4NCj4gDQo+IEkgYWdyZWUgdGhhdCBn ZXR0aW5nIGV4cGxpY2l0IGFja25vd2xlZGdtZW50IG9mIGRlbGl2ZXJ5IGlzIGhpZ2hseSBkZXNp cmFibGU7IG15DQo+IHF1YWxtIGhlcmUgaXMgc29sZWx5IGFib3V0IHRoZSBncmFtbWFyIG9mIHRo ZSBzZW50ZW5jZS4NCj4gRG9lcyBpdCBwcmVzZXJ2ZSB0aGUgZGVzaXJlZCBtZWFuaW5nIHRvIHJl cGxhY2UgInN1Y2Nlc3NmdWxseSByZWNlaXZlZCINCj4gd2l0aCAic3VjY2Vzc2Z1bGx5IGFja25v d2xlZGdlZCIgKG9yICJzdWNjZXNzZnVsbHkgcmVjZWl2ZWQgYW5kDQo+IGFja25vd2xlZGdlZCIp Pw0KDQpJIHdvdWxkIGxvdmUgdG8gaGF2ZSBoYWQgYWNrbm93bGVkZ2VkLiAgSG93ZXZlciBJIGhh dmUgaGVhcmQgZnJvbSBpbXBsZW1lbnRlcnMgdGhhdCBORVRDT05GIGlzIG5vdCBhcyByb2J1c3Qg aW4gdGhpcyB3YXkgYXMgSFRUUC4gIEFuZCBhY2tub3dsZWRnZWQgbWlnaHQgaW1wbHkgdGhpbmdz IHRvIGRldmVsb3BlcnMgdGhleSBtaWdodCBub3QgYmUgYWJsZSB0byBkZWxpdmVyLg0KDQo+ID4g PiAgICAgICAgICAgICAgY29uZmlnIGZhbHNlOw0KPiA+ID4gICAgICAgICAgICAgIG1hbmRhdG9y eSB0cnVlOw0KPiA+ID4gICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gPiAgICAgICAgICAg ICAgICAiU3BlY2lmaWVzIHRoZSBzdGF0ZSBvZiBhIHN1YnNjcmlwdGlvbiBmcm9tIHRoZQ0KPiA+ ID4gICAgICAgICAgICAgICAgcGVyc3BlY3RpdmUgb2YgYSBwYXJ0aWN1bGFyIHJlY2VpdmVyLiAg V2l0aCB0aGlzIGluZm8gaXQNCj4gPiA+ICAgICAgICAgICAgICAgIGlzIHBvc3NpYmxlIHRvIGRl dGVybWluZSB3aGV0aGVyIGEgc3Vic2NyaWJlciBpcw0KPiA+ID4gICAgICAgICAgICAgICAgY3Vy cmVudGx5IGdlbmVyYXRpbmcgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGludGVuZGVkIGZvcg0KPiA+ ID4gICAgICAgICAgICAgICAgdGhhdCByZWNlaXZlci4iOw0KPiA+ID4NCj4gPiA+IG5pdDogaXMg aXQgdGhlIHN1YnNjcmliZXIgdGhhdCBpcyBnZW5lcmF0aW5nIG1lc3NhZ2VzIG9yIHRoZSBwdWJs aXNoZXI/DQo+ID4NCj4gPiBHb29kIGNhdGNoLiAgQ2hhbmdlZCB0byBwdWJsaXNoZXIuDQo+ID4N Cj4gPiA+IFNlY3Rpb24gNS4zDQo+ID4gPg0KPiA+ID4gICAgQSBzZWN1cmUgdHJhbnNwb3J0IGlz IGhpZ2hseSByZWNvbW1lbmRlZCBhbmQgdGhlIHB1Ymxpc2hlciBNVVNUDQo+ID4gPiAgICBlbnN1 cmUgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIHN1ZmZpY2llbnQgYXV0aG9yaXphdGlvbiB0byBwZXJm b3JtIHRoZQ0KPiA+ID4gICAgZnVuY3Rpb24gdGhleSBhcmUgcmVxdWVzdGluZyBhZ2FpbnN0IHRo ZSBzcGVjaWZpYyBzdWJzZXQgb2YgY29udGVudA0KPiA+ID4gICAgaW52b2x2ZWQuDQo+ID4gPg0K PiA+ID4gInNlY3VyZSB0cmFuc3BvcnQiIHVzdWFsbHkgbWVhbnMgdGhhdCBpdCBwcm92aWRlcyBt ZXNzYWdlDQo+ID4gPiBjb25maWRlbnRpYWxpdHksIGludGVncml0eSBwcm90ZWN0aW9uLCBhbmQg c291cmNlIGF1dGhlbnRpY2l0eSAoYWtpbiB0byB0aGUNCj4gbXV0dWFsIGF1dGhlbnRpY2F0aW9u KS4NCj4gPiA+IFRoaXMgaXMgcXVhbGl0YXRpdmVseSBkaWZmZXJlbnQgZnJvbSBpbXBsZW1lbnRp bmcgYXV0aG9yaXphdGlvbg0KPiA+ID4gY2hlY2tzLCBhbmQgaXQncyBzdXJwcmlzaW5nIHRvIHNl ZSB0aGVtIHNxdWFzaGVkIGludG8gdGhlIHNhbWUgc2VudGVuY2UuDQo+ID4NCj4gPiBUd2Vha2Vk IHRvICJBIHNlY3VyZSB0cmFuc3BvcnQgaXMgaGlnaGx5IHJlY29tbWVuZGVkLiAgQmV5b25kIHRo aXMsIHRoZQ0KPiBwdWJsaXNoZXIgTVVTVCIuDQo+ID4NCj4gPiA+IERvIHdlIHdhbnQgdG8gc2F5 IGFueXRoaW5nIGFib3V0IGRpc2NvdmVyeSBmb3Igc3VwcG9ydCBvZiBuZXcNCj4gPiA+IHRyYW5z cG9ydHMsIGFuZCB3aGF0IHdvcmtmbG93IHdvdWxkIGJlIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSB1 c2Ugb2YgYSBuZXcNCj4gdHJhbnNwb3J0Pw0KPiA+DQo+ID4gTm90IGF0IHRoaXMgcG9pbnQuDQo+ IA0KPiBPa2F5Lg0KPiANCj4gPiA+IFNlY3Rpb24gNS40DQo+ID4gPg0KPiA+ID4gSSBjYW4gdGhp bmsgb2YgYSBjb3VwbGUgb3RoZXIgY29uc2lkZXJhdGlvbnMgdG8gbWVudGlvbiBoZXJlOg0KPiA+ ID4NCj4gPiA+IC0gVXNpbmcgRE5TIG5hbWVzIGZvciByZWNlaXZlciAibmFtZSIgbG9va3VwIGNh biBjYXVzZSBzaXR1YXRpb25zIHdoZXJlDQo+ID4gPiAgIHRoZSBuYW1lIHJlc29sdmVzIGRpZmZl cmVudGx5IG9uIHRoZSBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXIsIHNvIHRoZQ0KPiA+ID4gICBy ZWNpcGllbnQgd291bGQgYmUgZGlmZmVyZW50IHRoYW4gZXhwZWN0ZWQuDQo+ID4gPg0KPiA+ID4g LSBVc2luZyB0aGUgcHVibGlzaGVyJ3MgYm9vdCB0aW1lIGZvciBkZWR1cGxpY2F0aW9uIHByb3Rl Y3Rpb24gb24NCj4gPiA+ICAgcmVwbGF5ZWQgbWVzc2FnZXMgaW50cm9kdWNlcyBhIGRlcGVuZGVu Y3kgb24gYWNjdXJhdGUgdGltZS4gIFdlIGRvbid0DQo+ID4gPiAgIGhhdmUgYSBncmVhdCBzZWN1 cmUgdGltZSBzdG9yeSBhdCBwcmVzZW50LCBzbyB0aGlzIGlzIG1vcmUgb2YgYQ0KPiA+ID4gICAi YmV3YXJlIG9mIHJpc2siIHNpdHVhdGlvbiB0aGFuIHNvbWV0aGluZyB3ZSBjYW4gbWl0aWdhdGUs IGJ1dCBpdCBkb2VzDQo+ID4gPiAgIHNlZW0gdGhhdCBhbiBhdHRhY2tlciB0aGF0IGNvdWxkIChl LmcuKSBzcG9vZiB0aGUgTlRQIHRyYWZmaWMgdG8gdGhlDQo+ID4gPiAgIHB1Ymxpc2hlciBvbiBi b290IGNvdWxkIGNhdXNlIGl0IHRvIHNlbmQgZHVwbGljYXRlIG5vdGlmaWNhdGlvbnMgdG8NCj4g PiA+ICAgcmVjaXBpZW50cyB0aGF0IHJlcXVlc3RlZCBoaXN0b3JpY2FsIGRhdGEuDQo+ID4NCj4g PiBJIHR3ZWFrZWQgYW5kIGluc2VydGVkIHRoZSB0d28gcGFyYWdyYXBocyBmcm9tIHlvdS4uLg0K PiA+DQo+ID4gIlVzaW5nIEROUyBuYW1lcyBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gcmVj ZWl2ZXIgIm5hbWUiIGxvb2t1cCBjYW4NCj4gY2F1c2Ugc2l0dWF0aW9ucyB3aGVyZSB0aGUgbmFt ZSByZXNvbHZlcyB1bmV4cGVjdGVkbHkgZGlmZmVyZW50bHkgb24gdGhlDQo+IHB1Ymxpc2hlciwg c28gdGhlIHJlY2lwaWVudCB3b3VsZCBiZSBkaWZmZXJlbnQgdGhhbiBleHBlY3RlZC4iDQo+ID4N Cj4gPiAiVXNpbmcgdGhlIHB1Ymxpc2hlcidzIGJvb3QgdGltZSBmb3IgZGVkdXBsaWNhdGlvbiBw cm90ZWN0aW9uIG9uIHJlcGxheWVkDQo+IG1lc3NhZ2VzIGludHJvZHVjZXMgYSBkZXBlbmRlbmN5 IG9uIGFjY3VyYXRlIHRpbWUuIg0KPiANCj4gQ2FuIHdlIGFsc28gc2F5IHNvbWV0aGluZyBsaWtl ICJBbiBhdHRhY2tlciB0aGF0IGNhbiBjYXVzZSB0aGUgcHVibGlzaGVyIHRvIHVzZQ0KPiBhbiBp bmNvcnJlY3QgdGltZSBjYW4gaW5kdWNlIG1lc3NhZ2UgcmVwbGF5IGJ5IHNldHRpbmcgdGhlIHRp bWUgaW4gdGhlIHBhc3QsIGFuZA0KPiBpbnRyb2R1Y2UgYSByaXNrIG9mIG1lc3NhZ2UgbG9zcyBi eSBzZXR0aW5nIHRoZSB0aW1lIGluIHRoZSBmdXR1cmUiPw0KDQpUZXh0IHlvdSBzdWdnZXN0IGFi b3ZlIGhhcyBiZWVuIGluc2VydGVkIGluc3RlYWQgb2YgIiBVc2luZyB0aGUgcHVibGlzaGVyJ3Mg Ym9vdCB0aW1lIGZvciBkZWR1cGxpY2F0aW9uIHByb3RlY3Rpb24uLi4iLg0KDQo+ID4NCj4gPiA+ IFNvbWUgb3RoZXIgY29tbWVudHMgb24gd2hhdCdzIGFscmVhZHkgdGhlcmUgKHdoaWNoIGlzIHBy ZXR0eSBnb29kOw0KPiA+ID4gdGhhbmtzIGZvcg0KPiA+ID4gaXQhKSBmb2xsb3cuDQo+ID4gPg0K PiA+ID4gICAgQ29udGFpbmVyOiAiL2ZpbHRlcnMiDQo+ID4gPg0KPiA+ID4gICAgbyAgInN0cmVh bS1zdWJ0cmVlLWZpbHRlciI6IHVwZGF0aW5nIGEgZmlsdGVyIGNvdWxkIGluY3JlYXNlIHRoZQ0K PiA+ID4gICAgICAgY29tcHV0YXRpb25hbCBjb21wbGV4aXR5IG9mIGFsbCByZWZlcmVuY2luZyBz dWJzY3JpcHRpb25zLg0KPiA+ID4NCj4gPiA+ICAgIG8gICJzdHJlYW0teHBhdGgtZmlsdGVyIjog dXBkYXRpbmcgYSBmaWx0ZXIgY291bGQgaW5jcmVhc2UgdGhlDQo+ID4gPiAgICAgICBjb21wdXRh dGlvbmFsIGNvbXBsZXhpdHkgb2YgYWxsIHJlZmVyZW5jaW5nIHN1YnNjcmlwdGlvbnMuDQo+ID4g Pg0KPiA+ID4gRG8gd2Ugd2FudCB0byBzYXkgYW55dGhpbmcgYWJvdXQgbW9kaWZ5aW5nIGVpdGhl ciBvZiB0aGVzZSBjYXVzaW5nDQo+ID4gPiB0aGUgc2V0IG9mIG5vdGlmaWNhdGlvbnMgZGVsaXZl cmVkIHRvIHJlY2lwaWVudHMgdG8gc2hyaW5rIChvciBiZWNvbWUNCj4gdW5tYW5hZ2VhYmx5IGxh cmdlKT8NCj4gPiA+IEkgZ3Vlc3MgaXQgbWF5IG5vdCBiZSBuZWNlc3NhcnksIHNpbmNlIHRoZSBy ZWNpcGllbnQgZ2V0cyBhDQo+ID4gPiBub3RpZmljYXRpb24gYWJvdXQgdGhlIG1vZGlmaWNhdGlv biB0aGF0IGluY2x1ZGVzIHRoZSBkZXRhaWxzIG9mIHRoZSBmaWx0ZXIuDQo+ID4NCj4gPiBZZXMs IHRoYXQgd2FzIHRoZSB0aGlua2luZy4NCj4gPg0KPiA+ID4gICAgQ29udGFpbmVyOiAiL3N1YnNj cmlwdGlvbnMiDQo+ID4gPg0KPiA+ID4gICAgbyAgImV4Y2x1ZGVkLWV2ZW50LXJlY29yZHMiOiBs ZWFmIGNhbiBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0DQo+ID4gPiAgICAgICBmaWx0ZXJlZCBl dmVudCByZWNvcmRzLiAgQSBuZXR3b3JrIG9wZXJhdG9yIHNob3VsZCBoYXZlDQo+ID4gPiAgICAg ICBwZXJtaXNzaW9ucyB0byBrbm93IGFib3V0IHN1Y2ggZmlsdGVyaW5nLg0KPiA+ID4NCj4gPiA+ IFRvIGJlIGNsZWFyLCB0aGlzIGlzIGV2ZW50IHJlY29yZHMgZmlsdGVyZWQgZWl0aGVyIHZpYSBl eHBsaWNpdA0KPiA+ID4gZmlsdGVyIG9yIHZpYSBhY2Nlc3MgY29udHJvbCByZXN0cmljdGlvbnMu DQo+ID4NCj4gPiBZZXMuDQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhlIHNlbWFudGljIGRpZmZlcmVu Y2UgaXMgd29ydGggbm90aW5nLg0KPiANCj4gPiA+IFNwZWNpZmljYWxseSwgaXQgY2FuIGFsbG93 IGEgcmVjZWl2ZXIgdG8gbGVhcm4gdGhhdCB0aGVyZSBleGlzdHMNCj4gPiA+IGFjY2VzcyBjb250 cm9scyB0aGF0IGRlbnkgaXQgYWNjZXNzIHRvIHNvbWUgZGF0YSwgaW4gdGhlIGNhc2Ugd2hlbg0K PiA+ID4gdGhleSBkaWQgbm90IGFwcGx5IGFueSBmaWx0ZXJpbmcgcnVsZXMgZXhwbGljaXRseS4N Cj4gPg0KPiA+IFllcy4NCj4gPg0KPiA+ID5UaGlzIHBvdGVudGlhbCBmb3IgaW5mb3JtYXRpb24g bGVha2FnZSAob2YgdGhlICBleGlzdGVuY2Ugb2YNCj4gPiA+IEFDTHMpIHNob3VsZCBiZSBtZW50 aW9uZWQgZXhwbGljaXRseS4NCj4gPg0KPiA+IEFkZGVkIHRoZSBzZW50ZW5jZTogIkltcHJvcGVy IGNvbmZpZ3VyYXRpb24gY291bGQgcHJvdmlkZSBhIHJlY2VpdmVyIHdpdGgNCj4gaW5mb3JtYXRp b24gbGVha2FnZSBjb25zaXN0aW5nIG9mIHRoZSBkcm9wcGluZyBvZiBldmVudCByZWNvcmRzLiIN Cj4gDQo+IENhbiBJIGNvdW50ZXItcHJvcG9zZTogIkltcHJvcGVyIGNvbmZpZ3VyYXRpb24gY291 bGQgYWxsb3cgYSByZWNlaXZlciB0byBsZWFybg0KPiB0aGF0IGV2ZW50IHJlY29yZHMgd2VyZSBk cm9wcGVkIGR1ZSB0byBhbiBBQ0wgd2hlbiB0aGUgZXhpc3RlbmNlIG9mIHRoYXQgQUNMDQo+IHdv dWxkIG90aGVyd2lzZSBiZSB0cmFuc3BhcmVudC4iDQo+IA0KPiA+DQo+ID4gPiBBcHBlbmRpeCBB DQo+ID4gPg0KPiA+ID4gVGhpcyBleGFtcGxlIHRyYW5zcG9ydCBtb2R1bGUgZG9lcyBub3Qgc3Bl Y2lmeSB0aGUgbGlmZSBjeWNsZSBvZg0KPiA+ID4gZHluYW1pYyBzdWJzY3JpcHRpb25zIHBlciBT ZWN0aW9uIDEuMywgYW5kIGEgY291cGxlIG90aGVyIHRoaW5ncw0KPiA+ID4gcmVxdWlyZWQgZnJv bSBhIHRyYW5zcG9ydCBtb2R1bGUgc3BlY2lmaWNhdGlvbi4gIFBlcmhhcHMgd2UgYXJlIG9rYXkN Cj4gPiA+IGNsYWltaW5nIHRoYXQgc2luY2UgdGhpcyBpcyBqdXN0IGFuIGV4YW1wbGUgWUFORyBt b2RlbCBhbmQgbm90IGENCj4gPiA+IGZ1bGwgdHJhbnNwb3J0IGV4YW1wbGUsIHRoZSBvbWlzc2lv biBpcyBva2F5LCBidXQgaXQgbWF5IGJlIHdvcnRoIG1lbnRpb25pbmcNCj4gdGhlIG9taXNzaW9u IGZvciBjbGFyaXR5Lg0KPiA+DQo+ID4gSSBhZGRlZCBhcyB0aGUgc2Vjb25kIHNlbnRlbmNlDQo+ ID4gIiBUaGlzIGV4YW1wbGUgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgY29tcGxldGUgdHJhbnNw b3J0IG1vZGVsLiINCj4gPg0KPiA+IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldywgaXQgd2Fz IGV4Y2VsbGVudGx5IGRvbmUuDQo+IA0KPiBBbmQgdGhhbmtzIGZvciB0aGUgY2xlYXIgZXhwbGFu YXRpb25zIG9mIHRoZSBwYXJ0cyB0aGF0IEkgZGlkbid0IHVuZGVyc3RhbmQsIGl0IHdhcw0KPiB2 ZXJ5IGhlbHBmdWwgdG8gbWUuDQoNCk5vIHByb2JsZW0uICBUaGlzIHRocmVhZCBoYXMgYmVlbiBn b29kIGZvciBtZSB0b28uICBJIHdpbGwgcG9zdCB2MjUgYXMgc29vbiBhcyB5b3UgZ2l2ZSB0aGUg b2suDQoNCkVyaWMNCg0KPiAtQmVuDQo= From nobody Wed May 1 10:12:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D813D1200A2; Wed, 1 May 2019 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7tHqtpf45E7; Wed, 1 May 2019 10:12:45 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A1B5C12008F; Wed, 1 May 2019 10:12:44 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x41HCcOt025983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 May 2019 13:12:40 -0400 Date: Wed, 1 May 2019 12:12:38 -0500 From: Benjamin Kaduk To: "Eric Voit (evoit)" Cc: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Message-ID: <20190501171238.GK59871@kduck.mit.edu> References: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> <20190501153725.GG59871@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:12:49 -0000 On Wed, May 01, 2019 at 05:09:11PM +0000, Eric Voit (evoit) wrote: > > From: Benjamin Kaduk, May 1, 2019 11:37 AM > > > > On Wed, May 01, 2019 at 05:48:45AM +0000, Eric Voit (evoit) wrote: > > > Hi Benjamin, > > > > > > > From: Benjamin Kaduk, April 30, 2019 5:11 PM > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-netconf-subscribed-notifications-24: Discuss > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > DISCUSS: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Thanks for this document; I just have a few minor "housekeeping" > > > > points that should get resolved before publication. (Please also > > > > note the substantive comments in the COMMENT section as well, > > > > particularly those relating to the transport requirements and > > > > security considerations.) > > > > > > > > I'm not sure that we state clearly enough what is required to have a > > > > specification for a transport for notifications. Specifically (see > > > > COMMENT), in the module we seem to say that the specification must > > > > indicate what the default encoding is to be used if not otherwise > > > > specified, but that's not enumerated as a requirement on such a specification > > anywhere I see. > > > > > > I provide more info in-line below with your comment. But here is a summary... > > > > > > For dynamic subscriptions, the default encoding is normally specified by > > whatever is used within the establish-subscription RPC. So there is not a need > > for a default here as the subscriber has already encoded in the RPC what it > > wants. > > > > > > For configured subscriptions, the default (and only) encoding is often driven by > > the transport selection. And this is defined by existing transport RFCs which > > themselves define supported encodings (e.g., "NETCONF + XML" , "RESTCONF + > > JSON"). > > > > > > But encodings can vary (e.g., the use of CBOR within draft-birkholz-yang-push- > > coap-problemstatement). Supporting this need is the purpose of the identity > > "configurable-encoding" in the YANG model. And this identity does say that > > "Further details for any specific configurable encoding would be explored in a > > transport document based on this specification." I guess this information could > > be repeated as a separate requirement in Section 5.3 if you feel this is > > insufficiently defined. > > > > I'm mostly concerned about the case of configured subscriptions and future > > extensibility. If someone wants to make a new "QUIC + CBOR" transport, do we > > have a clear list of what details that specification needs to provide? > > (From my reading of this document, there should be an explicit "this is the > > default encoding" statement, even if there is only one encoding specified in the > > transport specification.) > > I have added the following statement to Section 5.3... > "A specific transport specification MUST identity any encoding supported. Where a configured subscription's transport allows different encodings, the specification MUST identify the default encoding." > > > > > > I also think that we could > > > > probably require (as opposed to "highly recommend" in the current > > > > security > > > > considerations) that the transport provide message confidentiality > > > > and integrity protection. > > > > > > I for sure like the idea of encryption. And I absolutely like the idea of > > signatures too. However several years ago on based on work with MSDC / cloud > > providers desiring telemetry, there were requests for deployments where the > > volume of telemetry generated could overwhelm the CPU of the host router. > > And as the telemetry was being delivered within a fully protected MSDC > > domain/environment, these MSDC providers said they wanted *all* the router > > data more than they needed message confidentiality and integrity protection. > > I.e., the wanted to have more data rather than being constrained the host CPU > > doing functions which reduced the volume of data being delivered. > > > > > > So personally, I want low volume telemetry with full security protections > > applied. But by leaving it at "highly recommend" we don't unintentionally inhibit > > applicability to MSDC implementations in a protected domain. They explicitly > > said they didn't want it. > > > > We do sometimes have cases where we leave an opening for people to assert > > that the physical security of their network provides "equivalent protection" to > > cryptographic confidentiality/integrity protection, if we want to try to > > wordsmith something. But, given the above, I won't push very hard on this > > front. > > Ok, will leave as is. > > > > > I'm also unsure that I properly understand the use of the "reset" > > > > RPC -- if it has no effect when transit connectivity already exists, > > > > then what entity is going to call "reset" in the case of publisher timeout when > > trying to reach a receiver? > > > > Surely not the publisher itself, since that would just be > > > > publisher-internal functionality with no need for an external-facing RPC. > > > > > > The reset RPC of section 2.5.5 is YANG model exposed operational knob based > > on the YANG 1.1 language construct "action": > > > https://tools.ietf.org/html/rfc7950#section-7.15 > > > > > > An operational interface can call this action. I.e., an entity with the proper > > administrative privileges can access "reset". This means a REST interface could > > be exposed upon a controller for that publisher. And when somebody find that > > the subscription isn't responsive (for a variety of reasons) that REST interface > > can be called, and the publisher can start trying to make connections (such as > > RFC 8071 call home connections) to a receiver. > > > > Okay, thanks for helping me out here; consider this one resolved. > > > > > > > > > I'm also a little unclear on the mechanics of the list of > > > > subscriptions described in Section 3.3. Does it provide a way for a > > > > low-privilege client (that can only access one or a handful of the > > > > subscriptions) to enumerate all subscriptions that exist, including > > > > subscriptions used by high-privilege clients? If so, we may want to > > > > think about some security considerations text to that effect; if > > > > not, we may want to say that the access-control will limit which leafs are > > visible to some clients. > > > > > > Your functional requirements completely valid. I believe they are covered by a > > set of other YANG RFC which dictate who/what can access various elements of > > YANG data. Good example documents to look at here are ones like: > > > > > > RFC-8341 - Network Configuration Access Control Model > > > > > > An understanding of these documents are assumed, and listed in places like the > > security considerations in Section 5.4. > > > > I admit to having not fully absorbed the NACM, and given the number of > > documents I have left to ballot on this week, I'll take your word that it's covered > > well enough there. > > > > > > Finally, we have a few instances of "leaf filter-failure-hint" > > > > that's of type "string", providing > > > > "Information describing where and/or why a provided filter > > > > was unsupportable for a subscription."; I don't > > > > understand why it's a string as opposed to some form of > > > > machine-readable data. Is it supposed to be human-readable? Does that > > bring in any internationalization considerations? > > > > > > There are many reasons why a filter might fail. The authors didn't believe that > > there was enough operational experience to sufficiently document the universe > > of failure types across the set of interested parties. As a result, the option > > seemed to be to provide no guidance on the failure reason, or to let the vendors > > provide some guidance (albeit just a 'string'). So at this point with the > > specification, it would be up to the vendor to determine whether it is human > > readable, or whether internationalization considerations should be covered. > > Hopefully with enough deployments this might be revisited at a future date. > > > > We should probably think about saying something about how its syntax and > > semantics are implementation-specific, then -- there doesn't seem to be real > > guidance for how to use it, at present. > > Added text in leaf to clarify this approach... > > leaf filter-failure-hint { > type string; > description > "Information describing where and/or why a provided filter > was unsupportable for a subscription. The syntax and > semantics of this hint are implementation-specific."; > } > > > > > -------------------------------------------------------------------- > > > > -- > > > > COMMENT: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Section 1.3 > > > > > > > > Also note that transport specific transport drafts based on this > > > > specification MUST detail the life cycle of dynamic subscriptions, as > > > > well as the lifecycle of configured subscriptions (if supported). > > > > > > > > I'm not sure I understand what additional specification is needed > > > > for the lifecycle of configured subscriptions -- doesn't the > > > > previous text tightly tie their lifecycle to the presence of configuration in the > > configuration datastore? > > > > > > For the most part it does. However there is a relationship for exactly when to > > establish transport connectivity based on the state of each receiver of a > > configured subscription. > > > > > > As an example of what should be specified, see Section 5.2 of > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-noti > > > fications/10/ Here you can see how NETCONF call home is invoked at the > > > proper points in the configured subscription state machine. > > > > Ah, thanks for the pointer. > > > > > > nit: please be consistent about "life cycle" vs. "lifecycle" throughout. > > > > > > Fixed nit to "lifecycle". > > > > > > > Section 2.1 > > > > > > > > An event stream is a named entity on a publisher which exposes a > > > > continuously updating set of YANG encoded event records. [...] > > > > > > > > nit: I don't think "YANG encoded" is well-defined (here and below), > > > > in that YANG structures generate data models but can be encoded into > > > > various formats (like XML and JSON). > > > > > > This is true. I made the two occurrences of "YANG encoded" into "YANG > > defined". > > > > > > > Section 2.3 > > > > > > > > If the publisher supports the "dscp" feature, then a subscription > > > > with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP > > > > marking being placed within the IP header of any resulting > > > > notification messages and subscription state change notifications. > > > > Where TCP is used, a publisher which supports the "dscp" feature > > > > SHOULD ensure that a subscription's notification messages are > > > > returned within a single TCP transport session where all traffic > > > > shares the subscription's "dscp" leaf value. Where this cannot be > > > > guaranteed, any "establish subscription" RPC request SHOULD be > > > > rejected with a "dscp-unavailable" error > > > > > > > > I can't decide whether we need to be more explicit in the second > > > > and/or third sentences that this remains contingent on the > > > > subscription in question having a "dscp" leaf. > > > > > > The sentences were already long, it feels to me like it would be more > > confusing to put in more words here. > > > > > > > nit: end sentence with a full stop > > > > > > Period added. > > > > > > > I share the TSV-ART reviewer's confusion about how the weighting (as > > > > well as > > > > DSCP) functionality is intended to work. > > > > > > Short answer: Earlier versions of this draft made explicit parallels of the > > weighting method to HTTP2 RFC-7450 section 5.3.2. The operation of weighting > > is exactly the same HTTP2 dependency weighting. There is additional definition > > of how this is supposed to work in Section 4 of draft-ietf-netconf-restconf-notif > > (which is also currently up for review). > > > > > > Long answer: TSV-ART is absolutely correct that a publisher might generate a > > lot of traffic. In many ways, high traffic volumes would be a successful outcome > > for this work. As a result, mitigating different dimensions of this volume risk has > > been a design goal since this effort’s inception. And this is the reason robust > > QoS mechanisms were included. This includes both DSCP and weighting. > > > > > > Here is a quick summary of some QoS mechanisms available in this draft... > > > > > > 1. The publisher is allowed to decline a dynamic subscription. One of these > > reasons is that the incremental traffic generated by a particular incremental > > subscription will be too high. There are errors back to the subscriber indicating > > this condition exist. > > > 2. A publisher can suspend any subscription for capacity reasons, and a > > receiver must be able to gracefully accept this suspension. > > > 3. Much like with HTTP2 streams, higher priority subscriptions intended for a > > particular receiver can be dequeued first from a publisher. > > > 4. Much like with HTTP2 streams, proportional subscription dequeuing > > intended for a particular receiver can be performed a publisher. > > > 5. DSCP markings can be placed on subscribed data. > > > 6. Mechanisms for detecting and reacting to different types of subscribed data > > loss have been embedded. > > > 7. Methods have been included to ensure a configured receiver “ok’s” > > > information push before subscribed data is sent. (This should reduce one DDoS > > vector.) 8. Keep alive mechanisms are established for different transport types, > > so that subscribed data isn’t being sent when the is no receiver listening. > > > > > > Mechanism (4) is in question here. As defined by draft-ietf-netconf-restconf- > > notif, this is supposed to work identically to HTTP2 RFC-7450 section 5.3.2. > > However there were WG members who did not want to include a functional > > requirement normative reference to that HTTP2 transport in this document > > however. Therefore the reference to HTP2 was removed. > > > > > > In the end, I don't think we can afford to get rid of support for (4) from the > > specification. This weighting capability is quite powerful, and can easily be > > added to GRPC based subscription alternatives. > > > > I don't think I was trying to suggest removing the mechanism entirely. > > What you've written here includes a mental model of having local queues of > > messages that get dequeued according to a specific algorithm, and the weights > > influencing the rate of dequeuing across queues; that mental model (combined > > with the knowledge that larger weight values get more traffic > > faster) gives me the picture I wanted for "how it's supposed to work". > > Maybe we could distill that down a bit and put it in the draft, as the current text > > had some level of "magic occurs here", to me. > > I am hoping to leave things as they are for now. Basically the magic that occurs can be gleaned from Section 4 of draft-ietf-netconf-restconf-notif. And nobody in the NETCONF world is likely to implement this type of Dequeuing, so they shouldn't have the extra text in the base specification trip them up.. > > > > > Section 2.4.2.1 > > > > > > > > Replay provides the ability to establish a subscription which is also > > > > capable of passing recently generated event records. In other > > > > words, > > > > > > > > nit/editorial: this language could probably be more clear about > > > > "recently generated" meaning "in the past", that is, records for > > > > events that have already happened when the subscription is established. > > > > > > Tweaked to "event records generated in the recent past" > > > > > > > Section 2.4.3 > > > > > > > > any number of times. Dynamic subscriptions can only be modified via > > > > this RPC using a transport session connecting to the subscriber. > > > > If > > > > > > > > nit(?): is this more readable as "connecting to" or "connecting from" > > > > the subscriber? (The same wording shows up throughout the document, > > > > but I'll try to just comment once.) > > > > > > I expect that it should be clear enough either way. I believe leaving the current > > text should not impact implementations. > > > > > > > Section 2.4.5 > > > > > > > > Is there any distinction between "killing a subscription" and > > > > "administratively deleting a subscription"? It's unclear to me that > > > > we need the extra connotations of the word "kill", here. > > > > > > We chose to use a different RPC name so that administrative access control > > permissions differences between the kill-subscription and delete-subscription > > would be explicit and obvious. And once we had a new RPC name, it seemed > > easier for the reader to continue using the "kill" word for that RPC. > > > > In vacuum, "admin-delete-subscription" seems like a fine name, to me. But this > > is a non-blocking comment so I'll stop pushing now. > > > > > > Section 2.4.6 > > > > > > > > As a result of this mixture, how subscription errors are encoded > > > > > > > > nit: "mixture" doesn't seem like the right word to me; "variety" or > > > > "varied population" are the first alternatives that come to mind, > > > > though they are not perfect either. > > > > > > Changed to 'variety'. > > > > > > > Is there some sort of "access denied" error that could result from > > > > kill- subscription RPCs? (The table/artwork only lists > > > > "no-such-subscription".) > > > > > > Access denied when an RPC fails access control is part of the base transport > > error types for the RPC. I.e., transports like NETCONF and RESTCONF already > > have non-subscription-specific errors like this one already covered. > > > > Ah, of course, and we require processing of transport-level errors before these > > ones, so it all works out fine. > > > > > > Section 2.5 > > > > > > > > It's interesting to see a slight dichotomy between dynamic and > > > > configured subscriptions, in that (IIUC) for dynamic subscriptions, > > > > a modification event un- suspends a subscription immediately, but > > > > for configured subscriptions the publisher seems to have some > > > > latitude to retain the subscription in the suspended state for some > > > > time before un-suspending it and sending the "subscription-modified" state > > change message. > > > > > > > > In this case, a separate dynamic subscription can be > > > > established to retransmit the missing event records. > > > > > > > > Do you want to put in a pointer to replay-start-time here? > > > > > > I thought getting to that level of detail in the intro was confusing for this intro > > section. > > > > Okay. (Maybe a parenthetical "replay" as a search term would help without > > being confusing, but entirely your call.) > > I will leave as-is. > > > > > Section 2.5.1 > > > > > > > > Event records are only sent to active receivers. Receivers of > > > > a configured subscription remain active if both transport > > > > connectivity can be verified to the receiver, and event records are > > > > not being dropped due to a publisher buffer overflow. [...] > > > > > > > > nit: "buffer overflow" is a technical term in security circles > > > > indicating a potentially exploitable security flaw; would "publisher > > > > buffer capacity being reached" be an acceptable substitute (here and > > below)? > > > > > > Change made > > > > > > > Section 2.7.7 > > > > > > > > This notification indicates that all of the event records prior to > > > > the current time have been passed to a receiver. It is sent before > > > > any notification message containing an event record with a timestamp > > > > later than (1) the "stop-time" or (2) the subscription's start time. > > > > > > > > nit(?): this text seems to imply that a notification message with a > > > > timestamp later than the "stop-time" might actually be sent, which IIUC is > > not the case. > > > > > > You are correct that it is not sent. But the event record does exist on the > > stream. > > > > > > I think it obvious, but if you want I could add the following sentence to the end > > of the subsequent paragraph. "If a stop-time has been exceed during replay, no > > subsequent event records are sent following the sending of a "replay- > > completed" notification." > > > > I don't think there's a need to add that sentence, but thanks for offering. > > > > > > > > > Section 2.9 > > > > > > > > nit: the name "supports-vrf" for the feature doesn't really parallel > > > > the other feature names, that don't include a word like "support" > > > > and rather just describe the actual feature. > > > > > > This is true. Several years ago when someone proposed this name, there was > > a reason. But I can't remember what it is right now. So hopefully we can leave > > it so as not to break someone's thinking. > > > > > > > Section 3.1 > > > > > > > > Is there any risk of collision in event stream names from > > > > vendor-specific streams? (We don't seem to create an IANA registry > > > > for them, for example.) > > > > > > In theory yes. But it has not proven to be an issue with RFC-5277 streams, so it > > doesn't seem worth it to do something new now. So in this document, we have > > one IETF stream "NETCONF" defined in Section 2.1. Hopefully it is enough to > > hard-code this. We can always revisit if IETF groups want to start defining > > streams > > > > > > > Section 4 > > > > > > > > identity subscription-suspended-reason { > > > > description > > > > "Problem condition communicated to a receiver as part of a > > > > 'subscription-terminated' notification."; > > > > } > > > > > > > > identity subscription-terminated-reason { > > > > description > > > > "Problem condition communicated to a receiver as part of a > > > > 'subscription-terminated' notification."; > > > > } > > > > > > > > Are these descriptions supposed to be the same? > > > > > > Good catch. Fixed the 'subscription-suspended' description. > > > > > > > identity configurable-encoding { > > > > description > > > > "If a transport identity derives from this identity, it means > > > > that it supports configurable encodings. An example of a > > > > [...] > > > > > > > > Is it intended that such future transports (or future encodings?) > > > > will derive from both this and the normal base identity (i.e., "transport")? > > > > I guess I'm asking why this identity does not derive from the > > > > corresponding base, but that's just a style question and not really > > > > a protocol matter, making this question a side note. > > > > > > Yes. Future identities can derive from configurable-encoding > > > > > > > leaf weighting { > > > > if-feature "qos"; > > > > type uint8 { > > > > range "0 .. 255"; > > > > } > > > > description > > > > "Relative weighting for a subscription. Allows an underlying > > > > transport layer perform informed load balance allocations > > > > between various subscriptions"; > > > > reference > > > > "RFC-7540, section 5.3.2"; > > > > > > > > Do we want to chase the reference for readers and say that larger > > > > weights get more resources? > > > > > > I put in "Larger weights get more resources." as sentence two of the > > description. > > > > > > > leaf encoding { > > > > when 'not(../transport) or derived-from(../transport, > > > > "sn:configurable-encoding")'; > > > > type encoding; > > > > description > > > > "The type of encoding for notification messages. For a > > > > dynamic subscription, if not included as part of an establish- > > > > subscription RPC, the encoding will be populated with the > > > > encoding used by that RPC. For a configured subscription, if > > > > not explicitly configured the encoding with be the default > > > > encoding for an underlying transport."; > > > > > > > > Where is the default encoding for an underlying transport specified? > > > > Section 5.3 does not seem to say that a transport specification must > > > > provide this information, nor does Section 1.3 (which mentions that > > > > transport specifications must detail the lifecycle of dynamic > > > > subscriptions), nor does Section 2.5.7 (that discusses the need for > > > > a separate model augmenting > > > > /subscriptions/subscription/receivers/receiver > > > > to provide transport details). > > > > > > For many transports, the encoding is redundant information. The > > > reason is that transport RFCs themselves define supported encodings > > > (e.g., "NETCONF + XML" , "RESTCONF + JSON"). And WG members who built > > > those transport RFCs did not want to allow operators to misconfigure > > > anything here. (As an aside, this desire to significantly reduce the > > > opportunity for misconfiguration is what drove the interesting 'when' > > > statement above.) > > > > > > But encodings can vary. This is the purpose of the identity "configurable- > > encoding" in the YANG model. And this identity does say that "Further details > > for any specific configurable encoding would be explored in a transport > > document based on this specification." I guess this information could be > > repeated in Section 5.3 if necessary. > > > > I think that duplication would be my preference, to get things consolidated in > > one place. > > Per above in the discuss, text added to 5.3. > > > > > choice notification-message-origin { > > > > if-feature "configured"; > > > > description > > > > "Identifies the egress interface on the publisher from which > > > > notification messages are to be sent."; > > > > > > > > nit: given the address-originated case, perhaps "the egress interface" > > > > is not quite correct anymore. > > > > > > Every alternative I come up with seems more problematic. I believe readers > > should be able to understand based on the cases below. > > > > (I don't have any better suggestions, either.) > > > > > > enum connecting { > > > > value 3; > > > > if-feature "configured"; > > > > description > > > > "A subscription has been configured, but a > > > > 'subscription-started' subscription state change > > > > notification needs to be successfully received before > > > > notification messages are sent. > > > > > > > > nit: successful receipt happens on the receiver but sending happens > > > > on the publisher, so there's a bit of a mismatch in the sentence > > > > subject here. Perhaps we could talk about "successfully sent" state-changes > > to resolve things. > > > > > > This wording is as intended. Basically it is highly desirable for > > > configured receivers will need to acknowledgement of successful > > > receipt of a "subscription-started" before sending event records. > > > This helps prevent DDOS attacks. The mechanism for gaining an > > > acknowledgement varies by transport. As an example of what we have > > > been thinking about here, see > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/04/ > > Section 3.1.2 > > > Hopefully this type of mechanism will be revived in future drafts. > > > > I agree that getting explicit acknowledgment of delivery is highly desirable; my > > qualm here is solely about the grammar of the sentence. > > Does it preserve the desired meaning to replace "successfully received" > > with "successfully acknowledged" (or "successfully received and > > acknowledged")? > > I would love to have had acknowledged. However I have heard from implementers that NETCONF is not as robust in this way as HTTP. And acknowledged might imply things to developers they might not be able to deliver. > > > > > config false; > > > > mandatory true; > > > > description > > > > "Specifies the state of a subscription from the > > > > perspective of a particular receiver. With this info it > > > > is possible to determine whether a subscriber is > > > > currently generating notification messages intended for > > > > that receiver."; > > > > > > > > nit: is it the subscriber that is generating messages or the publisher? > > > > > > Good catch. Changed to publisher. > > > > > > > Section 5.3 > > > > > > > > A secure transport is highly recommended and the publisher MUST > > > > ensure that the receiver has sufficient authorization to perform the > > > > function they are requesting against the specific subset of content > > > > involved. > > > > > > > > "secure transport" usually means that it provides message > > > > confidentiality, integrity protection, and source authenticity (akin to the > > mutual authentication). > > > > This is qualitatively different from implementing authorization > > > > checks, and it's surprising to see them squashed into the same sentence. > > > > > > Tweaked to "A secure transport is highly recommended. Beyond this, the > > publisher MUST". > > > > > > > Do we want to say anything about discovery for support of new > > > > transports, and what workflow would be used to negotiate the use of a new > > transport? > > > > > > Not at this point. > > > > Okay. > > > > > > Section 5.4 > > > > > > > > I can think of a couple other considerations to mention here: > > > > > > > > - Using DNS names for receiver "name" lookup can cause situations where > > > > the name resolves differently on the publisher and subscriber, so the > > > > recipient would be different than expected. > > > > > > > > - Using the publisher's boot time for deduplication protection on > > > > replayed messages introduces a dependency on accurate time. We don't > > > > have a great secure time story at present, so this is more of a > > > > "beware of risk" situation than something we can mitigate, but it does > > > > seem that an attacker that could (e.g.) spoof the NTP traffic to the > > > > publisher on boot could cause it to send duplicate notifications to > > > > recipients that requested historical data. > > > > > > I tweaked and inserted the two paragraphs from you... > > > > > > "Using DNS names for configured subscription receiver "name" lookup can > > cause situations where the name resolves unexpectedly differently on the > > publisher, so the recipient would be different than expected." > > > > > > "Using the publisher's boot time for deduplication protection on replayed > > messages introduces a dependency on accurate time." > > > > Can we also say something like "An attacker that can cause the publisher to use > > an incorrect time can induce message replay by setting the time in the past, and > > introduce a risk of message loss by setting the time in the future"? > > Text you suggest above has been inserted instead of " Using the publisher's boot time for deduplication protection...". > > > > > > > > Some other comments on what's already there (which is pretty good; > > > > thanks for > > > > it!) follow. > > > > > > > > Container: "/filters" > > > > > > > > o "stream-subtree-filter": updating a filter could increase the > > > > computational complexity of all referencing subscriptions. > > > > > > > > o "stream-xpath-filter": updating a filter could increase the > > > > computational complexity of all referencing subscriptions. > > > > > > > > Do we want to say anything about modifying either of these causing > > > > the set of notifications delivered to recipients to shrink (or become > > unmanageably large)? > > > > I guess it may not be necessary, since the recipient gets a > > > > notification about the modification that includes the details of the filter. > > > > > > Yes, that was the thinking. > > > > > > > Container: "/subscriptions" > > > > > > > > o "excluded-event-records": leaf can provide information about > > > > filtered event records. A network operator should have > > > > permissions to know about such filtering. > > > > > > > > To be clear, this is event records filtered either via explicit > > > > filter or via access control restrictions. > > > > > > Yes. > > > > I think that the semantic difference is worth noting. > > > > > > Specifically, it can allow a receiver to learn that there exists > > > > access controls that deny it access to some data, in the case when > > > > they did not apply any filtering rules explicitly. > > > > > > Yes. > > > > > > >This potential for information leakage (of the existence of > > > > ACLs) should be mentioned explicitly. > > > > > > Added the sentence: "Improper configuration could provide a receiver with > > information leakage consisting of the dropping of event records." > > > > Can I counter-propose: "Improper configuration could allow a receiver to learn > > that event records were dropped due to an ACL when the existence of that ACL > > would otherwise be transparent." > > > > > > > > > Appendix A > > > > > > > > This example transport module does not specify the life cycle of > > > > dynamic subscriptions per Section 1.3, and a couple other things > > > > required from a transport module specification. Perhaps we are okay > > > > claiming that since this is just an example YANG model and not a > > > > full transport example, the omission is okay, but it may be worth mentioning > > the omission for clarity. > > > > > > I added as the second sentence > > > " This example is not intended to be a complete transport model." > > > > > > Thanks again for the review, it was excellently done. > > > > And thanks for the clear explanations of the parts that I didn't understand, it was > > very helpful to me. > > No problem. This thread has been good for me too. I will post v25 as soon as you give the ok. Please go ahead and post v25. Thanks, Ben From nobody Wed May 1 10:28:58 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2EA1200A4; Wed, 1 May 2019 10:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <155673172911.801.16813704633938557802@ietfa.amsl.com> Date: Wed, 01 May 2019 10:28:49 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-25.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:28:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Subscription to YANG Event Notifications Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-subscribed-notifications-25.txt Pages : 80 Date : 2019-05-01 Abstract: This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request for and receive a continuous, custom feed of publisher generated information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-25 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 1 10:32:59 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DA81200A2; Wed, 1 May 2019 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr82agvlWqcQ; Wed, 1 May 2019 10:32:46 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F591200B6; Wed, 1 May 2019 10:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51320; q=dns/txt; s=iport; t=1556731966; x=1557941566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hZqcPiBjcSN7eDfKaNWkYrtwDPJwro8ETnwwbL2cmbM=; b=Yay5QWLQZXErtmFvTXWqiAFcWkZfS/AGKgtq5K0Wj2iVRYHeeCRSafEY 9hue18wXc0N6yUOC7SmyEFNz0v+L0ogwyAMZJMUUH4S+Yj+ruE31JeAFd /Rd9L2LYxyaF2P6UvTbB5IfQVCAhDEI0PjOWIMlTpb8lWEw1DtaVhNSmW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAABC18lc/49dJa1cAQIHDgsBAQE?= =?us-ascii?q?BAQEBAQEBAQEHAQEBAQEBgWWBZyppgQQoCoNGQJUvfpdmgWcOAQEjhEoCF4Y?= =?us-ascii?q?bIzgTAQMBAQQBAQIBAm0cDIVKAQEBAQIBDAIMAQgRMQcGBQIFCwIBBgIVAwI?= =?us-ascii?q?CCRYHAgICMBUQAgQODRGCPkyBew8PkiCbZYEvhEZBhSkGgQsniiGBKxeBQD+?= =?us-ascii?q?BEYIUSTU+gmEBAQIBAYEyAQQOAQSDHYJYBIp2AxImC4IIhGqBbpISZQkCggm?= =?us-ascii?q?CU4NEjCAjgg2GN4xxkleOFgIRFYEwNiGBVnAVO4JtghoXFG0BCIdWhQQ7QTE?= =?us-ascii?q?BkSEBJQOBCIEhAQE?= X-IronPort-AV: E=Sophos;i="5.60,418,1549929600"; d="scan'208";a="269976317" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 17:32:44 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x41HWi0T006673 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 17:32:44 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 13:32:43 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 1 May 2019 13:32:43 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) Thread-Index: AQHU/5lDbPOEHPnGa0+OxIdeqCy7a6ZVXYMAgAFN5gD//8vZMIAATsAA///BjlA= Date: Wed, 1 May 2019 17:32:43 +0000 Message-ID: References: <155665867115.7536.12392383474714269681.idtracker@ietfa.amsl.com> <20190501153725.GG59871@kduck.mit.edu> <20190501171238.GK59871@kduck.mit.edu> In-Reply-To: <20190501171238.GK59871@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 17:32:52 -0000 PiBGcm9tOiBCZW5qYW1pbiBLYWR1aywgTWF5IDEsIDIwMTkgMToxMyBQTQ0KPiANCj4gT24gV2Vk LCBNYXkgMDEsIDIwMTkgYXQgMDU6MDk6MTFQTSArMDAwMCwgRXJpYyBWb2l0IChldm9pdCkgd3Jv dGU6DQo+ID4gPiBGcm9tOiBCZW5qYW1pbiBLYWR1aywgIE1heSAxLCAyMDE5IDExOjM3IEFNDQo+ ID4gPg0KPiA+ID4gT24gV2VkLCBNYXkgMDEsIDIwMTkgYXQgMDU6NDg6NDVBTSArMDAwMCwgRXJp YyBWb2l0IChldm9pdCkgd3JvdGU6DQo+ID4gPiA+IEhpIEJlbmphbWluLA0KPiA+ID4gPg0KPiA+ ID4gPiA+IEZyb206IEJlbmphbWluIEthZHVrLCBBcHJpbCAzMCwgMjAxOSA1OjExIFBNDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2Ny aWJlZC1ub3RpZmljYXRpb25zLTI0OiBEaXNjdXNzDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gPiA+ID4gLS0tLQ0KPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4gRElTQ1VTUzoNCj4g PiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gLS0tLQ0KPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBUaGFua3MgZm9yIHRoaXMgZG9jdW1lbnQ7IEkganVzdCBoYXZlIGEgZmV3IG1p bm9yICJob3VzZWtlZXBpbmciDQo+ID4gPiA+ID4gcG9pbnRzIHRoYXQgc2hvdWxkIGdldCByZXNv bHZlZCBiZWZvcmUgcHVibGljYXRpb24uICAoUGxlYXNlDQo+ID4gPiA+ID4gYWxzbyBub3RlIHRo ZSBzdWJzdGFudGl2ZSBjb21tZW50cyBpbiB0aGUgQ09NTUVOVCBzZWN0aW9uIGFzDQo+ID4gPiA+ ID4gd2VsbCwgcGFydGljdWxhcmx5IHRob3NlIHJlbGF0aW5nIHRvIHRoZSB0cmFuc3BvcnQgcmVx dWlyZW1lbnRzDQo+ID4gPiA+ID4gYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLikNCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IEknbSBub3Qgc3VyZSB0aGF0IHdlIHN0YXRlIGNsZWFybHkgZW5vdWdo IHdoYXQgaXMgcmVxdWlyZWQgdG8NCj4gPiA+ID4gPiBoYXZlIGEgc3BlY2lmaWNhdGlvbiBmb3Ig YSB0cmFuc3BvcnQgZm9yIG5vdGlmaWNhdGlvbnMuDQo+ID4gPiA+ID4gU3BlY2lmaWNhbGx5IChz ZWUgQ09NTUVOVCksIGluIHRoZSBtb2R1bGUgd2Ugc2VlbSB0byBzYXkgdGhhdA0KPiA+ID4gPiA+ IHRoZSBzcGVjaWZpY2F0aW9uIG11c3QgaW5kaWNhdGUgd2hhdCB0aGUgZGVmYXVsdCBlbmNvZGlu ZyBpcyB0bw0KPiA+ID4gPiA+IGJlIHVzZWQgaWYgbm90IG90aGVyd2lzZSBzcGVjaWZpZWQsIGJ1 dCB0aGF0J3Mgbm90IGVudW1lcmF0ZWQgYXMNCj4gPiA+ID4gPiBhIHJlcXVpcmVtZW50IG9uIHN1 Y2ggYSBzcGVjaWZpY2F0aW9uDQo+ID4gPiBhbnl3aGVyZSBJIHNlZS4NCj4gPiA+ID4NCj4gPiA+ ID4gSSBwcm92aWRlIG1vcmUgaW5mbyBpbi1saW5lIGJlbG93IHdpdGggeW91ciBjb21tZW50LiAg QnV0IGhlcmUgaXMgYQ0KPiBzdW1tYXJ5Li4uDQo+ID4gPiA+DQo+ID4gPiA+IEZvciBkeW5hbWlj IHN1YnNjcmlwdGlvbnMsIHRoZSBkZWZhdWx0IGVuY29kaW5nIGlzIG5vcm1hbGx5DQo+ID4gPiA+ IHNwZWNpZmllZCBieQ0KPiA+ID4gd2hhdGV2ZXIgaXMgdXNlZCB3aXRoaW4gdGhlIGVzdGFibGlz aC1zdWJzY3JpcHRpb24gUlBDLiAgU28gdGhlcmUgaXMNCj4gPiA+IG5vdCBhIG5lZWQgZm9yIGEg ZGVmYXVsdCBoZXJlIGFzIHRoZSBzdWJzY3JpYmVyIGhhcyBhbHJlYWR5IGVuY29kZWQNCj4gPiA+ IGluIHRoZSBSUEMgd2hhdCBpdCB3YW50cy4NCj4gPiA+ID4NCj4gPiA+ID4gRm9yIGNvbmZpZ3Vy ZWQgc3Vic2NyaXB0aW9ucywgdGhlIGRlZmF1bHQgKGFuZCBvbmx5KSBlbmNvZGluZyBpcw0KPiA+ ID4gPiBvZnRlbiBkcml2ZW4gYnkNCj4gPiA+IHRoZSB0cmFuc3BvcnQgc2VsZWN0aW9uLiAgQW5k IHRoaXMgaXMgZGVmaW5lZCBieSBleGlzdGluZyB0cmFuc3BvcnQNCj4gPiA+IFJGQ3Mgd2hpY2gg dGhlbXNlbHZlcyBkZWZpbmUgc3VwcG9ydGVkIGVuY29kaW5ncyAoZS5nLiwgIk5FVENPTkYgKw0K PiA+ID4gWE1MIiAsICJSRVNUQ09ORiArIEpTT04iKS4NCj4gPiA+ID4NCj4gPiA+ID4gQnV0IGVu Y29kaW5ncyBjYW4gdmFyeSAoZS5nLiwgdGhlIHVzZSBvZiBDQk9SIHdpdGhpbg0KPiA+ID4gPiBk cmFmdC1iaXJraG9sei15YW5nLXB1c2gtDQo+ID4gPiBjb2FwLXByb2JsZW1zdGF0ZW1lbnQpLiAg U3VwcG9ydGluZyB0aGlzIG5lZWQgaXMgdGhlIHB1cnBvc2Ugb2YgdGhlIGlkZW50aXR5DQo+ID4g PiAiY29uZmlndXJhYmxlLWVuY29kaW5nIiBpbiB0aGUgWUFORyBtb2RlbC4gICBBbmQgdGhpcyBp ZGVudGl0eSBkb2VzIHNheSB0aGF0DQo+ID4gPiAiRnVydGhlciBkZXRhaWxzIGZvciBhbnkgc3Bl Y2lmaWMgY29uZmlndXJhYmxlIGVuY29kaW5nIHdvdWxkIGJlDQo+ID4gPiBleHBsb3JlZCBpbiBh IHRyYW5zcG9ydCBkb2N1bWVudCBiYXNlZCBvbiB0aGlzIHNwZWNpZmljYXRpb24uIiAgSQ0KPiA+ ID4gZ3Vlc3MgdGhpcyBpbmZvcm1hdGlvbiBjb3VsZCBiZSByZXBlYXRlZCBhcyBhIHNlcGFyYXRl IHJlcXVpcmVtZW50DQo+ID4gPiBpbiBTZWN0aW9uIDUuMyBpZiB5b3UgZmVlbCB0aGlzIGlzIGlu c3VmZmljaWVudGx5IGRlZmluZWQuDQo+ID4gPg0KPiA+ID4gSSdtIG1vc3RseSBjb25jZXJuZWQg YWJvdXQgdGhlIGNhc2Ugb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFuZA0KPiA+ID4gZnV0 dXJlIGV4dGVuc2liaWxpdHkuICBJZiBzb21lb25lIHdhbnRzIHRvIG1ha2UgYSBuZXcgIlFVSUMg KyBDQk9SIg0KPiA+ID4gdHJhbnNwb3J0LCBkbyB3ZSBoYXZlIGEgY2xlYXIgbGlzdCBvZiB3aGF0 IGRldGFpbHMgdGhhdCBzcGVjaWZpY2F0aW9uIG5lZWRzIHRvDQo+IHByb3ZpZGU/DQo+ID4gPiAo RnJvbSBteSByZWFkaW5nIG9mIHRoaXMgZG9jdW1lbnQsIHRoZXJlIHNob3VsZCBiZSBhbiBleHBs aWNpdCAidGhpcw0KPiA+ID4gaXMgdGhlIGRlZmF1bHQgZW5jb2RpbmciIHN0YXRlbWVudCwgZXZl biBpZiB0aGVyZSBpcyBvbmx5IG9uZQ0KPiA+ID4gZW5jb2Rpbmcgc3BlY2lmaWVkIGluIHRoZSB0 cmFuc3BvcnQgc3BlY2lmaWNhdGlvbi4pDQo+ID4NCj4gPiBJIGhhdmUgYWRkZWQgdGhlIGZvbGxv d2luZyBzdGF0ZW1lbnQgdG8gU2VjdGlvbiA1LjMuLi4NCj4gPiAiQSBzcGVjaWZpYyB0cmFuc3Bv cnQgc3BlY2lmaWNhdGlvbiBNVVNUIGlkZW50aXR5IGFueSBlbmNvZGluZyBzdXBwb3J0ZWQuDQo+ IFdoZXJlIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24ncyB0cmFuc3BvcnQgYWxsb3dzIGRpZmZl cmVudCBlbmNvZGluZ3MsIHRoZQ0KPiBzcGVjaWZpY2F0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGRl ZmF1bHQgICAgICAgZW5jb2RpbmcuIg0KPiA+DQo+ID4NCj4gPiA+ID4gPiBJIGFsc28gdGhpbmsg dGhhdCB3ZSBjb3VsZA0KPiA+ID4gPiA+IHByb2JhYmx5IHJlcXVpcmUgKGFzIG9wcG9zZWQgdG8g ImhpZ2hseSByZWNvbW1lbmQiIGluIHRoZQ0KPiA+ID4gPiA+IGN1cnJlbnQgc2VjdXJpdHkNCj4g PiA+ID4gPiBjb25zaWRlcmF0aW9ucykgdGhhdCB0aGUgdHJhbnNwb3J0IHByb3ZpZGUgbWVzc2Fn ZQ0KPiA+ID4gPiA+IGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24uDQo+ ID4gPiA+DQo+ID4gPiA+IEkgZm9yIHN1cmUgbGlrZSB0aGUgaWRlYSBvZiBlbmNyeXB0aW9uLiBB bmQgSSBhYnNvbHV0ZWx5IGxpa2UgdGhlDQo+ID4gPiA+IGlkZWEgb2YNCj4gPiA+IHNpZ25hdHVy ZXMgdG9vLiAgSG93ZXZlciBzZXZlcmFsIHllYXJzIGFnbyBvbiBiYXNlZCBvbiB3b3JrIHdpdGgN Cj4gPiA+IE1TREMgLyBjbG91ZCBwcm92aWRlcnMgZGVzaXJpbmcgdGVsZW1ldHJ5LCB0aGVyZSB3 ZXJlIHJlcXVlc3RzIGZvcg0KPiA+ID4gZGVwbG95bWVudHMgd2hlcmUgdGhlIHZvbHVtZSBvZiB0 ZWxlbWV0cnkgZ2VuZXJhdGVkIGNvdWxkIG92ZXJ3aGVsbSB0aGUNCj4gQ1BVIG9mIHRoZSBob3N0 IHJvdXRlci4NCj4gPiA+IEFuZCBhcyB0aGUgdGVsZW1ldHJ5IHdhcyBiZWluZyBkZWxpdmVyZWQg d2l0aGluIGEgZnVsbHkgcHJvdGVjdGVkDQo+ID4gPiBNU0RDIGRvbWFpbi9lbnZpcm9ubWVudCwg dGhlc2UgTVNEQyBwcm92aWRlcnMgc2FpZCB0aGV5IHdhbnRlZCAqYWxsKg0KPiA+ID4gdGhlIHJv dXRlciBkYXRhIG1vcmUgdGhhbiB0aGV5IG5lZWRlZCBtZXNzYWdlIGNvbmZpZGVudGlhbGl0eSBh bmQgaW50ZWdyaXR5DQo+IHByb3RlY3Rpb24uDQo+ID4gPiBJLmUuLCB0aGUgd2FudGVkIHRvIGhh dmUgbW9yZSBkYXRhIHJhdGhlciB0aGFuIGJlaW5nIGNvbnN0cmFpbmVkIHRoZQ0KPiA+ID4gaG9z dCBDUFUgZG9pbmcgZnVuY3Rpb25zIHdoaWNoIHJlZHVjZWQgdGhlIHZvbHVtZSBvZiBkYXRhIGJl aW5nIGRlbGl2ZXJlZC4NCj4gPiA+ID4NCj4gPiA+ID4gU28gcGVyc29uYWxseSwgSSB3YW50IGxv dyB2b2x1bWUgdGVsZW1ldHJ5IHdpdGggZnVsbCBzZWN1cml0eQ0KPiA+ID4gPiBwcm90ZWN0aW9u cw0KPiA+ID4gYXBwbGllZC4gIEJ1dCBieSBsZWF2aW5nIGl0IGF0ICJoaWdobHkgcmVjb21tZW5k IiB3ZSBkb24ndA0KPiA+ID4gdW5pbnRlbnRpb25hbGx5IGluaGliaXQgYXBwbGljYWJpbGl0eSB0 byBNU0RDIGltcGxlbWVudGF0aW9ucyBpbiBhDQo+ID4gPiBwcm90ZWN0ZWQgZG9tYWluLiAgVGhl eSBleHBsaWNpdGx5IHNhaWQgdGhleSBkaWRuJ3Qgd2FudCBpdC4NCj4gPiA+DQo+ID4gPiBXZSBk byBzb21ldGltZXMgaGF2ZSBjYXNlcyB3aGVyZSB3ZSBsZWF2ZSBhbiBvcGVuaW5nIGZvciBwZW9w bGUgdG8NCj4gPiA+IGFzc2VydCB0aGF0IHRoZSBwaHlzaWNhbCBzZWN1cml0eSBvZiB0aGVpciBu ZXR3b3JrIHByb3ZpZGVzDQo+ID4gPiAiZXF1aXZhbGVudCBwcm90ZWN0aW9uIiB0byBjcnlwdG9n cmFwaGljIGNvbmZpZGVudGlhbGl0eS9pbnRlZ3JpdHkNCj4gPiA+IHByb3RlY3Rpb24sIGlmIHdl IHdhbnQgdG8gdHJ5IHRvIHdvcmRzbWl0aCBzb21ldGhpbmcuICBCdXQsIGdpdmVuDQo+ID4gPiB0 aGUgYWJvdmUsIEkgd29uJ3QgcHVzaCB2ZXJ5IGhhcmQgb24gdGhpcyBmcm9udC4NCj4gPg0KPiA+ IE9rLCB3aWxsIGxlYXZlIGFzIGlzLg0KPiA+DQo+ID4gPiA+ID4gSSdtIGFsc28gdW5zdXJlIHRo YXQgSSBwcm9wZXJseSB1bmRlcnN0YW5kIHRoZSB1c2Ugb2YgdGhlICJyZXNldCINCj4gPiA+ID4g PiBSUEMgLS0gaWYgaXQgaGFzIG5vIGVmZmVjdCB3aGVuIHRyYW5zaXQgY29ubmVjdGl2aXR5IGFs cmVhZHkNCj4gPiA+ID4gPiBleGlzdHMsIHRoZW4gd2hhdCBlbnRpdHkgaXMgZ29pbmcgdG8gY2Fs bCAicmVzZXQiIGluIHRoZSBjYXNlIG9mDQo+ID4gPiA+ID4gcHVibGlzaGVyIHRpbWVvdXQgd2hl bg0KPiA+ID4gdHJ5aW5nIHRvIHJlYWNoIGEgcmVjZWl2ZXI/DQo+ID4gPiA+ID4gU3VyZWx5IG5v dCB0aGUgcHVibGlzaGVyIGl0c2VsZiwgc2luY2UgdGhhdCB3b3VsZCBqdXN0IGJlDQo+ID4gPiA+ ID4gcHVibGlzaGVyLWludGVybmFsIGZ1bmN0aW9uYWxpdHkgd2l0aCBubyBuZWVkIGZvciBhbiBl eHRlcm5hbC1mYWNpbmcgUlBDLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgcmVzZXQgUlBDIG9mIHNl Y3Rpb24gMi41LjUgaXMgWUFORyBtb2RlbCBleHBvc2VkIG9wZXJhdGlvbmFsDQo+ID4gPiA+IGtu b2IgYmFzZWQNCj4gPiA+IG9uIHRoZSBZQU5HIDEuMSBsYW5ndWFnZSBjb25zdHJ1Y3QgImFjdGlv biI6DQo+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24t Ny4xNQ0KPiA+ID4gPg0KPiA+ID4gPiBBbiBvcGVyYXRpb25hbCBpbnRlcmZhY2UgY2FuIGNhbGwg dGhpcyBhY3Rpb24uICBJLmUuLCBhbiBlbnRpdHkNCj4gPiA+ID4gd2l0aCB0aGUgcHJvcGVyDQo+ ID4gPiBhZG1pbmlzdHJhdGl2ZSBwcml2aWxlZ2VzIGNhbiBhY2Nlc3MgInJlc2V0Ii4gICAgVGhp cyBtZWFucyBhIFJFU1QgaW50ZXJmYWNlDQo+IGNvdWxkDQo+ID4gPiBiZSBleHBvc2VkIHVwb24g YSBjb250cm9sbGVyIGZvciB0aGF0IHB1Ymxpc2hlci4gIEFuZCB3aGVuIHNvbWVib2R5DQo+ID4g PiBmaW5kIHRoYXQgdGhlIHN1YnNjcmlwdGlvbiBpc24ndCByZXNwb25zaXZlIChmb3IgYSB2YXJp ZXR5IG9mDQo+ID4gPiByZWFzb25zKSB0aGF0IFJFU1QgaW50ZXJmYWNlIGNhbiBiZSBjYWxsZWQs IGFuZCB0aGUgcHVibGlzaGVyIGNhbg0KPiA+ID4gc3RhcnQgdHJ5aW5nIHRvIG1ha2UgY29ubmVj dGlvbnMgKHN1Y2ggYXMgUkZDIDgwNzEgY2FsbCBob21lIGNvbm5lY3Rpb25zKQ0KPiB0byBhIHJl Y2VpdmVyLg0KPiA+ID4NCj4gPiA+IE9rYXksIHRoYW5rcyBmb3IgaGVscGluZyBtZSBvdXQgaGVy ZTsgY29uc2lkZXIgdGhpcyBvbmUgcmVzb2x2ZWQuDQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+ IEknbSBhbHNvIGEgbGl0dGxlIHVuY2xlYXIgb24gdGhlIG1lY2hhbmljcyBvZiB0aGUgbGlzdCBv Zg0KPiA+ID4gPiA+IHN1YnNjcmlwdGlvbnMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4zLiAgRG9l cyBpdCBwcm92aWRlIGEgd2F5DQo+ID4gPiA+ID4gZm9yIGEgbG93LXByaXZpbGVnZSBjbGllbnQg KHRoYXQgY2FuIG9ubHkgYWNjZXNzIG9uZSBvciBhDQo+ID4gPiA+ID4gaGFuZGZ1bCBvZiB0aGUN Cj4gPiA+ID4gPiBzdWJzY3JpcHRpb25zKSB0byBlbnVtZXJhdGUgYWxsIHN1YnNjcmlwdGlvbnMg dGhhdCBleGlzdCwNCj4gPiA+ID4gPiBpbmNsdWRpbmcgc3Vic2NyaXB0aW9ucyB1c2VkIGJ5IGhp Z2gtcHJpdmlsZWdlIGNsaWVudHM/ICBJZiBzbywNCj4gPiA+ID4gPiB3ZSBtYXkgd2FudCB0byB0 aGluayBhYm91dCBzb21lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgdG8NCj4gPiA+ID4g PiB0aGF0IGVmZmVjdDsgaWYgbm90LCB3ZSBtYXkgd2FudCB0byBzYXkgdGhhdCB0aGUgYWNjZXNz LWNvbnRyb2wNCj4gPiA+ID4gPiB3aWxsIGxpbWl0IHdoaWNoIGxlYWZzIGFyZQ0KPiA+ID4gdmlz aWJsZSB0byBzb21lIGNsaWVudHMuDQo+ID4gPiA+DQo+ID4gPiA+IFlvdXIgZnVuY3Rpb25hbCBy ZXF1aXJlbWVudHMgY29tcGxldGVseSB2YWxpZC4gIEkgYmVsaWV2ZSB0aGV5IGFyZQ0KPiA+ID4g PiBjb3ZlcmVkIGJ5IGENCj4gPiA+IHNldCBvZiBvdGhlciBZQU5HIFJGQyB3aGljaCBkaWN0YXRl IHdoby93aGF0IGNhbiBhY2Nlc3MgdmFyaW91cw0KPiA+ID4gZWxlbWVudHMgb2YgWUFORyBkYXRh LiAgR29vZCBleGFtcGxlIGRvY3VtZW50cyB0byBsb29rIGF0IGhlcmUgYXJlIG9uZXMNCj4gbGlr ZToNCj4gPiA+ID4NCj4gPiA+ID4gUkZDLTgzNDEgLSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gQWNj ZXNzIENvbnRyb2wgTW9kZWwNCj4gPiA+ID4NCj4gPiA+ID4gQW4gdW5kZXJzdGFuZGluZyBvZiB0 aGVzZSBkb2N1bWVudHMgYXJlIGFzc3VtZWQsIGFuZCBsaXN0ZWQgaW4NCj4gPiA+ID4gcGxhY2Vz IGxpa2UgdGhlDQo+ID4gPiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBTZWN0aW9uIDUuNC4N Cj4gPiA+DQo+ID4gPiBJIGFkbWl0IHRvIGhhdmluZyBub3QgZnVsbHkgYWJzb3JiZWQgdGhlIE5B Q00sIGFuZCBnaXZlbiB0aGUgbnVtYmVyDQo+ID4gPiBvZiBkb2N1bWVudHMgSSBoYXZlIGxlZnQg dG8gYmFsbG90IG9uIHRoaXMgd2VlaywgSSdsbCB0YWtlIHlvdXIgd29yZA0KPiA+ID4gdGhhdCBp dCdzIGNvdmVyZWQgd2VsbCBlbm91Z2ggdGhlcmUuDQo+ID4gPg0KPiA+ID4gPiA+IEZpbmFsbHks IHdlIGhhdmUgYSBmZXcgaW5zdGFuY2VzIG9mICJsZWFmIGZpbHRlci1mYWlsdXJlLWhpbnQiDQo+ ID4gPiA+ID4gdGhhdCdzIG9mIHR5cGUgInN0cmluZyIsIHByb3ZpZGluZw0KPiA+ID4gPiA+ICAg ICAgICAgICAgICAiSW5mb3JtYXRpb24gZGVzY3JpYmluZyB3aGVyZSBhbmQvb3Igd2h5IGEgcHJv dmlkZWQgZmlsdGVyDQo+ID4gPiA+ID4gICAgICAgICAgICAgICB3YXMgdW5zdXBwb3J0YWJsZSBm b3IgYSBzdWJzY3JpcHRpb24uIjsgSSBkb24ndA0KPiA+ID4gPiA+IHVuZGVyc3RhbmQgd2h5IGl0 J3MgYSBzdHJpbmcgYXMgb3Bwb3NlZCB0byBzb21lIGZvcm0gb2YNCj4gPiA+ID4gPiBtYWNoaW5l LXJlYWRhYmxlIGRhdGEuICBJcyBpdCBzdXBwb3NlZCB0byBiZSBodW1hbi1yZWFkYWJsZT8NCj4g PiA+ID4gPiBEb2VzIHRoYXQNCj4gPiA+IGJyaW5nIGluIGFueSBpbnRlcm5hdGlvbmFsaXphdGlv biBjb25zaWRlcmF0aW9ucz8NCj4gPiA+ID4NCj4gPiA+ID4gVGhlcmUgYXJlIG1hbnkgcmVhc29u cyB3aHkgYSBmaWx0ZXIgbWlnaHQgZmFpbC4gIFRoZSBhdXRob3JzDQo+ID4gPiA+IGRpZG4ndCBi ZWxpZXZlIHRoYXQNCj4gPiA+IHRoZXJlIHdhcyBlbm91Z2ggb3BlcmF0aW9uYWwgZXhwZXJpZW5j ZSB0byBzdWZmaWNpZW50bHkgZG9jdW1lbnQgdGhlDQo+ID4gPiB1bml2ZXJzZSBvZiBmYWlsdXJl IHR5cGVzIGFjcm9zcyB0aGUgc2V0IG9mIGludGVyZXN0ZWQgcGFydGllcy4gIEFzDQo+ID4gPiBh IHJlc3VsdCwgdGhlIG9wdGlvbiBzZWVtZWQgdG8gYmUgdG8gcHJvdmlkZSBubyBndWlkYW5jZSBv biB0aGUNCj4gPiA+IGZhaWx1cmUgcmVhc29uLCBvciB0byBsZXQgdGhlIHZlbmRvcnMgcHJvdmlk ZSBzb21lIGd1aWRhbmNlIChhbGJlaXQNCj4gPiA+IGp1c3QgYSAnc3RyaW5nJykuICBTbyBhdCB0 aGlzIHBvaW50IHdpdGggdGhlIHNwZWNpZmljYXRpb24sIGl0IHdvdWxkDQo+ID4gPiBiZSB1cCB0 byB0aGUgdmVuZG9yIHRvIGRldGVybWluZSB3aGV0aGVyIGl0IGlzIGh1bWFuIHJlYWRhYmxlLCBv ciB3aGV0aGVyDQo+IGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb25zIHNob3VsZCBi ZSBjb3ZlcmVkLg0KPiA+ID4gSG9wZWZ1bGx5IHdpdGggZW5vdWdoIGRlcGxveW1lbnRzIHRoaXMg bWlnaHQgYmUgcmV2aXNpdGVkIGF0IGEgZnV0dXJlIGRhdGUuDQo+ID4gPg0KPiA+ID4gV2Ugc2hv dWxkIHByb2JhYmx5IHRoaW5rIGFib3V0IHNheWluZyBzb21ldGhpbmcgYWJvdXQgaG93IGl0cyBz eW50YXgNCj4gPiA+IGFuZCBzZW1hbnRpY3MgYXJlIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLCB0 aGVuIC0tIHRoZXJlIGRvZXNuJ3QNCj4gPiA+IHNlZW0gdG8gYmUgcmVhbCBndWlkYW5jZSBmb3Ig aG93IHRvIHVzZSBpdCwgYXQgcHJlc2VudC4NCj4gPg0KPiA+IEFkZGVkIHRleHQgaW4gbGVhZiB0 byBjbGFyaWZ5IHRoaXMgYXBwcm9hY2guLi4NCj4gPg0KPiA+ICAgICAgIGxlYWYgZmlsdGVyLWZh aWx1cmUtaGludCB7DQo+ID4gICAgICAgICB0eXBlIHN0cmluZzsNCj4gPiAgICAgICAgICAgZGVz Y3JpcHRpb24NCj4gPiAgICAgICAgICAgICAiSW5mb3JtYXRpb24gZGVzY3JpYmluZyB3aGVyZSBh bmQvb3Igd2h5IGEgcHJvdmlkZWQgZmlsdGVyDQo+ID4gICAgICAgICAgICAgIHdhcyB1bnN1cHBv cnRhYmxlIGZvciBhIHN1YnNjcmlwdGlvbi4gVGhlIHN5bnRheCBhbmQNCj4gPiAgICAgICAgICAg ICAgc2VtYW50aWNzIG9mIHRoaXMgaGludCBhcmUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMuIjsN Cj4gPiAgICAgICB9DQo+ID4NCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gLS0tLQ0KPiA+ ID4gPiA+IC0tDQo+ID4gPiA+ID4gQ09NTUVOVDoNCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ ID4gLS0tLQ0KPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDEuMw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgQWxzbyBub3RlIHRoYXQgdHJhbnNwb3J0IHNwZWNpZmlj IHRyYW5zcG9ydCBkcmFmdHMgYmFzZWQgb24gdGhpcw0KPiA+ID4gPiA+ICAgIHNwZWNpZmljYXRp b24gTVVTVCBkZXRhaWwgdGhlIGxpZmUgY3ljbGUgb2YgZHluYW1pYyBzdWJzY3JpcHRpb25zLCBh cw0KPiA+ID4gPiA+ICAgIHdlbGwgYXMgdGhlIGxpZmVjeWNsZSBvZiBjb25maWd1cmVkIHN1YnNj cmlwdGlvbnMgKGlmIHN1cHBvcnRlZCkuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJJ20gbm90IHN1 cmUgSSB1bmRlcnN0YW5kIHdoYXQgYWRkaXRpb25hbCBzcGVjaWZpY2F0aW9uIGlzDQo+ID4gPiA+ ID4gbmVlZGVkIGZvciB0aGUgbGlmZWN5Y2xlIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyAt LSBkb2Vzbid0DQo+ID4gPiA+ID4gdGhlIHByZXZpb3VzIHRleHQgdGlnaHRseSB0aWUgdGhlaXIg bGlmZWN5Y2xlIHRvIHRoZSBwcmVzZW5jZSBvZg0KPiA+ID4gPiA+IGNvbmZpZ3VyYXRpb24gaW4g dGhlDQo+ID4gPiBjb25maWd1cmF0aW9uIGRhdGFzdG9yZT8NCj4gPiA+ID4NCj4gPiA+ID4gRm9y IHRoZSBtb3N0IHBhcnQgaXQgZG9lcy4gIEhvd2V2ZXIgdGhlcmUgaXMgYSByZWxhdGlvbnNoaXAg Zm9yDQo+ID4gPiA+IGV4YWN0bHkgd2hlbiB0bw0KPiA+ID4gZXN0YWJsaXNoIHRyYW5zcG9ydCBj b25uZWN0aXZpdHkgYmFzZWQgb24gdGhlIHN0YXRlIG9mIGVhY2ggcmVjZWl2ZXINCj4gPiA+IG9m IGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24uDQo+ID4gPiA+DQo+ID4gPiA+IEFzIGFuIGV4YW1w bGUgb2Ygd2hhdCBzaG91bGQgYmUgc3BlY2lmaWVkLCBzZWUgU2VjdGlvbiA1LjIgb2YNCj4gPiA+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLW5l dGNvbmYtZXZlbnQtDQo+ID4gPiA+IG5vdGkgZmljYXRpb25zLzEwLyBIZXJlIHlvdSBjYW4gc2Vl IGhvdyBORVRDT05GIGNhbGwgaG9tZSBpcw0KPiA+ID4gPiBpbnZva2VkIGF0IHRoZSBwcm9wZXIg cG9pbnRzIGluIHRoZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBzdGF0ZQ0KPiA+ID4gPiBtYWNo aW5lLg0KPiA+ID4NCj4gPiA+IEFoLCB0aGFua3MgZm9yIHRoZSBwb2ludGVyLg0KPiA+ID4NCj4g PiA+ID4gPiBuaXQ6IHBsZWFzZSBiZSBjb25zaXN0ZW50IGFib3V0ICJsaWZlIGN5Y2xlIiB2cy4g ImxpZmVjeWNsZSIgdGhyb3VnaG91dC4NCj4gPiA+ID4NCj4gPiA+ID4gRml4ZWQgbml0IHRvICJs aWZlY3ljbGUiLg0KPiA+ID4gPg0KPiA+ID4gPiA+IFNlY3Rpb24gMi4xDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiAgICBBbiBldmVudCBzdHJlYW0gaXMgYSBuYW1lZCBlbnRpdHkgb24gYSBwdWJsaXNo ZXIgd2hpY2ggZXhwb3NlcyBhDQo+ID4gPiA+ID4gICAgY29udGludW91c2x5IHVwZGF0aW5nIHNl dCBvZiBZQU5HIGVuY29kZWQgZXZlbnQgcmVjb3Jkcy4NCj4gPiA+ID4gPiBbLi4uXQ0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gbml0OiBJIGRvbid0IHRoaW5rICJZQU5HIGVuY29kZWQiIGlzIHdlbGwt ZGVmaW5lZCAoaGVyZSBhbmQNCj4gPiA+ID4gPiBiZWxvdyksIGluIHRoYXQgWUFORyBzdHJ1Y3R1 cmVzIGdlbmVyYXRlIGRhdGEgbW9kZWxzIGJ1dCBjYW4gYmUNCj4gPiA+ID4gPiBlbmNvZGVkIGlu dG8gdmFyaW91cyBmb3JtYXRzIChsaWtlIFhNTCBhbmQgSlNPTikuDQo+ID4gPiA+DQo+ID4gPiA+ IFRoaXMgaXMgdHJ1ZS4gIEkgbWFkZSB0aGUgdHdvIG9jY3VycmVuY2VzIG9mICJZQU5HIGVuY29k ZWQiIGludG8NCj4gPiA+ID4gIllBTkcNCj4gPiA+IGRlZmluZWQiLg0KPiA+ID4gPg0KPiA+ID4g PiA+IFNlY3Rpb24gMi4zDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICBJZiB0aGUgcHVibGlzaGVy IHN1cHBvcnRzIHRoZSAiZHNjcCIgZmVhdHVyZSwgdGhlbiBhIHN1YnNjcmlwdGlvbg0KPiA+ID4g PiA+ICAgIHdpdGggYSAiZHNjcCIgbGVhZiBNVVNUIHJlc3VsdCBpbiBhIGNvcnJlc3BvbmRpbmcg W1JGQzI0NzRdIERTQ1ANCj4gPiA+ID4gPiAgICBtYXJraW5nIGJlaW5nIHBsYWNlZCB3aXRoaW4g dGhlIElQIGhlYWRlciBvZiBhbnkgcmVzdWx0aW5nDQo+ID4gPiA+ID4gICAgbm90aWZpY2F0aW9u IG1lc3NhZ2VzIGFuZCBzdWJzY3JpcHRpb24gc3RhdGUgY2hhbmdlIG5vdGlmaWNhdGlvbnMuDQo+ ID4gPiA+ID4gICAgV2hlcmUgVENQIGlzIHVzZWQsIGEgcHVibGlzaGVyIHdoaWNoIHN1cHBvcnRz IHRoZSAiZHNjcCIgZmVhdHVyZQ0KPiA+ID4gPiA+ICAgIFNIT1VMRCBlbnN1cmUgdGhhdCBhIHN1 YnNjcmlwdGlvbidzIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBhcmUNCj4gPiA+ID4gPiAgICByZXR1 cm5lZCB3aXRoaW4gYSBzaW5nbGUgVENQIHRyYW5zcG9ydCBzZXNzaW9uIHdoZXJlIGFsbCB0cmFm ZmljDQo+ID4gPiA+ID4gICAgc2hhcmVzIHRoZSBzdWJzY3JpcHRpb24ncyAiZHNjcCIgbGVhZiB2 YWx1ZS4gIFdoZXJlIHRoaXMgY2Fubm90IGJlDQo+ID4gPiA+ID4gICAgZ3VhcmFudGVlZCwgYW55 ICJlc3RhYmxpc2ggc3Vic2NyaXB0aW9uIiBSUEMgcmVxdWVzdCBTSE9VTEQgYmUNCj4gPiA+ID4g PiAgICByZWplY3RlZCB3aXRoIGEgImRzY3AtdW5hdmFpbGFibGUiIGVycm9yDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBJIGNhbid0IGRlY2lkZSB3aGV0aGVyIHdlIG5lZWQgdG8gYmUgbW9yZSBleHBs aWNpdCBpbiB0aGUgc2Vjb25kDQo+ID4gPiA+ID4gYW5kL29yIHRoaXJkIHNlbnRlbmNlcyB0aGF0 IHRoaXMgcmVtYWlucyBjb250aW5nZW50IG9uIHRoZQ0KPiA+ID4gPiA+IHN1YnNjcmlwdGlvbiBp biBxdWVzdGlvbiBoYXZpbmcgYSAiZHNjcCIgbGVhZi4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIHNl bnRlbmNlcyB3ZXJlIGFscmVhZHkgbG9uZywgaXQgZmVlbHMgdG8gbWUgbGlrZSBpdCB3b3VsZCBi ZQ0KPiA+ID4gPiBtb3JlDQo+ID4gPiBjb25mdXNpbmcgdG8gcHV0IGluIG1vcmUgd29yZHMgaGVy ZS4NCj4gPiA+ID4NCj4gPiA+ID4gPiBuaXQ6IGVuZCBzZW50ZW5jZSB3aXRoIGEgZnVsbCBzdG9w DQo+ID4gPiA+DQo+ID4gPiA+IFBlcmlvZCBhZGRlZC4NCj4gPiA+ID4NCj4gPiA+ID4gPiBJIHNo YXJlIHRoZSBUU1YtQVJUIHJldmlld2VyJ3MgY29uZnVzaW9uIGFib3V0IGhvdyB0aGUgd2VpZ2h0 aW5nDQo+ID4gPiA+ID4gKGFzIHdlbGwgYXMNCj4gPiA+ID4gPiBEU0NQKSBmdW5jdGlvbmFsaXR5 IGlzIGludGVuZGVkIHRvIHdvcmsuDQo+ID4gPiA+DQo+ID4gPiA+IFNob3J0IGFuc3dlcjogIEVh cmxpZXIgdmVyc2lvbnMgb2YgdGhpcyBkcmFmdCBtYWRlIGV4cGxpY2l0DQo+ID4gPiA+IHBhcmFs bGVscyBvZiB0aGUNCj4gPiA+IHdlaWdodGluZyBtZXRob2QgdG8gSFRUUDIgUkZDLTc0NTAgc2Vj dGlvbiA1LjMuMi4gIFRoZSBvcGVyYXRpb24gb2YNCj4gPiA+IHdlaWdodGluZyBpcyBleGFjdGx5 IHRoZSBzYW1lIEhUVFAyIGRlcGVuZGVuY3kgd2VpZ2h0aW5nLiAgVGhlcmUgaXMNCj4gPiA+IGFk ZGl0aW9uYWwgZGVmaW5pdGlvbiBvZiBob3cgdGhpcyBpcyBzdXBwb3NlZCB0byB3b3JrIGluIFNl Y3Rpb24gNA0KPiA+ID4gb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmICh3aGlj aCBpcyBhbHNvIGN1cnJlbnRseSB1cCBmb3IgcmV2aWV3KS4NCj4gPiA+ID4NCj4gPiA+ID4gTG9u ZyBhbnN3ZXI6IFRTVi1BUlQgaXMgYWJzb2x1dGVseSBjb3JyZWN0IHRoYXQgYSBwdWJsaXNoZXIg bWlnaHQNCj4gPiA+ID4gZ2VuZXJhdGUgYQ0KPiA+ID4gbG90IG9mIHRyYWZmaWMuICBJbiBtYW55 IHdheXMsIGhpZ2ggdHJhZmZpYyB2b2x1bWVzIHdvdWxkIGJlIGEgc3VjY2Vzc2Z1bA0KPiBvdXRj b21lDQo+ID4gPiBmb3IgdGhpcyB3b3JrLiAgIEFzIGEgcmVzdWx0LCBtaXRpZ2F0aW5nIGRpZmZl cmVudCBkaW1lbnNpb25zIG9mIHRoaXMgdm9sdW1lIHJpc2sNCj4gaGFzDQo+ID4gPiBiZWVuIGEg ZGVzaWduIGdvYWwgc2luY2UgdGhpcyBlZmZvcnTigJlzIGluY2VwdGlvbi4gIEFuZCB0aGlzIGlz IHRoZQ0KPiA+ID4gcmVhc29uIHJvYnVzdCBRb1MgbWVjaGFuaXNtcyB3ZXJlIGluY2x1ZGVkLiAg VGhpcyBpbmNsdWRlcyBib3RoIERTQ1AgYW5kDQo+IHdlaWdodGluZy4NCj4gPiA+ID4NCj4gPiA+ ID4gSGVyZSBpcyBhIHF1aWNrIHN1bW1hcnkgb2Ygc29tZSBRb1MgbWVjaGFuaXNtcyBhdmFpbGFi bGUgaW4gdGhpcyBkcmFmdC4uLg0KPiA+ID4gPg0KPiA+ID4gPiAxLiBUaGUgcHVibGlzaGVyIGlz IGFsbG93ZWQgdG8gZGVjbGluZSBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uLg0KPiA+ID4gPiBPbmUg b2YgdGhlc2UNCj4gPiA+IHJlYXNvbnMgaXMgdGhhdCB0aGUgaW5jcmVtZW50YWwgdHJhZmZpYyBn ZW5lcmF0ZWQgYnkgYSBwYXJ0aWN1bGFyDQo+ID4gPiBpbmNyZW1lbnRhbCBzdWJzY3JpcHRpb24g d2lsbCBiZSB0b28gaGlnaC4gIFRoZXJlIGFyZSBlcnJvcnMgYmFjayB0bw0KPiA+ID4gdGhlIHN1 YnNjcmliZXIgaW5kaWNhdGluZyB0aGlzIGNvbmRpdGlvbiBleGlzdC4NCj4gPiA+ID4gMi4gQSBw dWJsaXNoZXIgY2FuIHN1c3BlbmQgYW55IHN1YnNjcmlwdGlvbiBmb3IgY2FwYWNpdHkgcmVhc29u cywNCj4gPiA+ID4gYW5kIGENCj4gPiA+IHJlY2VpdmVyIG11c3QgYmUgYWJsZSB0byBncmFjZWZ1 bGx5IGFjY2VwdCB0aGlzIHN1c3BlbnNpb24uDQo+ID4gPiA+IDMuIE11Y2ggbGlrZSB3aXRoIEhU VFAyIHN0cmVhbXMsIGhpZ2hlciBwcmlvcml0eSBzdWJzY3JpcHRpb25zDQo+ID4gPiA+IGludGVu ZGVkIGZvciBhDQo+ID4gPiBwYXJ0aWN1bGFyIHJlY2VpdmVyIGNhbiBiZSBkZXF1ZXVlZCBmaXJz dCBmcm9tIGEgcHVibGlzaGVyLg0KPiA+ID4gPiA0LiBNdWNoIGxpa2Ugd2l0aCBIVFRQMiBzdHJl YW1zLCBwcm9wb3J0aW9uYWwgc3Vic2NyaXB0aW9uDQo+ID4gPiA+IGRlcXVldWluZw0KPiA+ID4g aW50ZW5kZWQgZm9yIGEgcGFydGljdWxhciByZWNlaXZlciBjYW4gYmUgcGVyZm9ybWVkIGEgcHVi bGlzaGVyLg0KPiA+ID4gPiA1LiBEU0NQIG1hcmtpbmdzIGNhbiBiZSBwbGFjZWQgb24gc3Vic2Ny aWJlZCBkYXRhLg0KPiA+ID4gPiA2LiBNZWNoYW5pc21zIGZvciBkZXRlY3RpbmcgYW5kIHJlYWN0 aW5nIHRvIGRpZmZlcmVudCB0eXBlcyBvZg0KPiA+ID4gPiBzdWJzY3JpYmVkIGRhdGENCj4gPiA+ IGxvc3MgaGF2ZSBiZWVuIGVtYmVkZGVkLg0KPiA+ID4gPiA3LiBNZXRob2RzIGhhdmUgYmVlbiBp bmNsdWRlZCB0byBlbnN1cmUgYSBjb25maWd1cmVkIHJlY2VpdmVyIOKAnG9r4oCZc+KAnQ0KPiA+ ID4gPiBpbmZvcm1hdGlvbiBwdXNoIGJlZm9yZSBzdWJzY3JpYmVkIGRhdGEgaXMgc2VudC4gKFRo aXMgc2hvdWxkDQo+ID4gPiA+IHJlZHVjZSBvbmUgRERvUw0KPiA+ID4gdmVjdG9yLikgOC4gS2Vl cCBhbGl2ZSBtZWNoYW5pc21zIGFyZSBlc3RhYmxpc2hlZCBmb3IgZGlmZmVyZW50DQo+ID4gPiB0 cmFuc3BvcnQgdHlwZXMsIHNvIHRoYXQgc3Vic2NyaWJlZCBkYXRhIGlzbuKAmXQgYmVpbmcgc2Vu dCB3aGVuIHRoZSBpcyBubw0KPiByZWNlaXZlciBsaXN0ZW5pbmcuDQo+ID4gPiA+DQo+ID4gPiA+ IE1lY2hhbmlzbSAoNCkgaXMgaW4gcXVlc3Rpb24gaGVyZS4gICBBcyBkZWZpbmVkIGJ5IGRyYWZ0 LWlldGYtbmV0Y29uZi0NCj4gcmVzdGNvbmYtDQo+ID4gPiBub3RpZiwgdGhpcyBpcyBzdXBwb3Nl ZCB0byB3b3JrIGlkZW50aWNhbGx5IHRvIEhUVFAyIFJGQy03NDUwIHNlY3Rpb24gNS4zLjIuDQo+ ID4gPiBIb3dldmVyIHRoZXJlIHdlcmUgV0cgbWVtYmVycyB3aG8gZGlkIG5vdCB3YW50IHRvIGlu Y2x1ZGUgYQ0KPiA+ID4gZnVuY3Rpb25hbCByZXF1aXJlbWVudCBub3JtYXRpdmUgcmVmZXJlbmNl IHRvIHRoYXQgSFRUUDIgdHJhbnNwb3J0DQo+ID4gPiBpbiB0aGlzIGRvY3VtZW50IGhvd2V2ZXIu ICBUaGVyZWZvcmUgdGhlIHJlZmVyZW5jZSB0byBIVFAyIHdhcyByZW1vdmVkLg0KPiA+ID4gPg0K PiA+ID4gPiBJbiB0aGUgZW5kLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBhZmZvcmQgdG8gZ2V0IHJp ZCBvZiBzdXBwb3J0IGZvcg0KPiA+ID4gPiAoNCkgZnJvbSB0aGUNCj4gPiA+IHNwZWNpZmljYXRp b24uICAgVGhpcyB3ZWlnaHRpbmcgY2FwYWJpbGl0eSBpcyBxdWl0ZSBwb3dlcmZ1bCwgYW5kIGNh biBlYXNpbHkgYmUNCj4gPiA+IGFkZGVkIHRvIEdSUEMgYmFzZWQgc3Vic2NyaXB0aW9uIGFsdGVy bmF0aXZlcy4NCj4gPiA+DQo+ID4gPiBJIGRvbid0IHRoaW5rIEkgd2FzIHRyeWluZyB0byBzdWdn ZXN0IHJlbW92aW5nIHRoZSBtZWNoYW5pc20gZW50aXJlbHkuDQo+ID4gPiBXaGF0IHlvdSd2ZSB3 cml0dGVuIGhlcmUgaW5jbHVkZXMgYSBtZW50YWwgbW9kZWwgb2YgaGF2aW5nIGxvY2FsDQo+ID4g PiBxdWV1ZXMgb2YgbWVzc2FnZXMgdGhhdCBnZXQgZGVxdWV1ZWQgYWNjb3JkaW5nIHRvIGEgc3Bl Y2lmaWMNCj4gPiA+IGFsZ29yaXRobSwgYW5kIHRoZSB3ZWlnaHRzIGluZmx1ZW5jaW5nIHRoZSBy YXRlIG9mIGRlcXVldWluZyBhY3Jvc3MNCj4gPiA+IHF1ZXVlczsgdGhhdCBtZW50YWwgbW9kZWwg KGNvbWJpbmVkIHdpdGggdGhlIGtub3dsZWRnZSB0aGF0IGxhcmdlcg0KPiA+ID4gd2VpZ2h0IHZh bHVlcyBnZXQgbW9yZSB0cmFmZmljDQo+ID4gPiBmYXN0ZXIpIGdpdmVzIG1lIHRoZSBwaWN0dXJl IEkgd2FudGVkIGZvciAiaG93IGl0J3Mgc3VwcG9zZWQgdG8gd29yayIuDQo+ID4gPiBNYXliZSB3 ZSBjb3VsZCBkaXN0aWxsIHRoYXQgZG93biBhIGJpdCBhbmQgcHV0IGl0IGluIHRoZSBkcmFmdCwg YXMNCj4gPiA+IHRoZSBjdXJyZW50IHRleHQgaGFkIHNvbWUgbGV2ZWwgb2YgIm1hZ2ljIG9jY3Vy cyBoZXJlIiwgdG8gbWUuDQo+ID4NCj4gPiBJIGFtIGhvcGluZyB0byBsZWF2ZSB0aGluZ3MgYXMg dGhleSBhcmUgZm9yIG5vdy4gIEJhc2ljYWxseSB0aGUgbWFnaWMgdGhhdA0KPiBvY2N1cnMgY2Fu IGJlIGdsZWFuZWQgZnJvbSBTZWN0aW9uIDQgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m LW5vdGlmLiAgIEFuZA0KPiBub2JvZHkgaW4gdGhlIE5FVENPTkYgd29ybGQgaXMgbGlrZWx5IHRv IGltcGxlbWVudCB0aGlzIHR5cGUgb2YgRGVxdWV1aW5nLCBzbw0KPiB0aGV5IHNob3VsZG4ndCBo YXZlIHRoZSBleHRyYSB0ZXh0IGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gdHJpcCB0aGVtIHVw Li4NCj4gPg0KPiA+ID4gPiA+IFNlY3Rpb24gMi40LjIuMQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g ICAgUmVwbGF5IHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIGVzdGFibGlzaCBhIHN1YnNjcmlwdGlv biB3aGljaCBpcyBhbHNvDQo+ID4gPiA+ID4gICAgY2FwYWJsZSBvZiBwYXNzaW5nIHJlY2VudGx5 IGdlbmVyYXRlZCBldmVudCByZWNvcmRzLiAgSW4NCj4gPiA+ID4gPiBvdGhlciB3b3JkcywNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IG5pdC9lZGl0b3JpYWw6IHRoaXMgbGFuZ3VhZ2UgY291bGQgcHJv YmFibHkgYmUgbW9yZSBjbGVhciBhYm91dA0KPiA+ID4gPiA+ICJyZWNlbnRseSBnZW5lcmF0ZWQi IG1lYW5pbmcgImluIHRoZSBwYXN0IiwgdGhhdCBpcywgcmVjb3JkcyBmb3INCj4gPiA+ID4gPiBl dmVudHMgdGhhdCBoYXZlIGFscmVhZHkgaGFwcGVuZWQgd2hlbiB0aGUgc3Vic2NyaXB0aW9uIGlz IGVzdGFibGlzaGVkLg0KPiA+ID4gPg0KPiA+ID4gPiBUd2Vha2VkIHRvICJldmVudCByZWNvcmRz IGdlbmVyYXRlZCBpbiB0aGUgcmVjZW50IHBhc3QiDQo+ID4gPiA+DQo+ID4gPiA+ID4gU2VjdGlv biAyLjQuMw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgYW55IG51bWJlciBvZiB0aW1lcy4gIER5 bmFtaWMgc3Vic2NyaXB0aW9ucyBjYW4gb25seSBiZSBtb2RpZmllZCB2aWENCj4gPiA+ID4gPiAg ICB0aGlzIFJQQyB1c2luZyBhIHRyYW5zcG9ydCBzZXNzaW9uIGNvbm5lY3RpbmcgdG8gdGhlIHN1 YnNjcmliZXIuDQo+ID4gPiA+ID4gSWYNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IG5pdCg/KTogaXMg dGhpcyBtb3JlIHJlYWRhYmxlIGFzICJjb25uZWN0aW5nIHRvIiBvciAiY29ubmVjdGluZyBmcm9t Ig0KPiA+ID4gPiA+IHRoZSBzdWJzY3JpYmVyPyAgKFRoZSBzYW1lIHdvcmRpbmcgc2hvd3MgdXAg dGhyb3VnaG91dCB0aGUNCj4gPiA+ID4gPiBkb2N1bWVudCwgYnV0IEknbGwgdHJ5IHRvIGp1c3Qg Y29tbWVudCBvbmNlLikNCj4gPiA+ID4NCj4gPiA+ID4gSSBleHBlY3QgdGhhdCBpdCBzaG91bGQg YmUgY2xlYXIgZW5vdWdoIGVpdGhlciB3YXkuICBJIGJlbGlldmUNCj4gPiA+ID4gbGVhdmluZyB0 aGUgY3VycmVudA0KPiA+ID4gdGV4dCBzaG91bGQgbm90IGltcGFjdCBpbXBsZW1lbnRhdGlvbnMu DQo+ID4gPiA+DQo+ID4gPiA+ID4gU2VjdGlvbiAyLjQuNQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g SXMgdGhlcmUgYW55IGRpc3RpbmN0aW9uIGJldHdlZW4gImtpbGxpbmcgYSBzdWJzY3JpcHRpb24i IGFuZA0KPiA+ID4gPiA+ICJhZG1pbmlzdHJhdGl2ZWx5IGRlbGV0aW5nIGEgc3Vic2NyaXB0aW9u Ij8gIEl0J3MgdW5jbGVhciB0byBtZQ0KPiA+ID4gPiA+IHRoYXQgd2UgbmVlZCB0aGUgZXh0cmEg Y29ubm90YXRpb25zIG9mIHRoZSB3b3JkICJraWxsIiwgaGVyZS4NCj4gPiA+ID4NCj4gPiA+ID4g V2UgY2hvc2UgdG8gdXNlIGEgZGlmZmVyZW50IFJQQyBuYW1lIHNvIHRoYXQgYWRtaW5pc3RyYXRp dmUgYWNjZXNzDQo+ID4gPiA+IGNvbnRyb2wNCj4gPiA+IHBlcm1pc3Npb25zIGRpZmZlcmVuY2Vz IGJldHdlZW4gdGhlIGtpbGwtc3Vic2NyaXB0aW9uIGFuZA0KPiA+ID4gZGVsZXRlLXN1YnNjcmlw dGlvbiB3b3VsZCBiZSBleHBsaWNpdCBhbmQgb2J2aW91cy4gIEFuZCBvbmNlIHdlIGhhZA0KPiA+ ID4gYSBuZXcgUlBDIG5hbWUsIGl0IHNlZW1lZCBlYXNpZXIgZm9yIHRoZSByZWFkZXIgdG8gY29u dGludWUgdXNpbmcgdGhlICJraWxsIg0KPiB3b3JkIGZvciB0aGF0IFJQQy4NCj4gPiA+DQo+ID4g PiBJbiB2YWN1dW0sICJhZG1pbi1kZWxldGUtc3Vic2NyaXB0aW9uIiBzZWVtcyBsaWtlIGEgZmlu ZSBuYW1lLCB0bw0KPiA+ID4gbWUuICBCdXQgdGhpcyBpcyBhIG5vbi1ibG9ja2luZyBjb21tZW50 IHNvIEknbGwgc3RvcCBwdXNoaW5nIG5vdy4NCj4gPiA+DQo+ID4gPiA+ID4gU2VjdGlvbiAyLjQu Ng0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgQXMgYSByZXN1bHQgb2YgdGhpcyBtaXh0dXJlLCBo b3cgc3Vic2NyaXB0aW9uIGVycm9ycyBhcmUNCj4gPiA+ID4gPiBlbmNvZGVkDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBuaXQ6ICJtaXh0dXJlIiBkb2Vzbid0IHNlZW0gbGlrZSB0aGUgcmlnaHQgd29y ZCB0byBtZTsgInZhcmlldHkiDQo+ID4gPiA+ID4gb3IgInZhcmllZCBwb3B1bGF0aW9uIiBhcmUg dGhlIGZpcnN0IGFsdGVybmF0aXZlcyB0aGF0IGNvbWUgdG8NCj4gPiA+ID4gPiBtaW5kLCB0aG91 Z2ggdGhleSBhcmUgbm90IHBlcmZlY3QgZWl0aGVyLg0KPiA+ID4gPg0KPiA+ID4gPiBDaGFuZ2Vk IHRvICd2YXJpZXR5Jy4NCj4gPiA+ID4NCj4gPiA+ID4gPiBJcyB0aGVyZSBzb21lIHNvcnQgb2Yg ImFjY2VzcyBkZW5pZWQiIGVycm9yIHRoYXQgY291bGQgcmVzdWx0DQo+ID4gPiA+ID4gZnJvbQ0K PiA+ID4gPiA+IGtpbGwtIHN1YnNjcmlwdGlvbiBSUENzPyAgKFRoZSB0YWJsZS9hcnR3b3JrIG9u bHkgbGlzdHMNCj4gPiA+ID4gPiAibm8tc3VjaC1zdWJzY3JpcHRpb24iLikNCj4gPiA+ID4NCj4g PiA+ID4gQWNjZXNzIGRlbmllZCB3aGVuIGFuIFJQQyBmYWlscyBhY2Nlc3MgY29udHJvbCBpcyBw YXJ0IG9mIHRoZSBiYXNlDQo+ID4gPiA+IHRyYW5zcG9ydA0KPiA+ID4gZXJyb3IgdHlwZXMgZm9y IHRoZSBSUEMuICAgSS5lLiwgdHJhbnNwb3J0cyBsaWtlIE5FVENPTkYgYW5kIFJFU1RDT05GDQo+ IGFscmVhZHkNCj4gPiA+IGhhdmUgbm9uLXN1YnNjcmlwdGlvbi1zcGVjaWZpYyBlcnJvcnMgbGlr ZSB0aGlzIG9uZSBhbHJlYWR5IGNvdmVyZWQuDQo+ID4gPg0KPiA+ID4gQWgsIG9mIGNvdXJzZSwg YW5kIHdlIHJlcXVpcmUgcHJvY2Vzc2luZyBvZiB0cmFuc3BvcnQtbGV2ZWwgZXJyb3JzDQo+ID4g PiBiZWZvcmUgdGhlc2Ugb25lcywgc28gaXQgYWxsIHdvcmtzIG91dCBmaW5lLg0KPiA+ID4NCj4g PiA+ID4gPiBTZWN0aW9uIDIuNQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSXQncyBpbnRlcmVzdGlu ZyB0byBzZWUgYSBzbGlnaHQgZGljaG90b215IGJldHdlZW4gZHluYW1pYyBhbmQNCj4gPiA+ID4g PiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMsIGluIHRoYXQgKElJVUMpIGZvciBkeW5hbWljDQo+ ID4gPiA+ID4gc3Vic2NyaXB0aW9ucywgYSBtb2RpZmljYXRpb24gZXZlbnQgdW4tIHN1c3BlbmRz IGEgc3Vic2NyaXB0aW9uDQo+ID4gPiA+ID4gaW1tZWRpYXRlbHksIGJ1dCBmb3IgY29uZmlndXJl ZCBzdWJzY3JpcHRpb25zIHRoZSBwdWJsaXNoZXINCj4gPiA+ID4gPiBzZWVtcyB0byBoYXZlIHNv bWUgbGF0aXR1ZGUgdG8gcmV0YWluIHRoZSBzdWJzY3JpcHRpb24gaW4gdGhlDQo+ID4gPiA+ID4g c3VzcGVuZGVkIHN0YXRlIGZvciBzb21lIHRpbWUgYmVmb3JlIHVuLXN1c3BlbmRpbmcgaXQgYW5k DQo+ID4gPiA+ID4gc2VuZGluZyB0aGUgInN1YnNjcmlwdGlvbi1tb2RpZmllZCIgc3RhdGUNCj4g PiA+IGNoYW5nZSBtZXNzYWdlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICBJbiB0aGlzIGNhc2UsIGEgc2VwYXJhdGUgZHluYW1pYyBzdWJzY3JpcHRpb24gY2FuIGJlDQo+ ID4gPiA+ID4gICAgZXN0YWJsaXNoZWQgdG8gcmV0cmFuc21pdCB0aGUgbWlzc2luZyBldmVudCBy ZWNvcmRzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRG8geW91IHdhbnQgdG8gcHV0IGluIGEgcG9p bnRlciB0byByZXBsYXktc3RhcnQtdGltZSBoZXJlPw0KPiA+ID4gPg0KPiA+ID4gPiBJIHRob3Vn aHQgZ2V0dGluZyB0byB0aGF0IGxldmVsIG9mIGRldGFpbCBpbiB0aGUgaW50cm8gd2FzDQo+ID4g PiA+IGNvbmZ1c2luZyBmb3IgdGhpcyBpbnRybw0KPiA+ID4gc2VjdGlvbi4NCj4gPiA+DQo+ID4g PiBPa2F5LiAgKE1heWJlIGEgcGFyZW50aGV0aWNhbCAicmVwbGF5IiBhcyBhIHNlYXJjaCB0ZXJt IHdvdWxkIGhlbHANCj4gPiA+IHdpdGhvdXQgYmVpbmcgY29uZnVzaW5nLCBidXQgZW50aXJlbHkg eW91ciBjYWxsLikNCj4gPg0KPiA+IEkgd2lsbCBsZWF2ZSBhcy1pcy4NCj4gPg0KPiA+ID4gPiA+ IFNlY3Rpb24gMi41LjENCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgICAgIEV2ZW50IHJlY29y ZHMgYXJlIG9ubHkgc2VudCB0byBhY3RpdmUgcmVjZWl2ZXJzLiAgUmVjZWl2ZXJzIG9mDQo+ID4g PiA+ID4gICAgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiByZW1haW4gYWN0aXZlIGlmIGJvdGgg dHJhbnNwb3J0DQo+ID4gPiA+ID4gICAgY29ubmVjdGl2aXR5IGNhbiBiZSB2ZXJpZmllZCB0byB0 aGUgcmVjZWl2ZXIsIGFuZCBldmVudCByZWNvcmRzIGFyZQ0KPiA+ID4gPiA+ICAgIG5vdCBiZWlu ZyBkcm9wcGVkIGR1ZSB0byBhIHB1Ymxpc2hlciBidWZmZXIgb3ZlcmZsb3cuICBbLi4uXQ0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gbml0OiAiYnVmZmVyIG92ZXJmbG93IiBpcyBhIHRlY2huaWNhbCB0 ZXJtIGluIHNlY3VyaXR5IGNpcmNsZXMNCj4gPiA+ID4gPiBpbmRpY2F0aW5nIGEgcG90ZW50aWFs bHkgZXhwbG9pdGFibGUgc2VjdXJpdHkgZmxhdzsgd291bGQNCj4gPiA+ID4gPiAicHVibGlzaGVy IGJ1ZmZlciBjYXBhY2l0eSBiZWluZyByZWFjaGVkIiBiZSBhbiBhY2NlcHRhYmxlDQo+ID4gPiA+ ID4gc3Vic3RpdHV0ZSAoaGVyZSBhbmQNCj4gPiA+IGJlbG93KT8NCj4gPiA+ID4NCj4gPiA+ID4g Q2hhbmdlIG1hZGUNCj4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDIuNy43DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiAgICBUaGlzIG5vdGlmaWNhdGlvbiBpbmRpY2F0ZXMgdGhhdCBhbGwgb2YgdGhl IGV2ZW50IHJlY29yZHMgcHJpb3IgdG8NCj4gPiA+ID4gPiAgICB0aGUgY3VycmVudCB0aW1lIGhh dmUgYmVlbiBwYXNzZWQgdG8gYSByZWNlaXZlci4gIEl0IGlzIHNlbnQgYmVmb3JlDQo+ID4gPiA+ ID4gICAgYW55IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGNvbnRhaW5pbmcgYW4gZXZlbnQgcmVjb3Jk IHdpdGggYSB0aW1lc3RhbXANCj4gPiA+ID4gPiAgICBsYXRlciB0aGFuICgxKSB0aGUgInN0b3At dGltZSIgb3IgKDIpIHRoZSBzdWJzY3JpcHRpb24ncyBzdGFydCB0aW1lLg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gbml0KD8pOiB0aGlzIHRleHQgc2VlbXMgdG8gaW1wbHkgdGhhdCBhIG5vdGlmaWNh dGlvbiBtZXNzYWdlDQo+ID4gPiA+ID4gd2l0aCBhIHRpbWVzdGFtcCBsYXRlciB0aGFuIHRoZSAi c3RvcC10aW1lIiBtaWdodCBhY3R1YWxseSBiZQ0KPiA+ID4gPiA+IHNlbnQsIHdoaWNoIElJVUMg aXMNCj4gPiA+IG5vdCB0aGUgY2FzZS4NCj4gPiA+ID4NCj4gPiA+ID4gWW91IGFyZSBjb3JyZWN0 IHRoYXQgaXQgaXMgbm90IHNlbnQuICBCdXQgdGhlIGV2ZW50IHJlY29yZCBkb2VzDQo+ID4gPiA+ IGV4aXN0IG9uIHRoZQ0KPiA+ID4gc3RyZWFtLg0KPiA+ID4gPg0KPiA+ID4gPiBJIHRoaW5rIGl0 IG9idmlvdXMsIGJ1dCBpZiB5b3Ugd2FudCBJIGNvdWxkIGFkZCB0aGUgZm9sbG93aW5nDQo+ID4g PiA+IHNlbnRlbmNlIHRvIHRoZSBlbmQNCj4gPiA+IG9mIHRoZSBzdWJzZXF1ZW50IHBhcmFncmFw aC4gICJJZiBhIHN0b3AtdGltZSBoYXMgYmVlbiBleGNlZWQgZHVyaW5nDQo+ID4gPiByZXBsYXks IG5vIHN1YnNlcXVlbnQgZXZlbnQgcmVjb3JkcyBhcmUgc2VudCBmb2xsb3dpbmcgdGhlIHNlbmRp bmcNCj4gPiA+IG9mIGEgInJlcGxheS0gY29tcGxldGVkIiBub3RpZmljYXRpb24uIg0KPiA+ID4N Cj4gPiA+IEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhIG5lZWQgdG8gYWRkIHRoYXQgc2VudGVuY2Us IGJ1dCB0aGFua3MgZm9yIG9mZmVyaW5nLg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0 aW9uIDIuOQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gbml0OiB0aGUgbmFtZSAic3VwcG9ydHMtdnJm IiBmb3IgdGhlIGZlYXR1cmUgZG9lc24ndCByZWFsbHkNCj4gPiA+ID4gPiBwYXJhbGxlbCB0aGUg b3RoZXIgZmVhdHVyZSBuYW1lcywgdGhhdCBkb24ndCBpbmNsdWRlIGEgd29yZCBsaWtlICJzdXBw b3J0Ig0KPiA+ID4gPiA+IGFuZCByYXRoZXIganVzdCBkZXNjcmliZSB0aGUgYWN0dWFsIGZlYXR1 cmUuDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgaXMgdHJ1ZS4gIFNldmVyYWwgeWVhcnMgYWdvIHdo ZW4gc29tZW9uZSBwcm9wb3NlZCB0aGlzIG5hbWUsDQo+ID4gPiA+IHRoZXJlIHdhcw0KPiA+ID4g YSByZWFzb24uICBCdXQgSSBjYW4ndCByZW1lbWJlciB3aGF0IGl0IGlzIHJpZ2h0IG5vdy4gIFNv IGhvcGVmdWxseQ0KPiA+ID4gd2UgY2FuIGxlYXZlIGl0IHNvIGFzIG5vdCB0byBicmVhayBzb21l b25lJ3MgdGhpbmtpbmcuDQo+ID4gPiA+DQo+ID4gPiA+ID4gU2VjdGlvbiAzLjENCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IElzIHRoZXJlIGFueSByaXNrIG9mIGNvbGxpc2lvbiBpbiBldmVudCBzdHJl YW0gbmFtZXMgZnJvbQ0KPiA+ID4gPiA+IHZlbmRvci1zcGVjaWZpYyBzdHJlYW1zPyAgKFdlIGRv bid0IHNlZW0gdG8gY3JlYXRlIGFuIElBTkENCj4gPiA+ID4gPiByZWdpc3RyeSBmb3IgdGhlbSwg Zm9yIGV4YW1wbGUuKQ0KPiA+ID4gPg0KPiA+ID4gPiBJbiB0aGVvcnkgeWVzLiAgQnV0IGl0IGhh cyBub3QgcHJvdmVuIHRvIGJlIGFuIGlzc3VlIHdpdGggUkZDLTUyNzcNCj4gPiA+ID4gc3RyZWFt cywgc28gaXQNCj4gPiA+IGRvZXNuJ3Qgc2VlbSB3b3J0aCBpdCB0byBkbyBzb21ldGhpbmcgbmV3 IG5vdy4gICBTbyBpbiB0aGlzIGRvY3VtZW50LCB3ZQ0KPiBoYXZlDQo+ID4gPiBvbmUgSUVURiBz dHJlYW0gIk5FVENPTkYiIGRlZmluZWQgaW4gU2VjdGlvbiAyLjEuICBIb3BlZnVsbHkgaXQgaXMg ZW5vdWdoIHRvDQo+ID4gPiBoYXJkLWNvZGUgdGhpcy4gICBXZSBjYW4gYWx3YXlzIHJldmlzaXQg aWYgSUVURiBncm91cHMgd2FudCB0byBzdGFydCBkZWZpbmluZw0KPiA+ID4gc3RyZWFtcw0KPiA+ ID4gPg0KPiA+ID4gPiA+IFNlY3Rpb24gNA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgaWRlbnRp dHkgc3Vic2NyaXB0aW9uLXN1c3BlbmRlZC1yZWFzb24gew0KPiA+ID4gPiA+ICAgICAgIGRlc2Ny aXB0aW9uDQo+ID4gPiA+ID4gICAgICAgICJQcm9ibGVtIGNvbmRpdGlvbiBjb21tdW5pY2F0ZWQg dG8gYSByZWNlaXZlciBhcyBwYXJ0IG9mIGENCj4gPiA+ID4gPiAgICAgICAgJ3N1YnNjcmlwdGlv bi10ZXJtaW5hdGVkJyBub3RpZmljYXRpb24uIjsNCj4gPiA+ID4gPiAgICB9DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiAgICBpZGVudGl0eSBzdWJzY3JpcHRpb24tdGVybWluYXRlZC1yZWFzb24gew0K PiA+ID4gPiA+ICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gPiA+ID4gICAgICAgICJQcm9ibGVtIGNv bmRpdGlvbiBjb21tdW5pY2F0ZWQgdG8gYSByZWNlaXZlciBhcyBwYXJ0IG9mIGENCj4gPiA+ID4g PiAgICAgICAgJ3N1YnNjcmlwdGlvbi10ZXJtaW5hdGVkJyBub3RpZmljYXRpb24uIjsNCj4gPiA+ ID4gPiAgICB9DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBBcmUgdGhlc2UgZGVzY3JpcHRpb25zIHN1 cHBvc2VkIHRvIGJlIHRoZSBzYW1lPw0KPiA+ID4gPg0KPiA+ID4gPiBHb29kIGNhdGNoLiAgIEZp eGVkIHRoZSAnc3Vic2NyaXB0aW9uLXN1c3BlbmRlZCcgZGVzY3JpcHRpb24uDQo+ID4gPiA+DQo+ ID4gPiA+ID4gICAgaWRlbnRpdHkgY29uZmlndXJhYmxlLWVuY29kaW5nIHsNCj4gPiA+ID4gPiAg ICAgIGRlc2NyaXB0aW9uDQo+ID4gPiA+ID4gICAgICAgICJJZiBhIHRyYW5zcG9ydCBpZGVudGl0 eSBkZXJpdmVzIGZyb20gdGhpcyBpZGVudGl0eSwgaXQgbWVhbnMNCj4gPiA+ID4gPiAgICAgICAg IHRoYXQgaXQgc3VwcG9ydHMgY29uZmlndXJhYmxlIGVuY29kaW5ncy4gIEFuIGV4YW1wbGUgb2YN Cj4gPiA+ID4gPiBhIFsuLi5dDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJcyBpdCBpbnRlbmRlZCB0 aGF0IHN1Y2ggZnV0dXJlIHRyYW5zcG9ydHMgKG9yIGZ1dHVyZQ0KPiA+ID4gPiA+IGVuY29kaW5n cz8pIHdpbGwgZGVyaXZlIGZyb20gYm90aCB0aGlzIGFuZCB0aGUgbm9ybWFsIGJhc2UgaWRlbnRp dHkgKGkuZS4sDQo+ICJ0cmFuc3BvcnQiKT8NCj4gPiA+ID4gPiBJIGd1ZXNzIEknbSBhc2tpbmcg d2h5IHRoaXMgaWRlbnRpdHkgZG9lcyBub3QgZGVyaXZlIGZyb20gdGhlDQo+ID4gPiA+ID4gY29y cmVzcG9uZGluZyBiYXNlLCBidXQgdGhhdCdzIGp1c3QgYSBzdHlsZSBxdWVzdGlvbiBhbmQgbm90 DQo+ID4gPiA+ID4gcmVhbGx5IGEgcHJvdG9jb2wgbWF0dGVyLCBtYWtpbmcgdGhpcyBxdWVzdGlv biBhIHNpZGUgbm90ZS4NCj4gPiA+ID4NCj4gPiA+ID4gWWVzLiAgRnV0dXJlIGlkZW50aXRpZXMg Y2FuIGRlcml2ZSBmcm9tIGNvbmZpZ3VyYWJsZS1lbmNvZGluZw0KPiA+ID4gPg0KPiA+ID4gPiA+ ICAgICAgbGVhZiB3ZWlnaHRpbmcgew0KPiA+ID4gPiA+ICAgICAgICBpZi1mZWF0dXJlICJxb3Mi Ow0KPiA+ID4gPiA+ICAgICAgICB0eXBlIHVpbnQ4IHsNCj4gPiA+ID4gPiAgICAgICAgICAgcmFu Z2UgIjAgLi4gMjU1IjsNCj4gPiA+ID4gPiAgICAgICAgfQ0KPiA+ID4gPiA+ICAgICAgICBkZXNj cmlwdGlvbg0KPiA+ID4gPiA+ICAgICAgICAgICJSZWxhdGl2ZSB3ZWlnaHRpbmcgZm9yIGEgc3Vi c2NyaXB0aW9uLiBBbGxvd3MgYW4gdW5kZXJseWluZw0KPiA+ID4gPiA+ICAgICAgICAgICB0cmFu c3BvcnQgbGF5ZXIgcGVyZm9ybSBpbmZvcm1lZCBsb2FkIGJhbGFuY2UgYWxsb2NhdGlvbnMNCj4g PiA+ID4gPiAgICAgICAgICAgYmV0d2VlbiB2YXJpb3VzIHN1YnNjcmlwdGlvbnMiOw0KPiA+ID4g PiA+ICAgICAgICByZWZlcmVuY2UNCj4gPiA+ID4gPiAgICAgICAgICAiUkZDLTc1NDAsIHNlY3Rp b24gNS4zLjIiOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRG8gd2Ugd2FudCB0byBjaGFzZSB0aGUg cmVmZXJlbmNlIGZvciByZWFkZXJzIGFuZCBzYXkgdGhhdA0KPiA+ID4gPiA+IGxhcmdlciB3ZWln aHRzIGdldCBtb3JlIHJlc291cmNlcz8NCj4gPiA+ID4NCj4gPiA+ID4gSSBwdXQgaW4gIkxhcmdl ciB3ZWlnaHRzIGdldCBtb3JlIHJlc291cmNlcy4iIGFzIHNlbnRlbmNlIHR3byBvZg0KPiA+ID4g PiB0aGUNCj4gPiA+IGRlc2NyaXB0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgbGVhZiBl bmNvZGluZyB7DQo+ID4gPiA+ID4gICAgICAgIHdoZW4gJ25vdCguLi90cmFuc3BvcnQpIG9yIGRl cml2ZWQtZnJvbSguLi90cmFuc3BvcnQsDQo+ID4gPiA+ID4gICAgICAgICJzbjpjb25maWd1cmFi bGUtZW5jb2RpbmciKSc7DQo+ID4gPiA+ID4gICAgICAgIHR5cGUgZW5jb2Rpbmc7DQo+ID4gPiA+ ID4gICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gPiA+ID4gICAgICAgICAgIlRoZSB0eXBlIG9mIGVu Y29kaW5nIGZvciBub3RpZmljYXRpb24gbWVzc2FnZXMuICAgRm9yIGENCj4gPiA+ID4gPiAgICAg ICAgICBkeW5hbWljIHN1YnNjcmlwdGlvbiwgaWYgbm90IGluY2x1ZGVkIGFzIHBhcnQgb2YgYW4g ZXN0YWJsaXNoLQ0KPiA+ID4gPiA+ICAgICAgICAgIHN1YnNjcmlwdGlvbiBSUEMsIHRoZSBlbmNv ZGluZyB3aWxsIGJlIHBvcHVsYXRlZCB3aXRoIHRoZQ0KPiA+ID4gPiA+ICAgICAgICAgIGVuY29k aW5nIHVzZWQgYnkgdGhhdCBSUEMuICBGb3IgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiwgaWYN Cj4gPiA+ID4gPiAgICAgICAgICBub3QgZXhwbGljaXRseSBjb25maWd1cmVkIHRoZSBlbmNvZGlu ZyB3aXRoIGJlIHRoZSBkZWZhdWx0DQo+ID4gPiA+ID4gICAgICAgICAgZW5jb2RpbmcgZm9yIGFu IHVuZGVybHlpbmcgdHJhbnNwb3J0LiI7DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaGVyZSBpcyB0 aGUgZGVmYXVsdCBlbmNvZGluZyBmb3IgYW4gdW5kZXJseWluZyB0cmFuc3BvcnQgc3BlY2lmaWVk Pw0KPiA+ID4gPiA+IFNlY3Rpb24gNS4zIGRvZXMgbm90IHNlZW0gdG8gc2F5IHRoYXQgYSB0cmFu c3BvcnQgc3BlY2lmaWNhdGlvbg0KPiA+ID4gPiA+IG11c3QgcHJvdmlkZSB0aGlzIGluZm9ybWF0 aW9uLCBub3IgZG9lcyBTZWN0aW9uIDEuMyAod2hpY2gNCj4gPiA+ID4gPiBtZW50aW9ucyB0aGF0 IHRyYW5zcG9ydCBzcGVjaWZpY2F0aW9ucyBtdXN0IGRldGFpbCB0aGUgbGlmZWN5Y2xlDQo+ID4g PiA+ID4gb2YgZHluYW1pYyBzdWJzY3JpcHRpb25zKSwgbm9yIGRvZXMgU2VjdGlvbiAyLjUuNyAo dGhhdA0KPiA+ID4gPiA+IGRpc2N1c3NlcyB0aGUgbmVlZCBmb3IgYSBzZXBhcmF0ZSBtb2RlbCBh dWdtZW50aW5nDQo+ID4gPiA+ID4gL3N1YnNjcmlwdGlvbnMvc3Vic2NyaXB0aW9uL3JlY2VpdmVy cy9yZWNlaXZlcg0KPiA+ID4gPiA+IHRvIHByb3ZpZGUgdHJhbnNwb3J0IGRldGFpbHMpLg0KPiA+ ID4gPg0KPiA+ID4gPiBGb3IgbWFueSB0cmFuc3BvcnRzLCB0aGUgZW5jb2RpbmcgaXMgcmVkdW5k YW50IGluZm9ybWF0aW9uLiAgVGhlDQo+ID4gPiA+IHJlYXNvbiBpcyB0aGF0IHRyYW5zcG9ydCBS RkNzIHRoZW1zZWx2ZXMgZGVmaW5lIHN1cHBvcnRlZA0KPiA+ID4gPiBlbmNvZGluZ3MgKGUuZy4s ICJORVRDT05GICsgWE1MIiAsICJSRVNUQ09ORiArIEpTT04iKS4gIEFuZCBXRw0KPiA+ID4gPiBt ZW1iZXJzIHdobyBidWlsdCB0aG9zZSB0cmFuc3BvcnQgUkZDcyBkaWQgbm90IHdhbnQgdG8gYWxs b3cNCj4gPiA+ID4gb3BlcmF0b3JzIHRvIG1pc2NvbmZpZ3VyZSBhbnl0aGluZyBoZXJlLiAgKEFz IGFuIGFzaWRlLCB0aGlzDQo+ID4gPiA+IGRlc2lyZSB0byBzaWduaWZpY2FudGx5IHJlZHVjZSB0 aGUgb3Bwb3J0dW5pdHkgZm9yIG1pc2NvbmZpZ3VyYXRpb24gaXMgd2hhdA0KPiBkcm92ZSB0aGUg aW50ZXJlc3RpbmcgJ3doZW4nDQo+ID4gPiA+IHN0YXRlbWVudCBhYm92ZS4pDQo+ID4gPiA+DQo+ ID4gPiA+IEJ1dCBlbmNvZGluZ3MgY2FuIHZhcnkuICBUaGlzIGlzIHRoZSBwdXJwb3NlIG9mIHRo ZSBpZGVudGl0eQ0KPiA+ID4gPiAiY29uZmlndXJhYmxlLQ0KPiA+ID4gZW5jb2RpbmciIGluIHRo ZSBZQU5HIG1vZGVsLiAgIEFuZCB0aGlzIGlkZW50aXR5IGRvZXMgc2F5IHRoYXQgIkZ1cnRoZXIN Cj4gZGV0YWlscw0KPiA+ID4gZm9yIGFueSBzcGVjaWZpYyBjb25maWd1cmFibGUgZW5jb2Rpbmcg d291bGQgYmUgZXhwbG9yZWQgaW4gYQ0KPiA+ID4gdHJhbnNwb3J0IGRvY3VtZW50IGJhc2VkIG9u IHRoaXMgc3BlY2lmaWNhdGlvbi4iICBJIGd1ZXNzIHRoaXMNCj4gPiA+IGluZm9ybWF0aW9uIGNv dWxkIGJlIHJlcGVhdGVkIGluIFNlY3Rpb24gNS4zIGlmIG5lY2Vzc2FyeS4NCj4gPiA+DQo+ID4g PiBJIHRoaW5rIHRoYXQgZHVwbGljYXRpb24gd291bGQgYmUgbXkgcHJlZmVyZW5jZSwgdG8gZ2V0 IHRoaW5ncw0KPiA+ID4gY29uc29saWRhdGVkIGluIG9uZSBwbGFjZS4NCj4gPg0KPiA+IFBlciBh Ym92ZSBpbiB0aGUgZGlzY3VzcywgdGV4dCBhZGRlZCB0byA1LjMuDQo+ID4NCj4gPiA+ID4gPiAg ICAgICAgY2hvaWNlIG5vdGlmaWNhdGlvbi1tZXNzYWdlLW9yaWdpbiB7DQo+ID4gPiA+ID4gICAg ICAgICAgaWYtZmVhdHVyZSAiY29uZmlndXJlZCI7DQo+ID4gPiA+ID4gICAgICAgICAgZGVzY3Jp cHRpb24NCj4gPiA+ID4gPiAgICAgICAgICAgICJJZGVudGlmaWVzIHRoZSBlZ3Jlc3MgaW50ZXJm YWNlIG9uIHRoZSBwdWJsaXNoZXIgZnJvbSB3aGljaA0KPiA+ID4gPiA+ICAgICAgICAgICAgIG5v dGlmaWNhdGlvbiBtZXNzYWdlcyBhcmUgdG8gYmUgc2VudC4iOw0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gbml0OiBnaXZlbiB0aGUgYWRkcmVzcy1vcmlnaW5hdGVkIGNhc2UsIHBlcmhhcHMgInRoZSBl Z3Jlc3MgaW50ZXJmYWNlIg0KPiA+ID4gPiA+IGlzIG5vdCBxdWl0ZSBjb3JyZWN0IGFueW1vcmUu DQo+ID4gPiA+DQo+ID4gPiA+IEV2ZXJ5IGFsdGVybmF0aXZlIEkgY29tZSB1cCB3aXRoIHNlZW1z IG1vcmUgcHJvYmxlbWF0aWMuICAgSSBiZWxpZXZlDQo+IHJlYWRlcnMNCj4gPiA+IHNob3VsZCBi ZSBhYmxlIHRvIHVuZGVyc3RhbmQgYmFzZWQgb24gdGhlIGNhc2VzIGJlbG93Lg0KPiA+ID4NCj4g PiA+IChJIGRvbid0IGhhdmUgYW55IGJldHRlciBzdWdnZXN0aW9ucywgZWl0aGVyLikNCj4gPiA+ DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgZW51bSBjb25uZWN0aW5nIHsNCj4gPiA+ID4gPiAg ICAgICAgICAgICAgICAgIHZhbHVlIDM7DQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICBpZi1m ZWF0dXJlICJjb25maWd1cmVkIjsNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICJBIHN1YnNjcmlwdGlvbiBoYXMgYmVl biBjb25maWd1cmVkLCBidXQgYQ0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAnc3Vic2Ny aXB0aW9uLXN0YXJ0ZWQnIHN1YnNjcmlwdGlvbiBzdGF0ZSBjaGFuZ2UNCj4gPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIG5lZWRzIHRvIGJlIHN1Y2Nlc3NmdWxseSByZWNl aXZlZCBiZWZvcmUNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIG1l c3NhZ2VzIGFyZSBzZW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gbml0OiBzdWNjZXNzZnVsIHJl Y2VpcHQgaGFwcGVucyBvbiB0aGUgcmVjZWl2ZXIgYnV0IHNlbmRpbmcNCj4gPiA+ID4gPiBoYXBw ZW5zIG9uIHRoZSBwdWJsaXNoZXIsIHNvIHRoZXJlJ3MgYSBiaXQgb2YgYSBtaXNtYXRjaCBpbiB0 aGUNCj4gPiA+ID4gPiBzZW50ZW5jZSBzdWJqZWN0IGhlcmUuICBQZXJoYXBzIHdlIGNvdWxkIHRh bGsgYWJvdXQNCj4gPiA+ID4gPiAic3VjY2Vzc2Z1bGx5IHNlbnQiIHN0YXRlLWNoYW5nZXMNCj4g PiA+IHRvIHJlc29sdmUgdGhpbmdzLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIHdvcmRpbmcgaXMg YXMgaW50ZW5kZWQuICBCYXNpY2FsbHkgaXQgaXMgaGlnaGx5IGRlc2lyYWJsZSBmb3INCj4gPiA+ ID4gY29uZmlndXJlZCByZWNlaXZlcnMgd2lsbCBuZWVkIHRvIGFja25vd2xlZGdlbWVudCBvZiBz dWNjZXNzZnVsDQo+ID4gPiA+IHJlY2VpcHQgb2YgYSAic3Vic2NyaXB0aW9uLXN0YXJ0ZWQiIGJl Zm9yZSBzZW5kaW5nIGV2ZW50IHJlY29yZHMuDQo+ID4gPiA+IFRoaXMgaGVscHMgcHJldmVudCBE RE9TIGF0dGFja3MuICBUaGUgbWVjaGFuaXNtIGZvciBnYWluaW5nIGFuDQo+ID4gPiA+IGFja25v d2xlZGdlbWVudCB2YXJpZXMgYnkgdHJhbnNwb3J0LiAgQXMgYW4gZXhhbXBsZSBvZiB3aGF0IHdl DQo+ID4gPiA+IGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCBoZXJlLCBzZWUNCj4gPiA+ID4NCj4g PiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25m LXJlc3Rjb25mLW5vdGlmDQo+ID4gPiA+IC8wNC8NCj4gPiA+IFNlY3Rpb24gMy4xLjINCj4gPiA+ ID4gSG9wZWZ1bGx5IHRoaXMgdHlwZSBvZiBtZWNoYW5pc20gd2lsbCBiZSByZXZpdmVkIGluIGZ1 dHVyZSBkcmFmdHMuDQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSB0aGF0IGdldHRpbmcgZXhwbGljaXQg YWNrbm93bGVkZ21lbnQgb2YgZGVsaXZlcnkgaXMgaGlnaGx5DQo+ID4gPiBkZXNpcmFibGU7IG15 IHF1YWxtIGhlcmUgaXMgc29sZWx5IGFib3V0IHRoZSBncmFtbWFyIG9mIHRoZSBzZW50ZW5jZS4N Cj4gPiA+IERvZXMgaXQgcHJlc2VydmUgdGhlIGRlc2lyZWQgbWVhbmluZyB0byByZXBsYWNlICJz dWNjZXNzZnVsbHkgcmVjZWl2ZWQiDQo+ID4gPiB3aXRoICJzdWNjZXNzZnVsbHkgYWNrbm93bGVk Z2VkIiAob3IgInN1Y2Nlc3NmdWxseSByZWNlaXZlZCBhbmQNCj4gPiA+IGFja25vd2xlZGdlZCIp Pw0KPiA+DQo+ID4gSSB3b3VsZCBsb3ZlIHRvIGhhdmUgaGFkIGFja25vd2xlZGdlZC4gIEhvd2V2 ZXIgSSBoYXZlIGhlYXJkIGZyb20NCj4gaW1wbGVtZW50ZXJzIHRoYXQgTkVUQ09ORiBpcyBub3Qg YXMgcm9idXN0IGluIHRoaXMgd2F5IGFzIEhUVFAuICBBbmQNCj4gYWNrbm93bGVkZ2VkIG1pZ2h0 IGltcGx5IHRoaW5ncyB0byBkZXZlbG9wZXJzIHRoZXkgbWlnaHQgbm90IGJlIGFibGUgdG8NCj4g ZGVsaXZlci4NCj4gPg0KPiA+ID4gPiA+ICAgICAgICAgICAgICBjb25maWcgZmFsc2U7DQo+ID4g PiA+ID4gICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KPiA+ID4gPiA+ICAgICAgICAgICAg ICBkZXNjcmlwdGlvbg0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgICJTcGVjaWZpZXMgdGhlIHN0 YXRlIG9mIGEgc3Vic2NyaXB0aW9uIGZyb20gdGhlDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAg cGVyc3BlY3RpdmUgb2YgYSBwYXJ0aWN1bGFyIHJlY2VpdmVyLiAgV2l0aCB0aGlzIGluZm8gaXQN Cj4gPiA+ID4gPiAgICAgICAgICAgICAgICBpcyBwb3NzaWJsZSB0byBkZXRlcm1pbmUgd2hldGhl ciBhIHN1YnNjcmliZXIgaXMNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICBjdXJyZW50bHkgZ2Vu ZXJhdGluZyBub3RpZmljYXRpb24gbWVzc2FnZXMgaW50ZW5kZWQgZm9yDQo+ID4gPiA+ID4gICAg ICAgICAgICAgICAgdGhhdCByZWNlaXZlci4iOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gbml0OiBp cyBpdCB0aGUgc3Vic2NyaWJlciB0aGF0IGlzIGdlbmVyYXRpbmcgbWVzc2FnZXMgb3IgdGhlIHB1 Ymxpc2hlcj8NCj4gPiA+ID4NCj4gPiA+ID4gR29vZCBjYXRjaC4gIENoYW5nZWQgdG8gcHVibGlz aGVyLg0KPiA+ID4gPg0KPiA+ID4gPiA+IFNlY3Rpb24gNS4zDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiAgICBBIHNlY3VyZSB0cmFuc3BvcnQgaXMgaGlnaGx5IHJlY29tbWVuZGVkIGFuZCB0aGUgcHVi bGlzaGVyIE1VU1QNCj4gPiA+ID4gPiAgICBlbnN1cmUgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIHN1 ZmZpY2llbnQgYXV0aG9yaXphdGlvbiB0byBwZXJmb3JtIHRoZQ0KPiA+ID4gPiA+ICAgIGZ1bmN0 aW9uIHRoZXkgYXJlIHJlcXVlc3RpbmcgYWdhaW5zdCB0aGUgc3BlY2lmaWMgc3Vic2V0IG9mIGNv bnRlbnQNCj4gPiA+ID4gPiAgICBpbnZvbHZlZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICJzZWN1 cmUgdHJhbnNwb3J0IiB1c3VhbGx5IG1lYW5zIHRoYXQgaXQgcHJvdmlkZXMgbWVzc2FnZQ0KPiA+ ID4gPiA+IGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5IHByb3RlY3Rpb24sIGFuZCBzb3VyY2Ug YXV0aGVudGljaXR5DQo+ID4gPiA+ID4gKGFraW4gdG8gdGhlDQo+ID4gPiBtdXR1YWwgYXV0aGVu dGljYXRpb24pLg0KPiA+ID4gPiA+IFRoaXMgaXMgcXVhbGl0YXRpdmVseSBkaWZmZXJlbnQgZnJv bSBpbXBsZW1lbnRpbmcgYXV0aG9yaXphdGlvbg0KPiA+ID4gPiA+IGNoZWNrcywgYW5kIGl0J3Mg c3VycHJpc2luZyB0byBzZWUgdGhlbSBzcXVhc2hlZCBpbnRvIHRoZSBzYW1lIHNlbnRlbmNlLg0K PiA+ID4gPg0KPiA+ID4gPiBUd2Vha2VkIHRvICJBIHNlY3VyZSB0cmFuc3BvcnQgaXMgaGlnaGx5 IHJlY29tbWVuZGVkLiAgQmV5b25kDQo+ID4gPiA+IHRoaXMsIHRoZQ0KPiA+ID4gcHVibGlzaGVy IE1VU1QiLg0KPiA+ID4gPg0KPiA+ID4gPiA+IERvIHdlIHdhbnQgdG8gc2F5IGFueXRoaW5nIGFi b3V0IGRpc2NvdmVyeSBmb3Igc3VwcG9ydCBvZiBuZXcNCj4gPiA+ID4gPiB0cmFuc3BvcnRzLCBh bmQgd2hhdCB3b3JrZmxvdyB3b3VsZCBiZSB1c2VkIHRvIG5lZ290aWF0ZSB0aGUgdXNlDQo+ID4g PiA+ID4gb2YgYSBuZXcNCj4gPiA+IHRyYW5zcG9ydD8NCj4gPiA+ID4NCj4gPiA+ID4gTm90IGF0 IHRoaXMgcG9pbnQuDQo+ID4gPg0KPiA+ID4gT2theS4NCj4gPiA+DQo+ID4gPiA+ID4gU2VjdGlv biA1LjQNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgY2FuIHRoaW5rIG9mIGEgY291cGxlIG90aGVy IGNvbnNpZGVyYXRpb25zIHRvIG1lbnRpb24gaGVyZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC0g VXNpbmcgRE5TIG5hbWVzIGZvciByZWNlaXZlciAibmFtZSIgbG9va3VwIGNhbiBjYXVzZSBzaXR1 YXRpb25zDQo+IHdoZXJlDQo+ID4gPiA+ID4gICB0aGUgbmFtZSByZXNvbHZlcyBkaWZmZXJlbnRs eSBvbiB0aGUgcHVibGlzaGVyIGFuZCBzdWJzY3JpYmVyLCBzbyB0aGUNCj4gPiA+ID4gPiAgIHJl Y2lwaWVudCB3b3VsZCBiZSBkaWZmZXJlbnQgdGhhbiBleHBlY3RlZC4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IC0gVXNpbmcgdGhlIHB1Ymxpc2hlcidzIGJvb3QgdGltZSBmb3IgZGVkdXBsaWNhdGlv biBwcm90ZWN0aW9uIG9uDQo+ID4gPiA+ID4gICByZXBsYXllZCBtZXNzYWdlcyBpbnRyb2R1Y2Vz IGEgZGVwZW5kZW5jeSBvbiBhY2N1cmF0ZSB0aW1lLiAgV2UNCj4gZG9uJ3QNCj4gPiA+ID4gPiAg IGhhdmUgYSBncmVhdCBzZWN1cmUgdGltZSBzdG9yeSBhdCBwcmVzZW50LCBzbyB0aGlzIGlzIG1v cmUgb2YgYQ0KPiA+ID4gPiA+ICAgImJld2FyZSBvZiByaXNrIiBzaXR1YXRpb24gdGhhbiBzb21l dGhpbmcgd2UgY2FuIG1pdGlnYXRlLCBidXQgaXQgZG9lcw0KPiA+ID4gPiA+ICAgc2VlbSB0aGF0 IGFuIGF0dGFja2VyIHRoYXQgY291bGQgKGUuZy4pIHNwb29mIHRoZSBOVFAgdHJhZmZpYyB0byB0 aGUNCj4gPiA+ID4gPiAgIHB1Ymxpc2hlciBvbiBib290IGNvdWxkIGNhdXNlIGl0IHRvIHNlbmQg ZHVwbGljYXRlIG5vdGlmaWNhdGlvbnMgdG8NCj4gPiA+ID4gPiAgIHJlY2lwaWVudHMgdGhhdCBy ZXF1ZXN0ZWQgaGlzdG9yaWNhbCBkYXRhLg0KPiA+ID4gPg0KPiA+ID4gPiBJIHR3ZWFrZWQgYW5k IGluc2VydGVkIHRoZSB0d28gcGFyYWdyYXBocyBmcm9tIHlvdS4uLg0KPiA+ID4gPg0KPiA+ID4g PiAiVXNpbmcgRE5TIG5hbWVzIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiByZWNlaXZlciAi bmFtZSINCj4gPiA+ID4gbG9va3VwIGNhbg0KPiA+ID4gY2F1c2Ugc2l0dWF0aW9ucyB3aGVyZSB0 aGUgbmFtZSByZXNvbHZlcyB1bmV4cGVjdGVkbHkgZGlmZmVyZW50bHkgb24NCj4gPiA+IHRoZSBw dWJsaXNoZXIsIHNvIHRoZSByZWNpcGllbnQgd291bGQgYmUgZGlmZmVyZW50IHRoYW4gZXhwZWN0 ZWQuIg0KPiA+ID4gPg0KPiA+ID4gPiAiVXNpbmcgdGhlIHB1Ymxpc2hlcidzIGJvb3QgdGltZSBm b3IgZGVkdXBsaWNhdGlvbiBwcm90ZWN0aW9uIG9uDQo+ID4gPiA+IHJlcGxheWVkDQo+ID4gPiBt ZXNzYWdlcyBpbnRyb2R1Y2VzIGEgZGVwZW5kZW5jeSBvbiBhY2N1cmF0ZSB0aW1lLiINCj4gPiA+ DQo+ID4gPiBDYW4gd2UgYWxzbyBzYXkgc29tZXRoaW5nIGxpa2UgIkFuIGF0dGFja2VyIHRoYXQg Y2FuIGNhdXNlIHRoZQ0KPiA+ID4gcHVibGlzaGVyIHRvIHVzZSBhbiBpbmNvcnJlY3QgdGltZSBj YW4gaW5kdWNlIG1lc3NhZ2UgcmVwbGF5IGJ5DQo+ID4gPiBzZXR0aW5nIHRoZSB0aW1lIGluIHRo ZSBwYXN0LCBhbmQgaW50cm9kdWNlIGEgcmlzayBvZiBtZXNzYWdlIGxvc3MgYnkgc2V0dGluZw0K PiB0aGUgdGltZSBpbiB0aGUgZnV0dXJlIj8NCj4gPg0KPiA+IFRleHQgeW91IHN1Z2dlc3QgYWJv dmUgaGFzIGJlZW4gaW5zZXJ0ZWQgaW5zdGVhZCBvZiAiIFVzaW5nIHRoZSBwdWJsaXNoZXIncw0K PiBib290IHRpbWUgZm9yIGRlZHVwbGljYXRpb24gcHJvdGVjdGlvbi4uLiIuDQo+ID4NCj4gPiA+ ID4NCj4gPiA+ID4gPiBTb21lIG90aGVyIGNvbW1lbnRzIG9uIHdoYXQncyBhbHJlYWR5IHRoZXJl ICh3aGljaCBpcyBwcmV0dHkNCj4gPiA+ID4gPiBnb29kOyB0aGFua3MgZm9yDQo+ID4gPiA+ID4g aXQhKSBmb2xsb3cuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICBDb250YWluZXI6ICIvZmlsdGVy cyINCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIG8gICJzdHJlYW0tc3VidHJlZS1maWx0ZXIiOiB1 cGRhdGluZyBhIGZpbHRlciBjb3VsZCBpbmNyZWFzZSB0aGUNCj4gPiA+ID4gPiAgICAgICBjb21w dXRhdGlvbmFsIGNvbXBsZXhpdHkgb2YgYWxsIHJlZmVyZW5jaW5nIHN1YnNjcmlwdGlvbnMuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiAgICBvICAic3RyZWFtLXhwYXRoLWZpbHRlciI6IHVwZGF0aW5n IGEgZmlsdGVyIGNvdWxkIGluY3JlYXNlIHRoZQ0KPiA+ID4gPiA+ICAgICAgIGNvbXB1dGF0aW9u YWwgY29tcGxleGl0eSBvZiBhbGwgcmVmZXJlbmNpbmcgc3Vic2NyaXB0aW9ucy4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IERvIHdlIHdhbnQgdG8gc2F5IGFueXRoaW5nIGFib3V0IG1vZGlmeWluZyBl aXRoZXIgb2YgdGhlc2UNCj4gPiA+ID4gPiBjYXVzaW5nIHRoZSBzZXQgb2Ygbm90aWZpY2F0aW9u cyBkZWxpdmVyZWQgdG8gcmVjaXBpZW50cyB0bw0KPiA+ID4gPiA+IHNocmluayAob3IgYmVjb21l DQo+ID4gPiB1bm1hbmFnZWFibHkgbGFyZ2UpPw0KPiA+ID4gPiA+IEkgZ3Vlc3MgaXQgbWF5IG5v dCBiZSBuZWNlc3NhcnksIHNpbmNlIHRoZSByZWNpcGllbnQgZ2V0cyBhDQo+ID4gPiA+ID4gbm90 aWZpY2F0aW9uIGFib3V0IHRoZSBtb2RpZmljYXRpb24gdGhhdCBpbmNsdWRlcyB0aGUgZGV0YWls cyBvZiB0aGUgZmlsdGVyLg0KPiA+ID4gPg0KPiA+ID4gPiBZZXMsIHRoYXQgd2FzIHRoZSB0aGlu a2luZy4NCj4gPiA+ID4NCj4gPiA+ID4gPiAgICBDb250YWluZXI6ICIvc3Vic2NyaXB0aW9ucyIN Cj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIG8gICJleGNsdWRlZC1ldmVudC1yZWNvcmRzIjogbGVh ZiBjYW4gcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dA0KPiA+ID4gPiA+ICAgICAgIGZpbHRlcmVk IGV2ZW50IHJlY29yZHMuICBBIG5ldHdvcmsgb3BlcmF0b3Igc2hvdWxkIGhhdmUNCj4gPiA+ID4g PiAgICAgICBwZXJtaXNzaW9ucyB0byBrbm93IGFib3V0IHN1Y2ggZmlsdGVyaW5nLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gVG8gYmUgY2xlYXIsIHRoaXMgaXMgZXZlbnQgcmVjb3JkcyBmaWx0ZXJl ZCBlaXRoZXIgdmlhIGV4cGxpY2l0DQo+ID4gPiA+ID4gZmlsdGVyIG9yIHZpYSBhY2Nlc3MgY29u dHJvbCByZXN0cmljdGlvbnMuDQo+ID4gPiA+DQo+ID4gPiA+IFllcy4NCj4gPiA+DQo+ID4gPiBJ IHRoaW5rIHRoYXQgdGhlIHNlbWFudGljIGRpZmZlcmVuY2UgaXMgd29ydGggbm90aW5nLg0KPiA+ ID4NCj4gPiA+ID4gPiBTcGVjaWZpY2FsbHksIGl0IGNhbiBhbGxvdyBhIHJlY2VpdmVyIHRvIGxl YXJuIHRoYXQgdGhlcmUgZXhpc3RzDQo+ID4gPiA+ID4gYWNjZXNzIGNvbnRyb2xzIHRoYXQgZGVu eSBpdCBhY2Nlc3MgdG8gc29tZSBkYXRhLCBpbiB0aGUgY2FzZQ0KPiA+ID4gPiA+IHdoZW4gdGhl eSBkaWQgbm90IGFwcGx5IGFueSBmaWx0ZXJpbmcgcnVsZXMgZXhwbGljaXRseS4NCj4gPiA+ID4N Cj4gPiA+ID4gWWVzLg0KPiA+ID4gPg0KPiA+ID4gPiA+VGhpcyBwb3RlbnRpYWwgZm9yIGluZm9y bWF0aW9uIGxlYWthZ2UgKG9mIHRoZSAgZXhpc3RlbmNlIG9mDQo+ID4gPiA+ID4gQUNMcykgc2hv dWxkIGJlIG1lbnRpb25lZCBleHBsaWNpdGx5Lg0KPiA+ID4gPg0KPiA+ID4gPiBBZGRlZCB0aGUg c2VudGVuY2U6ICJJbXByb3BlciBjb25maWd1cmF0aW9uIGNvdWxkIHByb3ZpZGUgYQ0KPiA+ID4g PiByZWNlaXZlciB3aXRoDQo+ID4gPiBpbmZvcm1hdGlvbiBsZWFrYWdlIGNvbnNpc3Rpbmcgb2Yg dGhlIGRyb3BwaW5nIG9mIGV2ZW50IHJlY29yZHMuIg0KPiA+ID4NCj4gPiA+IENhbiBJIGNvdW50 ZXItcHJvcG9zZTogIkltcHJvcGVyIGNvbmZpZ3VyYXRpb24gY291bGQgYWxsb3cgYQ0KPiA+ID4g cmVjZWl2ZXIgdG8gbGVhcm4gdGhhdCBldmVudCByZWNvcmRzIHdlcmUgZHJvcHBlZCBkdWUgdG8g YW4gQUNMIHdoZW4NCj4gPiA+IHRoZSBleGlzdGVuY2Ugb2YgdGhhdCBBQ0wgd291bGQgb3RoZXJ3 aXNlIGJlIHRyYW5zcGFyZW50LiINCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gQXBwZW5kaXgg QQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBleGFtcGxlIHRyYW5zcG9ydCBtb2R1bGUgZG9l cyBub3Qgc3BlY2lmeSB0aGUgbGlmZSBjeWNsZSBvZg0KPiA+ID4gPiA+IGR5bmFtaWMgc3Vic2Ny aXB0aW9ucyBwZXIgU2VjdGlvbiAxLjMsIGFuZCBhIGNvdXBsZSBvdGhlciB0aGluZ3MNCj4gPiA+ ID4gPiByZXF1aXJlZCBmcm9tIGEgdHJhbnNwb3J0IG1vZHVsZSBzcGVjaWZpY2F0aW9uLiAgUGVy aGFwcyB3ZSBhcmUNCj4gPiA+ID4gPiBva2F5IGNsYWltaW5nIHRoYXQgc2luY2UgdGhpcyBpcyBq dXN0IGFuIGV4YW1wbGUgWUFORyBtb2RlbCBhbmQNCj4gPiA+ID4gPiBub3QgYSBmdWxsIHRyYW5z cG9ydCBleGFtcGxlLCB0aGUgb21pc3Npb24gaXMgb2theSwgYnV0IGl0IG1heQ0KPiA+ID4gPiA+ IGJlIHdvcnRoIG1lbnRpb25pbmcNCj4gPiA+IHRoZSBvbWlzc2lvbiBmb3IgY2xhcml0eS4NCj4g PiA+ID4NCj4gPiA+ID4gSSBhZGRlZCBhcyB0aGUgc2Vjb25kIHNlbnRlbmNlDQo+ID4gPiA+ICIg VGhpcyBleGFtcGxlIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBhIGNvbXBsZXRlIHRyYW5zcG9ydCBt b2RlbC4iDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldywgaXQg d2FzIGV4Y2VsbGVudGx5IGRvbmUuDQo+ID4gPg0KPiA+ID4gQW5kIHRoYW5rcyBmb3IgdGhlIGNs ZWFyIGV4cGxhbmF0aW9ucyBvZiB0aGUgcGFydHMgdGhhdCBJIGRpZG4ndA0KPiA+ID4gdW5kZXJz dGFuZCwgaXQgd2FzIHZlcnkgaGVscGZ1bCB0byBtZS4NCj4gPg0KPiA+IE5vIHByb2JsZW0uICBU aGlzIHRocmVhZCBoYXMgYmVlbiBnb29kIGZvciBtZSB0b28uICBJIHdpbGwgcG9zdCB2MjUgYXMg c29vbiBhcw0KPiB5b3UgZ2l2ZSB0aGUgb2suDQo+IA0KPiBQbGVhc2UgZ28gYWhlYWQgYW5kIHBv c3QgdjI1Lg0KDQpQb3N0ZWQNCg0KLUVyaWMNCg0KPiBUaGFua3MsDQo+IA0KPiBCZW4NCg== From nobody Wed May 1 11:06:13 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A3E120130 for ; Wed, 1 May 2019 11:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L_R7bRrArjmJ for ; Wed, 1 May 2019 11:05:58 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD59120152 for ; Wed, 1 May 2019 11:05:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3B80F7B7; Wed, 1 May 2019 20:05:56 +0200 (CEST) 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 tI2W7Y3kxwOu; Wed, 1 May 2019 20:05:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 May 2019 20:05:56 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED8F7200E0; Wed, 1 May 2019 20:05:55 +0200 (CEST) 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 PR125wnrEGIL; Wed, 1 May 2019 20:05:55 +0200 (CEST) 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 6A1A7200DE; Wed, 1 May 2019 20:05:55 +0200 (CEST) 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.1713.5; Wed, 1 May 2019 20:05:54 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 19CFC3008B86B6; Wed, 1 May 2019 20:05:53 +0200 (CEST) Date: Wed, 1 May 2019 20:05:53 +0200 From: Juergen Schoenwaelder To: Andy Bierman CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" Message-ID: <20190501180553.3oidb7x275tgcdz6@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "Rob Wilton (rwilton)" , "netconf@ietf.org" References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 18:06:00 -0000 On Wed, May 01, 2019 at 09:19:38AM -0700, Andy Bierman wrote: > > This seems to be a good test for whether NMDA is useful as designed. > It seems obvious that something has to be stored in and > then transformed as it is applied to . > The issue here seems to be that you create a resource that you would like to be partially accessible as config and partially not accessible at all or only as applied config in operational state. The question is how to model that, i.e., the binding between config part and the internal state part. Do we have any other similar resources or is this really a very special case? We discussed the 'create user account' case where often users ids are allocated as a side effect of creating an account but the allocated ids then becomes regular config, i.e., the config can be copied and restored as one would expect. This is not really the same case that we have with locally created keys. An alternative might be to consider a locally generated key entirely operational state (applied config): You invoke an RPC to create a key and you give it a name and then it exists as named operational state (applied config) until you delete that named operational state. If you want to configure a transport that refers to such a key, you do this via a name binding, pretty much in the way we apply interface configuration to an interface with a matching name. Perhaps this is a model that could work. Perhaps Martin has even better ideas. /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 May 1 11:07:32 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEBE120108; Wed, 1 May 2019 11:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155673405097.987.17906173989722694221.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 11:07:30 -0700 Archived-At: Subject: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-subscribed-notifications-25: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 18:07:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 1.3 = "Also note that transport specific transport drafts based on this specification MUST detail the life cycle of dynamic subscriptions, as well as the lifecycle of configured subscriptions (if supported)." I think this would be clearer if it said "transport-specific documents." = Section 2.5 = Please expand VRF on first use. From nobody Wed May 1 11:20:27 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB31C120072; Wed, 1 May 2019 11:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=OgWEhiqm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Npg2vQou Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiBWo9JKNFAU; Wed, 1 May 2019 11:20:11 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC7E120136; Wed, 1 May 2019 11:20:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C581022540; Wed, 1 May 2019 14:20:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 01 May 2019 14:20:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=V LHprhnY5JK7x+HFKxjImARh387isesWPqfw5136dPE=; b=OgWEhiqmMhLOneOEg dd/G2w4sDjEBELfDUiFCjx/4/9Cdae6DuxBxVaPMhWBVSrNVrSZJXhA9i6Nhb99k TLuvm6KcAr46zwrLtMqLbeoS4t5vEI0QOvNP4DF3Ez0FUTD6VcKLLMK3J9xjxrqm 2COnwQmghp096n/YUldHD6y5fHCm+0LM/srMVVuyWcrfveARp4Xo6QECLOGrZ920 iXc1N5CjB5WiqN+Qkw7gK/tq9IaGM6RFbOWdLCyzIqc8oI+lpFYzrFgZbQIu8JVR o+ldBJ/+AuMRl84DhmpCEDiY5sARg7LYVpQwab5+63xW/Xjvw3BSj5DRcRMhKkWU cdKNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=VLHprhnY5JK7x+HFKxjImARh387isesWPqfw5136d PE=; b=Npg2vQouM0Bq56+zKCcC+qU1KNBlB76TtprIWOJmhwa3IVM1KwVXJnbRb VF118LcJAB0RDGhmXa82XoUnJvyXjJUKCnXYrOHs0jT8fPeEwGgWxQDsDtziFZTa T+hjuN9LTV8E6HJ/xHYUj5+CI2vJ/Wpc8hlcN97HlsDq4fGkQv/NrXf3TTL848bB lKAmW22FRxw5/ZfVw+ydGhtQoOLOZCMX4DxDlL3SvnIH6viprmdBcslQbxqmYXWj kqNpme1RdKwMHiZKMJC075kaady5WgPxYgty0esxfg9xebtvQSW4Qzmg6B3+Aovg IOJp8jre5b1sucleOXDZhzp0Hn6lg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieejgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrleegnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.94]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AA29E4067; Wed, 1 May 2019 14:20:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <10b201d4fad0$f9c70ba0$ed5522e0$@clemm.org> Date: Wed, 1 May 2019 14:20:05 -0400 Cc: General Area Review Team , draft-ietf-netconf-yang-push.all@ietf.org, "" , netconf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5B79DAF8-4B46-4B70-BFEF-4BCA4CB04FDE@cooperw.in> References: <155492884208.22557.5359832641233656648@ietfa.amsl.com> <10b201d4fad0$f9c70ba0$ed5522e0$@clemm.org> To: Alexander Clemm , Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] [Gen-art] Genart last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 18:20:14 -0000 Stewart, thanks for your review. Alex, thanks for your responses, they = all make sense to me. I have entered a No Objection ballot. Alissa > On Apr 24, 2019, at 3:07 PM, Alexander Clemm wrote: >=20 > Hi Stewart, >=20 > Thank you for your comments! Please find replies inline, >=20 > --- Alex >=20 > -----Original Message----- > From: netconf On Behalf Of Stewart Bryant = via > Datatracker > Sent: Wednesday, April 10, 2019 1:41 PM > To: gen-art@ietf.org > Cc: draft-ietf-netconf-yang-push.all@ietf.org; ietf@ietf.org; > netconf@ietf.org > Subject: [netconf] Genart last call review of > draft-ietf-netconf-yang-push-22 >=20 > Reviewer: Stewart Bryant > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG = for > the IETF Chair. Please treat these comments just like any other last = call > comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-netconf-yang-push-22 > Reviewer: Stewart Bryant > Review Date: 2019-04-10 > IETF LC End Date: 2019-04-12 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: A well written document with just a small nuber of minor = matter in > the nits section that need to be considered. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 > ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > We will update the reference. > >=20 > SB> I assume that the ADs are happy with seven front page authors. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Abstract >=20 > Via the mechanism described in this document, subscriber = applications > SB> I am not sure if starting a sentence with "via" is good English = but=20 > SB> I have not seen it done before. >=20 > we think "via" is fine; if you prefer it to say "using", please = let > us know and we will change it. =20 > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Traditional approaches to providing visibility into managed entities > from remote have been built on polling. > SB> from remote what? >=20 > from a remote system, a remote application, a remote location. =20= > I do think this is clear; if you prefer it to say "from a remote = system" we > will change; please let us know if you would prefer to make that = change. =20 > >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 3.10. On-Change Notifiable Datastore Nodes >=20 > In some cases, a publisher supporting on-change notifications may = not > be able to push on-change updates for some object types. Reasons = for > this might be that the value of the datastore node changes = frequently > (e.g., [RFC8343]'s in-octets counter), that small object changes are > frequent and meaningless (e.g., a temperature gauge changing 0.1 > degrees), or that the implementation is not capable of on-change > notification for a particular object. >=20 > SB> I could not see the parameter range specifiy what is regarded as=20= > SB> trivial specified in the model. It seems that it perhaps ought to = be. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This will depend heavily on the object and its intended use. > Basically we are giving only reasons why an implementation might = choose to > not support on-change notifications for a particular object. Going = deeper > into reasoning behind such implementation choices, what size would be > "small" or "large", and over what time interval, etc, would IMHO go = beyond > the scope of this document. We prefer not to make a change to the = document. > (Please note that there is another draft on smart filters for push = updates, > which might in the future add the ability for users to e.g. configure = this > and other things.) > >=20 > The next figure depicts augmentations of module ietf-yang-push to = the > notifications that are specified in module ietf-subscribed- > notifications. The augmentations allow to include subscription > SB> s/allow to include/allow the inclusion of/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > We will make this change. > >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 1 11:55:03 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18012008D; Wed, 1 May 2019 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 FGWfdLu12vy6; Wed, 1 May 2019 11:55:00 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 17F88120021; Wed, 1 May 2019 11:54:59 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id x15so8560622pln.9; Wed, 01 May 2019 11:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=RlXnca01+Nw8qZwp1Gio8Luahnr9NcYZvBNsG8MVF58=; b=U8eG+p2IpZL6PEPS36L+y6ihTYVKsqFo3Q9MkkB4D/A/fBgRK3t8hKbMx0/f77y4Pf DWHCrb3lwrHPX+F9Jp7kdijvMiXQS5PMG5JL3Gb0vxn+VnLPytMO7xmWlNo+0yRa8qbr RBipSvTN/YZoUPswkAgodby9v93Quzg7iA9nh1kW3Xy2L9Mz6gensBGF+M8+V0qOMELH yYcF47WFnTm3or86NIuSVcul75NJMGDlT/AvnuC6ZvYvWjqRfnkWHflW+m+gPg8CYkMI qAiWYJxOJHHK0MDp9Ex/Zh4FvKSC/6IvWTQJBkFkBKyUwNy76QLg656EIYamylDRY9VS RuLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=RlXnca01+Nw8qZwp1Gio8Luahnr9NcYZvBNsG8MVF58=; b=TxWJ549FeSOk9J2xkuHEDuyTp5wdrqUXB2MKpbdqBcF2kvjJlLWCL4wFcFxIQr9qey 2zBR5wIANsx6XGlpokGOjsTq92eqVl+9vtqQ61K4z4RxI71/dVfuRm69iW8PtDbocBDK zUHcD+hfTYHVlndmuzrUo6yMh0KeeaWTqhF9hw/7FYO8qA3nfkKJAMz1ScjSZ8bD5GzT HB2PT+44loVUwKxQewaJIe4iAZEHSjFs20gVw7CfBFqs55twwje5okdcZON8fniN74/7 Tja/Z7l4Oe6EhtRaRGoa1cecwv+nbjMxm8rXWz3zuyAHJURlR99MikE8JX7UgKJMeYxZ jiXw== X-Gm-Message-State: APjAAAWdNEFoiLHL9wuLU5RZN7TftcXztyjm75xUPLT4HZa8CPPzlSc1 lMxjFL8ISqVIHQu1bsB8NqtsNnbQSO0= X-Google-Smtp-Source: APXvYqz0iFbRuvuOTcMId0lljXtnygaG4NMMSmqm45DR2WoofSaXrTS5A0B9Ra5ZIuJ8GNM81RU+jg== X-Received: by 2002:a17:902:7b8f:: with SMTP id w15mr28456113pll.314.1556736899155; Wed, 01 May 2019 11:54:59 -0700 (PDT) Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id z127sm21107472pfb.53.2019.05.01.11.54.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 11:54:57 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <0A966DA9-7CF7-4288-B636-70EABC184742@gmail.com> Date: Wed, 1 May 2019 11:54:56 -0700 Cc: tcpm@ietf.org To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netconf] Re-issue of adoption poll for draft-kwatsen-netconf-tcp-client-server-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 18:55:02 -0000 As noted in the mail yesterday to the NETCONF WG, I am issuing a new = poll on draft-kwatsen-netconf-tcp-client-server draft that was discussed = in 104. There were comments that were received on the -00 draft that was = presented in 104, that have been addressed in the -02 version of the = draft. Since the original poll was on the -00 version of the draft, we = (the chairs), felt the need to re-issue the poll. Also, that poll = included the HTTP client/server draft, which is still under discussion, = and as such has been removed from this poll. The TCP client/server draft did get support in 103, so rather than = asking for a repeat of that show of support, I am asking if there is any = objection to the adoption of this draft. If you do have an objection, = please state your reasons for why you feel this work should not be done. The poll will run for two weeks, till May 15, and if no objections are = received by then, the draft will be adopted as a WG item. Cheers. Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed May 1 12:02:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286E812015E; Wed, 1 May 2019 12:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQB4-ebQvyvq; Wed, 1 May 2019 12:02:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445CE120130; Wed, 1 May 2019 12:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1083; q=dns/txt; s=iport; t=1556737366; x=1557946966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Lpvz2aOIBt/WNCSzCs1YDb/21q4KKlbBrt4jzeVUSCg=; b=PzPvoJRMafOtbISeQxmY/+uJ6NSI7aRTKmJg8Q5yKDL6e1xu/4qzTwHL 1VKBqRJS5d1ciGQnb1DaB8spslFZeQylrq0X0vKu6gddtj4xngkhF1+p2 LbSu1/L/Q8C+XmrCayJgF2AjgGvxryvbmwYc7gl0Iy6bBiWUlHKx/I3Hv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABn7Mlc/5xdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCEGmBBCgKjCKNE5hQgXsOAQEYC4QERgKGMiM?= =?us-ascii?q?0CQ4BAwEBBAEBAgECbRwMhUoBAQEBAgEBAWwJAgULAgEIFSYLJwslAgQBDQU?= =?us-ascii?q?IEYMKgXsPD69Dii4GgTIBi0sXgUA/gRGDEj6CYQEBh0MEiwuHcpQWCQKCCZI?= =?us-ascii?q?3I4INhjeMcYwRlFwCERWBMB84gVZwFTuCbIIbFxSITIU/QTGSU4EhAQE?= X-IronPort-AV: E=Sophos;i="5.60,418,1549929600"; d="scan'208";a="551936397" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 19:02:45 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x41J2iwl019266 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 19:02:45 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 15:02:44 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 1 May 2019 15:02:44 -0400 From: "Eric Voit (evoit)" To: Alissa Cooper , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-subscribed-notifications-25: (with COMMENT) Thread-Index: AQHVAEjHhZpNMHHKrEWYa9B8KX+8naZWnWmA Date: Wed, 1 May 2019 19:02:44 +0000 Message-ID: References: <155673405097.987.17906173989722694221.idtracker@ietfa.amsl.com> In-Reply-To: <155673405097.987.17906173989722694221.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-subscribed-notifications-25: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 19:02:48 -0000 Hi Alissa, Thanks for the review. Some thoughts in-line... > From: Alissa Cooper , Wednesday, May 1, 2019 2:08 PM >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-netconf-subscribed-notifications-25: No Objection >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 1.3 =3D >=20 > "Also note that transport specific transport drafts based on this > specification MUST detail the life cycle of dynamic subscriptions, as > well as the lifecycle of configured subscriptions (if supported)." >=20 > I think this would be clearer if it said "transport-specific documents." =C9ric Vyncke caught this one too. Let's go with "transport specific speci= fications". > =3D Section 2.5 =3D >=20 > Please expand VRF on first use. Done. =20 Eric > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed May 1 12:08:32 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 133D112008D; Wed, 1 May 2019 12:08:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netconf-yang-push@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 12:08:24 -0700 Archived-At: Subject: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 19:08:24 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netconf-yang-push-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Note that I reviewed the -22 and the current version is -23. Briefly skimming the diff, it seems that some changes touch on points I make in my review, but there is probably still discussion to have on them. (pro-forma) I see the GenArt reviewer noted the author count (seven) already, but I couldn't find a response or note in the ballot or shephert writeup acknowledging this. So failing that, I'll put up a discuss point until the responsible AD says it's fine. [See also discussion on draft-ietf-netconf-subscribed notifications about the pre-RFC5378 boilerplate and whether or not it can be removed from this document] Section 3.3 states: In order for a subscriber to determine whether objects support on-change subscriptions, objects are marked accordingly on a publisher. Accordingly, when subscribing, it is the responsibility of the subscriber to ensure it is aware of which objects support on- change and which do not. For more on how objects are so marked, see Section 3.10. Chasing the reference, we see that this marking is left for future work or implementation-specific usage. I'm not very comfortable with the way we are describing this situation, as it seems pretty fragile in the face of different implementations trying to interoperate. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the very thoughtful document! I've lost track of the number of places where I started writing a comment only to note that my concern had already been addressed in the following text. In general the writing style is great, though I did find some grammar and clarity nits (noted inline). Abstract Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. This phrasing ("new capabilities based on") is hard for me to follow, particularly about whether these are protocol-level capabilities and what actors are granted the new capabilities. Section 1 Traditional approaches to providing visibility into managed entities from remote have been built on polling. [...] nit: "remote" is an adjective and needs a noun to bind to; "from remote systems", "from remote vantages", or "from afar" would all be fine wordings here. o Polling incurs significant latency. This latency prohibits many application types. nit: I'd suggest wording as "types of application", since on my first reading I thought this was referring to some sort of codepoint. o Polling cycles may be missed, requests may be delayed or get lost, often when the network is under stress and the need for the data is the greatest. nit: the grammar is a bit weird, here, as if a comma splice. I think replacing the first comma with a colon or em dash would suffice. o Datastore node update: A data item containing the current value of a datastore node at the time the datastore node update was created, as well as the path to the datastore node. Is this storing the "new" or the "old" value as the "current value"? Section 3.1 + Dampening period: In an on-change subscription, detected [...] is included. The dampening period goes into effect every time an update record completes assembly. Just to double-check: this means that after a long hiatus, the first change to the monitored subtree(s) triggers an immediate push with just the single update, and only then does the dampening period kick in and defer delivery of potential subsequent updates? Section 3.5.2 This bit about the "create" and "delete" errors from RFC 8072 Section 2.5 not being errors in our usage is a little interesting, process-wise. In one sense, we are changing the semantics of an already published RFC, and would need to apply an "Updates:" relationship to indicate that, but in the other sense we are building a new custom thing that reuses a lot of the syntax/semantics of YANG patch but is fundamentally a new (different) thing. The phrasing we use to talk about it can affect which case the reader perceives us to be in... The discussion on the "change-type" enumeration seems to pretty clearly place us in the latter case, which is good. Section 3.6 Thank you for the note about the power of XPath expressions and the duty of the receiver to understand what it's asking for -- that sort of statement would potentially even be appropriate in the Security Considerations (but is fine where it is)! Section 3.7 Of note in the above example is the 'patch-id' with a value of '0'. Per [RFC8072], the 'patch-id' is an arbitrary string. With YANG Push, the publisher SHOULD put into the 'patch-id' a counter starting at '0' which increments with every 'push-change-update' generated for a subscription. If used as a counter, this counter MUST be reset to '0' anytime a resynchronization occurs (i.e., with the sending of a 'push-update'). Also if used as a counter, the counter MUST be reset to '0' after passing a maximum value of '4294967295' (i.e. maximum value that can be represented using uint32 data type). Such a mechanism allows easy identification of lost or out-of-sequence update records. It's not really clear to me how much value there is in this counter mechanism if the client' can't rely on the server's behavior actually being to use a counter (the requirement is only "SHOULD"). Can this be a "MUST" (or maybe "MUST excpet when [...]") instead? Section 3.9 Empty "push- change-update" messages (in case of an on-change subscription) MUST NOT be sent. This is required to ensure that clients cannot surreptitiously monitor objects that they do not have access to via carefully crafted selection filters. By the same token, changes to objects that are filtered MUST NOT affect any dampening intervals. I appreciate this attention to security-relevant detail; thank you! Section 3.11.1 Do we want to give any guidance for the "incomplete-update" case about whether a subscriber should wait and give the publisher a chance to provide a full "push-update" for resynchronization (per Section 4.3.2) versus perform a normal query for the datastore contents and effectuating its own resynchronization? Section 4.2 o For on-change subscriptions, assuming any dampening period has completed, triggering occurs whenever a change in the subscribed information is detected. On-change subscriptions have more complex semantics that is guided by its own set of parameters: nit: singular/plural mismatch "semantics"/"is" Section 4.3.2 A "time-of-update" which represents the time an update record snapshot was generated. A receiver MAY assume that at this point in time a publisher's objects have the values that were pushed. nit: I think "had the values" (past tense) is more appropriate. Section 4.4.1 a publisher that cannot serve on-change updates but periodic updates might return the following NETCONF response: nit: "but can serve periodic updates" Section 4.4.2 The specific parameters to be returned in as part of the RPC error response depend on the specific transport that is used to manage the subscription. For NETCONF, those parameters are specified in [I-D.draft-ietf-netconf-netconf-event-notifications]. nit: "in" and "as part of" are redundant. Section 5 It is slightly interesting to note that (apparently) the update-policy-modifiable grouping allows for a subscription to switch between periodic and triggered at runtime (by virtue of wanting a single grouping to cover all the cases and needing to be able to modify the parameters for each case). I would mostly expect implementations to deny such modification requests due to the needed complexity, but I'm also not sure that there's a need to mention this explicitly in the document. leaf period { type centiseconds; mandatory true; description "Duration of time which should occur between periodic push updates, in one hundredths of a second."; It would probably be okay to skip "in one hundredths of a second" given the usage of the centiseconds typedef. rc:yang-data resync-subscription-error { container resync-subscription-error { description "If a 'resync-subscription' RPC fails, the subscription is not resynced and the RPC error response MUST indicate the reason for this failure. This yang-data MAY be inserted as structured data within a subscription's RPC error response to indicate the failure reason."; It's a little weird to have the normative language here constraining the RPC error response that must be returned for a specific RPC, since this is not the description of that RPC. (It's probably also duplicating langauge elsewhere but I didn't double-check.) rc:yang-data establish-subscription-datastore-error-info { container establish-subscription-datastore-error-info { description "If any 'establish-subscription' RPC parameters are unsupportable against the datastore, a subscription is not created and the RPC error response MUST indicate the reason why the subscription failed to be created. This yang-data MAY be inserted as structured data within a subscription's RPC error response to indicate the failure reason. This yang-data MUST be inserted if hints are to be provided back to the subscriber."; (ditto) Contrast to modify-subscription-datastore-error-info, which only has normative language about the yang-data being described and not the RPCs that (might) use it. nit: push-update and push-change-update use different langauge about "does not constitute a general-purpose notification" and I'm not sure there's a reason to diverge. Their "incomplete-update" leaves also have divergent descriptions, but I think that latter divergence is more reasonable. augment "/sn:subscription-modified/sn:target" { [...] case datastore { uses datastore-criteria { refine "selection-filter/within-subscription" { description "Specifies where the selection filter, and where it came from within the subscription and then populated within this notification. If the 'selection-filter-ref' is nit: "where the selection filter" seems like an incomplete clause. From nobody Wed May 1 12:43:34 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D0120223; Wed, 1 May 2019 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Rd8hVd7uDbdi; Wed, 1 May 2019 12:43:31 -0700 (PDT) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7DA120228; Wed, 1 May 2019 12:43:31 -0700 (PDT) Received: by mail-it1-f171.google.com with SMTP id k64so350350itb.5; Wed, 01 May 2019 12:43:31 -0700 (PDT) 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:content-transfer-encoding; bh=PLvlpdUdL5qajVYJ6ZB6R8ozIjJC+39S0dM584rDjPQ=; b=gLkMNAkqMwG2nIAOvfLsLfAWb/3lbHcjiMKcil8I3JAmD/FQxgBFxleBBLSfkZgj9D GwpsOI+dO+BXWXsbd3XIFayKi58Kr3TcdZQ3fDF115i0oniKKbLvZnVTtYomDjBkxC8o VvlygOZ+XJOZgos366RpmyOxyZQTWomqVbhX+RIlJ01Ao25IoIIxrGgQgchlRvzAwZDj rSnhi3jBIo22Bsw2ZeqHk34B+RnrkIrh14YcqGKPHb9oKi6raUziIDDWDsUdF/jYGkga 4GTMIF9qX9jo7YrNbivYx9kOjvzXYJHbRc3GBmGCOSnQHVbgs0HPsKSReLgTIVHxpuMK AI5w== X-Gm-Message-State: APjAAAUEYPozt6pMN2VOAIYH98J3qYpI+Yffge2TJGn6mCK4xTkWEw9h m3q0A8RnCemcGnSVsm3XTjBjF2MZxmc9HLZWUb8P+Q== X-Google-Smtp-Source: APXvYqzOUinnzdQnAcHTaE2P3FUXvhdt/vsakr5lNzvVztHI5dssP8yQNUMFzSiK875zkgui5x2RxQdI5nAVzowrhrw= X-Received: by 2002:a24:fa88:: with SMTP id v130mr9728005ith.122.1556739810337; Wed, 01 May 2019 12:43:30 -0700 (PDT) MIME-Version: 1.0 References: <155673405097.987.17906173989722694221.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Wed, 1 May 2019 15:43:19 -0400 Message-ID: To: "Eric Voit (evoit)" Cc: Alissa Cooper , The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-subscribed-notifications-25: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 19:43:32 -0000 > > I think this would be clearer if it said "transport-specific documents.= " > > =C3=89ric Vyncke caught this one too. Let's go with "transport specific = specifications". But please hyphenate "transport-specific" (it's a compound adjective). Thanks, Barry From nobody Wed May 1 13:15:46 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F1E120094; Wed, 1 May 2019 13:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7_NVrNSSMbN; Wed, 1 May 2019 13:15:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D671200C7; Wed, 1 May 2019 13:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=396; q=dns/txt; s=iport; t=1556741735; x=1557951335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xC/LJWhXm2VvYe+NRShl8BZ7knY9TaVKJrUJyLTKhqQ=; b=UC1CHNP6PL13ziCEJp9OiFD/26SzESGrBFsoxaFziUmjI+yAVO0vliG3 uIdw5rsyjvHwIHw1YIFTYYCePQ4Jelz/ZVdEcWeen7ztW2+Gx8RXE9PUj BFkhwJnzCBGJkM0Ypg5wnwvP4oeLBvJEUUjmC6qBx3uuO21FeRsrzoyQ1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADf/clc/5JdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCEIFtMoQGiByNE5hQgXsOAQGEbQIXhhsjNAk?= =?us-ascii?q?OAQMBAQQBAQIBAm0ohUoBAQEBAgEjEUMCBQsCAQgaAh8HAgICMBUQAgQODYU?= =?us-ascii?q?WD64hgS+KNIELJwGLSxeBQD+EIz6HToJYBI0YLJlPCQKCCZI3I4F9AQ+GN4x?= =?us-ascii?q?xoG0CERWBMB84gVZwFYMoghoXFI4LQZMEgSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,418,1549929600"; d="scan'208";a="265482098" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 May 2019 20:15:34 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x41KFXSq006130 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 May 2019 20:15:34 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 16:15:33 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 1 May 2019 16:15:33 -0400 From: "Eric Voit (evoit)" To: Barry Leiba CC: Alissa Cooper , The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-subscribed-notifications-25: (with COMMENT) Thread-Index: AQHVAEjHhZpNMHHKrEWYa9B8KX+8naZWnWmAgABRVID//8XZQA== Date: Wed, 1 May 2019 20:15:33 +0000 Message-ID: <883f9079a5ab4d4db69dcefe19de3790@XCH-RTP-013.cisco.com> References: <155673405097.987.17906173989722694221.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-subscribed-notifications-25: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 20:15:38 -0000 PiA+ID4gSSB0aGluayB0aGlzIHdvdWxkIGJlIGNsZWFyZXIgaWYgaXQgc2FpZCAidHJhbnNwb3J0 LXNwZWNpZmljIGRvY3VtZW50cy4iDQo+ID4NCj4gPiDDiXJpYyBWeW5ja2UgY2F1Z2h0IHRoaXMg b25lIHRvby4gIExldCdzIGdvIHdpdGggInRyYW5zcG9ydCBzcGVjaWZpYw0KPiBzcGVjaWZpY2F0 aW9ucyIuDQo+IA0KPiBCdXQgcGxlYXNlIGh5cGhlbmF0ZSAidHJhbnNwb3J0LXNwZWNpZmljIiAo aXQncyBhIGNvbXBvdW5kIGFkamVjdGl2ZSkuDQoNCkRvbmUNCg0KPiBUaGFua3MsDQo+IEJhcnJ5 DQo= From nobody Wed May 1 14:06:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED63120094 for ; Wed, 1 May 2019 14:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sr6ldoBvsh7Q for ; Wed, 1 May 2019 14:06:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 886E4120021 for ; Wed, 1 May 2019 14:06:25 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A96D41AE0451; Wed, 1 May 2019 23:06:22 +0200 (CEST) Date: Wed, 01 May 2019 23:06:22 +0200 (CEST) Message-Id: <20190501.230622.158012882760210627.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <20190430161223.cwqfsyyxbtnkqbl7@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 21:06:28 -0000 SGksDQoNCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiB3cm90ZToNCj4gT24gVHVlLCBBcHIgMzAsIDIwMTkgYXQgMDI6NDk6MzBQTSAr MDIwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPiBLZW50IFdhdHNlbiA8a2VudCtpZXRm QHdhdHNlbi5uZXQ+IHdyb3RlOg0KPiA+ID4gDQo+ID4gPiBDb3JyZWN0LCBhcyBJIGRpZG7igJl0 IHRoaW5rIHRoZXJlIHdhcyBjb25zZW5zdXMgeWV0LiAgUGVyaGFwcyB0aGVyZSBpcw0KPiA+ID4g cm91Z2gtY29uc2Vuc3VzLCBhbmQgaXQgbWF5IGJlIHRoYXQgdGhlIG9ubHkgd2F5IHRvIGdhdWdl IHRoYXQgaXMgdG8NCj4gPiA+IHRyeSBhbmQgc2VlIGhvdyBtdWNoIHB1c2ggYmFjayB0aGVyZSBp cy4NCj4gPiA+IA0KPiA+ID4gT2theSwgc28gaG93IGFib3V0IHRoaXMsIGJhc2VkIG9uIHRoaXMg dGhyZWFkLCB0aGVyZSBhcHBlYXJzIHRvIGJlDQo+ID4gPiBzdXBwb3J0IHRvIGFkZCBhIGZsYWcg dG8gY29udHJvbCBpZiBhIGtleSBzaG91bGQgYmUg4oCccGVybWFuZW50bHkNCj4gPiA+IGhpZGRl buKAnSBvciBub3QsIGluIHdoaWNoIGNhc2UgY29uZmlndXJhdGlvbiBpcyBjcmVhdGVkLg0KPiA+ IA0KPiA+IEkgKHN0aWxsKSBvYmplY3QgdG8gdGhpcy4gIEFjdGlvbnMgc2hvdWxkbid0IGNyZWF0 ZSBjb25maWcuICBXZQ0KPiA+IGFscmVhZHkgaGF2ZSBnZW5lcmljIHByb3Rjb2wgb3BlcmF0aW9u cyB0byBkbyB0aGlzLiAgV2UgZ28gZnJvbSBhDQo+ID4gZG9jdW1lbnQtb3JpZW50ZWQgY29uZmln dXJhdGlvbiBtb2RlbCB0b3dhcmRzIGEgY29tbWFuZC1vcmllbnRlZA0KPiA+IG1vZGVsLiAgTm90 IGdvb2QuICBJbiBSRVNUQ09ORiwgdGhlIGdlbmVyaWMgbWV0aG9kcyBzdXBwb3J0IHRoaW5ncw0K PiA+IGxpa2UgRVRhZ3MsIHdoaWNoIEkgc3VzcGVjdCB5b3UgZG9uJ3Qgd2FudCB0byByZXBsaWNh dGUgaW4gdGhpcw0KPiA+IGFjdGlvbj8gICBXaWxsIHRoZSBhY3Rpb24gc3VwcG9ydCBhbGwgZXJy b3Itb3B0aW9ucyBvZiBlZGl0LWNvbmZpZywNCj4gPiBsaWtlIHJvbGxiYWNrLW9uLWVycm9yPw0K PiA+DQo+IA0KPiBNYXJ0aW4sDQo+IA0KPiBkbyB5b3UgaGF2ZSBhbnkgcHJvcG9zYWwgaG93IHRv IHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50IHRvIGdlbmVyYXRlIGENCj4ga2V5IG9uIHRoZSBkZXZp Y2UgdGhhdCBpcyB3b3JrYWJsZSB3aXRoIGEgZG9jdW1lbnQtb3JpZW50ZWQNCj4gY29uZmlndXJh dGlvbiBtb2RlbD8gRG8geW91IHByb3Bvc2UgdGhhdCB0aGUgYWN0aW9uL3JwYyByZXR1cm5zIHRo ZQ0KPiBwdWJsaWMga2V5IGluZm9ybWF0aW9uIGFzIHJlc3VsdCBkYXRhIHRoYXQgdGhlbiBuZWVk cyB0byBiZSB3cml0dGVuDQo+IGJhY2sgdG8gdGhlIHNlcnZlciBhbmQgc29tZWhvdyBtYXRjaGVk IHRvIHRoZSBrZXkgdGhhdCBpcyBjYWNoZWQgb24NCj4gdGhlIGRldmljZT8gUGVyaGFwcyB5b3Ug aGF2ZSBvdGhlciBpZGVhcyBJIGNhbid0IHRoaW5rIG9mPw0KPiANCj4gSSB0aGluayBJIHdvdWxk IGJlIGhhcHB5IHRvIG5vdCBoYXZlIHRoaXMgc3BlY2lhbCBoYWNrIGJ1dCB0aGVuIHdlDQo+IG5l ZWQgYSB3b3JrYWJsZSBhbHRlcm5hdGl2ZS4gS2V5IGdlbmVyYXRpb24gb24gZGV2aWNlcyBpcyBz b21ldGhpbmcNCj4gdGhhdCBpcyBiZWluZyB1c2VkIC0gYW5kIG1heSBiZSBldmVuIG1vcmUgdXNl ZCBpbiB0aGUgZnV0dXJlIHRoZSBtb3JlDQo+IHdlIGdldCBzcGVjaWFsIGhhcmR3YXJlIHN1cHBv cnQgZm9yIHN0b3Jpbmcga2V5cy4NCg0KU28gdGhlIGN1cnJlbnQgZHJhZnQgc3VwcG9ydHMgdHdv IHVzZSBjYXNlczoNCg0KICAxLiAgVGhlIGNsaWVudCBjb25maWd1cmVzIHRoZSBwcml2YXRlIGFu ZCBwdWJsaWMga2V5cyBleHBsaWNpdGx5DQogICAgICAoc2ltcGxlIGNhc2UpLiAgQm90aCBrZXlz IGFyZSBhdmFpbGlibGUgaW4gdGhlIGNvbmZpZyBhbmQNCiAgICAgIG9wZXJhaW9uYWwgc3RhdGUu DQoNCiAgMi4gIFRoZSBjbGllbnQgYXNrcyB0aGUgZGV2aWNlIHRvIGdlbmVyYXRlIGEgImhpZGRl biIga2V5IHdoaWNoIG1heQ0KICAgICAgYmUgYSBrZXkgaW4gc3BlY2lhbCBUUE0gaGFyZHdhcmUu DQoNCkZvciAyLCB0aGUgY2xpZW50IGNvbmZpZ3VyZXMgdGhlIG5hbWUgb2YgdGhlIGtleSAoaW4g PHJ1bm5pbmc+KS4gIFRoZW4NCnRoZSBjbGllbnQgaW52b2tlcyB0aGUgYWN0aW9uIChpbiA8b3Bl cmF0aW9uYWw+KS4gIFRoZSBkZXZpY2UNCmdlbmVyYXRlcyBhIG5ldyBrZXkgcGFpciAocGVyaGFw cyBpbiB0cG0taHcpLiAgSW4gPG9wZXJhdGlvbmFsPiwgdGhlDQpwdWJsaWMga2V5IGlzIG5vdyB2 aXNpYmxlIGFuZCB0aGUgcHJpdmF0ZSBrZXkgaGFzIHRoZSBzcGVjaWFsIGVudW0NCiJwZXJtYW5l bnRseS1oaWRkZW4iLg0KDQpBIGRldmljZSB0aGF0IGRvZXNuJ3QgaGF2ZSBzcGVjaWFsIGhhcmR3 YXJlIGNhbiBzdGlsbCBpbXBsZW1lbnQgMiwgYnV0DQpzdG9yZSB0aGUga2V5cyBpbiB0aGUgZmls ZXN5c3RlbS4gIFBlcmhhcHMgdGhpcyBpbmZvIG5lZWRzIHRvIGJlDQp2aXNpYmxlIGZvciB0aGUg Y2xpZW50LCBvciBldmVuIGNvbnRyb2xsZWQgYnkgdGhlIGNsaWVudC4NCg0KV2hhdCBJIG9iamVj dCB0byBpcyBhIHRoaXJkIHVzZSBjYXNlLCB3aGVyZSB0aGUgYWN0aW9uIHdvdWxkIG1vZGlmeQ0K dGhlIGNvbmZpZyB3aXRoIHRoZSBnZW5lcmF0ZWQga2V5cy4NCg0KDQovbWFydGluDQo= From nobody Wed May 1 15:39:19 2019 Return-Path: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9109120025; Wed, 1 May 2019 15:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trsbGbmu6G_o; Wed, 1 May 2019 15:39:13 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACAD120019; Wed, 1 May 2019 15:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556750352; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=V5KtbbfevQ1KLEhpE4cJ8IG5qHOTzaOnf3eukJTczVA=; b=PmK8qQjAA0n+3GR3HDIYnHennmx2Ky79Li9t0D49zvCFTf2vesOW1eJScyTJNIgs WGmxiPZkwtc4qMp4BX4FgNpJ/39+/aUUovOQ5m5ZAssCUEuMncIZodLzezORPBQORr0 WYWnD8OACBkanmzTPYf0p6PH14X11fh+4d/Dqq30= From: Kent Watsen Message-ID: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 1 May 2019 22:39:11 +0000 In-Reply-To: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> Cc: Dhruv Dhody , "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" To: "Eric Voit (evoit)" References: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.01-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 22:39:17 -0000 --Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) = wrote: >=20 > Hi Dhruv, > Hi Kent, >=20 > Thanks very much for the comments Dhruv. Thoughts in-line, with one = question to Kent... >=20 >> From: Dhruv Dhody, April 30, 2019 12:53 AM >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. The >> Routing Directorate seeks to review all routing or routing-related = drafts as they >> pass through IETF last call and IESG review, and sometimes on special = request. >> The purpose of the review is to provide assistance to the Routing = ADs. For more >> information about the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it would >> be helpful if you could consider them along with any other IETF Last = Call >> comments that you receive, and strive to resolve them through = discussion or by >> updating the draft. >>=20 >> Document: draft-ietf-netconf-netconf-event-notifications-17 >> Reviewer: Dhruv Dhody >> Review Date: 2019-04-29 >> IETF LC End Date: 2019-04-12 >> Intended Status: Standards Track >>=20 >> Summary: >> -------- >> I have some minor concerns about this document that I think should be = resolved >> before publication. >>=20 >> Comments: >> --------- >> This document provides a binding for events streamed over the NETCONF = for >> dynamic subscriptions. This is a companion document to = draft-ietf-netconf- >> subscribed-notifications and this capability for RESTCONF is defined = in draft-ietf- >> netconf-restconf-notif. >>=20 >> The document is overall well written, it makes an assumption that the = reader is >> well versed in this area and thus sparse in providing details in the = Introduction >> section. The appendix provides good examples. >>=20 >> I don't see any Routing Yang model specific issue. >>=20 >> Major Issues: >> ------------- >> Note - An IETF process issue, but worth handling right away. >>=20 >> Section 11 says - >>=20 >> 11. Notes to the RFC Editor >>=20 >> This section can be removed by the RFC editor after the requests = have >> been performed. >>=20 >> It further says - >>=20 >> RFC 6241 needs to be updated based on the needs of this draft. >> RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it >> identifies RFC 5717, but that was an error fixed after RFC >> publication). Anyway the current phrasing in RFC-5277 says that a >> notification message can only be sent after a successful "create- >> subscription". Therefore the reference text must be modified to = also >> allow notification messages be sent after a successful "establish- >> subscription". Proposed text for bullet (2) of RFC-6241 would be: >>=20 >> (2) The Messages layer provides a simple, transport-independent >> framing mechanism for encoding RPCs and notifications. >> Section 4 documents the RPC messages, [RFC5277] documents >> Notifications sent as a result of a = RPC, >> and [RFC xxxx] documents Notifications sent as a result of >> an RPC. >>=20 >> (where xxxx is replaced with this RFC number) >>=20 >> I am not sure if this is correct. I don't think RFC editor can do the = action you are >> asking them to do on their own. They would need an errata (which is = not correct >> here) or another document that updates RFC 6241. In my view this = document >> should just update RFC 6241 (and mark that in this document's >> header) and do necessary text changes to reflect that. >=20 > I am happy to follow whatever process is cleanest. =20 >=20 > Kent, are you comfortable with this document directly revising = wording of RFC-6241 section 1.2 bullet "(2)" above? If yes, it would = be great to have your thoughts on what needs to go into this document. = Especially as RFC-6241 section 1.2 bullet "(2)" already had a fix = applied against it.=20 Dhruv is correct, the RFC Editor cannot make the requested change, and = an Errata is also not correct, as there is nothing wrong with the way = that RFC 6241 was written at the time it was written. To answer the question, if this draft is to "update" RFC 6241, the steps = are 1) declare the update in the draft's header (see Section 2.33.10 of = RFC 7749), 2) so so in the Abstract, and 3) have a new section (either = before of after the current Section 3 called "Update to RFC 6241" that = describes the desired modification. However, it is unclear if an "update" is appropriate either, given that = the "update" is informative in nature and, while it is true that this = document cannot be used without RFC 6241, that is also true for so many = documents that don't update RFC 6241. =46rom now obsolete RFC 2223 (I couldn't find a current reference): Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. and from expired draft-rfc-editor-rfc2223bis-08: Updates Specifies an earlier document whose contents are modified or augmented by the new document. The new document cannot be used alone, it can only be used in conjunction with the earlier document. Is an "update" overreaching? Another option is to not update RFC 6241 and instead just mention it, = similar to what was done here: = https://tools.ietf.org/html/rfc8071#section-1.4 = . Note that RFC 8071 = originally "updated" RFC 4253, but Benoit (AD at the time) recommended = downgrading it to what it is now. A couple more thoughts: 1) if an update is needed, would it be better coming from = draft-ietf-netconf-subscribed-notifications, which defines the = "establish-subscription" RPC? 2) whatever the outcome of this discussion, it seems that a similar = outcome should be applied to draft-ietf-netconf-restconf-notif and its = relation to RFC 8040. [also see my comment below] >> Minor Issues: >> ------------- >> (1) Abstract & Introduction, It is not clear what does the 'binding' = mean and who >> are the parties to this binding? If this is the document that = mentions 'binding' >> first, so please add some more clarifying text. >>=20 >> (2) Section 3, since you use MUST in the error handling, isn't it = better to use >> normative in below sentence as well - >> OLD: >> However a = single >> NETCONF transport session cannot support both this specification = and >> a subscription established by [RFC5277]'s "create-subscription" = RPC. >> NEW: >> However a = single >> NETCONF transport session MUST NOT support both this specification = and >> a subscription established by [RFC5277]'s "create-subscription" = RPC. >=20 > Makes sense. I have made the change, and will post the update when = the "Major issue" from above is resolved. >=20 >> (3) Section 6, You have - >>=20 >> And per [RFC5277]'s "eventTime" object definition, the >> "eventTime" MUST be populated with the event occurrence time. >>=20 >> Is this a new requirement, or just re-stating RFC5277? RFC5277 says - >>=20 >> eventTime >>=20 >> The time the event was generated by the event source. This >> parameter is of type dateTime and compliant to [RFC3339]. >> Implementations must support time zones. >>=20 >> Also contains notification-specific tagged content, if any. = With >> the exception of , the content of the notification is >> beyond the scope of this document. >>=20 >> Maybe remove MUST? If you are trying to refine the text from RFC5277, = then >> please re-word. >=20 > You are correct. The MUST is redundant with RFC-5277's XSD = definition. Therefore I have removed "MUST be". >=20 >> Nits: >> ----- >> (1) Abstract >>=20 >> RFC Editor note: please replace the four references to pre-RFC >> normative drafts with the actual assigned RFC numbers. >>=20 >> I see two drafts in the reference section. Why four? >=20 > You are correct. I removed the word "four". =20 >=20 >> Also, since those two are normative references, these would be = published as a >> cluster as a part of normal RFC editor processing right? >=20 > Yes. >=20 >> (2) Regarding NETCONF, the RFC editor says [1] - >>=20 >> NETCONF - Network Configuration Protocol (NETCONF) >> [Not typically expanded in titles, but expand in = abstract] >>=20 >> Please expand. >=20 > Done. >=20 >> (3) s/[I-D.draft-ietf-netconf-subscribed-notifications] >> /[I-D.ietf-netconf-subscribed-notifications] >=20 > Actually I changed the [I-D.ietf-netconf-yang-push] to = [I-D.draft-ietf-netconf-yang-push] >=20 > This makes it consistent across all four drafts. The issue isn't consistency so much as meeting expectations, per = `xml2rfc`, the document should have something like the following in the = References section, which then auto-expands to the correct reference = text, as well as defining the anchor = "I-D.ietf-netconf-subscribed-notifications": Kent // shepherd >=20 > Thanks again! > Eric >=20 >> Just so that you have the same style of draft reference in the = document. I get >> that it would be replaced with a RFC number anyways :) >>=20 >> [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt = >>=20 >> Thanks! >> Dhruv --Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

Hi = Dhruv,
Hi = Kent,

Thanks very = much for the comments Dhruv.  Thoughts in-line, with one question = to Kent...

From: = Dhruv Dhody, April 30, 2019 12:53 AM

Hello,

I have been selected as = the Routing Directorate reviewer for this draft. The
Routing= Directorate seeks to review all routing or routing-related drafts as = they
pass through IETF last call and IESG review, and = sometimes on special request.
The purpose of the review is = to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the = use of the Routing ADs, it would
be helpful if you could = consider them along with any other IETF Last Call
comments = that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: = draft-ietf-netconf-netconf-event-notifications-17
Reviewer: = Dhruv Dhody
Review Date: 2019-04-29
IETF LC = End Date: 2019-04-12
Intended Status: Standards Track

Summary:
--------
I = have some minor concerns about this document that I think should be = resolved
before publication.

Comments:
---------
This document = provides a binding for events streamed over the NETCONF for
dynamic subscriptions. This is a companion document to = draft-ietf-netconf-
subscribed-notifications and this = capability for RESTCONF is defined in draft-ietf-
netconf-restconf-notif.

The = document is overall well written, it makes an assumption that the reader = is
well versed in this area and thus sparse in providing = details in the Introduction
section. The appendix provides = good examples.

I don't see any Routing Yang = model specific issue.

Major Issues:
-------------
Note - An IETF process issue, but = worth handling right away.

Section 11 says = -

11.  Notes to the RFC Editor

  This section can be removed by the = RFC editor after the requests have
  been = performed.

It further says -

  RFC 6241 needs to be updated based = on the needs of this draft.
  RFC-6241 section = 1.2 bullet "(2)" targets RFC-5277 (actually it
  identifies RFC 5717, but that was an error fixed = after RFC
  publication).  Anyway the = current phrasing in RFC-5277 says that a
  notification message can only be sent after a = successful "create-
  subscription". =  Therefore the reference text must be modified to also
  allow notification messages be sent after a = successful "establish-
  subscription". =  Proposed text for bullet (2) of RFC-6241 would be:
    (2)  The Messages layer = provides a simple, transport-independent
         framing = mechanism for encoding RPCs and notifications.
         Section = 4 documents the RPC messages, [RFC5277] documents
         Notificat= ions sent as a result of a <create-subscription> RPC,
         and = [RFC xxxx] documents Notifications sent as a result of
         an = <establish-subscription> RPC.

     (where xxxx is replaced with = this RFC number)

I am not sure if this is = correct. I don't think RFC editor can do the action you are
asking them to do on their own. They would need an errata = (which is not correct
here) or another document that = updates RFC 6241. In my view this document
should just = update RFC 6241 (and mark that in this document's
header) = and do necessary text changes to reflect that.

I am happy to follow whatever process is cleanest. =   

Kent, are you = comfortable with this document directly revising  wording of = RFC-6241 section 1.2 bullet "(2)" above?    If yes, it = would be great to have your thoughts on what needs to go into this = document.   Especially as RFC-6241 section 1.2 bullet "(2)" = already had a fix applied against it. 


Dhruv is correct, the RFC Editor cannot make the = requested change, and an Errata is also not correct, as there is nothing = wrong with the way that RFC 6241 was written at the time it was = written.

To answer the = question, if this draft is to "update" RFC 6241, the steps are 1) = declare the update in the draft's header (see Section 2.33.10 of RFC = 7749), 2) so so in the Abstract, and 3) have a new section (either = before of after the current Section 3 called "Update to RFC 6241" that = describes the desired modification.

However, it is unclear if an "update" is = appropriate either, given that the "update" is informative in nature = and, while it is true that this document cannot be used without RFC = 6241, that is also true for so many documents that don't update RFC = 6241.

=46rom now obsolete RFC 2223 = (I couldn't find a current reference):

   Updates

      To = be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a = previous document), to refer
      = to the previous document.  The newer publication is a part = that
      will supplement or be = added on to the existing document; e.g., an
  =     addendum, or separate, extra information that is to be = added to
      the original = document.

and = from expired draft-rfc-editor-rfc2223bis-08:
      =    Updates

            Specifies an = earlier document whose contents are modified or
            augmented by the = new document.  The new document cannot be
 =           used alone, it can only be used in = conjunction with the
        =     earlier document.

Is an "update" overreaching?

Another option is to not update RFC 6241 and = instead just mention it, similar to what was done here: https://tools.ietf.org/html/rfc8071#section-1.4.   = Note that RFC 8071 originally "updated" RFC 4253, but Benoit (AD at the = time) recommended downgrading it to what it is now.


A = couple more thoughts:

1) if an = update is needed, would it be better coming from = draft-ietf-netconf-subscribed-notifications, which defines the = "establish-subscription" RPC?

2) = whatever the outcome of this discussion, it seems that a similar outcome = should be applied to draft-ietf-netconf-restconf-notif and its relation = to RFC 8040.


[also see my comment below]



Minor Issues:
-------------
(1) Abstract & Introduction, = It is not clear what does the 'binding' mean and who
are = the parties to this binding? If this is the document that mentions = 'binding'
first, so please add some more clarifying = text.

(2) Section 3, since you use MUST in = the error handling, isn't it better to use
normative in = below sentence as well -
OLD:
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      However a single
  NETCONF transport session cannot support both = this specification and
  a subscription = established by [RFC5277]'s "create-subscription" RPC.
NEW:
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      However a single
  NETCONF transport session MUST NOT support both = this specification and
  a subscription = established by [RFC5277]'s "create-subscription" RPC.

Makes sense.  I have made the change, and will post the = update when the "Major issue" from above is resolved.

(3) = Section 6, You have -

  And per = [RFC5277]'s "eventTime" object definition, the
  "eventTime" MUST be populated with the event = occurrence time.

Is this a new requirement, = or just re-stating RFC5277? RFC5277 says -

     eventTime

        The time the = event was generated by the event source.  This
        parameter is = of type dateTime and compliant to [RFC3339].
        Implementations= must support time zones.

     Also contains = notification-specific tagged content, if any.  With
     the exception of = <eventTime>, the content of the notification is
     beyond the scope of this = document.

Maybe remove MUST? If you are = trying to refine the text from RFC5277, then
please = re-word.

You are correct.  The MUST is redundant with RFC-5277's = XSD definition.   Therefore I have removed "MUST = be".

Nits:
-----
(1) Abstract

  RFC Editor note: please replace = the four references to pre-RFC
  normative = drafts with the actual assigned RFC numbers.

I see two drafts in the reference section. Why four?

You are correct.  I removed the word "four". =  

Also, = since those two are normative references, these would be published as = a
cluster as a part of normal RFC editor processing = right?

Yes.

(2) Regarding NETCONF, the RFC editor = says [1] -

NETCONF    - = Network Configuration Protocol (NETCONF)
          &nb= sp;   [Not typically expanded in titles, but expand in = abstract]

Please expand.

Done.

(3) = s/[I-D.draft-ietf-netconf-subscribed-notifications]
    /[I-D.ietf-netconf-subscribed-notificat= ions]

Actually I changed the [I-D.ietf-netconf-yang-push]  to =  [I-D.draft-ietf-netconf-yang-push]

This makes it consistent across all four drafts.


The issue isn't consistency so much as meeting = expectations, per `xml2rfc`, the document should have something like the = following in the References section, which then auto-expands to the = correct reference text, as well as defining the anchor = "I-D.ietf-netconf-subscribed-notifications":

        <?rfc = include=3D"reference.I-D.ietf-netconf-subscribed-notifications"?>



Kent // = shepherd



Thanks again!
Eric

Just so that you have the same style = of draft reference in the document. I get
that it would be = replaced with a RFC number anyways :)

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt
Thanks!
Dhruv

= --Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3-- From nobody Wed May 1 17:34:25 2019 Return-Path: <0100016a75f6a814-773436bf-9706-443a-b59e-3c5747566859-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468F8120089 for ; Wed, 1 May 2019 17:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5vMsQ0N17cf for ; Wed, 1 May 2019 17:34:21 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8263812006B for ; Wed, 1 May 2019 17:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556757260; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=EU21l/2xKfQtRzRY4FHOfzTVI5WALk2pjwVnwEbX2GI=; b=YN0Qf3d1G1KGz6Rz2OdZuQiqvXGSbcZFpB2cB++EfdXYOd5J4Rbgv91Lj8s2DJKN +//3FXb5pRvnt9bMJWXFc4gjyg5+qPhC7EZWY9Gco++ss4898iBr5wDRa36qaU9Od9A WbvJPzaw33DbCh4Kfqic2pOM0COU3CSg7unIkS8I= From: Kent Watsen Message-ID: <0100016a75f6a814-773436bf-9706-443a-b59e-3c5747566859-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_039D6799-5356-4AAA-A7F0-FD82F2A2D78F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 2 May 2019 00:34:20 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" To: Andy Bierman References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 00:34:23 -0000 --Apple-Mail=_039D6799-5356-4AAA-A7F0-FD82F2A2D78F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The document-oriented configuration came from a requirement identified > at the IAB Network Management Workshop (way back when). > It is critical for rebooting, swapping out a defective device, etc. Regarding the document-model concern, here is a line of thinking that = may help this discussion: We recently removed the "cannot be backed-up language" because there may = be a way for a device to backup a permanently hidden key, even when = protected by a TPM. Specifically, a TPM (I don't know about other crypto processors) is able = to encrypt TPM-protected keys (using yet another TPM-protected key = called the storage root key, SRK), thus the key (albeit encrypted) CAN = be backed up, but it CAN ONLY be restored on the device having the = originating TPM. Thus, instead of using the enum "permanently-hidden", the value of the = *encrypted* key could be safely provided. Perhaps we could model the 'private-key' value after iana-crypt-hash and = prefix the base64-encoded binary private key value with some special = (not legal base64) value indicating that the key is 1) encrypted and 2) = can only be restored on the originating device. Ideally, the prefix = identifies the device (or, better, the crypto processor), lest there is = any confusion. As for "swapping out a defective device", the above idea doesn't support = that workflow, but I think that the inability to do a full RMA is given = with the meaning of a "permanently-hiddden" key already and, anyone that = creates such a key does so with that understanding. What it does = support, though, is the full restoration of the device after a = hard-drive replacement (or reformat) using a standard "configuration" = document, which seems better than what we have now with the = "permanently-hidden" enum. > The "server created config" problem could be viewed as an access = control problem. > There are proprietary YANG extensions that implement this approach. I don't understand, can you provide examples? Kent // contributor --Apple-Mail=_039D6799-5356-4AAA-A7F0-FD82F2A2D78F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The = document-oriented configuration came from a requirement = identified
at the IAB Network Management Workshop = (way back when).
It is critical for rebooting, = swapping out a defective device, = etc.


Regarding the document-model concern, here is = a line of thinking that may help this discussion:

We recently removed the "cannot be backed-up = language" because there may be a way for a device to backup a = permanently hidden key, even when protected by a TPM.

Specifically, a TPM (I don't know about other = crypto processors) is able to encrypt TPM-protected keys (using yet = another TPM-protected key called the storage root key, SRK), thus the = key (albeit encrypted) CAN be backed up, but it CAN ONLY be restored on = the device having the originating TPM.

Thus, instead of using the enum = "permanently-hidden", the value of the *encrypted* key could be safely = provided.

Perhaps we could model the = 'private-key' value after iana-crypt-hash and prefix the base64-encoded = binary private key value with some special (not legal base64) value = indicating that the key is 1) encrypted and 2) can only be restored on = the originating device.  Ideally, the prefix identifies the device = (or, better, the crypto processor), lest there is any = confusion.

As for "swapping out a = defective device", the above idea doesn't support that workflow, but I = think that the inability to do a full RMA is given with the meaning of a = "permanently-hiddden" key already and, anyone that creates such a key = does so with that understanding.   What it does support, though, is = the full restoration of the device after a hard-drive replacement (or = reformat) using a standard "configuration" document, which seems better = than what we have now with the "permanently-hidden" enum.



The = "server created config" problem could be viewed as an access control = problem.
There are proprietary YANG extensions that = implement this approach.

I don't understand, can you provide = examples?



Kent // = contributor

= --Apple-Mail=_039D6799-5356-4AAA-A7F0-FD82F2A2D78F-- From nobody Wed May 1 17:43:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BDD1201A6 for ; Wed, 1 May 2019 17:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FEmlNLKTlGWj for ; Wed, 1 May 2019 17:43:53 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2601200A3 for ; Wed, 1 May 2019 17:43:52 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id k8so575031lja.8 for ; Wed, 01 May 2019 17:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cJITYUppbMs9K4lq4bcZj2uRj3j5Bf0U7tkjTQ+TYKI=; b=kMnVFtkQdBy5h4XYvSSVLygiNeM69jRG8UJA9iGVpHSlWydGAN67oGyfjKi/eZ/9P+ 2jfdizeU3upZg6VdxTNG8GxRa/5yUf4qkKzkdvkl3l/Koa0b5F2KluYWfbE+Wwl8ZMW3 PsWs910wFRfLFyscjavl9ui9mVvq/WktOS68coGHUchYgISvTgdUK3nFztn6BfmLLoe4 5+gm9oS+2W1bkgCrpnTvRHcUx4h87IwYqdCbqJSCTqhDvX17uIP6FHhvk8ZMdm8T8QRw Z55mJFfwF+iPIjLk4AiWgM+1CLYthrV2yu2FGEBL7dbpE0hyDDnvC0p/bCKvf4iJYLD4 VbyA== 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=cJITYUppbMs9K4lq4bcZj2uRj3j5Bf0U7tkjTQ+TYKI=; b=oFSZys362UZ5GOFz0zJmJ5RLF2Qub51uukG4vOYL2pchbWdeYWt43UE8O4sFid51iK /GHTmhgfHisEIlome9u8B4Vb6/tTv+WzFqLGzrCCQ34e/TPH4JPHlog5Z88s+Fl3OuKX OS6Sh+zNbrHJz0peoNrY7ufoQSBc+AuwdZhnpG+4Kp+E81i2TxTqwGSWSE0vho4iJEQW Eyod4LTLKXZ7dNjF2M0vP/AW3vhL/bvlvUJ4FGQTOgtEZ2pN+JTdeCjDJh2lRm7mFgmC OF+VVs5xDcEiH4LjghIQSV8qTtSKAkQ3dv0JDbkfogaQMFwz3m34Wx9ImitnIdwIt+Ba mVeQ== X-Gm-Message-State: APjAAAVmOm6tR/WBygiv3OrVXXX2L7al2hBt5Ag3dzy0fu/6go4NtsRf X/8sux87jKkx1Ib+frLsJj8YTcfEaCmyGlpyUqKb6g== X-Google-Smtp-Source: APXvYqxNC6tGF6zA4nzHoEw8WuvyDq53nGaYu1VUfU4Ix5BswIYqRlOL9ShHqeRWrRgYMlIwx+0O9koBc9hGXlxVdMY= X-Received: by 2002:a2e:85d2:: with SMTP id h18mr224340ljj.128.1556757830835; Wed, 01 May 2019 17:43:50 -0700 (PDT) MIME-Version: 1.0 References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <0100016a75f6a814-773436bf-9706-443a-b59e-3c5747566859-000000@email.amazonses.com> In-Reply-To: <0100016a75f6a814-773436bf-9706-443a-b59e-3c5747566859-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 1 May 2019 17:43:39 -0700 Message-ID: To: Kent Watsen Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008237470587dcedc2" Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 00:43:55 -0000 --0000000000008237470587dcedc2 Content-Type: text/plain; charset="UTF-8" On Wed, May 1, 2019 at 5:34 PM Kent Watsen wrote: > > The document-oriented configuration came from a requirement identified > at the IAB Network Management Workshop (way back when). > It is critical for rebooting, swapping out a defective device, etc. > > > > Regarding the document-model concern, here is a line of thinking that may > help this discussion: > > We recently removed the "cannot be backed-up language" because there may > be a way for a device to backup a permanently hidden key, even when > protected by a TPM. > > Specifically, a TPM (I don't know about other crypto processors) is able > to encrypt TPM-protected keys (using yet another TPM-protected key called > the storage root key, SRK), thus the key (albeit encrypted) CAN be backed > up, but it CAN ONLY be restored on the device having the originating TPM. > > Thus, instead of using the enum "permanently-hidden", the value of the > *encrypted* key could be safely provided. > > Perhaps we could model the 'private-key' value after iana-crypt-hash and > prefix the base64-encoded binary private key value with some special (not > legal base64) value indicating that the key is 1) encrypted and 2) can only > be restored on the originating device. Ideally, the prefix identifies the > device (or, better, the crypto processor), lest there is any confusion. > > As for "swapping out a defective device", the above idea doesn't support > that workflow, but I think that the inability to do a full RMA is given > with the meaning of a "permanently-hiddden" key already and, anyone that > creates such a key does so with that understanding. What it does support, > though, is the full restoration of the device after a hard-drive > replacement (or reformat) using a standard "configuration" document, which > seems better than what we have now with the "permanently-hidden" enum. > > This requirement led directly to the ability in NETCONF to do a simple and stuff the returned data into an or request. > > The "server created config" problem could be viewed as an access control > problem. > There are proprietary YANG extensions that implement this approach. > > > I don't understand, can you provide examples? > We have a "user-write" extension that can override NACM and prevent client access to server-created configuration. http://www.netconfcentral.org/modules/yuma-ncx/2015-10-16#user-write.704 Andy > > > > Kent // contributor > > --0000000000008237470587dcedc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 1, 2019 at 5:34 PM Kent W= atsen <kent+ietf@watsen.net> wrote:

<= div dir=3D"ltr">
The document-oriented confi= guration came from a requirement identified
at the IAB Network Ma= nagement Workshop (way back when).
It is critical for rebooting, = swapping out a defective device, etc.













Andy
=C2=A0



Ke= nt // contributor

--0000000000008237470587dcedc2-- From nobody Wed May 1 18:57:13 2019 Return-Path: <0100016a7642264b-768e94ec-95fd-400a-9837-73b14528737f-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1D1202C7 for ; Wed, 1 May 2019 18:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXz8CWBX_xQg for ; Wed, 1 May 2019 18:56:49 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0C51202A7 for ; Wed, 1 May 2019 18:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556762207; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2GIFAcsqteeoAykExsexOF03FUodhHc+qNaYRy9quO4=; b=H1CAABLk4Fa0Hv4gT1FuxmUWmMkWv/0MOkE2ZEz1sGHds6C7lvCwmpH8gILJhaUr lQSQP07eh0iF3liX6nohA5Xy3EpuOF1rD1Yht1q5h3pZ5zMyh4qV4z2S0ZfSqyglKdV MU1Q0iQE1OU/1BKUi5+fS20cTm7GlWxmAS2nDsaA= From: Kent Watsen Message-ID: <0100016a7642264b-768e94ec-95fd-400a-9837-73b14528737f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4605E82F-F4B1-44C9-9A81-692C7A3DFF8C" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 2 May 2019 01:56:47 +0000 In-Reply-To: <20190501.230622.158012882760210627.mbj@tail-f.com> Cc: Juergen Schoenwaelder , "netconf@ietf.org" To: Martin Bjorklund References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 01:57:00 -0000 --Apple-Mail=_4605E82F-F4B1-44C9-9A81-692C7A3DFF8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > What I object to is a third use case, where the action would modify > the config with the generated keys. What is your proposal for how to address the best practice and, in some = cases,=20 government requirement, that a private key never exists outside of a = device=20 (controlled backups aside)? =46rom https://revocent.com/best-practices-for-securing-private-keys: = "It=E2=80=99s crucial that the generation of the key be done on the = same system and the same local filesystem as the storage location. Generating the key on a = server and then transferring the key back to the local system and storing it just = adds multiple points of vulnerability. Why would you want to increase the chance of = your private key being compromised?" Additionally, SC-12(3) of NIST 800-53 says: (note: the word "produce" = is key here) "Produce, control, and distribute asymmetric cryptographic keys = using [Selection:=20 NSA-approved key management technology and processes; approved DoD = PKI Class 3 certificates; prepositioned keying material; approved DoD = PKI Class 3 or Class 4 certificates and hardware security tokens that protect the = user=E2=80=99s private key; certificates issued in accordance with organization-defined = requirements]." Many networking devices include an SSL-protected web-interface. 1) Typically the interface is initially secured via a self-signed = certificate, which causes the browser to display a nagging message when = connecting, thus prompting remediation. 2) Almost all products include an ability to upload the 2-tuple of a = private key and a signed certificate. This resolves the self-sign cert = issue, but the best practice and government compliance concerns are not = addressed. 3) The better products have an ability to: a) let the device generate the private key b) let the device generate a certificate signing request using = its private key c) upload to the device a certificate generated by an external = CA signing the CSR. =20 [FWIW, Juniper's SRX device introduced this ability in 2011.] The current model supports (2), as well as (3b) and (3c), we're just = missing (3a),=20 which is what the original `generate-asymmetric-key` action was for. FWIW, from a product perspective, supporting (3a) is more important then = supporting `generate-hidden-key` or `install-hidden-key` (so long as = manufacturer-generated hidden keys are still supported, e.g., for IDevID certificates). While = client-generated permanently-hidden keys is goodness, it's not widely implemented. Kent --Apple-Mail=_4605E82F-F4B1-44C9-9A81-692C7A3DFF8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

What I object to is a third use case, where the action would = modify
the config with the = generated keys.

What is your proposal for how to address the best = practice and, in some cases, 
government requirement, = that a private key never exists outside of a = device 
(controlled backups aside)?















= --Apple-Mail=_4605E82F-F4B1-44C9-9A81-692C7A3DFF8C-- From nobody Wed May 1 19:41:49 2019 Return-Path: <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7EB1202D3 for ; Wed, 1 May 2019 19:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 eZ0opJxmuPFK for ; Wed, 1 May 2019 19:41:43 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB611202EA for ; Wed, 1 May 2019 19:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556764902; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=IdCUxtVesY88/f6fXkS6Mov/oA8A7koOO20rX+K2gqQ=; b=QQrWVLJ2TUgQU/hXSZgtWnxLubCHsagPpuVK89BUmRbOIjG0DWjHFt/VqEiQUSIJ Q8UI2PdOu3aRIJhxmz4uR5eToRGR8BUo4X4LsR9WsFaLykogGxPOE3u1fQ5OAra/5Lv rSL8Zi6rM1LHG2mCJM/7DRPuV86yhxCapS674AZs= From: Kent Watsen Message-ID: <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B5B10F-56D1-4EF9-A75C-89C073572A1E" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 2 May 2019 02:41:42 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Nick Hancock References: X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 02:41:49 -0000 --Apple-Mail=_E6B5B10F-56D1-4EF9-A75C-89C073572A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Nick, You are correct that something is amiss, but I'd like to discuss the fix = more. Your proposal looks (squinting my eyes) right (have you tested it?), but = I'm wondering if there isn't a lower-level and potentially more useful = fix... In particular, note that 'ks:asymmetric-key-certificate-ref' points to a = certificate in the the keystore that comes from the 'uses = ct:asymmetric-key-pair-with-certs-grouping' statement. The idea behind = this grouping is that, whenever a certificate is configured, whether in = the keystore or not, that the 'asymmetric-key-pair-grouping 3-tuple = (alg, pub key, private key) is also configured. This suggests that = ct:asymmetric-key-pair-with-certs-grouping may be missing a 'must' = statement or, more likely (due to the fact that the 3-tuple may only = exist in ), its 'description' statement is missing that = precondition in its text. Thoughts? Kent // contributor > On Apr 30, 2019, at 11:39 AM, Nick Hancock = wrote: >=20 > Hi Kent, >=20 > I have just noticed a issue with the leaf 'keystore-reference' used=20 > in the grouping 'local-or-keystore-end-entity-cert-with-key-grouping'=20= > in ietf-keystore. >=20 > This leafref uses the typedef 'asymmetric-key-certificate-ref', but,=20= > unless I am missing something, this alone will not work, because a=20 > predicate for the list 'asymmetric-key' is missing.=20 >=20 > I would expect something like the following: >=20 > case keystore { > if-feature "keystore-supported"; > leaf asymmetric-key-name { > type ks:asymmetric-key-ref; > description > "A reference to an asymmetric key that exists in > the keystore. ";=20 > } > leaf certificate-name { > type leafref { > path=20 > "/ks:keystore" > + "/ks:asymmetric-keys" > + "/ks:asymmetric-key" > + "[ks:name=3Dcurrent()/../"=20 > + "asymmetric-key-name]"=20 > + "/ks:certificates"=20 > + "/ks:certificate/ks:name"; > } > description > "A reference to a specific certificate associated=20 > with the given private key, stored in the keystore."; =20 > } > } >=20 > Regards > Nick >=20 --Apple-Mail=_E6B5B10F-56D1-4EF9-A75C-89C073572A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Nick,

You are correct that something is = amiss, but I'd like to discuss the fix more.

Your proposal looks (squinting my eyes) = right (have you tested it?), but I'm wondering if there isn't a = lower-level and potentially more useful fix...

In particular, note that = 'ks:asymmetric-key-certificate-ref' points to a certificate in the the = keystore that comes from the = 'uses ct:asymmetric-key-pair-with-certs-grouping' statement.   = The idea behind this grouping is that, whenever a certificate is = configured, whether in the keystore or not, that the = 'asymmetric-key-pair-grouping 3-tuple (alg, pub key, private key) is = also configured.   This suggests that = ct:asymmetric-key-pair-with-certs-grouping may be missing a 'must' = statement or, more likely (due to the fact that the 3-tuple may only = exist in <operational>), its 'description' statement is missing = that precondition in its text.

Thoughts?

Kent // contributor



On Apr = 30, 2019, at 11:39 AM, Nick Hancock <nick.hancock@adtran.com> wrote:

Hi = Kent,

I have just noticed a issue with the = leaf 'keystore-reference' used
in the grouping = 'local-or-keystore-end-entity-cert-with-key-grouping'
in = ietf-keystore.

This leafref uses the = typedef 'asymmetric-key-certificate-ref', but,
unless I = am missing something, this alone will not work, because a
predicate for the list 'asymmetric-key' is missing.

I would expect something like the = following:

case keystore {
=  if-feature "keystore-supported";
 leaf = asymmetric-key-name {
   type = ks:asymmetric-key-ref;
=      description
=        "A reference to an asymmetric = key that exists in
=         the keystore. ";
 }
 leaf certificate-name {
   type leafref {
=      path
=        "/ks:keystore"
=        + "/ks:asymmetric-keys"
       + = "/ks:asymmetric-key"
=        + "[ks:name=3Dcurrent()/../" =
       + = "asymmetric-key-name]"
=        + "/ks:certificates"
       + = "/ks:certificate/ks:name";
   }
   description
=     "A reference to a specific certificate = associated
     with the given = private key, stored in the keystore.";   
=  }
}

Regards
Nick


= --Apple-Mail=_E6B5B10F-56D1-4EF9-A75C-89C073572A1E-- From nobody Wed May 1 23:31:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E3A120052 for ; Wed, 1 May 2019 23:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23eph49RqwUD for ; Wed, 1 May 2019 23:31:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3B9A120006 for ; Wed, 1 May 2019 23:31:54 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id CA8A71AE0449; Thu, 2 May 2019 08:31:51 +0200 (CEST) Date: Thu, 02 May 2019 08:31:51 +0200 (CEST) Message-Id: <20190502.083151.1810372041148955048.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a7642264b-768e94ec-95fd-400a-9837-73b14528737f-000000@email.amazonses.com> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <0100016a7642264b-768e94ec-95fd-400a-9837-73b14528737f-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 06:31:57 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IA0KPiAN Cj4gPiBXaGF0IEkgb2JqZWN0IHRvIGlzIGEgdGhpcmQgdXNlIGNhc2UsIHdoZXJlIHRoZSBhY3Rp b24gd291bGQgbW9kaWZ5DQo+ID4gdGhlIGNvbmZpZyB3aXRoIHRoZSBnZW5lcmF0ZWQga2V5cy4N Cj4gDQo+IFdoYXQgaXMgeW91ciBwcm9wb3NhbCBmb3IgaG93IHRvIGFkZHJlc3MgdGhlIGJlc3Qg cHJhY3RpY2UgYW5kLCBpbiBzb21lIGNhc2VzLCANCj4gZ292ZXJubWVudCByZXF1aXJlbWVudCwg dGhhdCBhIHByaXZhdGUga2V5IG5ldmVyIGV4aXN0cyBvdXRzaWRlIG9mIGEgZGV2aWNlIA0KPiAo Y29udHJvbGxlZCBiYWNrdXBzIGFzaWRlKT8NCg0KVXNlIHRoZSBjdXJyZW50ICJnZW5lcmF0ZS1o aWRkZW4ta2V5Ii4gIE5vdGUgdGhhdCB0aGUgcHJvcG9zZWQgM3JkDQphbHRlcm5hdGl2ZSBkb2Vz IG5vdCBhZGRyZXNzIHRoaXMgcmVxdWlyZW1lbnQsIHNpbmNlIHRoZSBwcml2YXRlIGtleSB3aWxs IGJlDQpwYXJ0IG9mIHRoZSBub3JtYWwgY29uZmlnLCBhbmQgdGh1cyBjYW4gYmUgcmVhZCBieSBh bnlvbmUgKHdpdGggdGhlIHJpZ2h0DQphY2Nlc3MpLg0KDQo+IEZyb20gaHR0cHM6Ly9yZXZvY2Vu dC5jb20vYmVzdC1wcmFjdGljZXMtZm9yLXNlY3VyaW5nLXByaXZhdGUta2V5czogPGh0dHBzOi8v cmV2b2NlbnQuY29tL2Jlc3QtcHJhY3RpY2VzLWZvci1zZWN1cmluZy1wcml2YXRlLWtleXM6Pg0K PiANCj4gICAgICJJdOKAmXMgY3J1Y2lhbCB0aGF0IHRoZSBnZW5lcmF0aW9uIG9mIHRoZSBrZXkg YmUgZG9uZSBvbiB0aGUgc2FtZQ0KPiAgICAgIHN5c3RlbSBhbmQgdGhlIHNhbWUgbG9jYWwgZmls ZXN5c3RlbSBhcyB0aGUgc3RvcmFnZSBsb2NhdGlvbi4NCj4gICAgICBHZW5lcmF0aW5nIHRoZSBr ZXkgb24gYSBzZXJ2ZXIgYW5kIHRoZW4gdHJhbnNmZXJyaW5nIHRoZSBrZXkNCj4gICAgICBiYWNr IHRvIHRoZSBsb2NhbCBzeXN0ZW0gYW5kIHN0b3JpbmcgaXQganVzdCBhZGRzIG11bHRpcGxlDQo+ ICAgICAgcG9pbnRzIG9mIHZ1bG5lcmFiaWxpdHkuICBXaHkgd291bGQgeW91IHdhbnQgdG8gaW5j cmVhc2UgdGhlDQo+ICAgICAgY2hhbmNlIG9mIHlvdXIgcHJpdmF0ZSBrZXkgYmVpbmcgY29tcHJv bWlzZWQ/Ig0KPiANCj4gDQo+IEFkZGl0aW9uYWxseSwgU0MtMTIoMykgb2YgTklTVCA4MDAtNTMg c2F5czogICAobm90ZTogdGhlIHdvcmQNCj4gInByb2R1Y2UiIGlzIGtleSBoZXJlKSANCj4gDQo+ ICAgICAiUHJvZHVjZSwgY29udHJvbCwgYW5kIGRpc3RyaWJ1dGUgYXN5bW1ldHJpYyBjcnlwdG9n cmFwaGljIGtleXMNCj4gICAgICB1c2luZyBbU2VsZWN0aW9uOiBOU0EtYXBwcm92ZWQga2V5IG1h bmFnZW1lbnQgdGVjaG5vbG9neSBhbmQNCj4gICAgICBwcm9jZXNzZXM7IGFwcHJvdmVkIERvRCBQ S0kgQ2xhc3MgMyBjZXJ0aWZpY2F0ZXM7IHByZXBvc2l0aW9uZWQNCj4gICAgICBrZXlpbmcgbWF0 ZXJpYWw7IGFwcHJvdmVkIERvRCBQS0kgQ2xhc3MgMyBvciBDbGFzcyA0DQo+ICAgICAgY2VydGlm aWNhdGVzIGFuZCBoYXJkd2FyZSBzZWN1cml0eSB0b2tlbnMgdGhhdCBwcm90ZWN0IHRoZQ0KPiAg ICAgIHVzZXLigJlzIHByaXZhdGUga2V5OyBjZXJ0aWZpY2F0ZXMgaXNzdWVkIGluIGFjY29yZGFu Y2Ugd2l0aA0KPiAgICAgIG9yZ2FuaXphdGlvbi1kZWZpbmVkIHJlcXVpcmVtZW50c10uIg0KPiAN Cj4gDQo+IE1hbnkgbmV0d29ya2luZyBkZXZpY2VzIGluY2x1ZGUgYW4gU1NMLXByb3RlY3RlZCB3 ZWItaW50ZXJmYWNlLg0KPiANCj4gICAgIDEpIFR5cGljYWxseSB0aGUgaW50ZXJmYWNlIGlzIGlu aXRpYWxseSBzZWN1cmVkIHZpYSBhDQo+ICAgICAgICAgIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRl LCB3aGljaCBjYXVzZXMgdGhlIGJyb3dzZXIgdG8NCj4gICAgICAgICAgZGlzcGxheSBhIG5hZ2dp bmcgbWVzc2FnZSB3aGVuIGNvbm5lY3RpbmcsIHRodXMgcHJvbXB0aW5nDQo+ICAgICAgICAgIHJl bWVkaWF0aW9uLg0KPiANCj4gICAgIDIpIEFsbW9zdCBhbGwgcHJvZHVjdHMgaW5jbHVkZSBhbiBh YmlsaXR5IHRvIHVwbG9hZCB0aGUgMi10dXBsZQ0KPiAgICAgICAgICBvZiBhIHByaXZhdGUga2V5 IGFuZCBhIHNpZ25lZCBjZXJ0aWZpY2F0ZS4gIFRoaXMgcmVzb2x2ZXMNCj4gICAgICAgICAgdGhl IHNlbGYtc2lnbiBjZXJ0IGlzc3VlLCBidXQgdGhlIGJlc3QgcHJhY3RpY2UgYW5kDQo+ICAgICAg ICAgIGdvdmVybm1lbnQgY29tcGxpYW5jZSBjb25jZXJucyBhcmUgbm90IGFkZHJlc3NlZC4NCj4g DQo+ICAgICAzKSBUaGUgYmV0dGVyIHByb2R1Y3RzIGhhdmUgYW4gYWJpbGl0eSB0bzoNCj4gICAg ICAgICAgIGEpIGxldCB0aGUgZGV2aWNlIGdlbmVyYXRlIHRoZSBwcml2YXRlIGtleQ0KPiAgICAg ICAgICAgYikgbGV0IHRoZSBkZXZpY2UgZ2VuZXJhdGUgYSBjZXJ0aWZpY2F0ZSBzaWduaW5nIHJl cXVlc3QNCj4gICAgICAgICAgICAgIHVzaW5nIGl0cyBwcml2YXRlIGtleQ0KPiAgICAgICAgICAg YykgdXBsb2FkIHRvIHRoZSBkZXZpY2UgYSBjZXJ0aWZpY2F0ZSBnZW5lcmF0ZWQgYnkgYW4NCj4g ICAgICAgICAgICAgIGV4dGVybmFsIENBIHNpZ25pbmcgdGhlIENTUi4gICANCj4gICAgICAgICAg IFtGV0lXLCBKdW5pcGVyJ3MgU1JYIGRldmljZSBpbnRyb2R1Y2VkIHRoaXMgYWJpbGl0eSBpbiAy MDExLl0NCj4gDQo+IFRoZSBjdXJyZW50IG1vZGVsIHN1cHBvcnRzICgyKSwgYXMgd2VsbCBhcyAo M2IpIGFuZCAoM2MpLCB3ZSdyZSBqdXN0DQo+IG1pc3NpbmcgKDNhKSwNCj4gd2hpY2ggaXMgd2hh dCB0aGUgb3JpZ2luYWwgYGdlbmVyYXRlLWFzeW1tZXRyaWMta2V5YCBhY3Rpb24gd2FzIGZvci4N Cg0KVGhlcmUgbXVzdCBiZSBzb21lIG1pc3VuZGVyc3RhbmRpbmcuICBJTU8sIHRoZSBjdXJyZW50 DQoiZ2VuZXJhdGUtaGlkZGVuLWtleSIgY2xlYXJseSBzdXBwb3J0cyAzYS4gIFRoZSBkZXZpY2Ug Z2VuZXJhdGVzIHRoZQ0Ka2V5IHdoZW4gdGhpcyBhY3Rpb24gaXMgaW52b2tlZC4NCg0KPiBGV0lX LCBmcm9tIGEgcHJvZHVjdCBwZXJzcGVjdGl2ZSwgc3VwcG9ydGluZyAoM2EpIGlzIG1vcmUgaW1w b3J0YW50DQo+IHRoZW4gc3VwcG9ydGluZyBgZ2VuZXJhdGUtaGlkZGVuLWtleWAgb3IgYGluc3Rh bGwtaGlkZGVuLWtleWAgKHNvDQo+IGxvbmcgYXMgbWFudWZhY3R1cmVyLWdlbmVyYXRlZCBoaWRk ZW4ga2V5cyBhcmUgc3RpbGwgc3VwcG9ydGVkLA0KPiBlLmcuLCBmb3IgSURldklEIGNlcnRpZmlj YXRlcykuICBXaGlsZSBjbGllbnQtZ2VuZXJhdGVkDQo+IHBlcm1hbmVudGx5LWhpZGRlbiBrZXlz IGlzIGdvb2RuZXNzLCBpdCdzIG5vdCB3aWRlbHkgaW1wbGVtZW50ZWQuDQoNCg0KDQovbWFydGlu DQo= From nobody Thu May 2 02:39:16 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA3120026 for ; Thu, 2 May 2019 02:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PVwbGQk-bBe for ; Thu, 2 May 2019 02:39:13 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10111.outbound.protection.outlook.com [40.107.1.111]) (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 D832212004A for ; Thu, 2 May 2019 02:39:12 -0700 (PDT) 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=rDtRmoBG1vGuOaNxhF+YkKq0olIZHfKofjvWppzzddE=; b=WKiZ4l4i2s7j9g5zQnPlbWaJXTnOO19LCXcndzrQLbC5Ge5oR5U9hLptlUubj0wwD4ixRj1Jbre0lzPtTW4O/1hLsfyux6jtcMjRiqpVgJ0umsxyJg8powfZMbN9QneIAm5QYkD9uzpCNMAQ4AZNVAy98+LAU3tESc86+/YWV1w= Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5693.eurprd07.prod.outlook.com (20.178.120.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Thu, 2 May 2019 09:39:09 +0000 Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Thu, 2 May 2019 09:39:09 +0000 From: tom petch To: Juergen Schoenwaelder , Andy Bierman CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHVAMrknf3fF5qMGEKvxGfF1bfg7A== Date: Thu, 2 May 2019 09:39:09 +0000 Message-ID: <03de01d500ca$68ad9da0$4001a8c0@gateway.2wire.net> References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <20190501180553.3oidb7x275tgcdz6@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0024.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::36) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dda59e16-d341-442a-3b2d-08d6cee2069d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5693; x-ms-traffictypediagnostic: VI1PR07MB5693: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(136003)(346002)(396003)(376002)(13464003)(189003)(199004)(54094003)(2906002)(76176011)(81686011)(4720700003)(81816011)(52116002)(6486002)(84392002)(966005)(478600001)(62236002)(1556002)(44716002)(66066001)(61296003)(50226002)(44736005)(6246003)(256004)(53936002)(476003)(86152003)(9686003)(6512007)(14444005)(8936002)(6306002)(4326008)(25786009)(14496001)(446003)(3846002)(486006)(73956011)(66946007)(66476007)(66556008)(66446008)(6116002)(5660300002)(8676002)(229853002)(64756008)(186003)(26005)(14454004)(316002)(81156014)(386003)(81166006)(6506007)(102836004)(71200400001)(71190400001)(99286004)(305945005)(68736007)(86362001)(6436002)(7736002)(110136005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5693; H:VI1PR07MB3118.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OQBy4ztH80r8couRAg8GCLUs/i1F8LGBhGLlPeioeDPr4LKGEe2thOQwa3LCYJUoH4+PdwNVdM3P9W/nfADMurb5lwfvzPS8ZkFKOQ4O6D9I9ByjpPbB+gwU8vDcWjSZAb2JBOVkLmRf9gtFwPW65AiYssccyenil9KqX9vW2p2eDKcbB6tqv6KYQmjuMufqKjzYiE1cYiLn29Nhd0Z84Ll8CA6X9JvC9Og8ajFdWL/9q5PaSlfsAfp6cxbQc8SnuG6ltciiGBcqPHBXU34s+mmqjxF+P7FqflJ3GQbw3pwNl7LZR1gvxLc7x9z+JO0n1MrANNc+rErXsLQQ2SKCGbXfzltYARXX6qwlpcgpdng/+jGDeGE0Fa/pKwjDslcfiHY9naqKmgiLdKZEiwyNs/TmY0lq+MePsnkisHM48L8= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <774E1A22505CEE498C46A2DDCA9DD1BB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: dda59e16-d341-442a-3b2d-08d6cee2069d X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 09:39:09.7587 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5693 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 09:39:15 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Wednesday, May 01, 2019 7:05 PM > On Wed, May 01, 2019 at 09:19:38AM -0700, Andy Bierman wrote: > > > > This seems to be a good test for whether NMDA is useful as designed. > > It seems obvious that something has to be stored in and > > then transformed as it is applied to . > > > > The issue here seems to be that you create a resource that you would > like to be partially accessible as config and partially not accessible > at all or only as applied config in operational state. The question is > how to model that, i.e., the binding between config part and the > internal state part. Do we have any other similar resources or is this > really a very special case? I wonder if IPv6 privacy addresses are similar, generated on the device using random or pseudo-random input and which may also use device specific data such as MAC address; and which may derive from the device's public key. If the hardware is replaced, and the configuration is restored, should the address stay the same or is it a breach of privacy to carry the address across? I do not know but would guess the latter. Tom Petch > We discussed the 'create user account' case where often users ids are > allocated as a side effect of creating an account but the allocated > ids then becomes regular config, i.e., the config can be copied and > restored as one would expect. This is not really the same case that we > have with locally created keys. > > An alternative might be to consider a locally generated key entirely > operational state (applied config): You invoke an RPC to create a key > and you give it a name and then it exists as named operational state > (applied config) until you delete that named operational state. If you > want to configure a transport that refers to such a key, you do this > via a name binding, pretty much in the way we apply interface > configuration to an interface with a matching name. Perhaps this is a > model that could work. > > Perhaps Martin has even better ideas. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu May 2 02:49:24 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563F12031F for ; Thu, 2 May 2019 02:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1o1nl5ltzSO for ; Thu, 2 May 2019 02:49:20 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5DD120318 for ; Thu, 2 May 2019 02:49:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B73EC7F; Thu, 2 May 2019 11:49:18 +0200 (CEST) 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 J0YDWld4HWGE; Thu, 2 May 2019 11:49:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 May 2019 11:49:18 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id A08CA200E2; Thu, 2 May 2019 11:49:18 +0200 (CEST) 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 y4kidvss-13B; Thu, 2 May 2019 11:49:18 +0200 (CEST) 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 4D1F7200E1; Thu, 2 May 2019 11:49:18 +0200 (CEST) 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.1713.5; Thu, 2 May 2019 11:49:17 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 2B96E3008B9D17; Thu, 2 May 2019 11:49:16 +0200 (CEST) Date: Thu, 2 May 2019 11:49:16 +0200 From: Juergen Schoenwaelder To: tom petch CC: Andy Bierman , "netconf@ietf.org" Message-ID: <20190502094916.cot6vrlrpxog5pr5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , Andy Bierman , "netconf@ietf.org" References: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com> <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <20190501180553.3oidb7x275tgcdz6@anna.jacobs.jacobs-university.de> <03de01d500ca$68ad9da0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <03de01d500ca$68ad9da0$4001a8c0@gateway.2wire.net> 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: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 09:49:23 -0000 On Thu, May 02, 2019 at 09:39:09AM +0000, tom petch wrote: > > I wonder if IPv6 privacy addresses are similar, generated on the device > using random or pseudo-random input and which may also use device > specific data such as MAC address; and which may derive from the > device's public key. > > If the hardware is replaced, and the configuration is restored, should > the address stay the same or is it a breach of privacy to carry the > address across? I do not know but would guess the latter. > My understanding is that privacy addresses are temporary addresses and hence they exist in the datastore but not in regular configuration datastores. Since they are created and garbage collected automatically, there is most likely no need for a management interface for them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 2 03:09:47 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7064712032D for ; Thu, 2 May 2019 03:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thG_UbFnGAXA for ; Thu, 2 May 2019 03:09:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D82EE120329 for ; Thu, 2 May 2019 03:09:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9EF351AE0449; Thu, 2 May 2019 12:09:41 +0200 (CEST) Date: Thu, 02 May 2019 12:09:44 +0200 (CEST) Message-Id: <20190502.120944.41224357089248496.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: balazs.kovacs@ericsson.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 10:09:46 -0000 Hi, Kent Watsen wrote: > > > > I (still) object to this. Actions shouldn't create config. We > > already have generic protcol operations to do this. We go from a > > document-oriented configuration model towards a command-oriented > > model. Not good. In RESTCONF, the generic methods support things > > like ETags, which I suspect you don't want to replicate in this > > action? Will the action support all error-options of edit-config, > > like rollback-on-error? > > The specifics for how this could work would need to be defined. Given > that it is a special case, I think that we could constrain it heavily > and target simple solution. Depending how much text is required to > describe it, it might be good to define an extension statement that > could be placed on the actions. While an extension statement may seem > like it opens the gates for general use, we could further define the > extension statement as being something that MUST NOT be used when > general purpose operations are suitable such that, at least with the > IETF, it could only be used in extraordinary circumstances. Let's first agree on the issue about whether this action should exist at all. > > Some comments on the new text: > > > > In action generate-hidden-key, it should be stated that the public-key > > will be populated, and that the private-key will exist but report > > 'permanently-hidden'. > > Okay, but before making the edit, see comment below about lifetimes... > > > > > In action install-hidden-key, shouldn't both public-key and > > private-key be mandatory? Also state that the private-key will report > > 'permanently-hidden'. > > Indeed, fixed. > > > > In leaf private-key, the type binary part of the union doesn't have a > > description, and the description for the leaf itself says: > > > > A binary that contains the value of the private key. > > > > which is not quite correct. > > > > I think we should state that the enum 'permanently-hidden' is only > > reported in operational state. > > The 'type' statement doesn't have 'description' as a substatement, > but, point taken, two updates: > > In leaf private-key: > OLD: > A binary that contains the value of the private key. > NEW: > Either a binary that contains the value of the private key or, in > the case of a hidden key, the value 'permanently-hidden'. > > In enum permanently-hidden: > OLD: > The private key is inaccessible due to being protected by the > system (e.g., a cryptographic hardware module). > NEW: > The private key is inaccessible due to being protected by the > system (e.g., a cryptographic hardware module). Since hidden > keys are only ever reported in , the value > 'permanently-hidden' never appears in . Ok, but perhaps s//conventional configuration datastores/? > > The new descriptions say: > > > > [...] present only in > > and bound to the lifetime of the parent > > 'config true' node. > > > > Aren't all nodes bound to the lifetime of their parent? > > The action is invoked in a node that exists in and it > > creates a key. What does the statement tell me? > > This seems like something new (and maybe wrong) and hence needs to be > explained. This seems new because we are saying that the lifetime of > an operational value is tied to the lifetime of a configured value. > Normally we talk about how operational values exist on their own and > that, if one wants to override/extend them (e.g., associate a > certificate to the private key created by the manufacturer), > configuration would overlay the operational values. By extension, if > the configuration is removed, the operational values go back to their > original state (i.e., existing on their own). Here we're saying that, > if the configuration (for the parent node) is removed, the operational > values are removed as well. > > Note that this statement was added because Juergen asked about how > hidden keys could be removed/replaced. We iterated towards not > wanting to support the "replace" case But why? If an operator wants to replace, why should the list entry first be deleted and then created and then the key can be generated? This seems like a CLR to me. > and this seemed like an easy > way to handle the "remove" case. Another way to do this would be via > another action such as 'remove-hidden-key'. What do you think would > be best? Ok, I see. I think the text needs some clarification; make it more explicit. It needs to say that if a "permanently-hidden" private key exists in under a parent config true node and this parent node is deleted, the private key is supposed to be (MUST be?) deleted from the system as well. A remove-hidden-key action can be problematic b/c if you forget to call this action and then delete the config, presumably you have lingering keys in the system that you can't remove. /martin From nobody Thu May 2 05:21:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1EA12038D for ; Thu, 2 May 2019 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HuNPZEEzQkp for ; Thu, 2 May 2019 05:21:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B303B120110 for ; Thu, 2 May 2019 05:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4764; q=dns/txt; s=iport; t=1556799682; x=1558009282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7M7H1jpCrCtYgOan6aQ/gcz5336ZsoOZAj4hqSrcCi0=; b=CGLQVigeAaqEQ5m6O3OHCV3xVOJ70y/QK+7Zm5aUhIKCTCcKWxx3FJx2 U14M6DRT76hqp5kKnW+LWR1ASxmJyCOATDW4NvFvc7nZ13gcP4Y32QKi9 1w9piZYeK/y0eecMc4RH1LBfp8Y0YZdFt66DC06ttpy/dk2UaV5uN2uSb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABX38pc/4gNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghBpgQQoCoQGiByNB5hQgXsOAQEYC4Q?= =?us-ascii?q?ERgIXhhwjNAkOAQMBAQQBAQIBAm0cDIVKAQEBAwEBASEROgsMBAIBCA4CAQQ?= =?us-ascii?q?BAQECAiYCAgIlCxUICAIEAQ0FCIMbgXsPD61WgS+KLgaBCycBigiBQxeBQD+?= =?us-ascii?q?DbjU+gmEBAYFLgyCCWASNSYRrlG0JAoIJkjgjlTuDbYgnlGICERWBMB84gVZ?= =?us-ascii?q?wFTuCbIsShT9BMZM3gSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,421,1549929600"; d="scan'208";a="554320361" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 May 2019 12:21:20 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x42CLKYV023004 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 May 2019 12:21:20 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 2 May 2019 07:21:19 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 2 May 2019 07:21:19 -0500 From: "Rob Wilton (rwilton)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAL4+PiAAAVM54ADt02zAAAGzCgAAAQfJ4AABQvugADqhRSAAAgkE4AAKD/bgAABK6oAAAGYSwAABxXrgAA8jwUAAA4ykpA= Date: Thu, 2 May 2019 12:21:19 +0000 Message-ID: References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> In-Reply-To: <20190501.230622.158012882760210627.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 12:21:27 -0000 SGkgTWFydGluLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5ldGNv bmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1hcnRpbiBCam9ya2x1 bmQNCj4gU2VudDogMDEgTWF5IDIwMTkgMjI6MDYNCj4gVG86IGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZQ0KPiBDYzogbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W25ldGNvbmZdIGlldGYgY3J5cHRvIHR5cGVzIC0gcGVybWFuZW50bHkgaGlkZGVuDQo+IA0KPiBI aSwNCj4gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiBPbiBUdWUsIEFwciAzMCwgMjAxOSBhdCAwMjo0OToz MFBNICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+ID4gS2VudCBXYXRzZW4gPGtl bnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4gQ29ycmVjdCwgYXMg SSBkaWRu4oCZdCB0aGluayB0aGVyZSB3YXMgY29uc2Vuc3VzIHlldC4gIFBlcmhhcHMgdGhlcmUN Cj4gPiA+ID4gaXMgcm91Z2gtY29uc2Vuc3VzLCBhbmQgaXQgbWF5IGJlIHRoYXQgdGhlIG9ubHkg d2F5IHRvIGdhdWdlIHRoYXQNCj4gPiA+ID4gaXMgdG8gdHJ5IGFuZCBzZWUgaG93IG11Y2ggcHVz aCBiYWNrIHRoZXJlIGlzLg0KPiA+ID4gPg0KPiA+ID4gPiBPa2F5LCBzbyBob3cgYWJvdXQgdGhp cywgYmFzZWQgb24gdGhpcyB0aHJlYWQsIHRoZXJlIGFwcGVhcnMgdG8gYmUNCj4gPiA+ID4gc3Vw cG9ydCB0byBhZGQgYSBmbGFnIHRvIGNvbnRyb2wgaWYgYSBrZXkgc2hvdWxkIGJlIOKAnHBlcm1h bmVudGx5DQo+ID4gPiA+IGhpZGRlbuKAnSBvciBub3QsIGluIHdoaWNoIGNhc2UgY29uZmlndXJh dGlvbiBpcyBjcmVhdGVkLg0KPiA+ID4NCj4gPiA+IEkgKHN0aWxsKSBvYmplY3QgdG8gdGhpcy4g IEFjdGlvbnMgc2hvdWxkbid0IGNyZWF0ZSBjb25maWcuICBXZQ0KPiA+ID4gYWxyZWFkeSBoYXZl IGdlbmVyaWMgcHJvdGNvbCBvcGVyYXRpb25zIHRvIGRvIHRoaXMuICBXZSBnbyBmcm9tIGENCj4g PiA+IGRvY3VtZW50LW9yaWVudGVkIGNvbmZpZ3VyYXRpb24gbW9kZWwgdG93YXJkcyBhIGNvbW1h bmQtb3JpZW50ZWQNCj4gPiA+IG1vZGVsLiAgTm90IGdvb2QuICBJbiBSRVNUQ09ORiwgdGhlIGdl bmVyaWMgbWV0aG9kcyBzdXBwb3J0IHRoaW5ncw0KPiA+ID4gbGlrZSBFVGFncywgd2hpY2ggSSBz dXNwZWN0IHlvdSBkb24ndCB3YW50IHRvIHJlcGxpY2F0ZSBpbiB0aGlzDQo+ID4gPiBhY3Rpb24/ ICAgV2lsbCB0aGUgYWN0aW9uIHN1cHBvcnQgYWxsIGVycm9yLW9wdGlvbnMgb2YgZWRpdC1jb25m aWcsDQo+ID4gPiBsaWtlIHJvbGxiYWNrLW9uLWVycm9yPw0KPiA+ID4NCj4gPg0KPiA+IE1hcnRp biwNCj4gPg0KPiA+IGRvIHlvdSBoYXZlIGFueSBwcm9wb3NhbCBob3cgdG8gc3VwcG9ydCB0aGUg cmVxdWlyZW1lbnQgdG8gZ2VuZXJhdGUgYQ0KPiA+IGtleSBvbiB0aGUgZGV2aWNlIHRoYXQgaXMg d29ya2FibGUgd2l0aCBhIGRvY3VtZW50LW9yaWVudGVkDQo+ID4gY29uZmlndXJhdGlvbiBtb2Rl bD8gRG8geW91IHByb3Bvc2UgdGhhdCB0aGUgYWN0aW9uL3JwYyByZXR1cm5zIHRoZQ0KPiA+IHB1 YmxpYyBrZXkgaW5mb3JtYXRpb24gYXMgcmVzdWx0IGRhdGEgdGhhdCB0aGVuIG5lZWRzIHRvIGJl IHdyaXR0ZW4NCj4gPiBiYWNrIHRvIHRoZSBzZXJ2ZXIgYW5kIHNvbWVob3cgbWF0Y2hlZCB0byB0 aGUga2V5IHRoYXQgaXMgY2FjaGVkIG9uDQo+ID4gdGhlIGRldmljZT8gUGVyaGFwcyB5b3UgaGF2 ZSBvdGhlciBpZGVhcyBJIGNhbid0IHRoaW5rIG9mPw0KPiA+DQo+ID4gSSB0aGluayBJIHdvdWxk IGJlIGhhcHB5IHRvIG5vdCBoYXZlIHRoaXMgc3BlY2lhbCBoYWNrIGJ1dCB0aGVuIHdlDQo+ID4g bmVlZCBhIHdvcmthYmxlIGFsdGVybmF0aXZlLiBLZXkgZ2VuZXJhdGlvbiBvbiBkZXZpY2VzIGlz IHNvbWV0aGluZw0KPiA+IHRoYXQgaXMgYmVpbmcgdXNlZCAtIGFuZCBtYXkgYmUgZXZlbiBtb3Jl IHVzZWQgaW4gdGhlIGZ1dHVyZSB0aGUgbW9yZQ0KPiA+IHdlIGdldCBzcGVjaWFsIGhhcmR3YXJl IHN1cHBvcnQgZm9yIHN0b3Jpbmcga2V5cy4NCj4gDQo+IFNvIHRoZSBjdXJyZW50IGRyYWZ0IHN1 cHBvcnRzIHR3byB1c2UgY2FzZXM6DQo+IA0KPiAgIDEuICBUaGUgY2xpZW50IGNvbmZpZ3VyZXMg dGhlIHByaXZhdGUgYW5kIHB1YmxpYyBrZXlzIGV4cGxpY2l0bHkNCj4gICAgICAgKHNpbXBsZSBj YXNlKS4gIEJvdGgga2V5cyBhcmUgYXZhaWxpYmxlIGluIHRoZSBjb25maWcgYW5kDQo+ICAgICAg IG9wZXJhaW9uYWwgc3RhdGUuDQo+IA0KPiAgIDIuICBUaGUgY2xpZW50IGFza3MgdGhlIGRldmlj ZSB0byBnZW5lcmF0ZSBhICJoaWRkZW4iIGtleSB3aGljaCBtYXkNCj4gICAgICAgYmUgYSBrZXkg aW4gc3BlY2lhbCBUUE0gaGFyZHdhcmUuDQo+IA0KPiBGb3IgMiwgdGhlIGNsaWVudCBjb25maWd1 cmVzIHRoZSBuYW1lIG9mIHRoZSBrZXkgKGluIDxydW5uaW5nPikuICBUaGVuIHRoZSBjbGllbnQN Cj4gaW52b2tlcyB0aGUgYWN0aW9uIChpbiA8b3BlcmF0aW9uYWw+KS4gIFRoZSBkZXZpY2UgZ2Vu ZXJhdGVzIGEgbmV3IGtleSBwYWlyDQo+IChwZXJoYXBzIGluIHRwbS1odykuICBJbiA8b3BlcmF0 aW9uYWw+LCB0aGUgcHVibGljIGtleSBpcyBub3cgdmlzaWJsZSBhbmQgdGhlDQo+IHByaXZhdGUg a2V5IGhhcyB0aGUgc3BlY2lhbCBlbnVtICJwZXJtYW5lbnRseS1oaWRkZW4iLg0KDQpXaHkgaXMg YSBzZXBhcmF0ZSBhY3Rpb24gcmVxdWlyZWQgdG8gY3JlYXRlIHRoZSBrZXlzPyANCg0KV2h5IGlz IHRoZSBjb25maWd1cmF0aW9uIHRvIGdlbmVyYXRlIGEgaGlkZGVuIGtleSBub3Qgc3VmZmljaWVu dCBmb3IgdGhlIGRldmljZSB0byBhdXRvbWF0aWNhbGx5IGFsbG9jYXRlIGEga2V5IGluIHRoZSBU UE0gbW9kdWxlPw0KDQpUaGFua3MsDQpSb2INCg0KDQo+IA0KPiBBIGRldmljZSB0aGF0IGRvZXNu J3QgaGF2ZSBzcGVjaWFsIGhhcmR3YXJlIGNhbiBzdGlsbCBpbXBsZW1lbnQgMiwgYnV0IHN0b3Jl IHRoZQ0KPiBrZXlzIGluIHRoZSBmaWxlc3lzdGVtLiAgUGVyaGFwcyB0aGlzIGluZm8gbmVlZHMg dG8gYmUgdmlzaWJsZSBmb3IgdGhlIGNsaWVudCwgb3INCj4gZXZlbiBjb250cm9sbGVkIGJ5IHRo ZSBjbGllbnQuDQo+IA0KPiBXaGF0IEkgb2JqZWN0IHRvIGlzIGEgdGhpcmQgdXNlIGNhc2UsIHdo ZXJlIHRoZSBhY3Rpb24gd291bGQgbW9kaWZ5IHRoZSBjb25maWcNCj4gd2l0aCB0aGUgZ2VuZXJh dGVkIGtleXMuDQo+IA0KPiANCj4gL21hcnRpbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiBuZXRjb25m QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0K From nobody Thu May 2 05:24:48 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 834DC12035C; Thu, 2 May 2019 05:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 05:24:46 -0700 Archived-At: Subject: [netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 12:24:47 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- My focus when reviewing this document was from a perspective of how to handle overload. I have a hard time understanding how this will actually work, especially in a fashion that preservers goodput and ensure what is considered the most important subscriptions are delivered. Not having good undertanding into netconf and restconf don't hesitate to call out likely missunderstanding by me and provide clarification and pointers. A) The QoS and priority sending mechanism discussed in 2.3 and furhter defined by the YANG model. I do want to raise the usage of the DSCP code point to a discuss. As the DSCP defines different PHB and relative priorities in the router queues a DSCP value does not provide the publisher any information about priority. I get the feeling from the text that this may be intended. If the only intention is to have the transport perform differential treatment in the network between the publisher and the receiver there are still more considerations are needed. First of all I think these sentence needs a total rewrite: If the publisher supports the "dscp" feature, then a subscription with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP marking being placed within the IP header of any resulting notification messages and subscription state change notifications. Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value. I think one need to put a requriement on the transport to use a transport that utilize the DSCP marking on its traffic. Which for the current set of connection oriented transport protocols, TCP, SCTP, and QUIC all currently only support using a single DSCP per connection. Implying multiple transport protocol connections using a particular transport to enable this mapping. A.2 Queuing model of a publisher. With the DSCP and the Weight and dependency model I think it is important to clarify the model of the queueing in the publisher. So is the intention that several subscriptions with different weights and possibly dependencies have their individual queues that goes into a scheduler? To avoid complex queue interactions on this level I think there need to be seperate scheduler instances per DSCP. I would also note that Dependency mechanism can't ensure that a dependent stream arrive at receiver after the identified dependency if they are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not even guarantee it within a single connection and same DSCP due to packet loss impact. To me this model and what relationship one need to consider here need to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication of just the importance of considering what is in the same dependency tree and what it means to have different weighting. To conclude I think this needs a model description and clearer definition and possibly requirements towards the transport. Espceially if you actually need an in-order delivery requirement? B. The unpredictability of the circuit breaker overload mechanism. My description of the overload handling in this document is that it is a circuit breaker based mechanism that can blow a fuse on subscriptions that it fails to honor in overload situations. What worries me deply is the total unpredictability of this mechanism. First, is it the intention to derive what subscriptions are least important from the DSCP, weighting and Dependency parameters? If it is, I think that may be a misstake as priority on what subscriptions are most important to retain are not necessarily reflected in their QoS parameters. Secondly, what are the values when a subscription are considered to be to heavy or not be handled accordingly. Are there any parameter sets that actually describe what SLA the subscriber expect that can be converted into timeout timers or buffer depth thresholds to indicate that publisher side isn't delivering these in time? Third, I what I understand there are no any additional back pressure mechanism between the receiver and the publisher than the transport protocols flow control? So a receiver that is not keeping up processing the data it process will not read out the data out of the flow controlled buffers in the receiver and thus prevent the publisher to write to the transport conncetion, thus causing the publisher to eventually trigger a suspension due to its queue build up? To my understanding the current mechanism places all subscriptions on the same importance and with the same SLA. Thus likely causing short term overload situations to cause subscription suspensions in random subscriptions. Is the WG fine with this type of randomness occuring and expecting that normally there will be such amount of overprovisioning that being able to indicate priority and SLA are overkill? At a minimal a change of this sentence in Section 2.5.1 is needed: This could be for reasons of an unexpected but sustained increase in an event stream's event records, degraded CPU capacity, a more complex referenced filter, or other higher priority subscriptions which have usurped resources. As it states that subscriptions has priorities without reference to a mechanism that provides that priority. C. 2.4.5. Killing a Dynamic Subscription The "kill-subscription" operation permits an operator to end a dynamic subscription which is not associated with the transport session used for the RPC. A publisher MUST terminate any dynamic subscription identified by the "id" parameter in the RPC request, if such a subscription exists. Can someone please clarify the use case for this functionality. To my understanding it allows another receiver given authority to kill the subscription being delivered to another receiver. Based on the otherwise rather strict that all manipulations of dynamic subscriptions happens from the transport session context that established it I want to better understand the use case it appears out place. D. The Requirements on a transport supporting Configured Subscriptions Reading through Section 2.5 I arrived at a number of questions. I tried to understand what the requirements are for the transport that supports Configured Subscriptions. I did note that neither draft-ietf-netconf-restconf-notif-13 nor draft-ietf-netconf-netconf-event-notifications-17 supports configured subscriptions. Thus, there appear no template for a solution either, or does there exist another document that is being worked on defining such a transport? Questions that arose for me related to Configured Susbription Transport where the following: 1. Can Transport Session be initiated in both direction. RFC 8071 provides a solution for Publisher to Receiver initiation. It is unclear if all parts are in place to have a receiver to publisher initiated transport to be bound to the subscription. 2. What is "name" really? It appears to be defined as an empty container. Despite that it appears to have requirements on being both a security identity as well as network address. 3. In Figure 9, which is stated to be for the receiver. What information does the receiver use to determine the transition (d)? And what does it do in this step. Related to Discuss part B). 4. RFC 8071 appears to lack any considerations for how often and how many times it attempts to connect to the receiver. So applying that mechanism appears to require some usage guidance to avoid causing overload situations or DoS potential by misconfiguring network devices with this soltution to dial out frequently to a target. As the transport solution requirements are not detail it is actually hard to determine if there are short comings in the description in Section 2.5 and the corresponding YANG model. Is it an reasonable request to document these requirements? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 2.3: DSCP domains I think the text could benefit from pointing out that the subscriber actually needs to know what the DSCP values represents in the diffserv domain of the publisher. As these could be different, they also create an interesting problems for transports of how they establish a transport connection that uses a particular DSCP, as the receiver if initiating need to know the local DSCP value that corresponds to the behavior in the publisher's domain. 2. In general I think there are more than one description that are fuzzy about if it describes a publisher or receiver action/requirement. From nobody Thu May 2 09:19:32 2019 Return-Path: <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDACF120426 for ; Thu, 2 May 2019 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TR-f8fVLInz8 for ; Thu, 2 May 2019 09:19:28 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C655712042C for ; Thu, 2 May 2019 09:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556813962; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=YDuhKhbVclgFuGQ1KgACexAIbE4qAy+47nw1yb31iU8=; b=VVRxDMq38jPx1atjWKQo/OQI2ur3GRZ0+ZGRyASVxLpKasGgTHAUHLosJvUzeWUb CtcQP4ZSaRUVa3L9kAYJajWOLkbCVq00m8F3xtWI+cTh8nhldrkY5nw5BMlbXnqqADr c+BJe2qPVP7z+xZaqq7VDAiS+SgD+CRDeyuKyAzA= From: Kent Watsen Message-ID: <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_161F4D0A-F3F5-4399-8ABB-A7DA6BF8DA84" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 2 May 2019 16:19:22 +0000 In-Reply-To: <20190502.120944.41224357089248496.mbj@tail-f.com> Cc: balazs.kovacs@ericsson.com, "netconf@ietf.org" To: Martin Bjorklund References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <20190502.120944.41224357089248496.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 16:19:31 -0000 --Apple-Mail=_161F4D0A-F3F5-4399-8ABB-A7DA6BF8DA84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> In enum permanently-hidden: >> OLD: >> The private key is inaccessible due to being protected by the >> system (e.g., a cryptographic hardware module). >> NEW: >> The private key is inaccessible due to being protected by the >> system (e.g., a cryptographic hardware module). Since hidden >> keys are only ever reported in , the value >> 'permanently-hidden' never appears in . >=20 > Ok, but perhaps s//conventional configuration datastores/? Fixed in my local copy. >> Note that this statement was added because Juergen asked about how >> hidden keys could be removed/replaced. We iterated towards not >> wanting to support the "replace" case >=20 > But why? If an operator wants to replace, why should the list entry > first be deleted and then created and then the key can be generated? > This seems like a CLR to me. = https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE = > Ok, I see. I think the text needs some clarification; make it more > explicit. It needs to say that if a "permanently-hidden" private key > exists in under a parent config true node and this > parent node is deleted, the private key is supposed to be (MUST be?) > deleted from the system as well. Added, with a MUST. > A remove-hidden-key action can be problematic b/c if you forget to > call this action and then delete the config, presumably you have > lingering keys in the system that you can't remove. I don't think this is true. Even if an asymmetric key only exists in = (i.e., the corresponding "config true" parent node is = deleted), it seems that a 'remove-hidden-key' could still remove it. In = fact, this is the most consistent thing, to have an 'action' act on = values in . Kent // contributor --Apple-Mail=_161F4D0A-F3F5-4399-8ABB-A7DA6BF8DA84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
In enum = permanently-hidden:
 OLD:
=       The private key is inaccessible due = to being protected by the
=       system (e.g., a cryptographic = hardware module).
 NEW:
=       The private key is inaccessible due = to being protected by the
=       system (e.g., a cryptographic = hardware module).  Since hidden
=       keys are only ever reported in = <operational>, the value
=       'permanently-hidden' never appears = in <intended>.

Ok, but = perhaps s/<intended>/conventional configuration datastores/?

Fixed = in my local copy.


Note that this = statement was added because Juergen asked about how
hidden = keys could be removed/replaced.  We iterated towards not
wanting to support the "replace" case

But why?  If an operator = wants to replace, why should the list entry
first be = deleted and then created and then the key can be generated?
This seems like a CLR to me.




Ok, I see.  I think the text needs some = clarification; make it more
explicit.  It needs to = say that if a "permanently-hidden" private key
exists in = <operational> under a parent config true node and this
parent node is deleted, the private key is supposed to be = (MUST be?)
deleted from the system as well.

Added, = with a MUST.


A = remove-hidden-key action can be problematic b/c if you forget to
call this action and then delete the config, presumably you = have
lingering keys in the system that you can't = remove.

I don't think this is true.  Even if an asymmetric key = only exists in <operational> (i.e., the corresponding "config = true" parent node is deleted), it seems that a 'remove-hidden-key' could = still remove it.  In fact, this is the most consistent thing, to = have an 'action' act on values in <operational>.


Kent // contributor

= --Apple-Mail=_161F4D0A-F3F5-4399-8ABB-A7DA6BF8DA84-- From nobody Thu May 2 09:59:16 2019 Return-Path: <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3291204AA for ; Thu, 2 May 2019 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cbE_xdzwz2MU for ; Thu, 2 May 2019 09:59:05 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6DB1204AC for ; Thu, 2 May 2019 09:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556816344; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=fT4xCwvPNWQSzjm0LSY/5ZYqK/lgJv+kSRnIuyImtRM=; b=mJ2cfweV5N28mIQVO0PBuPcAcOiHoNebSDbeLs9JphkSYqx/NGNSdU79/UihYUnP oykBy4viP+e0sWSBvnxH9hcma+fQ3DvT87Vow2qVfXBy3glgdbruLt+449Cuh476lW1 FXBk+o/rClNpZZTaonhTZmH8w6fCLjps8i3h9aik= 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: Date: Thu, 2 May 2019 16:59:04 +0000 Cc: Martin Bjorklund , Juergen Schoenwaelder , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@email.amazonses.com> References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 16:59:14 -0000 Hi Rob, > Why is a separate action required to create the keys?=20 >=20 > Why is the configuration to generate a hidden key not sufficient for = the device to automatically allocate a key in the TPM module? I seem to be failing with words.=20 Hopefully a picture will do the trick... THIS IS WHAT WE HAVE CURRENTLY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D | Client is okay with the | Client is = NOT okay with the | | private key being in config | private key = being in config | | w/ nacm:default-deny-all. | i.e., wants = "hidden" key. | | (doc model not impacted.) | (doc model = impacted!) | | (this col more important) | (this col = less important) | | | = | = -------------------------+-------------------------------+----------------= ---------------+ | | = | Client is okay with | | = | generating the private | can be used. | use = | key (not best practice) | | = | | | = | = -------------------------+-------------------------------+----------------= ---------------+ | | = | Client is NOT okay with | | = | generating the private | Currently no solution !!! | use = | key (best practice) | | = | | | = | = -------------------------+-------------------------------+----------------= ---------------+ PROPOSAL: move "hidden" from action names to an input parameter, and let = an action gen config = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Client is okay with the | Client is = NOT okay with the | | private key being in config | private key = being in config | | w/ nacm:default-deny-all. | i.e., wants = "hidden" key. | | (doc model not impacted.) | (doc model = impacted!) | | (this col more important) | (this col = less important) | | | = | = -------------------------+-------------------------------+----------------= ---------------+ | | = | Client is okay with | Either or | Use = with | generating the private | with input | input = "hidden". | key (not best practice) | NOT "hidden". | = | | | = | = -------------------------+-------------------------------+----------------= ---------------+ | | = | Client is NOT okay with | Use with | Use = with | generating the private | with input NOT "hidden". | with input = "hidden". | key (best practice) | | = | | | = | = -------------------------+-------------------------------+----------------= ---------------+ Other proposals welcomed. Kent // contributor From nobody Thu May 2 10:47:05 2019 Return-Path: <0100016a79a8090b-e7480d49-0ee2-45c6-89ca-c4bcd374aa80-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E51203AF for ; Thu, 2 May 2019 10:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFDeZFMIoifP for ; Thu, 2 May 2019 10:47:02 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E21B1204AB for ; Thu, 2 May 2019 10:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556819216; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=8dmZJU6daNIQc7OTigMtm57N7yTUHXLein1/cX3yfVM=; b=K54OWuBrkP42+LaWWTvKaxZOI+AN5eHYMgC4/CL7k5djQW8gAu+GVIB2Q7C6efU9 6wvFb+qxIlmfvekv3aO1rstqXl2do3Cot1bkDNBd4rg96xqn3RHkmCjb+sCPCitmTJj YRz0pK/6ymhzwfJCIx60e4Y0bd5pCkA8WnCJlfDU= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_8E9066A8-71E3-44D3-B439-E0D4BEF1B26C" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016a79a8090b-e7480d49-0ee2-45c6-89ca-c4bcd374aa80-000000@email.amazonses.com> Date: Thu, 2 May 2019 17:46:56 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] rename /ta:trust-anchors to /ts:truststore X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 17:47:05 -0000 --Apple-Mail=_8E9066A8-71E3-44D3-B439-E0D4BEF1B26C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One of the Change Log entries in Monday's update to the trust-anchor's = draft said this: o Added groupings 'local-or-truststore-certs-grouping' and 'local- or-truststore-host-keys-grouping', matching similar definitions in the keystore draft. Note new (and incomplete) "truststore" usage! Regarding renaming top-level container, I initially did this so that = these new grouping names made sense (i.e., they sound like they're = referring to a noun), but a little searching found lots of precedent. = For instance: 1. Truststore and Keystore Definitions = https://stackoverflow.com/questions/318441/truststore-and-keystore-definit= ions = 2. Trust Store vs Key Store - creating with keytool = https://stackoverflow.com/questions/6340918/trust-store-vs-key-store-creat= ing-with-keytool = 3. Difference between trustStore vs keyStore in Java SSL http://www.java67.com/2012/12/difference-between-truststore-vs.html = In my view, the above not only confirms that we should rename = "trust-anchors" to "truststore", but also that we did the right thing in = having separate models for keys and trust anchors. If no objection is raised, this name change will be in the next update = to the trust-anchors draft (note: the draft name itself will stay the = same). This update will likely not occur before the crypto-types = "hidden" key issue is resolved, so as to minimize the number of updates. Separately, there needs to be a discussion regarding these new = groupings, specifically if the SSL and TLS client/server drafts should = be updated to use them, to enable local-definition of trust anchors, = rather than only supporting references to /ta:trust-anchors (or now, I = guess, /ts:truststore). It would be great if someone wants to comment = on that now as well. PS: As mentioned in Prague, the goal is to move the three drafts = (crypto-types, keystore, and trust-anchors) to Last Call quickly, hence = the attention being given to them lately. Kent // contributor --Apple-Mail=_8E9066A8-71E3-44D3-B439-E0D4BEF1B26C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

One of the Change Log = entries in Monday's update to the trust-anchor's draft said = this:

  = o  Added groupings 'local-or-truststore-certs-grouping' and = 'local-
     or-truststore-host-keys-grouping'= , matching similar definitions in
     the keystore draft.  Note = new (and incomplete) "truststore" usage!


Regarding renaming top-level container, I = initially did this so that these new grouping names made sense (i.e., = they sound like they're referring to a noun), but a little = searching found lots of precedent. For instance:

  1. Truststore and Keystore = Definitions
     https://stackoverflow.com/questions/318441/truststore-and-keyst= ore-definitions

  2. Trust Store vs Key Store - creating = with keytool
     https://stackoverflow.com/questions/6340918/trust-store-vs-key-= store-creating-with-keytool

  3. Difference between trustStore vs = keyStore in Java SSL
     http://www.java67.com/2012/12/difference-between-truststore-vs.= html

In my view, the above not = only confirms that we should rename "trust-anchors" to "truststore", but = also that we did the right thing in having separate models for keys and = trust anchors.

If no objection is raised, = this name change will be in the next update to = the trust-anchors draft (note: the draft name itself will stay the = same).  This update will likely not occur before the crypto-types = "hidden" key issue is resolved, so as to minimize the number of = updates.


Separately, there needs to be a discussion = regarding these new groupings, specifically if the SSL and TLS = client/server drafts should be updated to use them, to = enable local-definition of trust anchors, rather than only = supporting references to /ta:trust-anchors (or now, I guess, = /ts:truststore).  It would be great if someone wants to comment on = that now as well.


PS: As mentioned in Prague, the goal is to move = the three drafts (crypto-types, keystore, and trust-anchors) to Last = Call quickly, hence the attention being given to them = lately.

Kent // = contributor

= --Apple-Mail=_8E9066A8-71E3-44D3-B439-E0D4BEF1B26C-- From nobody Thu May 2 11:11:28 2019 Return-Path: <0100016a79be5df2-196e176a-4ee6-4cd4-8289-e49ee2cb1c5b-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD80F120640; Thu, 2 May 2019 11:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTBztOfY1jbL; Thu, 2 May 2019 11:11:25 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DEE12064D; Thu, 2 May 2019 11:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556820680; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=GyF6aq2W1YV8BalVU0LugU0SL+91FdayIStrNSYB0xo=; b=NxAz+jRI9jc55qpLVYTNMXCDb2b5sv2NuMdgig9Cwtm7IqZ3Duz/rCd2tqCrHCIc etQORB9FPLNzSuUJP3u8DPD3Y5ls8b8atwfotxSURBRUfnHLSRA0iddQs5fBIZ1rfZc iC/KRvZLlph2FitLcTO/flulyC7R60s0VR8pF0rg= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_394C3CE6-E177-463C-AE3A-400DCB289BC3" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-ID: <0100016a79be5df2-196e176a-4ee6-4cd4-8289-e49ee2cb1c5b-000000@email.amazonses.com> Date: Thu, 2 May 2019 18:11:20 +0000 Cc: "netconf@ietf.org" To: draft-zhou-netconf-multi-stream-originators@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.02-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] teeing up adoption call on draft-zhou-netconf-multi-stream-originators X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 18:11:27 -0000 --Apple-Mail=_394C3CE6-E177-463C-AE3A-400DCB289BC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Authors, =46rom the minutes, the WG agrees that this is a problem worth solving, = but the current documented isn't quite right. Please update the draft = to: 1) focus on introducing a way to configure subscriptions such that any = "notif" draft can be used to send notifications out line cards. 1a) do not focus on any particular "notif" transport (at least not in = this draft) 1b) assume that the notif transports may be either UDP or TCP (more = likely TCP) 1c) assume that the notif transports may be encrypted or not encrypted 2) per Ignas's comment, explicitly state how transport congestion and = related aspects are or are not being taken into account. 2a) my opinion is that this draft sets up up the *potential* for a = problem (and should say so), but it is likely that the particular = "notif" transport used will matter greatly (e.g., unencrypted UDP is = less heavy than encrypted TCP). 2b) also my opinion, this draft is comparable to the = subscribed-notifications draft in this regard, so lifting text from = there should be possible. Since there is an overlap of authors on both = drafts, hopefully what's needed is well understood. An adoption call will proceed once the update is published addressing = the above. Kent (and Mahesh) // chairs --Apple-Mail=_394C3CE6-E177-463C-AE3A-400DCB289BC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Authors,

=46rom the minutes, the WG agrees that this is a problem = worth solving, but the current documented isn't quite right. =  Please update the draft to:

1) focus on introducing a way to = configure subscriptions such that any "notif" draft can be used to send = notifications out line cards.
1a) do not focus on = any particular "notif" transport (at least not in this draft)
1b) assume that the notif transports may be either UDP or TCP = (more likely TCP)
1c) assume that the notif = transports may be encrypted or not encrypted

2) per Ignas's comment, explicitly = state how transport congestion and related aspects are or are not being = taken into account.
2a) my opinion is that this = draft sets up up the *potential* for a problem (and should say so), but = it is likely that the particular "notif" transport used will matter = greatly (e.g., unencrypted UDP is less heavy than encrypted = TCP).
2b) also my opinion, this draft is comparable = to the subscribed-notifications draft in this regard, so lifting text = from there should be possible.  Since there is an overlap of = authors on both drafts, hopefully what's needed is well understood.

An = adoption call will proceed once the update is published addressing the = above.

Kent = (and Mahesh)  // chairs


= --Apple-Mail=_394C3CE6-E177-463C-AE3A-400DCB289BC3-- From nobody Thu May 2 23:10:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EE312006D for ; Thu, 2 May 2019 23:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X76EXo4xpRua for ; Thu, 2 May 2019 23:10:05 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10068.outbound.protection.outlook.com [40.107.1.68]) (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 5B389120059 for ; Thu, 2 May 2019 23:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZvU54oRMGYmsb1ZGM6GyDoQLsRq4+fNFRcEXG6eZ4Os=; b=WJnzJptgt5Clu5KHn/qSCL4nQaKJOim5lds44wFfBS6L2lQISB152RH4C3Bih/VS5+EnM5QKwExcoEd4pq3jYGY7qGCUE1EctsU6QeJ2aQoGZzOZgVo0gE0B+MOFAftd54EM/1mcI69i1Cu9mPqkNcTU7NrW9z6VlljI/Mglq1U= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB5568.eurprd07.prod.outlook.com (20.178.80.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.11; Fri, 3 May 2019 06:09:57 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::dc72:dfff:beb3:3b47]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::dc72:dfff:beb3:3b47%7]) with mapi id 15.20.1856.008; Fri, 3 May 2019 06:09:57 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Kent Watsen , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oAAICCMAAAQfJ4AABQvugADqJOIAAAiERYAAKAZY4AABZSwAAAGYSwAACr5PgABUQnkAAAzoyAAAHLnpkA== Date: Fri, 3 May 2019 06:09:57 +0000 Message-ID: References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <20190502.120944.41224357089248496.mbj@tail-f.com> <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@email.amazonses.com> In-Reply-To: <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [2a02:ab88:2cb8:5600:149b:bf3c:db30:aae6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47bde480-27fe-47c5-254e-08d6cf8df80c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5568; x-ms-traffictypediagnostic: VI1PR07MB5568: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(376002)(346002)(39860400002)(199004)(189003)(71200400001)(486006)(8936002)(4326008)(53936002)(6436002)(54896002)(6306002)(81156014)(81166006)(74316002)(71190400001)(8676002)(316002)(478600001)(9686003)(476003)(25786009)(5660300002)(7736002)(46003)(2906002)(606006)(236005)(11346002)(9326002)(86362001)(446003)(76176011)(110136005)(7696005)(55016002)(66476007)(66946007)(33656002)(6246003)(66574012)(53546011)(6506007)(14454004)(68736007)(45776006)(102836004)(14444005)(186003)(52536014)(6116002)(256004)(966005)(229853002)(73956011)(790700001)(99286004)(66556008)(64756008)(66446008)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5568; H:VI1PR07MB4735.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: XEyxCOJ7kpBY4tkUS3rF5tNqtpHdkqcxTvrMzMqZpi5ABUvfd5/Ux6RosJaq5+kvIc0kdSUlpXK1FZlAv9jhhUG0BOGMGaZJqz9/Xpb8SsGJEtq5rs+d9r6IB797OjKM5JAwRbVOM0q6OhUp2xcrd7qjlDomZalT7MWQ+FExYiEDUw0a/9MUSVldxuGTFFjMsqIMmyJkrTmk/A+L5UGJw8BzmViriJAJRxo3x2lbDCObEvohNCJxR4TKkagDFdzuuk/nOGHQyETGl5B8Ffb0/JxFq/Qzi1LI7aEeTpqbpuFRForMNhF8p8c2oR5tbq/p+dbupFlLt9TYJ/whCbZQGEBSZTKev8Ja1RMVtKLZUZQOnL8O0F3DBQnu5rjZ8xduo1HtJRjyAzBCLU9jASVovxBCOUGrmdx/1/nFzSbOH9w= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB473550063330EE25D65642E083350VI1PR07MB4735eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47bde480-27fe-47c5-254e-08d6cf8df80c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 06:09:57.7468 (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: VI1PR07MB5568 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 06:10:09 -0000 --_000_VI1PR07MB473550063330EE25D65642E083350VI1PR07MB4735eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, But why? If an operator wants to replace, why should the list entry first be deleted and then created and then the key can be generated? This seems like a CLR to me. https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE I might back off from this one. I guess mismatched key pairs can occur with= regular configuration case too, so it all depends on the operator to provi= de the right pair, and it should be the operator's decision to do a gracefu= l key switch by creating a new key instance or do an instant renewal on the= same instance. If the peer device does not have to be reconfigured, the re= newal on same instance could be a better choice. Br, Balazs From: Kent Watsen Sent: Thursday, May 2, 2019 6:19 PM To: Martin Bjorklund Cc: Bal=E1zs Kov=E1cs ; netconf@ietf.org Subject: Re: [netconf] ietf crypto types - permanently hidden In enum permanently-hidden: OLD: The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module). NEW: The private key is inaccessible due to being protected by the system (e.g., a cryptographic hardware module). Since hidden keys are only ever reported in , the value 'permanently-hidden' never appears in . Ok, but perhaps s//conventional configuration datastores/? Fixed in my local copy. Note that this statement was added because Juergen asked about how hidden keys could be removed/replaced. We iterated towards not wanting to support the "replace" case But why? If an operator wants to replace, why should the list entry first be deleted and then created and then the key can be generated? This seems like a CLR to me. https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE Ok, I see. I think the text needs some clarification; make it more explicit. It needs to say that if a "permanently-hidden" private key exists in under a parent config true node and this parent node is deleted, the private key is supposed to be (MUST be?) deleted from the system as well. Added, with a MUST. A remove-hidden-key action can be problematic b/c if you forget to call this action and then delete the config, presumably you have lingering keys in the system that you can't remove. I don't think this is true. Even if an asymmetric key only exists in (i.e., the corresponding "config true" parent node is deleted), it= seems that a 'remove-hidden-key' could still remove it. In fact, this is = the most consistent thing, to have an 'action' act on values in . Kent // contributor --_000_VI1PR07MB473550063330EE25D65642E083350VI1PR07MB4735eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

But why?  If an ope= rator wants to replace, why should the list entry
first be deleted and then created and then the key can be generated?
This seems like a CLR to me.

 

https://mailar= chive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE<= /p>

 

I might back off from this one. I guess mismatched k= ey pairs can occur with regular configuration case too, so it all depends o= n the operator to provide the right pair, and it should be the operatorR= 17;s decision to do a graceful key switch by creating a new key instance or do an instant renewal on the same instan= ce. If the peer device does not have to be reconfigured, the renewal on sam= e instance could be a better choice.

 

Br,

Balazs

 

From: Kent Watsen <kent+ietf@watsen.ne= t>
Sent: Thursday, May 2, 2019 6:19 PM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Bal=E1zs Kov=E1cs <balazs.kovacs@ericsson.com>; netconf@ie= tf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden

 

 

In enum permanently-hidden:
 OLD:
      The private key is inaccessible due to = being protected by the
      system (e.g., a cryptographic hardware = module).
 NEW:
      The private key is inaccessible due to = being protected by the
      system (e.g., a cryptographic hardware = module).  Since hidden
      keys are only ever reported in <oper= ational>, the value
      'permanently-hidden' never appears in &= lt;intended>.


Ok, but perhaps s/<intended>/conventional configuration datastores/?<= o:p>

 

Fixed in my local copy.

 

 

Note that this statement was added because Juergen a= sked about how
hidden keys could be removed/replaced.  We iterated towards not
wanting to support the "replace" case


But why?  If an operator wants to replace, why should the list entry first be deleted and then created and then the key can be generated?
This seems like a CLR to me.

 

 

 



Ok, I see.  I think the text needs some clarifi= cation; make it more
explicit.  It needs to say that if a "permanently-hidden" pr= ivate key
exists in <operational> under a parent config true node and this
parent node is deleted, the private key is supposed to be (MUST be?)
deleted from the system as well.

 

Added, with a MUST.

 



A remove-hidden-key action can be problematic b/c if= you forget to
call this action and then delete the config, presumably you have
lingering keys in the system that you can't remove.

 

I don't think this is true.  Even if an asymmet= ric key only exists in <operational> (i.e., the corresponding "c= onfig true" parent node is deleted), it seems that a 'remove-hidden-ke= y' could still remove it.  In fact, this is the most consistent thing, to have an 'action' act on values in <operational>.

 

 

Kent // contributor

 

--_000_VI1PR07MB473550063330EE25D65642E083350VI1PR07MB4735eurp_-- From nobody Thu May 2 23:48:06 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25D3120090 for ; Thu, 2 May 2019 23:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3n_QU5w_Wtu for ; Thu, 2 May 2019 23:48:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29846120044 for ; Thu, 2 May 2019 23:48:02 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 78B411AE0389; Fri, 3 May 2019 08:47:57 +0200 (CEST) Date: Fri, 03 May 2019 08:47:57 +0200 (CEST) Message-Id: <20190503.084757.791827158808672980.mbj@tail-f.com> To: rwilton@cisco.com Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 06:48:05 -0000 IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBN YXJ0aW4sDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbmV0 Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluIEJqb3Jr bHVuZA0KPiA+IFNlbnQ6IDAxIE1heSAyMDE5IDIyOjA2DQo+ID4gVG86IGouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZQ0KPiA+IENjOiBuZXRjb25mQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUmU6IFtuZXRjb25mXSBpZXRmIGNyeXB0byB0eXBlcyAtIHBlcm1hbmVudGx5IGhpZGRl bg0KPiA+IA0KPiA+IEhpLA0KPiA+IA0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiA+IE9uIFR1ZSwgQXBy IDMwLCAyMDE5IGF0IDAyOjQ5OjMwUE0gKzAyMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ ID4gPiA+IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBDb3JyZWN0LCBhcyBJIGRpZG7igJl0IHRoaW5rIHRoZXJlIHdhcyBjb25z ZW5zdXMgeWV0LiAgUGVyaGFwcyB0aGVyZQ0KPiA+ID4gPiA+IGlzIHJvdWdoLWNvbnNlbnN1cywg YW5kIGl0IG1heSBiZSB0aGF0IHRoZSBvbmx5IHdheSB0byBnYXVnZSB0aGF0DQo+ID4gPiA+ID4g aXMgdG8gdHJ5IGFuZCBzZWUgaG93IG11Y2ggcHVzaCBiYWNrIHRoZXJlIGlzLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gT2theSwgc28gaG93IGFib3V0IHRoaXMsIGJhc2VkIG9uIHRoaXMgdGhyZWFk LCB0aGVyZSBhcHBlYXJzIHRvIGJlDQo+ID4gPiA+ID4gc3VwcG9ydCB0byBhZGQgYSBmbGFnIHRv IGNvbnRyb2wgaWYgYSBrZXkgc2hvdWxkIGJlIOKAnHBlcm1hbmVudGx5DQo+ID4gPiA+ID4gaGlk ZGVu4oCdIG9yIG5vdCwgaW4gd2hpY2ggY2FzZSBjb25maWd1cmF0aW9uIGlzIGNyZWF0ZWQuDQo+ ID4gPiA+DQo+ID4gPiA+IEkgKHN0aWxsKSBvYmplY3QgdG8gdGhpcy4gIEFjdGlvbnMgc2hvdWxk bid0IGNyZWF0ZSBjb25maWcuICBXZQ0KPiA+ID4gPiBhbHJlYWR5IGhhdmUgZ2VuZXJpYyBwcm90 Y29sIG9wZXJhdGlvbnMgdG8gZG8gdGhpcy4gIFdlIGdvIGZyb20gYQ0KPiA+ID4gPiBkb2N1bWVu dC1vcmllbnRlZCBjb25maWd1cmF0aW9uIG1vZGVsIHRvd2FyZHMgYSBjb21tYW5kLW9yaWVudGVk DQo+ID4gPiA+IG1vZGVsLiAgTm90IGdvb2QuICBJbiBSRVNUQ09ORiwgdGhlIGdlbmVyaWMgbWV0 aG9kcyBzdXBwb3J0IHRoaW5ncw0KPiA+ID4gPiBsaWtlIEVUYWdzLCB3aGljaCBJIHN1c3BlY3Qg eW91IGRvbid0IHdhbnQgdG8gcmVwbGljYXRlIGluIHRoaXMNCj4gPiA+ID4gYWN0aW9uPyAgIFdp bGwgdGhlIGFjdGlvbiBzdXBwb3J0IGFsbCBlcnJvci1vcHRpb25zIG9mIGVkaXQtY29uZmlnLA0K PiA+ID4gPiBsaWtlIHJvbGxiYWNrLW9uLWVycm9yPw0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IE1h cnRpbiwNCj4gPiA+DQo+ID4gPiBkbyB5b3UgaGF2ZSBhbnkgcHJvcG9zYWwgaG93IHRvIHN1cHBv cnQgdGhlIHJlcXVpcmVtZW50IHRvIGdlbmVyYXRlIGENCj4gPiA+IGtleSBvbiB0aGUgZGV2aWNl IHRoYXQgaXMgd29ya2FibGUgd2l0aCBhIGRvY3VtZW50LW9yaWVudGVkDQo+ID4gPiBjb25maWd1 cmF0aW9uIG1vZGVsPyBEbyB5b3UgcHJvcG9zZSB0aGF0IHRoZSBhY3Rpb24vcnBjIHJldHVybnMg dGhlDQo+ID4gPiBwdWJsaWMga2V5IGluZm9ybWF0aW9uIGFzIHJlc3VsdCBkYXRhIHRoYXQgdGhl biBuZWVkcyB0byBiZSB3cml0dGVuDQo+ID4gPiBiYWNrIHRvIHRoZSBzZXJ2ZXIgYW5kIHNvbWVo b3cgbWF0Y2hlZCB0byB0aGUga2V5IHRoYXQgaXMgY2FjaGVkIG9uDQo+ID4gPiB0aGUgZGV2aWNl PyBQZXJoYXBzIHlvdSBoYXZlIG90aGVyIGlkZWFzIEkgY2FuJ3QgdGhpbmsgb2Y/DQo+ID4gPg0K PiA+ID4gSSB0aGluayBJIHdvdWxkIGJlIGhhcHB5IHRvIG5vdCBoYXZlIHRoaXMgc3BlY2lhbCBo YWNrIGJ1dCB0aGVuIHdlDQo+ID4gPiBuZWVkIGEgd29ya2FibGUgYWx0ZXJuYXRpdmUuIEtleSBn ZW5lcmF0aW9uIG9uIGRldmljZXMgaXMgc29tZXRoaW5nDQo+ID4gPiB0aGF0IGlzIGJlaW5nIHVz ZWQgLSBhbmQgbWF5IGJlIGV2ZW4gbW9yZSB1c2VkIGluIHRoZSBmdXR1cmUgdGhlIG1vcmUNCj4g PiA+IHdlIGdldCBzcGVjaWFsIGhhcmR3YXJlIHN1cHBvcnQgZm9yIHN0b3Jpbmcga2V5cy4NCj4g PiANCj4gPiBTbyB0aGUgY3VycmVudCBkcmFmdCBzdXBwb3J0cyB0d28gdXNlIGNhc2VzOg0KPiA+ IA0KPiA+ICAgMS4gIFRoZSBjbGllbnQgY29uZmlndXJlcyB0aGUgcHJpdmF0ZSBhbmQgcHVibGlj IGtleXMgZXhwbGljaXRseQ0KPiA+ICAgICAgIChzaW1wbGUgY2FzZSkuICBCb3RoIGtleXMgYXJl IGF2YWlsaWJsZSBpbiB0aGUgY29uZmlnIGFuZA0KPiA+ICAgICAgIG9wZXJhaW9uYWwgc3RhdGUu DQo+ID4gDQo+ID4gICAyLiAgVGhlIGNsaWVudCBhc2tzIHRoZSBkZXZpY2UgdG8gZ2VuZXJhdGUg YSAiaGlkZGVuIiBrZXkgd2hpY2ggbWF5DQo+ID4gICAgICAgYmUgYSBrZXkgaW4gc3BlY2lhbCBU UE0gaGFyZHdhcmUuDQo+ID4gDQo+ID4gRm9yIDIsIHRoZSBjbGllbnQgY29uZmlndXJlcyB0aGUg bmFtZSBvZiB0aGUga2V5IChpbiA8cnVubmluZz4pLiAgVGhlbg0KPiA+IHRoZSBjbGllbnQNCj4g PiBpbnZva2VzIHRoZSBhY3Rpb24gKGluIDxvcGVyYXRpb25hbD4pLiAgVGhlIGRldmljZSBnZW5l cmF0ZXMgYSBuZXcga2V5DQo+ID4gcGFpcg0KPiA+IChwZXJoYXBzIGluIHRwbS1odykuICBJbiA8 b3BlcmF0aW9uYWw+LCB0aGUgcHVibGljIGtleSBpcyBub3cgdmlzaWJsZQ0KPiA+IGFuZCB0aGUN Cj4gPiBwcml2YXRlIGtleSBoYXMgdGhlIHNwZWNpYWwgZW51bSAicGVybWFuZW50bHktaGlkZGVu Ii4NCj4gDQo+IFdoeSBpcyBhIHNlcGFyYXRlIGFjdGlvbiByZXF1aXJlZCB0byBjcmVhdGUgdGhl IGtleXM/IA0KPiANCj4gV2h5IGlzIHRoZSBjb25maWd1cmF0aW9uIHRvIGdlbmVyYXRlIGEgaGlk ZGVuIGtleSBub3Qgc3VmZmljaWVudCBmb3INCj4gdGhlIGRldmljZSB0byBhdXRvbWF0aWNhbGx5 IGFsbG9jYXRlIGEga2V5IGluIHRoZSBUUE0gbW9kdWxlPw0KDQpUaGlzIGlzIGEgdmVyeSBnb29k IHF1ZXN0aW9uLiAgV2h5IGRvbid0IHdlIGhhdmUgYWN0aW9ucyBmb3INCiJjcmVhdGUtaW50ZXJm YWNlJywgImNyZWF0ZS11c2VyIiBvciAiY3JlYXRlLWFjbCI/ICBJbiBhbGwgdGhlc2UgY2FzZXMN CndlIGhhdmUgY29uZmlnIHRoYXQgYSBkZXZpY2UgaW50ZXJuYWxseSBwYXJzZXMgYW5kIHRyYW5z bGF0ZXMgdG8NCnNvbWUgaW50ZXJuYWwgcHJvY2VkdXJlIChwZXJoYXBzIGlmY29uZmlnLCBhZGR1 c2VyLCBpcHRhYmxlcyBldGMpLg0KDQpJbiBhIHdheSwgdGhpcyBjYXNlIGlzIGRpZmZlcmVudCBi L2MgdGhlIGNsaWVudCBuZWVkcyBjb250cm9sIG9mDQoqd2hlbiogdGhlIGtleSBpcyBnZW5lcmF0 ZWQuICBXZSBjYW5ub3QgY29weSAmIHBhc3RlIHNvbWUgY29uZmlnIHRvDQphbm90aGVyIGRldmlj ZSBhbmQgZXhwZWN0IGl0IHRvIHdvcmsgZXhhY3RseSB0aGUgc2FtZS4gIE9UT0ggdGhhdA0KcHJv YmFibHkgaXMgdHJ1ZSBmb3Igb3RoZXIgdGhpbmdzIGFzIHdlbGw7IGlmIGEgdXNlciBoYXMgYmVl biBjcmVhdGVkDQppbiB0aGUgY29uZmlnIHRoZXJlIG1pZ2h0IGJlIGZpbGVzIG93bmVkIGJ5IHRo YXQgdXNlciBzdG9yZWQgaW4gdGhlDQpob21lIGRpcmVjdG9yeS4NCg0KQWxzbywgd2UgbWlnaHQg bmVlZCB0aGUgb3B0aW9uIHRvIHJlLWdlbmVyYXRlIHRoZSBrZXkgKGV2ZW4gdGhvdWdoIHRoZQ0K Y3VycmVudCB2ZXJzaW9uIGRvZXNuJ3Qgc3VwcG9ydCB0aGlzKS4gIEJ1dCAqdGhpcyogY291bGQg YmUgZG9uZSB3LyBhbg0KYWN0aW9uIChpZiB3ZSBuZWVkIHRvIHN1cHBvcnQgaXQpLg0KDQpXaGF0 IGRpZCBJIG1pc3M7IHdoYXQgbWFrZXMgdGhpcyBjYXNlIHNwZWNpYWwgc28gdGhhdCBpdCBjYW4n dCBiZQ0KaGFuZGxlZCBsaWtlIG90aGVyIGNvbmZpZz8NCg0KDQovbWFydGluDQoNCg== From nobody Thu May 2 23:50:03 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B119112006B for ; Thu, 2 May 2019 23:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FgSNZZQdhOWI for ; Thu, 2 May 2019 23:49:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7601120044 for ; Thu, 2 May 2019 23:49:59 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D74A41AE0389; Fri, 3 May 2019 08:49:58 +0200 (CEST) Date: Fri, 03 May 2019 08:49:58 +0200 (CEST) Message-Id: <20190503.084958.1871984073774502678.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: balazs.kovacs@ericsson.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@email.amazonses.com> References: <0100016a6f64a438-50e97747-d12b-429b-8147-8bf6ed82bdac-000000@email.amazonses.com> <20190502.120944.41224357089248496.mbj@tail-f.com> <0100016a7957dd62-0c25451b-3a69-4a08-b4e6-d7ad22e5227d-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 06:50:02 -0000 Kent Watsen wrote: > > >> In enum permanently-hidden: > >> OLD: > >> The private key is inaccessible due to being protected by the > >> system (e.g., a cryptographic hardware module). > >> NEW: > >> The private key is inaccessible due to being protected by the > >> system (e.g., a cryptographic hardware module). Since hidden > >> keys are only ever reported in , the value > >> 'permanently-hidden' never appears in . > > > > Ok, but perhaps s//conventional configuration datastores/? > > Fixed in my local copy. > > > >> Note that this statement was added because Juergen asked about how > >> hidden keys could be removed/replaced. We iterated towards not > >> wanting to support the "replace" case > > > > But why? If an operator wants to replace, why should the list entry > > first be deleted and then created and then the key can be generated? > > This seems like a CLR to me. > > https://mailarchive.ietf.org/arch/msg/netconf/ZwXll9BtAv61EvVXtFDLLzTkljE > > > > > > Ok, I see. I think the text needs some clarification; make it more > > explicit. It needs to say that if a "permanently-hidden" private key > > exists in under a parent config true node and this > > parent node is deleted, the private key is supposed to be (MUST be?) > > deleted from the system as well. > > Added, with a MUST. > > > > A remove-hidden-key action can be problematic b/c if you forget to > > call this action and then delete the config, presumably you have > > lingering keys in the system that you can't remove. > > I don't think this is true. Even if an asymmetric key only exists in > (i.e., the corresponding "config true" parent node is > deleted), it seems that a 'remove-hidden-key' could still remove it. > In fact, this is the most consistent thing, to have an 'action' act on > values in . You're right. If we have "create" action it makes sense to have a "delete" action. But see the mail from Rob W. Perhaps we shouldn't have these actions at all? /martin From nobody Fri May 3 00:08:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FF212006B for ; Fri, 3 May 2019 00:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZDg3zeZzhKz for ; Fri, 3 May 2019 00:08:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3B2120044 for ; Fri, 3 May 2019 00:08:11 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 98E021AE0389; Fri, 3 May 2019 09:08:09 +0200 (CEST) Date: Fri, 03 May 2019 09:08:09 +0200 (CEST) Message-Id: <20190503.090809.1872906124999950846.mbj@tail-f.com> To: kent@watsen.net Cc: rwilton@cisco.com, j.schoenwaelder@jacobs-university.de, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@email.amazonses.com> References: <20190501.230622.158012882760210627.mbj@tail-f.com> <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 07:08:14 -0000 Kent Watsen wrote: > Hi Rob, > > > Why is a separate action required to create the keys? > > > > Why is the configuration to generate a hidden key not sufficient for the device to automatically allocate a key in the TPM module? > > > I seem to be failing with words. > Hopefully a picture will do the trick... > > > > THIS IS WHAT WE HAVE CURRENTLY > ============================== > > | Client is okay with the | Client is NOT okay with the | > | private key being in config | private key being in config | > | w/ nacm:default-deny-all. | i.e., wants "hidden" key. | > | (doc model not impacted.) | (doc model impacted!) | > | (this col more important) | (this col less important) | > | | | I don't think the last column is less important. That's the TPM case, right? > -------------------------+-------------------------------+-------------------------------+ > | | | > Client is okay with | | | > generating the private | can be used. | use | > key (not best practice) | | | > | | | > -------------------------+-------------------------------+-------------------------------+ > | | | > Client is NOT okay with | | | > generating the private | Currently no solution !!! | use | > key (best practice) | | | > | | | > -------------------------+-------------------------------+-------------------------------+ For the "no solution" case, it means that the client doesn't want to write the private key, but it wants to read it. Why should it read it if it never writes it? The whole point would be to be able to re-generate the config on another device - but this would mean that the client would use to pass the key, and it would be in the upper left cell in table above. > PROPOSAL: move "hidden" from action names to an input parameter, and let an action gen config > ============================================================================================= > > | Client is okay with the | Client is NOT okay with the | > | private key being in config | private key being in config | > | w/ nacm:default-deny-all. | i.e., wants "hidden" key. | > | (doc model not impacted.) | (doc model impacted!) | > | (this col more important) | (this col less important) | > | | | > -------------------------+-------------------------------+-------------------------------+ > | | | > Client is okay with | Either or | Use with | > generating the private | with input | input "hidden". | > key (not best practice) | NOT "hidden". | | > | | | > -------------------------+-------------------------------+-------------------------------+ > | | | > Client is NOT okay with | Use with | Use with | > generating the private | with input NOT "hidden". | with input "hidden". | > key (best practice) | | | > | | | > -------------------------+-------------------------------+-------------------------------+ An option could perhaps be to let the "generate-key" with option "not-hidden" create the private key in (still with nacm:default-deny-all). To re-create the key on another device, the client would use install-key. /martin From nobody Fri May 3 00:20:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1B12006B for ; Fri, 3 May 2019 00:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYjxMFItJIqi for ; Fri, 3 May 2019 00:20:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06E89120044 for ; Fri, 3 May 2019 00:20:34 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id C97DC1AE0389 for ; Fri, 3 May 2019 09:20:32 +0200 (CEST) Date: Fri, 03 May 2019 09:20:32 +0200 (CEST) Message-Id: <20190503.092032.2009186244613537120.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netconf] ietf crypto types - identities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 07:20:36 -0000 Hi, It seems all sec* identities have the same description: identity secp192r1 { base asymmetric-key-algorithm; description "The ECDSA algorithm using a NIST P256 Curve."; reference "RFC 6090: Fundamental Elliptic Curve Cryptography Algorithms."; } This I assume should have been "NIST P191 Curve". Also, it wasn't clear to me by looking at the reference what this actually means. I had to google for "secp192r1", which lead me to RFC 5480 which defines the *curve* "secp192r1". So I wonder if the reference needs to be updated, and if the name of this identity is really correct? /martin From nobody Fri May 3 02:15:46 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126BE1200B8 for ; Fri, 3 May 2019 02:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Watw9ZB4ZnhM for ; Fri, 3 May 2019 02:15:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3490512006D for ; Fri, 3 May 2019 02:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9172; q=dns/txt; s=iport; t=1556874943; x=1558084543; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wkpi9IPT0SZqhaLt0Zd+sf6Ru9JymnIUReWAHEsJub0=; b=ArA2zp6sixBl6P+f9Cv5hNVnM2OxslSO6dSpojR91ks/UrgcVXPqjBh3 T4AfIVTSfaWJIwzzhtgdHBrmrlFUvAM1XM+f1bQTceGJfkIgZRgnV2v3I jPj7z/k6dQiKeHpXhu32zysEt6uTPilIe3t0D+cRg3q5EfgOmsfZvfWni g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADVBcxc/5ldJa1bCAIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFRBAEBAQEBCwGCEIFtKAqEBogcjQh+l1QUgWcOAQG?= =?us-ascii?q?EbQIXhh0jNAkOAQMBAQQBAQIBAm0ohUoBAQEDASMRRQwEAgEIDgIBBAEBAQI?= =?us-ascii?q?CEhQCAgIwFQgIAgQOBQgThQMPrimBL4o1gQsnAYoIgSYdF4FAP4ERgl01PoQ?= =?us-ascii?q?ZEwJeDII2glgEixCCPYRslHQJAoIJkjwjlUaDbp0TAhEVgTAfOIFWcBWDJ4I?= =?us-ascii?q?bF44fQTGQRoEigSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,425,1549929600"; d="scan'208";a="270874927" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2019 09:15:41 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x439FfS9013148 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 May 2019 09:15:41 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 May 2019 04:15:41 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 3 May 2019 04:15:40 -0500 From: "Rob Wilton (rwilton)" To: Martin Bjorklund CC: "j.schoenwaelder@jacobs-university.de" , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAL4+PiAAAVM54ADt02zAAAGzCgAAAQfJ4AABQvugADqhRSAAAgkE4AAKD/bgAABK6oAAAGYSwAABxXrgAA8jwUAAA4ykpAAOGfLgAAGk8Wg Date: Fri, 3 May 2019 09:15:40 +0000 Message-ID: <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <20190503.084757.791827158808672980.mbj@tail-f.com> In-Reply-To: <20190503.084757.791827158808672980.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 09:15:45 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIEJqb3JrbHVu ZCA8bWJqQHRhaWwtZi5jb20+DQo+IFNlbnQ6IDAzIE1heSAyMDE5IDA3OjQ4DQo+IFRvOiBSb2Ig V2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQo+IENjOiBqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU7IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtuZXRjb25mXSBpZXRmIGNyeXB0byB0eXBlcyAtIHBlcm1hbmVudGx5IGhpZGRlbg0KPiANCj4g IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiA+IEhp IE1hcnRpbiwNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy b206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1hcnRp bg0KPiA+ID4gQmpvcmtsdW5kDQo+ID4gPiBTZW50OiAwMSBNYXkgMjAxOSAyMjowNg0KPiA+ID4g VG86IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZQ0KPiA+ID4gQ2M6IG5ldGNv bmZAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlw ZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4NCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiBK dWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZT4gd3JvdGU6DQo+ID4gPiA+IE9uIFR1ZSwgQXByIDMwLCAyMDE5IGF0IDAyOjQ5OjMwUE0gKzAy MDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gPiA+ID4gS2VudCBXYXRzZW4gPGtlbnQr aWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBDb3JyZWN0 LCBhcyBJIGRpZG7igJl0IHRoaW5rIHRoZXJlIHdhcyBjb25zZW5zdXMgeWV0LiAgUGVyaGFwcw0K PiA+ID4gPiA+ID4gdGhlcmUgaXMgcm91Z2gtY29uc2Vuc3VzLCBhbmQgaXQgbWF5IGJlIHRoYXQg dGhlIG9ubHkgd2F5IHRvDQo+ID4gPiA+ID4gPiBnYXVnZSB0aGF0IGlzIHRvIHRyeSBhbmQgc2Vl IGhvdyBtdWNoIHB1c2ggYmFjayB0aGVyZSBpcy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBP a2F5LCBzbyBob3cgYWJvdXQgdGhpcywgYmFzZWQgb24gdGhpcyB0aHJlYWQsIHRoZXJlIGFwcGVh cnMNCj4gPiA+ID4gPiA+IHRvIGJlIHN1cHBvcnQgdG8gYWRkIGEgZmxhZyB0byBjb250cm9sIGlm IGEga2V5IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID4g4oCccGVybWFuZW50bHkgaGlkZGVu4oCdIG9y IG5vdCwgaW4gd2hpY2ggY2FzZSBjb25maWd1cmF0aW9uIGlzIGNyZWF0ZWQuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBJIChzdGlsbCkgb2JqZWN0IHRvIHRoaXMuICBBY3Rpb25zIHNob3VsZG4ndCBj cmVhdGUgY29uZmlnLiAgV2UNCj4gPiA+ID4gPiBhbHJlYWR5IGhhdmUgZ2VuZXJpYyBwcm90Y29s IG9wZXJhdGlvbnMgdG8gZG8gdGhpcy4gIFdlIGdvIGZyb20NCj4gPiA+ID4gPiBhIGRvY3VtZW50 LW9yaWVudGVkIGNvbmZpZ3VyYXRpb24gbW9kZWwgdG93YXJkcyBhDQo+ID4gPiA+ID4gY29tbWFu ZC1vcmllbnRlZCBtb2RlbC4gIE5vdCBnb29kLiAgSW4gUkVTVENPTkYsIHRoZSBnZW5lcmljDQo+ ID4gPiA+ID4gbWV0aG9kcyBzdXBwb3J0IHRoaW5ncyBsaWtlIEVUYWdzLCB3aGljaCBJIHN1c3Bl Y3QgeW91IGRvbid0IHdhbnQgdG8NCj4gcmVwbGljYXRlIGluIHRoaXMNCj4gPiA+ID4gPiBhY3Rp b24/ICAgV2lsbCB0aGUgYWN0aW9uIHN1cHBvcnQgYWxsIGVycm9yLW9wdGlvbnMgb2YgZWRpdC1j b25maWcsDQo+ID4gPiA+ID4gbGlrZSByb2xsYmFjay1vbi1lcnJvcj8NCj4gPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiBNYXJ0aW4sDQo+ID4gPiA+DQo+ID4gPiA+IGRvIHlvdSBoYXZlIGFueSBw cm9wb3NhbCBob3cgdG8gc3VwcG9ydCB0aGUgcmVxdWlyZW1lbnQgdG8NCj4gPiA+ID4gZ2VuZXJh dGUgYSBrZXkgb24gdGhlIGRldmljZSB0aGF0IGlzIHdvcmthYmxlIHdpdGggYQ0KPiA+ID4gPiBk b2N1bWVudC1vcmllbnRlZCBjb25maWd1cmF0aW9uIG1vZGVsPyBEbyB5b3UgcHJvcG9zZSB0aGF0 IHRoZQ0KPiA+ID4gPiBhY3Rpb24vcnBjIHJldHVybnMgdGhlIHB1YmxpYyBrZXkgaW5mb3JtYXRp b24gYXMgcmVzdWx0IGRhdGEgdGhhdA0KPiA+ID4gPiB0aGVuIG5lZWRzIHRvIGJlIHdyaXR0ZW4g YmFjayB0byB0aGUgc2VydmVyIGFuZCBzb21laG93IG1hdGNoZWQgdG8NCj4gPiA+ID4gdGhlIGtl eSB0aGF0IGlzIGNhY2hlZCBvbiB0aGUgZGV2aWNlPyBQZXJoYXBzIHlvdSBoYXZlIG90aGVyIGlk ZWFzIEkgY2FuJ3QNCj4gdGhpbmsgb2Y/DQo+ID4gPiA+DQo+ID4gPiA+IEkgdGhpbmsgSSB3b3Vs ZCBiZSBoYXBweSB0byBub3QgaGF2ZSB0aGlzIHNwZWNpYWwgaGFjayBidXQgdGhlbiB3ZQ0KPiA+ ID4gPiBuZWVkIGEgd29ya2FibGUgYWx0ZXJuYXRpdmUuIEtleSBnZW5lcmF0aW9uIG9uIGRldmlj ZXMgaXMNCj4gPiA+ID4gc29tZXRoaW5nIHRoYXQgaXMgYmVpbmcgdXNlZCAtIGFuZCBtYXkgYmUg ZXZlbiBtb3JlIHVzZWQgaW4gdGhlDQo+ID4gPiA+IGZ1dHVyZSB0aGUgbW9yZSB3ZSBnZXQgc3Bl Y2lhbCBoYXJkd2FyZSBzdXBwb3J0IGZvciBzdG9yaW5nIGtleXMuDQo+ID4gPg0KPiA+ID4gU28g dGhlIGN1cnJlbnQgZHJhZnQgc3VwcG9ydHMgdHdvIHVzZSBjYXNlczoNCj4gPiA+DQo+ID4gPiAg IDEuICBUaGUgY2xpZW50IGNvbmZpZ3VyZXMgdGhlIHByaXZhdGUgYW5kIHB1YmxpYyBrZXlzIGV4 cGxpY2l0bHkNCj4gPiA+ICAgICAgIChzaW1wbGUgY2FzZSkuICBCb3RoIGtleXMgYXJlIGF2YWls aWJsZSBpbiB0aGUgY29uZmlnIGFuZA0KPiA+ID4gICAgICAgb3BlcmFpb25hbCBzdGF0ZS4NCj4g PiA+DQo+ID4gPiAgIDIuICBUaGUgY2xpZW50IGFza3MgdGhlIGRldmljZSB0byBnZW5lcmF0ZSBh ICJoaWRkZW4iIGtleSB3aGljaCBtYXkNCj4gPiA+ICAgICAgIGJlIGEga2V5IGluIHNwZWNpYWwg VFBNIGhhcmR3YXJlLg0KPiA+ID4NCj4gPiA+IEZvciAyLCB0aGUgY2xpZW50IGNvbmZpZ3VyZXMg dGhlIG5hbWUgb2YgdGhlIGtleSAoaW4gPHJ1bm5pbmc+KS4NCj4gPiA+IFRoZW4gdGhlIGNsaWVu dCBpbnZva2VzIHRoZSBhY3Rpb24gKGluIDxvcGVyYXRpb25hbD4pLiAgVGhlIGRldmljZQ0KPiA+ ID4gZ2VuZXJhdGVzIGEgbmV3IGtleSBwYWlyIChwZXJoYXBzIGluIHRwbS1odykuICBJbiA8b3Bl cmF0aW9uYWw+LCB0aGUNCj4gPiA+IHB1YmxpYyBrZXkgaXMgbm93IHZpc2libGUgYW5kIHRoZSBw cml2YXRlIGtleSBoYXMgdGhlIHNwZWNpYWwgZW51bQ0KPiA+ID4gInBlcm1hbmVudGx5LWhpZGRl biIuDQo+ID4NCj4gPiBXaHkgaXMgYSBzZXBhcmF0ZSBhY3Rpb24gcmVxdWlyZWQgdG8gY3JlYXRl IHRoZSBrZXlzPw0KPiA+DQo+ID4gV2h5IGlzIHRoZSBjb25maWd1cmF0aW9uIHRvIGdlbmVyYXRl IGEgaGlkZGVuIGtleSBub3Qgc3VmZmljaWVudCBmb3INCj4gPiB0aGUgZGV2aWNlIHRvIGF1dG9t YXRpY2FsbHkgYWxsb2NhdGUgYSBrZXkgaW4gdGhlIFRQTSBtb2R1bGU/DQo+IA0KPiBUaGlzIGlz IGEgdmVyeSBnb29kIHF1ZXN0aW9uLiAgV2h5IGRvbid0IHdlIGhhdmUgYWN0aW9ucyBmb3IgImNy ZWF0ZS1pbnRlcmZhY2UnLA0KPiAiY3JlYXRlLXVzZXIiIG9yICJjcmVhdGUtYWNsIj8gIEluIGFs bCB0aGVzZSBjYXNlcyB3ZSBoYXZlIGNvbmZpZyB0aGF0IGEgZGV2aWNlDQo+IGludGVybmFsbHkg cGFyc2VzIGFuZCB0cmFuc2xhdGVzIHRvIHNvbWUgaW50ZXJuYWwgcHJvY2VkdXJlIChwZXJoYXBz IGlmY29uZmlnLA0KPiBhZGR1c2VyLCBpcHRhYmxlcyBldGMpLg0KDQpGb3IgbWUsIHRoZSBpZGVh bCBnb2FsIGlzIHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24gaXMgaW50ZW50IGJhc2VkLiAgSS5lLiBy YXRoZXIgdGhhbiB0ZWxsaW5nIHRoZSBkZXZpY2Ugd2hhdCBzZXF1ZW5jZSBvZiBzdGVwcyBpdCBz aG91bGQgcGVyZm9ybSwgaXQgaXMgdGVsbGluZyB0aGUgZGV2aWNlIHdoYXQgc3RhdGUgdGhlIGRl dmljZSBzaG91bGQgYmUgdHJ5aW5nIHRvIGdldCBpbnRvLg0KDQpTbyBmb3IgYW4gaW50ZXJmYWNl LCB0aGUgaW50ZW50IG9mIHRoZSBpbnRlcmZhY2UgY29uZmlndXJhdGlvbiBpcyAiSSB3YW50IGlu dGVyZmFjZSBYWFggdG8gZXhpc3Qgb24gdGhlIGRldmljZSwgYmUgZW5hYmxlZCwgaGF2ZSB0aGlz IElQdjQgYWRkcmVzcyBjb25maWd1cmVkIG9uIGl0Ii4gIEFzIGEgY2xpZW50LCBJIGRvbid0IGNh cmUgd2hhdCBpbnRlcm5hbCBzdGVwcyB0aGUgZGV2aWNlIG5lZWRzIHRvIHRha2UgdG8gcmVhY2gg dGhpcyBzdGF0ZSwgaWYgaXQgZ2V0cyB0byB0aGlzIGRlc2lyZWQgc3RhdGUuICBTaW1pbGFybHks IGlmIHNvbWV0aGluZyB0cmFuc2llbnRseSBnb2VzIHdyb25nIG9uIHRoZSBkZXZpY2UsIHRoZW4g aXQgc2hvdWxkIGFsd2F5cyB0cnkgdG8gcmVjb3ZlciB0b3dhcmRzIHRoZSBkZXNpcmVkIHN0YXRl IGV4cHJlc3NlZCBpbiB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbi4NCg0KSSB0aGluayB0aGF0 IHVzZXJzIGlzIGEgc2xpZ2h0bHkgb3J0aG9nb25hbCBpc3N1ZS4gIEkgdGhpbmsgdGhhdCB0aGUg ZXh0ZXJuYWwgcHJpbWFyeSBtYW5hZ2VhYmlsaXR5IGtleSBmb3IgdXNlcnMgc2hvdWxkIGJlIHVu aXF1ZSB1c2VybmFtZXMuICBDZXJ0YWlubHksIHdoZW5ldmVyIEkgbG9nIGludG8gYW55IG1hY2hp bmUgaXQgaXMgbXkgdXNlcm5hbWUgdGhhdCBJIHVzZSB0byBpZGVudGlmeSBteXNlbGYuICBXaGVu IEkgbG9vayBmb2xrcyB1cCBpbiB0aGUgZGlyZWN0b3J5IEkgZG8gaXQgdmlhIHRoZWlyIG5hbWUs IG5vdCB0aGVpciB1c2VyaWQuICBJbiBzb21lIGNhc2VzLCBpdCBtaWdodCBiZSBkZXNpcmFibGUg dG8gdXNlIHRoZSBzYW1lIHVzZXJpZCBhY3Jvc3MgbXVsdGlwbGUgbWFjaGluZXMuICBUaGlzIGNh biBiZSBhY2hpZXZlZCBieSBoYXZpbmcgZXh0cmEgb3B0aW9uYWwgY29uZmlndXJhdGlvbiB0byBl eHByZXNzIHRoaXMuICBPdGhlcndpc2UsIEkgdGhpbmsgdGhhdCB1c2VyaWRzIHNob3VsZCBwcmlt YXJpbHkgYmUgdHJlYXRlZCBhcyBpbnRlcm5hbCB1c2VyIGlkZW50aWZpZXJzIHRoYXQgbmVlZCB0 byBwZXJzaXN0ZWQgYWxvbmcgd2l0aCBhbnkgZmlsZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSB1c2Vy Lg0KDQo+IA0KPiBJbiBhIHdheSwgdGhpcyBjYXNlIGlzIGRpZmZlcmVudCBiL2MgdGhlIGNsaWVu dCBuZWVkcyBjb250cm9sIG9mDQo+ICp3aGVuKiB0aGUga2V5IGlzIGdlbmVyYXRlZC4gIFdlIGNh bm5vdCBjb3B5ICYgcGFzdGUgc29tZSBjb25maWcgdG8gYW5vdGhlcg0KPiBkZXZpY2UgYW5kIGV4 cGVjdCBpdCB0byB3b3JrIGV4YWN0bHkgdGhlIHNhbWUuICBPVE9IIHRoYXQgcHJvYmFibHkgaXMg dHJ1ZSBmb3INCj4gb3RoZXIgdGhpbmdzIGFzIHdlbGw7IGlmIGEgdXNlciBoYXMgYmVlbiBjcmVh dGVkIGluIHRoZSBjb25maWcgdGhlcmUgbWlnaHQgYmUgZmlsZXMNCj4gb3duZWQgYnkgdGhhdCB1 c2VyIHN0b3JlZCBpbiB0aGUgaG9tZSBkaXJlY3RvcnkuDQo+IA0KPiBBbHNvLCB3ZSBtaWdodCBu ZWVkIHRoZSBvcHRpb24gdG8gcmUtZ2VuZXJhdGUgdGhlIGtleSAoZXZlbiB0aG91Z2ggdGhlIGN1 cnJlbnQNCj4gdmVyc2lvbiBkb2Vzbid0IHN1cHBvcnQgdGhpcykuICBCdXQgKnRoaXMqIGNvdWxk IGJlIGRvbmUgdy8gYW4gYWN0aW9uIChpZiB3ZSBuZWVkDQo+IHRvIHN1cHBvcnQgaXQpLg0KDQpF eGFjdGx5LiAgVXNpbmcgYW4gYWN0aW9uIHRvIHJlZ2VuZXJhdGUgYW4gaW50ZXJuYWxseSBtYW5h Z2VkIGtleSBpcyBmaW5lLiAgVGhpcyBpcyBlcXVpdmFsZW50IHRvIGFuIGFjdGlvbiB0byByZWJv b3QgYSBsaW5lY2FyZCBvciBjbGVhciBzb21lIHN0YXRpc3RpY3MuICBUaGlzIGhhc24ndCBjaGFu Z2VkIHRoZSBpbnRlbnQgb2Ygd2hhdCB0aGUgZGVzaXJlZCBzdGF0ZSB0aGUgc3lzdGVtIHNob3Vs ZCBiZSBpbi4NCg0KVGhlIGFsdGVybmF0aXZlIHRvIHRoZSBhY3Rpb24gd291bGQgYmUgdG8gcmVt b3ZlIHRoZSBjb25maWcsIHdhaXQgdW50aWwgdGhlIGRldmljZSBoYXMgY29uZmlybWVkIHRoYXQg dGhlIGtleSBpcyByZW1vdmVkIChpbiBvcGVyYXRpb25hbCksIGFuZCB0aGVuIGNvbmZpZ3VyZSBp dCBhZ2Fpbi4NCg0KDQo+IA0KPiBXaGF0IGRpZCBJIG1pc3M7IHdoYXQgbWFrZXMgdGhpcyBjYXNl IHNwZWNpYWwgc28gdGhhdCBpdCBjYW4ndCBiZSBoYW5kbGVkIGxpa2UNCj4gb3RoZXIgY29uZmln Pw0KDQpGb3IgbWUsIEkgdGhpbmsgdGhhdCB0aGUgc3BlY2lhbCBjYXNlcyBhcmU6DQogKGkpIFRo ZSBhYmlsaXR5IHRvIGZvcmNlIGEga2V5IHRvIGJlIHJlY3JlYXRlZCAoaS5lLiB0aGUgYWN0aW9u IGRlc2NyaWJlZCBhYm92ZSkNCiAoaWkpIFRoZSBhYmlsaXR5IHRvIHByb2dyYW0gYSBjbGllbnQg ZGVmaW5lZCBrZXkgcGFpciBpbiBhIHByaXZhdGUgd2F5IHRoYXQgaXMgbm90IHZpc2libGUgaW4g dGhlIGNvbmZpZ3VyYXRpb24uICBIYXZlIHdlIGNvbnNpZGVyZWQgYSBzb2x1dGlvbiB0aGF0IHB1 dHMgdGhlc2UgaW50byB0aGUgY29uZmlndXJhdGlvbiBidXQgaGFzIHRoZW0gZW5jcnlwdGVkIHdp dGggYSBkZXZpY2Ugc3BlY2lmaWMgcHVibGljL3ByaXZhdGUga2V5IHBhaXIuDQoNClRoYW5rcywN ClJvYg0KDQoNCj4gDQo+IA0KPiAvbWFydGluDQoNCg== From nobody Fri May 3 03:48:30 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846EE120026 for ; Fri, 3 May 2019 03:48:28 -0700 (PDT) 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, 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 IOBcJbkGM1nq for ; Fri, 3 May 2019 03:48:26 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20091.outbound.protection.outlook.com [40.107.2.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCF71200B1 for ; Fri, 3 May 2019 03:48:25 -0700 (PDT) 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=iwPvxj55rw0Sr88hWQ8sR/xxSbkcYAczg3tiiR++aKo=; b=KDDW6LUQYuGm1F3Ep3srolLhqtO/tOKFx8xkMR4fVdos9Imq45VQYHgOY8hIpcmCtxActnfASLmnFR03bb3tD+sMZaGlV6RcArWg0aJ9knnK2QMklFu5DtW45Wcqa+3Q4KukKYJTKJsPXrXXGipzuNM4ZgTuqgvSXyk0OsnLj54= Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5406.eurprd07.prod.outlook.com (20.178.14.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Fri, 3 May 2019 10:48:23 +0000 Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Fri, 3 May 2019 10:48:23 +0000 From: tom petch To: "rwilton@cisco.com" , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHVAZ25vWzSND4r/0+wKWIH0SB1HQ== Date: Fri, 3 May 2019 10:48:20 +0000 Message-ID: <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <20190503.084757.791827158808672980.mbj@tail-f.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0366.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::18) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 899478bd-9b4a-4f61-4e2e-08d6cfb4db5b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5406; x-ms-traffictypediagnostic: VI1PR07MB5406: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39860400002)(346002)(136003)(189003)(199004)(13464003)(2501003)(61296003)(66946007)(81166006)(81156014)(8676002)(7736002)(62236002)(6306002)(73956011)(305945005)(50226002)(8936002)(66446008)(64756008)(66556008)(26005)(256004)(14444005)(5024004)(186003)(66066001)(102836004)(486006)(6436002)(446003)(53546011)(6506007)(476003)(386003)(44736005)(6486002)(14454004)(86362001)(86152003)(66476007)(561944003)(71200400001)(71190400001)(5660300002)(1556002)(229853002)(53936002)(478600001)(14496001)(4720700003)(4326008)(6116002)(3846002)(44716002)(6512007)(9686003)(6246003)(966005)(25786009)(68736007)(99286004)(316002)(52116002)(76176011)(81686011)(2906002)(81816011)(84392002)(110136005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5406; H:VI1PR07MB3118.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4xj0HfKDc+WI38GLYDyBQs7RTWn1SOvfWjV+/3ocKysONXVmaiae7w2BkC3mr7dXyOEP0SFr74/j1Z6CQfrG42kd68VIKhIEDsOJXQiRJnNPJov8/a9PWvRiTO796QPzqRUbVm2PyxgM4FIkh/VRqwpjhGUEC9bLNczHZX1q55RApf7KyS2CUyZnMGpLJDliqNMevU3g6AGc1uNVGcWVUtMsrGRFZo43qtaPnPipCUfmelpt+TBk4FLY/hTl/PKXeQI/LubWLKNvh3bcYxYpQGU0chGScdGLCW7bbsRwfwBQLx6P43sUrY+1CMwdPndyQakf/U+N2WZu10MHPeo3dK6XFti+xZoqur4UEdMExi+xfliquPa8kNX8oPsKRpQ0ZzkC8LS0Dfra8QE64LcKxgQrfUNLmYt/t9Tsu3NFUOQ= Content-Type: text/plain; charset="utf-8" Content-ID: <742607CBE430154CB64606072BC1C925@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 899478bd-9b4a-4f61-4e2e-08d6cfb4db5b X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 10:48:20.3429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5406 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 10:48:29 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIk1hcnRpbiBCam9ya2x1bmQiIDxt YmpAdGFpbC1mLmNvbT4NClNlbnQ6IEZyaWRheSwgTWF5IDAzLCAyMDE5IDc6NDcgQU0NCg0KPiAi Um9iIFdpbHRvbiAocndpbHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gSGkg TWFydGluLA0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJv bTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGlu DQpCam9ya2x1bmQNCj4gPiA+IFNlbnQ6IDAxIE1heSAyMDE5IDIyOjA2DQo+ID4gPiBUbzogai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlDQo+ID4gPiBDYzogbmV0Y29uZkBpZXRm Lm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtuZXRjb25mXSBpZXRmIGNyeXB0byB0eXBlcyAtIHBl cm1hbmVudGx5IGhpZGRlbg0KPiA+ID4NCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0Kd3Jv dGU6DQo+ID4gPiA+IE9uIFR1ZSwgQXByIDMwLCAyMDE5IGF0IDAyOjQ5OjMwUE0gKzAyMDAsIE1h cnRpbiBCam9ya2x1bmQNCndyb3RlOg0KPiA+ID4gPiA+IEtlbnQgV2F0c2VuIDxrZW50K2lldGZA d2F0c2VuLm5ldD4gd3JvdGU6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ29ycmVjdCwgYXMg SSBkaWRu4oCZdCB0aGluayB0aGVyZSB3YXMgY29uc2Vuc3VzIHlldC4gIFBlcmhhcHMNCnRoZXJl DQo+ID4gPiA+ID4gPiBpcyByb3VnaC1jb25zZW5zdXMsIGFuZCBpdCBtYXkgYmUgdGhhdCB0aGUg b25seSB3YXkgdG8gZ2F1Z2UNCnRoYXQNCj4gPiA+ID4gPiA+IGlzIHRvIHRyeSBhbmQgc2VlIGhv dyBtdWNoIHB1c2ggYmFjayB0aGVyZSBpcy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPa2F5 LCBzbyBob3cgYWJvdXQgdGhpcywgYmFzZWQgb24gdGhpcyB0aHJlYWQsIHRoZXJlIGFwcGVhcnMN CnRvIGJlDQo+ID4gPiA+ID4gPiBzdXBwb3J0IHRvIGFkZCBhIGZsYWcgdG8gY29udHJvbCBpZiBh IGtleSBzaG91bGQgYmUNCuKAnHBlcm1hbmVudGx5DQo+ID4gPiA+ID4gPiBoaWRkZW7igJ0gb3Ig bm90LCBpbiB3aGljaCBjYXNlIGNvbmZpZ3VyYXRpb24gaXMgY3JlYXRlZC4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEkgKHN0aWxsKSBvYmplY3QgdG8gdGhpcy4gIEFjdGlvbnMgc2hvdWxkbid0IGNy ZWF0ZSBjb25maWcuDQpXZQ0KPiA+ID4gPiA+IGFscmVhZHkgaGF2ZSBnZW5lcmljIHByb3Rjb2wg b3BlcmF0aW9ucyB0byBkbyB0aGlzLiAgV2UgZ28NCmZyb20gYQ0KPiA+ID4gPiA+IGRvY3VtZW50 LW9yaWVudGVkIGNvbmZpZ3VyYXRpb24gbW9kZWwgdG93YXJkcyBhDQpjb21tYW5kLW9yaWVudGVk DQo+ID4gPiA+ID4gbW9kZWwuICBOb3QgZ29vZC4gIEluIFJFU1RDT05GLCB0aGUgZ2VuZXJpYyBt ZXRob2RzIHN1cHBvcnQNCnRoaW5ncw0KPiA+ID4gPiA+IGxpa2UgRVRhZ3MsIHdoaWNoIEkgc3Vz cGVjdCB5b3UgZG9uJ3Qgd2FudCB0byByZXBsaWNhdGUgaW4NCnRoaXMNCj4gPiA+ID4gPiBhY3Rp b24/ICAgV2lsbCB0aGUgYWN0aW9uIHN1cHBvcnQgYWxsIGVycm9yLW9wdGlvbnMgb2YNCmVkaXQt Y29uZmlnLA0KPiA+ID4gPiA+IGxpa2Ugcm9sbGJhY2stb24tZXJyb3I/DQo+ID4gPiA+ID4NCj4g PiA+ID4NCj4gPiA+ID4gTWFydGluLA0KPiA+ID4gPg0KPiA+ID4gPiBkbyB5b3UgaGF2ZSBhbnkg cHJvcG9zYWwgaG93IHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50IHRvDQpnZW5lcmF0ZSBhDQo+ ID4gPiA+IGtleSBvbiB0aGUgZGV2aWNlIHRoYXQgaXMgd29ya2FibGUgd2l0aCBhIGRvY3VtZW50 LW9yaWVudGVkDQo+ID4gPiA+IGNvbmZpZ3VyYXRpb24gbW9kZWw/IERvIHlvdSBwcm9wb3NlIHRo YXQgdGhlIGFjdGlvbi9ycGMgcmV0dXJucw0KdGhlDQo+ID4gPiA+IHB1YmxpYyBrZXkgaW5mb3Jt YXRpb24gYXMgcmVzdWx0IGRhdGEgdGhhdCB0aGVuIG5lZWRzIHRvIGJlDQp3cml0dGVuDQo+ID4g PiA+IGJhY2sgdG8gdGhlIHNlcnZlciBhbmQgc29tZWhvdyBtYXRjaGVkIHRvIHRoZSBrZXkgdGhh dCBpcyBjYWNoZWQNCm9uDQo+ID4gPiA+IHRoZSBkZXZpY2U/IFBlcmhhcHMgeW91IGhhdmUgb3Ro ZXIgaWRlYXMgSSBjYW4ndCB0aGluayBvZj8NCj4gPiA+ID4NCj4gPiA+ID4gSSB0aGluayBJIHdv dWxkIGJlIGhhcHB5IHRvIG5vdCBoYXZlIHRoaXMgc3BlY2lhbCBoYWNrIGJ1dCB0aGVuDQp3ZQ0K PiA+ID4gPiBuZWVkIGEgd29ya2FibGUgYWx0ZXJuYXRpdmUuIEtleSBnZW5lcmF0aW9uIG9uIGRl dmljZXMgaXMNCnNvbWV0aGluZw0KPiA+ID4gPiB0aGF0IGlzIGJlaW5nIHVzZWQgLSBhbmQgbWF5 IGJlIGV2ZW4gbW9yZSB1c2VkIGluIHRoZSBmdXR1cmUgdGhlDQptb3JlDQo+ID4gPiA+IHdlIGdl dCBzcGVjaWFsIGhhcmR3YXJlIHN1cHBvcnQgZm9yIHN0b3Jpbmcga2V5cy4NCj4gPiA+DQo+ID4g PiBTbyB0aGUgY3VycmVudCBkcmFmdCBzdXBwb3J0cyB0d28gdXNlIGNhc2VzOg0KPiA+ID4NCj4g PiA+ICAgMS4gIFRoZSBjbGllbnQgY29uZmlndXJlcyB0aGUgcHJpdmF0ZSBhbmQgcHVibGljIGtl eXMgZXhwbGljaXRseQ0KPiA+ID4gICAgICAgKHNpbXBsZSBjYXNlKS4gIEJvdGgga2V5cyBhcmUg YXZhaWxpYmxlIGluIHRoZSBjb25maWcgYW5kDQo+ID4gPiAgICAgICBvcGVyYWlvbmFsIHN0YXRl Lg0KPiA+ID4NCj4gPiA+ICAgMi4gIFRoZSBjbGllbnQgYXNrcyB0aGUgZGV2aWNlIHRvIGdlbmVy YXRlIGEgImhpZGRlbiIga2V5IHdoaWNoDQptYXkNCj4gPiA+ICAgICAgIGJlIGEga2V5IGluIHNw ZWNpYWwgVFBNIGhhcmR3YXJlLg0KPiA+ID4NCj4gPiA+IEZvciAyLCB0aGUgY2xpZW50IGNvbmZp Z3VyZXMgdGhlIG5hbWUgb2YgdGhlIGtleSAoaW4gPHJ1bm5pbmc+KS4NClRoZW4NCj4gPiA+IHRo ZSBjbGllbnQNCj4gPiA+IGludm9rZXMgdGhlIGFjdGlvbiAoaW4gPG9wZXJhdGlvbmFsPikuICBU aGUgZGV2aWNlIGdlbmVyYXRlcyBhIG5ldw0Ka2V5DQo+ID4gPiBwYWlyDQo+ID4gPiAocGVyaGFw cyBpbiB0cG0taHcpLiAgSW4gPG9wZXJhdGlvbmFsPiwgdGhlIHB1YmxpYyBrZXkgaXMgbm93DQp2 aXNpYmxlDQo+ID4gPiBhbmQgdGhlDQo+ID4gPiBwcml2YXRlIGtleSBoYXMgdGhlIHNwZWNpYWwg ZW51bSAicGVybWFuZW50bHktaGlkZGVuIi4NCj4gPg0KPiA+IFdoeSBpcyBhIHNlcGFyYXRlIGFj dGlvbiByZXF1aXJlZCB0byBjcmVhdGUgdGhlIGtleXM/DQo+ID4NCj4gPiBXaHkgaXMgdGhlIGNv bmZpZ3VyYXRpb24gdG8gZ2VuZXJhdGUgYSBoaWRkZW4ga2V5IG5vdCBzdWZmaWNpZW50IGZvcg0K PiA+IHRoZSBkZXZpY2UgdG8gYXV0b21hdGljYWxseSBhbGxvY2F0ZSBhIGtleSBpbiB0aGUgVFBN IG1vZHVsZT8NCj4NCj4gVGhpcyBpcyBhIHZlcnkgZ29vZCBxdWVzdGlvbi4gIFdoeSBkb24ndCB3 ZSBoYXZlIGFjdGlvbnMgZm9yDQo+ICJjcmVhdGUtaW50ZXJmYWNlJywgImNyZWF0ZS11c2VyIiBv ciAiY3JlYXRlLWFjbCI/ICBJbiBhbGwgdGhlc2UgY2FzZXMNCj4gd2UgaGF2ZSBjb25maWcgdGhh dCBhIGRldmljZSBpbnRlcm5hbGx5IHBhcnNlcyBhbmQgdHJhbnNsYXRlcyB0bw0KPiBzb21lIGlu dGVybmFsIHByb2NlZHVyZSAocGVyaGFwcyBpZmNvbmZpZywgYWRkdXNlciwgaXB0YWJsZXMgZXRj KS4NCj4NCj4gSW4gYSB3YXksIHRoaXMgY2FzZSBpcyBkaWZmZXJlbnQgYi9jIHRoZSBjbGllbnQg bmVlZHMgY29udHJvbCBvZg0KPiAqd2hlbiogdGhlIGtleSBpcyBnZW5lcmF0ZWQuICBXZSBjYW5u b3QgY29weSAmIHBhc3RlIHNvbWUgY29uZmlnIHRvDQo+IGFub3RoZXIgZGV2aWNlIGFuZCBleHBl Y3QgaXQgdG8gd29yayBleGFjdGx5IHRoZSBzYW1lLiAgT1RPSCB0aGF0DQo+IHByb2JhYmx5IGlz IHRydWUgZm9yIG90aGVyIHRoaW5ncyBhcyB3ZWxsOyBpZiBhIHVzZXIgaGFzIGJlZW4gY3JlYXRl ZA0KPiBpbiB0aGUgY29uZmlnIHRoZXJlIG1pZ2h0IGJlIGZpbGVzIG93bmVkIGJ5IHRoYXQgdXNl ciBzdG9yZWQgaW4gdGhlDQo+IGhvbWUgZGlyZWN0b3J5Lg0KPg0KPiBBbHNvLCB3ZSBtaWdodCBu ZWVkIHRoZSBvcHRpb24gdG8gcmUtZ2VuZXJhdGUgdGhlIGtleSAoZXZlbiB0aG91Z2ggdGhlDQo+ IGN1cnJlbnQgdmVyc2lvbiBkb2Vzbid0IHN1cHBvcnQgdGhpcykuICBCdXQgKnRoaXMqIGNvdWxk IGJlIGRvbmUgdy8gYW4NCj4gYWN0aW9uIChpZiB3ZSBuZWVkIHRvIHN1cHBvcnQgaXQpLg0KPg0K PiBXaGF0IGRpZCBJIG1pc3M7IHdoYXQgbWFrZXMgdGhpcyBjYXNlIHNwZWNpYWwgc28gdGhhdCBp dCBjYW4ndCBiZQ0KPiBoYW5kbGVkIGxpa2Ugb3RoZXIgY29uZmlnPw0KDQpJZiBJIGNvbmZpZ3Vy ZSBhbiBpbnRlcmZhY2UsIEkgYW0gcHJvdmlkaW5nIGF0IGxlYXN0IHBhcnQgb2YgdGhlDQppbmZv cm1hdGlvbiBhbmQgYW55dGhpbmcgdGhhdCB0aGUgZGV2aWNlIGdlbmVyYXRlcyAtIGludGVyZmFj ZSBuYW1lLA0KTVRVLCBwcml2YWN5IGFkZHJlc3MgLSBJIGNhbiB0aGVuIHNlZSBhbmQgbWF5IG9y IG1heSBub3QgYmUgYWJsZSB0bw0KY2hhbmdlLg0KDQpXaGVuIEkgZ2VuZXJhdGUgYSBrZXkgcGFp ciwgeWVzIEkgd2FudCB0byBzZWUgdGhlIHB1YmxpYyBrZXkgYnV0IEkgaGF2ZQ0Kbm8gaW50ZXJl c3QgaW4gdGhlIHByaXZhdGUga2V5LiAgSSB3YW50IHRoZSBkZXZpY2UsIGFuZCBpdCBpcyB0aGUg ZGV2aWNlDQpub3QgYW4gaW5kaXZpZHVhbCB1c2VyLCB0byBiZSBhYmxlIHRvIGRvIHRoaW5ncyB3 aXRoIHRoZSBwcml2YXRlIGtleSwNCm5vdGFibHkgdG8gZ2VuZXJhdGUgYSBjZXJ0aWZpY2F0ZSBm b3IgdGhlIGRldmljZTsgSSBub3cgc2VlDQpvcmdhbmlzYXRpb25zIHdoZXJlIGV2ZXJ5IGRldmlj ZSB0aGF0IGlzIGF0dGFjaGVkIHRvIHRoZSBuZXR3b3JrIG11c3QNCmhhdmUgaXRzIG93biBjZXJ0 aWZpY2F0ZSByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGRldmljZSBpcywgd2hvIG93bnMgaXQsDQp3 aG8gaXMgbG9nZ2VkIG9udG8gaXQgZXRjLg0KDQpTbyBnZW5lcmF0ZSBhIGtleSBwYWlyLCBrZWVw IHRoZSBwcml2YXRlIHByaXZhdGUsIHVzZSBpdCBmb3IgYQ0KY2VydGlmaWNhdGUsIGJ1dCBJIHdp bGwgbmV2ZXIgY2hhbmdlIGl0LCBkb24ndCB3YW50IHRvIGtub3cgaXQgaXMsIEkNCmp1c3Qgd2Fu dCBpdCBzZWN1cmVseSBoaWRkZW4gLSBhbmQgaXQgaXMgdW5saWtlbHkgdGhhdCB0aGUgbm90ZXBh ZCwNCnNtYXJ0UGhvbmUsIGxhcHRvcCBldGMgd2lsbCBoYXZlIGEgVFBNLg0KDQpUaGlzIGlzIHRo ZSBwb2xpY3kgb2YgdGhlIG1vc3Qgc2VjdXJpdHktY29uc2Npb3VzIG9yZ2FuaXNhdGlvbiBJIGtu b3csDQp0aGUgb25seSBvbmUgd2hvc2UgcGFzc3dvcmRzIHdvdWxkIG1lZXQgdGhlIGNyaXRlcmlh IGxhaWQgZG93biBpbiBSRkMsDQpidXQgaXQgaGFzIG9ubHkgYmVlbiBhcm91bmQgZm9yIGEgeWVh ciBvciBzbyBzbyBJIGV4cGVjdCBvdGhlcnMgd2lsbA0KZm9sbG93IHN1aXQuDQoNClRvbSBQZXRj aA0KDQo+IC9tYXJ0aW4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4NCg0K From nobody Fri May 3 04:00:22 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E924412004A for ; Fri, 3 May 2019 04:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbZavq2Mt2fK for ; Fri, 3 May 2019 04:00:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C49120026 for ; Fri, 3 May 2019 04:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9476; q=dns/txt; s=iport; t=1556881217; x=1558090817; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h//6vrokUNalXuBodcS2pkGemczR4RyhaHBP8UNZAIM=; b=kO0iN9BwYZTbMn+dOCl3bvNTzgAnAy8j/qAZ8jhQ5VJMCc7HKK9sYqQU 2E7OvzdhOHm1Xd32Nc6D/BTbZ/myliHDZKgUS7uBCTcLPHTRog1aahhEg AUHTKzb4h0QiE9H2EQ3/yz4UqRh6+jpzdyfyta6atE7A95dYOl87ZvrvT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAC1Hsxc/4MNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCEGmBBCgKhAaIHI0IfpdUgXsOAQEYC4QERgI?= =?us-ascii?q?XgW0jNAkOAQMBAQQBAQIBAm0cDIVKAQEBAwEBASEROgsMBAIBCBABBAEBAQI?= =?us-ascii?q?CJgICAiULFQgIAQEEAQ0FCBODCIF7Dw+uF4EvijOBCycBigiBQxeBQD+BEYJ?= =?us-ascii?q?dNT6CYQEBgUuDIIJYBIsQgj2EbJR0CQKCCZI8I5VGg26ILIsciUsCERWBMB8?= =?us-ascii?q?4gVZwFTuCbAmCEheDTIUUhT9BMZFogSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,425,1549929600"; d="scan'208";a="335294235" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2019 11:00:09 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x43B086n024123 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 May 2019 11:00:08 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 May 2019 06:00:07 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 3 May 2019 06:00:02 -0500 From: "Rob Wilton (rwilton)" To: tom petch , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAhrcNiw Date: Fri, 3 May 2019 11:00:02 +0000 Message-ID: <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> In-Reply-To: <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> 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.60] 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: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 11:00:21 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHRoZSBpbnNpZ2h0LiAgU29tZSBjb21tZW50cyBpbmxpbmUg Li4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdG9tIHBldGNoIDxp ZXRmY0BidGNvbm5lY3QuY29tPg0KPiBTZW50OiAwMyBNYXkgMjAxOSAxMTo0OA0KPiBUbzogUm9i IFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtDQo+IGYuY29tPg0KPiBDYzogbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW25ldGNvbmZdIGlldGYgY3J5cHRvIHR5cGVzIC0gcGVybWFuZW50bHkgaGlkZGVuDQo+IA0K PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJNYXJ0aW4gQmpvcmtsdW5k IiA8bWJqQHRhaWwtZi5jb20+DQo+IFNlbnQ6IEZyaWRheSwgTWF5IDAzLCAyMDE5IDc6NDcgQU0N Cj4gDQo+ID4gIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3Rl Og0KPiA+ID4gSGkgTWFydGluLA0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgTWFydGluDQo+IEJqb3JrbHVuZA0KPiA+ID4gPiBTZW50OiAwMSBNYXkgMjAx OSAyMjowNg0KPiA+ID4gPiBUbzogai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl DQo+ID4gPiA+IENjOiBuZXRjb25mQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0 Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4NCj4gPiA+ID4NCj4g PiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiB3cm90ZToNCj4gPiA+ID4gPiBPbiBU dWUsIEFwciAzMCwgMjAxOSBhdCAwMjo0OTozMFBNICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kDQo+ IHdyb3RlOg0KPiA+ID4gPiA+ID4gS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3 cm90ZToNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQ29ycmVjdCwgYXMgSSBkaWRu4oCZ dCB0aGluayB0aGVyZSB3YXMgY29uc2Vuc3VzIHlldC4gIFBlcmhhcHMNCj4gdGhlcmUNCj4gPiA+ ID4gPiA+ID4gaXMgcm91Z2gtY29uc2Vuc3VzLCBhbmQgaXQgbWF5IGJlIHRoYXQgdGhlIG9ubHkg d2F5IHRvIGdhdWdlDQo+IHRoYXQNCj4gPiA+ID4gPiA+ID4gaXMgdG8gdHJ5IGFuZCBzZWUgaG93 IG11Y2ggcHVzaCBiYWNrIHRoZXJlIGlzLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBP a2F5LCBzbyBob3cgYWJvdXQgdGhpcywgYmFzZWQgb24gdGhpcyB0aHJlYWQsIHRoZXJlIGFwcGVh cnMNCj4gdG8gYmUNCj4gPiA+ID4gPiA+ID4gc3VwcG9ydCB0byBhZGQgYSBmbGFnIHRvIGNvbnRy b2wgaWYgYSBrZXkgc2hvdWxkIGJlDQo+IOKAnHBlcm1hbmVudGx5DQo+ID4gPiA+ID4gPiA+IGhp ZGRlbuKAnSBvciBub3QsIGluIHdoaWNoIGNhc2UgY29uZmlndXJhdGlvbiBpcyBjcmVhdGVkLg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEkgKHN0aWxsKSBvYmplY3QgdG8gdGhpcy4gIEFjdGlv bnMgc2hvdWxkbid0IGNyZWF0ZSBjb25maWcuDQo+IFdlDQo+ID4gPiA+ID4gPiBhbHJlYWR5IGhh dmUgZ2VuZXJpYyBwcm90Y29sIG9wZXJhdGlvbnMgdG8gZG8gdGhpcy4gIFdlIGdvDQo+IGZyb20g YQ0KPiA+ID4gPiA+ID4gZG9jdW1lbnQtb3JpZW50ZWQgY29uZmlndXJhdGlvbiBtb2RlbCB0b3dh cmRzIGENCj4gY29tbWFuZC1vcmllbnRlZA0KPiA+ID4gPiA+ID4gbW9kZWwuICBOb3QgZ29vZC4g IEluIFJFU1RDT05GLCB0aGUgZ2VuZXJpYyBtZXRob2RzIHN1cHBvcnQNCj4gdGhpbmdzDQo+ID4g PiA+ID4gPiBsaWtlIEVUYWdzLCB3aGljaCBJIHN1c3BlY3QgeW91IGRvbid0IHdhbnQgdG8gcmVw bGljYXRlIGluDQo+IHRoaXMNCj4gPiA+ID4gPiA+IGFjdGlvbj8gICBXaWxsIHRoZSBhY3Rpb24g c3VwcG9ydCBhbGwgZXJyb3Itb3B0aW9ucyBvZg0KPiBlZGl0LWNvbmZpZywNCj4gPiA+ID4gPiA+ IGxpa2Ugcm9sbGJhY2stb24tZXJyb3I/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gTWFydGluLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gZG8geW91IGhhdmUgYW55IHByb3Bvc2Fs IGhvdyB0byBzdXBwb3J0IHRoZSByZXF1aXJlbWVudCB0bw0KPiBnZW5lcmF0ZSBhDQo+ID4gPiA+ ID4ga2V5IG9uIHRoZSBkZXZpY2UgdGhhdCBpcyB3b3JrYWJsZSB3aXRoIGEgZG9jdW1lbnQtb3Jp ZW50ZWQNCj4gPiA+ID4gPiBjb25maWd1cmF0aW9uIG1vZGVsPyBEbyB5b3UgcHJvcG9zZSB0aGF0 IHRoZSBhY3Rpb24vcnBjIHJldHVybnMNCj4gdGhlDQo+ID4gPiA+ID4gcHVibGljIGtleSBpbmZv cm1hdGlvbiBhcyByZXN1bHQgZGF0YSB0aGF0IHRoZW4gbmVlZHMgdG8gYmUNCj4gd3JpdHRlbg0K PiA+ID4gPiA+IGJhY2sgdG8gdGhlIHNlcnZlciBhbmQgc29tZWhvdyBtYXRjaGVkIHRvIHRoZSBr ZXkgdGhhdCBpcyBjYWNoZWQNCj4gb24NCj4gPiA+ID4gPiB0aGUgZGV2aWNlPyBQZXJoYXBzIHlv dSBoYXZlIG90aGVyIGlkZWFzIEkgY2FuJ3QgdGhpbmsgb2Y/DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBJIHRoaW5rIEkgd291bGQgYmUgaGFwcHkgdG8gbm90IGhhdmUgdGhpcyBzcGVjaWFsIGhhY2sg YnV0IHRoZW4NCj4gd2UNCj4gPiA+ID4gPiBuZWVkIGEgd29ya2FibGUgYWx0ZXJuYXRpdmUuIEtl eSBnZW5lcmF0aW9uIG9uIGRldmljZXMgaXMNCj4gc29tZXRoaW5nDQo+ID4gPiA+ID4gdGhhdCBp cyBiZWluZyB1c2VkIC0gYW5kIG1heSBiZSBldmVuIG1vcmUgdXNlZCBpbiB0aGUgZnV0dXJlIHRo ZQ0KPiBtb3JlDQo+ID4gPiA+ID4gd2UgZ2V0IHNwZWNpYWwgaGFyZHdhcmUgc3VwcG9ydCBmb3Ig c3RvcmluZyBrZXlzLg0KPiA+ID4gPg0KPiA+ID4gPiBTbyB0aGUgY3VycmVudCBkcmFmdCBzdXBw b3J0cyB0d28gdXNlIGNhc2VzOg0KPiA+ID4gPg0KPiA+ID4gPiAgIDEuICBUaGUgY2xpZW50IGNv bmZpZ3VyZXMgdGhlIHByaXZhdGUgYW5kIHB1YmxpYyBrZXlzIGV4cGxpY2l0bHkNCj4gPiA+ID4g ICAgICAgKHNpbXBsZSBjYXNlKS4gIEJvdGgga2V5cyBhcmUgYXZhaWxpYmxlIGluIHRoZSBjb25m aWcgYW5kDQo+ID4gPiA+ICAgICAgIG9wZXJhaW9uYWwgc3RhdGUuDQo+ID4gPiA+DQo+ID4gPiA+ ICAgMi4gIFRoZSBjbGllbnQgYXNrcyB0aGUgZGV2aWNlIHRvIGdlbmVyYXRlIGEgImhpZGRlbiIg a2V5IHdoaWNoDQo+IG1heQ0KPiA+ID4gPiAgICAgICBiZSBhIGtleSBpbiBzcGVjaWFsIFRQTSBo YXJkd2FyZS4NCj4gPiA+ID4NCj4gPiA+ID4gRm9yIDIsIHRoZSBjbGllbnQgY29uZmlndXJlcyB0 aGUgbmFtZSBvZiB0aGUga2V5IChpbiA8cnVubmluZz4pLg0KPiBUaGVuDQo+ID4gPiA+IHRoZSBj bGllbnQNCj4gPiA+ID4gaW52b2tlcyB0aGUgYWN0aW9uIChpbiA8b3BlcmF0aW9uYWw+KS4gIFRo ZSBkZXZpY2UgZ2VuZXJhdGVzIGEgbmV3DQo+IGtleQ0KPiA+ID4gPiBwYWlyDQo+ID4gPiA+IChw ZXJoYXBzIGluIHRwbS1odykuICBJbiA8b3BlcmF0aW9uYWw+LCB0aGUgcHVibGljIGtleSBpcyBu b3cNCj4gdmlzaWJsZQ0KPiA+ID4gPiBhbmQgdGhlDQo+ID4gPiA+IHByaXZhdGUga2V5IGhhcyB0 aGUgc3BlY2lhbCBlbnVtICJwZXJtYW5lbnRseS1oaWRkZW4iLg0KPiA+ID4NCj4gPiA+IFdoeSBp cyBhIHNlcGFyYXRlIGFjdGlvbiByZXF1aXJlZCB0byBjcmVhdGUgdGhlIGtleXM/DQo+ID4gPg0K PiA+ID4gV2h5IGlzIHRoZSBjb25maWd1cmF0aW9uIHRvIGdlbmVyYXRlIGEgaGlkZGVuIGtleSBu b3Qgc3VmZmljaWVudCBmb3INCj4gPiA+IHRoZSBkZXZpY2UgdG8gYXV0b21hdGljYWxseSBhbGxv Y2F0ZSBhIGtleSBpbiB0aGUgVFBNIG1vZHVsZT8NCj4gPg0KPiA+IFRoaXMgaXMgYSB2ZXJ5IGdv b2QgcXVlc3Rpb24uICBXaHkgZG9uJ3Qgd2UgaGF2ZSBhY3Rpb25zIGZvcg0KPiA+ICJjcmVhdGUt aW50ZXJmYWNlJywgImNyZWF0ZS11c2VyIiBvciAiY3JlYXRlLWFjbCI/ICBJbiBhbGwgdGhlc2Ug Y2FzZXMNCj4gPiB3ZSBoYXZlIGNvbmZpZyB0aGF0IGEgZGV2aWNlIGludGVybmFsbHkgcGFyc2Vz IGFuZCB0cmFuc2xhdGVzIHRvIHNvbWUNCj4gPiBpbnRlcm5hbCBwcm9jZWR1cmUgKHBlcmhhcHMg aWZjb25maWcsIGFkZHVzZXIsIGlwdGFibGVzIGV0YykuDQo+ID4NCj4gPiBJbiBhIHdheSwgdGhp cyBjYXNlIGlzIGRpZmZlcmVudCBiL2MgdGhlIGNsaWVudCBuZWVkcyBjb250cm9sIG9mDQo+ID4g KndoZW4qIHRoZSBrZXkgaXMgZ2VuZXJhdGVkLiAgV2UgY2Fubm90IGNvcHkgJiBwYXN0ZSBzb21l IGNvbmZpZyB0bw0KPiA+IGFub3RoZXIgZGV2aWNlIGFuZCBleHBlY3QgaXQgdG8gd29yayBleGFj dGx5IHRoZSBzYW1lLiAgT1RPSCB0aGF0DQo+ID4gcHJvYmFibHkgaXMgdHJ1ZSBmb3Igb3RoZXIg dGhpbmdzIGFzIHdlbGw7IGlmIGEgdXNlciBoYXMgYmVlbiBjcmVhdGVkDQo+ID4gaW4gdGhlIGNv bmZpZyB0aGVyZSBtaWdodCBiZSBmaWxlcyBvd25lZCBieSB0aGF0IHVzZXIgc3RvcmVkIGluIHRo ZQ0KPiA+IGhvbWUgZGlyZWN0b3J5Lg0KPiA+DQo+ID4gQWxzbywgd2UgbWlnaHQgbmVlZCB0aGUg b3B0aW9uIHRvIHJlLWdlbmVyYXRlIHRoZSBrZXkgKGV2ZW4gdGhvdWdoIHRoZQ0KPiA+IGN1cnJl bnQgdmVyc2lvbiBkb2Vzbid0IHN1cHBvcnQgdGhpcykuICBCdXQgKnRoaXMqIGNvdWxkIGJlIGRv bmUgdy8gYW4NCj4gPiBhY3Rpb24gKGlmIHdlIG5lZWQgdG8gc3VwcG9ydCBpdCkuDQo+ID4NCj4g PiBXaGF0IGRpZCBJIG1pc3M7IHdoYXQgbWFrZXMgdGhpcyBjYXNlIHNwZWNpYWwgc28gdGhhdCBp dCBjYW4ndCBiZQ0KPiA+IGhhbmRsZWQgbGlrZSBvdGhlciBjb25maWc/DQo+IA0KPiBJZiBJIGNv bmZpZ3VyZSBhbiBpbnRlcmZhY2UsIEkgYW0gcHJvdmlkaW5nIGF0IGxlYXN0IHBhcnQgb2YgdGhl DQo+IGluZm9ybWF0aW9uIGFuZCBhbnl0aGluZyB0aGF0IHRoZSBkZXZpY2UgZ2VuZXJhdGVzIC0g aW50ZXJmYWNlIG5hbWUsIE1UVSwNCj4gcHJpdmFjeSBhZGRyZXNzIC0gSSBjYW4gdGhlbiBzZWUg YW5kIG1heSBvciBtYXkgbm90IGJlIGFibGUgdG8gY2hhbmdlLg0KPiANCj4gV2hlbiBJIGdlbmVy YXRlIGEga2V5IHBhaXIsIHllcyBJIHdhbnQgdG8gc2VlIHRoZSBwdWJsaWMga2V5IGJ1dCBJIGhh dmUgbm8NCj4gaW50ZXJlc3QgaW4gdGhlIHByaXZhdGUga2V5LiAgSSB3YW50IHRoZSBkZXZpY2Us IGFuZCBpdCBpcyB0aGUgZGV2aWNlIG5vdA0KPiBhbiBpbmRpdmlkdWFsIHVzZXIsIHRvIGJlIGFi bGUgdG8gZG8gdGhpbmdzIHdpdGggdGhlIHByaXZhdGUga2V5LCBub3RhYmx5DQo+IHRvIGdlbmVy YXRlIGEgY2VydGlmaWNhdGUgZm9yIHRoZSBkZXZpY2U7IEkgbm93IHNlZSBvcmdhbmlzYXRpb25z IHdoZXJlDQo+IGV2ZXJ5IGRldmljZSB0aGF0IGlzIGF0dGFjaGVkIHRvIHRoZSBuZXR3b3JrIG11 c3QgaGF2ZSBpdHMgb3duIGNlcnRpZmljYXRlDQo+IHJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUgZGV2 aWNlIGlzLCB3aG8gb3ducyBpdCwgd2hvIGlzIGxvZ2dlZCBvbnRvIGl0IGV0Yy4NCj4gDQo+IFNv IGdlbmVyYXRlIGEga2V5IHBhaXIsIGtlZXAgdGhlIHByaXZhdGUgcHJpdmF0ZSwgdXNlIGl0IGZv ciBhIGNlcnRpZmljYXRlLA0KPiBidXQgSSB3aWxsIG5ldmVyIGNoYW5nZSBpdCwgZG9uJ3Qgd2Fu dCB0byBrbm93IGl0IGlzLCBJIGp1c3Qgd2FudCBpdA0KPiBzZWN1cmVseSBoaWRkZW4gLSBhbmQg aXQgaXMgdW5saWtlbHkgdGhhdCB0aGUgbm90ZXBhZCwgc21hcnRQaG9uZSwgbGFwdG9wDQo+IGV0 YyB3aWxsIGhhdmUgYSBUUE0uDQo+IA0KPiBUaGlzIGlzIHRoZSBwb2xpY3kgb2YgdGhlIG1vc3Qg c2VjdXJpdHktY29uc2Npb3VzIG9yZ2FuaXNhdGlvbiBJIGtub3csIHRoZQ0KPiBvbmx5IG9uZSB3 aG9zZSBwYXNzd29yZHMgd291bGQgbWVldCB0aGUgY3JpdGVyaWEgbGFpZCBkb3duIGluIFJGQywg YnV0IGl0DQo+IGhhcyBvbmx5IGJlZW4gYXJvdW5kIGZvciBhIHllYXIgb3Igc28gc28gSSBleHBl Y3Qgb3RoZXJzIHdpbGwgZm9sbG93IHN1aXQuDQoNClRoaXMgaXMgYWxsIGZpbmUgYW5kIHNvdW5k cyBzZW5zaWJsZSB0byBtZS4NCg0KVGhlIHB1YmxpYyBrZXkgY2FuIGJlIHB1Ymxpc2hlZCBpbiA8 b3BlcmF0aW9uYWw+Lg0KDQpCdXQgd2h5IGRvZXMgdGhlcmUgbmVlZCB0byBiZSBhIHNlcGFyYXRl IFlBTkcgYWN0aW9uIHJlcXVpcmVkIHRvIGdlbmVyYXRlIHRoZSBwdWJsaWMvcHJpdmF0ZSBrZXkg cGFpciBvbiB0aGUgZGV2aWNlPw0KDQpXaHkgaXMgdGhlIGNvbmZpZ3VyYXRpb24gaW50ZW50IG9m ICJJIHdhbnQgeW91IHRvIHVzZSBhIHNlY3VyZWx5IGFsbG9jYXRlZCBwdWJsaWMvcHJpdmF0ZSBr ZXkgcGFpciIgKHdoaWNoIGNvdWxkIGJlIGluIHRoZSBjb25maWd1cmF0aW9uKSBub3Qgc3VmZmlj aWVudD8NCg0KSWYgdGhlIGlzc3VlIGlzIHRoYXQgdGhlc2Uga2V5cyBuZWVkIHRvIHBlcnNpc3Qg b3ZlciBkZXZpY2UgcmVzdGFydCwgdGhlbiBJIHdvdWxkIHRoaW5rIHRoYXQgdGhlIHNvbHV0aW9u IGlzIGZvciB0aGUgZGV2aWNlIHRvIHNlY3VyZWx5IHBlcnNpc3QgdGhlc2Uga2V5cyBpbmRlcGVu ZGVudGx5IG9mIHRoZSBZQU5HIGNvbmZpZ3VyYXRpb24uDQoNClRoYW5rcywNClJvYg0KDQoNCj4g DQo+IFRvbSBQZXRjaA0KPiANCj4gPiAvbWFydGluDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldGNvbmYgbWFpbGluZyBsaXN0 DQo+ID4gbmV0Y29uZkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0KPiA+DQoNCg== From nobody Fri May 3 04:31:47 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B212008A for ; Fri, 3 May 2019 04:31:45 -0700 (PDT) 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, 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 7sQ4wKauAsqq for ; Fri, 3 May 2019 04:31:42 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70109.outbound.protection.outlook.com [40.107.7.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4189D12004A for ; Fri, 3 May 2019 04:31:41 -0700 (PDT) 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=6w5EwIcokKSxJQAEvGcUqcyYnBKNqxcRd3kpCrV9oW4=; b=Q3yI3Q6WZeyB9E1qOzCIgMGpoS72EIQb7YU46GhvhqYt5LXwWAMTQZew3Ri7C+2tK8iLLHDKgE7LFmA6v/favQ5GhcLR6GBjfV3jV1qC9csgGgfn0V7tl7jlDGnouTtSP670DX8NQFPH3vIdBolEh2kDecLLjOCGytcf7AAuIik= Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5853.eurprd07.prod.outlook.com (20.178.122.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Fri, 3 May 2019 11:31:38 +0000 Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Fri, 3 May 2019 11:31:38 +0000 From: tom petch To: "Rob Wilton (rwilton)" , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHVAZ25vWzSND4r/0+wKWIH0SB1HQ== Date: Fri, 3 May 2019 11:31:38 +0000 Message-ID: <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0378.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::30) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ca0b893-6adf-4c86-a66c-08d6cfbae7fd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5853; x-ms-traffictypediagnostic: VI1PR07MB5853: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(366004)(189003)(199004)(51914003)(13464003)(561944003)(81156014)(81166006)(26005)(4720700003)(6506007)(8936002)(6116002)(14454004)(53546011)(62236002)(8676002)(44716002)(14496001)(102836004)(81686011)(68736007)(386003)(5660300002)(99286004)(52116002)(3846002)(86152003)(2906002)(81816011)(76176011)(84392002)(50226002)(186003)(64756008)(66446008)(229853002)(5024004)(66476007)(6306002)(446003)(110136005)(86362001)(966005)(6486002)(478600001)(44736005)(66556008)(6436002)(1556002)(4326008)(71190400001)(316002)(45080400002)(6512007)(9686003)(66066001)(25786009)(61296003)(476003)(14444005)(486006)(73956011)(256004)(7736002)(305945005)(66946007)(53936002)(71200400001)(6246003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5853; H:VI1PR07MB3118.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MQNIGkMbI0Ieg8IZKx/VXlrtU5E3JlvMYy8AsLQJfqJw+OecNF94gjrroFMshSls1He7b4ysyMrVUwzHPZVvex7omg2uyiBfPsIeDrGySltbta6QiiirxZ/RwLAxyKuAnkLFIWRmB/qxVj3x9RPK21lGvcPWTqN7uc5Cpq3AZ+bQ2NIogocVyj5ExtP2ym2ewgot5nQzqretb+UdG9nFE5vqjR5zYB+n9N5Nj83CVl0gWzfD3lRUeGbhRvDYpAiEtaIr96VaOA0hiEfPJYGQ/FcVKAV1mPjQzBsBWMorVXOu5p67N0HOHyOOuo+q/nruvb0WRPPpIS940/cBgHLWoZpeMtFbATTeNU7CTvrnAvpTRgeZ4KPmK41viobRs3K78svA8eEJvbZ9Oo3x07XeW593vm2riNMnPkaMe0HfzF8= Content-Type: text/plain; charset="utf-8" Content-ID: <10A656643534A94E9CFBF8473132368B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ca0b893-6adf-4c86-a66c-08d6cfbae7fd X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 11:31:38.5738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5853 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 11:31:46 -0000 LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiUm9iIFdpbHRvbiAocndpbHRvbiki IDxyd2lsdG9uQGNpc2NvLmNvbT4NClRvOiAidG9tIHBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNv bT47ICJNYXJ0aW4gQmpvcmtsdW5kIg0KPG1iakB0YWlsLWYuY29tPg0KQ2M6IDxuZXRjb25mQGll dGYub3JnPg0KU2VudDogRnJpZGF5LCBNYXkgMDMsIDIwMTkgMTI6MDAgUE0NClN1YmplY3Q6IFJF OiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4NCg0KDQo+ IEhpIFRvbSwNCj4NCj4gVGhhbmtzIGZvciB0aGUgaW5zaWdodC4gIFNvbWUgY29tbWVudHMgaW5s aW5lIC4uLg0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdG9t IHBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPg0KPiA+IFNlbnQ6IDAzIE1heSAyMDE5IDExOjQ4 DQo+ID4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IE1hcnRp biBCam9ya2x1bmQNCjxtYmpAdGFpbC0NCj4gPiBmLmNvbT4NCj4gPiBDYzogbmV0Y29uZkBpZXRm Lm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJt YW5lbnRseSBoaWRkZW4NCj4gPg0KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4g PiBGcm9tOiAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPg0KPiA+IFNlbnQ6IEZy aWRheSwgTWF5IDAzLCAyMDE5IDc6NDcgQU0NCj4gPg0KPiA+ID4gIlJvYiBXaWx0b24gKHJ3aWx0 b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gPiBIaSBNYXJ0aW4sDQo+ID4g PiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9t OiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNYXJ0aW4N Cj4gPiBCam9ya2x1bmQNCj4gPiA+ID4gPiBTZW50OiAwMSBNYXkgMjAxOSAyMjowNg0KPiA+ID4g PiA+IFRvOiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUNCj4gPiA+ID4gPiBD YzogbmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gaWV0 ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPiBP biBUdWUsIEFwciAzMCwgMjAxOSBhdCAwMjo0OTozMFBNICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5k DQo+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2Vu Lm5ldD4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBDb3JyZWN0LCBh cyBJIGRpZG7igJl0IHRoaW5rIHRoZXJlIHdhcyBjb25zZW5zdXMgeWV0Lg0KUGVyaGFwcw0KPiA+ IHRoZXJlDQo+ID4gPiA+ID4gPiA+ID4gaXMgcm91Z2gtY29uc2Vuc3VzLCBhbmQgaXQgbWF5IGJl IHRoYXQgdGhlIG9ubHkgd2F5IHRvDQpnYXVnZQ0KPiA+IHRoYXQNCj4gPiA+ID4gPiA+ID4gPiBp cyB0byB0cnkgYW5kIHNlZSBob3cgbXVjaCBwdXNoIGJhY2sgdGhlcmUgaXMuDQo+ID4gPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBPa2F5LCBzbyBob3cgYWJvdXQgdGhpcywgYmFzZWQgb24g dGhpcyB0aHJlYWQsIHRoZXJlDQphcHBlYXJzDQo+ID4gdG8gYmUNCj4gPiA+ID4gPiA+ID4gPiBz dXBwb3J0IHRvIGFkZCBhIGZsYWcgdG8gY29udHJvbCBpZiBhIGtleSBzaG91bGQgYmUNCj4gPiDi gJxwZXJtYW5lbnRseQ0KPiA+ID4gPiA+ID4gPiA+IGhpZGRlbuKAnSBvciBub3QsIGluIHdoaWNo IGNhc2UgY29uZmlndXJhdGlvbiBpcyBjcmVhdGVkLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiBJIChzdGlsbCkgb2JqZWN0IHRvIHRoaXMuICBBY3Rpb25zIHNob3VsZG4ndCBjcmVhdGUN CmNvbmZpZy4NCj4gPiBXZQ0KPiA+ID4gPiA+ID4gPiBhbHJlYWR5IGhhdmUgZ2VuZXJpYyBwcm90 Y29sIG9wZXJhdGlvbnMgdG8gZG8gdGhpcy4gIFdlIGdvDQo+ID4gZnJvbSBhDQo+ID4gPiA+ID4g PiA+IGRvY3VtZW50LW9yaWVudGVkIGNvbmZpZ3VyYXRpb24gbW9kZWwgdG93YXJkcyBhDQo+ID4g Y29tbWFuZC1vcmllbnRlZA0KPiA+ID4gPiA+ID4gPiBtb2RlbC4gIE5vdCBnb29kLiAgSW4gUkVT VENPTkYsIHRoZSBnZW5lcmljIG1ldGhvZHMNCnN1cHBvcnQNCj4gPiB0aGluZ3MNCj4gPiA+ID4g PiA+ID4gbGlrZSBFVGFncywgd2hpY2ggSSBzdXNwZWN0IHlvdSBkb24ndCB3YW50IHRvIHJlcGxp Y2F0ZSBpbg0KPiA+IHRoaXMNCj4gPiA+ID4gPiA+ID4gYWN0aW9uPyAgIFdpbGwgdGhlIGFjdGlv biBzdXBwb3J0IGFsbCBlcnJvci1vcHRpb25zIG9mDQo+ID4gZWRpdC1jb25maWcsDQo+ID4gPiA+ ID4gPiA+IGxpa2Ugcm9sbGJhY2stb24tZXJyb3I/DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gTWFydGluLA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IGRvIHlvdSBo YXZlIGFueSBwcm9wb3NhbCBob3cgdG8gc3VwcG9ydCB0aGUgcmVxdWlyZW1lbnQgdG8NCj4gPiBn ZW5lcmF0ZSBhDQo+ID4gPiA+ID4gPiBrZXkgb24gdGhlIGRldmljZSB0aGF0IGlzIHdvcmthYmxl IHdpdGggYSBkb2N1bWVudC1vcmllbnRlZA0KPiA+ID4gPiA+ID4gY29uZmlndXJhdGlvbiBtb2Rl bD8gRG8geW91IHByb3Bvc2UgdGhhdCB0aGUgYWN0aW9uL3JwYw0KcmV0dXJucw0KPiA+IHRoZQ0K PiA+ID4gPiA+ID4gcHVibGljIGtleSBpbmZvcm1hdGlvbiBhcyByZXN1bHQgZGF0YSB0aGF0IHRo ZW4gbmVlZHMgdG8gYmUNCj4gPiB3cml0dGVuDQo+ID4gPiA+ID4gPiBiYWNrIHRvIHRoZSBzZXJ2 ZXIgYW5kIHNvbWVob3cgbWF0Y2hlZCB0byB0aGUga2V5IHRoYXQgaXMNCmNhY2hlZA0KPiA+IG9u DQo+ID4gPiA+ID4gPiB0aGUgZGV2aWNlPyBQZXJoYXBzIHlvdSBoYXZlIG90aGVyIGlkZWFzIEkg Y2FuJ3QgdGhpbmsgb2Y/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSSB0aGluayBJIHdvdWxk IGJlIGhhcHB5IHRvIG5vdCBoYXZlIHRoaXMgc3BlY2lhbCBoYWNrIGJ1dA0KdGhlbg0KPiA+IHdl DQo+ID4gPiA+ID4gPiBuZWVkIGEgd29ya2FibGUgYWx0ZXJuYXRpdmUuIEtleSBnZW5lcmF0aW9u IG9uIGRldmljZXMgaXMNCj4gPiBzb21ldGhpbmcNCj4gPiA+ID4gPiA+IHRoYXQgaXMgYmVpbmcg dXNlZCAtIGFuZCBtYXkgYmUgZXZlbiBtb3JlIHVzZWQgaW4gdGhlIGZ1dHVyZQ0KdGhlDQo+ID4g bW9yZQ0KPiA+ID4gPiA+ID4gd2UgZ2V0IHNwZWNpYWwgaGFyZHdhcmUgc3VwcG9ydCBmb3Igc3Rv cmluZyBrZXlzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU28gdGhlIGN1cnJlbnQgZHJhZnQgc3Vw cG9ydHMgdHdvIHVzZSBjYXNlczoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgMS4gIFRoZSBjbGll bnQgY29uZmlndXJlcyB0aGUgcHJpdmF0ZSBhbmQgcHVibGljIGtleXMNCmV4cGxpY2l0bHkNCj4g PiA+ID4gPiAgICAgICAoc2ltcGxlIGNhc2UpLiAgQm90aCBrZXlzIGFyZSBhdmFpbGlibGUgaW4g dGhlIGNvbmZpZw0KYW5kDQo+ID4gPiA+ID4gICAgICAgb3BlcmFpb25hbCBzdGF0ZS4NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+ICAgMi4gIFRoZSBjbGllbnQgYXNrcyB0aGUgZGV2aWNlIHRvIGdlbmVy YXRlIGEgImhpZGRlbiIga2V5DQp3aGljaA0KPiA+IG1heQ0KPiA+ID4gPiA+ICAgICAgIGJlIGEg a2V5IGluIHNwZWNpYWwgVFBNIGhhcmR3YXJlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRm9yIDIs IHRoZSBjbGllbnQgY29uZmlndXJlcyB0aGUgbmFtZSBvZiB0aGUga2V5IChpbg0KPHJ1bm5pbmc+ KS4NCj4gPiBUaGVuDQo+ID4gPiA+ID4gdGhlIGNsaWVudA0KPiA+ID4gPiA+IGludm9rZXMgdGhl IGFjdGlvbiAoaW4gPG9wZXJhdGlvbmFsPikuICBUaGUgZGV2aWNlIGdlbmVyYXRlcyBhDQpuZXcN Cj4gPiBrZXkNCj4gPiA+ID4gPiBwYWlyDQo+ID4gPiA+ID4gKHBlcmhhcHMgaW4gdHBtLWh3KS4g IEluIDxvcGVyYXRpb25hbD4sIHRoZSBwdWJsaWMga2V5IGlzIG5vdw0KPiA+IHZpc2libGUNCj4g PiA+ID4gPiBhbmQgdGhlDQo+ID4gPiA+ID4gcHJpdmF0ZSBrZXkgaGFzIHRoZSBzcGVjaWFsIGVu dW0gInBlcm1hbmVudGx5LWhpZGRlbiIuDQo+ID4gPiA+DQo+ID4gPiA+IFdoeSBpcyBhIHNlcGFy YXRlIGFjdGlvbiByZXF1aXJlZCB0byBjcmVhdGUgdGhlIGtleXM/DQo+ID4gPiA+DQo+ID4gPiA+ IFdoeSBpcyB0aGUgY29uZmlndXJhdGlvbiB0byBnZW5lcmF0ZSBhIGhpZGRlbiBrZXkgbm90IHN1 ZmZpY2llbnQNCmZvcg0KPiA+ID4gPiB0aGUgZGV2aWNlIHRvIGF1dG9tYXRpY2FsbHkgYWxsb2Nh dGUgYSBrZXkgaW4gdGhlIFRQTSBtb2R1bGU/DQo+ID4gPg0KPiA+ID4gVGhpcyBpcyBhIHZlcnkg Z29vZCBxdWVzdGlvbi4gIFdoeSBkb24ndCB3ZSBoYXZlIGFjdGlvbnMgZm9yDQo+ID4gPiAiY3Jl YXRlLWludGVyZmFjZScsICJjcmVhdGUtdXNlciIgb3IgImNyZWF0ZS1hY2wiPyAgSW4gYWxsIHRo ZXNlDQpjYXNlcw0KPiA+ID4gd2UgaGF2ZSBjb25maWcgdGhhdCBhIGRldmljZSBpbnRlcm5hbGx5 IHBhcnNlcyBhbmQgdHJhbnNsYXRlcyB0bw0Kc29tZQ0KPiA+ID4gaW50ZXJuYWwgcHJvY2VkdXJl IChwZXJoYXBzIGlmY29uZmlnLCBhZGR1c2VyLCBpcHRhYmxlcyBldGMpLg0KPiA+ID4NCj4gPiA+ IEluIGEgd2F5LCB0aGlzIGNhc2UgaXMgZGlmZmVyZW50IGIvYyB0aGUgY2xpZW50IG5lZWRzIGNv bnRyb2wgb2YNCj4gPiA+ICp3aGVuKiB0aGUga2V5IGlzIGdlbmVyYXRlZC4gIFdlIGNhbm5vdCBj b3B5ICYgcGFzdGUgc29tZSBjb25maWcNCnRvDQo+ID4gPiBhbm90aGVyIGRldmljZSBhbmQgZXhw ZWN0IGl0IHRvIHdvcmsgZXhhY3RseSB0aGUgc2FtZS4gIE9UT0ggdGhhdA0KPiA+ID4gcHJvYmFi bHkgaXMgdHJ1ZSBmb3Igb3RoZXIgdGhpbmdzIGFzIHdlbGw7IGlmIGEgdXNlciBoYXMgYmVlbg0K Y3JlYXRlZA0KPiA+ID4gaW4gdGhlIGNvbmZpZyB0aGVyZSBtaWdodCBiZSBmaWxlcyBvd25lZCBi eSB0aGF0IHVzZXIgc3RvcmVkIGluDQp0aGUNCj4gPiA+IGhvbWUgZGlyZWN0b3J5Lg0KPiA+ID4N Cj4gPiA+IEFsc28sIHdlIG1pZ2h0IG5lZWQgdGhlIG9wdGlvbiB0byByZS1nZW5lcmF0ZSB0aGUg a2V5IChldmVuIHRob3VnaA0KdGhlDQo+ID4gPiBjdXJyZW50IHZlcnNpb24gZG9lc24ndCBzdXBw b3J0IHRoaXMpLiAgQnV0ICp0aGlzKiBjb3VsZCBiZSBkb25lDQp3LyBhbg0KPiA+ID4gYWN0aW9u IChpZiB3ZSBuZWVkIHRvIHN1cHBvcnQgaXQpLg0KPiA+ID4NCj4gPiA+IFdoYXQgZGlkIEkgbWlz czsgd2hhdCBtYWtlcyB0aGlzIGNhc2Ugc3BlY2lhbCBzbyB0aGF0IGl0IGNhbid0IGJlDQo+ID4g PiBoYW5kbGVkIGxpa2Ugb3RoZXIgY29uZmlnPw0KPiA+DQo+ID4gSWYgSSBjb25maWd1cmUgYW4g aW50ZXJmYWNlLCBJIGFtIHByb3ZpZGluZyBhdCBsZWFzdCBwYXJ0IG9mIHRoZQ0KPiA+IGluZm9y bWF0aW9uIGFuZCBhbnl0aGluZyB0aGF0IHRoZSBkZXZpY2UgZ2VuZXJhdGVzIC0gaW50ZXJmYWNl IG5hbWUsDQpNVFUsDQo+ID4gcHJpdmFjeSBhZGRyZXNzIC0gSSBjYW4gdGhlbiBzZWUgYW5kIG1h eSBvciBtYXkgbm90IGJlIGFibGUgdG8NCmNoYW5nZS4NCj4gPg0KPiA+IFdoZW4gSSBnZW5lcmF0 ZSBhIGtleSBwYWlyLCB5ZXMgSSB3YW50IHRvIHNlZSB0aGUgcHVibGljIGtleSBidXQgSQ0KaGF2 ZSBubw0KPiA+IGludGVyZXN0IGluIHRoZSBwcml2YXRlIGtleS4gIEkgd2FudCB0aGUgZGV2aWNl LCBhbmQgaXQgaXMgdGhlDQpkZXZpY2Ugbm90DQo+ID4gYW4gaW5kaXZpZHVhbCB1c2VyLCB0byBi ZSBhYmxlIHRvIGRvIHRoaW5ncyB3aXRoIHRoZSBwcml2YXRlIGtleSwNCm5vdGFibHkNCj4gPiB0 byBnZW5lcmF0ZSBhIGNlcnRpZmljYXRlIGZvciB0aGUgZGV2aWNlOyBJIG5vdyBzZWUgb3JnYW5p c2F0aW9ucw0Kd2hlcmUNCj4gPiBldmVyeSBkZXZpY2UgdGhhdCBpcyBhdHRhY2hlZCB0byB0aGUg bmV0d29yayBtdXN0IGhhdmUgaXRzIG93bg0KY2VydGlmaWNhdGUNCj4gPiByZWdhcmRsZXNzIG9m IHdoYXQgdGhlIGRldmljZSBpcywgd2hvIG93bnMgaXQsIHdobyBpcyBsb2dnZWQgb250byBpdA0K ZXRjLg0KPiA+DQo+ID4gU28gZ2VuZXJhdGUgYSBrZXkgcGFpciwga2VlcCB0aGUgcHJpdmF0ZSBw cml2YXRlLCB1c2UgaXQgZm9yIGENCmNlcnRpZmljYXRlLA0KPiA+IGJ1dCBJIHdpbGwgbmV2ZXIg Y2hhbmdlIGl0LCBkb24ndCB3YW50IHRvIGtub3cgaXQgaXMsIEkganVzdCB3YW50IGl0DQo+ID4g c2VjdXJlbHkgaGlkZGVuIC0gYW5kIGl0IGlzIHVubGlrZWx5IHRoYXQgdGhlIG5vdGVwYWQsIHNt YXJ0UGhvbmUsDQpsYXB0b3ANCj4gPiBldGMgd2lsbCBoYXZlIGEgVFBNLg0KPiA+DQo+ID4gVGhp cyBpcyB0aGUgcG9saWN5IG9mIHRoZSBtb3N0IHNlY3VyaXR5LWNvbnNjaW91cyBvcmdhbmlzYXRp b24gSQ0Ka25vdywgdGhlDQo+ID4gb25seSBvbmUgd2hvc2UgcGFzc3dvcmRzIHdvdWxkIG1lZXQg dGhlIGNyaXRlcmlhIGxhaWQgZG93biBpbiBSRkMsDQpidXQgaXQNCj4gPiBoYXMgb25seSBiZWVu IGFyb3VuZCBmb3IgYSB5ZWFyIG9yIHNvIHNvIEkgZXhwZWN0IG90aGVycyB3aWxsIGZvbGxvdw0K c3VpdC4NCj4NCj4gVGhpcyBpcyBhbGwgZmluZSBhbmQgc291bmRzIHNlbnNpYmxlIHRvIG1lLg0K Pg0KPiBUaGUgcHVibGljIGtleSBjYW4gYmUgcHVibGlzaGVkIGluIDxvcGVyYXRpb25hbD4uDQo+ DQo+IEJ1dCB3aHkgZG9lcyB0aGVyZSBuZWVkIHRvIGJlIGEgc2VwYXJhdGUgWUFORyBhY3Rpb24g cmVxdWlyZWQgdG8NCmdlbmVyYXRlIHRoZSBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpciBvbiB0aGUg ZGV2aWNlPw0KDQpIb3cgZWxzZSBpcyB0aGUga2V5IHBhaXIgZ29pbmcgdG8gY29tZSBpbnRvIGV4 aXN0ZW5jZT8gIFRoZSBkZXZpY2UgaXMNCm5vdCBzaGlwcGVkIHdpdGggb25lIChhbHRob3VnaCBp dCBpcyB0aGUgc29ydCBvZiB0aGUgdGhpbmcgdGhhdCBhDQpNaWNyb3NvZnQgbWlnaHQgb3JnYW5p c2UgaWYgaXQgYmVjb21lcyB0aGUgbm9ybSkuICBBIHVzZXIgKHdpdGggc3VpdGFibGUNCmNyZWRl bnRpYWxzKSBicmluZ3MgaW4gaGlzIGRldmljZSwgdGhlIG9yZ2FuaXNhdGlvbiBzYXlzICdnZW5l cmF0ZSBrZXkNCnBhaXInLCBhbmQgY2VydGlmaWNhdGUsIGFuZCB0aGUgdXNlciBpcyB0aGVuIGdv b2QgdG8gZ28gZm9yIGhvd2V2ZXIgbG9uZw0KdGhleSB1c2UgdGhlIG9yZ2FuaXNhdGlvbidzIG5l dHdvcmssIGNvdWxkIGJlIHllYXJzOyBhbmQgeWVzLCB0aGUgcHVibGljDQprZXksIGFuZCBjZXJ0 aWZpY2F0ZSwgbXVzdCBwZXJzaXN0IGluIHRoZSBkZXZpY2UgYWNyb3NzIHJlc3RhcnRzIGJ1dA0K bm90LCBvZiBjb3Vyc2UsIGlmIHRoZSBoYXJkd2FyZSBpcyByZXBsYWNlZCBieSBmcmVzaCBoYXJk d2FyZSAtIGl0IGlzIGENCmRldmljZSBjZXJ0aWZpY2F0ZSwgbm90IGEgdXNlciBjZXJ0aWZpY2F0 ZS4NCg0KVG9tIFBldGNoDQoNCj4gV2h5IGlzIHRoZSBjb25maWd1cmF0aW9uIGludGVudCBvZiAi SSB3YW50IHlvdSB0byB1c2UgYSBzZWN1cmVseQ0KYWxsb2NhdGVkIHB1YmxpYy9wcml2YXRlIGtl eSBwYWlyIiAod2hpY2ggY291bGQgYmUgaW4gdGhlIGNvbmZpZ3VyYXRpb24pDQpub3Qgc3VmZmlj aWVudD8NCj4NCj4gSWYgdGhlIGlzc3VlIGlzIHRoYXQgdGhlc2Uga2V5cyBuZWVkIHRvIHBlcnNp c3Qgb3ZlciBkZXZpY2UgcmVzdGFydCwNCnRoZW4gSSB3b3VsZCB0aGluayB0aGF0IHRoZSBzb2x1 dGlvbiBpcyBmb3IgdGhlIGRldmljZSB0byBzZWN1cmVseQ0KcGVyc2lzdCB0aGVzZSBrZXlzIGlu ZGVwZW5kZW50bHkgb2YgdGhlIFlBTkcgY29uZmlndXJhdGlvbi4NCj4NCj4gVGhhbmtzLA0KPiBS b2INCj4NCj4NCj4gPg0KPiA+IFRvbSBQZXRjaA0KPiA+DQo+ID4gPiAvbWFydGluDQo+ID4gPg0K PiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRjb25mQGlldGYub3JnDQo+ID4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+DQo+DQo+ DQoNCg== From nobody Fri May 3 04:37:49 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD42B1200B7 for ; Fri, 3 May 2019 04:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FlyE-Q2oSmjX for ; Fri, 3 May 2019 04:37:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D590512004A for ; Fri, 3 May 2019 04:37:44 -0700 (PDT) Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 57CEA1AE0389; Fri, 3 May 2019 13:37:43 +0200 (CEST) Date: Fri, 03 May 2019 13:37:43 +0200 (CEST) Message-Id: <20190503.133743.1149689382943153005.mbj@tail-f.com> To: rwilton@cisco.com Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> References: <20190503.084757.791827158808672980.mbj@tail-f.com> <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 11:37:48 -0000 IlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBNYXJ0aW4gQmpvcmts dW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gPiBTZW50OiAwMyBNYXkgMjAxOSAwNzo0OA0KPiA+IFRv OiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4gQ2M6IGouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTsgbmV0Y29uZkBpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFJlOiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRk ZW4NCj4gPiANCj4gPiAiUm9iIFdpbHRvbiAocndpbHRvbikiIDxyd2lsdG9uQGNpc2NvLmNvbT4g d3JvdGU6DQo+ID4gPiBIaSBNYXJ0aW4sDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBNYXJ0aW4NCj4gPiA+ID4gQmpvcmtsdW5kDQo+ID4gPiA+IFNlbnQ6 IDAxIE1heSAyMDE5IDIyOjA2DQo+ID4gPiA+IFRvOiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGUNCj4gPiA+ID4gQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+ID4gU3ViamVj dDogUmU6IFtuZXRjb25mXSBpZXRmIGNyeXB0byB0eXBlcyAtIHBlcm1hbmVudGx5IGhpZGRlbg0K PiA+ID4gPg0KPiA+ID4gPiBIaSwNCj4gPiA+ID4NCj4gPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVs ZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+ID4g PiA+IE9uIFR1ZSwgQXByIDMwLCAyMDE5IGF0IDAyOjQ5OjMwUE0gKzAyMDAsIE1hcnRpbiBCam9y a2x1bmQgd3JvdGU6DQo+ID4gPiA+ID4gPiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5u ZXQ+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBDb3JyZWN0LCBhcyBJIGRp ZG7igJl0IHRoaW5rIHRoZXJlIHdhcyBjb25zZW5zdXMgeWV0LiAgUGVyaGFwcw0KPiA+ID4gPiA+ ID4gPiB0aGVyZSBpcyByb3VnaC1jb25zZW5zdXMsIGFuZCBpdCBtYXkgYmUgdGhhdCB0aGUgb25s eSB3YXkgdG8NCj4gPiA+ID4gPiA+ID4gZ2F1Z2UgdGhhdCBpcyB0byB0cnkgYW5kIHNlZSBob3cg bXVjaCBwdXNoIGJhY2sgdGhlcmUgaXMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IE9r YXksIHNvIGhvdyBhYm91dCB0aGlzLCBiYXNlZCBvbiB0aGlzIHRocmVhZCwgdGhlcmUgYXBwZWFy cw0KPiA+ID4gPiA+ID4gPiB0byBiZSBzdXBwb3J0IHRvIGFkZCBhIGZsYWcgdG8gY29udHJvbCBp ZiBhIGtleSBzaG91bGQgYmUNCj4gPiA+ID4gPiA+ID4g4oCccGVybWFuZW50bHkgaGlkZGVu4oCd IG9yIG5vdCwgaW4gd2hpY2ggY2FzZSBjb25maWd1cmF0aW9uIGlzDQo+ID4gPiA+ID4gPiA+IGNy ZWF0ZWQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSSAoc3RpbGwpIG9iamVjdCB0byB0aGlz LiAgQWN0aW9ucyBzaG91bGRuJ3QgY3JlYXRlIGNvbmZpZy4gIFdlDQo+ID4gPiA+ID4gPiBhbHJl YWR5IGhhdmUgZ2VuZXJpYyBwcm90Y29sIG9wZXJhdGlvbnMgdG8gZG8gdGhpcy4gIFdlIGdvIGZy b20NCj4gPiA+ID4gPiA+IGEgZG9jdW1lbnQtb3JpZW50ZWQgY29uZmlndXJhdGlvbiBtb2RlbCB0 b3dhcmRzIGENCj4gPiA+ID4gPiA+IGNvbW1hbmQtb3JpZW50ZWQgbW9kZWwuICBOb3QgZ29vZC4g IEluIFJFU1RDT05GLCB0aGUgZ2VuZXJpYw0KPiA+ID4gPiA+ID4gbWV0aG9kcyBzdXBwb3J0IHRo aW5ncyBsaWtlIEVUYWdzLCB3aGljaCBJIHN1c3BlY3QgeW91IGRvbid0IHdhbnQgdG8NCj4gPiBy ZXBsaWNhdGUgaW4gdGhpcw0KPiA+ID4gPiA+ID4gYWN0aW9uPyAgIFdpbGwgdGhlIGFjdGlvbiBz dXBwb3J0IGFsbCBlcnJvci1vcHRpb25zIG9mIGVkaXQtY29uZmlnLA0KPiA+ID4gPiA+ID4gbGlr ZSByb2xsYmFjay1vbi1lcnJvcj8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBN YXJ0aW4sDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBkbyB5b3UgaGF2ZSBhbnkgcHJvcG9zYWwgaG93 IHRvIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50IHRvDQo+ID4gPiA+ID4gZ2VuZXJhdGUgYSBrZXkg b24gdGhlIGRldmljZSB0aGF0IGlzIHdvcmthYmxlIHdpdGggYQ0KPiA+ID4gPiA+IGRvY3VtZW50 LW9yaWVudGVkIGNvbmZpZ3VyYXRpb24gbW9kZWw/IERvIHlvdSBwcm9wb3NlIHRoYXQgdGhlDQo+ ID4gPiA+ID4gYWN0aW9uL3JwYyByZXR1cm5zIHRoZSBwdWJsaWMga2V5IGluZm9ybWF0aW9uIGFz IHJlc3VsdCBkYXRhIHRoYXQNCj4gPiA+ID4gPiB0aGVuIG5lZWRzIHRvIGJlIHdyaXR0ZW4gYmFj ayB0byB0aGUgc2VydmVyIGFuZCBzb21laG93IG1hdGNoZWQgdG8NCj4gPiA+ID4gPiB0aGUga2V5 IHRoYXQgaXMgY2FjaGVkIG9uIHRoZSBkZXZpY2U/IFBlcmhhcHMgeW91IGhhdmUgb3RoZXIgaWRl YXMgSQ0KPiA+ID4gPiA+IGNhbid0DQo+ID4gdGhpbmsgb2Y/DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBJIHRoaW5rIEkgd291bGQgYmUgaGFwcHkgdG8gbm90IGhhdmUgdGhpcyBzcGVjaWFsIGhhY2sg YnV0IHRoZW4gd2UNCj4gPiA+ID4gPiBuZWVkIGEgd29ya2FibGUgYWx0ZXJuYXRpdmUuIEtleSBn ZW5lcmF0aW9uIG9uIGRldmljZXMgaXMNCj4gPiA+ID4gPiBzb21ldGhpbmcgdGhhdCBpcyBiZWlu ZyB1c2VkIC0gYW5kIG1heSBiZSBldmVuIG1vcmUgdXNlZCBpbiB0aGUNCj4gPiA+ID4gPiBmdXR1 cmUgdGhlIG1vcmUgd2UgZ2V0IHNwZWNpYWwgaGFyZHdhcmUgc3VwcG9ydCBmb3Igc3RvcmluZyBr ZXlzLg0KPiA+ID4gPg0KPiA+ID4gPiBTbyB0aGUgY3VycmVudCBkcmFmdCBzdXBwb3J0cyB0d28g dXNlIGNhc2VzOg0KPiA+ID4gPg0KPiA+ID4gPiAgIDEuICBUaGUgY2xpZW50IGNvbmZpZ3VyZXMg dGhlIHByaXZhdGUgYW5kIHB1YmxpYyBrZXlzIGV4cGxpY2l0bHkNCj4gPiA+ID4gICAgICAgKHNp bXBsZSBjYXNlKS4gIEJvdGgga2V5cyBhcmUgYXZhaWxpYmxlIGluIHRoZSBjb25maWcgYW5kDQo+ ID4gPiA+ICAgICAgIG9wZXJhaW9uYWwgc3RhdGUuDQo+ID4gPiA+DQo+ID4gPiA+ICAgMi4gIFRo ZSBjbGllbnQgYXNrcyB0aGUgZGV2aWNlIHRvIGdlbmVyYXRlIGEgImhpZGRlbiIga2V5IHdoaWNo IG1heQ0KPiA+ID4gPiAgICAgICBiZSBhIGtleSBpbiBzcGVjaWFsIFRQTSBoYXJkd2FyZS4NCj4g PiA+ID4NCj4gPiA+ID4gRm9yIDIsIHRoZSBjbGllbnQgY29uZmlndXJlcyB0aGUgbmFtZSBvZiB0 aGUga2V5IChpbiA8cnVubmluZz4pLg0KPiA+ID4gPiBUaGVuIHRoZSBjbGllbnQgaW52b2tlcyB0 aGUgYWN0aW9uIChpbiA8b3BlcmF0aW9uYWw+KS4gIFRoZSBkZXZpY2UNCj4gPiA+ID4gZ2VuZXJh dGVzIGEgbmV3IGtleSBwYWlyIChwZXJoYXBzIGluIHRwbS1odykuICBJbiA8b3BlcmF0aW9uYWw+ LCB0aGUNCj4gPiA+ID4gcHVibGljIGtleSBpcyBub3cgdmlzaWJsZSBhbmQgdGhlIHByaXZhdGUg a2V5IGhhcyB0aGUgc3BlY2lhbCBlbnVtDQo+ID4gPiA+ICJwZXJtYW5lbnRseS1oaWRkZW4iLg0K PiA+ID4NCj4gPiA+IFdoeSBpcyBhIHNlcGFyYXRlIGFjdGlvbiByZXF1aXJlZCB0byBjcmVhdGUg dGhlIGtleXM/DQo+ID4gPg0KPiA+ID4gV2h5IGlzIHRoZSBjb25maWd1cmF0aW9uIHRvIGdlbmVy YXRlIGEgaGlkZGVuIGtleSBub3Qgc3VmZmljaWVudCBmb3INCj4gPiA+IHRoZSBkZXZpY2UgdG8g YXV0b21hdGljYWxseSBhbGxvY2F0ZSBhIGtleSBpbiB0aGUgVFBNIG1vZHVsZT8NCj4gPiANCj4g PiBUaGlzIGlzIGEgdmVyeSBnb29kIHF1ZXN0aW9uLiAgV2h5IGRvbid0IHdlIGhhdmUgYWN0aW9u cyBmb3INCj4gPiAiY3JlYXRlLWludGVyZmFjZScsDQo+ID4gImNyZWF0ZS11c2VyIiBvciAiY3Jl YXRlLWFjbCI/ICBJbiBhbGwgdGhlc2UgY2FzZXMgd2UgaGF2ZSBjb25maWcgdGhhdA0KPiA+IGEg ZGV2aWNlDQo+ID4gaW50ZXJuYWxseSBwYXJzZXMgYW5kIHRyYW5zbGF0ZXMgdG8gc29tZSBpbnRl cm5hbCBwcm9jZWR1cmUgKHBlcmhhcHMNCj4gPiBpZmNvbmZpZywNCj4gPiBhZGR1c2VyLCBpcHRh YmxlcyBldGMpLg0KPiANCj4gRm9yIG1lLCB0aGUgaWRlYWwgZ29hbCBpcyB0aGF0IHRoZSBjb25m aWd1cmF0aW9uIGlzIGludGVudCBiYXNlZC4NCg0KQWJzb2x1dGVseS4gIFRoZXNlIHdlcmUgcmhl dG9yaWNhbCBxdWVzdGlvbnMuDQoNCj4gSS5lLiByYXRoZXIgdGhhbiB0ZWxsaW5nIHRoZSBkZXZp Y2Ugd2hhdCBzZXF1ZW5jZSBvZiBzdGVwcyBpdCBzaG91bGQNCj4gcGVyZm9ybSwgaXQgaXMgdGVs bGluZyB0aGUgZGV2aWNlIHdoYXQgc3RhdGUgdGhlIGRldmljZSBzaG91bGQgYmUNCj4gdHJ5aW5n IHRvIGdldCBpbnRvLg0KPiANCj4gU28gZm9yIGFuIGludGVyZmFjZSwgdGhlIGludGVudCBvZiB0 aGUgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gaXMgIkkNCj4gd2FudCBpbnRlcmZhY2UgWFhYIHRv IGV4aXN0IG9uIHRoZSBkZXZpY2UsIGJlIGVuYWJsZWQsIGhhdmUgdGhpcyBJUHY0DQo+IGFkZHJl c3MgY29uZmlndXJlZCBvbiBpdCIuICBBcyBhIGNsaWVudCwgSSBkb24ndCBjYXJlIHdoYXQgaW50 ZXJuYWwNCj4gc3RlcHMgdGhlIGRldmljZSBuZWVkcyB0byB0YWtlIHRvIHJlYWNoIHRoaXMgc3Rh dGUsIGlmIGl0IGdldHMgdG8gdGhpcw0KPiBkZXNpcmVkIHN0YXRlLiAgU2ltaWxhcmx5LCBpZiBz b21ldGhpbmcgdHJhbnNpZW50bHkgZ29lcyB3cm9uZyBvbiB0aGUNCj4gZGV2aWNlLCB0aGVuIGl0 IHNob3VsZCBhbHdheXMgdHJ5IHRvIHJlY292ZXIgdG93YXJkcyB0aGUgZGVzaXJlZCBzdGF0ZQ0K PiBleHByZXNzZWQgaW4gdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24uDQo+IA0KPiBJIHRoaW5r IHRoYXQgdXNlcnMgaXMgYSBzbGlnaHRseSBvcnRob2dvbmFsIGlzc3VlLiAgSSB0aGluayB0aGF0 IHRoZQ0KPiBleHRlcm5hbCBwcmltYXJ5IG1hbmFnZWFiaWxpdHkga2V5IGZvciB1c2VycyBzaG91 bGQgYmUgdW5pcXVlDQo+IHVzZXJuYW1lcy4gIENlcnRhaW5seSwgd2hlbmV2ZXIgSSBsb2cgaW50 byBhbnkgbWFjaGluZSBpdCBpcyBteQ0KPiB1c2VybmFtZSB0aGF0IEkgdXNlIHRvIGlkZW50aWZ5 IG15c2VsZi4gIFdoZW4gSSBsb29rIGZvbGtzIHVwIGluIHRoZQ0KPiBkaXJlY3RvcnkgSSBkbyBp dCB2aWEgdGhlaXIgbmFtZSwgbm90IHRoZWlyIHVzZXJpZC4gIEluIHNvbWUgY2FzZXMsIGl0DQo+ IG1pZ2h0IGJlIGRlc2lyYWJsZSB0byB1c2UgdGhlIHNhbWUgdXNlcmlkIGFjcm9zcyBtdWx0aXBs ZSBtYWNoaW5lcy4NCj4gVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgaGF2aW5nIGV4dHJhIG9wdGlv bmFsIGNvbmZpZ3VyYXRpb24gdG8gZXhwcmVzcw0KPiB0aGlzLiAgT3RoZXJ3aXNlLCBJIHRoaW5r IHRoYXQgdXNlcmlkcyBzaG91bGQgcHJpbWFyaWx5IGJlIHRyZWF0ZWQgYXMNCj4gaW50ZXJuYWwg dXNlciBpZGVudGlmaWVycyB0aGF0IG5lZWQgdG8gcGVyc2lzdGVkIGFsb25nIHdpdGggYW55IGZp bGVzDQo+IGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlci4NCj4gDQo+ID4gDQo+ID4gSW4gYSB3YXks IHRoaXMgY2FzZSBpcyBkaWZmZXJlbnQgYi9jIHRoZSBjbGllbnQgbmVlZHMgY29udHJvbCBvZg0K PiA+ICp3aGVuKiB0aGUga2V5IGlzIGdlbmVyYXRlZC4gIFdlIGNhbm5vdCBjb3B5ICYgcGFzdGUg c29tZSBjb25maWcgdG8NCj4gPiAqYW5vdGhlcg0KPiA+IGRldmljZSBhbmQgZXhwZWN0IGl0IHRv IHdvcmsgZXhhY3RseSB0aGUgc2FtZS4gIE9UT0ggdGhhdCBwcm9iYWJseSBpcw0KPiA+IHRydWUg Zm9yDQo+ID4gb3RoZXIgdGhpbmdzIGFzIHdlbGw7IGlmIGEgdXNlciBoYXMgYmVlbiBjcmVhdGVk IGluIHRoZSBjb25maWcgdGhlcmUNCj4gPiBtaWdodCBiZSBmaWxlcw0KPiA+IG93bmVkIGJ5IHRo YXQgdXNlciBzdG9yZWQgaW4gdGhlIGhvbWUgZGlyZWN0b3J5Lg0KPiA+IA0KPiA+IEFsc28sIHdl IG1pZ2h0IG5lZWQgdGhlIG9wdGlvbiB0byByZS1nZW5lcmF0ZSB0aGUga2V5IChldmVuIHRob3Vn aCB0aGUNCj4gPiBjdXJyZW50DQo+ID4gdmVyc2lvbiBkb2Vzbid0IHN1cHBvcnQgdGhpcykuICBC dXQgKnRoaXMqIGNvdWxkIGJlIGRvbmUgdy8gYW4gYWN0aW9uDQo+ID4gKGlmIHdlIG5lZWQNCj4g PiB0byBzdXBwb3J0IGl0KS4NCj4gDQo+IEV4YWN0bHkuICBVc2luZyBhbiBhY3Rpb24gdG8gcmVn ZW5lcmF0ZSBhbiBpbnRlcm5hbGx5IG1hbmFnZWQga2V5IGlzDQo+IGZpbmUuICBUaGlzIGlzIGVx dWl2YWxlbnQgdG8gYW4gYWN0aW9uIHRvIHJlYm9vdCBhIGxpbmVjYXJkIG9yIGNsZWFyDQo+IHNv bWUgc3RhdGlzdGljcy4gIFRoaXMgaGFzbid0IGNoYW5nZWQgdGhlIGludGVudCBvZiB3aGF0IHRo ZSBkZXNpcmVkDQo+IHN0YXRlIHRoZSBzeXN0ZW0gc2hvdWxkIGJlIGluLg0KPiANCj4gVGhlIGFs dGVybmF0aXZlIHRvIHRoZSBhY3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIHRoZSBjb25maWcsIHdh aXQNCj4gdW50aWwgdGhlIGRldmljZSBoYXMgY29uZmlybWVkIHRoYXQgdGhlIGtleSBpcyByZW1v dmVkIChpbg0KPiBvcGVyYXRpb25hbCksIGFuZCB0aGVuIGNvbmZpZ3VyZSBpdCBhZ2Fpbi4NCg0K Tm90IHZlcnkgbmljZSwgc2luY2UgeW91IG1heSBoYXZlIGxlYWZyZWZzIHRvIHRoZSBrZXlzIHRo YXQgd291bGQgaGF2ZQ0KdG8gYmUgcmVtb3ZlZCBhcyB3ZWxsLCBhbmQgc28gb24uDQoNCj4gPiBX aGF0IGRpZCBJIG1pc3M7IHdoYXQgbWFrZXMgdGhpcyBjYXNlIHNwZWNpYWwgc28gdGhhdCBpdCBj YW4ndCBiZQ0KPiA+IGhhbmRsZWQgbGlrZQ0KPiA+IG90aGVyIGNvbmZpZz8NCj4gDQo+IEZvciBt ZSwgSSB0aGluayB0aGF0IHRoZSBzcGVjaWFsIGNhc2VzIGFyZToNCj4gIChpKSBUaGUgYWJpbGl0 eSB0byBmb3JjZSBhIGtleSB0byBiZSByZWNyZWF0ZWQgKGkuZS4gdGhlIGFjdGlvbg0KPiAgZGVz Y3JpYmVkIGFib3ZlKQ0KDQpPay4NCg0KPiAgKGlpKSBUaGUgYWJpbGl0eSB0byBwcm9ncmFtIGEg Y2xpZW50IGRlZmluZWQga2V5IHBhaXIgaW4gYSBwcml2YXRlIHdheQ0KPiAgdGhhdCBpcyBub3Qg dmlzaWJsZSBpbiB0aGUgY29uZmlndXJhdGlvbi4gIEhhdmUgd2UgY29uc2lkZXJlZCBhDQo+ICBz b2x1dGlvbiB0aGF0IHB1dHMgdGhlc2UgaW50byB0aGUgY29uZmlndXJhdGlvbiBidXQgaGFzIHRo ZW0gZW5jcnlwdGVkDQo+ICB3aXRoIGEgZGV2aWNlIHNwZWNpZmljIHB1YmxpYy9wcml2YXRlIGtl eSBwYWlyLg0KDQpJIGRvbid0IHRoaW5rIHNvLiAgSSdtIG5vdCBzdXJlIHRoaXMgaXRzZWxmIHNv bHZlcyB0aGUgcHJvYmxlbQ0KdGhvdWdoLiAgRldJVywgd2UgaGF2ZSB0YWlsZi1zcGVjaWZpYyB0 eXBlcyB0aGF0IHdvcmsgbGlrZSB0aGlzLiAgVGhleQ0KYXJlIHNpbWlsYXIgdG8gaWFuYS1jcnlw dC1oYXNoIGluIHN5bnRheCBhbmQgc2VtYW50aWNzLCBidXQgdGhleSB1c2UNCmVuY3J5cHRpb24g cmF0aGVyIHRoYW4gaGFzaGluZy4NCg0KDQovbWFydGluDQo= From nobody Fri May 3 06:46:48 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0F212002F for ; Fri, 3 May 2019 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQlhmoQG6r4c for ; Fri, 3 May 2019 06:46:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F77D120100 for ; Fri, 3 May 2019 06:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5892; q=dns/txt; s=iport; t=1556891205; x=1558100805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7DFPHUL+1KvxHBGCRV/vx37y8obFNM48LBpT2QdrX1g=; b=LtdncqmRz4rBQRUqgFRIvcPQbw49PSyHWlVLwY8HvRtD0tFbufFc33aO wtR/msLW8llIRw0vCgr1W6OLBUFiSe5jzTIRDyTODWrejYcuKrVqnnqSf G469L4VIbZhmUjon71XYW2CgGvUImhuQdtlipaqaDYy7cBljr2mByoI20 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAABvRcxc/4MNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGCEGmBBCgKhAaVJJhSgXsOAQEYC4QERgIXgW8?= =?us-ascii?q?jNgcOAQMBAQQBAQIBAm0cDIVKAQEBAwEBASEROgsMBAIBBgIRBAEBAwImAgI?= =?us-ascii?q?CJQsVCAgBAQQBDQUIE4MIgXsPD5Ikm2WBL4oygQsnAYoKgUMXgUA/hCM+gmE?= =?us-ascii?q?BAYFLgyCCWASDNYdfgj2EbJR1CQKCCZI9I5VIg26ILYsdiUwCERWBMCYDLoF?= =?us-ascii?q?WcBU7gmwJghIXg0yFFIU/QTGQH4EhAQE?= X-IronPort-AV: E=Sophos;i="5.60,425,1549929600"; d="scan'208";a="552639476" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2019 13:46:43 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x43Dkh3g010177 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 May 2019 13:46:43 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 May 2019 08:46:42 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 3 May 2019 08:46:43 -0500 From: "Rob Wilton (rwilton)" To: tom petch , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAhxAf5w Date: Fri, 3 May 2019 13:46:42 +0000 Message-ID: <435aee7585f1425c9ed1c7a07c216dd0@XCH-RCD-007.cisco.com> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com> <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net> In-Reply-To: <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net> 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.60] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 13:46:47 -0000 SGkgVG9tLCANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0b20gcGV0 Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb20+DQo+IFNlbnQ6IDAzIE1heSAyMDE5IDEyOjMyDQo+IFRv OiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBNYXJ0aW4gQmpvcmts dW5kIDxtYmpAdGFpbC0NCj4gZi5jb20+DQo+IENjOiBuZXRjb25mQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4N Cj4gDQo8c25pcHBlZD4NCj4gPiA+ID4NCj4gPiA+ID4gV2hhdCBkaWQgSSBtaXNzOyB3aGF0IG1h a2VzIHRoaXMgY2FzZSBzcGVjaWFsIHNvIHRoYXQgaXQgY2FuJ3QgYmUNCj4gPiA+ID4gaGFuZGxl ZCBsaWtlIG90aGVyIGNvbmZpZz8NCj4gPiA+DQo+ID4gPiBJZiBJIGNvbmZpZ3VyZSBhbiBpbnRl cmZhY2UsIEkgYW0gcHJvdmlkaW5nIGF0IGxlYXN0IHBhcnQgb2YgdGhlDQo+ID4gPiBpbmZvcm1h dGlvbiBhbmQgYW55dGhpbmcgdGhhdCB0aGUgZGV2aWNlIGdlbmVyYXRlcyAtIGludGVyZmFjZSBu YW1lLA0KPiBNVFUsDQo+ID4gPiBwcml2YWN5IGFkZHJlc3MgLSBJIGNhbiB0aGVuIHNlZSBhbmQg bWF5IG9yIG1heSBub3QgYmUgYWJsZSB0bw0KPiBjaGFuZ2UuDQo+ID4gPg0KPiA+ID4gV2hlbiBJ IGdlbmVyYXRlIGEga2V5IHBhaXIsIHllcyBJIHdhbnQgdG8gc2VlIHRoZSBwdWJsaWMga2V5IGJ1 dCBJDQo+IGhhdmUgbm8NCj4gPiA+IGludGVyZXN0IGluIHRoZSBwcml2YXRlIGtleS4gIEkgd2Fu dCB0aGUgZGV2aWNlLCBhbmQgaXQgaXMgdGhlDQo+IGRldmljZSBub3QNCj4gPiA+IGFuIGluZGl2 aWR1YWwgdXNlciwgdG8gYmUgYWJsZSB0byBkbyB0aGluZ3Mgd2l0aCB0aGUgcHJpdmF0ZSBrZXks DQo+IG5vdGFibHkNCj4gPiA+IHRvIGdlbmVyYXRlIGEgY2VydGlmaWNhdGUgZm9yIHRoZSBkZXZp Y2U7IEkgbm93IHNlZSBvcmdhbmlzYXRpb25zDQo+IHdoZXJlDQo+ID4gPiBldmVyeSBkZXZpY2Ug dGhhdCBpcyBhdHRhY2hlZCB0byB0aGUgbmV0d29yayBtdXN0IGhhdmUgaXRzIG93bg0KPiBjZXJ0 aWZpY2F0ZQ0KPiA+ID4gcmVnYXJkbGVzcyBvZiB3aGF0IHRoZSBkZXZpY2UgaXMsIHdobyBvd25z IGl0LCB3aG8gaXMgbG9nZ2VkIG9udG8gaXQNCj4gZXRjLg0KPiA+ID4NCj4gPiA+IFNvIGdlbmVy YXRlIGEga2V5IHBhaXIsIGtlZXAgdGhlIHByaXZhdGUgcHJpdmF0ZSwgdXNlIGl0IGZvciBhDQo+ IGNlcnRpZmljYXRlLA0KPiA+ID4gYnV0IEkgd2lsbCBuZXZlciBjaGFuZ2UgaXQsIGRvbid0IHdh bnQgdG8ga25vdyBpdCBpcywgSSBqdXN0IHdhbnQgaXQNCj4gPiA+IHNlY3VyZWx5IGhpZGRlbiAt IGFuZCBpdCBpcyB1bmxpa2VseSB0aGF0IHRoZSBub3RlcGFkLCBzbWFydFBob25lLA0KPiBsYXB0 b3ANCj4gPiA+IGV0YyB3aWxsIGhhdmUgYSBUUE0uDQo+ID4gPg0KPiA+ID4gVGhpcyBpcyB0aGUg cG9saWN5IG9mIHRoZSBtb3N0IHNlY3VyaXR5LWNvbnNjaW91cyBvcmdhbmlzYXRpb24gSQ0KPiBr bm93LCB0aGUNCj4gPiA+IG9ubHkgb25lIHdob3NlIHBhc3N3b3JkcyB3b3VsZCBtZWV0IHRoZSBj cml0ZXJpYSBsYWlkIGRvd24gaW4gUkZDLA0KPiBidXQgaXQNCj4gPiA+IGhhcyBvbmx5IGJlZW4g YXJvdW5kIGZvciBhIHllYXIgb3Igc28gc28gSSBleHBlY3Qgb3RoZXJzIHdpbGwgZm9sbG93DQo+ IHN1aXQuDQo+ID4NCj4gPiBUaGlzIGlzIGFsbCBmaW5lIGFuZCBzb3VuZHMgc2Vuc2libGUgdG8g bWUuDQo+ID4NCj4gPiBUaGUgcHVibGljIGtleSBjYW4gYmUgcHVibGlzaGVkIGluIDxvcGVyYXRp b25hbD4uDQo+ID4NCj4gPiBCdXQgd2h5IGRvZXMgdGhlcmUgbmVlZCB0byBiZSBhIHNlcGFyYXRl IFlBTkcgYWN0aW9uIHJlcXVpcmVkIHRvDQo+IGdlbmVyYXRlIHRoZSBwdWJsaWMvcHJpdmF0ZSBr ZXkgcGFpciBvbiB0aGUgZGV2aWNlPw0KPiANCj4gSG93IGVsc2UgaXMgdGhlIGtleSBwYWlyIGdv aW5nIHRvIGNvbWUgaW50byBleGlzdGVuY2U/ICBUaGUgZGV2aWNlIGlzIG5vdA0KPiBzaGlwcGVk IHdpdGggb25lIChhbHRob3VnaCBpdCBpcyB0aGUgc29ydCBvZiB0aGUgdGhpbmcgdGhhdCBhIE1p Y3Jvc29mdA0KPiBtaWdodCBvcmdhbmlzZSBpZiBpdCBiZWNvbWVzIHRoZSBub3JtKS4gIEEgdXNl ciAod2l0aCBzdWl0YWJsZQ0KPiBjcmVkZW50aWFscykgYnJpbmdzIGluIGhpcyBkZXZpY2UsIHRo ZSBvcmdhbmlzYXRpb24gc2F5cyAnZ2VuZXJhdGUga2V5DQo+IHBhaXInLCBhbmQgY2VydGlmaWNh dGUsIGFuZCB0aGUgdXNlciBpcyB0aGVuIGdvb2QgdG8gZ28gZm9yIGhvd2V2ZXIgbG9uZw0KPiB0 aGV5IHVzZSB0aGUgb3JnYW5pc2F0aW9uJ3MgbmV0d29yaywgY291bGQgYmUgeWVhcnM7IGFuZCB5 ZXMsIHRoZSBwdWJsaWMNCj4ga2V5LCBhbmQgY2VydGlmaWNhdGUsIG11c3QgcGVyc2lzdCBpbiB0 aGUgZGV2aWNlIGFjcm9zcyByZXN0YXJ0cyBidXQgbm90LA0KPiBvZiBjb3Vyc2UsIGlmIHRoZSBo YXJkd2FyZSBpcyByZXBsYWNlZCBieSBmcmVzaCBoYXJkd2FyZSAtIGl0IGlzIGEgZGV2aWNlDQo+ IGNlcnRpZmljYXRlLCBub3QgYSB1c2VyIGNlcnRpZmljYXRlLg0KDQpTb3JyeSwgSSBzdGlsbCBk b24ndCBnZXQgaXQsIEknbSBtaXNzaW5nIHNvbWV0aGluZyDwn5iJDQoNCmxpc3QgY3J5cHRvLWtl eXMgew0KICBjb25maWcgdHJ1ZTsNCiAga2V5ICJuYW1lIjsNCiAgbGVhZiAibmFtZSIgeyB0eXBl IHN0cmluZzsgfQ0KICBjaG9pY2Uga2V5LXR5cGUgew0KICAgICBjYXNlIGV4cGxpY2l0IHsNCiAg ICAgICAgbGVhZiBwcml2YXRlLWtleSB7IHR5cGUgYmluYXJ5OyB9DQogICAgICAgIGxlYWYgcHVi bGljLWtleSB7IHR5cGUgYmluYXJ5OyB9DQogICAgIH0NCiAgICAgY2FzZSBhdXRvLWdlbmVyYXRl ZCB7DQogICAgICAgIGxlYWYgYXV0by1nZW5lcmF0ZWQgeyB0eXBlIGJvb2xlYW47IGRlZmF1bHQg ZmFsc2U7IH0NCiAgICAgICAgbGVhZiBwdWJsaWMta2V5IHsgdHlwZSBiaW5hcnk7IGNvbmZpZyBm YWxzZTsgfQ0KICAgICB9DQogIH0NCn0NCg0KSWYgdGhlIGNsaWVudCBjb25maWd1cmVzIGFuIGVu dHJ5IGluIHRoZSBsaXN0IHdpdGggZXhwbGljaXQga2V5cyB0aGVuIHRoYXQgaXMgd2hhdCB0aGUg c2VydmVyIHVzZXMuDQoNCkhvd2V2ZXIsIGlmIHRoZSBjbGllbnQgY29uZmlndXJlcyBhbiBlbnRy eSBpbiB0aGUgbGlzdCB3aXRoIGxlYWYgImF1dG8tZ2VuZXJhdGVkIiBzZXQgdGhhdCB0aGUgZGV2 aWNlIGdlbmVyYXRlcyBhIHB1YmxpYy9wcml2YXRlIGtleSBwYWlyIGFuZCBwZXJzaXN0cyB0aGVt IGludGVybmFsbHkuICBUaGUgcHVibGljLWtleSBpcyBhdmFpbGFibGUgdmlhIHRoZSBjb25maWcg ZmFsc2UgbGVhZi4gIFRoZSBwcml2YXRlIGtleSBpcyBrZXB0IHByaXZhdGUuICBObyBzZXBhcmF0 ZSBZQU5HIGFjdGlvbiBpcyByZXF1aXJlZCB0byBpbnN0YW50aWF0ZSB0aGUga2V5cyAtIGl0IGhh cHBlbnMgYXV0b21hdGljYWxseSBkdWUgdG8gdGhlIGNvbmZpZ3VyYXRpb24uICBXaGF0IGlzIHRo ZSBvYnZpb3VzIHN0ZXAgdGhhdCBJIGFtIG1pc3NpbmcgYXMgdG8gd2h5IHRoaXMgZG9lc24ndCB3 b3JrPyDwn5iJDQoNClRoYW5rcywNClJvYg0KDQoNCj4gDQo+IFRvbSBQZXRjaA0KPiANCj4gPiBX aHkgaXMgdGhlIGNvbmZpZ3VyYXRpb24gaW50ZW50IG9mICJJIHdhbnQgeW91IHRvIHVzZSBhIHNl Y3VyZWx5DQo+IGFsbG9jYXRlZCBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpciIgKHdoaWNoIGNvdWxk IGJlIGluIHRoZSBjb25maWd1cmF0aW9uKQ0KPiBub3Qgc3VmZmljaWVudD8NCj4gPg0KPiA+IElm IHRoZSBpc3N1ZSBpcyB0aGF0IHRoZXNlIGtleXMgbmVlZCB0byBwZXJzaXN0IG92ZXIgZGV2aWNl IHJlc3RhcnQsDQo+IHRoZW4gSSB3b3VsZCB0aGluayB0aGF0IHRoZSBzb2x1dGlvbiBpcyBmb3Ig dGhlIGRldmljZSB0byBzZWN1cmVseSBwZXJzaXN0DQo+IHRoZXNlIGtleXMgaW5kZXBlbmRlbnRs eSBvZiB0aGUgWUFORyBjb25maWd1cmF0aW9uLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFJvYg0K PiA+DQo+ID4NCj4gPiA+DQo+ID4gPiBUb20gUGV0Y2gNCj4gPiA+DQo+ID4gPiA+IC9tYXJ0aW4N Cj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+ID4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbmV0Y29uZkBp ZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCj4gPiA+ID4NCj4gPg0KPiA+DQoNCg== From nobody Fri May 3 06:55:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55171200C5 for ; Fri, 3 May 2019 06:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vDnB-4jtXl7g for ; Fri, 3 May 2019 06:55:08 -0700 (PDT) Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D2C12002F for ; Fri, 3 May 2019 06:55:08 -0700 (PDT) Received: from ex-hc1.corp.adtran.com (ex-hc1.adtran.com [76.164.174.81]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-LWyd_xibNNyfrWws5CjWtw-1; Fri, 03 May 2019 09:55:05 -0400 Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0382.000; Fri, 3 May 2019 08:55:04 -0500 From: Nick Hancock To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] draft-ietf-netconf-keystore-09.txt Thread-Index: AdT/Ypeae5Jx2/tnSQGaoI1kbpVxTQBV+RMAAAPy5nA= Date: Fri, 3 May 2019 13:55:03 +0000 Message-ID: References: <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@email.amazonses.com> In-Reply-To: <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@email.amazonses.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiOWJlN2VhYzUtYWQ1OS00ZTE2LTljMGUtZjU1NGFmZGJiNTcxIiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6InEyNkV6UzcyaFVJb2pncjRPSFNzXC9jYkhcL0YyY0VxQnZPV1wvZTBCanpKVXNUem9GdkNISkcyWFA5aEwwRE82SU4ifQ== x-originating-ip: [172.20.62.161] MIME-Version: 1.0 X-MC-Unique: LWyd_xibNNyfrWws5CjWtw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 13:55:12 -0000 Hi Kent,=20 > -----Original Message----- > From: Kent Watsen > Sent: 02 May 2019 04:42 > To: Nick Hancock > Cc: netconf@ietf.org > Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt >=20 >=20 > Hi Nick, >=20 > You are correct that something is amiss, but I'd like to discuss the fix = more. >=20 > Your proposal looks (squinting my eyes) right (have you tested it?), but = I'm > wondering if there isn't a lower-level and potentially more useful fix... No, I haven't tested it. However, we have implemented similar YANG to=20 access an entry of a list that itself is within a list in the same=20 way successfully in the past. >=20 > In particular, note that 'ks:asymmetric-key-certificate-ref' points to a > certificate in the the keystore that comes from the 'uses=A0ct:asymmetric= -key- > pair-with-certs-grouping' statement. =A0 The idea behind this grouping is= that, > whenever a certificate is configured, whether in the keystore or not, tha= t the > 'asymmetric-key-pair-grouping 3-tuple (alg, pub key, private key) is also > configured. =A0 This suggests that ct:asymmetric-key-pair-with-certs-grou= ping > may be missing a 'must' statement or, more likely (due to the fact that t= he 3- > tuple may only exist in ), its 'description' statement is mi= ssing > that precondition in its text. >=20 > Thoughts? Given that a client has the required permissions, the current model=20 allows a client to create an entry in the list 'asymmetric-key'=20 without the 3-tuple leafs 'algorithm', 'public-key' and 'private-key'=20 as allowed via the must statement on the list. At this point there=20 would be no 3-tuple in either. Defining the 3-tuple in=20 or would be a second step, such as invoking=20 the action 'generate-hidden-key'. Since there is, as you indicated,=20 no 'must' statement relevant to the 'certificate' list, the model=20 also allows a client to configure a certificate (chain) on an entry=20 in the list 'asymmetric-key' without the 3-tuple in either =20 or . The asymmetric key entry would not be able to be=20 used to establish a TLS session due to the missing 3-tuple, of course. Is this a valid use case? Possibly. I could argue that a client may=20 wish to 'park' certificate chains in the keystore without necessary=20 immediately using them on the server or even just pre-provision them=20 and then provide the actual public key later maybe through some other=20 process based on an operator's security policies? It makes no sense=20 to reference a certificate in the keystore that is missing the=20 3-tuple as the server identity of a NETCONF server or client identity=20 of a NETCONF client as it cannot be used, so the question is whether=20 it would make more sense to constrain the actual reference to=20 reference certificates that have 3-tuple, if this is at all possible=20 considering that the 3-tuple may only be in ? During analysis of deploying the keystore and truststore in our=20 implementation, I have made some further observations that may be of=20 interest: 1. There is nothing in the model to prevent a client configuring a=20 certificate to an asymmetric key that is not applicable to that=20 asymmetric key or even a certificate chain in the keystore or=20 truststore that is incompatible to the required type=20 ('end-entity-cert-cms' or 'trust-anchor-cert-cms' respectively)=20 or is this to be rejected by the implementation, in which case=20 this behavior is not described in the YANG? 2. I am not convinced whether the use of the prefix 'pinned-' on the=20 containers and lists in ietf-trust-anchors is correct. The=20 certificates are available in the truststore for pinning, yes, but=20 does not the 'pinning' actually take place when the certificates=20 are configured for client authentication on a server or server=20 authentication on a client? So I would argue that a certificate=20 may be in the trust store, but not necessarily pinned, so the name=20 may be misleading or am I missing something? Thus, I would have=20 expected the containers and lists to be without the 'pinned-'=20 prefix within the truststore itself. The 'pinned-' prefix being=20 only on the references, which is the case in the NETCONF client=20 and server models. 3. As an initial step we are analyzing the standalone use of the=20 keystore in truststore modules and were considering some=20 proprietary notifications that would include the certificate=20 (chain) received during TLS session establishment, but could not=20 'use' the groupings in ietf-crypt-types because they include=20 actions and notifications, which are not allowed in notifications.=20 Maybe it would be advantageous to provide basic groupings without=20 actions and notifications for use in proprietary RPCs and=20 notifications and provide refined versions of these groupings that=20 include the actions and notifications? Obviously this would mean=20 even more groupings, but wouldn't this increase their reusability? Regards Nick >=20 > Kent // contributor >=20 >=20 >=20 >=20 > On Apr 30, 2019, at 11:39 AM, Nick Hancock > wrote: >=20 > Hi Kent, >=20 > I have just noticed a issue with the leaf 'keystore-reference' used > in the grouping 'local-or-keystore-end-entity-cert-with-key-grouping' > in ietf-keystore. >=20 > This leafref uses the typedef 'asymmetric-key-certificate-ref', but, > unless I am missing something, this alone will not work, because a > predicate for the list 'asymmetric-key' is missing. >=20 > I would expect something like the following: >=20 > case keystore { > =A0if-feature "keystore-supported"; > =A0leaf asymmetric-key-name { > =A0=A0=A0type ks:asymmetric-key-ref; > =A0=A0=A0=A0=A0description > =A0=A0=A0=A0=A0=A0=A0"A reference to an asymmetric key that exists in > =A0=A0=A0=A0=A0=A0=A0=A0the keystore. "; > =A0} > =A0leaf certificate-name { > =A0=A0=A0type leafref { > =A0=A0=A0=A0=A0path > =A0=A0=A0=A0=A0=A0=A0"/ks:keystore" > =A0=A0=A0=A0=A0=A0=A0+ "/ks:asymmetric-keys" > =A0=A0=A0=A0=A0=A0=A0+ "/ks:asymmetric-key" > =A0=A0=A0=A0=A0=A0=A0+ "[ks:name=3Dcurrent()/../" > =A0=A0=A0=A0=A0=A0=A0+ "asymmetric-key-name]" > =A0=A0=A0=A0=A0=A0=A0+ "/ks:certificates" > =A0=A0=A0=A0=A0=A0=A0+ "/ks:certificate/ks:name"; > =A0=A0=A0} > =A0=A0=A0description > =A0=A0=A0=A0"A reference to a specific certificate associated > =A0=A0=A0=A0=A0with the given private key, stored in the keystore."; > =A0} > } >=20 > Regards > Nick From nobody Fri May 3 09:10:01 2019 Return-Path: <0100016a7e759062-1a4a8a21-1eb1-469b-b1f3-136ae411d034-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FA51200EF for ; Fri, 3 May 2019 09:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Shwz14B4ETb for ; Fri, 3 May 2019 09:09:56 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3621200E3 for ; Fri, 3 May 2019 09:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556899795; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=QLstcES3h5szAlbsubAjXfM0olHCZJpgY0/Kxl7T0cY=; b=NX6oLkXnByb3q/J0I9F01R+vhN6gCLyhG4lo1ZPeaq3CelaHQNjPjRLbdyzLSAEl pLQ6UWJJ6l4mKvBXVQtqn3KYuZezZSAAz82NYDDvqxCPQrn84MAC4oF4CpeFuWvZvq3 uBws2tTe1uj66YALEVweeaBfNbNxZIvGAZZmQGRQ= From: Kent Watsen Message-ID: <0100016a7e759062-1a4a8a21-1eb1-469b-b1f3-136ae411d034-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_769C2580-D271-47E6-B921-9A4C6B4054A6" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 3 May 2019 16:09:55 +0000 In-Reply-To: <20190503.090809.1872906124999950846.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <20190501.230622.158012882760210627.mbj@tail-f.com> <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@email.amazonses.com> <20190503.090809.1872906124999950846.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.03-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 16:09:58 -0000 --Apple-Mail=_769C2580-D271-47E6-B921-9A4C6B4054A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I don't think the last column is less important. That's the TPM case, = right? Yes, the last column is the TPM case, which are very important to = support, but there's a subtly between: a) there exists a TPM that the manufacturer uses to generate a protected = private key, e.g., in order to pre-provision the device with an IDevID = certificate. (this is a hyper-critical use case to support) and b) there exists a TPM that average clients can use to generate a = protected private key. The motivation behind this is unclear to me, but = perhaps because 1) the owner wants to use an LDevID certificate instead = of the IDevID certificate, 2) the owner requires that the private key is = TPM-protected, and 3) the device is unable to generate a second CSR = using the same private key used for the IDevID certificate. (given that = I believe #3 SHOULD be supported, this use case seems less important, = bordering on not important). > For the "no solution" case, it means that the client doesn't want to > write the private key, but it wants to read it. Why should it read it > if it never writes it? The whole point would be to be able to > re-generate the config on another device - but this would mean that > the client would use to pass the key, and it would be in > the upper left cell in table above. We have to envision different classes of clients: regular-access and = special-access. Regular access clients should be able to ask the system = the generate a private key to which they have no read-access. Special = access clients have read (and write) access, but presumably are only = ever used to perform backup/restore operations. > An option could perhaps be to let the "generate-key" with option > "not-hidden" create the private key in (still with > nacm:default-deny-all). To re-create the key on another device, the > client would use install-key. Yes, this is the goal, to enable not-hidden keys to be migrated to = another device (but only by a special-access client). Kent // contributor --Apple-Mail=_769C2580-D271-47E6-B921-9A4C6B4054A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I don't think the last column is less important.  That's = the TPM case, right?

Yes, = the last column is the TPM case, which are very important to support, = but there's a subtly between:

a) = there exists a TPM that the manufacturer uses to generate a protected = private key, e.g., in order to pre-provision the device with an IDevID = certificate.  (this is a hyper-critical use case to = support)

and

b) there exists a TPM that average clients can use = to generate a protected private key.  The motivation behind = this is unclear to me, but perhaps because 1) the owner wants to use an = LDevID certificate instead of the IDevID certificate, 2) the owner = requires that the private key is TPM-protected, and 3) the device is = unable to generate a second CSR using the same private key used for the = IDevID certificate.  (given that I believe #3 SHOULD be supported, = this use case seems less important, bordering on not = important).



For the "no solution" case, = it means that the client doesn't want to
write the private = key, but it wants to read it.  Why should it read it
if= it never writes it?  The whole point would be to be able to
re-generate the config on another device - but this would = mean that
the client would use <edit-config> to pass = the key, and it would be in
the upper left cell in table = above.

We have to envision different classes of clients: = regular-access and special-access.  Regular access clients should = be able to ask the system the generate a private key to which they have = no read-access.  Special access clients have read (and write) = access, but presumably are only ever used to perform backup/restore = operations.



An option could perhaps be to = let the "generate-key" with option
"not-hidden" create the = private key in <operational> (still with
nacm:default-deny-all).  To re-create the key on another = device, the
client would use install-key.

Yes, this = is the goal, to enable not-hidden keys to be migrated to another device = (but only by a special-access client).


Kent // = contributor


= --Apple-Mail=_769C2580-D271-47E6-B921-9A4C6B4054A6-- From nobody Fri May 3 09:15:31 2019 Return-Path: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D7C1200EF for ; Fri, 3 May 2019 09:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Tl8IJOwQ-nde for ; Fri, 3 May 2019 09:15:27 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71841200E3 for ; Fri, 3 May 2019 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556900126; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=8lkZiGn2BZ0N/NBNiDe4bmH/S62GMLhKZGS8AJ10aVY=; b=EXMmbTMUPJbwJE31jBnroVkcwa/ORWQe4AoS+3bz7GABfyuTHhTArlKoftoY7Ich 7+ab0fnKGlzDPkrurIXaCcH9M/gqtU0ZjLy6an5j+tWVCRGB/77+kbQIRhjSonY/jNv HdL6IkuGGhaDbt0Cwsqk19Ve11jPAaQd/y8xY4Pg= From: Kent Watsen Message-ID: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AC924030-FE1E-4EBD-A9C0-CAF5E0995508" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 3 May 2019 16:15:26 +0000 In-Reply-To: <20190503.133743.1149689382943153005.mbj@tail-f.com> Cc: rwilton@cisco.com, "netconf@ietf.org" To: Martin Bjorklund References: <20190503.084757.791827158808672980.mbj@tail-f.com> <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> <20190503.133743.1149689382943153005.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.03-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 16:15:29 -0000 --Apple-Mail=_AC924030-FE1E-4EBD-A9C0-CAF5E0995508 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> (ii) The ability to program a client defined key pair in a private = way >> that is not visible in the configuration. Have we considered a >> solution that puts these into the configuration but has them = encrypted >> with a device specific public/private key pair. >=20 > I don't think so. I'm not sure this itself solves the problem > though. FWIW, we have tailf-specific types that work like this. They > are similar to iana-crypt-hash in syntax and semantics, but they use > encryption rather than hashing. Encrypting "hidden" keys is a viable option that would enable such keys = to appear in standard config and hence support the "document model" = (backup/restore operations using, e.g., ). The only catch = is that the restore-operation *only* works on the same device (or, more = specifically, the same crypto-processor). Still, this would help the = scenario where the device needs to be restored after having its = non-volatile memory reformatted or replaced. I was also thinking about the relation to crypt-hash, but the scenarios = is different in that the crypt-hash operation is idempotent; passing in = a "$0$" prefixed password will always produce the same result. In the = "best practice" scenario, no private-key data is passed in, and just = asking the device to generate a random key each time will give different = results each time (not idempotent). Kent // contributor= --Apple-Mail=_AC924030-FE1E-4EBD-A9C0-CAF5E0995508 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(ii) The ability to = program a client defined key pair in a private way
that = is not visible in the configuration.  Have we considered a
solution that puts these into the configuration but has them = encrypted
with a device specific public/private key = pair.

I don't think so. =  I'm not sure this itself solves the problem
though. =  FWIW, we have tailf-specific types that work like this. =  They
are similar to iana-crypt-hash in syntax and = semantics, but they use
encryption rather than = hashing.


Encrypting "hidden" keys is a viable option that = would enable such keys to appear in standard config and hence support = the "document model" (backup/restore operations using, e.g., = <copy-config>).  The only catch is that the restore-operation = *only* works on the same device (or, more specifically, the same = crypto-processor).  Still, this would help the scenario where the = device needs to be restored after having its non-volatile memory = reformatted or replaced.

I was also = thinking about the relation to crypt-hash, but the scenarios is = different in that the crypt-hash operation is idempotent; passing in a = "$0$" prefixed password will always produce the same result.  In = the "best practice" scenario, no private-key data is passed in, and just = asking the device to generate a random key each time will give different = results each time (not idempotent).


Kent // = contributor
= --Apple-Mail=_AC924030-FE1E-4EBD-A9C0-CAF5E0995508-- From nobody Fri May 3 09:23:44 2019 Return-Path: <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3F1200EF for ; Fri, 3 May 2019 09:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tmhiist6OcS for ; Fri, 3 May 2019 09:23:41 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9BF1200E3 for ; Fri, 3 May 2019 09:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556900620; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=IFzfvZ2Yhw4IWFHjDYiwoKUwjphWZ90LqAWVB5oNZIk=; b=Q1pCar3SoXCdVKSHJ7Lpg67ZdBKZCQarodqJZWwz24e2P6nwyWahmv/BSeMKwuJ6 QaB0AlctHyWsmMnQKvfdIWrzPEtLs1LjJ0ySpBNEe1Ja64zlLY2Tf5N5Tz/QQVXLNF2 NbmXx0FwAOgtVRndbPw0SEGfnw/JwEGClO9UNxak= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_FB52849F-CC35-44AF-A795-66254099705F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 3 May 2019 16:23:40 +0000 References: <20190503.084757.791827158808672980.mbj@tail-f.com> <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> <20190503.133743.1149689382943153005.mbj@tail-f.com> <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> Message-ID: <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.03-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 16:23:43 -0000 --Apple-Mail=_FB52849F-CC35-44AF-A795-66254099705F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I had an idea last night that might inch us closer to a solution. =20 Essentially, the generate/install-key operations always populate = , even for keys that are not-hidden, but then a follow-up = operation (something like ) replicates the not-hidden key = in to . Two options: 1) A regular-access admin executes the actions to generate the key, get = a CSR, configure a resulting signed certificate, etc. and then, as a = second step later in time, a special-access admin replicates the key to = (perhaps using standard and ), so = that it can be included in a standard backup and restored to *any* = device (since this key is "not-hidden", it isn't encrypted with a = device-specific key and hence can be migrated). 2) A regular-access admin executes the actions to generate the key, get = a CSR, configure a resulting signed certificate, etc. and then, as a = second step (ideally immediately after), the regular-access admin = executes a command like , but rather than copying the = entire datastore, it just copies a subtree. =20 Neither option seems great. #1 is unappealing being it necessitates = coordination between clients. #2 is unappealing because defining a = generic operation for this special case seems too much. =20 IMO, allowing to create the configuration directly is the = only client-friendly answer. Kent // contributor --Apple-Mail=_FB52849F-CC35-44AF-A795-66254099705F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I had an idea last night that might inch us closer to a = solution.  

Essentially, the = generate/install-key operations always populate <operational>, = even for keys that are not-hidden, but then a follow-up operation = (something like <copy-config>) replicates the not-hidden key in = <operational> to <running>.    Two = options:

1) A regular-access admin = executes the actions to generate the key, get a CSR, configure a = resulting signed certificate, etc. and then, as a second step later in = time, a special-access admin replicates the key to <running> = (perhaps using standard <get-confg> and <edit-config>), so = that it can be included in a standard backup and restored to *any* = device (since this key is "not-hidden", it isn't encrypted with a = device-specific key and hence can be migrated).

2) A regular-access admin executes the actions to = generate the key, get a CSR, configure a resulting signed certificate, = etc. and then, as a second step (ideally immediately after), the = regular-access admin executes a command like <copy-config>, but = rather than copying the entire datastore, it just copies a subtree. =   

Neither option seems = great.  #1 is unappealing being it necessitates coordination = between clients.  #2 is unappealing because defining a generic = operation for this special case seems too much. =   

IMO, allowing = <generate-key> to create the configuration directly is the only = client-friendly answer.


Kent // contributor

= --Apple-Mail=_FB52849F-CC35-44AF-A795-66254099705F-- From nobody Fri May 3 14:48:14 2019 Return-Path: <0100016a7fab3d80-cc7c913b-9ef7-4c37-b2f2-a38bb5b3a91c-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2F9120130 for ; Fri, 3 May 2019 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tKpVwVTj0PG for ; Fri, 3 May 2019 14:48:12 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17C7120162 for ; Fri, 3 May 2019 14:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556920090; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=tFEC6/RaYpzsghgcNzxAxBRW2PjSv+nl8Kqb/s1x+Z8=; b=XUx7cXyb9XOYIXqxv6W/jcSAWNzTuXLgNCptcC6WBrSlV4U1GyHy9T3FUCPJJdsB pnj+H3W35veAs+d3dfx/UazuJ2ovLNi6a5XLZc0MukVybmwHigoF1bCE14qaVrISwLI JI33VA1GHAfHC07k3f6d1jDdPSSy09jCH+8v2lFM= 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: Fri, 3 May 2019 21:48:10 +0000 References: <20190503.084757.791827158808672980.mbj@tail-f.com> <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> <20190503.133743.1149689382943153005.mbj@tail-f.com> <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> Message-ID: <0100016a7fab3d80-cc7c913b-9ef7-4c37-b2f2-a38bb5b3a91c-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.102.3) X-SES-Outgoing: 2019.05.03-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 21:48:14 -0000 [WARNING: wide-screen needed] > IMO, allowing to create the configuration directly is = the only client-friendly answer. Speaking of friendly solutions, the current solution struggles on = another point too. In particular, it is troubling that = public-key-grouping and asymmetric-key-grouping nodes aren't "mandatory = true". The reason these fields are not "mandatory true" is captured in = ietf-crypto-types: [These] nodes are not mandatory because they MAY be defined in . Implementations SHOULD assert that these values are either configured or that they exist in ."; How did we get here? =20 1) We needed to support manufacturer-generated private key and IDevID = certificate, which would be in with origin=3D"system" and, = in order to support leafrefs to the manufacturer-generated IDevID cert, = we said that the client needs to create an "overlay" key in = (by "name" only). [note that this was after exploring a solution using = "require-instance false"] 2) We felt that, in order to use the `generate/install-hidden-key` = actions, the "config true" parent node should be created first and then = these actions would only populate descendent values in . To recap, following is an abbreviated version of what's in the current = keystore draft: +--rw keystore +--rw asymmetric-keys +--rw asymmetric-key* [name] +--rw name +--rw algorithm? <--- = optional? +--rw public-key? <--- = optional? +--rw private-key? union <--- = optional? (note union) +---x generate-hidden-key +---x install-hidden-key +---x generate-certificate-signing-request +--rw certificates +--rw certificate* [name] This seems messy. Let's reconstruct the solution from basics, and build = up from there... First, assuming no hidden-keys or special actions, we would have this: +--rw keystore +--rw asymmetric-keys +--rw asymmetric-key* [name] +--rw name +--rw algorithm <--- not = optional. +--rw public-key <--- not = optional. +--rw private-key binary <--- not = optional. (note binary) +---x generate-certificate-signing-request +--rw certificates +--rw certificate* [name] Note that the private-key type is just "binary", because there isn't a = need for a union with the "permanently-hidden" value. Now, adding back support for manufacturer-generated private key and = IDevID certificate (but WITHOUT the ability for clients to create their = own TPM-protected keys), we could have this: +--rw keystore +--rw asymmetric-keys +--rw asymmetric-key* [name] +--rw name +--rw algorithm <--- not = optional. +--rw public-key <--- not = optional. +--rw private-key ct:private-key <--- not = optional. (note ct:private-key) +---x generate-certificate-signing-request +--rw certificates +--rw certificate* [name] There are two differences: - the private key type is changed (more on that below) - there's an implicit assumption that the manufacturer-generated = private key and IDevID certificate will initially only exist in (w/ = origin=3D"system") and that the client MUST first COPY those values into before they = can be referenced by configuration. Regarding the "ct:private-key" type, rather then using the "union" we = have today (between a binary value and the string "permanently-hidden"), = it would be better to accommodate the recently-discussed idea that the = device MAY be able to encrypt the TPM-protected private key. For = instance: typedef private-key { type union { type binary; // the real value of the private key type string { pattern '[A-Za-z0-9+/]+[=3D]*' { description "Used for hidden-keys the device is able to encrypt. The base64-encoded encrypted private key, prefixed by the sting '', where the 'by' value is a device specific value that might represent, e.g., the device's serial number, the TPM's serial number, and/or the specific key identifier within the TPM."; } } type enumeration { enum permanently-hidden { description "Used for hidden-keys the device is unable to encrypt."; } } } } =20 Now let's add back the ability for a client to request a "not-hidden" = key to be created (note: we only need the 'generate' action, since = is effectively the same as an 'install' action): +--rw keystore +--rw asymmetric-keys +--x generate-key <-- LOOK HERE | +--w input | +--w name // "name" MUST NOT conflict with any = other name in use | +--w algorithm +--rw asymmetric-key* [name] +--rw name +--rw algorithm=20 +--rw public-key +--rw private-key=20 +---x generate-certificate-signing-request +--rw certificates +--rw certificate* [name] Note that the action has been added to the parent "container", to avoid = to need for the client to first have to create the "asymmetric-key" in = . Now let's discuss what this action does. Two options: 1) it generates values in . This is most friendly, but gives = some folks heartburn ;) 2) it generates values in , thus necessitating that the = client MUST first COPY those values into before they can be referenced by = configuration. Note that this is exactly the same language used above, with respect to a = manufacturer-generated private key and IDevID certificate. If we stopped here, I think we'd have a go-to-market solution, but let's = enable `generate-key` to be able to create a "hidden" key: +--rw keystore +--rw asymmetric-keys +--x generate-key | +--w input | +--w name | +--w hidden? boolean {hidden-keys-supported}? = <--- LOOK HERE | +--w algorithm +--rw asymmetric-key* [name] +--rw name +--rw algorithm=20 +--rw public-key=20 +--rw private-key +---x generate-certificate-signing-request +--rw certificates +--rw certificate* [name] Now the only thing left is the ability to install a hidden key, which = could be supported as follows: +--rw keystore +--rw asymmetric-keys +--x generate-key | +--w input | +--w name | +--w hidden? boolean {hidden-keys-supported}? | +--w algorithm +--x install-hidden-key {hidden-keys-supported}? <-- = NOTE "hidden" in name and | +--w input no = "hidden" input param... | +--w name | +--w algorithm | +--w public-key=20 | +--w private-key +--rw asymmetric-key* [name] +--rw name +--rw algorithm=20 +--rw public-key=20 +--rw private-key=20 +---x generate-certificate-signing-request +--rw certificates +--rw certificate* [name] Presumably how this action works would be similar to how the = `generate-key` action works. This is what I think we should do. Kent // contributor From nobody Fri May 3 16:57:28 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9894120092; Fri, 3 May 2019 16:57:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155692784695.7217.908270903914526669.idtracker@ietfa.amsl.com> Date: Fri, 03 May 2019 16:57:26 -0700 Archived-At: Subject: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 23:57:27 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It looks like the description of filter-failure-hint in modify-subscription-stream-error-info needs the same treatment that establish-subscription-stream-error-info received. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [original comment section replaced] In the updated security considerations: The replay mechanisms described in Sections Section 2.4.2.1 and Section 2.5.6 provides access to historical event records. By design, the access control model that protects these records could enable subscribers to view data to which they were not authorized at the time of collection. Looks like there's some xml2rfc redundancy ("Sections Section"). o "excluded-event-records": leaf can provide information about filtered event records. A network operator should have permissions to know about such filtering. Improper configuration could provide a receiver with information leakage consisting of the dropping of event records. In mail I had proposed "Improper configuration could allow a receiver to learn that event records were dropped due to an ACL when the existence of that ACL would otherwise be transparent."; repeating it here just in case it got missed (but this remains the non-blocking comment section). From nobody Sat May 4 04:55:33 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E6120044 for ; Sat, 4 May 2019 04:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERzBJQco4y_r for ; Sat, 4 May 2019 04:55:29 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70139.outbound.protection.outlook.com [40.107.7.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA92F120026 for ; Sat, 4 May 2019 04:55:28 -0700 (PDT) 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=dMAs39RJJswQsVJcXC7TwDpPHHRynrGQckG7g8hw28I=; b=T5QEWVxE5KsrLQrlFWsXI+sWkr1ezHWHfh6FwTCSftx0FfG4ziX2U37Usz3k9ZWb32/CMVTIR+zosbx6fqZ4ZoDRmlCkYMRgdQkeO6KT5t6CoV+kMcGj3iQlaPC5Hyvpmp+ZRZrd6ZwVohpqClM84UOj+T0+E44E6boR3aRRX00= Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB4160.eurprd07.prod.outlook.com (20.176.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.13; Sat, 4 May 2019 11:55:25 +0000 Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Sat, 4 May 2019 11:55:25 +0000 From: tom petch To: "Rob Wilton (rwilton)" , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AQHVAZ25vWzSND4r/0+wKWIH0SB1HQ== Date: Sat, 4 May 2019 11:55:25 +0000 Message-ID: <01ea01d5026f$c5196960$4001a8c0@gateway.2wire.net> References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com> <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net> <435aee7585f1425c9ed1c7a07c216dd0@XCH-RCD-007.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0277.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::25) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20559873-cb95-4ab6-5861-08d6d08764f2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4160; x-ms-traffictypediagnostic: VI1PR07MB4160: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0027ED21E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(396003)(346002)(376002)(13464003)(199004)(189003)(71200400001)(71190400001)(14496001)(486006)(68736007)(66066001)(62236002)(44716002)(446003)(99286004)(6306002)(86152003)(61296003)(81686011)(6246003)(4720700003)(53936002)(76176011)(316002)(81816011)(110136005)(52116002)(6512007)(9686003)(66446008)(66946007)(73956011)(66556008)(64756008)(66476007)(84392002)(6116002)(3846002)(229853002)(25786009)(2906002)(4326008)(1556002)(44736005)(6436002)(305945005)(6486002)(476003)(8936002)(8676002)(7736002)(81156014)(50226002)(81166006)(186003)(26005)(6506007)(102836004)(53546011)(5024004)(14444005)(256004)(45080400002)(478600001)(14454004)(386003)(966005)(86362001)(5660300002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4160; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OavfRBhJOm6yhKTYBdCEvQzAW0a18ucjfPgQ+HvyLofych38U+yE/AYTAw69ZB8Ti38tNHUwgAM3pse0Gsrc4L+O9ltxvBjPx/JaNcH+skkG9DUl2kn1BYC5A2YqjBAVZWAHw538HYhSlcrgSOzAFrlPqd1v9G+Fkj1JvjPkzP2y+p3mZaCcT7TVx13u4/J1oDpnwRCO/nhxgsiz7ZFmwVLqrP+cgJHyo4ST8T9cv/bJlv/30/wwlZRaIdlsHdnfm1mzH5xnXNVrXDebHKPbVohE2L94JyTUuMn8V9mB06ur+cP9wzKKTCgbC3f5XK2ICbW5uGGr8kC9IptaY42p5FYvP2ttKijLyG7tmmhbycwPc/oEOHSWHvPY86jNoVdUcXRXBvvgWUIh40XP/gUgIkdMVCGflaui8qDy9E2g828= Content-Type: text/plain; charset="utf-8" Content-ID: <51191CDEB6D55A48BE7331CF8460CCCC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20559873-cb95-4ab6-5861-08d6d08764f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2019 11:55:25.7886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4160 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2019 11:55:32 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlJvYiBXaWx0b24gKHJ3aWx0b24p IiA8cndpbHRvbkBjaXNjby5jb20+DQpUbzogInRvbSBwZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5j b20+OyAiTWFydGluIEJqb3JrbHVuZCINCjxtYmpAdGFpbC1mLmNvbT4NCkNjOiA8bmV0Y29uZkBp ZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgTWF5IDAzLCAyMDE5IDI6NDYgUE0NCg0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdG9tIHBldGNoIDxpZXRmY0BidGNvbm5l Y3QuY29tPg0KPiA+IFNlbnQ6IDAzIE1heSAyMDE5IDEyOjMyDQo+ID4gVG86IFJvYiBXaWx0b24g KHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47IE1hcnRpbiBCam9ya2x1bmQNCjxtYmpAdGFp bC0NCj4gPiBmLmNvbT4NCj4gPiBDYzogbmV0Y29uZkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJl OiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8gdHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW4NCj4gPg0K PiA8c25pcHBlZD4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdoYXQgZGlkIEkgbWlzczsgd2hhdCBt YWtlcyB0aGlzIGNhc2Ugc3BlY2lhbCBzbyB0aGF0IGl0IGNhbid0DQpiZQ0KPiA+ID4gPiA+IGhh bmRsZWQgbGlrZSBvdGhlciBjb25maWc/DQo+ID4gPiA+DQo+ID4gPiA+IElmIEkgY29uZmlndXJl IGFuIGludGVyZmFjZSwgSSBhbSBwcm92aWRpbmcgYXQgbGVhc3QgcGFydCBvZiB0aGUNCj4gPiA+ ID4gaW5mb3JtYXRpb24gYW5kIGFueXRoaW5nIHRoYXQgdGhlIGRldmljZSBnZW5lcmF0ZXMgLSBp bnRlcmZhY2UNCm5hbWUsDQo+ID4gTVRVLA0KPiA+ID4gPiBwcml2YWN5IGFkZHJlc3MgLSBJIGNh biB0aGVuIHNlZSBhbmQgbWF5IG9yIG1heSBub3QgYmUgYWJsZSB0bw0KPiA+IGNoYW5nZS4NCj4g PiA+ID4NCj4gPiA+ID4gV2hlbiBJIGdlbmVyYXRlIGEga2V5IHBhaXIsIHllcyBJIHdhbnQgdG8g c2VlIHRoZSBwdWJsaWMga2V5IGJ1dA0KSQ0KPiA+IGhhdmUgbm8NCj4gPiA+ID4gaW50ZXJlc3Qg aW4gdGhlIHByaXZhdGUga2V5LiAgSSB3YW50IHRoZSBkZXZpY2UsIGFuZCBpdCBpcyB0aGUNCj4g PiBkZXZpY2Ugbm90DQo+ID4gPiA+IGFuIGluZGl2aWR1YWwgdXNlciwgdG8gYmUgYWJsZSB0byBk byB0aGluZ3Mgd2l0aCB0aGUgcHJpdmF0ZQ0Ka2V5LA0KPiA+IG5vdGFibHkNCj4gPiA+ID4gdG8g Z2VuZXJhdGUgYSBjZXJ0aWZpY2F0ZSBmb3IgdGhlIGRldmljZTsgSSBub3cgc2VlDQpvcmdhbmlz YXRpb25zDQo+ID4gd2hlcmUNCj4gPiA+ID4gZXZlcnkgZGV2aWNlIHRoYXQgaXMgYXR0YWNoZWQg dG8gdGhlIG5ldHdvcmsgbXVzdCBoYXZlIGl0cyBvd24NCj4gPiBjZXJ0aWZpY2F0ZQ0KPiA+ID4g PiByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGRldmljZSBpcywgd2hvIG93bnMgaXQsIHdobyBpcyBs b2dnZWQNCm9udG8gaXQNCj4gPiBldGMuDQo+ID4gPiA+DQo+ID4gPiA+IFNvIGdlbmVyYXRlIGEg a2V5IHBhaXIsIGtlZXAgdGhlIHByaXZhdGUgcHJpdmF0ZSwgdXNlIGl0IGZvciBhDQo+ID4gY2Vy dGlmaWNhdGUsDQo+ID4gPiA+IGJ1dCBJIHdpbGwgbmV2ZXIgY2hhbmdlIGl0LCBkb24ndCB3YW50 IHRvIGtub3cgaXQgaXMsIEkganVzdA0Kd2FudCBpdA0KPiA+ID4gPiBzZWN1cmVseSBoaWRkZW4g LSBhbmQgaXQgaXMgdW5saWtlbHkgdGhhdCB0aGUgbm90ZXBhZCwNCnNtYXJ0UGhvbmUsDQo+ID4g bGFwdG9wDQo+ID4gPiA+IGV0YyB3aWxsIGhhdmUgYSBUUE0uDQo+ID4gPiA+DQo+ID4gPiA+IFRo aXMgaXMgdGhlIHBvbGljeSBvZiB0aGUgbW9zdCBzZWN1cml0eS1jb25zY2lvdXMgb3JnYW5pc2F0 aW9uIEkNCj4gPiBrbm93LCB0aGUNCj4gPiA+ID4gb25seSBvbmUgd2hvc2UgcGFzc3dvcmRzIHdv dWxkIG1lZXQgdGhlIGNyaXRlcmlhIGxhaWQgZG93biBpbg0KUkZDLA0KPiA+IGJ1dCBpdA0KPiA+ ID4gPiBoYXMgb25seSBiZWVuIGFyb3VuZCBmb3IgYSB5ZWFyIG9yIHNvIHNvIEkgZXhwZWN0IG90 aGVycyB3aWxsDQpmb2xsb3cNCj4gPiBzdWl0Lg0KPiA+ID4NCj4gPiA+IFRoaXMgaXMgYWxsIGZp bmUgYW5kIHNvdW5kcyBzZW5zaWJsZSB0byBtZS4NCj4gPiA+DQo+ID4gPiBUaGUgcHVibGljIGtl eSBjYW4gYmUgcHVibGlzaGVkIGluIDxvcGVyYXRpb25hbD4uDQo+ID4gPg0KPiA+ID4gQnV0IHdo eSBkb2VzIHRoZXJlIG5lZWQgdG8gYmUgYSBzZXBhcmF0ZSBZQU5HIGFjdGlvbiByZXF1aXJlZCB0 bw0KPiA+IGdlbmVyYXRlIHRoZSBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpciBvbiB0aGUgZGV2aWNl Pw0KPiA+DQo+ID4gSG93IGVsc2UgaXMgdGhlIGtleSBwYWlyIGdvaW5nIHRvIGNvbWUgaW50byBl eGlzdGVuY2U/ICBUaGUgZGV2aWNlDQppcyBub3QNCj4gPiBzaGlwcGVkIHdpdGggb25lIChhbHRo b3VnaCBpdCBpcyB0aGUgc29ydCBvZiB0aGUgdGhpbmcgdGhhdCBhDQpNaWNyb3NvZnQNCj4gPiBt aWdodCBvcmdhbmlzZSBpZiBpdCBiZWNvbWVzIHRoZSBub3JtKS4gIEEgdXNlciAod2l0aCBzdWl0 YWJsZQ0KPiA+IGNyZWRlbnRpYWxzKSBicmluZ3MgaW4gaGlzIGRldmljZSwgdGhlIG9yZ2FuaXNh dGlvbiBzYXlzICdnZW5lcmF0ZQ0Ka2V5DQo+ID4gcGFpcicsIGFuZCBjZXJ0aWZpY2F0ZSwgYW5k IHRoZSB1c2VyIGlzIHRoZW4gZ29vZCB0byBnbyBmb3IgaG93ZXZlcg0KbG9uZw0KPiA+IHRoZXkg dXNlIHRoZSBvcmdhbmlzYXRpb24ncyBuZXR3b3JrLCBjb3VsZCBiZSB5ZWFyczsgYW5kIHllcywg dGhlDQpwdWJsaWMNCj4gPiBrZXksIGFuZCBjZXJ0aWZpY2F0ZSwgbXVzdCBwZXJzaXN0IGluIHRo ZSBkZXZpY2UgYWNyb3NzIHJlc3RhcnRzIGJ1dA0Kbm90LA0KPiA+IG9mIGNvdXJzZSwgaWYgdGhl IGhhcmR3YXJlIGlzIHJlcGxhY2VkIGJ5IGZyZXNoIGhhcmR3YXJlIC0gaXQgaXMgYQ0KZGV2aWNl DQo+ID4gY2VydGlmaWNhdGUsIG5vdCBhIHVzZXIgY2VydGlmaWNhdGUuDQo+DQo+IFNvcnJ5LCBJ IHN0aWxsIGRvbid0IGdldCBpdCwgSSdtIG1pc3Npbmcgc29tZXRoaW5nIPCfmIkNCj4NCj4gbGlz dCBjcnlwdG8ta2V5cyB7DQo+ICAgY29uZmlnIHRydWU7DQo+ICAga2V5ICJuYW1lIjsNCj4gICBs ZWFmICJuYW1lIiB7IHR5cGUgc3RyaW5nOyB9DQo+ICAgY2hvaWNlIGtleS10eXBlIHsNCj4gICAg ICBjYXNlIGV4cGxpY2l0IHsNCj4gICAgICAgICBsZWFmIHByaXZhdGUta2V5IHsgdHlwZSBiaW5h cnk7IH0NCj4gICAgICAgICBsZWFmIHB1YmxpYy1rZXkgeyB0eXBlIGJpbmFyeTsgfQ0KPiAgICAg IH0NCj4gICAgICBjYXNlIGF1dG8tZ2VuZXJhdGVkIHsNCj4gICAgICAgICBsZWFmIGF1dG8tZ2Vu ZXJhdGVkIHsgdHlwZSBib29sZWFuOyBkZWZhdWx0IGZhbHNlOyB9DQo+ICAgICAgICAgbGVhZiBw dWJsaWMta2V5IHsgdHlwZSBiaW5hcnk7IGNvbmZpZyBmYWxzZTsgfQ0KPiAgICAgIH0NCj4gICB9 DQo+IH0NCj4NCj4gSWYgdGhlIGNsaWVudCBjb25maWd1cmVzIGFuIGVudHJ5IGluIHRoZSBsaXN0 IHdpdGggZXhwbGljaXQga2V5cyB0aGVuDQp0aGF0IGlzIHdoYXQgdGhlIHNlcnZlciB1c2VzLg0K Pg0KPiBIb3dldmVyLCBpZiB0aGUgY2xpZW50IGNvbmZpZ3VyZXMgYW4gZW50cnkgaW4gdGhlIGxp c3Qgd2l0aCBsZWFmDQoiYXV0by1nZW5lcmF0ZWQiIHNldCB0aGF0IHRoZSBkZXZpY2UgZ2VuZXJh dGVzIGEgcHVibGljL3ByaXZhdGUga2V5IHBhaXINCmFuZCBwZXJzaXN0cyB0aGVtIGludGVybmFs bHkuICBUaGUgcHVibGljLWtleSBpcyBhdmFpbGFibGUgdmlhIHRoZQ0KY29uZmlnIGZhbHNlIGxl YWYuICBUaGUgcHJpdmF0ZSBrZXkgaXMga2VwdCBwcml2YXRlLiAgTm8gc2VwYXJhdGUgWUFORw0K YWN0aW9uIGlzIHJlcXVpcmVkIHRvIGluc3RhbnRpYXRlIHRoZSBrZXlzIC0gaXQgaGFwcGVucyBh dXRvbWF0aWNhbGx5DQpkdWUgdG8gdGhlIGNvbmZpZ3VyYXRpb24uICBXaGF0IGlzIHRoZSBvYnZp b3VzIHN0ZXAgdGhhdCBJIGFtIG1pc3NpbmcgYXMNCnRvIHdoeSB0aGlzIGRvZXNuJ3Qgd29yaz8g 8J+YiQ0KDQpSb2INCg0KSSBhbSB3YW50aW5nIGFuIGFjdGlvbiwgZ2VuZXJhdGUga2V5IHBhaXIs IHRoYXQgSSBjYW4gaW52b2tlLCBhcyBvcHBvc2VkDQp0byBlLmcuIGluc3RhbGwgaGlkZGVuIGtl eS4NCg0KVGhlIHNjZW5hcmlvIEkgZGVzY3JpYmUgaXMgYW4gb3BlcmF0aW9uYWwgb25lLCB0aGUg dXNlciBoYXMgYQ0KY29uZmlndXJlZCwgd29ya2luZyBkZXZpY2UgYnV0IHRoZSBuZXR3b3JrIGl0 IGlzIG5vdyBnb2luZyB0byBiZSB1c2VkIG9uDQpyZXF1aXJlcyB0aGF0IGEgY2VydGlmaWNhdGUg YmUgZ2VuZXJhdGVkLCB3aGljaCwgeWVzLCBjb21lcyB1bmRlciB0aGUNCmdlbmVyYWwgaGVhZGlu ZyBvZiBPQU0gYnV0IGlzIHRvIG1lIGEgZGlmZmVyZW50IGtpbmQgb2YgY29uZmlndXJhdGlvbg0K Y29tcGFyZWQgdG8gdGhlIGluaXRpYWwgY29uZmlndXJhdGlvbiBvciB1cGRhdGVzIGRyaXZlbiBi eSBvdGhlcg0KY2hhbmdlcy4NCg0KQW5kIEkgZGlkIGNvbW1lbnQgZWFybGllciB0aGF0IEkgZmlu ZCB0aGUgcmVmZXJlbmNlcyB0byBoaWRkZW4gYW5kIHRvDQpnZW5lcmF0ZSBoaWRkZW4gbWlzbGVh ZGluZy4gIFdoYXQgSSBzZWUgZ2VuZXJhdGVkIGlzIGFsd2F5cyBhIGtleSBwYWlyLA0Kbm90IG9u ZSBoYWxmIG9mIGEga2V5IHBhaXIuIEkgZG8gZmluZCB0aGUgdGVybWlub2xvZ3kgbXV0YXRpbmcg aW4gYSB3YXkNCnRoYXQgc2VlbXMgdW5jbGVhciB0byBtZSwgc29tZXRoaW5nIEkgbWF5IGNvbW1l bnQgb24gb25jZSB0aGUNCmZ1bmN0aW9uYWxpdHkgaGFzIGJlZW4gYWdyZWVkLg0KDQpUb20gUGV0 Y2gNCj4NCj4gVGhhbmtzLA0KPiBSb2INCj4NCj4NCj4gPg0KPiA+IFRvbSBQZXRjaA0KPiA+DQo+ ID4gPiBXaHkgaXMgdGhlIGNvbmZpZ3VyYXRpb24gaW50ZW50IG9mICJJIHdhbnQgeW91IHRvIHVz ZSBhIHNlY3VyZWx5DQo+ID4gYWxsb2NhdGVkIHB1YmxpYy9wcml2YXRlIGtleSBwYWlyIiAod2hp Y2ggY291bGQgYmUgaW4gdGhlDQpjb25maWd1cmF0aW9uKQ0KPiA+IG5vdCBzdWZmaWNpZW50Pw0K PiA+ID4NCj4gPiA+IElmIHRoZSBpc3N1ZSBpcyB0aGF0IHRoZXNlIGtleXMgbmVlZCB0byBwZXJz aXN0IG92ZXIgZGV2aWNlDQpyZXN0YXJ0LA0KPiA+IHRoZW4gSSB3b3VsZCB0aGluayB0aGF0IHRo ZSBzb2x1dGlvbiBpcyBmb3IgdGhlIGRldmljZSB0byBzZWN1cmVseQ0KcGVyc2lzdA0KPiA+IHRo ZXNlIGtleXMgaW5kZXBlbmRlbnRseSBvZiB0aGUgWUFORyBjb25maWd1cmF0aW9uLg0KPiA+ID4N Cj4gPiA+IFRoYW5rcywNCj4gPiA+IFJvYg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ IFRvbSBQZXRjaA0KPiA+ID4gPg0KPiA+ID4gPiA+IC9tYXJ0aW4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g PiA+ID4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBuZXRjb25mQGlldGYub3JnDQo+ ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ ID4gPiA+ID4NCj4gPiA+DQo+ID4gPg0KPg0KPg0KDQo= From nobody Mon May 6 14:19:17 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753A120162; Mon, 6 May 2019 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mRSmGX-ZtR1; Mon, 6 May 2019 14:19:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73F512016B; Mon, 6 May 2019 14:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25088; q=dns/txt; s=iport; t=1557177552; x=1558387152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rgGvi9hIwsOQ9UnEbn579NwRxzZYJlDRfHsityJobOE=; b=ZqB7vdhqHaHVA05lZ9d/12AOI2LQT1P/BJ/zTEriyvl0XaLGpVOIwLWB 7xjBoiY2ne7paQ53if6nTpUqWwtl5ehoEs+1TnWWrnLSqjVqaH/HQWyxV 73JCbM6AuJcfpdW1rpsWNh7gziPoCNICcfbT8XfKkIzXjHj31INz0PVAI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAAAqpNBc/5xdJa1cAgcbAQEBAQM?= =?us-ascii?q?BAQEHAwEBAYFRBgEBAQsBgWYqaYEEKAqDRkCIHI0HfpdUFIFnDgEBJYRIAhe?= =?us-ascii?q?BfCM0CQ4BAwEBBAEBAgECbRwMhUoBAQEDAQwXET4FAgULAgEGAhUFAgkWBwI?= =?us-ascii?q?CAjAVEAIEAQ0NE4I8TIF7Dw+QdZtlgS+ERkGFJgaBCycBiiKBKxeBQD+BEYI?= =?us-ascii?q?USTU+gmECAQIBgSoBCAoBBwWDHYJYBIp1IAEDgjqEbZQXZQkCggmGGYNwQoV?= =?us-ascii?q?SgiQjgg+GQYNtiROMH4ZNiheEDQIRFYEwHzhlWBEIcBWCcwEzghsXFG0BAwQ?= =?us-ascii?q?Hh1CFPgFBMQGQBw8XA4EIgSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,439,1549929600"; d="scan'208";a="269551091" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2019 21:19:11 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x46LJBbW016072 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 May 2019 21:19:11 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 May 2019 17:19:10 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Mon, 6 May 2019 17:19:10 -0400 From: "Eric Voit (evoit)" To: Magnus Westerlund , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) Thread-Index: AQHVAOILPUp24ohD6UOwYws4qyBRVKZec0sQ Date: Mon, 6 May 2019 21:19:10 +0000 Message-ID: <7efee2607c62458d865ce663f9d4fc27@XCH-RTP-013.cisco.com> References: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> In-Reply-To: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:19:15 -0000 SGkgTWFnbnVzLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiAgIFRob3Vn aHRzIGluLWxpbmUuLi4NCg0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCwgTWF5IDIsIDIwMTkg ODoyNSBBTQ0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v dGlmaWNhdGlvbnMtMjU6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQg dGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1j cml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IE15IGZvY3VzIHdoZW4gcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQg d2FzIGZyb20gYSBwZXJzcGVjdGl2ZSBvZiBob3cgdG8NCj4gaGFuZGxlIG92ZXJsb2FkLiANCg0K WW91IGFyZSBhYnNvbHV0ZWx5IGNvcnJlY3QgdG8gZm9jdXMgb24gb3ZlcmxvYWQuICBNaXRpZ2F0 aW5nIGRpZmZlcmVudCBkaW1lbnNpb25zIG9mIHRoZSBvdmVybG9hZCByaXNrIGhhcyBiZWVuIGEg ZGVzaWduIGdvYWwgc2luY2UgdGhpcyBlZmZvcnTigJlzIGluY2VwdGlvbi4gIEFuZCB0aGlzIGlz IHRoZSByZWFzb24gYSB2YXJpZXR5IG9mIFFvUyBtZWNoYW5pc21zIHdlcmUgaW5jbHVkZWQgaW4g dGhlIGRvY3VtZW50Lg0KDQo+IEkgaGF2ZSBhIGhhcmQgdGltZSB1bmRlcnN0YW5kaW5nIGhvdyB0 aGlzIHdpbGwgYWN0dWFsbHkgd29yaywNCj4gZXNwZWNpYWxseSBpbiBhIGZhc2hpb24gdGhhdCBw cmVzZXJ2ZXJzIGdvb2RwdXQgYW5kIGVuc3VyZSB3aGF0IGlzIGNvbnNpZGVyZWQNCj4gdGhlIG1v c3QgaW1wb3J0YW50IHN1YnNjcmlwdGlvbnMgYXJlIGRlbGl2ZXJlZC4gTm90IGhhdmluZyBnb29k IHVuZGVydGFuZGluZw0KPiBpbnRvIG5ldGNvbmYgYW5kIHJlc3Rjb25mIGRvbid0IGhlc2l0YXRl IHRvIGNhbGwgb3V0IGxpa2VseSBtaXNzdW5kZXJzdGFuZGluZyBieQ0KPiBtZSBhbmQgcHJvdmlk ZSBjbGFyaWZpY2F0aW9uIGFuZCBwb2ludGVycy4NCg0KRmV3IG9mIHRoZSBtZWNoYW5pc21zIGFy ZSBzcGVjaWZpYyB0byBlaXRoZXIgUkVTVENPTkYgb3IgTkVUQ09ORi4gIEZvciBjb21wbGV0ZW5l c3MgcmVhc29ucywgbGV0IG1lIHN1bW1hcml6ZSB0aGUgb3ZlcmxvYWQgbWVjaGFuaXNtcyBhdmFp bGFibGUuLi4NCg0KMS4gVGhlIHB1Ymxpc2hlciBpcyBhbGxvd2VkIHRvIGRlY2xpbmUgYSBkeW5h bWljIHN1YnNjcmlwdGlvbi4gIE9uZSBvZiB0aGVzZSByZWFzb25zIGlzIHRoYXQgdGhlIGluY3Jl bWVudGFsIHRyYWZmaWMgZ2VuZXJhdGVkIGJ5IGEgcGFydGljdWxhciBpbmNyZW1lbnRhbCBzdWJz Y3JpcHRpb24gd2lsbCBiZSB0b28gaGlnaC4gIFRoZXJlIGFyZSBlcnJvcnMgYmFjayB0byB0aGUg c3Vic2NyaWJlciBpbmRpY2F0aW5nIHRoaXMgY29uZGl0aW9uIGV4aXN0Lg0KMi4gQSBwdWJsaXNo ZXIgY2FuIHN1c3BlbmQgYW55IHN1YnNjcmlwdGlvbiBmb3IgY2FwYWNpdHkgcmVhc29ucywgYW5k IGEgcmVjZWl2ZXIgbXVzdCBiZSBhYmxlIHRvIGdyYWNlZnVsbHkgYWNjZXB0IHRoaXMgc3VzcGVu c2lvbi4gDQozLiBNdWNoIGxpa2Ugd2l0aCBIVFRQMiBzdHJlYW1zLCBoaWdoZXIgcHJpb3JpdHkg c3Vic2NyaXB0aW9ucyBpbnRlbmRlZCBmb3IgYSBwYXJ0aWN1bGFyIHJlY2VpdmVyIGNhbiBiZSBk ZXF1ZXVlZCBmaXJzdCBmcm9tIGEgcHVibGlzaGVyLiANCjQuIE11Y2ggbGlrZSB3aXRoIEhUVFAy IHN0cmVhbXMsIHByb3BvcnRpb25hbCBzdWJzY3JpcHRpb24gZGVxdWV1aW5nIGludGVuZGVkIGZv ciBhIHBhcnRpY3VsYXIgcmVjZWl2ZXIgY2FuIGJlIHBlcmZvcm1lZCBhIHB1Ymxpc2hlci4NCjUu IERTQ1AgbWFya2luZ3MgY2FuIGJlIHBsYWNlZCBvbiBzdWJzY3JpYmVkIGRhdGEuDQo2LiBNZWNo YW5pc21zIGZvciBkZXRlY3RpbmcgYW5kIHJlYWN0aW5nIHRvIGRpZmZlcmVudCB0eXBlcyBvZiBz dWJzY3JpYmVkIGRhdGEgbG9zcyBoYXZlIGJlZW4gZW1iZWRkZWQuDQo3LiBNZXRob2RzIGhhdmUg YmVlbiBpbmNsdWRlZCB0byBlbnN1cmUgYSBjb25maWd1cmVkIHJlY2VpdmVyIOKAnG9r4oCZc+KA nSBpbmZvcm1hdGlvbiBwdXNoIGJlZm9yZSBzdWJzY3JpYmVkIGRhdGEgaXMgc2VudC4gKFRoaXMg c2hvdWxkIHJlZHVjZSBvbmUgRERvUyB2ZWN0b3IuKSANCjguIEtlZXAgYWxpdmUgbWVjaGFuaXNt cyBhcmUgZXN0YWJsaXNoZWQgZm9yIGRpZmZlcmVudCB0cmFuc3BvcnQgdHlwZXMsIHNvIHRoYXQg c3Vic2NyaWJlZCBkYXRhIGlzbuKAmXQgYmVpbmcgc2VudCB3aGVuIHRoZSBpcyBubyByZWNlaXZl ciBsaXN0ZW5pbmcuDQoNCk1lY2hhbmlzbXMgKDMpICYgKDQpIHdpbGwgbGlrZWx5IGJlIHNlZW4g b25seSB3aXRoIEhUVFAyIGJhc2VkIHRyYW5zcG9ydHMuKiAgIFRoaXMgaXMgYmVjYXVzZSAoYXMg ZG9jdW1lbnRlZCB3aXRoaW4gZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmIHNlY3Rp b24gNCksIHRoZXNlIGNhcGFiaWxpdGllcyBhcmUgdG8gaW50ZWdyYXRlZCBkaXJlY3RseSBIVFRQ MiBSRkMtNzQ1MCBzZWN0aW9ucyA1LjMuMSAmIDUuMy4yLiAgIA0KDQoqIE9uZSBiYWNrZ3JvdW5k L3JldmlldyBub3RlLi4uICBFYXJsaWVyIHZlcnNpb25zIG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1z dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgaW5jbHVkZWQgc3BlY2lmaWMgcGFyYWxsZWxzIHRvIFJG Qy03NDUwIHdoZW4gZGVzY3JpYmluZyAoMykgJiAoNCkuICBIb3dldmVyIFdHIG1lbWJlcnMgd2Fu dGVkIHRvIGFic3RyYWN0IGF3YXkgd2hhdCB0aGV5IGZlbHQgd2VyZSBIVFRQMiBzcGVjaWZpYyBy ZWZlcmVuY2VzLiBUaGlzIGlzIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB3aGF0IHdhcyBiZWluZyBy ZWZlcmVuY2VkIHdhcyB0aGUgZGVzaXJlZCBmdW5jdGlvbmFsIGJlaGF2aW9yIHJhdGhlciB0aGFu IGFueXRoaW5nIEhUVFAyIHNwZWNpZmljLiAgIEkgY2FuIHVuZGVyc3RhbmQgdGhlIFdHIHJldmll d2VycycgY29uY2Vybi4gIFRoaXMgaXMgYWxyZWFkeSBhIGxvbmcgZG9jdW1lbnQsIGFuZCBhIHJl YWRlciB3aG8gb25seSBjYXJlcyBhYm91dCBORVRDT05GIGhvcGVmdWxseSB3b24ndCBuZWVkIHRv IHdhZGUgdGhyb3VnaCBjb21wbGV4IGlzc3VlcyB3aGljaCB0aGV5IGFyZSB1bmxpa2VseSB0byB3 b3JyeSBhYm91dCBpbiBkZXBsb3ltZW50Lg0KDQo+IEEpIFRoZSBRb1MgYW5kIHByaW9yaXR5IHNl bmRpbmcgbWVjaGFuaXNtIGRpc2N1c3NlZCBpbiAyLjMgYW5kIGZ1cmh0ZXIgZGVmaW5lZA0KPiBi eSB0aGUgWUFORyBtb2RlbC4NCj4gDQo+IEkgZG8gd2FudCB0byByYWlzZSB0aGUgdXNhZ2Ugb2Yg dGhlIERTQ1AgY29kZSBwb2ludCB0byBhIGRpc2N1c3MuIEFzIHRoZSBEU0NQDQo+IGRlZmluZXMg ZGlmZmVyZW50IFBIQiBhbmQgcmVsYXRpdmUgcHJpb3JpdGllcyBpbiB0aGUgcm91dGVyIHF1ZXVl cyBhIERTQ1AgdmFsdWUNCj4gZG9lcyBub3QgcHJvdmlkZSB0aGUgcHVibGlzaGVyIGFueSBpbmZv cm1hdGlvbiBhYm91dCBwcmlvcml0eS4gSSBnZXQgdGhlIGZlZWxpbmcNCj4gZnJvbSB0aGUgdGV4 dCB0aGF0IHRoaXMgbWF5IGJlIGludGVuZGVkLiBJZiB0aGUgb25seSBpbnRlbnRpb24gaXMgdG8g aGF2ZSB0aGUNCj4gdHJhbnNwb3J0IHBlcmZvcm0gZGlmZmVyZW50aWFsIHRyZWF0bWVudCBpbiB0 aGUgbmV0d29yayBiZXR3ZWVuIHRoZSBwdWJsaXNoZXINCj4gYW5kIHRoZSByZWNlaXZlciANCg0K WWVzLCB0aGlzIGlzIHRoZSBjYXNlLg0KDQo+IHRoZXJlIGFyZSBzdGlsbCBtb3JlIGNvbnNpZGVy YXRpb25zIGFyZSBuZWVkZWQuDQo+IEZpcnN0IG9mIGFsbCBJIHRoaW5rIHRoZXNlIHNlbnRlbmNl IG5lZWRzIGEgdG90YWwgcmV3cml0ZToNCj4gDQo+ICAgIElmIHRoZSBwdWJsaXNoZXIgc3VwcG9y dHMgdGhlICJkc2NwIiBmZWF0dXJlLCB0aGVuIGEgc3Vic2NyaXB0aW9uDQo+ICAgIHdpdGggYSAi ZHNjcCIgbGVhZiBNVVNUIHJlc3VsdCBpbiBhIGNvcnJlc3BvbmRpbmcgW1JGQzI0NzRdIERTQ1AN Cj4gICAgbWFya2luZyBiZWluZyBwbGFjZWQgd2l0aGluIHRoZSBJUCBoZWFkZXIgb2YgYW55IHJl c3VsdGluZw0KPiAgICBub3RpZmljYXRpb24gbWVzc2FnZXMgYW5kIHN1YnNjcmlwdGlvbiBzdGF0 ZSBjaGFuZ2Ugbm90aWZpY2F0aW9ucy4NCj4gICAgV2hlcmUgVENQIGlzIHVzZWQsIGEgcHVibGlz aGVyIHdoaWNoIHN1cHBvcnRzIHRoZSAiZHNjcCIgZmVhdHVyZQ0KPiAgICBTSE9VTEQgZW5zdXJl IHRoYXQgYSBzdWJzY3JpcHRpb24ncyBub3RpZmljYXRpb24gbWVzc2FnZXMgYXJlDQo+ICAgIHJl dHVybmVkIHdpdGhpbiBhIHNpbmdsZSBUQ1AgdHJhbnNwb3J0IHNlc3Npb24gd2hlcmUgYWxsIHRy YWZmaWMNCj4gICAgc2hhcmVzIHRoZSBzdWJzY3JpcHRpb24ncyAiZHNjcCIgbGVhZiB2YWx1ZS4N Cj4gDQo+IEkgdGhpbmsgb25lIG5lZWQgdG8gcHV0IGEgcmVxdXJpZW1lbnQgb24gdGhlIHRyYW5z cG9ydCB0byB1c2UgYSB0cmFuc3BvcnQgdGhhdA0KPiB1dGlsaXplIHRoZSBEU0NQIG1hcmtpbmcg b24gaXRzIHRyYWZmaWMuIA0KDQpJIGJlbGlldmUgeW91IGFyZSBhc2tpbmcgZm9yIGEgIHRoZSBw dWJsaXNoZXIgcmVzcGVjdCB0aGUgRFNDUCBtYXJraW5ncyBmb3IgdHJhZmZpYyBlZ3Jlc3Npbmcg YW4gaW50ZXJmYWNlIG9uIGEgcHVibGlzaGVyLiAgWWVzIHRoaXMgcmVxdWlyZW1lbnQgd2FzIGFz c3VtZWQsIGFuZCBjYW4gYmUgZXhwbGljaXRseSBhZGRlZC4NCg0KPiBXaGljaCBmb3IgdGhlIGN1 cnJlbnQgc2V0IG9mIGNvbm5lY3Rpb24NCj4gb3JpZW50ZWQgdHJhbnNwb3J0IHByb3RvY29scywg VENQLCBTQ1RQLCBhbmQgUVVJQyBhbGwgY3VycmVudGx5IG9ubHkgc3VwcG9ydA0KPiB1c2luZyBh IHNpbmdsZSBEU0NQIHBlciBjb25uZWN0aW9uLiBJbXBseWluZyBtdWx0aXBsZSB0cmFuc3BvcnQg cHJvdG9jb2wNCj4gY29ubmVjdGlvbnMgdXNpbmcgYSBwYXJ0aWN1bGFyIHRyYW5zcG9ydCB0byBl bmFibGUgdGhpcyBtYXBwaW5nLg0KDQpZZXMgZnVsbHkgYWdyZWUsIGEgY29ubmVjdGlvbiB3b3Vs ZCBiZSBuZWVkZWQgcGVyIERTQ1AuICAgICBJcyB5b3VyIG9iamVjdGlvbiB3aXRoIHRoZSB0ZXh0 IGFib3ZlIHRoZSB3b3JkcyAiU0hPVUxEIGVuc3VyZSIgcmF0aGVyIHRoYW4gIk1VU1QgZW5zdXJl Ij8gICAgSWYgeWVzLCBJIGNhbiBhc2sgdGhlIFdHIG9iamVjdHMgdG8gd2hldGhlciB0aGlzIHJl cXVpcmVtZW50IHNob3VsZCBiZSBhIE1VU1QuDQoNCj4gQS4yIFF1ZXVpbmcgbW9kZWwgb2YgYSBw dWJsaXNoZXIuDQo+IFdpdGggdGhlIERTQ1AgYW5kIHRoZSBXZWlnaHQgYW5kIGRlcGVuZGVuY3kg bW9kZWwgSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8NCj4gY2xhcmlmeSB0aGUgbW9kZWwgb2Yg dGhlIHF1ZXVlaW5nIGluIHRoZSBwdWJsaXNoZXIuIFNvIGlzIHRoZSBpbnRlbnRpb24gdGhhdCBz ZXZlcmFsDQo+IHN1YnNjcmlwdGlvbnMgd2l0aCBkaWZmZXJlbnQgd2VpZ2h0cyBhbmQgcG9zc2li bHkgZGVwZW5kZW5jaWVzIGhhdmUgdGhlaXINCj4gaW5kaXZpZHVhbCBxdWV1ZXMgdGhhdCBnb2Vz IGludG8gYSBzY2hlZHVsZXI/DQoNCkFzIHlvdSBrbm93LCBxdWV1aW5nIG1vZGVscyBhcmUgbm9u LXRyaXZpYWwuICAgRm9yIHRoYXQgcmVhc29uIHdlIHdhbnRlZCB0byAxMDAlIGFkb3B0IHRoZSBm dW5jdGlvbmFsIGJlaGF2aW9yIFJGQy03NTQwIFNlY3Rpb24gNS4zLjEgYW5kIDUuMy4yIHdpdGhv dXQgaGF2aW5nIHRvIHJlLWRvY3VtZW50L21pcnJvciB0aGF0IGNvbnRlbnQgYXQgYSBoaWdoZXIg bGV2ZWwgb2YgdGhlIG5ldHdvcmsgc3RhY2suICAgV2UgYXJlIGEgaG9waW5nIHRoYXQgYSByZWFk ZXIgb2YgbmV0d29yayBzdWJzY3JpcHRpb25zIGNhbiBsb29rIHRvIHdlbGwgZG9jdW1lbnRlZCwg aW1wbGVtZW50ZWQgSFRUUDIgYmVoYXZpb3JzIGFzIGFwcGxpY2FibGUuICBQcm92aWRpbmcgYW4g aW50ZXJtZWRpYXRlIGxheWVyIG9mIGZ1bmN0aW9uYWwgZGVzY3JpcHRpb24gY291bGQgZWFzaWx5 IHJlc3VsdCBpbiBzb21lIG1pcy1hbGlnbm1lbnRzIGZyb20gd2hhdCBpcyBpbnRlbmRlZC4NCg0K PiBUbyBhdm9pZCBjb21wbGV4IHF1ZXVlDQo+IGludGVyYWN0aW9ucyBvbiB0aGlzIGxldmVsIEkg dGhpbmsgdGhlcmUgbmVlZCB0byBiZSBzZXBlcmF0ZSBzY2hlZHVsZXIgaW5zdGFuY2VzDQo+IHBl ciBEU0NQLiBJIHdvdWxkIGFsc28gbm90ZSB0aGF0IERlcGVuZGVuY3kgbWVjaGFuaXNtIGNhbid0 IGVuc3VyZSB0aGF0IGENCj4gZGVwZW5kZW50IHN0cmVhbSBhcnJpdmUgYXQgcmVjZWl2ZXIgYWZ0 ZXIgdGhlIGlkZW50aWZpZWQgZGVwZW5kZW5jeSBpZiB0aGV5IGFyZQ0KPiBvbiBkaWZmZXJlbnQg RFNDUC4gSW4gZmFjdCBpZiBvbmUgd291bGQgaGF2ZSBIVFRQLzMgKG92ZXIgUVVJQykgd2UgbWF5 IG5vdA0KPiBldmVuIGd1YXJhbnRlZSBpdCB3aXRoaW4gYSBzaW5nbGUgY29ubmVjdGlvbiBhbmQg c2FtZSBEU0NQIGR1ZSB0byBwYWNrZXQgbG9zcw0KPiBpbXBhY3QuIFRvIG1lIHRoaXMgbW9kZWwg YW5kIHdoYXQgcmVsYXRpb25zaGlwIG9uZSBuZWVkIHRvIGNvbnNpZGVyIGhlcmUgbmVlZA0KPiB0 byBiZSBjbGFyaWZpZWQuIEkgdGhpbmsgUkZDIDc1NDAgU2VjdGlvbiA1LjMuMSBpcyBhbiBleGNl bGxlbnQgaW5kaWNhdGlvbiBvZiBqdXN0IHRoZQ0KPiBpbXBvcnRhbmNlIG9mIGNvbnNpZGVyaW5n IHdoYXQgaXMgaW4gdGhlIHNhbWUgZGVwZW5kZW5jeSB0cmVlIGFuZCB3aGF0IGl0DQo+IG1lYW5z IHRvIGhhdmUgZGlmZmVyZW50IHdlaWdodGluZy4gVG8gY29uY2x1ZGUgSSB0aGluayB0aGlzIG5l ZWRzIGEgbW9kZWwNCj4gZGVzY3JpcHRpb24gYW5kIGNsZWFyZXIgZGVmaW5pdGlvbiBhbmQgcG9z c2libHkgcmVxdWlyZW1lbnRzIHRvd2FyZHMgdGhlDQo+IHRyYW5zcG9ydC4gRXNwY2VpYWxseSBp ZiB5b3UgYWN0dWFsbHkgbmVlZCBhbiBpbi1vcmRlciBkZWxpdmVyeSByZXF1aXJlbWVudD8NCg0K SSB0aGluayB3ZSBoYXZlIHRoZSBzYW1lIHRlY2huaWNhbCBvYmplY3RpdmUgaW4gbWluZC4gICBB bmQgaXQgaXMgYWJzb2x1dGVseSB0aGUgZGVzaXJlIHRvIGhhdmUgaWRlbnRpY2FsIGJlaGF2aW9y IHRvIFJGQy03NTQwIFNlY3Rpb24gNS4zLjEgYW5kIDUuMy4yLiAgICBGb3IgdGhlIGN1cnJlbnQg c2V0IG9mIGRvY3VtZW50cyBiZWZvcmUgdGhlIElFU0csIHdlIGluY2x1ZGUgd2l0aGluIGRyYWZ0 LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBTZWN0aW9uIDQsIGEgMToxIG1hcHBpbmcgYmV0 d2VlbiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGFuZCBSRkMt NzU0MC4gICAgDQoNCldlIGFyZSBob3BpbmcgdGhhdCB0aGUgdHJhbnNwb3J0IGRvY3VtZW50cyBs aWtlIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBjYW4gYmUgdGhlIHBsYWNlIHdo ZXJlIHN1Y2ggc3VwcG9ydGluZyBkb2N1bWVudGF0aW9uIGFuZCBtYXBwaW5ncyBvY2N1ci4gIA0K DQo+IEIuIFRoZSB1bnByZWRpY3RhYmlsaXR5IG9mIHRoZSBjaXJjdWl0IGJyZWFrZXIgb3Zlcmxv YWQgbWVjaGFuaXNtLg0KPiANCj4gTXkgZGVzY3JpcHRpb24gb2YgdGhlIG92ZXJsb2FkIGhhbmRs aW5nIGluIHRoaXMgZG9jdW1lbnQgaXMgdGhhdCBpdCBpcyBhIGNpcmN1aXQNCj4gYnJlYWtlciBi YXNlZCBtZWNoYW5pc20gdGhhdCBjYW4gYmxvdyBhIGZ1c2Ugb24gc3Vic2NyaXB0aW9ucyB0aGF0 IGl0IGZhaWxzIHRvDQo+IGhvbm9yIGluIG92ZXJsb2FkIHNpdHVhdGlvbnMuIFdoYXQgd29ycmll cyBtZSBkZXBseSBpcyB0aGUgdG90YWwgdW5wcmVkaWN0YWJpbGl0eQ0KPiBvZiB0aGlzIG1lY2hh bmlzbS4NCg0KQXQgdGhlIGJlZ2lubmluZyBvZiB0aGlzIGVtYWlsLCB0aGVyZSBhcmUgZWlnaHQg bWV0aG9kcyBvZiBvdmVyZmxvdyBoYW5kbGluZyBsaXN0ZWQuICBXZSBvcHRpbWl6ZWQgdGhlc2Ug ZWlnaHQgbWVjaGFuaXNtcyBmb3IgZGlmZmVyZW50IGZhaWx1cmUgc2NlbmFyaW9zIGFuZCBjb25n ZXN0aW9uIGNvbmRpdGlvbnMuICAgT3VyIGdvYWwgd2FzIHRvIGRlcGVuZCBvbiBleGlzdGluZyBt ZWNoYW5pc21zL3RlY2hub2xvZ2llcyB3aGVyZXZlciBwb3NzaWJsZS4gIFJldXNlIG9mIGV4aXN0 aW5nIG1lY2hhbmlzbXMgc2hvdWxkIHJlZHVjZSBhdCBsZWFzdCBzb21lIG9mIHRoZSB1bnByZWRp Y3RhYmlsaXR5Lg0KDQo+IEZpcnN0LCBpcyBpdCB0aGUgaW50ZW50aW9uIHRvIGRlcml2ZSB3aGF0 IHN1YnNjcmlwdGlvbnMgYXJlIGxlYXN0IGltcG9ydGFudCBmcm9tIHRoZQ0KPiBEU0NQLCB3ZWln aHRpbmcgYW5kIERlcGVuZGVuY3kgcGFyYW1ldGVycz8gSWYgaXQgaXMsIEkgdGhpbmsgdGhhdCBt YXkgYmUgYQ0KPiBtaXNzdGFrZSBhcyBwcmlvcml0eSBvbiB3aGF0IHN1YnNjcmlwdGlvbnMgYXJl IG1vc3QgaW1wb3J0YW50IHRvIHJldGFpbiBhcmUgbm90DQo+IG5lY2Vzc2FyaWx5IHJlZmxlY3Rl ZCBpbiB0aGVpciBRb1MgcGFyYW1ldGVycy4NCg0KQXQgdGhpcyBwb2ludCB0aGUgZG9jdW1lbnQg ZG9lcyBub3QgYXR0ZW1wdCB0byBkZWZpbmUgImltcG9ydGFudCIuICBBbGwgdGhhdCBpcyBkb25l IGlzIHRvIHByb3ZpZGUgZ3VpZGFuY2UgcmVsYXRpbmcgdG8gc29tZSBlbGVtZW50cyBvZiBuZXR3 b3JrIHRyYW5zcG9ydC4gICBJZiB0aGVyZSBpcyBhIGRpbWVuc2lvbiBvZiAiaW1wb3J0YW5jZSIg d2hpY2ggYW4gaW1wbGVtZW50ZXIgd291bGQgbGlrZSB0byBsYXllciBvbnRvIHRoaXMgc29sdXRp b24sIGl0IGNvdWxkIGJlIGRvbmUuICBGb3IgZXhhbXBsZSwgImltcG9ydGFuY2UiIGNvdWxkIGFw cGxpZWQgaW4gYXJlYXMgc3VjaCBhcyB3aGF0IHN1YnNjcmlwdGlvbnMgc2hvdWxkIGJlIHN1c3Bl bmRlZCAgaW4gY2FzZSBvZiBDUFUgZXhoYXVzdC4gICBIb3dldmVyIGd1aWRhbmNlIG9uIHN1Y2gg ZW5oYW5jZW1lbnRzIGFyZSBub3QgaW5jbHVkZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KPiBTZWNv bmRseSwgd2hhdCBhcmUgdGhlIHZhbHVlcyB3aGVuIGEgc3Vic2NyaXB0aW9uIGFyZSBjb25zaWRl cmVkIHRvIGJlIHRvIGhlYXZ5DQo+IG9yIG5vdCBiZSBoYW5kbGVkIGFjY29yZGluZ2x5LiBBcmUg dGhlcmUgYW55IHBhcmFtZXRlciBzZXRzIHRoYXQgYWN0dWFsbHkNCj4gZGVzY3JpYmUgd2hhdCBT TEEgdGhlIHN1YnNjcmliZXIgZXhwZWN0IHRoYXQgY2FuIGJlIGNvbnZlcnRlZCBpbnRvIHRpbWVv dXQNCj4gdGltZXJzIG9yIGJ1ZmZlciBkZXB0aCB0aHJlc2hvbGRzIHRvIGluZGljYXRlIHRoYXQg cHVibGlzaGVyIHNpZGUgaXNuJ3QgZGVsaXZlcmluZw0KPiB0aGVzZSBpbiB0aW1lPw0KDQpUaGVy ZSBpcyBubyBndWlkYW5jZSBvbiB0aGlzIHByb3ZpZGVkIGluIHRoZSBkb2N1bWVudC4gICBBcyBl cXVpcG1lbnQgdHlwZXMsIHN1YnNjcmlwdGlvbiB2b2x1bWVzLCBhdmFpbGFibGUgbWVtb3J5LCB3 aWxsIHZhcnkgYmV0d2VlbiBzb2x1dGlvbnMsIHRoaXMgd2lsbCB0YWtlIGEgd2hpbGUgdG8gZGlt ZW5zaW9uIHByb3Blcmx5LiAgSSBjYW4gaW1hZ2luZSBzb21lZGF5IHRoYXQgd2UgbWlnaHQgaGF2 ZSBzb21ldGhpbmcgbGlrZSAiRXJsYW5nIGZvciBzdWJzY3JpcHRpb25zIiBtdWNoIGxpa2Ugd2Ug dXNlZCBFcmxhbmdzIGluIHRoZSBvbGQgdGVsZXBob255IG5ldHdvcmsgdG8gZGltZW5zaW9uIGNh bGwgaGFuZGxpbmcgY2FwYWJpbGl0aWVzIG9mIHBob25lIHN3aXRjaGVzLiAgQnV0IHdlIGFyZSBh IGxvbmcgd2F5IGZyb20gdGhhdC4gDQogDQo+IFRoaXJkLCBJIHdoYXQgSSB1bmRlcnN0YW5kIHRo ZXJlIGFyZSBubyBhbnkgYWRkaXRpb25hbCBiYWNrIHByZXNzdXJlIG1lY2hhbmlzbQ0KPiBiZXR3 ZWVuIHRoZSByZWNlaXZlciBhbmQgdGhlIHB1Ymxpc2hlciB0aGFuIHRoZSB0cmFuc3BvcnQgcHJv dG9jb2xzIGZsb3cNCj4gY29udHJvbD8gU28gYSByZWNlaXZlciB0aGF0IGlzIG5vdCBrZWVwaW5n IHVwIHByb2Nlc3NpbmcgdGhlIGRhdGEgaXQgcHJvY2VzcyB3aWxsDQo+IG5vdCByZWFkIG91dCB0 aGUgZGF0YSBvdXQgb2YgdGhlIGZsb3cgY29udHJvbGxlZCBidWZmZXJzIGluIHRoZSByZWNlaXZl ciBhbmQgdGh1cw0KPiBwcmV2ZW50IHRoZSBwdWJsaXNoZXIgdG8gd3JpdGUgdG8gdGhlIHRyYW5z cG9ydCBjb25uY2V0aW9uLCB0aHVzIGNhdXNpbmcgdGhlDQo+IHB1Ymxpc2hlciB0byBldmVudHVh bGx5IHRyaWdnZXIgYSBzdXNwZW5zaW9uIGR1ZSB0byBpdHMgcXVldWUgYnVpbGQgdXA/DQoNClRo ZXJlIGlzIG5vdGhpbmcgYmV5b25kIHRyYW5zcG9ydCBmbG93IGNvbnRyb2wuICBXZSB0aG91Z2h0 IGFib3V0IGl0IGluaXRpYWxseSwgYnV0IHdlIHdlcmUgbm90IHJlYWR5IHRvIHBpY2sgdXAgZXZl biBtb3JlIGNvbXBsZXhpdHkgdGhhbiB3ZSBhbHJlYWR5IGhhZC4NCg0KPiBUbyBteSB1bmRlcnN0 YW5kaW5nIHRoZSBjdXJyZW50IG1lY2hhbmlzbSBwbGFjZXMgYWxsIHN1YnNjcmlwdGlvbnMgb24g dGhlDQo+IHNhbWUgaW1wb3J0YW5jZSBhbmQgd2l0aCB0aGUgc2FtZSBTTEEuIFRodXMgbGlrZWx5 IGNhdXNpbmcgc2hvcnQgdGVybSBvdmVybG9hZA0KPiBzaXR1YXRpb25zIHRvIGNhdXNlIHN1YnNj cmlwdGlvbiBzdXNwZW5zaW9ucyBpbiByYW5kb20gc3Vic2NyaXB0aW9ucy4gSXMgdGhlIFdHDQo+ IGZpbmUgd2l0aCB0aGlzIHR5cGUgb2YgcmFuZG9tbmVzcyBvY2N1cmluZyBhbmQgZXhwZWN0aW5n IHRoYXQgbm9ybWFsbHkgdGhlcmUNCj4gd2lsbCBiZSBzdWNoIGFtb3VudCBvZiBvdmVycHJvdmlz aW9uaW5nIHRoYXQgYmVpbmcgYWJsZSB0byBpbmRpY2F0ZSBwcmlvcml0eSBhbmQNCj4gU0xBIGFy ZSBvdmVya2lsbD8NCg0KWWVzLiAgIFdlIG5lZWRlZCBhIHN0YXJ0aW5nIHBvaW50LiAgQW5kIHRo ZXJlIGFyZSB0ZWNobmljYWwgc29sdXRpb25zIHdoaWNoIGNhbiBiZSBsYXllcmVkIG9uIHRvcC4g ICBCdXQgd2hhdCB3ZSBoYXZlIG5vdyB0b29rIG1hbnkgeWVhcnMgdG8gZmluYWxpemUsIGFuZCBz aG91bGQgYmUgYSBiaWcgZW5vdWdoIHRlY2huaWNhbCBqdW1wIGNvbnNpZGVyaW5nIG91ciBjdXJy ZW50IGtub3dsZWRnZS4NCg0KPiBBdCBhIG1pbmltYWwgYSBjaGFuZ2Ugb2YgdGhpcyBzZW50ZW5j ZSBpbiBTZWN0aW9uIDIuNS4xIGlzIG5lZWRlZDoNCj4gDQo+ICAgVGhpcyBjb3VsZA0KPiAgICBi ZSBmb3IgcmVhc29ucyBvZiBhbiB1bmV4cGVjdGVkIGJ1dCBzdXN0YWluZWQgaW5jcmVhc2UgaW4g YW4gZXZlbnQNCj4gICAgc3RyZWFtJ3MgZXZlbnQgcmVjb3JkcywgZGVncmFkZWQgQ1BVIGNhcGFj aXR5LCBhIG1vcmUgY29tcGxleA0KPiAgICByZWZlcmVuY2VkIGZpbHRlciwgb3Igb3RoZXIgaGln aGVyIHByaW9yaXR5IHN1YnNjcmlwdGlvbnMgd2hpY2ggaGF2ZQ0KPiAgICB1c3VycGVkIHJlc291 cmNlcy4NCg0KSSBoYXZlIHJlbW92ZWQgImhpZ2hlciBwcmlvcml0eSIuDQoNCj4gQXMgaXQgc3Rh dGVzIHRoYXQgc3Vic2NyaXB0aW9ucyBoYXMgcHJpb3JpdGllcyB3aXRob3V0IHJlZmVyZW5jZSB0 byBhIG1lY2hhbmlzbQ0KPiB0aGF0IHByb3ZpZGVzIHRoYXQgcHJpb3JpdHkuDQo+IA0KPiBDLiAy LjQuNS4gIEtpbGxpbmcgYSBEeW5hbWljIFN1YnNjcmlwdGlvbg0KPiANCj4gICAgVGhlICJraWxs LXN1YnNjcmlwdGlvbiIgb3BlcmF0aW9uIHBlcm1pdHMgYW4gb3BlcmF0b3IgdG8gZW5kIGENCj4g ICAgZHluYW1pYyBzdWJzY3JpcHRpb24gd2hpY2ggaXMgbm90IGFzc29jaWF0ZWQgd2l0aCB0aGUg dHJhbnNwb3J0DQo+ICAgIHNlc3Npb24gdXNlZCBmb3IgdGhlIFJQQy4gIEEgcHVibGlzaGVyIE1V U1QgdGVybWluYXRlIGFueSBkeW5hbWljDQo+ICAgIHN1YnNjcmlwdGlvbiBpZGVudGlmaWVkIGJ5 IHRoZSAiaWQiIHBhcmFtZXRlciBpbiB0aGUgUlBDIHJlcXVlc3QsIGlmDQo+ICAgIHN1Y2ggYSBz dWJzY3JpcHRpb24gZXhpc3RzLg0KPiANCj4gQ2FuIHNvbWVvbmUgcGxlYXNlIGNsYXJpZnkgdGhl IHVzZSBjYXNlIGZvciB0aGlzIGZ1bmN0aW9uYWxpdHkuIFRvIG15DQo+IHVuZGVyc3RhbmRpbmcg aXQgYWxsb3dzIGFub3RoZXIgcmVjZWl2ZXIgZ2l2ZW4gYXV0aG9yaXR5IHRvIGtpbGwgdGhlIHN1 YnNjcmlwdGlvbg0KPiBiZWluZyBkZWxpdmVyZWQgdG8gYW5vdGhlciByZWNlaXZlci4gQmFzZWQg b24gdGhlIG90aGVyd2lzZSByYXRoZXIgc3RyaWN0IHRoYXQgYWxsDQo+IG1hbmlwdWxhdGlvbnMg b2YgZHluYW1pYyBzdWJzY3JpcHRpb25zIGhhcHBlbnMgZnJvbSB0aGUgdHJhbnNwb3J0IHNlc3Np b24NCj4gY29udGV4dCB0aGF0IGVzdGFibGlzaGVkIGl0IEkgd2FudCB0byBiZXR0ZXIgdW5kZXJz dGFuZCB0aGUgdXNlIGNhc2UgaXQgYXBwZWFycw0KPiBvdXQgcGxhY2UuDQoNCkEgbmV0d29yayBv cGVyYXRvciBuZWVkcyBhIHZlcnkgc2VjdXJlIG1lY2hhbmlzbSB0byBlbmQgYSBkeW5hbWljIHN1 YnNjcmlwdGlvbiBpbiBwcm9ncmVzcyB3aGljaCBpdCBzZWVzIGFzIGhhcm1mdWwuICAgVGhlIG9w ZXJhdG9yIGNhbm5vdCBkbyB0aGlzIHZpYSBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMsIGFzIHRo ZSBkeW5hbWljIHN1YnNjcmlwdGlvbiBpcyBub3QgY29uZmlndXJlZCAoYW5kIHRoZXJlZm9yZSBj YW5ub3QgYmUgZGVsZXRlZCBpbiB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUpLiAgDQoNCj4g RC4gVGhlIFJlcXVpcmVtZW50cyBvbiBhIHRyYW5zcG9ydCBzdXBwb3J0aW5nIENvbmZpZ3VyZWQg U3Vic2NyaXB0aW9ucw0KPiBSZWFkaW5nIHRocm91Z2ggU2VjdGlvbiAyLjUgSSBhcnJpdmVkIGF0 IGEgbnVtYmVyIG9mIHF1ZXN0aW9ucy4gSSB0cmllZCB0bw0KPiB1bmRlcnN0YW5kIHdoYXQgdGhl IHJlcXVpcmVtZW50cyBhcmUgZm9yIHRoZSB0cmFuc3BvcnQgdGhhdCBzdXBwb3J0cw0KPiBDb25m aWd1cmVkIFN1YnNjcmlwdGlvbnMuIEkgZGlkIG5vdGUgdGhhdCBuZWl0aGVyIGRyYWZ0LWlldGYt bmV0Y29uZi1yZXN0Y29uZi0NCj4gbm90aWYtMTMgbm9yDQo+IGRyYWZ0LWlldGYtbmV0Y29uZi1u ZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMtMTcgc3VwcG9ydHMgY29uZmlndXJlZA0KPiBzdWJz Y3JpcHRpb25zLiBUaHVzLCB0aGVyZSBhcHBlYXIgbm8gdGVtcGxhdGUgZm9yIGEgc29sdXRpb24g ZWl0aGVyLCBvciBkb2VzDQo+IHRoZXJlIGV4aXN0IGFub3RoZXIgZG9jdW1lbnQgdGhhdCBpcyBi ZWluZyB3b3JrZWQgb24gZGVmaW5pbmcgc3VjaCBhIHRyYW5zcG9ydD8NCg0KVGhpcyBpcyB0aGUg Y2FzZS4gICBPcmlnaW5hbGx5IGJvdGggb2YgdGhvc2UgZG9jdW1lbnRzICpkaWQqIGluY2x1ZGUg Y29uZmlndXJlZCBzdWJzY3JpcHRpb25zLiAgSG93ZXZlciB3aXRoaW4gdGhlIFdHIHRoZXJlIHdh cyBhIGRlY2lzaW9uIG5vdCB0byBwcm9ncmVzcyBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgeWV0 LiAgT25lIHJlYXNvbiBpcyB0aGF0IG90aGVyIFlBTkcgbW9kZWwgZHJhZnRzIG1vdmluZyBpbiB0 aGUgTkVUQ09ORiBXRyB3ZXJlIHNlZW4gYXMgcHJlLXJlcXVpc2l0ZXMgZm9yIHNlY3VyZWx5IGNy ZWF0aW5nIHRyYW5zcG9ydCBzZXNzaW9ucyB2aWEgY2FsbCBob21lIGZvciB0aGUgY29uZmlndXJl ZCBzdWJzY3JpcHRpb25zLiAgQXMgYSByZXN1bHQsIHN1cHBvcnQgZm9yIGNvbmZpZ3VyZWQgc3Vi c2NyaXB0aW9ucyB3YXMgZXh0cmFjdGVkIGZyb20gdGhvc2UgdHJhbnNwb3J0IGRvY3VtZW50cy4g ICBJdCBpcyBleHBlY3RlZCB0aGF0IHRoYXQgdXBkYXRlZCB2ZXJzaW9ucyBvZiBqdXN0IHRob3Nl IHRyYW5zcG9ydCBkb2N1bWVudHMgd2lsbCBiZSBkcml2ZW4gd2hlbiB0aGUgWUFORyBtb2RlbHMg Y29tcGxldGUuDQoNCj4gUXVlc3Rpb25zIHRoYXQgYXJvc2UgZm9yIG1lIHJlbGF0ZWQgdG8gQ29u ZmlndXJlZCBTdXNicmlwdGlvbiBUcmFuc3BvcnQgd2hlcmUNCj4gdGhlIGZvbGxvd2luZzogMS4g Q2FuIFRyYW5zcG9ydCBTZXNzaW9uIGJlIGluaXRpYXRlZCBpbiBib3RoIGRpcmVjdGlvbi4gUkZD DQo+IDgwNzEgcHJvdmlkZXMgYSBzb2x1dGlvbiBmb3IgUHVibGlzaGVyIHRvIFJlY2VpdmVyIGlu aXRpYXRpb24uIEl0IGlzIHVuY2xlYXIgaWYgYWxsDQo+IHBhcnRzIGFyZSBpbiBwbGFjZSB0byBo YXZlIGEgcmVjZWl2ZXIgdG8gcHVibGlzaGVyIGluaXRpYXRlZCB0cmFuc3BvcnQgdG8gYmUgYm91 bmQNCj4gdG8gdGhlIHN1YnNjcmlwdGlvbi4gDQoNClRoaXMgd2lsbCBiZSB1cCB0byBhIHNwZWNp ZmljIHRyYW5zcG9ydCBkcmFmdCB0byBtYWtlIHRoaXMgZGV0ZXJtaW5hdGlvbi4gIA0KDQpUbyBz ZWUgd2hhdCBtaWdodCBiZSB2aWFibGUgZm9yIE5FVENPTkYsIGNoZWNrIG91dCB0aGUgZWFybGll ciB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBhdDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMvMTAv IA0KDQpUaGlzIHdhcyBzZWVuIGFzIGEgY29tcGxldGUgdmVyc2lvbiBvZiBzdWNoIGEgc29sdXRp b24uICBIb3dldmVyIHRoZSBXRyB3YW50ZWQgYSBZQU5HIG1vZGVsIGZvciBzZXNzaW9uIHBhcmFt ZXRlcnMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNS4yLg0KDQo+Mi4gV2hhdCBpcyAibmFtZSIgcmVh bGx5PyBJdCBhcHBlYXJzIHRvIGJlIGRlZmluZWQgYXMgYW4NCj4gZW1wdHkgY29udGFpbmVyLiBE ZXNwaXRlIHRoYXQgaXQgYXBwZWFycyB0byBoYXZlIHJlcXVpcmVtZW50cyBvbiBiZWluZyBib3Ro IGENCj4gc2VjdXJpdHkgaWRlbnRpdHkgYXMgd2VsbCBhcyBuZXR3b3JrIGFkZHJlc3MuIA0KDQpZ b3UgYXJlIGNvcnJlY3QuICBJbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGlzIGRyYWZ0LCBhIHJl Y2VpdmVyIHdhcyBpZGVudGlmaWVkIGJ5IHRoZSBjb21iaW5hdGlvbiBvZiBhZGRyZXNzICsgcG9y dC4gIEhvd2V2ZXIgZHVlIHRvIHRoZSBZQU5HIGRvY3RvciByZXZpZXdzLCBhbmQgY2FsbCBob21l IGRpc2N1c3Npb25zIHJlZmVyZW5jZWQgYWJvdmUsIHRoZSBXRyB3YXNuJ3QgcmVhZHkgdG8gZmlu YWxpemUgdGhpcyBZQU5HIHN0cnVjdHVyZS4gIFRoZSBjb21wcm9taXNlIHdhcyB0aGUgY3VycmVu dCBzdHJ1Y3R1cmUsIHBsdXMgdGhlIGV4YW1wbGUgWUFORyBtb2RlbCBvZiBBcHBlbmRpeCBBIHRv IHNob3cgaG93IHRoaXMgbWlnaHQgYmUgYnVpbHQgb3V0Lg0KDQo+IDMuIEluIEZpZ3VyZSA5LCB3 aGljaCBpcyBzdGF0ZWQgdG8gYmUNCj4gZm9yIHRoZSByZWNlaXZlci4gV2hhdCBpbmZvcm1hdGlv biBkb2VzIHRoZSByZWNlaXZlciB1c2UgdG8gZGV0ZXJtaW5lIHRoZQ0KPiB0cmFuc2l0aW9uIChk KT8gQW5kIHdoYXQgZG9lcyBpdCBkbyBpbiB0aGlzIHN0ZXAuIFJlbGF0ZWQgdG8gRGlzY3VzcyBw YXJ0IEIpLiANCg0KVGhpcyBkZXRlcm1pbmF0aW9uIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmlj Lg0KDQo+IDQuIFJGQw0KPiA4MDcxIGFwcGVhcnMgdG8gbGFjayBhbnkgY29uc2lkZXJhdGlvbnMg Zm9yIGhvdyBvZnRlbiBhbmQgaG93IG1hbnkgdGltZXMgaXQNCj4gYXR0ZW1wdHMgdG8gY29ubmVj dCB0byB0aGUgcmVjZWl2ZXIuIFNvIGFwcGx5aW5nIHRoYXQgbWVjaGFuaXNtIGFwcGVhcnMgdG8N Cj4gcmVxdWlyZSBzb21lIHVzYWdlIGd1aWRhbmNlIHRvIGF2b2lkIGNhdXNpbmcgb3ZlcmxvYWQg c2l0dWF0aW9ucyBvciBEb1MNCj4gcG90ZW50aWFsIGJ5IG1pc2NvbmZpZ3VyaW5nIG5ldHdvcmsg ZGV2aWNlcyB3aXRoIHRoaXMgc29sdHV0aW9uIHRvIGRpYWwgb3V0DQo+IGZyZXF1ZW50bHkgdG8g YSB0YXJnZXQuDQo+IA0KPiBBcyB0aGUgdHJhbnNwb3J0IHNvbHV0aW9uIHJlcXVpcmVtZW50cyBh cmUgbm90IGRldGFpbCBpdCBpcyBhY3R1YWxseSBoYXJkIHRvDQo+IGRldGVybWluZSBpZiB0aGVy ZSBhcmUgc2hvcnQgY29taW5ncyBpbiB0aGUgZGVzY3JpcHRpb24gaW4gU2VjdGlvbiAyLjUgYW5k IHRoZQ0KPiBjb3JyZXNwb25kaW5nIFlBTkcgbW9kZWwuIElzIGl0IGFuIHJlYXNvbmFibGUgcmVx dWVzdCB0byBkb2N1bWVudCB0aGVzZQ0KPiByZXF1aXJlbWVudHM/DQoNClRoZSByZXF1aXJlbWVu dHMgd2VyZSBkb2N1bWVudGVkIGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RDT05GLiAgIEhvd2V2 ZXIgdGhlc2UgcmVxdWlyZW1lbnRzIHdlcmUgcmVtb3ZlZCB3aGVuIHRoZSBXRyBkZWNpZGVkIHRv IHdhaXQgdW50aWwgdGhlcmUgd2FzIGEgWUFORyBtb2RlbCBmb3IgUkZDLTgwNzEgcmVhZHkgdG8g Z28gdG8gdGhlIElFU0cuICAgRm9yIGEgcHJldmlldyBvbiB3aGF0IHRoZXNlIHJlcXVpcmVtZW50 cyBtaWdodCBsb29rIGxpa2UsIEkgcmVmZXIgeW91ICB0byBTZWN0aW9uIDUuMiBvZiANCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2 ZW50LW5vdGlmaWNhdGlvbnMvMTAvDQoNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IDEuIFNlY3Rpb24gMi4zOiBEU0NQIGRvbWFpbnMNCj4gSSB0 aGluayB0aGUgdGV4dCBjb3VsZCBiZW5lZml0IGZyb20gcG9pbnRpbmcgb3V0IHRoYXQgdGhlIHN1 YnNjcmliZXIgYWN0dWFsbHkgbmVlZHMNCj4gdG8ga25vdyB3aGF0IHRoZSBEU0NQIHZhbHVlcyBy ZXByZXNlbnRzIGluIHRoZSBkaWZmc2VydiBkb21haW4gb2YgdGhlIHB1Ymxpc2hlci4NCj4gQXMg dGhlc2UgY291bGQgYmUgZGlmZmVyZW50LCB0aGV5IGFsc28gY3JlYXRlIGFuIGludGVyZXN0aW5n IHByb2JsZW1zIGZvcg0KPiB0cmFuc3BvcnRzIG9mIGhvdyB0aGV5IGVzdGFibGlzaCBhIHRyYW5z cG9ydCBjb25uZWN0aW9uIHRoYXQgdXNlcyBhIHBhcnRpY3VsYXINCj4gRFNDUCwgYXMgdGhlIHJl Y2VpdmVyIGlmIGluaXRpYXRpbmcgbmVlZCB0byBrbm93IHRoZSBsb2NhbCBEU0NQIHZhbHVlIHRo YXQNCj4gY29ycmVzcG9uZHMgdG8gdGhlIGJlaGF2aW9yIGluIHRoZSBwdWJsaXNoZXIncyBkb21h aW4uDQoNClRoaXMgbWFrZXMgc2Vuc2UuICANCg0KSSBoYXZlIGFkZGVkIGluIFNlY3Rpb24gNS4z IFRyYW5zcG9ydCBSZXF1aXJlbWVudHMgYSBuZXcgZW50cnkgd2hpY2ggc3RhdGVzOg0KDQoiQSBz dWJzY3JpYmVyIHdoaWNoIGluY2x1ZGVzIGEgImRzY3AiIGxlYWYgd2l0aGluIGFuICJlc3RhYmxp c2gtc3Vic2NyaXB0aW9uIiByZXF1ZXN0IHdpbGwgbmVlZCB0byB1bmRlcnN0YW5kIGFuZCBjb25z aWRlciB3aGF0IHRoZSBjb3JyZXNwb25kaW5nIERTQ1AgdmFsdWUgcmVwcmVzZW50cyB3aXRoaW4g dGhlIGRvbWFpbiBvZiB0aGUgcHVibGlzaGVyLiINCg0KTGV0IG1lIGtub3cgaWYgdGhpcyBpcyBu b3Qgc3VmZmljaWVudC4NCg0KPiAyLiBJbiBnZW5lcmFsIEkgdGhpbmsgdGhlcmUgYXJlIG1vcmUg dGhhbiBvbmUgZGVzY3JpcHRpb24gdGhhdCBhcmUgZnV6enkgYWJvdXQgaWYgaXQNCj4gZGVzY3Jp YmVzIGEgcHVibGlzaGVyIG9yIHJlY2VpdmVyIGFjdGlvbi9yZXF1aXJlbWVudC4NCg0KSXQgd291 bGQgYmUgZ3JlYXQgaWYgeW91IGhhdmUgc29tZSBzcGVjaWZpY3MuICAgVGhlIGF1dGhvcnMgYW5k IHByZXZpb3VzIHJldmlld2VycyBsaWtlbHkgaGF2ZSBsb29rZWQgYXQgdGhpcyBvZnRlbiBlbm91 Z2ggd2hlcmUgdGhpbmdzIGxvb2sgb2J2aW91cyB3aGljaCBwZXJoYXBzIGFyZSBub3QuDQoNClRo YW5rcyBhZ2FpbiBmb3IgdGhlIHJldmlldywNCkVyaWMNCg== From nobody Mon May 6 14:46:55 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8A01201DA; Mon, 6 May 2019 14:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAHpg9TEaToI; Mon, 6 May 2019 14:46:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD591200A4; Mon, 6 May 2019 14:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3774; q=dns/txt; s=iport; t=1557179191; x=1558388791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t6oMIMqZpafrSkkeUuxP4YaTbVAeGkcVD7327x5lwSA=; b=isn0wt5bcQ+JdSFnML7QmUvXbzzeuRuutPXXDp5xR9QHxS6Nb4iLcN+A lO1Q8Usni+Op4JR+m/8x97Xc+eFXFbdEQmo4ma7hITZNDd0nLwBvQian3 GU4AsS743G/k4ZqVF33mOYQ+LwPN3WPHeo4Q+rKYxESTr8/34cGI6I6yt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAGqtBc/5RdJa1lDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgWYqaYEEKAqEBogcjQeYUhSBZw4BASWESAI?= =?us-ascii?q?XgXwjNAkOAQMBAQQBAQIBAm0cDIVKAQEBAwEjEUMCBQsCAQgVBQIJFgcCAgI?= =?us-ascii?q?wFRACBAENDYJPTIF7Dw+sSYEvhEZBhSYGgQsnAYtNF4FAP4QjPoJhAgECAYE?= =?us-ascii?q?qARECAYMoglgEixmCOplpCQKCCYYZjCgjgg+GQY0AjB+BIYUsjiQCERWBMB8?= =?us-ascii?q?4ZVgRCHAVgyeCRohMhQQ7QTEBkTiBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,439,1549929600"; d="scan'208";a="555971013" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2019 21:46:30 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x46LkUhO007836 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 May 2019 21:46:30 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 May 2019 17:46:29 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Mon, 6 May 2019 17:46:29 -0400 From: "Eric Voit (evoit)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) Thread-Index: AQHVAgv37Q002AfzXk6U6HjHV/fZO6ZeoOmw Date: Mon, 6 May 2019 21:46:29 +0000 Message-ID: References: <155692784695.7217.908270903914526669.idtracker@ietfa.amsl.com> In-Reply-To: <155692784695.7217.908270903914526669.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:46:46 -0000 SGkgQmVuamFtaW4NCg0KPiBGcm9tOiBCZW5qYW1pbiBLYWR1aywgTWF5IDMsIDIwMTkgNzo1NyBQ TQ0KPiANCj4gQmVuamFtaW4gS2FkdWsgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlv bnMtMjU6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRy b2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gDQo+IEl0IGxvb2tzIGxpa2UgdGhlIGRlc2NyaXB0aW9uIG9mIGZpbHRlci1mYWlsdXJl LWhpbnQgaW4gbW9kaWZ5LXN1YnNjcmlwdGlvbi1zdHJlYW0tDQo+IGVycm9yLWluZm8gbmVlZHMg dGhlIHNhbWUgdHJlYXRtZW50IHRoYXQgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbi1zdHJlYW0tZXJy b3ItDQo+IGluZm8gIHJlY2VpdmVkLg0KDQpEb25lLiAgWW91IHdpbGwgc2VlIGluIHRoZSBuZXh0 IHVwZGF0ZS4gIEkgd2lsbCBwb3N0IGFmdGVyIEkgZ2V0IGEgc2V0IG9mIHRob3VnaHRzIGJhY2sg ZnJvbSBNYWdudXMgb24gaGlzIERJU0NVU1MuDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5U Og0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBbb3JpZ2luYWwgY29tbWVudCBzZWN0aW9uIHJlcGxh Y2VkXQ0KPiANCj4gSW4gdGhlIHVwZGF0ZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQo+IA0K PiAgICBUaGUgcmVwbGF5IG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIFNlY3Rpb25zIFNlY3Rpb24g Mi40LjIuMSBhbmQNCj4gICAgU2VjdGlvbiAyLjUuNiBwcm92aWRlcyBhY2Nlc3MgdG8gaGlzdG9y aWNhbCBldmVudCByZWNvcmRzLiAgQnkNCj4gICAgZGVzaWduLCB0aGUgYWNjZXNzIGNvbnRyb2wg bW9kZWwgdGhhdCBwcm90ZWN0cyB0aGVzZSByZWNvcmRzIGNvdWxkDQo+ICAgIGVuYWJsZSBzdWJz Y3JpYmVycyB0byB2aWV3IGRhdGEgdG8gd2hpY2ggdGhleSB3ZXJlIG5vdCBhdXRob3JpemVkIGF0 DQo+ICAgIHRoZSB0aW1lIG9mIGNvbGxlY3Rpb24uDQo+IA0KPiBMb29rcyBsaWtlIHRoZXJlJ3Mg c29tZSB4bWwycmZjIHJlZHVuZGFuY3kgKCJTZWN0aW9ucyBTZWN0aW9uIikuDQoNCkZpeGVkDQoN Cj4gICAgbyAgImV4Y2x1ZGVkLWV2ZW50LXJlY29yZHMiOiBsZWFmIGNhbiBwcm92aWRlIGluZm9y bWF0aW9uIGFib3V0DQo+ICAgICAgIGZpbHRlcmVkIGV2ZW50IHJlY29yZHMuICBBIG5ldHdvcmsg b3BlcmF0b3Igc2hvdWxkIGhhdmUNCj4gICAgICAgcGVybWlzc2lvbnMgdG8ga25vdyBhYm91dCBz dWNoIGZpbHRlcmluZy4gIEltcHJvcGVyIGNvbmZpZ3VyYXRpb24NCj4gICAgICAgY291bGQgcHJv dmlkZSBhIHJlY2VpdmVyIHdpdGggaW5mb3JtYXRpb24gbGVha2FnZSBjb25zaXN0aW5nIG9mDQo+ ICAgICAgIHRoZSBkcm9wcGluZyBvZiBldmVudCByZWNvcmRzLg0KPiANCj4gSW4gbWFpbCBJIGhh ZCBwcm9wb3NlZCAiSW1wcm9wZXIgY29uZmlndXJhdGlvbiBjb3VsZCBhbGxvdyBhIHJlY2VpdmVy IHRvIGxlYXJuDQo+IHRoYXQgZXZlbnQgcmVjb3JkcyB3ZXJlIGRyb3BwZWQgZHVlIHRvIGFuIEFD TCB3aGVuIHRoZSBleGlzdGVuY2Ugb2YgdGhhdCBBQ0wNCj4gd291bGQgb3RoZXJ3aXNlIGJlIHRy YW5zcGFyZW50LiI7IHJlcGVhdGluZyBpdCBoZXJlIGp1c3QgaW4gY2FzZSBpdCBnb3QgbWlzc2Vk DQo+IChidXQgdGhpcyAgcmVtYWlucyB0aGUgbm9uLWJsb2NraW5nIGNvbW1lbnQgc2VjdGlvbiku DQoNCkkgaGFkIHRob3VnaHQgeW91ciBvdGhlciBzZW50ZW5jZSB3YXMgZm9yIGluZm9ybWF0aW9u IHB1cnBvc2VzIHJhdGhlciB0aGFuIHN1Z2dlc3RlZCB0ZXh0IHRvIGluY2x1ZGUuICBUaGlua2lu ZyBhYm91dCBpdCwgSSBwcmVmZXIganVzdCBzdGlja2luZyB3aXRoIHRoZSBjdXJyZW50ICdpbmZv cm1hdGlvbiBsZWFrYWdlJyB0ZXh0IHdpdGhvdXQgZXhwbGljaXRseSB1c2luZyB0aGUgd29yZCBB Q0wuICANCg0KVGhhbmtzIGFnYWluIEJlbmphbWluIGZvciByZWFsbHkgZ2l2aW5nIHRoaXMgYSBn b29kIGxvb2ssDQpFcmljDQoNCg0K From nobody Mon May 6 14:53:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32C912002F; Mon, 6 May 2019 14:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDaSVH1P9t9o; Mon, 6 May 2019 14:53:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7FBCD12001E; Mon, 6 May 2019 14:53:11 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x46Lr6tF013884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 17:53:08 -0400 Date: Mon, 6 May 2019 16:53:05 -0500 From: Benjamin Kaduk To: "Eric Voit (evoit)" Cc: The IESG , "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Message-ID: <20190506215305.GR19509@kduck.mit.edu> References: <155692784695.7217.908270903914526669.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:53:14 -0000 On Mon, May 06, 2019 at 09:46:29PM +0000, Eric Voit (evoit) wrote: > Hi Benjamin > > > From: Benjamin Kaduk, May 3, 2019 7:57 PM > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-netconf-subscribed-notifications-25: Discuss > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > It looks like the description of filter-failure-hint in modify-subscription-stream- > > error-info needs the same treatment that establish-subscription-stream-error- > > info received. > > Done. You will see in the next update. I will post after I get a set of thoughts back from Magnus on his DISCUSS. Sounds good; I've cleared in the datatracker so I can stop paying attention :) > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > [original comment section replaced] > > > > In the updated security considerations: > > > > The replay mechanisms described in Sections Section 2.4.2.1 and > > Section 2.5.6 provides access to historical event records. By > > design, the access control model that protects these records could > > enable subscribers to view data to which they were not authorized at > > the time of collection. > > > > Looks like there's some xml2rfc redundancy ("Sections Section"). > > Fixed > > > o "excluded-event-records": leaf can provide information about > > filtered event records. A network operator should have > > permissions to know about such filtering. Improper configuration > > could provide a receiver with information leakage consisting of > > the dropping of event records. > > > > In mail I had proposed "Improper configuration could allow a receiver to learn > > that event records were dropped due to an ACL when the existence of that ACL > > would otherwise be transparent."; repeating it here just in case it got missed > > (but this remains the non-blocking comment section). > > I had thought your other sentence was for information purposes rather than suggested text to include. Thinking about it, I prefer just sticking with the current 'information leakage' text without explicitly using the word ACL. I'm happy that you have considered it and made your decision; you have a better sense of how things work than I do. > Thanks again Benjamin for really giving this a good look, You're welcome! -Ben From nobody Tue May 7 04:36:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C11120117 for ; Tue, 7 May 2019 04:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP1JI9Kg_j7K for ; Tue, 7 May 2019 04:36:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A008212010C for ; Tue, 7 May 2019 04:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13376; q=dns/txt; s=iport; t=1557229006; x=1558438606; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zWSq/9+X0NBP2Oi1tou3SDTHBSaTxqpvQGjrYpBfnJU=; b=WHtjcftV2Q2ZHu/V16xXZG/gQ97f3RPhrRq3sWxjdXRS5qvA7mpVL2E/ HbNJEzOMxl9jCrGeWbg8HEHZ3NVu4FzQX8OAI7wRU8Uvsr4VSfwsBD/eo hgs9fkHW6f4jD7TDA8kRH1MvReR0G9l5nrHIYLWXQCftK8wQmaBB/7gBh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACNbdFc/5hdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDoECaYEEKAqMIo0IkleFe4F7DgEBhG0CghY?= =?us-ascii?q?jNAkOAQMBAQQBAQIBAm0ohUoBAQEBAycGXAIBCBEEAQEvMh0IAgQBEggTgwi?= =?us-ascii?q?BHW2vBDOKM4EyAYoKgSYdF4FAP4QjPoQAhiYEkiOVHgkCggmSRCOCEJNGg3C?= =?us-ascii?q?IMYEhk1QCERWBMB84gVZwFYMnkFFBMY9qK4EEgSEBAQ?= X-IronPort-AV: E=Sophos;i="5.60,441,1549929600"; d="scan'208,217";a="270353962" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2019 11:36:38 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x47BabHa007429 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 May 2019 11:36:38 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 May 2019 06:36:36 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 7 May 2019 06:36:36 -0500 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAL4+PiAAAVM54ADt02zAAAGzCgAAAQfJ4AABQvugADqhRSAAAgkE4AAKD/bgAABK6oAAAGYSwAABxXrgAA8jwUAAA4ykpAAOGfLgAAGk8WgAAOK8oAACbL7AAAASZ0AALNATcA= Date: Tue, 7 May 2019 11:36:36 +0000 Message-ID: References: <20190503.084757.791827158808672980.mbj@tail-f.com> <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com> <20190503.133743.1149689382943153005.mbj@tail-f.com> <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> In-Reply-To: <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-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.60] Content-Type: multipart/alternative; boundary="_000_e6930b6e52a642bda9f1bd76731ce9c3XCHRCD007ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 11:36:49 -0000 --_000_e6930b6e52a642bda9f1bd76731ce9c3XCHRCD007ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, The problem that I have with generating configuration direct= ly in is that on the device is now different from what = the management system thinks should be in on the device. I.e. it breaks the architectural simplicity that it is only the client that= controls what goes into in , e.g. perhaps that can be summarized = by this flow: "Update client's desired -> "Push to config" " ^ | | \/ "Client notified of <- "Apply config, changes in " updated" However, I would not be opposed to allowing create configura= tion that is persisted separately from and injected into (e.g. merged with ), hence allowing leaf-refs in config validat= ion to work as expected. I think that this would allow device reboot to wo= rk as expected. If the clients would like to see the keys in the configuration then they ca= n monitor (or ), and then add the keys, either in r= aw form, or encrypted in some way. But I still think that it is architectu= rally cleaner if it is always the client that updates the configu= ration and never the device. Thanks, Rob From: netconf On Behalf Of Kent Watsen Sent: 03 May 2019 17:24 To: netconf@ietf.org Subject: Re: [netconf] ietf crypto types - permanently hidden I had an idea last night that might inch us closer to a solution. Essentially, the generate/install-key operations always populate , even for keys that are not-hidden, but then a follow-up operation (som= ething like ) replicates the not-hidden key in t= o . Two options: 1) A regular-access admin executes the actions to generate the key, get a C= SR, configure a resulting signed certificate, etc. and then, as a second st= ep later in time, a special-access admin replicates the key to (p= erhaps using standard and ), so that it can be inc= luded in a standard backup and restored to *any* device (since this key is = "not-hidden", it isn't encrypted with a device-specific key and hence can b= e migrated). 2) A regular-access admin executes the actions to generate the key, get a C= SR, configure a resulting signed certificate, etc. and then, as a second st= ep (ideally immediately after), the regular-access admin executes a command= like , but rather than copying the entire datastore, it just = copies a subtree. Neither option seems great. #1 is unappealing being it necessitates coordi= nation between clients. #2 is unappealing because defining a generic opera= tion for this special case seems too much. IMO, allowing to create the configuration directly is the on= ly client-friendly answer. Kent // contributor --_000_e6930b6e52a642bda9f1bd76731ce9c3XCHRCD007ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

The problem that I have with <generate-key> generating co= nfiguration directly in <running> is that <running> on the devi= ce is now different from what the management system thinks should be in <running> on the device.

 

I.e. it breaks the architectural simplicity that it is only the= client that controls what goes into in <running>, e.g. perhaps that = can be summarized by this flow:

 

“Update client’s desired    ->&nb= sp;  “Push to

config”        &n= bsp;            = ;    <running>”

          ^ &= nbsp;           &nbs= p;          |

          | &= nbsp;           &nbs= p;          \/

“Client notified of      &n= bsp;  <-   “Apply config,

changes in <operational>”    &n= bsp;  <operational> updated”

 

 

However, I would not be opposed to allowing <generate-key>= ; create configuration that is persisted separately from <running> an= d injected into <intended> (e.g. merged with <running>), hence allowing leaf-refs in config validation to work as expected.  I= think that this would allow device reboot to work as expected.<= /span>

 

If the clients would like to see the keys in the configuration = then they can monitor <operational> (or <intended>), and then a= dd the keys, either in raw form, or encrypted in some way.  But I still think that it is architecturally cleaner if it= is always the client that updates the <running> configuration and ne= ver the device.

 

Thanks,

Rob

 

&nbs= p;

&nbs= p;

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 03 May 2019 17:24
To: netconf@ietf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden

 

I had an idea last night that might inch us closer t= o a solution.  

 

Essentially, the generate/install-key operations alw= ays populate <operational>, even for keys that are not-hidden, but th= en a follow-up operation (something like <copy-config>) replicates th= e not-hidden key in <operational> to <running>.    Two options:

 

1) A regular-access admin executes the actions to ge= nerate the key, get a CSR, configure a resulting signed certificate, etc. a= nd then, as a second step later in time, a special-access admin replicates = the key to <running> (perhaps using standard <get-confg> and <edit-config>), so that it can be inc= luded in a standard backup and restored to *any* device (since this key is = "not-hidden", it isn't encrypted with a device-specific key and h= ence can be migrated).

 

2) A regular-access admin executes the actions to ge= nerate the key, get a CSR, configure a resulting signed certificate, etc. a= nd then, as a second step (ideally immediately after), the regular-access a= dmin executes a command like <copy-config>, but rather than copying the entire datastore, it just copies a subtree. &n= bsp; 

 

Neither option seems great.  #1 is unappealing = being it necessitates coordination between clients.  #2 is unappealing= because defining a generic operation for this special case seems too much.=   

 

IMO, allowing <generate-key> to create the con= figuration directly is the only client-friendly answer.

 

 

Kent // contributor

 

--_000_e6930b6e52a642bda9f1bd76731ce9c3XCHRCD007ciscocom_-- From nobody Tue May 7 05:19:30 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DEF1200BA for ; Tue, 7 May 2019 05:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z_tSylUuGUy for ; Tue, 7 May 2019 05:19:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 87DA5120059 for ; Tue, 7 May 2019 05:19:26 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 562AD1AE0398; Tue, 7 May 2019 14:19:23 +0200 (CEST) Date: Tue, 07 May 2019 14:19:26 +0200 (CEST) Message-Id: <20190507.141926.1879619200930898148.mbj@tail-f.com> To: rwilton@cisco.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 12:19:29 -0000 "Rob Wilton (rwilton)" wrote: > Hi Kent, > > The problem that I have with generating configuration > directly in is that on the device is now different > from what the management system thinks should be in on the > device. > > I.e. it breaks the architectural simplicity that it is only the client > that controls what goes into in , e.g. perhaps that can be > summarized by this flow: > > "Update client's desired -> "Push to > config" " > ^ | > | \/ > "Client notified of <- "Apply config, > changes in " updated" > > > However, I would not be opposed to allowing create > configuration that is persisted separately from and injected > into (e.g. merged with ) But this isn't really allowed by the architecture in 8342, imo. If this would have been the case, we'd have another box with config going into "intended". 8342 allows "configuration transformations" between running and intended. > , hence allowing leaf-refs > in config validation to work as expected. I think that this would > allow device reboot to work as expected. > > If the clients would like to see the keys in the configuration then > they can monitor (or ), and then add the keys, > either in raw form, or encrypted in some way. But I still think that > it is architecturally cleaner if it is always the client that updates > the configuration and never the device. I agree. I think it would be worthwile to explore the "non-action-based" solution that Rob proposed. Is there anything in that solution that doesn't work? /martin > > Thanks, > Rob > > > > From: netconf On Behalf Of Kent Watsen > Sent: 03 May 2019 17:24 > To: netconf@ietf.org > Subject: Re: [netconf] ietf crypto types - permanently hidden > > I had an idea last night that might inch us closer to a solution. > > Essentially, the generate/install-key operations always populate > , even for keys that are not-hidden, but then a follow-up > operation (something like ) replicates the not-hidden key > in to . Two options: > > 1) A regular-access admin executes the actions to generate the key, > get a CSR, configure a resulting signed certificate, etc. and then, as > a second step later in time, a special-access admin replicates the key > to (perhaps using standard and ), > so that it can be included in a standard backup and restored to *any* > device (since this key is "not-hidden", it isn't encrypted with a > device-specific key and hence can be migrated). > > 2) A regular-access admin executes the actions to generate the key, > get a CSR, configure a resulting signed certificate, etc. and then, as > a second step (ideally immediately after), the regular-access admin > executes a command like , but rather than copying the > entire datastore, it just copies a subtree. > > Neither option seems great. #1 is unappealing being it necessitates > coordination between clients. #2 is unappealing because defining a > generic operation for this special case seems too much. > > IMO, allowing to create the configuration directly is > the only client-friendly answer. > > > Kent // contributor > From nobody Tue May 7 05:50:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5897412012C; Tue, 7 May 2019 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9oSBZ-oZKxH; Tue, 7 May 2019 05:50:10 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20066.outbound.protection.outlook.com [40.107.2.66]) (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 EA790120058; Tue, 7 May 2019 05:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zniLpG1kOgiKTAaO2i7nKpLjdFZ25QqvTRHutinvI5c=; b=FGUU5DwjJx+IjK1z1BWtgIxBZ18gGhJwE5kyU0VptVin7GUaLgib20Q4PjFDK10cN0lOn2X7xtug4OpPOuwJayJqMBSgD6Qz/TkBoBexRhJN1dgizHDuPsfp9Vu8Rp5RINcOmMsqMArWDcIvmHaDHARVRIVD7LADsp0O32JBy0g= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2523.eurprd07.prod.outlook.com (10.168.129.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.19; Tue, 7 May 2019 12:50:06 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1878.019; Tue, 7 May 2019 12:50:06 +0000 From: Magnus Westerlund To: "Eric Voit (evoit)" , The IESG CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) Thread-Index: AQHVAOIY2D7aivy2PU25mAR0nTlyqA== Date: Tue, 7 May 2019 12:50:06 +0000 Message-ID: References: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> <7efee2607c62458d865ce663f9d4fc27@XCH-RTP-013.cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c549dbd7-0f74-41f0-a0c9-08d6d2ea8815 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2523; x-ms-traffictypediagnostic: HE1PR0701MB2523: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(396003)(366004)(51914003)(51444003)(85664002)(189003)(199004)(54906003)(4326008)(110136005)(73956011)(66946007)(66476007)(66556008)(64756008)(76116006)(33656002)(102836004)(99286004)(6506007)(52536014)(76176011)(7696005)(2906002)(6246003)(6116002)(53546011)(74316002)(14454004)(66066001)(966005)(53936002)(3846002)(68736007)(15650500001)(478600001)(9686003)(476003)(54896002)(446003)(236005)(6306002)(55016002)(44832011)(486006)(21615005)(7736002)(6436002)(71190400001)(71200400001)(30864003)(5660300002)(66446008)(256004)(14444005)(66574012)(8676002)(81156014)(81166006)(8936002)(86362001)(316002)(25786009)(229853002)(186003)(26005)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2523; H:HE1PR0701MB2522.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: u2Ofn+MmKhyduvbAf6ZwW+5tZdDHcgwpjvAVMSp/tTar7QuoPhBAs5/9z+QxJ/pJU+y4+S/XPFS9gfoRXQWkBRSA1cCnU71WBLD1wXlFD4t+NS5AQcEOKovwCilBILwQhua+JCYRTnTj6AnzawnqZ2L2se2YvGBFvjRR9usgWbDN3HrSvpMJ1s1XQdEyaCuAPS7MpUe7BPeCzN2mkAK5ZUSbc2wBbgAffp7fcD9GUelCqxYLfn2+hF60/kEm/a42PdCoDBGOY9vnLeOJYc+Brxb2lWPxF7e+dn13xqzdjhGpVVo53a/lW3BlsU9RCjU+7yrW1yfToEMuNxswOaaRw6fjIfKYMFbkcjfTfFBpOS+L6Cmn3/dR/hNyosTmD9H3FV8vfzAJLSdS5fYjK2Z4vjk/yxu3+sN7k9WkJkyviHU= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522DA9FB3E9C9F0FB25597E95310HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c549dbd7-0f74-41f0-a0c9-08d6d2ea8815 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 12:50:06.4921 (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: HE1PR0701MB2523 Archived-At: Subject: Re: [netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 12:50:19 -0000 --_000_HE1PR0701MB2522DA9FB3E9C9F0FB25597E95310HE1PR0701MB2522_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for the answers. I think we are making progress here, see below. What I see is that there need to be some text changes in the QoS parts. Regarding the priority I get the impression that it is not the WG's intenti= on to clarify this. However, I would wish that the document is a bit more e= xplicit about the lack of any interface to affect the publisher's action wh= en it comes to dropping subscriptions. Yes there is this paragraph in Secti= on 1.3: A publisher MAY terminate a dynamic subscription at any time. Similarly, it MAY decide to temporarily suspend the sending of notification messages for any dynamic subscription, or for one or more receivers of a configured subscription. Such termination or suspension is driven by internal considerations of the publisher. So I guess I have to drop this aspect now when the explicit reference to pr= iority based actions are removed. On 2019-05-06 23:19, Eric Voit (evoit) wrote: Hi Magnus, Thanks very much for your comments. Thoughts in-line... From: Magnus Westerlund, May 2, 2019 8:25 AM Magnus Westerlund has entered the following ballot position for draft-ietf-netconf-subscribed-notifications-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introduct= ory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification= s/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- My focus when reviewing this document was from a perspective of how to handle overload. You are absolutely correct to focus on overload. Mitigating different dime= nsions of the overload risk has been a design goal since this effort=92s in= ception. And this is the reason a variety of QoS mechanisms were included = in the document. I have a hard time understanding how this will actually work, especially in a fashion that preservers goodput and ensure what is consider= ed the most important subscriptions are delivered. Not having good undertandin= g into netconf and restconf don't hesitate to call out likely missunderstandi= ng by me and provide clarification and pointers. Few of the mechanisms are specific to either RESTCONF or NETCONF. For comp= leteness reasons, let me summarize the overload mechanisms available... 1. The publisher is allowed to decline a dynamic subscription. One of thes= e reasons is that the incremental traffic generated by a particular increme= ntal subscription will be too high. There are errors back to the subscribe= r indicating this condition exist. 2. A publisher can suspend any subscription for capacity reasons, and a rec= eiver must be able to gracefully accept this suspension. 3. Much like with HTTP2 streams, higher priority subscriptions intended for= a particular receiver can be dequeued first from a publisher. 4. Much like with HTTP2 streams, proportional subscription dequeuing intend= ed for a particular receiver can be performed a publisher. 5. DSCP markings can be placed on subscribed data. 6. Mechanisms for detecting and reacting to different types of subscribed d= ata loss have been embedded. 7. Methods have been included to ensure a configured receiver =93ok=92s=94 = information push before subscribed data is sent. (This should reduce one DD= oS vector.) 8. Keep alive mechanisms are established for different transport types, so = that subscribed data isn=92t being sent when the is no receiver listening. Mechanisms (3) & (4) will likely be seen only with HTTP2 based transports.*= This is because (as documented within draft-ietf-netconf-restconf-notif = section 4), these capabilities are to integrated directly HTTP2 RFC-7450 se= ctions 5.3.1 & 5.3.2. To me the big weakness of this mechanism are actually in the API between th= e receiver and the publisher. The current API defined by this document does= not include any information that allow the receiver to express its actual = view on priority for a subscription. It has some other tools that has compl= etely different meanings namely: - Transport level DSCP expressing PHB and routing priority - Weight: Proportional bandwidth distribution - Dependency: Deliver this only after this other subscription None of this expresses anything related to the priority or importance to ma= intain a particular subscription, nor does the interface carry any informat= ion regarding what delivery requirements the receiver have on the subscript= ion. Thus, the behavior in overload situation is going to be totally random= . So if the WG is okay with this being the case I will hold my nose. However,= I think the fact that random implementation dependent things will happen i= n overload should be explicitly stated in the document. * One background/review note... Earlier versions of draft-ietf-netconf-sub= scribed-notifications included specific parallels to RFC-7450 when describi= ng (3) & (4). However WG members wanted to abstract away what they felt we= re HTTP2 specific references. This is despite the fact that what was being = referenced was the desired functional behavior rather than anything HTTP2 s= pecific. I can understand the WG reviewers' concern. This is already a l= ong document, and a reader who only cares about NETCONF hopefully won't nee= d to wade through complex issues which they are unlikely to worry about in = deployment. I did a brief look at the transports. They did not answer my questions when= I wrote this discuss. Also, to my understanding the HTTP/2 priority mechan= ism is that is far from easy to use and also intended to distribute resourc= es in an ongoing transmission. That doesn't actually match the higher level= need of determining which subscription are more important than another. Do= esn't a 5 level priority value cover a lot of the missing ground here? A) The QoS and priority sending mechanism discussed in 2.3 and furhter defi= ned by the YANG model. I do want to raise the usage of the DSCP code point to a discuss. As the DS= CP defines different PHB and relative priorities in the router queues a DSCP v= alue does not provide the publisher any information about priority. I get the fe= eling from the text that this may be intended. If the only intention is to have t= he transport perform differential treatment in the network between the publish= er and the receiver Yes, this is the case. there are still more considerations are needed. First of all I think these sentence needs a total rewrite: If the publisher supports the "dscp" feature, then a subscription with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP marking being placed within the IP header of any resulting notification messages and subscription state change notifications. Where TCP is used, a publisher which supports the "dscp" feature SHOULD ensure that a subscription's notification messages are returned within a single TCP transport session where all traffic shares the subscription's "dscp" leaf value. I think one need to put a requriement on the transport to use a transport t= hat utilize the DSCP marking on its traffic. I believe you are asking for a the publisher respect the DSCP markings for= traffic egressing an interface on a publisher. Yes this requirement was a= ssumed, and can be explicitly added. Please do. Which for the current set of connection oriented transport protocols, TCP, SCTP, and QUIC all currently only suppor= t using a single DSCP per connection. Implying multiple transport protocol connections using a particular transport to enable this mapping. Yes fully agree, a connection would be needed per DSCP. Is your objecti= on with the text above the words "SHOULD ensure" rather than "MUST ensure"?= If yes, I can ask the WG objects to whether this requirement should be = a MUST. If you think you should use RFC 2119 language, yes then I reuqest a MUST. H= owever, I think reformulating this so state it as a fact that different DSC= P code points requires different transport connections, unless a transport = supporting multiple DSCP simultanous are used (No standardized option that = has reliable object or stream semantics exist to my knowledge). A.2 Queuing model of a publisher. With the DSCP and the Weight and dependency model I think it is important t= o clarify the model of the queueing in the publisher. So is the intention tha= t several subscriptions with different weights and possibly dependencies have their individual queues that goes into a scheduler? As you know, queuing models are non-trivial. For that reason we wanted to= 100% adopt the functional behavior RFC-7540 Section 5.3.1 and 5.3.2 withou= t having to re-document/mirror that content at a higher level of the networ= k stack. We are a hoping that a reader of network subscriptions can look = to well documented, implemented HTTP2 behaviors as applicable. Providing a= n intermediate layer of functional description could easily result in some = mis-alignments from what is intended. Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540 is= all within a single TCP connection. Thus, to avoid complexities I think yo= u at least need to be explicit that one can only perform Dependency and Wei= ght operations between subscriptions that share DSCP, and that they become = independent queues. To avoid complex queue interactions on this level I think there need to be seperate scheduler inst= ances per DSCP. I would also note that Dependency mechanism can't ensure that a dependent stream arrive at receiver after the identified dependency if they= are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not even guarantee it within a single connection and same DSCP due to packet lo= ss impact. To me this model and what relationship one need to consider here ne= ed to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication = of just the importance of considering what is in the same dependency tree and what it means to have different weighting. To conclude I think this needs a model description and clearer definition and possibly requirements towards the transport. Espceially if you actually need an in-order delivery requirement= ? I think we have the same technical objective in mind. And it is absolutel= y the desire to have identical behavior to RFC-7540 Section 5.3.1 and 5.3.2= . For the current set of documents before the IESG, we include within dr= aft-ietf-netconf-restconf-notif Section 4, a 1:1 mapping between draft-ietf= -netconf-subscribed-notifications and RFC-7540. We are hoping that the transport documents like draft-ietf-netconf-restconf= -notif can be the place where such supporting documentation and mappings oc= cur. I still think that this document needs to have that sentence in their stati= ng that Dependency and Weight applies only per subscription sharing DSCP va= lue. Because these values are define on this document level, not on the map= ping level that the individual transport exists on. And this is the interfa= ce the WG have defined for this. And as it currently stands you appear to h= ave something that lacks a clear meaning. B. The unpredictability of the circuit breaker overload mechanism. My description of the overload handling in this document is that it is a ci= rcuit breaker based mechanism that can blow a fuse on subscriptions that it fails= to honor in overload situations. What worries me deply is the total unpredicta= bility of this mechanism. At the beginning of this email, there are eight methods of overflow handlin= g listed. We optimized these eight mechanisms for different failure scenar= ios and congestion conditions. Our goal was to depend on existing mechani= sms/technologies wherever possible. Reuse of existing mechanisms should re= duce at least some of the unpredictability. First, is it the intention to derive what subscriptions are least important= from the DSCP, weighting and Dependency parameters? If it is, I think that may be a misstake as priority on what subscriptions are most important to retain are= not necessarily reflected in their QoS parameters. At this point the document does not attempt to define "important". All tha= t is done is to provide guidance relating to some elements of network trans= port. If there is a dimension of "importance" which an implementer would = like to layer onto this solution, it could be done. For example, "importan= ce" could applied in areas such as what subscriptions should be suspended = in case of CPU exhaust. However guidance on such enhancements are not inc= luded in this document. Still it is both implied and explicitly stated in one place. Secondly, what are the values when a subscription are considered to be to h= eavy or not be handled accordingly. Are there any parameter sets that actually describe what SLA the subscriber expect that can be converted into timeout timers or buffer depth thresholds to indicate that publisher side isn't del= ivering these in time? There is no guidance on this provided in the document. As equipment types= , subscription volumes, available memory, will vary between solutions, this= will take a while to dimension properly. I can imagine someday that we mi= ght have something like "Erlang for subscriptions" much like we used Erlang= s in the old telephony network to dimension call handling capabilities of p= hone switches. But we are a long way from that. To be clear what I mean with SLA here is to express some boundaries on when= the subscribed to information will be received by the receiver compared to= when it come to existence on the publisher side. However, I do hear you th= at there is nothing defined and nothing in the pipeline. Third, I what I understand there are no any additional back pressure mechan= ism between the receiver and the publisher than the transport protocols flow control? So a receiver that is not keeping up processing the data it proces= s will not read out the data out of the flow controlled buffers in the receiver an= d thus prevent the publisher to write to the transport conncetion, thus causing th= e publisher to eventually trigger a suspension due to its queue build up? There is nothing beyond transport flow control. We thought about it initia= lly, but we were not ready to pick up even more complexity than we already = had. Ok, which just contribute to what I call random things happen at overload. To my understanding the current mechanism places all subscriptions on the same importance and with the same SLA. Thus likely causing short term overl= oad situations to cause subscription suspensions in random subscriptions. Is th= e WG fine with this type of randomness occuring and expecting that normally ther= e will be such amount of overprovisioning that being able to indicate priorit= y and SLA are overkill? Yes. We needed a starting point. And there are technical solutions which= can be layered on top. But what we have now took many years to finalize,= and should be a big enough technical jump considering our current knowledg= e. At a minimal a change of this sentence in Section 2.5.1 is needed: This could be for reasons of an unexpected but sustained increase in an event stream's event records, degraded CPU capacity, a more complex referenced filter, or other higher priority subscriptions which have usurped resources. I have removed "higher priority". Thanks. As it states that subscriptions has priorities without reference to a mecha= nism that provides that priority. C. 2.4.5. Killing a Dynamic Subscription The "kill-subscription" operation permits an operator to end a dynamic subscription which is not associated with the transport session used for the RPC. A publisher MUST terminate any dynamic subscription identified by the "id" parameter in the RPC request, if such a subscription exists. Can someone please clarify the use case for this functionality. To my understanding it allows another receiver given authority to kill the subscr= iption being delivered to another receiver. Based on the otherwise rather strict t= hat all manipulations of dynamic subscriptions happens from the transport session context that established it I want to better understand the use case it app= ears out place. A network operator needs a very secure mechanism to end a dynamic subscript= ion in progress which it sees as harmful. The operator cannot do this via= configuration operations, as the dynamic subscription is not configured (a= nd therefore cannot be deleted in the configuration datastore). Thanks, that clarification resolves my question mark. So lets close this is= sue without any actions. D. The Requirements on a transport supporting Configured Subscriptions Reading through Section 2.5 I arrived at a number of questions. I tried to understand what the requirements are for the transport that supports Configured Subscriptions. I did note that neither draft-ietf-netconf-restco= nf- notif-13 nor draft-ietf-netconf-netconf-event-notifications-17 supports configured subscriptions. Thus, there appear no template for a solution either, or doe= s there exist another document that is being worked on defining such a transp= ort? This is the case. Originally both of those documents *did* include config= ured subscriptions. However within the WG there was a decision not to prog= ress configured subscriptions yet. One reason is that other YANG model dra= fts moving in the NETCONF WG were seen as pre-requisites for securely creat= ing transport sessions via call home for the configured subscriptions. As = a result, support for configured subscriptions was extracted from those tra= nsport documents. It is expected that that updated versions of just those= transport documents will be driven when the YANG models complete. Look at the responses below I see that we are in one of these situation whe= re things are deliberately left open. I will simply assume that this is don= e in a way that supports those future definitions and clarifications. So le= ts close this issue without any actions. Questions that arose for me related to Configured Susbription Transport whe= re the following: 1. Can Transport Session be initiated in both direction. RFC 8071 provides a solution for Publisher to Receiver initiation. It is unclea= r if all parts are in place to have a receiver to publisher initiated transport to b= e bound to the subscription. This will be up to a specific transport draft to make this determination. To see what might be viable for NETCONF, check out the earlier version of t= he document at: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notificat= ions/10/ This was seen as a complete version of such a solution. However the WG wan= ted a YANG model for session parameters discussed in Section 5.2. 2. What is "name" really? It appears to be defined as an empty container. Despite that it appears to have requirements on being both= a security identity as well as network address. You are correct. In previous versions of this draft, a receiver was identi= fied by the combination of address + port. However due to the YANG doctor = reviews, and call home discussions referenced above, the WG wasn't ready to= finalize this YANG structure. The compromise was the current structure, p= lus the example YANG model of Appendix A to show how this might be built ou= t. 3. In Figure 9, which is stated to be for the receiver. What information does the receiver use to determine the transition (d)? And what does it do in this step. Related to Discuss part B= ). This determination is implementation specific. 4. RFC 8071 appears to lack any considerations for how often and how many times it attempts to connect to the receiver. So applying that mechanism appears to require some usage guidance to avoid causing overload situations or DoS potential by misconfiguring network devices with this soltution to dial out frequently to a target. As the transport solution requirements are not detail it is actually hard t= o determine if there are short comings in the description in Section 2.5 and = the corresponding YANG model. Is it an reasonable request to document these requirements? The requirements were documented for both NETCONF and RESTCONF. However t= hese requirements were removed when the WG decided to wait until there was = a YANG model for RFC-8071 ready to go to the IESG. For a preview on what = these requirements might look like, I refer you to Section 5.2 of https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notificat= ions/10/ Thanks, so this is clearly something to have in mind when the WG do get to = specify a solution for this. So I don't see a need for any actions here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 2.3: DSCP domains I think the text could benefit from pointing out that the subscriber actual= ly needs to know what the DSCP values represents in the diffserv domain of the publi= sher. As these could be different, they also create an interesting problems for transports of how they establish a transport connection that uses a particu= lar DSCP, as the receiver if initiating need to know the local DSCP value that corresponds to the behavior in the publisher's domain. This makes sense. I have added in Section 5.3 Transport Requirements a new entry which states= : "A subscriber which includes a "dscp" leaf within an "establish-subscriptio= n" request will need to understand and consider what the corresponding DSCP= value represents within the domain of the publisher." Let me know if this is not sufficient. 2. In general I think there are more than one description that are fuzzy ab= out if it describes a publisher or receiver action/requirement. It would be great if you have some specifics. The authors and previous re= viewers likely have looked at this often enough where things look obvious w= hich perhaps are not. Sorry, didn't take note about those confusion. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB2522DA9FB3E9C9F0FB25597E95310HE1PR0701MB2522_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thanks for the answers. I think we are makin= g progress here, see below.

What I see is that there need to be some tex= t changes in the QoS parts.

Regarding the priority I get the impression = that it is not the WG's intention to clarify this. However, I would wish th= at the document is a bit more explicit about the lack of any interface to a= ffect the publisher's action when it comes to dropping subscriptions. Yes there is this paragraph in Section= 1.3: 
   A publisher MAY terminate a dynamic subscription at any time.=0A=
   Similarly, it MAY decide to temporarily suspend the sending of=0A=
   notification messages for any dynamic subscription, or for one or=0A=
   more receivers of a configured subscription.  Such termination or=0A=
   suspension is driven by internal considerations of the publisher.=0A=
=0A=
So I guess I have to drop this aspect now when the explicit reference to pr=
iority based actions are removed.=0A=
=0A=
=0A=
=0A=

On 2019-05-06 23:19, Eric Voit (evoit) wrote= :
Hi Magnus,=0A=
=0A=
Thanks very much for your comments.   Thoughts in-line...=0A=
=0A=

From: Magnus Westerlund, May 2, 2019=
 8:25 AM=0A=
=0A=
Magnus Westerlund has entered the following ballot position for=0A=
draft-ietf-netconf-subscribed-notifications-25: Discuss=0A=
=0A=
When responding, please keep the subject line intact and reply to all email=
=0A=
addresses included in the To and CC lines. (Feel free to cut this introduct=
ory=0A=
paragraph, however.)=0A=
=0A=
=0A=
Please refer to https://www.ietf.org/iesg/statem=
ent/discuss-criteria.html=0A=
for more information about IESG DISCUSS and COMMENT positions.=0A=
=0A=
=0A=
The document, along with other ballot positions, can be found here:=0A=
https://datatracker.ietf.org=
/doc/draft-ietf-netconf-subscribed-notifications/=0A=
=0A=
=0A=
=0A=
----------------------------------------------------------------------=0A=
DISCUSS:=0A=
----------------------------------------------------------------------=0A=
=0A=
My focus when reviewing this document was from a perspective of how to=0A=
handle overload. =0A=

=0A=
You are absolutely correct to focus on overload.  Mitigating different dime=
nsions of the overload risk has been a design goal since this effort=92s in=
ception.  And this is the reason a variety of QoS mechanisms were included =
in the document.=0A=
=0A=

I have a hard time understanding how=
 this will actually work,=0A=
especially in a fashion that preservers goodput and ensure what is consider=
ed=0A=
the most important subscriptions are delivered. Not having good undertandin=
g=0A=
into netconf and restconf don't hesitate to call out likely missunderstandi=
ng by=0A=
me and provide clarification and pointers.=0A=

=0A=
Few of the mechanisms are specific to either RESTCONF or NETCONF.  For comp=
leteness reasons, let me summarize the overload mechanisms available...=0A=
=0A=
1. The publisher is allowed to decline a dynamic subscription.  One of thes=
e reasons is that the incremental traffic generated by a particular increme=
ntal subscription will be too high.  There are errors back to the subscribe=
r indicating this condition exist.=0A=
2. A publisher can suspend any subscription for capacity reasons, and a rec=
eiver must be able to gracefully accept this suspension. =0A=
3. Much like with HTTP2 streams, higher priority subscriptions intended for=
 a particular receiver can be dequeued first from a publisher. =0A=
4. Much like with HTTP2 streams, proportional subscription dequeuing intend=
ed for a particular receiver can be performed a publisher.=0A=
5. DSCP markings can be placed on subscribed data.=0A=
6. Mechanisms for detecting and reacting to different types of subscribed d=
ata loss have been embedded.=0A=
7. Methods have been included to ensure a configured receiver =93ok=92s=94 =
information push before subscribed data is sent. (This should reduce one DD=
oS vector.) =0A=
8. Keep alive mechanisms are established for different transport types, so =
that subscribed data isn=92t being sent when the is no receiver listening.=
=0A=
=0A=
Mechanisms (3) & (4) will likely be seen only with HTTP2 based transpor=
ts.*   This is because (as documented within draft-ietf-netconf-restconf-no=
tif section 4), these capabilities are to integrated directly HTTP2 RFC-745=
0 sections 5.3.1 & 5.3.2.

To me the big weakness of this mechanism are actually in the API between= the receiver and the publisher. The current API defined by this document d= oes not include any information that allow the receiver to express its actu= al view on priority for a subscription. It has some other tools that has completely different meanings namely:

- Transport level DSCP expressing PHB and routing priority

- Weight: Proportional bandwidth distribution

- Dependency: Deliver this only after this other subscription

None of this expresses anything related to the priority or importance to= maintain a particular subscription, nor does the interface carry any infor= mation regarding what delivery requirements the receiver have on the subscr= iption. Thus, the behavior in overload situation is going to be totally random.

So if the WG is okay with this being the case I will hold my nose. Howev= er, I think the fact that random implementation dependent things will happe= n in overload should be explicitly stated in the document. 


=0A=
=0A=
* One background/review note...  Earlier versions of draft-ietf-netconf-sub=
scribed-notifications included specific parallels to RFC-7450 when describi=
ng (3) & (4).  However WG members wanted to abstract away what they fel=
t were HTTP2 specific references. This is despite the fact that what was be=
ing referenced was the desired functional behavior rather than anything HTT=
P2 specific.   I can understand the WG reviewers' concern.  This is already=
 a long document, and a reader who only cares about NETCONF hopefully won't=
 need to wade through complex issues which they are unlikely to worry about=
 in deployment.

I did a brief look at the transports. They did not answer my questions w= hen I wrote this discuss. Also, to my understanding the HTTP/2 priority mec= hanism is that is far from easy to use and also intended to distribute reso= urces in an ongoing transmission. That doesn't actually match the higher level need of determining which sub= scription are more important than another. Doesn't a 5 level priority value= cover a lot of the missing ground here? 


=0A=
=0A=

A) The QoS and priority sending mech=
anism discussed in 2.3 and furhter defined=0A=
by the YANG model.=0A=
=0A=
I do want to raise the usage of the DSCP code point to a discuss. As the DS=
CP=0A=
defines different PHB and relative priorities in the router queues a DSCP v=
alue=0A=
does not provide the publisher any information about priority. I get the fe=
eling=0A=
from the text that this may be intended. If the only intention is to have t=
he=0A=
transport perform differential treatment in the network between the publish=
er=0A=
and the receiver =0A=

=0A=
Yes, this is the case.=0A=
=0A=

there are still more considerations =
are needed.=0A=
First of all I think these sentence needs a total rewrite:=0A=
=0A=
   If the publisher supports the "dscp" feature, then a subscript=
ion=0A=
   with a "dscp" leaf MUST result in a corresponding [RFC2474] DS=
CP=0A=
   marking being placed within the IP header of any resulting=0A=
   notification messages and subscription state change notifications.=0A=
   Where TCP is used, a publisher which supports the "dscp" featu=
re=0A=
   SHOULD ensure that a subscription's notification messages are=0A=
   returned within a single TCP transport session where all traffic=0A=
   shares the subscription's "dscp" leaf value.=0A=
=0A=
I think one need to put a requriement on the transport to use a transport t=
hat=0A=
utilize the DSCP marking on its traffic. =0A=

=0A=
I believe you are asking for a  the publisher respect the DSCP markings for=
 traffic egressing an interface on a publisher.  Yes this requirement was a=
ssumed, and can be explicitly added.

Please do. 

=0A=
=0A=

Which for the current set of connect=
ion=0A=
oriented transport protocols, TCP, SCTP, and QUIC all currently only suppor=
t=0A=
using a single DSCP per connection. Implying multiple transport protocol=0A=
connections using a particular transport to enable this mapping.=0A=

=0A=
Yes fully agree, a connection would be needed per DSCP.     Is your objecti=
on with the text above the words "SHOULD ensure" rather than &quo=
t;MUST ensure"?    If yes, I can ask the WG objects to whether this re=
quirement should be a MUST.


If you think you should use RFC 2119 language, yes then I reuqest a MUST= . However, I think reformulating this so state it as a fact that different = DSCP code points requires different transport connections, unless a transpo= rt supporting multiple DSCP simultanous are used (No standardized option that has reliable object or stream semant= ics exist to my knowledge). 


=0A=
=0A=

A.2 Queuing model of a publisher.=0A=
With the DSCP and the Weight and dependency model I think it is important t=
o=0A=
clarify the model of the queueing in the publisher. So is the intention tha=
t several=0A=
subscriptions with different weights and possibly dependencies have their=
=0A=
individual queues that goes into a scheduler?=0A=

=0A=
As you know, queuing models are non-trivial.   For that reason we wanted to=
 100% adopt the functional behavior RFC-7540 Section 5.3.1 and 5.3.2 withou=
t having to re-document/mirror that content at a higher level of the networ=
k stack.   We are a hoping that a reader of network subscriptions can look =
to well documented, implemented HTTP2 behaviors as applicable.  Providing a=
n intermediate layer of functional description could easily result in some =
mis-alignments from what is intended.

Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540= is all within a single TCP connection. Thus, to avoid complexities I think= you at least need to be explicit that one can only perform Dependency and = Weight operations between subscriptions that share DSCP, and that they become independent queues. 

=0A=
=0A=

To avoid complex queue=0A=
interactions on this level I think there need to be seperate scheduler inst=
ances=0A=
per DSCP. I would also note that Dependency mechanism can't ensure that a=
=0A=
dependent stream arrive at receiver after the identified dependency if they=
 are=0A=
on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not=
=0A=
even guarantee it within a single connection and same DSCP due to packet lo=
ss=0A=
impact. To me this model and what relationship one need to consider here ne=
ed=0A=
to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication =
of just the=0A=
importance of considering what is in the same dependency tree and what it=
=0A=
means to have different weighting. To conclude I think this needs a model=
=0A=
description and clearer definition and possibly requirements towards the=0A=
transport. Espceially if you actually need an in-order delivery requirement=
?=0A=

=0A=
I think we have the same technical objective in mind.   And it is absolutel=
y the desire to have identical behavior to RFC-7540 Section 5.3.1 and 5.3.2=
.    For the current set of documents before the IESG, we include within dr=
aft-ietf-netconf-restconf-notif Section 4, a 1:1 mapping between draft-ietf=
-netconf-subscribed-notifications and RFC-7540.    =0A=
=0A=
We are hoping that the transport documents like draft-ietf-netconf-restconf=
-notif can be the place where such supporting documentation and mappings oc=
cur.

I still think that this document needs to have that sentence in their st= ating that Dependency and Weight applies only per subscription sharing DSCP= value. Because these values are define on this document level, not on the = mapping level that the individual transport exists on. And this is the interface the WG have defined for thi= s. And as it currently stands you appear to have something that lacks a cle= ar meaning. 


=0A=
=0A=

B. The unpredictability of the circu=
it breaker overload mechanism.=0A=
=0A=
My description of the overload handling in this document is that it is a ci=
rcuit=0A=
breaker based mechanism that can blow a fuse on subscriptions that it fails=
 to=0A=
honor in overload situations. What worries me deply is the total unpredicta=
bility=0A=
of this mechanism.=0A=

=0A=
At the beginning of this email, there are eight methods of overflow handlin=
g listed.  We optimized these eight mechanisms for different failure scenar=
ios and congestion conditions.   Our goal was to depend on existing mechani=
sms/technologies wherever possible.  Reuse of existing mechanisms should re=
duce at least some of the unpredictability.=0A=
=0A=

First, is it the intention to derive=
 what subscriptions are least important from the=0A=
DSCP, weighting and Dependency parameters? If it is, I think that may be a=
=0A=
misstake as priority on what subscriptions are most important to retain are=
 not=0A=
necessarily reflected in their QoS parameters.=0A=

=0A=
At this point the document does not attempt to define "important"=
.  All that is done is to provide guidance relating to some elements of net=
work transport.   If there is a dimension of "importance" which a=
n implementer would like to layer onto this solution, it could be done.  Fo=
r example, "importance" could applied in areas such as what subsc=
riptions should be suspended  in case of CPU exhaust.   However guidance on=
 such enhancements are not included in this document.=0A=

Still it is both implied and explicitly stated in one place. 


=0A=

Secondly, what are the values when a=
 subscription are considered to be to heavy=0A=
or not be handled accordingly. Are there any parameter sets that actually=
=0A=
describe what SLA the subscriber expect that can be converted into timeout=
=0A=
timers or buffer depth thresholds to indicate that publisher side isn't del=
ivering=0A=
these in time?=0A=

=0A=
There is no guidance on this provided in the document.   As equipment types=
, subscription volumes, available memory, will vary between solutions, this=
 will take a while to dimension properly.  I can imagine someday that we mi=
ght have something like "Erlang for subscriptions" much like we u=
sed Erlangs in the old telephony network to dimension call handling capabil=
ities of phone switches.  But we are a long way from that.

To be clear what I mean with SLA here is to express some boundaries on w= hen the subscribed to information will be received by the receiver compared= to when it come to existence on the publisher side. However, I do hear you= that there is nothing defined and nothing in the pipeline. 


=0A=
 =0A=

Third, I what I understand there are=
 no any additional back pressure mechanism=0A=
between the receiver and the publisher than the transport protocols flow=0A=
control? So a receiver that is not keeping up processing the data it proces=
s will=0A=
not read out the data out of the flow controlled buffers in the receiver an=
d thus=0A=
prevent the publisher to write to the transport conncetion, thus causing th=
e=0A=
publisher to eventually trigger a suspension due to its queue build up?=0A=

=0A=
There is nothing beyond transport flow control.  We thought about it initia=
lly, but we were not ready to pick up even more complexity than we already =
had.

Ok, which just contribute to what I call random things happen at overloa= d. 

=0A=
=0A=

To my understanding the current mech=
anism places all subscriptions on the=0A=
same importance and with the same SLA. Thus likely causing short term overl=
oad=0A=
situations to cause subscription suspensions in random subscriptions. Is th=
e WG=0A=
fine with this type of randomness occuring and expecting that normally ther=
e=0A=
will be such amount of overprovisioning that being able to indicate priorit=
y and=0A=
SLA are overkill?=0A=

=0A=
Yes.   We needed a starting point.  And there are technical solutions which=
 can be layered on top.   But what we have now took many years to finalize,=
 and should be a big enough technical jump considering our current knowledg=
e.=0A=
=0A=

At a minimal a change of this senten=
ce in Section 2.5.1 is needed:=0A=
=0A=
  This could=0A=
   be for reasons of an unexpected but sustained increase in an event=0A=
   stream's event records, degraded CPU capacity, a more complex=0A=
   referenced filter, or other higher priority subscriptions which have=0A=
   usurped resources.=0A=

=0A=
I have removed "higher priority".

Thanks.

=0A=
=0A=

As it states that subscriptions has =
priorities without reference to a mechanism=0A=
that provides that priority.=0A=
=0A=
C. 2.4.5.  Killing a Dynamic Subscription=0A=
=0A=
   The "kill-subscription" operation permits an operator to end a=
=0A=
   dynamic subscription which is not associated with the transport=0A=
   session used for the RPC.  A publisher MUST terminate any dynamic=0A=
   subscription identified by the "id" parameter in the RPC reque=
st, if=0A=
   such a subscription exists.=0A=
=0A=
Can someone please clarify the use case for this functionality. To my=0A=
understanding it allows another receiver given authority to kill the subscr=
iption=0A=
being delivered to another receiver. Based on the otherwise rather strict t=
hat all=0A=
manipulations of dynamic subscriptions happens from the transport session=
=0A=
context that established it I want to better understand the use case it app=
ears=0A=
out place.=0A=

=0A=
A network operator needs a very secure mechanism to end a dynamic subscript=
ion in progress which it sees as harmful.   The operator cannot do this via=
 configuration operations, as the dynamic subscription is not configured (a=
nd therefore cannot be deleted in the configuration datastore).

Thanks, that clarification resolves my question mark. So lets close this= issue without any actions. 

=0A=
=0A=

D. The Requirements on a transport s=
upporting Configured Subscriptions=0A=
Reading through Section 2.5 I arrived at a number of questions. I tried to=
=0A=
understand what the requirements are for the transport that supports=0A=
Configured Subscriptions. I did note that neither draft-ietf-netconf-restco=
nf-=0A=
notif-13 nor=0A=
draft-ietf-netconf-netconf-event-notifications-17 supports configured=0A=
subscriptions. Thus, there appear no template for a solution either, or doe=
s=0A=
there exist another document that is being worked on defining such a transp=
ort?=0A=

=0A=
This is the case.   Originally both of those documents *did* include config=
ured subscriptions.  However within the WG there was a decision not to prog=
ress configured subscriptions yet.  One reason is that other YANG model dra=
fts moving in the NETCONF WG were seen as pre-requisites for securely creat=
ing transport sessions via call home for the configured subscriptions.  As =
a result, support for configured subscriptions was extracted from those tra=
nsport documents.   It is expected that that updated versions of just those=
 transport documents will be driven when the YANG models complete.=0A=

Look at the responses below I see that we are in one of these situation = where things are deliberately left open. I will simply assume that this is = done in a way that supports those future definitions and clarifications. So= lets close this issue without any actions. 

=0A=

Questions that arose for me related =
to Configured Susbription Transport where=0A=
the following: 1. Can Transport Session be initiated in both direction. RFC=
=0A=
8071 provides a solution for Publisher to Receiver initiation. It is unclea=
r if all=0A=
parts are in place to have a receiver to publisher initiated transport to b=
e bound=0A=
to the subscription. =0A=

=0A=
This will be up to a specific transport draft to make this determination.  =
=0A=
=0A=
To see what might be viable for NETCONF, check out the earlier version of t=
he document at:=0A=
https://datatracker.ie=
tf.org/doc/draft-ietf-netconf-netconf-event-notifications/10/ =0A=
=0A=
This was seen as a complete version of such a solution.  However the WG wan=
ted a YANG model for session parameters discussed in Section 5.2.=0A=
=0A=

2. What is "name" really? =
It appears to be defined as an=0A=
empty container. Despite that it appears to have requirements on being both=
 a=0A=
security identity as well as network address. =0A=

=0A=
You are correct.  In previous versions of this draft, a receiver was identi=
fied by the combination of address + port.  However due to the YANG doc=
tor reviews, and call home discussions referenced above, the WG wasn't read=
y to finalize this YANG structure.  The compromise was the current structur=
e, plus the example YANG model of Appendix A to show how this might be buil=
t out.=0A=
=0A=

3. In Figure 9, which is stated to b=
e=0A=
for the receiver. What information does the receiver use to determine the=
=0A=
transition (d)? And what does it do in this step. Related to Discuss part B=
). =0A=

=0A=
This determination is implementation specific.=0A=
=0A=

4. RFC=0A=
8071 appears to lack any considerations for how often and how many times it=
=0A=
attempts to connect to the receiver. So applying that mechanism appears to=
=0A=
require some usage guidance to avoid causing overload situations or DoS=0A=
potential by misconfiguring network devices with this soltution to dial out=
=0A=
frequently to a target.=0A=
=0A=
As the transport solution requirements are not detail it is actually hard t=
o=0A=
determine if there are short comings in the description in Section 2.5 and =
the=0A=
corresponding YANG model. Is it an reasonable request to document these=0A=
requirements?=0A=

=0A=
The requirements were documented for both NETCONF and RESTCONF.   However t=
hese requirements were removed when the WG decided to wait until there was =
a YANG model for RFC-8071 ready to go to the IESG.   For a preview on what =
these requirements might look like, I refer you  to Section 5.2 of =0A=
https://datatracker.ie=
tf.org/doc/draft-ietf-netconf-netconf-event-notifications/10/=0A=

Thanks, so this is clearly something to have in mind when the WG do get = to specify a solution for this. So I don't see a need for any actions here. 

=0A=
=0A=

------------------------------------=
----------------------------------=0A=
COMMENT:=0A=
----------------------------------------------------------------------=0A=
=0A=
1. Section 2.3: DSCP domains=0A=
I think the text could benefit from pointing out that the subscriber actual=
ly needs=0A=
to know what the DSCP values represents in the diffserv domain of the publi=
sher.=0A=
As these could be different, they also create an interesting problems for=
=0A=
transports of how they establish a transport connection that uses a particu=
lar=0A=
DSCP, as the receiver if initiating need to know the local DSCP value that=
=0A=
corresponds to the behavior in the publisher's domain.=0A=

=0A=
This makes sense.  =0A=
=0A=
I have added in Section 5.3 Transport Requirements a new entry which states=
:=0A=
=0A=
"A subscriber which includes a "dscp" leaf within an "e=
stablish-subscription" request will need to understand and consider wh=
at the corresponding DSCP value represents within the domain of the publish=
er."=0A=
=0A=
Let me know if this is not sufficient.=0A=
=0A=

2. In general I think there are more=
 than one description that are fuzzy about if it=0A=
describes a publisher or receiver action/requirement.=0A=

=0A=
It would be great if you have some specifics.   The authors and previous re=
viewers likely have looked at this often enough where things look obvious w=
hich perhaps are not.

Sorry, didn't take note about those confusion.

Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522DA9FB3E9C9F0FB25597E95310HE1PR0701MB2522_--


From nobody Tue May  7 06:34:26 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DE12012C for ; Tue,  7 May 2019 06:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWW5-7XLmz6E for ; Tue,  7 May 2019 06:34:23 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8059120026 for ; Tue,  7 May 2019 06:34:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4944; q=dns/txt; s=iport; t=1557236062; x=1558445662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DiVn1rqyuzZ3J6PLkmCkDO+zXDX57Zafa0Ozijo9F6U=; b=MZCwfvEdjQU6wYkirVEKB4Du6xaB6lJI7SwBd59CITMUZ2tIaydWQcNP k/jl401+DjZfn/yGVWLSr5tu3g+P651XO8su6GcuvH2xmWG6K2yee9CLc Rxa/sn72kDh/W3Cu3OQuGJZ29Q4dPLeq6//EXekI3yiCTEWK+fYOyQR35 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACTiNFc/40NJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCEIFtKAqMIo0ImFKBew4BAYRtAoIWIzQJDgE?= =?us-ascii?q?DAQEEAQECAQJtKIVKAQEBAQMnEz8MBAIBCA4DAQMBAQEeEDIXBggCBA4FCBO?= =?us-ascii?q?FEq5zM4oygTIBigqBJh0XgUA/gRGDEj6EAIYmBKdBCQKCCZJEI4IQk0aDcIl?= =?us-ascii?q?Sk1QCERWBMB84gVZwFYMnkFABQTGPaiuBBIEhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,441,1549929600"; d="scan'208";a="272613362"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2019 13:34:21 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x47DYLMN005273 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 May 2019 13:34:21 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 May 2019 08:34:20 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 7 May 2019 08:34:20 -0500
From: "Rob Wilton (rwilton)" 
To: Martin Bjorklund 
CC: "kent+ietf@watsen.net" , "netconf@ietf.org" 
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAL4+PiAAAVM54ADt02zAAAGzCgAAAQfJ4AABQvugADqhRSAAAgkE4AAKD/bgAABK6oAAAGYSwAABxXrgAA8jwUAAA4ykpAAOGfLgAAGk8WgAAOK8oAACbL7AAAASZ0AALNATcAADWJ/AAAITk0A
Date: Tue, 7 May 2019 13:34:20 +0000
Message-ID: <637d22b885a94bf4bd6c4bb53904dac9@XCH-RCD-007.cisco.com>
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com>  <20190507.141926.1879619200930898148.mbj@tail-f.com>
In-Reply-To: <20190507.141926.1879619200930898148.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: 
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 13:34:25 -0000

> -----Original Message-----
> From: Martin Bjorklund 
> Sent: 07 May 2019 13:19
> To: Rob Wilton (rwilton) 
> Cc: kent+ietf@watsen.net; netconf@ietf.org
> Subject: Re: [netconf] ietf crypto types - permanently hidden
>=20
> "Rob Wilton (rwilton)"  wrote:
> > Hi Kent,
> >
> > The problem that I have with  generating configuration
> > directly in  is that  on the device is now different
> > from what the management system thinks should be in  on the
> > device.
> >
> > I.e. it breaks the architectural simplicity that it is only the client
> > that controls what goes into in , e.g. perhaps that can be
> > summarized by this flow:
> >
> > "Update client's desired    ->   "Push to
> > config"                         "
> >           ^                        |
> >           |                        \/
> > "Client notified of         <-   "Apply config,
> > changes in "        updated"
> >
> >
> > However, I would not be opposed to allowing  create
> > configuration that is persisted separately from  and injected
> > into  (e.g. merged with )
>=20
> But this isn't really allowed by the architecture in 8342, imo.  If this
> would have been the case, we'd have another box with config going into
> "intended".  8342 allows "configuration transformations" between running
> and intended.

I'm not sure.  The definition of a configuration transformation is quite br=
oad:
   o  configuration transformation: The addition, modification, or
      removal of configuration between the  and 
      datastores.  Examples of configuration transformations include the
      removal of inactive configuration and the configuration produced
      through the expansion of templates.

In the NMDA discussions, we considered the idea of a template on the device=
 that injects configuration into intended, and this case doesn't seem miles=
 away from there.

However, I'm not sure that now is the right time for a discussion for what =
transformations between  and  are allowed.  If we can ag=
ree on a solution that doesn't require it, and doesn't update , th=
en I would probably be OK with that as well.

>=20
> > , hence allowing leaf-refs
> > in config validation to work as expected.  I think that this would
> > allow device reboot to work as expected.
> >
> > If the clients would like to see the keys in the configuration then
> > they can monitor  (or ), and then add the keys,
> > either in raw form, or encrypted in some way.  But I still think that
> > it is architecturally cleaner if it is always the client that updates
> > the  configuration and never the device.
>=20
> I agree.  I think it would be worthwile to explore the "non-action-based"
> solution that Rob proposed.  Is there anything in that solution that
> doesn't work?
>=20
>=20
> /martin

Thanks,
Rob

>=20
>=20
>=20
> >
> > Thanks,
> > Rob
> >
> >
> >
> > From: netconf  On Behalf Of Kent Watsen
> > Sent: 03 May 2019 17:24
> > To: netconf@ietf.org
> > Subject: Re: [netconf] ietf crypto types - permanently hidden
> >
> > I had an idea last night that might inch us closer to a solution.
> >
> > Essentially, the generate/install-key operations always populate
> > , even for keys that are not-hidden, but then a follow-up
> > operation (something like ) replicates the not-hidden key
> > in  to .  Two options:
> >
> > 1) A regular-access admin executes the actions to generate the key,
> > get a CSR, configure a resulting signed certificate, etc. and then, as
> > a second step later in time, a special-access admin replicates the key
> > to  (perhaps using standard  and ),
> > so that it can be included in a standard backup and restored to *any*
> > device (since this key is "not-hidden", it isn't encrypted with a
> > device-specific key and hence can be migrated).
> >
> > 2) A regular-access admin executes the actions to generate the key,
> > get a CSR, configure a resulting signed certificate, etc. and then, as
> > a second step (ideally immediately after), the regular-access admin
> > executes a command like , but rather than copying the
> > entire datastore, it just copies a subtree.
> >
> > Neither option seems great.  #1 is unappealing being it necessitates
> > coordination between clients.  #2 is unappealing because defining a
> > generic operation for this special case seems too much.
> >
> > IMO, allowing  to create the configuration directly is
> > the only client-friendly answer.
> >
> >
> > Kent // contributor
> >


From nobody Tue May  7 12:22:37 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D556E120144; Tue,  7 May 2019 12:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZH5n7HkTIEA; Tue,  7 May 2019 12:22:31 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B860F120192; Tue,  7 May 2019 12:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76445; q=dns/txt; s=iport; t=1557256950; x=1558466550; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m9IriHOlSeY4zakxHyGrg7GhlZa/qEQjeOMnWhm6lR4=; b=aVK7QHoyvktfdD3tCXlyUfJhz51bUrKPKq2RQnC9CmGhgORNv/EV3LPT 9WmBSvpGLQb8lVCHEGlBQ3UyERwcVLhULANa3SnkYA0hpUsDfdsNQxpVo ScJbZ70/bSw5Iu9LNsFPGblqjI1mDo0dRzPotXVVL5n+KI7QMD6Mvnja0 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADG2dFc/5JdJa1bAgcaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFRBQEBAQELAYEOUwUqaU03KAqMIo0IfpdUFIFnDgEBJYR?= =?us-ascii?q?IAoIWIzQJDgEDAQEEAQECAQJtHAyFSgEBAQQMDgESPwYFAg4CAgEIEgMQEwE?= =?us-ascii?q?CBAcbFxQDDgIEAQ0FCBOCPEyBHW0PrzQfhCdBhSIGBYEtAYoigSsXgUA/gRG?= =?us-ascii?q?CFEk1PoJhAgECAYEqAQgKAQcFGTCFLASKdyABAy+GWSCHaYwxZQkCggmGHYN?= =?us-ascii?q?wQoNjgXCCJSOCEIZEg2+FOoNajCSGTYoahA8CERWBMB84NTBYEQhwFYJzATO?= =?us-ascii?q?CGxcUbQEDBAeHUIU+AUExAY8GDxcDAYEHgSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,443,1549929600";  d="scan'208,217";a="559456421"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2019 19:22:26 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x47JMQlB008248 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 May 2019 19:22:26 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 May 2019 15:22:25 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 7 May 2019 15:22:25 -0400
From: "Eric Voit (evoit)" 
To: Magnus Westerlund , The IESG 
CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
Thread-Index: AQHVAOILPUp24ohD6UOwYws4qyBRVKZf4yrw
Date: Tue, 7 May 2019 19:22:25 +0000
Message-ID: <4ac32da8a1544e26b9671f6f5e2bdf84@XCH-RTP-013.cisco.com>
References: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> <7efee2607c62458d865ce663f9d4fc27@XCH-RTP-013.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.233]
Content-Type: multipart/alternative; boundary="_000_4ac32da8a1544e26b9671f6f5e2bdf84XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 19:22:36 -0000

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

Hi Magnus,

Thanks again for your thorough review on the overload aspect.   It is appre=
ciated.  Some thoughts/proposals back to you in-line..

From: Magnus Westerlund, May 7, 2019 8:50 AM

Hi Eric,

Thanks for the answers. I think we are making progress here, see below.

What I see is that there need to be some text changes in the QoS parts.

Regarding the priority I get the impression that it is not the WG's intenti=
on to clarify this. However, I would wish that the document is a bit more e=
xplicit about the lack of any interface to affect the publisher's action wh=
en it comes to dropping subscriptions. Yes there is this paragraph in Secti=
on 1.3:

   A publisher MAY terminate a dynamic subscription at any time.

   Similarly, it MAY decide to temporarily suspend the sending of

   notification messages for any dynamic subscription, or for one or

   more receivers of a configured subscription.  Such termination or

   suspension is driven by internal considerations of the publisher.



So I guess I have to drop this aspect now when the explicit reference to pr=
iority based actions are removed.



  I agree it would be great to have a structure of subscription handl=
ing precedence on the publisher.  However there are not any solutions that =
I know of being discussed today.   Building a model here would be hard, and=
 would likely take quite a bit of time/effort.  It is primarily the time co=
st which is the biggest consideration at this point.  Since NETCONF got sta=
rted on these subscription specifications, Google's GNMI alternative has be=
en introduced.    GNMI has fewer overload controls, yet has gained industry=
 traction.    Based on this, it doesn't seem like standardized handling of =
subscription precedence on a publisher is a market necessity yet.



On 2019-05-06 23:19, Eric Voit (evoit) wrote:

Hi Magnus,



Thanks very much for your comments.   Thoughts in-line...



From: Magnus Westerlund, May 2, 2019 8:25 AM



Magnus Westerlund has entered the following ballot position for

draft-ietf-netconf-subscribed-notifications-25: Discuss



When responding, please keep the subject line intact and reply to all email

addresses included in the To and CC lines. (Feel free to cut this introduct=
ory

paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification=
s/







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

DISCUSS:

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



My focus when reviewing this document was from a perspective of how to

handle overload.



You are absolutely correct to focus on overload.  Mitigating different dime=
nsions of the overload risk has been a design goal since this effort's ince=
ption.  And this is the reason a variety of QoS mechanisms were included in=
 the document.



I have a hard time understanding how this will actually work,

especially in a fashion that preservers goodput and ensure what is consider=
ed

the most important subscriptions are delivered. Not having good undertandin=
g

into netconf and restconf don't hesitate to call out likely missunderstandi=
ng by

me and provide clarification and pointers.



Few of the mechanisms are specific to either RESTCONF or NETCONF.  For comp=
leteness reasons, let me summarize the overload mechanisms available...



1. The publisher is allowed to decline a dynamic subscription.  One of thes=
e reasons is that the incremental traffic generated by a particular increme=
ntal subscription will be too high.  There are errors back to the subscribe=
r indicating this condition exist.

2. A publisher can suspend any subscription for capacity reasons, and a rec=
eiver must be able to gracefully accept this suspension.

3. Much like with HTTP2 streams, higher priority subscriptions intended for=
 a particular receiver can be dequeued first from a publisher.

4. Much like with HTTP2 streams, proportional subscription dequeuing intend=
ed for a particular receiver can be performed a publisher.

5. DSCP markings can be placed on subscribed data.

6. Mechanisms for detecting and reacting to different types of subscribed d=
ata loss have been embedded.

7. Methods have been included to ensure a configured receiver "ok's" inform=
ation push before subscribed data is sent. (This should reduce one DDoS vec=
tor.)

8. Keep alive mechanisms are established for different transport types, so =
that subscribed data isn't being sent when the is no receiver listening.



Mechanisms (3) & (4) will likely be seen only with HTTP2 based transports.*=
   This is because (as documented within draft-ietf-netconf-restconf-notif =
section 4), these capabilities are to integrated directly HTTP2 RFC-7450 se=
ctions 5.3.1 & 5.3.2.

To me the big weakness of this mechanism are actually in the API between th=
e receiver and the publisher. The current API defined by this document does=
 not include any information that allow the receiver to express its actual =
view on priority for a subscription. It has some other tools that has compl=
etely different meanings namely:

- Transport level DSCP expressing PHB and routing priority

- Weight: Proportional bandwidth distribution

- Dependency: Deliver this only after this other subscription

None of this expresses anything related to the priority or importance to ma=
intain a particular subscription, nor does the interface carry any informat=
ion regarding what delivery requirements the receiver have on the subscript=
ion. Thus, the behavior in overload situation is going to be totally random=
.

So if the WG is okay with this being the case I will hold my nose. However,=
 I think the fact that random implementation dependent things will happen i=
n overload should be explicitly stated in the document.

 I think the documents reflect the state-of-the-art across industry p=
layers.  Attempting to layer-in something new which hasn't been considered =
would be non-trivial.  But your intent should not be lost.  So to reflect y=
our request above, how about I add the following statement at the very end =
of Section 2.3 QoS:

There are additional types over publisher capacity overload which this spec=
ification does not address within its scope. For example, the prioritizatio=
n of which subscriptions have precedence when the publisher CPU is overload=
ed is not discussed.  As a result, implementation choices will need to be m=
ade to address such considerations.

Does this work for you?





* One background/review note...  Earlier versions of draft-ietf-netconf-sub=
scribed-notifications included specific parallels to RFC-7450 when describi=
ng (3) & (4).  However WG members wanted to abstract away what they felt we=
re HTTP2 specific references. This is despite the fact that what was being =
referenced was the desired functional behavior rather than anything HTTP2 s=
pecific.   I can understand the WG reviewers' concern.  This is already a l=
ong document, and a reader who only cares about NETCONF hopefully won't nee=
d to wade through complex issues which they are unlikely to worry about in =
deployment.

I did a brief look at the transports. They did not answer my questions when=
 I wrote this discuss. Also, to my understanding the HTTP/2 priority mechan=
ism is that is far from easy to use and also intended to distribute resourc=
es in an ongoing transmission. That doesn't actually match the higher level=
 need of determining which subscription are more important than another. Do=
esn't a 5 level priority value cover a lot of the missing ground here?

 Agree that the HTTP2 QoS mechanisms described do not address anythin=
g other than handling dequeuing congestion between a publisher and a receiv=
er as part of an ongoing transmission.  This actually is very relevant prob=
lem.  Early implementations of telemetry for SDN have many network element =
publishers pushing data to a few central data collectors.

Beyond this, I don't think the working group has ever considered a multi-le=
vel subscription priority mechanism.  I believe the problem to be a very ha=
rd one, even if there are just 5 levels (or two levels).

A) The QoS and priority sending mechanism discussed in 2.3 and furhter defi=
ned

by the YANG model.



I do want to raise the usage of the DSCP code point to a discuss. As the DS=
CP

defines different PHB and relative priorities in the router queues a DSCP v=
alue

does not provide the publisher any information about priority. I get the fe=
eling

from the text that this may be intended. If the only intention is to have t=
he

transport perform differential treatment in the network between the publish=
er

and the receiver



Yes, this is the case.



there are still more considerations are needed.

First of all I think these sentence needs a total rewrite:



   If the publisher supports the "dscp" feature, then a subscription

   with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP

   marking being placed within the IP header of any resulting

   notification messages and subscription state change notifications.

   Where TCP is used, a publisher which supports the "dscp" feature

   SHOULD ensure that a subscription's notification messages are

   returned within a single TCP transport session where all traffic

   shares the subscription's "dscp" leaf value.



I think one need to put a requriement on the transport to use a transport t=
hat

utilize the DSCP marking on its traffic.



I believe you are asking for a  the publisher respect the DSCP markings for=
 traffic egressing an interface on a publisher.  Yes this requirement was a=
ssumed, and can be explicitly added.

Please do.

 Section 2.3 QoS now says..

A publisher MUST respect the DSCP markings for subscription traffic egressi=
ng that publisher.





Which for the current set of connection

oriented transport protocols, TCP, SCTP, and QUIC all currently only suppor=
t

using a single DSCP per connection. Implying multiple transport protocol

connections using a particular transport to enable this mapping.



Yes fully agree, a connection would be needed per DSCP.     Is your objecti=
on with the text above the words "SHOULD ensure" rather than "MUST ensure"?=
    If yes, I can ask the WG objects to whether this requirement should be =
a MUST.



If you think you should use RFC 2119 language, yes then I request a MUST.  =
However, I think reformulating this so state it as a fact that different DS=
CP code points requires different transport connections, unless a transport=
 supporting multiple DSCP simultanous are used (No standardized option that=
 has reliable object or stream semantics exist to my knowledge).

  Adding a statement of fact here is not an issue.  And thinking abou=
t your comment regarding RFC2119 language, I don't think RFC2119 language i=
s needed here.  So I have turned the "SHOULD" into "must".   This results i=
n the following proposed text:

Different DSCP code points require different transport connections.  As a r=
esult where TCP is used, a publisher which supports the "dscp" feature must=
 ensure that a subscription's notification messages are returned within a s=
ingle TCP transport session where all traffic shares the subscription's "ds=
cp" leaf value.

Does this work for you?

Where TCP is used, a publisher which supports the "dscp" feature must ensur=
e that a subscription's notification messages are returned within a single =
TCP transport session where all traffic shares the subscription's "dscp" le=
af value.



A.2 Queuing model of a publisher.

With the DSCP and the Weight and dependency model I think it is important t=
o

clarify the model of the queueing in the publisher. So is the intention tha=
t several

subscriptions with different weights and possibly dependencies have their

individual queues that goes into a scheduler?



As you know, queuing models are non-trivial.   For that reason we wanted to=
 100% adopt the functional behavior RFC-7540 Section 5.3.1 and 5.3.2 withou=
t having to re-document/mirror that content at a higher level of the networ=
k stack.   We are a hoping that a reader of network subscriptions can look =
to well documented, implemented HTTP2 behaviors as applicable.  Providing a=
n intermediate layer of functional description could easily result in some =
mis-alignments from what is intended.

Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540 is=
 all within a single TCP connection. Thus, to avoid complexities I think yo=
u at least need to be explicit that one can only perform Dependency and Wei=
ght operations between subscriptions that share DSCP, and that they become =
independent queues.

 To cover this, are you ok with adding as a last sentence of Section =
2.3:

"Dependency" and "weight" parameters will only be respected and enforced be=
tween subscriptions that share the same "dscp" leaf value.

To avoid complex queue

interactions on this level I think there need to be seperate scheduler inst=
ances

per DSCP. I would also note that Dependency mechanism can't ensure that a

dependent stream arrive at receiver after the identified dependency if they=
 are

on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not

even guarantee it within a single connection and same DSCP due to packet lo=
ss

impact. To me this model and what relationship one need to consider here ne=
ed

to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication =
of just the

importance of considering what is in the same dependency tree and what it

means to have different weighting. To conclude I think this needs a model

description and clearer definition and possibly requirements towards the

transport. Espceially if you actually need an in-order delivery requirement=
?



I think we have the same technical objective in mind.   And it is absolutel=
y the desire to have identical behavior to RFC-7540 Section 5.3.1 and 5.3.2=
.    For the current set of documents before the IESG, we include within dr=
aft-ietf-netconf-restconf-notif Section 4, a 1:1 mapping between draft-ietf=
-netconf-subscribed-notifications and RFC-7540.



We are hoping that the transport documents like draft-ietf-netconf-restconf=
-notif can be the place where such supporting documentation and mappings oc=
cur.

I still think that this document needs to have that sentence in their stati=
ng that Dependency and Weight applies only per subscription sharing DSCP va=
lue. Because these values are define on this document level, not on the map=
ping level that the individual transport exists on. And this is the interfa=
ce the WG have defined for this. And as it currently stands you appear to h=
ave something that lacks a clear meaning.

 Hopefully the last suggested text covers this.



B. The unpredictability of the circuit breaker overload mechanism.



My description of the overload handling in this document is that it is a ci=
rcuit

breaker based mechanism that can blow a fuse on subscriptions that it fails=
 to

honor in overload situations. What worries me deply is the total unpredicta=
bility

of this mechanism.



At the beginning of this email, there are eight methods of overflow handlin=
g listed.  We optimized these eight mechanisms for different failure scenar=
ios and congestion conditions.   Our goal was to depend on existing mechani=
sms/technologies wherever possible.  Reuse of existing mechanisms should re=
duce at least some of the unpredictability.



First, is it the intention to derive what subscriptions are least important=
 from the

DSCP, weighting and Dependency parameters? If it is, I think that may be a

misstake as priority on what subscriptions are most important to retain are=
 not

necessarily reflected in their QoS parameters.



At this point the document does not attempt to define "important".  All tha=
t is done is to provide guidance relating to some elements of network trans=
port.   If there is a dimension of "importance" which an implementer would =
like to layer onto this solution, it could be done.  For example, "importan=
ce" could applied in areas such as what subscriptions should be suspended  =
in case of CPU exhaust.   However guidance on such enhancements are not inc=
luded in this document.

Still it is both implied and explicitly stated in one place.

 Hopefully the changes suggested above cover this concern.



Secondly, what are the values when a subscription are considered to be to h=
eavy

or not be handled accordingly. Are there any parameter sets that actually

describe what SLA the subscriber expect that can be converted into timeout

timers or buffer depth thresholds to indicate that publisher side isn't del=
ivering

these in time?



There is no guidance on this provided in the document.   As equipment types=
, subscription volumes, available memory, will vary between solutions, this=
 will take a while to dimension properly.  I can imagine someday that we mi=
ght have something like "Erlang for subscriptions" much like we used Erlang=
s in the old telephony network to dimension call handling capabilities of p=
hone switches.  But we are a long way from that.

To be clear what I mean with SLA here is to express some boundaries on when=
 the subscribed to information will be received by the receiver compared to=
 when it come to existence on the publisher side. However, I do hear you th=
at there is nothing defined and nothing in the pipeline.

 Understood.  We simply don't have anything.





Third, I what I understand there are no any additional back pressure mechan=
ism

between the receiver and the publisher than the transport protocols flow

control? So a receiver that is not keeping up processing the data it proces=
s will

not read out the data out of the flow controlled buffers in the receiver an=
d thus

prevent the publisher to write to the transport conncetion, thus causing th=
e

publisher to eventually trigger a suspension due to its queue build up?



There is nothing beyond transport flow control.  We thought about it initia=
lly, but we were not ready to pick up even more complexity than we already =
had.

Ok, which just contribute to what I call random things happen at overload.

 agree





To my understanding the current mechanism places all subscriptions on the

same importance and with the same SLA. Thus likely causing short term overl=
oad

situations to cause subscription suspensions in random subscriptions. Is th=
e WG

fine with this type of randomness occuring and expecting that normally ther=
e

will be such amount of overprovisioning that being able to indicate priorit=
y and

SLA are overkill?



Yes.   We needed a starting point.  And there are technical solutions which=
 can be layered on top.   But what we have now took many years to finalize,=
 and should be a big enough technical jump considering our current knowledg=
e.



At a minimal a change of this sentence in Section 2.5.1 is needed:



  This could

   be for reasons of an unexpected but sustained increase in an event

   stream's event records, degraded CPU capacity, a more complex

   referenced filter, or other higher priority subscriptions which have

   usurped resources.



I have removed "higher priority".

Thanks.





As it states that subscriptions has priorities without reference to a mecha=
nism

that provides that priority.



C. 2.4.5.  Killing a Dynamic Subscription



   The "kill-subscription" operation permits an operator to end a

   dynamic subscription which is not associated with the transport

   session used for the RPC.  A publisher MUST terminate any dynamic

   subscription identified by the "id" parameter in the RPC request, if

   such a subscription exists.



Can someone please clarify the use case for this functionality. To my

understanding it allows another receiver given authority to kill the subscr=
iption

being delivered to another receiver. Based on the otherwise rather strict t=
hat all

manipulations of dynamic subscriptions happens from the transport session

context that established it I want to better understand the use case it app=
ears

out place.



A network operator needs a very secure mechanism to end a dynamic subscript=
ion in progress which it sees as harmful.   The operator cannot do this via=
 configuration operations, as the dynamic subscription is not configured (a=
nd therefore cannot be deleted in the configuration datastore).

Thanks, that clarification resolves my question mark. So lets close this is=
sue without any actions.





D. The Requirements on a transport supporting Configured Subscriptions

Reading through Section 2.5 I arrived at a number of questions. I tried to

understand what the requirements are for the transport that supports

Configured Subscriptions. I did note that neither draft-ietf-netconf-restco=
nf-

notif-13 nor

draft-ietf-netconf-netconf-event-notifications-17 supports configured

subscriptions. Thus, there appear no template for a solution either, or doe=
s

there exist another document that is being worked on defining such a transp=
ort?



This is the case.   Originally both of those documents *did* include config=
ured subscriptions.  However within the WG there was a decision not to prog=
ress configured subscriptions yet.  One reason is that other YANG model dra=
fts moving in the NETCONF WG were seen as pre-requisites for securely creat=
ing transport sessions via call home for the configured subscriptions.  As =
a result, support for configured subscriptions was extracted from those tra=
nsport documents.   It is expected that that updated versions of just those=
 transport documents will be driven when the YANG models complete.

Look at the responses below I see that we are in one of these situation whe=
re things are deliberately left open. I will simply assume that this is don=
e in a way that supports those future definitions and clarifications. So le=
ts close this issue without any actions.



Questions that arose for me related to Configured Susbription Transport whe=
re

the following: 1. Can Transport Session be initiated in both direction. RFC

8071 provides a solution for Publisher to Receiver initiation. It is unclea=
r if all

parts are in place to have a receiver to publisher initiated transport to b=
e bound

to the subscription.



This will be up to a specific transport draft to make this determination.



To see what might be viable for NETCONF, check out the earlier version of t=
he document at:

https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notificat=
ions/10/



This was seen as a complete version of such a solution.  However the WG wan=
ted a YANG model for session parameters discussed in Section 5.2.



2. What is "name" really? It appears to be defined as an

empty container. Despite that it appears to have requirements on being both=
 a

security identity as well as network address.



You are correct.  In previous versions of this draft, a receiver was identi=
fied by the combination of address + port.  However due to the YANG doctor =
reviews, and call home discussions referenced above, the WG wasn't ready to=
 finalize this YANG structure.  The compromise was the current structure, p=
lus the example YANG model of Appendix A to show how this might be built ou=
t.



3. In Figure 9, which is stated to be

for the receiver. What information does the receiver use to determine the

transition (d)? And what does it do in this step. Related to Discuss part B=
).



This determination is implementation specific.



4. RFC

8071 appears to lack any considerations for how often and how many times it

attempts to connect to the receiver. So applying that mechanism appears to

require some usage guidance to avoid causing overload situations or DoS

potential by misconfiguring network devices with this soltution to dial out

frequently to a target.



As the transport solution requirements are not detail it is actually hard t=
o

determine if there are short comings in the description in Section 2.5 and =
the

corresponding YANG model. Is it an reasonable request to document these

requirements?



The requirements were documented for both NETCONF and RESTCONF.   However t=
hese requirements were removed when the WG decided to wait until there was =
a YANG model for RFC-8071 ready to go to the IESG.   For a preview on what =
these requirements might look like, I refer you  to Section 5.2 of

https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notificat=
ions/10/

Thanks, so this is clearly something to have in mind when the WG do get to =
specify a solution for this. So I don't see a need for any actions here.





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

COMMENT:

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



1. Section 2.3: DSCP domains

I think the text could benefit from pointing out that the subscriber actual=
ly needs

to know what the DSCP values represents in the diffserv domain of the publi=
sher.

As these could be different, they also create an interesting problems for

transports of how they establish a transport connection that uses a particu=
lar

DSCP, as the receiver if initiating need to know the local DSCP value that

corresponds to the behavior in the publisher's domain.



This makes sense.



I have added in Section 5.3 Transport Requirements a new entry which states=
:



"A subscriber which includes a "dscp" leaf within an "establish-subscriptio=
n" request will need to understand and consider what the corresponding DSCP=
 value represents within the domain of the publisher."



Let me know if this is not sufficient.



2. In general I think there are more than one description that are fuzzy ab=
out if it

describes a publisher or receiver action/requirement.



It would be great if you have some specifics.   The authors and previous re=
viewers likely have looked at this often enough where things look obvious w=
hich perhaps are not.

Sorry, didn't take note about those confusion.

 Magnus, once again your comments are thoughtful and appreciated.  Th=
anks for taking such a good look at this document.

Eric



Cheers



Magnus Westerlund



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

Network Architecture & Protocols, Ericsson Research

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

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

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

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











Hi Magnus,


 


Thanks again for your thorough review on the overload aspect.&nb=
sp;  It is appreciated.  Some thoughts/proposals
 back to you in-line..


 




From:=
 Magnus Westerlund, May 7, 2019 8:50 AM







Hi Eric,






 






Thanks for the answers. I think we are making progre=
ss here, see below.







 






What I see is that there need to be some text change=
s in the QoS parts.







 






Regarding the priority I get the impression that it =
is not the WG's intention to clarify this. However, I would wish that the d=
ocument is a bit more explicit about the lack of any interface to affect th=
e publisher's action when it comes
 to dropping subscriptions. Yes there is this paragraph in Section 1.3: 






   A publisher MAY terminate a dynamic subscription at =
any time.


   Similarly, it MAY decide to temporarily suspend the sendi=
ng of


   notification messages for any dynamic subscription, or fo=
r one or


   more receivers of a configured subscription.  Such t=
ermination or


   suspension is driven by internal considerations of the pu=
blisher.


 


So I guess I have to drop this aspect now when the explicit reference =
to priority based actions are removed.


 


<eric>  I a=
gree it would be great to have a structure of subscription handling precede=
nce on the publisher.  However there are not any solutions that I know=
 of being discussed today.   Building a model here would be hard,=
 and would likely take quite a bit of time/effort.  It is primarily th=
e time cost which is the biggest consideration at this point.  Since N=
ETCONF got started on these subscription specifications, Google’s GNM=
I alternative has been introduced.    GNMI has fewer overloa=
d controls, yet has gained industry traction.    Based on th=
is, it doesn’t seem like standardized handling of subscription preced=
ence on a publisher is a market necessity yet.

 






 






On 2019-05-06 23:19, Eric Voit (evoit) wrote:






Hi Magnus,


 


Thanks very much for your comments.   Thoughts in-line...


 




From: Magnus Westerlund, May 2, 2019 8:25 AM


 


Magnus Westerlund has entered the following ballot position for


draft-ietf-netconf-subscribed-notifications-25: Discuss

 


When responding, please keep the subject line intact and reply to all =
email


addresses included in the To and CC lines. (Feel free to cut this intr=
oductory


paragraph, however.)


 


 


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html


for more information about IESG DISCUSS and COMMENT positions.


 


 


The document, along with other ballot positions, can be found here:


https://datatracker.ietf.org/doc/draft-ietf-netconf-sub=
scribed-notifications/


 


 


 


----------------------------------------------------------------------=



DISCUSS:


----------------------------------------------------------------------=



 


My focus when reviewing this document was from a perspective of how to=



handle overload. 




 


You are absolutely correct to focus on overload.  Mitigating diff=
erent dimensions of the overload risk has been a design goal since this eff=
ort’s inception.  And this is the reason a variety of QoS mechan=
isms were included in the document.


 




I have a hard time understanding how this will actually work,


especially in a fashion that preservers goodput and ensure what is con=
sidered


the most important subscriptions are delivered. Not having good undert=
anding


into netconf and restconf don't hesitate to call out likely missunders=
tanding by


me and provide clarification and pointers.




 


Few of the mechanisms are specific to either RESTCONF or NETCONF. =
; For completeness reasons, let me summarize the overload mechanisms availa=
ble...


 


1. The publisher is allowed to decline a dynamic subscription.  O=
ne of these reasons is that the incremental traffic generated by a particul=
ar incremental subscription will be too high.  There are errors back t=
o the subscriber indicating this condition exist.


2. A publisher can suspend any subscription for capacity reasons, and =
a receiver must be able to gracefully accept this suspension. 

3. Much like with HTTP2 streams, higher priority subscriptions intende=
d for a particular receiver can be dequeued first from a publisher. 


4. Much like with HTTP2 streams, proportional subscription dequeuing i=
ntended for a particular receiver can be performed a publisher.<=
/pre>

5. DSCP markings can be placed on subscribed data.


6. Mechanisms for detecting and reacting to different types of subscri=
bed data loss have been embedded.


7. Methods have been included to ensure a configured receiver “o=
k’s” information push before subscribed data is sent. (This sho=
uld reduce one DDoS vector.) 


8. Keep alive mechanisms are established for different transport types=
, so that subscribed data isn’t being sent when the is no receiver li=
stening.


 


Mechanisms (3) & (4) will likely be seen only with HTTP2 based tra=
nsports.*   This is because (as documented within draft-ietf-netc=
onf-restconf-notif section 4), these capabilities are to integrated directl=
y HTTP2 RFC-7450 sections 5.3.1 & 5.3.2.   




To me the big weakness of this mechanism are actually in the API between=
 the receiver and the publisher. The current API defined by this document d=
oes not include any information that allow the receiver to express its actu=
al view on priority for a subscription.
 It has some other tools that has completely different meanings namely:


- Transport level DSCP expressing PHB and routing priority

- Weight: Proportional bandwidth distribution


- Dependency: Deliver this only after this other subscription=



None of this expresses anything related to the priority or importance to=
 maintain a particular subscription, nor does the interface carry any infor=
mation regarding what delivery requirements the receiver have on the subscr=
iption. Thus, the behavior in overload
 situation is going to be totally random. 


So if the WG is okay with this being the case I will hold my nose. Howev=
er, I think the fact that random implementation dependent things will happe=
n in overload should be explicitly stated in the document.



<eric&=
gt; I think the documents reflect the state-of-the-art across industry play=
ers.  Attempting to layer-in something new
 which hasn’t been considered would be non-trivial.  But your =
intent should not be lost.  So to reflect your
 request above, how about I add the following statement at the very end of =
Section 2.3 QoS:


There are additional types over publisher capaci=
ty overload which this specification does not
 address within its scope. For example, the prioritization of which subscri=
ptions have precedence when the publisher CPU is overloaded is not discusse=
d.  As a result, implementation choices will need to be made to addres=
s such considerations.


Does this=
 work for you?




 


 


* One background/review note...  Earlier versions of draft-ietf-n=
etconf-subscribed-notifications included specific parallels to RFC-7450 whe=
n describing (3) & (4).  However WG members wanted to abstract awa=
y what they felt were HTTP2 specific references. This is despite the fact t=
hat what was being referenced was the desired functional behavior rather th=
an anything HTTP2 specific.   I can understand the WG reviewers' =
concern.  This is already a long document, and a reader who only cares=
 about NETCONF hopefully won't need to wade through complex issues which th=
ey are unlikely to worry about in deployment.




I did a brief look at the transports. They did not answer my questions w=
hen I wrote this discuss. Also, to my understanding the HTTP/2 priority mec=
hanism is that is far from easy to use and also intended to distribute reso=
urces in an ongoing transmission.
 That doesn't actually match the higher level need of determining which sub=
scription are more important than another. Doesn't a 5 level priority value=
 cover a lot of the missing ground here?



<eric&=
gt; Agree that the HTTP2 QoS mechanisms described do not address anything o=
ther than handling dequeuing congestion between
 a publisher and a receiver as part of an ongoing transmission.  This =
actually is very relevant problem.  Early implementations of telemetry=
 for SDN have many network element publishers pushing data to a few central=
 data collectors. 



Beyond th=
is, I don’t think the working group has ever considered a multi-level=
 subscription priority mechanism.  I believe
 the problem to be a very hard one, even if there are just 5 levels (or two=
 levels).






A) The QoS and priority sending mechanism discussed in 2.3 and furhter=
 defined


by the YANG model.


 


I do want to raise the usage of the DSCP code point to a discuss. As t=
he DSCP


defines different PHB and relative priorities in the router queues a D=
SCP value


does not provide the publisher any information about priority. I get t=
he feeling


from the text that this may be intended. If the only intention is to h=
ave the


transport perform differential treatment in the network between the pu=
blisher


and the receiver 




 


Yes, this is the case.


 




there are still more considerations are needed.


First of all I think these sentence needs a total rewrite:<=
/pre>

 


   If the publisher supports the "dscp" feature, t=
hen a subscription


   with a "dscp" leaf MUST result in a correspondi=
ng [RFC2474] DSCP


   marking being placed within the IP header of any resultin=
g


   notification messages and subscription state change notif=
ications.


   Where TCP is used, a publisher which supports the "d=
scp" feature


   SHOULD ensure that a subscription's notification messages=
 are


   returned within a single TCP transport session where all =
traffic


   shares the subscription's "dscp" leaf value.


 


I think one need to put a requriement on the transport to use a transp=
ort that


utilize the DSCP marking on its traffic. 




 


I believe you are asking for a  the publisher respect the DSCP ma=
rkings for traffic egressing an interface on a publisher.  Yes this re=
quirement was assumed, and can be explicitly added.




Please do. 


<eric&=
gt; Section 2.3 QoS now says..


A publisher MUST respect the DSCP markings for s=
ubscription traffic egressing that publisher.




 


 




Which for the current set of connection


oriented transport protocols, TCP, SCTP, and QUIC all currently only s=
upport


using a single DSCP per connection. Implying multiple transport protoc=
ol


connections using a particular transport to enable this mapping.<=
/o:p>




 


Yes fully agree, a connection would be needed per DSCP.  &nb=
sp;  Is your objection with the text above the words "SHOULD ensu=
re" rather than "MUST ensure"?    If yes, I c=
an ask the WG objects to whether this requirement should be a MUST.




 


If you think you should use RFC 2119 language, yes then I request a MUST=
. 
However, I think reformulating this so state it as a fact that diffe=
rent DSCP code points requires different transport connections, unless a tr=
ansport supporting multiple DSCP simultanous are used (No standardized opti=
on that has reliable object or stream
 semantics exist to my knowledge). 


<eric&=
gt;  Adding a statement of fact here is not an issue. 
And thinking about your comment regarding RFC2119 language, I don’t=
 think RFC2119 language is needed here.  So
 I have turned the “SHOULD” into “must”.  =
; This results in the following proposed text:=



Different DSCP code points require different tra=
nsport connections.  As a result where TCP is
 used, a publisher which supports the "dscp" feature must ensure =
that a subscription's notification messages are returned within a single TC=
P transport session where all traffic shares the subscription's "dscp&=
quot; leaf value.


Does this=
 work for you?




Where TCP i=
s used, a publisher which supports the "dscp" feature must ensure=
 that a subscription's notification messages are returned within a single T=
CP transport session where all traffic shares the subscription's "dscp=
" leaf value.


 




A.2 Queuing model of a publisher.


With the DSCP and the Weight and dependency model I think it is import=
ant to


clarify the model of the queueing in the publisher. So is the intentio=
n that several


subscriptions with different weights and possibly dependencies have th=
eir


individual queues that goes into a scheduler?




 


As you know, queuing models are non-trivial.   For that reas=
on we wanted to 100% adopt the functional behavior RFC-7540 Section 5.3.1 a=
nd 5.3.2 without having to re-document/mirror that content at a higher leve=
l of the network stack.   We are a hoping that a reader of networ=
k subscriptions can look to well documented, implemented HTTP2 behaviors as=
 applicable.  Providing an intermediate layer of functional descriptio=
n could easily result in some mis-alignments from what is intended.




Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540=
 is all within a single TCP connection. Thus, to avoid complexities I think=
 you at least need to be explicit that one can only perform Dependency and =
Weight operations between subscriptions
 that share DSCP, and that they become independent queues. 


<eric&=
gt; To cover this, are you ok with adding as a last sentence of Section 2.3=
:


“Dependency” and “weight”=
; parameters will only be respected and enforced between subscriptions
 that share the same “dscp” leaf value.






To avoid complex queue


interactions on this level I think there need to be seperate scheduler=
 instances


per DSCP. I would also note that Dependency mechanism can't ensure tha=
t a


dependent stream arrive at receiver after the identified dependency if=
 they are


on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may=
 not


even guarantee it within a single connection and same DSCP due to pack=
et loss


impact. To me this model and what relationship one need to consider he=
re need


to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indica=
tion of just the


importance of considering what is in the same dependency tree and what=
 it


means to have different weighting. To conclude I think this needs a mo=
del


description and clearer definition and possibly requirements towards t=
he


transport. Espceially if you actually need an in-order delivery requir=
ement?




 


I think we have the same technical objective in mind.   And =
it is absolutely the desire to have identical behavior to RFC-7540 Section =
5.3.1 and 5.3.2.    For the current set of documents before =
the IESG, we include within draft-ietf-netconf-restconf-notif Section 4, a =
1:1 mapping between draft-ietf-netconf-subscribed-notifications and RFC-754=
0.    


 


We are hoping that the transport documents like draft-ietf-netconf-res=
tconf-notif can be the place where such supporting documentation and mappin=
gs occur.  




I still think that this document needs to have that sentence in their st=
ating that Dependency and Weight applies only per subscription sharing DSCP=
 value. Because these values are define on this document level, not on the =
mapping level that the individual
 transport exists on. And this is the interface the WG have defined for thi=
s. And as it currently stands you appear to have something that lacks a cle=
ar meaning.



<eric&=
gt; Hopefully the last suggested text covers this.=





 




B. The unpredictability of the circuit breaker overload mechanism.


 


My description of the overload handling in this document is that it is=
 a circuit


breaker based mechanism that can blow a fuse on subscriptions that it =
fails to


honor in overload situations. What worries me deply is the total unpre=
dictability


of this mechanism.




 


At the beginning of this email, there are eight methods of overflow ha=
ndling listed.  We optimized these eight mechanisms for different fail=
ure scenarios and congestion conditions.   Our goal was to depend=
 on existing mechanisms/technologies wherever possible.  Reuse of exis=
ting mechanisms should reduce at least some of the unpredictability.


 




First, is it the intention to derive what subscriptions are least impo=
rtant from the


DSCP, weighting and Dependency parameters? If it is, I think that may =
be a


misstake as priority on what subscriptions are most important to retai=
n are not


necessarily reflected in their QoS parameters.




 


At this point the document does not attempt to define "important&=
quot;.  All that is done is to provide guidance relating to some eleme=
nts of network transport.   If there is a dimension of "impo=
rtance" which an implementer would like to layer onto this solution, i=
t could be done.  For example, "importance" could applied in=
 areas such as what subscriptions should be suspended  in case of CPU =
exhaust.   However guidance on such enhancements are not included=
 in this document.




Still it is both implied and explicitly stated in one place. =



<eric&=
gt; Hopefully the changes suggested above cover this concern. 





 




Secondly, what are the values when a subscription are considered to be=
 to heavy


or not be handled accordingly. Are there any parameter sets that actua=
lly


describe what SLA the subscriber expect that can be converted into tim=
eout


timers or buffer depth thresholds to indicate that publisher side isn'=
t delivering


these in time?




 


There is no guidance on this provided in the document.   As =
equipment types, subscription volumes, available memory, will vary between =
solutions, this will take a while to dimension properly.  I can imagin=
e someday that we might have something like "Erlang for subscriptions&=
quot; much like we used Erlangs in the old telephony network to dimension c=
all handling capabilities of phone switches.  But we are a long way fr=
om that. 




To be clear what I mean with SLA here is to express some boundaries on w=
hen the subscribed to information will be received by the receiver compared=
 to when it come to existence on the publisher side. However, I do hear you=
 that there is nothing defined and
 nothing in the pipeline. 


<eric&=
gt; Understood.  We simply don’t have anything.




 


 




Third, I what I understand there are no any additional back pressure m=
echanism


between the receiver and the publisher than the transport protocols fl=
ow


control? So a receiver that is not keeping up processing the data it p=
rocess will


not read out the data out of the flow controlled buffers in the receiv=
er and thus


prevent the publisher to write to the transport conncetion, thus causi=
ng the


publisher to eventually trigger a suspension due to its queue build up=
?




 


There is nothing beyond transport flow control.  We thought about=
 it initially, but we were not ready to pick up even more complexity than w=
e already had.




Ok, which just contribute to what I call random things happen at overloa=
d. 



<eric&=
gt; agree




 


 




To my understanding the current mechanism places all subscriptions on =
the


same importance and with the same SLA. Thus likely causing short term =
overload


situations to cause subscription suspensions in random subscriptions. =
Is the WG


fine with this type of randomness occuring and expecting that normally=
 there


will be such amount of overprovisioning that being able to indicate pr=
iority and


SLA are overkill?




 


Yes.   We needed a starting point.  And there are techn=
ical solutions which can be layered on top.   But what we have no=
w took many years to finalize, and should be a big enough technical jump co=
nsidering our current knowledge.


 




At a minimal a change of this sentence in Section 2.5.1 is needed:


 


  This could


   be for reasons of an unexpected but sustained increase in=
 an event


   stream's event records, degraded CPU capacity, a more com=
plex


   referenced filter, or other higher priority subscriptions=
 which have


   usurped resources.




 


I have removed "higher priority".




Thanks.




 


 




As it states that subscriptions has priorities without reference to a =
mechanism


that provides that priority.


 


C. 2.4.5.  Killing a Dynamic Subscription


 


   The "kill-subscription" operation permits an op=
erator to end a


   dynamic subscription which is not associated with the tra=
nsport


   session used for the RPC.  A publisher MUST terminat=
e any dynamic


   subscription identified by the "id" parameter i=
n the RPC request, if


   such a subscription exists.


 


Can someone please clarify the use case for this functionality. To my<=
o:p>


understanding it allows another receiver given authority to kill the s=
ubscription


being delivered to another receiver. Based on the otherwise rather str=
ict that all


manipulations of dynamic subscriptions happens from the transport sess=
ion


context that established it I want to better understand the use case i=
t appears


out place.




 


A network operator needs a very secure mechanism to end a dynamic subs=
cription in progress which it sees as harmful.   The operator can=
not do this via configuration operations, as the dynamic subscription is no=
t configured (and therefore cannot be deleted in the configuration datastor=
e).  




Thanks, that clarification resolves my question mark. So lets close this=
 issue without any actions.





 


 




D. The Requirements on a transport supporting Configured Subscriptions=



Reading through Section 2.5 I arrived at a number of questions. I trie=
d to


understand what the requirements are for the transport that supports


Configured Subscriptions. I did note that neither draft-ietf-netconf-r=
estconf-


notif-13 nor


draft-ietf-netconf-netconf-event-notifications-17 supports configured<=
o:p>


subscriptions. Thus, there appear no template for a solution either, o=
r does


there exist another document that is being worked on defining such a t=
ransport?




 


This is the case.   Originally both of those documents *did*=
 include configured subscriptions.  However within the WG there was a =
decision not to progress configured subscriptions yet.  One reason is =
that other YANG model drafts moving in the NETCONF WG were seen as pre-requ=
isites for securely creating transport sessions via call home for the confi=
gured subscriptions.  As a result, support for configured subscription=
s was extracted from those transport documents.   It is expected =
that that updated versions of just those transport documents will be driven=
 when the YANG models complete.




Look at the responses below I see that we are in one of these situation =
where things are deliberately left open. I will simply assume that this is =
done in a way that supports those future definitions and clarifications. So=
 lets close this issue without any
 actions. 




 




Questions that arose for me related to Configured Susbription Transpor=
t where


the following: 1. Can Transport Session be initiated in both direction=
. RFC


8071 provides a solution for Publisher to Receiver initiation. It is u=
nclear if all


parts are in place to have a receiver to publisher initiated transport=
 to be bound


to the subscription. 




 


This will be up to a specific transport draft to make this determinati=
on.  


 


To see what might be viable for NETCONF, check out the earlier version=
 of the document at:


https://datatracker.ietf.org/doc/draft-ietf-netco=
nf-netconf-event-notifications/10/ 


 


This was seen as a complete version of such a solution.  However =
the WG wanted a YANG model for session parameters discussed in Section 5.2.=



 




2. What is "name" really? It appears to be defined as an


empty container. Despite that it appears to have requirements on being=
 both a


security identity as well as network address. 




 


You are correct.  In previous versions of this draft, a receiver =
was identified by the combination of address + port.  However due =
to the YANG doctor reviews, and call home discussions referenced above, the=
 WG wasn't ready to finalize this YANG structure.  The compromise was =
the current structure, plus the example YANG model of Appendix A to show ho=
w this might be built out.


 




3. In Figure 9, which is stated to be


for the receiver. What information does the receiver use to determine =
the


transition (d)? And what does it do in this step. Related to Discuss p=
art B). 




 


This determination is implementation specific.


 




4. RFC


8071 appears to lack any considerations for how often and how many tim=
es it


attempts to connect to the receiver. So applying that mechanism appear=
s to


require some usage guidance to avoid causing overload situations or Do=
S


potential by misconfiguring network devices with this soltution to dia=
l out


frequently to a target.


 


As the transport solution requirements are not detail it is actually h=
ard to


determine if there are short comings in the description in Section 2.5=
 and the


corresponding YANG model. Is it an reasonable request to document thes=
e


requirements?




 


The requirements were documented for both NETCONF and RESTCONF. &=
nbsp; However these requirements were removed when the WG decided to wait u=
ntil there was a YANG model for RFC-8071 ready to go to the IESG. &nbs=
p; For a preview on what these requirements might look like, I refer you&nb=
sp; to Section 5.2 of 


https://datatracker.ietf.org/doc/draft-ietf-netco=
nf-netconf-event-notifications/10/




Thanks, so this is clearly something to have in mind when the WG do get =
to specify a solution for this. So I don't see a need for any actions here.





 


 




----------------------------------------------------------------------=



COMMENT:


----------------------------------------------------------------------=



 


1. Section 2.3: DSCP domains


I think the text could benefit from pointing out that the subscriber a=
ctually needs


to know what the DSCP values represents in the diffserv domain of the =
publisher.


As these could be different, they also create an interesting problems =
for


transports of how they establish a transport connection that uses a pa=
rticular


DSCP, as the receiver if initiating need to know the local DSCP value =
that


corresponds to the behavior in the publisher's domain.



 


This makes sense.  


 


I have added in Section 5.3 Transport Requirements a new entry which s=
tates:


 


"A subscriber which includes a "dscp" leaf within an &q=
uot;establish-subscription" request will need to understand and consid=
er what the corresponding DSCP value represents within the domain of the pu=
blisher."


 


Let me know if this is not sufficient.


 




2. In general I think there are more than one description that are fuz=
zy about if it


describes a publisher or receiver action/requirement.




 


It would be great if you have some specifics.   The authors =
and previous reviewers likely have looked at this often enough where things=
 look obvious which perhaps are not.




Sorry, didn't take note about those confusion.


<eric&=
gt; Magnus, once again your comments are thoughtful and appreciated.  =
Thanks for taking such a good look at this document.


Eric=



 


Cheers 


 


Magnus Westerlund 


 


----------------------------------------------------------------------=



Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------=



Ericsson AB          =
;       | Phone  +46 10 7148287=



Torshamnsgatan 23         =
;  | Mobile +46 73 0949079


SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


----------------------------------------------------------------------=









--_000_4ac32da8a1544e26b9671f6f5e2bdf84XCHRTP013ciscocom_--


From nobody Tue May  7 13:59:03 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6BC1202BE; Tue,  7 May 2019 13:58:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <155726272794.32635.6531627027808857417.idtracker@ietfa.amsl.com>
Date: Tue, 07 May 2019 13:58:47 -0700
Archived-At: 
Subject: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 20:58:53 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the well-written document!  I  just have some boring housecleaning
points that should be easy to resolve.

Section 3.2 states:

   Subscribers can learn what event streams a RESTCONF server supports
   by querying the "streams" container of ietf-subscribed-
   notification.yang in
   [I-D.draft-ietf-netconf-subscribed-notifications].  Support for the
   "streams" container of ietf-restconf-monitoring.yang in [RFC8040] is
   not required.  If it is supported, the event streams which are in the
   "streams" container of ietf-subscribed-notifications.yang SHOULD also
   be in the "streams" container of ietf-restconf-monitoring.yang.

This "SHOULD" seems to be attempting to impose a normative requirement
on specifications that implement
draft-ietf-netconf-subscribed-notifications and RFC 8040 streams,
without regard to whether they implement this specification.  It seems
better-placed in draft-ietf-netconf-subscribed-notifications.

Similarly, when Section 4 writes:

   To meet subscription quality of service promises, the publisher MUST
   take any existing subscription "dscp" and apply it to the DSCP
   marking in the IP header.

that seems to be duplicating a normative requirement from the core
subscribed-notifications document.  (And I'm sure Magnus will have
further follow-up about how DSCP markings are per-connection for the
stream transports we have available, as well.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The core subscribed-notifications document notes that dynamic
subscriptions only last as long as the underlying transport.  In this
document, we have two connections in Figure 1, which could potentially
be separate TCP/TLS connections (or HTTP/2 streams).  In the "two TCP
connections" case, does terminating either one cause the cessation of
the subscription, or just (b)?

Section 2

Please use the boilerplate from RFC 8174.

Section 3

                                      YANG datastore subscription is
   accomplished via augmentations to
   [I-D.draft-ietf-netconf-subscribed-notifications] as described within
   [I-D.ietf-netconf-yang-push] Section 4.4.

I see some reviewers commented that things were a bit terse/arcane; I
might suggest that "via augmentations to [subscribed notifications]" is
not really adding much here, and the yang-push RPCs are the important
part.

Section 3.1

                                                         Where quick
   recognition of the loss of a publisher is required, a subscriber
   SHOULD use a TLS heartbeat [RFC6520], just from receiver to
   publisher, to track HTTP session continuity.

TLS heartbeats require initiation by the TLS client, by virtue of
including the HeartbeatExtension in the ClientHello.  Who is going to be
making the determination that quick recognition is required, and if
that's the publisher, how does the subscriber know to use TLS
heartbeats?

nit: It's interesting that we seem to be using both "subscriber" and
"receiver" to talk about the TLS client, in the same sentence.

side note: per https://github.com/openssl/openssl/pull/1928, OpenSSL
will not support TLS or DTLS heartbeats of any form in its next major
release (3.0.0).

   Loss of the heartbeat MUST result in any subscription related TCP
   sessions between those endpoints being torn down.  A subscriber can
   then attempt to re-establish the dynamic subscription by using the
   procedure described in Section 3.

RFC 6520 does not specify retransmit numbers or intervals to be used to
determine that a peer is nonresponsive (i.e., "lost"), so this text
seems under-specified.  Is the intent to leave these decisions to be
implementation-specific?

Section 3.3

I see that draft-ietf-netconf-subscribed-notifications (section 2.4.6)
admonishes us to check for transport-layer errors (and ACLs!) before
RPC-level errors; is the text here about "fails to serve the RPC
request" and our description of error handling consistent with the
separate transport-layer error handling?  (I think it can be, with a
careful reading of "one of the reasons indicated in [] Section 2.4.6",
but perhaps other readings are possible.)

      The yang-data included within "error-info" SHOULD NOT include the
      optional leaf "error-reason", as such a leaf would be redundant
      with information that is already placed within the
      "error-app-tag".

I'm not sure where this "error-reason" leaf is defined -- I don't see it
in any of subscribed-notifications, yang-push, or RFC 8040.

Section 3.4

I'm not sure that I've previously encountered using the section heading
to introduce an acronym (as is done here for SSE).  I bet the RFC Editor
will do the right thing, though.

   o  In addition to an RPC response for a "modify-subscription" RPC
      traveling over (a), a "subscription-modified" state change
      notification MUST be sent within (b).  This allows the receiver to
      know exactly when the new terms of the subscription have been
      applied to the notification messages.  See arrow (c).

nit: I might suggest some language about "order within the notifications
stream" for this state change, but that's purely editorial.

   o  In addition to any required access permissions (e.g., NACM), RPCs
      modify-subscription, resync-subscription and delete-subscription
      SHOULD only be allowed by the same RESTCONF username [RFC8040]
      which invoked establish-subscription.

I'm confused about this "SHOULD" (the secdir reviewer noted it as well)
-- in my understanding, the core subscribed-notifications requires that
such RPCs must be done on the same transport connection as the one used
to create a dynamic subscription (i.e., line (a) in Figure 1), and since
RFC 8040 authenticated client identities are at the connection level,
there could never be any change of username across the calls.

   o  Loss of TLS heartbeat

(As noted above, this is under-specified at present.)

Section 9

I would suggest also recommending that the 'uri' values not have a
predictable structure or be guessable.  While we do have solid access
control in place via NACM/etc., there is still a risk of side-channel
leakage if there's a distinction between "resource does not exist" and
"not authorized".  (FYI we had a long discussion about unguessable URIs
in the context of draft-ietf-acme-acme, which had a much weaker
access-control story and could in some sense be said to use "capability
URIs", if anyone wants to do some background reading.)
(One might see also draft-gont-numeric-ids-sec-considerations.)

I see that the subscription-id type is only of type uint32 in
draft-ietf-netconf-subscribed-notifications, which to some extent limits
the unguessability property to the URIs and not as much for the IDs
themselves (though randomization within a 32-bit space is not without
value).

Appendix A

Consistent with my suggestion in the Security Considerations, I'd change
the returned URI here or at least note that the "22", "23", etc. are
placeholders and not indicative of expected usage.

(This snippet from A.1.1)

   {
      "ietf-subscribed-notifications:input": {
         "stream-xpath-filter": "/example-module:foo/",
         "stream": "NETCONF",
         "dscp": "10"
      }
   }

The ambiguity of "10" has been noted elsewhere, but since it's a uint8
(range "0..63") wouldn't it be a JSON number, not a JSON string?

Similarly, subscription IDs are uint32, which IIUC gets encoded as a
number.



From nobody Tue May  7 14:13:55 2019
Return-Path: <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8581202B1 for ; Tue,  7 May 2019 14:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] 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 zhf9lqIu4wRA for ; Tue,  7 May 2019 14:13:46 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF64120170 for ; Tue,  7 May 2019 14:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557263624; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LHfsrPdwBSD27WwdKt2mW2BUm5BlFsPI3oDQjsnsY0E=; b=J+G/cjO/ojIlafaEkJ3y+KMdR/zvpuVW7YxUeyo5Q/8lqRsvDJLszDowxLjOCXrg mPgbjMD3vSL2lHRcOFaYnvd5bZOKTnuWjSM7SowkkFWvkXSMrX2sdTLxzl7i0eJjN3t qogyoB65ZHZDq+w4I+++rm4ZOMoy1z5s0P0ZzRGo=
From: Kent Watsen 
Message-ID: <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A1DEEFB-F337-447D-8C43-0AF892693851"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 7 May 2019 21:13:44 +0000
In-Reply-To: <20190507.141926.1879619200930898148.mbj@tail-f.com>
Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" 
To: Martin Bjorklund 
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com>  <20190507.141926.1879619200930898148.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.07-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 21:13:54 -0000

--Apple-Mail=_0A1DEEFB-F337-447D-8C43-0AF892693851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



>> The problem that I have with  generating configuration
>> directly in  is that  on the device is now =
different
>> from what the management system thinks should be in  on the
>> device.
>>=20
>> I.e. it breaks the architectural simplicity that it is only the =
client
>> that controls what goes into in 

I'm confused.  At least it seems that, regardless if the client uses =
 or , the client is performing the operation =
and can be fully aware of what it is .  For other clients, =
presumable they receive a yang-push notification alerting them to the =
update to .

Before I thought the objection regarded non-compliance to the document =
model, but that's not true in that, once the configuration is set (via =
an action), it becomes part of the document, even if =
nacm:default-deny-all.

Now I'm unclear what the objection is.  Martin has twice identified some =
issues, and both times I replied that it is acceptable to constrain the =
actions so as to avoid those issues.


>> If the clients would like to see the keys in the configuration then
>> they can monitor  (or ), and then add the =
keys,
>> either in raw form, or encrypted in some way.  But I still think that
>> it is architecturally cleaner if it is always the client that updates
>> the  configuration and never the device.
>=20
> I agree.  I think it would be worthwile to explore the
> "non-action-based" solution that Rob proposed.  Is there anything in
> that solution that doesn't work?


I discussed this option in my "wide-screen needed" email from last =
Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely "hidden") key pair and =
associated certificate.
      - these nodes MUST originate in  (origin=3D"system")
      - clients MUST replicate their (potentially encrypted or =
"permanently-hidden"
        enumerated) content into  in order reference the key =
and/or cert.

2) the client wishes to generate a key (hidden or not) without ever =
touching the
    private key.
      - presumably this occurs via a "generate-key" action (open to =
ideas)
      - this key ultimately MUST be in  in order to be =
referenced by config.
      - ideally it shows up in  as consequence of invoking the =
action.
      - less ideal, as in (1), a / sequence could =
be used
        to bring the key into .

3) the client wished to installed a hidden key.
      - note that we don't discuss installing a non-hidden key here, =
because
        that is exactly what a standard  operation does.
      - presumably this occurs via a "install-key" action (open to =
ideas)
      - this is a weird case because the client is initially okay with =
touching the
        private key, but thereafter wants it to be protected by the =
system.
      - again, as with (2), ideally the key shows up in running as =
consequence
        of the action, but a round-trip could also get it there.


Kent // contributor






--Apple-Mail=_0A1DEEFB-F337-447D-8C43-0AF892693851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



The =
problem that I have with <generate-key> generating =
configuration
directly in <running> is that =
<running> on the device is now different
from what =
the management system thinks should be in <running> on the
device.

I.e. it breaks the =
architectural simplicity that it is only the client
that =
controls what goes into in =
<running>

I'm confused.  At least it seems that, =
regardless if the client uses <edit-config> or =
<generate-key>, the client is performing the operation and can be =
fully aware of what it is <running>.  For other clients, =
presumable they receive a yang-push notification alerting them to the =
update to <running>.

Before I =
thought the objection regarded non-compliance to the document model, but =
that's not true in that, once the configuration is set (via an action), =
it becomes part of the document, even if =
nacm:default-deny-all.

Now I'm =
unclear what the objection is.  Martin has twice identified some =
issues, and both times I replied that it is acceptable to constrain the =
actions so as to avoid those issues.


If the clients would like to see the keys in the =
configuration then
they can monitor <operational> =
(or <intended>), and then add the keys,
either in =
raw form, or encrypted in some way.  But I still think that
it is architecturally cleaner if it is always the client that =
updates
the <running> configuration and never the =
device.

I agree.  I think =
it would be worthwile to explore the
"non-action-based" =
solution that Rob proposed.  Is there anything in
that =
solution that doesn't work?


I discussed this option =
in my "wide-screen needed" email from last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most =
likely "hidden") key pair and associated certificate.
      - these nodes MUST originate in =
<operational> (origin=3D"system")
  =
    - clients MUST replicate their (potentially encrypted or =
"permanently-hidden"
        =
enumerated) content into <running> in order reference the key =
and/or cert.

2) =
the client wishes to generate a key (hidden or not) without ever =
touching the
    private key.
      - presumably this occurs via a =
"generate-key" action (open to ideas)
    =
  - this key ultimately MUST be in <running> in order to be =
referenced by config.
      - =
ideally it shows up in <running> as consequence of invoking the =
action.
      - less ideal, as in =
(1), a <get-data>/<edit-data> sequence could be =
used
        to bring the key =
into <running>.

3) the client wished to installed a hidden key.
      - note =
that we don't discuss installing a non-hidden key here, =
because
        that is exactly =
what a standard <edit-config> operation does.
      - presumably this occurs via a =
"install-key" action (open to ideas)
  =
    - this is a weird case because the client is initially =
okay with touching the
        =
private key, but thereafter wants it to be protected by the =
system.
      - again, as with (2), =
ideally the key shows up in running as consequence
        of the action, but a round-trip =
could also get it there.


Kent // =
contributor





=

--Apple-Mail=_0A1DEEFB-F337-447D-8C43-0AF892693851--


From nobody Tue May  7 14:30:18 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB501202BA; Tue,  7 May 2019 14:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCPH7M2z3hM2; Tue,  7 May 2019 14:30:05 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20562120247; Tue,  7 May 2019 14:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35461; q=dns/txt; s=iport; t=1557264605; x=1558474205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3DOTfV1Da5mVWcXq2j7s+n5g92BeDEiNfLUdMftooK8=; b=LGgz/15190LKNZTLbUSNY02s5vkVZnA9Yp5FlYDICo0maoLWBnVN8W6o lkXmxDsAR+xtRLFGE0UJBKQd8pkRvRiiCO3adL9b2zF/D8PkGbdkleGTL Barh8cri8PCoQpYRkEfK/8TK3KkKGMySRtkZC7K/fxQmpFbRntOc5J/93 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABu+NFc/5xdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUgUBAQELAYEOWCppgQQoCpkqmFIUgWcOAQEjhEoCghYjNQgOAQM?= =?us-ascii?q?BAQQBAQIBAm0cDIVKAQEBBC1FBQIQAgEIFAEQEwEGBzIUEQIEAQ0FCIJPSwG?= =?us-ascii?q?BHW0Prx6KL4EyAYRkhmkXgUA/gRGCFH4+glYLAQECAYFGHwcSFgKFKgSLCQY?= =?us-ascii?q?MCYIGhHmCEoV3jRYJAoIJhUpTjCojgUJOYoViBYx+gxuJCYEhhSyIIT2FSwI?= =?us-ascii?q?RFYEwDRQBNYFWcBWDJwmLCYU/QTEBAZA2gSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,443,1549929600";  d="scan'208,217";a="554361263"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2019 21:29:39 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x47LTdjZ007713 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 May 2019 21:29:39 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 May 2019 17:29:38 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 7 May 2019 17:29:38 -0400
From: "Eric Voit (evoit)" 
To: Kent Watsen , Dhruv Dhody 
CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" 
Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sA==
Date: Tue, 7 May 2019 21:29:38 +0000
Message-ID: <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com>
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com>
In-Reply-To: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.233]
Content-Type: multipart/alternative; boundary="_000_1cf686e76a314553842305bc97baeb3dXCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 21:30:11 -0000

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

Hi Dhruv,
Hi Kent,

From: Kent Watsen, May 1, 2019 6:39 PM
On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) > wrote:

Hi Dhruv,
Hi Kent,

Thanks very much for the comments Dhruv.  Thoughts in-line, with one questi=
on to Kent...

From: Dhruv Dhody, April 30, 2019 12:53 AM

Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th=
e
Routing Directorate seeks to review all routing or routing-related drafts a=
s they
pass through IETF last call and IESG review, and sometimes on special reque=
st.
The purpose of the review is to provide assistance to the Routing ADs. For =
more
information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo=
uld
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or=
 by
updating the draft.

Document: draft-ietf-netconf-netconf-event-notifications-17
Reviewer: Dhruv Dhody
Review Date: 2019-04-29
IETF LC End Date: 2019-04-12
Intended Status: Standards Track

Summary:
--------
I have some minor concerns about this document that I think should be resol=
ved
before publication.

Comments:
---------
This document provides a binding for events streamed over the NETCONF for
dynamic subscriptions. This is a companion document to draft-ietf-netconf-
subscribed-notifications and this capability for RESTCONF is defined in dra=
ft-ietf-
netconf-restconf-notif.

The document is overall well written, it makes an assumption that the reade=
r is
well versed in this area and thus sparse in providing details in the Introd=
uction
section. The appendix provides good examples.

I don't see any Routing Yang model specific issue.

Major Issues:
-------------
Note - An IETF process issue, but worth handling right away.

Section 11 says -

11.  Notes to the RFC Editor

  This section can be removed by the RFC editor after the requests have
  been performed.

It further says -

  RFC 6241 needs to be updated based on the needs of this draft.
  RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it
  identifies RFC 5717, but that was an error fixed after RFC
  publication).  Anyway the current phrasing in RFC-5277 says that a
  notification message can only be sent after a successful "create-
  subscription".  Therefore the reference text must be modified to also
  allow notification messages be sent after a successful "establish-
  subscription".  Proposed text for bullet (2) of RFC-6241 would be:

    (2)  The Messages layer provides a simple, transport-independent
         framing mechanism for encoding RPCs and notifications.
         Section 4 documents the RPC messages, [RFC5277] documents
         Notifications sent as a result of a  RPC,
         and [RFC xxxx] documents Notifications sent as a result of
         an  RPC.

     (where xxxx is replaced with this RFC number)

I am not sure if this is correct. I don't think RFC editor can do the actio=
n you are
asking them to do on their own. They would need an errata (which is not cor=
rect
here) or another document that updates RFC 6241. In my view this document
should just update RFC 6241 (and mark that in this document's
header) and do necessary text changes to reflect that.

I am happy to follow whatever process is cleanest.

Kent, are you comfortable with this document directly revising  wording of =
RFC-6241 section 1.2 bullet "(2)" above?    If yes, it would be great to ha=
ve your thoughts on what needs to go into this document.   Especially as RF=
C-6241 section 1.2 bullet "(2)" already had a fix applied against it.


Dhruv is correct, the RFC Editor cannot make the requested change, and an E=
rrata is also not correct, as there is nothing wrong with the way that RFC =
6241 was written at the time it was written.

To answer the question, if this draft is to "update" RFC 6241, the steps ar=
e 1) declare the update in the draft's header (see Section 2.33.10 of RFC 7=
749), 2) so so in the Abstract, and 3) have a new section (either before of=
 after the current Section 3 called "Update to RFC 6241" that describes the=
 desired modification.

However, it is unclear if an "update" is appropriate either, given that the=
 "update" is informative in nature and, while it is true that this document=
 cannot be used without RFC 6241, that is also true for so many documents t=
hat don't update RFC 6241.

>From now obsolete RFC 2223 (I couldn't find a current reference):

   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

and from expired draft-rfc-editor-rfc2223bis-08:

         Updates

            Specifies an earlier document whose contents are modified or
            augmented by the new document.  The new document cannot be
            used alone, it can only be used in conjunction with the
            earlier document.

Is an "update" overreaching?

Another option is to not update RFC 6241 and instead just mention it, simil=
ar to what was done here: https://tools.ietf.org/html/rfc8071#section-1.4. =
  Note that RFC 8071 originally "updated" RFC 4253, but Benoit (AD at the t=
ime) recommended downgrading it to what it is now.


A couple more thoughts:

1) if an update is needed, would it be better coming from draft-ietf-netcon=
f-subscribed-notifications, which defines the "establish-subscription" RPC?


2) whatever the outcome of this discussion, it seems that a similar outcome=
 should be applied to draft-ietf-netconf-restconf-notif and its relation to=
 RFC 8040.


 Based on my reading of your process suggestions Kent, I like best th=
e "mention" approach which you used for RFC-8071, Section 1.4.

What I think could be done to cover this is:

(A)  Remove Section 11: Notes to the RFC Editor

(B)  Per Kent's desire to also cover draft-ietf-netconf-restconf-notif, pla=
ce the following statement into draft-ietf-netconf-subscribed-notifications=
 directly after Figure 10

[RFC-5277] Section 2.2.1 states that a notification message is to be sent t=
o a subscriber which initiated a "create-subscription".   With this specifi=
cation, this RFC-5277 statement should be more broadly interpreted to mean =
that notification messages can also be sent to a subscriber which initiated=
 an "establish-subscription", or a configured receiver which has been sent =
a "subscription-started".

Does this work for both of you?


[also see my comment below]



Minor Issues:
-------------
(1) Abstract & Introduction, It is not clear what does the 'binding' mean a=
nd who
are the parties to this binding? If this is the document that mentions 'bin=
ding'
first, so please add some more clarifying text.

(2) Section 3, since you use MUST in the error handling, isn't it better to=
 use
normative in below sentence as well -
OLD:
                                                      However a single
  NETCONF transport session cannot support both this specification and
  a subscription established by [RFC5277]'s "create-subscription" RPC.
NEW:
                                                      However a single
  NETCONF transport session MUST NOT support both this specification and
  a subscription established by [RFC5277]'s "create-subscription" RPC.

Makes sense.  I have made the change, and will post the update when the "Ma=
jor issue" from above is resolved.

(3) Section 6, You have -

  And per [RFC5277]'s "eventTime" object definition, the
  "eventTime" MUST be populated with the event occurrence time.

Is this a new requirement, or just re-stating RFC5277? RFC5277 says -

     eventTime

        The time the event was generated by the event source.  This
        parameter is of type dateTime and compliant to [RFC3339].
        Implementations must support time zones.

     Also contains notification-specific tagged content, if any.  With
     the exception of , the content of the notification is
     beyond the scope of this document.

Maybe remove MUST? If you are trying to refine the text from RFC5277, then
please re-word.

You are correct.  The MUST is redundant with RFC-5277's XSD definition.   T=
herefore I have removed "MUST be".

Nits:
-----
(1) Abstract

  RFC Editor note: please replace the four references to pre-RFC
  normative drafts with the actual assigned RFC numbers.

I see two drafts in the reference section. Why four?

You are correct.  I removed the word "four".

Also, since those two are normative references, these would be published as=
 a
cluster as a part of normal RFC editor processing right?

Yes.

(2) Regarding NETCONF, the RFC editor says [1] -

NETCONF    - Network Configuration Protocol (NETCONF)
              [Not typically expanded in titles, but expand in abstract]

Please expand.

Done.

(3) s/[I-D.draft-ietf-netconf-subscribed-notifications]
    /[I-D.ietf-netconf-subscribed-notifications]

Actually I changed the [I-D.ietf-netconf-yang-push]  to  [I-D.draft-ietf-ne=
tconf-yang-push]

This makes it consistent across all four drafts.


The issue isn't consistency so much as meeting expectations, per `xml2rfc`,=
 the document should have something like the following in the References se=
ction, which then auto-expands to the correct reference text, as well as de=
fining the anchor "I-D.ietf-netconf-subscribed-notifications":

        

 That definitely makes things easier than what I have been doing.  I =
am hitting an xml2rfc error trying this right now, but I will get there.

Eric



Kent // shepherd



Thanks again!
Eric

Just so that you have the same style of draft reference in the document. I =
get
that it would be replaced with a RFC number anyways :)

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

Thanks!
Dhruv


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











Hi Dhruv,


Hi Kent,


 




From: Kent Wat=
sen, May 1, 2019 6:39 PM








On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) <<=
a href=3D"mailto:evoit@cisco.com">evoit@cisco.com> wrote:=





 




Hi Dhruv,

Hi Kent,



Thanks very much for the comments Dhruv.  Thoughts in-line, with one q=
uestion to Kent...








From: Dhruv Dhody, April 30, 2019 12:53 AM



Hello,



I have been selected as the Routing Directorate reviewer for this draft. Th=
e

Routing Directorate seeks to review all routing or routing-related drafts a=
s they

pass through IETF last call and IESG review, and sometimes on special reque=
st.

The purpose of the review is to provide assistance to the Routing ADs. For =
more

information about the Routing Directorate, please see

http://tra=
c.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it wo=
uld

be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or=
 by

updating the draft.



Document: draft-ietf-netconf-netconf-event-notifications-17

Reviewer: Dhruv Dhody

Review Date: 2019-04-29

IETF LC End Date: 2019-04-12

Intended Status: Standards Track



Summary:

--------

I have some minor concerns about this document that I think should be resol=
ved

before publication.



Comments:

---------

This document provides a binding for events streamed over the NETCONF for
dynamic subscriptions. This is a companion document to draft-ietf-netconf-<=
br>
subscribed-notifications and this capability for RESTCONF is defined in dra=
ft-ietf-

netconf-restconf-notif.



The document is overall well written, it makes an assumption that the reade=
r is

well versed in this area and thus sparse in providing details in the Introd=
uction

section. The appendix provides good examples.



I don't see any Routing Yang model specific issue.



Major Issues:

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

Note - An IETF process issue, but worth handling right away.



Section 11 says -



11.  Notes to the RFC Editor



  This section can be removed by the RFC editor after the request=
s have

  been performed.



It further says -



  RFC 6241 needs to be updated based on the needs of this draft.<=
br>
  RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (a=
ctually it

  identifies RFC 5717, but that was an error fixed after RFC

  publication).  Anyway the current phrasing in RFC-5277 say=
s that a

  notification message can only be sent after a successful "=
create-

  subscription".  Therefore the reference text must be =
modified to also

  allow notification messages be sent after a successful "es=
tablish-

  subscription".  Proposed text for bullet (2) of RFC-6=
241 would be:



    (2)  The Messages layer provides a simple, tra=
nsport-independent

         framing mechanism for=
 encoding RPCs and notifications.

         Section 4 documents t=
he RPC messages, [RFC5277] documents

         Notifications sent as=
 a result of a <create-subscription> RPC,

         and [RFC xxxx] docume=
nts Notifications sent as a result of

         an <establish-subs=
cription> RPC.



     (where xxxx is replaced with this RFC number)=




I am not sure if this is correct. I don't think RFC editor can do the actio=
n you are

asking them to do on their own. They would need an errata (which is not cor=
rect

here) or another document that updates RFC 6241. In my view this document
should just update RFC 6241 (and mark that in this document's

header) and do necessary text changes to reflect that.





I am happy to follow whatever process is cleanest.   



Kent, are you comfortable with this document directly revising  wordin=
g of RFC-6241 section 1.2 bullet "(2)" above?    I=
f yes, it would be great to have your thoughts on what needs to go into thi=
s document.   Especially as RFC-6241 section 1.2 bullet "(2)=
"
 already had a fix applied against it. 








 






 






Dhruv is correct, the RFC Editor cannot make the req=
uested change, and an Errata is also not correct, as there is nothing wrong=
 with the way that RFC 6241 was written at the time it was written.






 








To answer the question, if this draft is to "up=
date" RFC 6241, the steps are 1) declare the update in the draft's hea=
der (see Section 2.33.10 of RFC 7749), 2) so so in the Abstract, and 3) hav=
e a new section (either before of after the
 current Section 3 called "Update to RFC 6241" that describes the=
 desired modification.






 








However, it is unclear if an "update" is a=
ppropriate either, given that the "update" is informative in natu=
re and, while it is true that this document cannot be used without RFC 6241=
, that is also true for so many documents that don't update
 RFC 6241.






 






From now obsolete RFC 2223 (I couldn't find a curren=
t reference):






 








   Updates






 






      To be used as a reference from =
a new item that cannot be used






      alone (i.e., one that supplemen=
ts a previous document), to refer






      to the previous document.  =
;The newer publication is a part that






      will supplement or be added on =
to the existing document; e.g., an






      addendum, or separate, extra in=
formation that is to be added to






      the original document.






 






and from expired draft-rfc-editor-rfc2223bis-08=
:






 








         Updates=







 






            Specifies =
an earlier document whose contents are modified or






            augmented =
by the new document.  The new document cannot be






            used alone=
, it can only be used in conjunction with the






            earlier do=
cument.




 






Is an "update" overreaching?





 






Another option is to not update RFC 6241 and instead=
 just mention it, similar to what was done here: https://tools.ietf.org/html/rfc8071#=
section-1.4.   Note that RFC 8071 originally
 "updated" RFC 4253, but Benoit (AD at the time) recommended down=
grading it to what it is now.






 








 






A couple more thoughts:






 






1) if an update is needed, would it be better coming=
 from draft-ietf-netconf-subscribed-notifications, which defines the "=
establish-subscription" RPC?


 






 






2) whatever the outcome of this discussion, it seems=
 that a similar outcome should be applied to draft-ietf-netconf-restconf-no=
tif and its relation to RFC 8040.






 






 


<eric> Based on =
my reading of your process suggestions Kent, I like best the “mention=
” approach which you used for RFC-8071, Section 1.4.


 


What I think could be =
done to cover this is:



 


(A)  Remove Secti=
on 11: Notes to the RFC Editor


 


(B)  Per KentR=
17;s desire to also cover draft-ietf-netconf-restconf-notif, place the foll=
owing statement into draft-ietf-netconf-subscribed-notifications directly a=
fter Figure 10


 


[RFC-5277] Section 2.2.1 states that a notification message i=
s to be sent to a subscriber which initiated a "create-subscription&qu=
ot;.   With this specification, this RFC-5277 statement
 should be more broadly interpreted to mean that notification messages can =
also be sent to a subscriber which initiated an "establish-subscriptio=
n", or a configured receiver which has been sent a “subscription=
-started”.


 


Does this work for bot=
h of you? 



 


 






[also see my comment below]






 






 




 








Minor Issues:

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

(1) Abstract & Introduction, It is not clear what does the 'binding' me=
an and who

are the parties to this binding? If this is the document that mentions 'bin=
ding'

first, so please add some more clarifying text.



(2) Section 3, since you use MUST in the error handling, isn't it better to=
 use

normative in below sentence as well -

OLD:

            &nb=
sp;            =
            &nb=
sp;            =
    However a single

  NETCONF transport session cannot support both this specificatio=
n and

  a subscription established by [RFC5277]'s "create-subscrip=
tion" RPC.

NEW:

            &nb=
sp;            =
            &nb=
sp;            =
    However a single

  NETCONF transport session MUST NOT support both this specificat=
ion and

  a subscription established by [RFC5277]'s "create-subscrip=
tion" RPC.






Makes sense.  I have made the change, and will post the update when th=
e "Major issue" from above is resolved.








(3) Section 6, You have -



  And per [RFC5277]'s "eventTime" object definition, th=
e

  "eventTime" MUST be populated with the event occurren=
ce time.



Is this a new requirement, or just re-stating RFC5277? RFC5277 says -



     eventTime



        The time the event was gene=
rated by the event source.  This

        parameter is of type dateTi=
me and compliant to [RFC3339].

        Implementations must suppor=
t time zones.



     Also contains notification-specific tagged co=
ntent, if any.  With

     the exception of <eventTime>, the conte=
nt of the notification is

     beyond the scope of this document.



Maybe remove MUST? If you are trying to refine the text from RFC5277, then<=
br>
please re-word.






You are correct.  The MUST is redundant with RFC-5277's XSD definition=
.   Therefore I have removed "MUST be".








Nits:

-----

(1) Abstract



  RFC Editor note: please replace the four references to pre-RFC<=
br>
  normative drafts with the actual assigned RFC numbers.



I see two drafts in the reference section. Why four?






You are correct.  I removed the word "four".  








Also, since those two are normative references, th=
ese would be published as a

cluster as a part of normal RFC editor processing right?<=
/p>





Yes.








(2) Regarding NETCONF, the RFC editor says [1] -


NETCONF    - Network Configuration Protocol (NETCONF)

            &nb=
sp; [Not typically expanded in titles, but expand in abstract]



Please expand.






Done.








(3) s/[I-D.draft-ietf-netconf-subscribed-notificat=
ions]

    /[I-D.ietf-netconf-subscribed-notifications]






Actually I changed the [I-D.ietf-netconf-yang-push]  to  [I-D.dra=
ft-ietf-netconf-yang-push]



This makes it consistent across all four drafts.








 






 






The issue isn't consistency so much as meeting expec=
tations, per `xml2rfc`, the document should have something like the followi=
ng in the References section, which then auto-expands to the correct refere=
nce text, as well as defining the
 anchor "I-D.ietf-netconf-subscribed-notifications":





 






        <?rfc include=3D=
"reference.I-D.ietf-netconf-subscribed-notifications"?>






 






<Eric> That defi=
nitely makes things easier than what I have been doing.  I am hitting =
an xml2rfc error trying this right now, but I will get there.


 


Eric=



 


 






 






Kent // shepherd






 




 








Thanks again!

Eric








Just so that you have the same style of draft refe=
rence in the document. I get

that it would be replaced with a RFC number anyways :)



[1] https://www.rfc-editor.org=
/materials/abbrev.expansion.txt



Thanks!

Dhruv










 








--_000_1cf686e76a314553842305bc97baeb3dXCHRTP013ciscocom_--


From nobody Tue May  7 14:49:55 2019
Return-Path: <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520381200EB; Tue,  7 May 2019 14:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NZLesFMdBSr; Tue,  7 May 2019 14:49:43 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381A6120086; Tue,  7 May 2019 14:49:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557265781; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BJj6538wbLJwCYzQThiiB19tcjwdgm/QGhFZOz9Lofk=; b=ENskTtUohbvx6HpYxqLfyvpv1Vzjel8g+L86qvg4HKGb6Z+PNsAJVK4FCcD8TKzS 0bZLu9YEq/uprXQ2EXxGgEnjET7josPqLpg8OGwGAuLCEc7+OFy/0agxvu2q2fcLeYZ L9Glw6uzdwD1Yhox26scI5wRq/JvKhMciCwDScmM=
From: Kent Watsen 
Message-ID: <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 7 May 2019 21:49:41 +0000
In-Reply-To: <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com>
Cc: Dhruv Dhody , "rtg-dir@ietf.org" ,  "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" ,  "netconf@ietf.org" , Dhruv Dhody , "" 
To: "Eric Voit (evoit)" 
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.07-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 21:49:46 -0000

--Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



>  Based on my reading of your process suggestions Kent, I like =
best the =E2=80=9Cmention=E2=80=9D approach which you used for RFC-8071, =
Section 1.4.
> =20
> What I think could be done to cover this is:
> =20
> (A)  Remove Section 11: Notes to the RFC Editor
> =20
> (B)  Per Kent=E2=80=99s desire to also cover =
draft-ietf-netconf-restconf-notif, place the following statement into =
draft-ietf-netconf-subscribed-notifications directly after Figure 10
> =20
> [RFC-5277] Section 2.2.1 states that a notification message is to be =
sent to a subscriber which initiated a "create-subscription".   With =
this specification, this RFC-5277 statement should be more broadly =
interpreted to mean that notification messages can also be sent to a =
subscriber which initiated an "establish-subscription", or a configured =
receiver which has been sent a =E2=80=9Csubscription-started=E2=80=9D.
> =20
> Does this work for both of you?=20

Works for me.



> The issue isn't consistency so much as meeting expectations, per =
`xml2rfc`, the document should have something like the following in the =
References section, which then auto-expands to the correct reference =
text, as well as defining the anchor =
"I-D.ietf-netconf-subscribed-notifications":
> =20
>         
> =20
>  That definitely makes things easier than what I have been =
doing.  I am hitting an xml2rfc error trying this right now, but I will =
get there.


Yes, it was an eye-opener when I figured it out.   Be aware that, though =
some external sources (e.g., ITU standards) are supported, many are not, =
and so hand-coding the  is still sometimes required...


Kent // shepherd




--Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



<eric> Based on my reading of your process =
suggestions Kent, I like best the =E2=80=9Cmention=E2=80=9D approach =
which you used for RFC-8071, Section 1.4.
 
What I =
think could be done to cover this is:
 
(A) =
 Remove Section 11: Notes to the RFC Editor
 
(B) =
 Per Kent=E2=80=99s desire to also cover =
draft-ietf-netconf-restconf-notif, place the following statement into =
draft-ietf-netconf-subscribed-notifications directly after Figure 10
 
[RFC-5277] =
Section 2.2.1 states that a notification message is to be sent to a =
subscriber which initiated a "create-subscription".   With =
this specification, this RFC-5277 statement should be more broadly =
interpreted to mean that notification messages can also be sent to a =
subscriber which initiated an "establish-subscription", or a configured =
receiver which has been sent a =E2=80=9Csubscription-started=E2=80=9D.
 
Does =
this work for both of =
you? 

Works for me.



The issue isn't consistency so =
much as meeting expectations, per `xml2rfc`, the document should have =
something like the following in the References section, which then =
auto-expands to the correct reference text, as well as defining the =
anchor =
"I-D.ietf-netconf-subscribed-notifications":
 
      =
  <?rfc =
include=3D"reference.I-D.ietf-netconf-subscribed-notifications"?>
 
<Eric> That definitely makes things easier than =
what I have been doing.  I am hitting an xml2rfc error trying this =
right now, but I will get =
there.

Yes, it was an eye-opener when I figured it out. =
  Be aware that, though some external sources (e.g., ITU standards) =
are supported, many are not, and so hand-coding the <reference> is =
still sometimes required...


Kent // shepherd



=

--Apple-Mail=_0FE25B22-758E-4E55-B537-77E289AF4899--


From nobody Tue May  7 15:24:29 2019
Return-Path: <0100016a9465d3e2-9e05e8e7-824c-41f8-985a-fc767147bc9c-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F8012023B for ; Tue,  7 May 2019 15:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wET_Vkk4dH5 for ; Tue,  7 May 2019 15:24:24 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3AC12014B for ; Tue,  7 May 2019 15:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557267862; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JGcIczEFrYsGAlqpYyqWoxyFaLE+OY5Zj3UwUIBkQJw=; b=CA6bWTKSyIH+T6ACT9+q44eR0E3mtIo71Y9Hiselp+AO79572NhezQsDWtbIw8ob cLxaPrgHzADra3FJ8AnIr0PdBZINackziRXpCyrQVy8KB1K/oNHgd0cN8Fpj5na2893 h4G+h4smrLcm+yXPAB0KI0sw9IOx/UzDNWZ2bB2o=
From: Kent Watsen 
Message-ID: <0100016a9465d3e2-9e05e8e7-824c-41f8-985a-fc767147bc9c-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_10A169CF-D213-4F11-8856-AD4186ADFD99"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 7 May 2019 22:24:22 +0000
In-Reply-To: 
Cc: "netconf@ietf.org" 
To: Nick Hancock 
References:  <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@email.amazonses.com> 
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.07-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 May 2019 22:24:27 -0000

--Apple-Mail=_10A169CF-D213-4F11-8856-AD4186ADFD99
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Nick,

> Given that a client has the required permissions, the current model=20
> allows a client to create an entry in the list 'asymmetric-key'=20
> without the 3-tuple leafs 'algorithm', 'public-key' and 'private-key'=20=

> as allowed via the must statement on the list. At this point there=20
> would be no 3-tuple in  either. Defining the 3-tuple in=20=

>  or  would be a second step, such as invoking=20=

> the action 'generate-hidden-key'. Since there is, as you indicated,=20
> no 'must' statement relevant to the 'certificate' list, the model=20
> also allows a client to configure a certificate (chain) on an entry=20
> in the list 'asymmetric-key' without the 3-tuple in either =20=

> or . The asymmetric key entry would not be able to be=20
> used to establish a TLS session due to the missing 3-tuple, of course.
>=20
> Is this a valid use case? Possibly. I could argue that a client may=20
> wish to 'park' certificate chains in the keystore without necessary=20
> immediately using them on the server or even just pre-provision them=20=

> and then provide the actual public key later maybe through some other=20=

> process based on an operator's security policies? It makes no sense=20
> to reference a certificate in the keystore that is missing the=20
> 3-tuple as the server identity of a NETCONF server or client identity=20=

> of a NETCONF client as it cannot be used, so the question is whether=20=

> it would make more sense to constrain the actual reference to=20
> reference certificates that have 3-tuple, if this is at all possible=20=

> considering that the 3-tuple may only be in ?

If you look at my "wide-screen needed" email from last Friday, you'll =
see that I'm trying to make a case that these 3-tuple nodes should be =
"mandatory true".   If that discussion falls apart, then we can revisit =
your proposal here.

BTW, please jump into that discussion, as comments from implementations =
are highly valued.


> During analysis of deploying the keystore and truststore in our=20
> implementation, I have made some further observations that may be of=20=

> interest:

I see you're calling it "truststore", which I take as a confirmation for =
the rename proposal sent out last Thursday.


> 1. There is nothing in the model to prevent a client configuring a=20
>   certificate to an asymmetric key that is not applicable to that=20
>   asymmetric key or even a certificate chain in the keystore or=20
>   truststore that is incompatible to the required type=20
>   ('end-entity-cert-cms' or 'trust-anchor-cert-cms' respectively)=20
>   or is this to be rejected by the implementation, in which case=20
>   this behavior is not described in the YANG?

Such incompatibilities must not be allowed.  As neither issue can be =
enforced via YANG validation constraints, the best we can do is add =
comments to the description statements. =20

For the latter case, I believe that both the 'end-entity-cert-cms' or =
'trust-anchor-cert-cms' description statements have a sufficient number =
of MUST statements. - agreed?

For the former, how about this:

@@ -1614,7 +1624,9 @@ module ietf-crypto-types {
=20
   grouping asymmetric-key-pair-with-cert-grouping {
     description
-      "A private/public key pair and an associated certificate.";
+      "A private/public key pair and an associated certificate.
+       Implementations SHOULD assert that certificates contain
+       the matching public key.";
=20
     uses asymmetric-key-pair-grouping;
     uses end-entity-cert-grouping;
@@ -1692,7 +1704,9 @@ module ietf-crypto-types {
=20
   grouping asymmetric-key-pair-with-certs-grouping {
     description
-      "A private/public key pair and associated certificates.";
+      "A private/public key pair and associated certificates.
+       Implementations SHOULD assert that certificates contain
+       the matching public key.";
     uses asymmetric-key-pair-grouping;
     container certificates {
=20




> 2. I am not convinced whether the use of the prefix 'pinned-' on the=20=

>   containers and lists in ietf-trust-anchors is correct. The=20
>   certificates are available in the truststore for pinning, yes, but=20=

>   does not the 'pinning' actually take place when the certificates=20
>   are configured for client authentication on a server or server=20
>   authentication on a client? So I would argue that a certificate=20
>   may be in the trust store, but not necessarily pinned, so the name=20=

>   may be misleading or am I missing something? Thus, I would have=20
>   expected the containers and lists to be without the 'pinned-'=20
>   prefix within the truststore itself. The 'pinned-' prefix being=20
>   only on the references, which is the case in the NETCONF client=20
>   and server models.


Agreed, especially with renaming the module and top-level container node =
to "truststore" (what else would a truststore contain, right?).  I just =
all the "pinned" prefixes in my local copy (s/pinned.//g)



> 3. As an initial step we are analyzing the standalone use of the=20
>   keystore in truststore modules and were considering some=20
>   proprietary notifications that would include the certificate=20
>   (chain) received during TLS session establishment, but could not=20
>   'use' the groupings in ietf-crypt-types because they include=20
>   actions and notifications, which are not allowed in notifications.=20=

>   Maybe it would be advantageous to provide basic groupings without=20
>   actions and notifications for use in proprietary RPCs and=20
>   notifications and provide refined versions of these groupings that=20=

>   include the actions and notifications? Obviously this would mean=20
>   even more groupings, but wouldn't this increase their reusability?

I don't understand "standalone use of the keystore in truststore =
modules" - maybe you meant "and"?

I know what you mean.   I recently wanted to use some groupings from =
another module but couldn't for a similar reason, and hence had a =
similar copy/paste yuck experience.

If I understand you correctly, you're saying that tooling such as =
`pyang` or `yanglint` is complaining because your notification "uses" =
the crypto-type grouping, which itself defines a notification - yes?

RFC 7950 Section 7.16 says"

   A notification MUST NOT be defined within an rpc, action, or another
   notification, i.e., a notification node MUST NOT have an rpc, action,
   or a notification node as one of its ancestors in the schema tree.
   For example, this means that it is an error if a grouping that
   contains a notification somewhere in its node hierarchy is used in an
   rpc definition.

Ouch, that's rather specific.  I was hoping there might be some wiggle =
room allowing for "inner" notifications to just be ignored.  That sounds =
like a better solution, don't you think, perhaps a YANG-Next candidate?

You're right in guessing we're reluctant to create more groupings =
unnecessarily and, in this case, these groupings are very small - just a =
single "leaf" or "leaf-list", so the yuck isn't all that much.  =
Copy/paste might be reasonable in this case, no?


Kent // contributor





--Apple-Mail=_10A169CF-D213-4F11-8856-AD4186ADFD99
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Nick,

Given that a client has the required =
permissions, the current =
model 
allows a client to create an entry in the list =
'asymmetric-key' 
without the =
3-tuple leafs 'algorithm', 'public-key' and 'private-key' 
as allowed =
via the must statement on the list. At this point there 
would be no =
3-tuple in <operational> either. Defining the 3-tuple in 
<intended> or <operational> would be a second =
step, such as invoking 
the action =
'generate-hidden-key'. Since there is, as you indicated, 
no 'must' =
statement relevant to the 'certificate' list, the model 
also allows a =
client to configure a certificate (chain) on an entry 
in the list =
'asymmetric-key' without the 3-tuple in either <intended> 
or =
<operational>. The asymmetric key entry would not be able to =
be 
used to =
establish a TLS session due to the missing 3-tuple, of course.

Is this a =
valid use case? Possibly. I could argue that a client may 
wish to =
'park' certificate chains in the keystore without necessary 
immediately =
using them on the server or even just pre-provision them 
and then =
provide the actual public key later maybe through some other 
process based =
on an operator's security policies? It makes no sense 
to reference =
a certificate in the keystore that is missing the 
3-tuple as =
the server identity of a NETCONF server or client identity 
of a NETCONF =
client as it cannot be used, so the question is whether 
it would make =
more sense to constrain the actual reference to 
reference =
certificates that have 3-tuple, if this is at all possible 
considering =
that the 3-tuple may only be in <operational>?

If you look at my "wide-screen needed" email =
from last Friday, you'll see that I'm trying to make a case that these =
3-tuple nodes should be "mandatory true".   If that discussion =
falls apart, then we can revisit your proposal here.

BTW, please jump into that =
discussion, as comments from implementations are highly =
valued.


During analysis of deploying the keystore and truststore in =
our 
implementation,=
 I have made some further observations that may be of 
interest:

I see you're calling it "truststore", which I take =
as a confirmation for the rename proposal sent out last =
Thursday.


1. There is nothing in the model to prevent a client =
configuring a   certificate to an asymmetric key that is not =
applicable to that 
  asymmetric key or even a certificate chain in the =
keystore or 
  truststore that is incompatible to the required =
type 
  ('end-entity-cert-cms' or 'trust-anchor-cert-cms' =
respectively)   or =
is this to be rejected by the implementation, in which case 
  this behavior is not described in the =
YANG?

Such =
incompatibilities must not be allowed.  As neither issue can be =
enforced via YANG validation constraints, the best we can do is add =
comments to the description statements.  

For the latter case, I believe that both =
the 'end-entity-cert-cms' or 'trust-anchor-cert-cms' description =
statements have a sufficient number of MUST statements. - =
agreed?

For the former, how about =
this:

@@ -1614,7 +1624,9 =
@@ module ietf-crypto-types {
 
   grouping asymmetric-key-pair-with-cert-grouping =
{
     description
-  =
    "A private/public key pair and an =
associated certificate.";
+    =
  "A private/public key pair and an =
associated certificate.
+     =
  Implementations SHOULD assert that =
certificates contain
+     =
  the matching public key.";
 
     uses asymmetric-key-pair-grouping;
     uses end-entity-cert-grouping;
@@ -1692,7 +1704,9 @@ module ietf-crypto-types {
 
   grouping =
asymmetric-key-pair-with-certs-grouping {
    =
 description
-      "A =
private/public key pair and associated certificates.";
+      "A private/public key pair and =
associated certificates.
+     =
  Implementations SHOULD assert that =
certificates contain
+     =
  the matching public key.";
    =
 uses asymmetric-key-pair-grouping;
    =
 container certificates {
 




2. I am not convinced whether the use of the prefix 'pinned-' =
on the 
  containers and lists in ietf-trust-anchors is =
correct. The 
  certificates are available in the truststore for =
pinning, yes, but 
  does not the 'pinning' actually take place when =
the certificates 
  are=
 configured for client authentication on a server or server 
  authentication on a client? So I would argue that =
a certificate   may=
 be in the trust store, but not necessarily pinned, so the name 
  may=
 be misleading or am I missing something? Thus, I would have 
  expected the containers and lists to be without =
the 'pinned-'   prefix within the truststore itself. The =
'pinned-' prefix being 
  only on the references, which is the case in the =
NETCONF client 
  and=
 server models.


Agreed, especially with =
renaming the module and top-level container node to "truststore" (what =
else would a truststore contain, right?).  I just all the "pinned" =
prefixes in my local copy (s/pinned.//g)



3. As an initial step we are analyzing the standalone use of =
the 
  keystore in truststore modules and were =
considering some 
  proprietary notifications that would include the =
certificate 
  (chain) received during TLS session =
establishment, but could not 
  'use' the groupings in ietf-crypt-types because =
they include 
  actions and notifications, which are not allowed =
in notifications. 
  Maybe it would be advantageous to provide basic =
groupings without 
  actions and notifications for use in proprietary =
RPCs and 
  notifications and provide refined versions of =
these groupings that 
  include the actions and notifications? Obviously =
this would mean 
  even more groupings, but wouldn't this increase =
their reusability?

I don't understand "standalone use of =
the keystore in truststore modules" - maybe you meant "and"?

I know what you mean. =
  I recently wanted to use some groupings from another module but =
couldn't for a similar reason, and hence had a similar copy/paste yuck =
experience.

If =
I understand you correctly, you're saying that tooling such as `pyang` =
or `yanglint` is complaining because your notification "uses" the =
crypto-type grouping, which itself defines a notification - =
yes?

RFC 7950 =
Section 7.16 says"

   A notification MUST NOT be defined within an rpc, action, or =
another
   notification, i.e., a notification node MUST NOT have an rpc, action,
   or a notification node as one of its ancestors in the schema tree.
   For example, this means that it is an error if a grouping that
   contains a notification somewhere in its node hierarchy is used in an
   rpc definition.


Ouch, =
that's rather specific.  I was hoping there might be some wiggle =
room allowing for "inner" notifications to just be ignored.  That =
sounds like a better solution, don't you think, perhaps a YANG-Next =
candidate?

You're right in guessing we're reluctant to create more =
groupings unnecessarily and, in this case, these groupings are very =
small - just a single "leaf" or "leaf-list", so the yuck isn't all that =
much.  Copy/paste might be reasonable in this case, no?


Kent // contributor




=

--Apple-Mail=_10A169CF-D213-4F11-8856-AD4186ADFD99--


From nobody Tue May  7 22:46:31 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C001212013B for ; Tue,  7 May 2019 22:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C_0Iw050FgxP for ; Tue,  7 May 2019 22:46:26 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBF3120086 for ; Tue,  7 May 2019 22:46:26 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 076E335E; Wed,  8 May 2019 07:46:24 +0200 (CEST)
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 W7yOJYRsx6Gf; Wed,  8 May 2019 07:46:23 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  8 May 2019 07:46:23 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3E37200EC; Wed,  8 May 2019 07:46:23 +0200 (CEST)
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 CBwM9NUEnQxO; Wed,  8 May 2019 07:46:23 +0200 (CEST)
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 3B697200EA; Wed,  8 May 2019 07:46:23 +0200 (CEST)
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.1713.5; Wed, 8 May 2019 07:46:22 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 55A113008C849B; Wed,  8 May 2019 07:46:22 +0200 (CEST)
Date: Wed, 8 May 2019 07:46:22 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: Martin Bjorklund , "netconf@ietf.org" 
Message-ID: <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" 
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com>  <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-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: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 05:46:30 -0000

On Tue, May 07, 2019 at 09:13:44PM +0000, Kent Watsen wrote:
> 
> 
> I discussed this option in my "wide-screen needed" email from last Friday.
> There are 3 cases to consider:
> 
> 1) the manufacturer creates the (most likely "hidden") key pair and associated certificate.
>       - these nodes MUST originate in  (origin="system")
>       - clients MUST replicate their (potentially encrypted or "permanently-hidden"
>         enumerated) content into  in order reference the key and/or cert.

The question is what or how much needs replication. We refer to
hardware interfaces created by the manufacturer (and identified during
system startup - or during hotplug procedures) by having a name
binding of config in  to operational state in .
If you configure eth0, then this config binds to an 
interface with the same name. So if there is a key pair created by the
vendor, perhaps all we need is a kind of a name that can be used to
bind the config to the key.
 
> 2) the client wishes to generate a key (hidden or not) without ever touching the
>     private key.
>       - presumably this occurs via a "generate-key" action (open to ideas)
>       - this key ultimately MUST be in  in order to be referenced by config.

Perhaps the question is whether this is 'the key' or 'the name of the
key'.

>       - ideally it shows up in  as consequence of invoking the action.
>       - less ideal, as in (1), a / sequence could be used
>         to bring the key into .

Would it help if "generate-key" simply returns a name for the new key?

> 3) the client wished to installed a hidden key.
>       - note that we don't discuss installing a non-hidden key here, because
>         that is exactly what a standard  operation does.
>       - presumably this occurs via a "install-key" action (open to ideas)
>       - this is a weird case because the client is initially okay with touching the
>         private key, but thereafter wants it to be protected by the system.
>       - again, as with (2), ideally the key shows up in running as consequence
>         of the action, but a round-trip could also get it there.

/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 May  7 23:21:25 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06112014A; Tue,  7 May 2019 23:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zKKjeAJQMW8j; Tue,  7 May 2019 23:21:23 -0700 (PDT)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2C6120134; Tue,  7 May 2019 23:21:23 -0700 (PDT)
Received: by mail-it1-x130.google.com with SMTP id g71so2152237ita.5; Tue, 07 May 2019 23:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4j58fOYHrClmYK94QGDLpjLQ7AmsI03YqKwjVGMeaZo=; b=end91jnoC15BoLGesk297OPobhrOGxVMW8XSQ/jaSAPG8gNwCcDVfXQrUFA0664Ec8 geuZSSgkOassi3i9GuLLbPrENL/2SCxaiRbWN+eGjtvTW9gqCD9aYDAyAMcr9Kt9s8pv /s47rfoltgk74n6cKjGFrMqZtYYNwJW+v4QhahR1s5+TyVuYycNdb11f/iXT9P07xYu6 gd934nUauT0tbEmfI+f3bGpsdqaqYRABiezWOMQPJqC8GvaAzTtViEpq3WkazmOMzIGQ Goi5V4nwNRBIL16rT4WJULRqLYwuGnT4FSt8g/o393jU77ALc11M5eUinvslwqy2QcS0 fzNw==
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:content-transfer-encoding; bh=4j58fOYHrClmYK94QGDLpjLQ7AmsI03YqKwjVGMeaZo=; b=YN7twdQ0ArejB21Xkwo/SkRjX5HMAquP/ZymUH/Ukm2kFspv2ZtSj0g9Dg212ThIxn Pi5jTlrKWDcZZaXpQXUz4mBIix6pxZlDW8PMmhEBcSSyoDHs2wEnxKceYHmN9YXqjKM1 SY/VP3XTOBRdDyOFgIZwuNOHxXGfFbpeRo9ZPzfnVX77LYmQNaknY5iuNsHh896TG6Ir w8srxvrVlN+tLWMwrrFahhGCarEBSPHllL0s5hYtvbmAf8tz0RHY+lCEz7bgQRsGglmK R2W79GBe5z1+/5T8/ojV1p2+QzTCiTMYNzUdYegBDIQXQ2Nu1UA/GzYUBgNIyOYRNqjd lH1A==
X-Gm-Message-State: APjAAAUV2k6tKkAwHac4iCXyqYE/kpCiZdQVg7Nxfo7myLNpojFxOtLY EUvlwO4BJMLqAW6N/Ss4vNZdBS3mq0pgyGeHl2s=
X-Google-Smtp-Source: APXvYqyZ9mlpYlrerT2VPxlbORQe7EwJrU3z4S4eYSo60R7UjFSQbCAq8dsV2yYmdqoBDaZix7/5ZC4Bjwm/CL6mAXE=
X-Received: by 2002:a24:cd82:: with SMTP id l124mr2157139itg.164.1557296482202;  Tue, 07 May 2019 23:21:22 -0700 (PDT)
MIME-Version: 1.0
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>
In-Reply-To: <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>
From: Dhruv Dhody 
Date: Wed, 8 May 2019 11:50:45 +0530
Message-ID: 
To: Kent Watsen 
Cc: "Eric Voit (evoit)" , "rtg-dir@ietf.org" ,  "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" ,  "netconf@ietf.org" , Dhruv Dhody ,  "" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 06:21:24 -0000

Hi Kent, Eric,

Fine with me!

Thanks!
Dhruv

On Wed, May 8, 2019 at 3:19 AM Kent Watsen  wrote:
>
>
>
>  Based on my reading of your process suggestions Kent, I like best =
the =E2=80=9Cmention=E2=80=9D approach which you used for RFC-8071, Section=
 1.4.
>
> What I think could be done to cover this is:
>
> (A)  Remove Section 11: Notes to the RFC Editor
>
> (B)  Per Kent=E2=80=99s desire to also cover draft-ietf-netconf-restconf-=
notif, place the following statement into draft-ietf-netconf-subscribed-not=
ifications directly after Figure 10
>
> [RFC-5277] Section 2.2.1 states that a notification message is to be sent=
 to a subscriber which initiated a "create-subscription".   With this speci=
fication, this RFC-5277 statement should be more broadly interpreted to mea=
n that notification messages can also be sent to a subscriber which initiat=
ed an "establish-subscription", or a configured receiver which has been sen=
t a =E2=80=9Csubscription-started=E2=80=9D.
>
> Does this work for both of you?
>
>
> Works for me.
>
>
>
> The issue isn't consistency so much as meeting expectations, per `xml2rfc=
`, the document should have something like the following in the References =
section, which then auto-expands to the correct reference text, as well as =
defining the anchor "I-D.ietf-netconf-subscribed-notifications":
>
>         
>
>  That definitely makes things easier than what I have been doing.  =
I am hitting an xml2rfc error trying this right now, but I will get there.
>
>
> Yes, it was an eye-opener when I figured it out.   Be aware that, though =
some external sources (e.g., ITU standards) are supported, many are not, an=
d so hand-coding the  is still sometimes required...
>
>
> Kent // shepherd
>
>
>


From nobody Wed May  8 02:12:21 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A8F12008D; Wed,  8 May 2019 02:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMSdf6vBEmHJ; Wed,  8 May 2019 02:12:12 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70081.outbound.protection.outlook.com [40.107.7.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E6F12003E; Wed,  8 May 2019 02:12:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JR5EqEU0b5GKTY7Rm5pRmW2ipcJ31RcVp/2BoVyLEYQ=; b=PWw9h0Dsv1reeGr7PzTZ2HI9QqQMx5tv8cZxYxXTHZEtbCFTun/ihxSqRfN/FY9roKioYU1JcSSZhu1NhNwqDGnSqCRC2G2ESccUW+Yq2WNyU+dmO6nkOnKQ/szUoO1DHfLRVCu2XZNay4HZu5sXqmh4uLHYEibfPNRs7Dq5XHo=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2953.eurprd07.prod.outlook.com (10.168.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.11; Wed, 8 May 2019 09:12:07 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1878.019; Wed, 8 May 2019 09:12:07 +0000
From: Magnus Westerlund 
To: "Eric Voit (evoit)" , The IESG 
CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
Thread-Index: AQHVAOIY2D7aivy2PU25mAR0nTlyqA==
Date: Wed, 8 May 2019 09:12:06 +0000
Message-ID: 
References: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> <7efee2607c62458d865ce663f9d4fc27@XCH-RTP-013.cisco.com>  <4ac32da8a1544e26b9671f6f5e2bdf84@XCH-RTP-013.cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 670eba58-fb05-4de5-1a84-08d6d3953e87
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2953; 
x-ms-traffictypediagnostic: HE1PR0701MB2953:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(376002)(346002)(366004)(51444003)(51914003)(85664002)(199004)(189003)(6506007)(52536014)(99286004)(14454004)(6246003)(53546011)(33656002)(486006)(478600001)(4326008)(53946003)(53936002)(236005)(9686003)(54896002)(6306002)(66556008)(66946007)(64756008)(66476007)(66446008)(66066001)(73956011)(76116006)(2906002)(66574012)(15650500001)(7696005)(68736007)(966005)(71200400001)(71190400001)(476003)(76176011)(5660300002)(14444005)(256004)(55016002)(8936002)(8676002)(81156014)(81166006)(21615005)(6436002)(7736002)(26005)(606006)(44832011)(316002)(229853002)(54906003)(110136005)(25786009)(30864003)(186003)(446003)(86362001)(6116002)(74316002)(790700001)(3846002)(102836004)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2953; H:HE1PR0701MB2522.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: aALeID2h/q1ChMzjlOr3uaR71nPs6fb++Lfk9MiwM0kfVX8HbN5sv19XSZC8LxknWjMhJ2uvCNbtQ4ZtiJ6J/Fe6wQ/CIVrMvFRJOEkZvq6P9Zq5af4/Wj9GjOUJjldlfzA41JeY14+qClTM330DD8HMPA/FLJESHfLnhUrd/XFeZNqFnNOC68PqTsq8nTOSMrbxTLP5b+CPPsPRado2HNPPR/G5XkU+paa7sC7Hr+c2cLNBvLFY+2qIFQcimq+Y+FTowHBFyntFkKeUwV8BVQjS6yusgA70a5kf5J80ggo0j/xNxe+CydURqhTu0iLIOTxvPAvi/ey0zm+0bbz3EDYHcY/YdQV1VwBSu33I0TwOjo2BlhXxvp5cHAbW8jlus+nZ/mWsO06o+lfNoIWpaKzYKHzPjsg4cleZGLcVkvw=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522B58B5A59B46BBD5E163395320HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 670eba58-fb05-4de5-1a84-08d6d3953e87
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 09:12:06.9100 (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: HE1PR0701MB2953
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 09:12:17 -0000

--_000_HE1PR0701MB2522B58B5A59B46BBD5E163395320HE1PR0701MB2522_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 2019-05-07 21:22, Eric Voit (evoit) wrote:
Hi Magnus,

Thanks again for your thorough review on the overload aspect.   It is appre=
ciated.  Some thoughts/proposals back to you in-line..

From: Magnus Westerlund, May 7, 2019 8:50 AM

Hi Eric,

Thanks for the answers. I think we are making progress here, see below.

What I see is that there need to be some text changes in the QoS parts.

Regarding the priority I get the impression that it is not the WG's intenti=
on to clarify this. However, I would wish that the document is a bit more e=
xplicit about the lack of any interface to affect the publisher's action wh=
en it comes to dropping subscriptions. Yes there is this paragraph in Secti=
on 1.3:

   A publisher MAY terminate a dynamic subscription at any time.

   Similarly, it MAY decide to temporarily suspend the sending of

   notification messages for any dynamic subscription, or for one or

   more receivers of a configured subscription.  Such termination or

   suspension is driven by internal considerations of the publisher.



So I guess I have to drop this aspect now when the explicit reference to pr=
iority based actions are removed.



>  I agree it would be great to have a structure of subscription > ha=
ndling precedence on the publisher. However there are not any > solutions t=
hat I know of being discussed today. Building a model > here would be hard,=
 and would likely take quite a bit of time/effort. > It is primarily the ti=
me cost which is the biggest consideration at > this point. Since NETCONF g=
ot started on these subscription > specifications, Google=92s GNMI alternat=
ive has been introduced. > GNMI has fewer overload controls, yet has gained=
 industry traction. > Based on this, it doesn=92t seem like standardized ha=
ndling of > subscription precedence on a publisher is a market necessity ye=
t.

Understood. And I will most definitely not insist on a solution at this tim=
e. I was considering if there should be more word on that this is something=
 suitable for future extension, but I guess it does not provide any good be=
nefit.




On 2019-05-06 23:19, Eric Voit (evoit) wrote:

Hi Magnus,



Thanks very much for your comments.   Thoughts in-line...



From: Magnus Westerlund, May 2, 2019 8:25 AM



Magnus Westerlund has entered the following ballot position for

draft-ietf-netconf-subscribed-notifications-25: Discuss



When responding, please keep the subject line intact and reply to all email

addresses included in the To and CC lines. (Feel free to cut this introduct=
ory

paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notification=
s/







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

DISCUSS:

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



My focus when reviewing this document was from a perspective of how to

handle overload.



You are absolutely correct to focus on overload.  Mitigating different dime=
nsions of the overload risk has been a design goal since this effort=92s in=
ception.  And this is the reason a variety of QoS mechanisms were included =
in the document.



I have a hard time understanding how this will actually work,

especially in a fashion that preservers goodput and ensure what is consider=
ed

the most important subscriptions are delivered. Not having good undertandin=
g

into netconf and restconf don't hesitate to call out likely missunderstandi=
ng by

me and provide clarification and pointers.



Few of the mechanisms are specific to either RESTCONF or NETCONF.  For comp=
leteness reasons, let me summarize the overload mechanisms available...



1. The publisher is allowed to decline a dynamic subscription.  One of thes=
e reasons is that the incremental traffic generated by a particular increme=
ntal subscription will be too high.  There are errors back to the subscribe=
r indicating this condition exist.

2. A publisher can suspend any subscription for capacity reasons, and a rec=
eiver must be able to gracefully accept this suspension.

3. Much like with HTTP2 streams, higher priority subscriptions intended for=
 a particular receiver can be dequeued first from a publisher.

4. Much like with HTTP2 streams, proportional subscription dequeuing intend=
ed for a particular receiver can be performed a publisher.

5. DSCP markings can be placed on subscribed data.

6. Mechanisms for detecting and reacting to different types of subscribed d=
ata loss have been embedded.

7. Methods have been included to ensure a configured receiver =93ok=92s=94 =
information push before subscribed data is sent. (This should reduce one DD=
oS vector.)

8. Keep alive mechanisms are established for different transport types, so =
that subscribed data isn=92t being sent when the is no receiver listening.



Mechanisms (3) & (4) will likely be seen only with HTTP2 based transports.*=
   This is because (as documented within draft-ietf-netconf-restconf-notif =
section 4), these capabilities are to integrated directly HTTP2 RFC-7450 se=
ctions 5.3.1 & 5.3.2.

To me the big weakness of this mechanism are actually in the API between th=
e receiver and the publisher. The current API defined by this document does=
 not include any information that allow the receiver to express its actual =
view on priority for a subscription. It has some other tools that has compl=
etely different meanings namely:

- Transport level DSCP expressing PHB and routing priority

- Weight: Proportional bandwidth distribution

- Dependency: Deliver this only after this other subscription

None of this expresses anything related to the priority or importance to ma=
intain a particular subscription, nor does the interface carry any informat=
ion regarding what delivery requirements the receiver have on the subscript=
ion. Thus, the behavior in overload situation is going to be totally random=
.

So if the WG is okay with this being the case I will hold my nose. However,=
 I think the fact that random implementation dependent things will happen i=
n overload should be explicitly stated in the document.

 I think the documents reflect the state-of-the-art across industry p=
layers.  Attempting to layer-in something new which hasn=92t been considere=
d would be non-trivial.  But your intent should not be lost.  So to reflect=
 your request above, how about I add the following statement at the very en=
d of Section 2.3 QoS:

There are additional types over publisher capacity overload which this spec=
ification does not address within its scope. For example, the prioritizatio=
n of which subscriptions have precedence when the publisher CPU is overload=
ed is not discussed.  As a result, implementation choices will need to be m=
ade to address such considerations.

Does this work for you?

Yes.





* One background/review note...  Earlier versions of draft-ietf-netconf-sub=
scribed-notifications included specific parallels to RFC-7450 when describi=
ng (3) & (4).  However WG members wanted to abstract away what they felt we=
re HTTP2 specific references. This is despite the fact that what was being =
referenced was the desired functional behavior rather than anything HTTP2 s=
pecific.   I can understand the WG reviewers' concern.  This is already a l=
ong document, and a reader who only cares about NETCONF hopefully won't nee=
d to wade through complex issues which they are unlikely to worry about in =
deployment.

I did a brief look at the transports. They did not answer my questions when=
 I wrote this discuss. Also, to my understanding the HTTP/2 priority mechan=
ism is that is far from easy to use and also intended to distribute resourc=
es in an ongoing transmission. That doesn't actually match the higher level=
 need of determining which subscription are more important than another. Do=
esn't a 5 level priority value cover a lot of the missing ground here?

 Agree that the HTTP2 QoS mechanisms described do not address anythin=
g other than handling dequeuing congestion between a publisher and a receiv=
er as part of an ongoing transmission.  This actually is very relevant prob=
lem.  Early implementations of telemetry for SDN have many network element =
publishers pushing data to a few central data collectors.

Ok

Beyond this, I don=92t think the working group has ever considered a multi-=
level subscription priority mechanism.  I believe the problem to be a very =
hard one, even if there are just 5 levels (or two levels).

Ok. Just a suggestion and I agree that solution to this problem will have t=
o be in a future extension, if ever.

A) The QoS and priority sending mechanism discussed in 2.3 and furhter defi=
ned

by the YANG model.



I do want to raise the usage of the DSCP code point to a discuss. As the DS=
CP

defines different PHB and relative priorities in the router queues a DSCP v=
alue

does not provide the publisher any information about priority. I get the fe=
eling

from the text that this may be intended. If the only intention is to have t=
he

transport perform differential treatment in the network between the publish=
er

and the receiver



Yes, this is the case.



there are still more considerations are needed.

First of all I think these sentence needs a total rewrite:



   If the publisher supports the "dscp" feature, then a subscription

   with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP

   marking being placed within the IP header of any resulting

   notification messages and subscription state change notifications.

   Where TCP is used, a publisher which supports the "dscp" feature

   SHOULD ensure that a subscription's notification messages are

   returned within a single TCP transport session where all traffic

   shares the subscription's "dscp" leaf value.



I think one need to put a requriement on the transport to use a transport t=
hat

utilize the DSCP marking on its traffic.



I believe you are asking for a  the publisher respect the DSCP markings for=
 traffic egressing an interface on a publisher.  Yes this requirement was a=
ssumed, and can be explicitly added.

Please do.

 Section 2.3 QoS now says..

A publisher MUST respect the DSCP markings for subscription traffic egressi=
ng that publisher.

I think that work, but I like to see it in its full context.





Which for the current set of connection

oriented transport protocols, TCP, SCTP, and QUIC all currently only suppor=
t

using a single DSCP per connection. Implying multiple transport protocol

connections using a particular transport to enable this mapping.



Yes fully agree, a connection would be needed per DSCP.     Is your objecti=
on with the text above the words "SHOULD ensure" rather than "MUST ensure"?=
    If yes, I can ask the WG objects to whether this requirement should be =
a MUST.



If you think you should use RFC 2119 language, yes then I request a MUST.  =
However, I think reformulating this so state it as a fact that different DS=
CP code points requires different transport connections, unless a transport=
 supporting multiple DSCP simultanous are used (No standardized option that=
 has reliable object or stream semantics exist to my knowledge).

  Adding a statement of fact here is not an issue.  And thinking abou=
t your comment regarding RFC2119 language, I don=92t think RFC2119 language=
 is needed here.  So I have turned the =93SHOULD=94 into =93must=94.   This=
 results in the following proposed text:

Different DSCP code points require different transport connections.  As a r=
esult where TCP is used, a publisher which supports the "dscp" feature must=
 ensure that a subscription's notification messages are returned within a s=
ingle TCP transport session where all traffic shares the subscription's "ds=
cp" leaf value.

Does this work for you?

Yes.

Where TCP is used, a publisher which supports the "dscp" feature must ensur=
e that a subscription's notification messages are returned within a single =
TCP transport session where all traffic shares the subscription's "dscp" le=
af value.



A.2 Queuing model of a publisher.

With the DSCP and the Weight and dependency model I think it is important t=
o

clarify the model of the queueing in the publisher. So is the intention tha=
t several

subscriptions with different weights and possibly dependencies have their

individual queues that goes into a scheduler?



As you know, queuing models are non-trivial.   For that reason we wanted to=
 100% adopt the functional behavior RFC-7540 Section 5.3.1 and 5.3.2 withou=
t having to re-document/mirror that content at a higher level of the networ=
k stack.   We are a hoping that a reader of network subscriptions can look =
to well documented, implemented HTTP2 behaviors as applicable.  Providing a=
n intermediate layer of functional description could easily result in some =
mis-alignments from what is intended.

Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540 is=
 all within a single TCP connection. Thus, to avoid complexities I think yo=
u at least need to be explicit that one can only perform Dependency and Wei=
ght operations between subscriptions that share DSCP, and that they become =
independent queues.

 To cover this, are you ok with adding as a last sentence of Section =
2.3:

=93Dependency=94 and =93weight=94 parameters will only be respected and enf=
orced between subscriptions that share the same =93dscp=94 leaf value.

Yes, I think that clarifies the issue.

To avoid complex queue

interactions on this level I think there need to be seperate scheduler inst=
ances

per DSCP. I would also note that Dependency mechanism can't ensure that a

dependent stream arrive at receiver after the identified dependency if they=
 are

on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may not

even guarantee it within a single connection and same DSCP due to packet lo=
ss

impact. To me this model and what relationship one need to consider here ne=
ed

to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication =
of just the

importance of considering what is in the same dependency tree and what it

means to have different weighting. To conclude I think this needs a model

description and clearer definition and possibly requirements towards the

transport. Espceially if you actually need an in-order delivery requirement=
?



I think we have the same technical objective in mind.   And it is absolutel=
y the desire to have identical behavior to RFC-7540 Section 5.3.1 and 5.3.2=
.    For the current set of documents before the IESG, we include within dr=
aft-ietf-netconf-restconf-notif Section 4, a 1:1 mapping between draft-ietf=
-netconf-subscribed-notifications and RFC-7540.



We are hoping that the transport documents like draft-ietf-netconf-restconf=
-notif can be the place where such supporting documentation and mappings oc=
cur.

I still think that this document needs to have that sentence in their stati=
ng that Dependency and Weight applies only per subscription sharing DSCP va=
lue. Because these values are define on this document level, not on the map=
ping level that the individual transport exists on. And this is the interfa=
ce the WG have defined for this. And as it currently stands you appear to h=
ave something that lacks a clear meaning.

 Hopefully the last suggested text covers this.

Yes, it does.



B. The unpredictability of the circuit breaker overload mechanism.



My description of the overload handling in this document is that it is a ci=
rcuit

breaker based mechanism that can blow a fuse on subscriptions that it fails=
 to

honor in overload situations. What worries me deply is the total unpredicta=
bility

of this mechanism.



At the beginning of this email, there are eight methods of overflow handlin=
g listed.  We optimized these eight mechanisms for different failure scenar=
ios and congestion conditions.   Our goal was to depend on existing mechani=
sms/technologies wherever possible.  Reuse of existing mechanisms should re=
duce at least some of the unpredictability.



First, is it the intention to derive what subscriptions are least important=
 from the

DSCP, weighting and Dependency parameters? If it is, I think that may be a

misstake as priority on what subscriptions are most important to retain are=
 not

necessarily reflected in their QoS parameters.



At this point the document does not attempt to define "important".  All tha=
t is done is to provide guidance relating to some elements of network trans=
port.   If there is a dimension of "importance" which an implementer would =
like to layer onto this solution, it could be done.  For example, "importan=
ce" could applied in areas such as what subscriptions should be suspended  =
in case of CPU exhaust.   However guidance on such enhancements are not inc=
luded in this document.

Still it is both implied and explicitly stated in one place.

 Hopefully the changes suggested above cover this concern.

Yes, I think it is sufficiently well handled.




Secondly, what are the values when a subscription are considered to be to h=
eavy

or not be handled accordingly. Are there any parameter sets that actually

describe what SLA the subscriber expect that can be converted into timeout

timers or buffer depth thresholds to indicate that publisher side isn't del=
ivering

these in time?



There is no guidance on this provided in the document.   As equipment types=
, subscription volumes, available memory, will vary between solutions, this=
 will take a while to dimension properly.  I can imagine someday that we mi=
ght have something like "Erlang for subscriptions" much like we used Erlang=
s in the old telephony network to dimension call handling capabilities of p=
hone switches.  But we are a long way from that.

To be clear what I mean with SLA here is to express some boundaries on when=
 the subscribed to information will be received by the receiver compared to=
 when it come to existence on the publisher side. However, I do hear you th=
at there is nothing defined and nothing in the pipeline.

 Understood.  We simply don=92t have anything.





Third, I what I understand there are no any additional back pressure mechan=
ism

between the receiver and the publisher than the transport protocols flow

control? So a receiver that is not keeping up processing the data it proces=
s will

not read out the data out of the flow controlled buffers in the receiver an=
d thus

prevent the publisher to write to the transport conncetion, thus causing th=
e

publisher to eventually trigger a suspension due to its queue build up?



There is nothing beyond transport flow control.  We thought about it initia=
lly, but we were not ready to pick up even more complexity than we already =
had.

Ok, which just contribute to what I call random things happen at overload.

 agree





To my understanding the current mechanism places all subscriptions on the

same importance and with the same SLA. Thus likely causing short term overl=
oad

situations to cause subscription suspensions in random subscriptions. Is th=
e WG

fine with this type of randomness occuring and expecting that normally ther=
e

will be such amount of overprovisioning that being able to indicate priorit=
y and

SLA are overkill?



Yes.   We needed a starting point.  And there are technical solutions which=
 can be layered on top.   But what we have now took many years to finalize,=
 and should be a big enough technical jump considering our current knowledg=
e.



At a minimal a change of this sentence in Section 2.5.1 is needed:



  This could

   be for reasons of an unexpected but sustained increase in an event

   stream's event records, degraded CPU capacity, a more complex

   referenced filter, or other higher priority subscriptions which have

   usurped resources.



I have removed "higher priority".

Thanks.





As it states that subscriptions has priorities without reference to a mecha=
nism

that provides that priority.



C. 2.4.5.  Killing a Dynamic Subscription



   The "kill-subscription" operation permits an operator to end a

   dynamic subscription which is not associated with the transport

   session used for the RPC.  A publisher MUST terminate any dynamic

   subscription identified by the "id" parameter in the RPC request, if

   such a subscription exists.



Can someone please clarify the use case for this functionality. To my

understanding it allows another receiver given authority to kill the subscr=
iption

being delivered to another receiver. Based on the otherwise rather strict t=
hat all

manipulations of dynamic subscriptions happens from the transport session

context that established it I want to better understand the use case it app=
ears

out place.



A network operator needs a very secure mechanism to end a dynamic subscript=
ion in progress which it sees as harmful.   The operator cannot do this via=
 configuration operations, as the dynamic subscription is not configured (a=
nd therefore cannot be deleted in the configuration datastore).

Thanks, that clarification resolves my question mark. So lets close this is=
sue without any actions.





D. The Requirements on a transport supporting Configured Subscriptions

Reading through Section 2.5 I arrived at a number of questions. I tried to

understand what the requirements are for the transport that supports

Configured Subscriptions. I did note that neither draft-ietf-netconf-restco=
nf-

notif-13 nor

draft-ietf-netconf-netconf-event-notifications-17 supports configured

subscriptions. Thus, there appear no template for a solution either, or doe=
s

there exist another document that is being worked on defining such a transp=
ort?



This is the case.   Originally both of those documents *did* include config=
ured subscriptions.  However within the WG there was a decision not to prog=
ress configured subscriptions yet.  One reason is that other YANG model dra=
fts moving in the NETCONF WG were seen as pre-requisites for securely creat=
ing transport sessions via call home for the configured subscriptions.  As =
a result, support for configured subscriptions was extracted from those tra=
nsport documents.   It is expected that that updated versions of just those=
 transport documents will be driven when the YANG models complete.

Look at the responses below I see that we are in one of these situation whe=
re things are deliberately left open. I will simply assume that this is don=
e in a way that supports those future definitions and clarifications. So le=
ts close this issue without any actions.



Questions that arose for me related to Configured Susbription Transport whe=
re

the following: 1. Can Transport Session be initiated in both direction. RFC

8071 provides a solution for Publisher to Receiver initiation. It is unclea=
r if all

parts are in place to have a receiver to publisher initiated transport to b=
e bound

to the subscription.



This will be up to a specific transport draft to make this determination.



To see what might be viable for NETCONF, check out the earlier version of t=
he document at:

https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notificat=
ions/10/



This was seen as a complete version of such a solution.  However the WG wan=
ted a YANG model for session parameters discussed in Section 5.2.



2. What is "name" really? It appears to be defined as an

empty container. Despite that it appears to have requirements on being both=
 a

security identity as well as network address.



You are correct.  In previous versions of this draft, a receiver was identi=
fied by the combination of address + port.  However due to the YANG doctor =
reviews, and call home discussions referenced above, the WG wasn't ready to=
 finalize this YANG structure.  The compromise was the current structure, p=
lus the example YANG model of Appendix A to show how this might be built ou=
t.



3. In Figure 9, which is stated to be

for the receiver. What information does the receiver use to determine the

transition (d)? And what does it do in this step. Related to Discuss part B=
).



This determination is implementation specific.



4. RFC

8071 appears to lack any considerations for how often and how many times it

attempts to connect to the receiver. So applying that mechanism appears to

require some usage guidance to avoid causing overload situations or DoS

potential by misconfiguring network devices with this soltution to dial out

frequently to a target.



As the transport solution requirements are not detail it is actually hard t=
o

determine if there are short comings in the description in Section 2.5 and =
the

corresponding YANG model. Is it an reasonable request to document these

requirements?



The requirements were documented for both NETCONF and RESTCONF.   However t=
hese requirements were removed when the WG decided to wait until there was =
a YANG model for RFC-8071 ready to go to the IESG.   For a preview on what =
these requirements might look like, I refer you  to Section 5.2 of

https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notificat=
ions/10/

Thanks, so this is clearly something to have in mind when the WG do get to =
specify a solution for this. So I don't see a need for any actions here.





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

COMMENT:

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



1. Section 2.3: DSCP domains

I think the text could benefit from pointing out that the subscriber actual=
ly needs

to know what the DSCP values represents in the diffserv domain of the publi=
sher.

As these could be different, they also create an interesting problems for

transports of how they establish a transport connection that uses a particu=
lar

DSCP, as the receiver if initiating need to know the local DSCP value that

corresponds to the behavior in the publisher's domain.



This makes sense.



I have added in Section 5.3 Transport Requirements a new entry which states=
:



"A subscriber which includes a "dscp" leaf within an "establish-subscriptio=
n" request will need to understand and consider what the corresponding DSCP=
 value represents within the domain of the publisher."



Let me know if this is not sufficient.



2. In general I think there are more than one description that are fuzzy ab=
out if it

describes a publisher or receiver action/requirement.



It would be great if you have some specifics.   The authors and previous re=
viewers likely have looked at this often enough where things look obvious w=
hich perhaps are not.

Sorry, didn't take note about those confusion.

 Magnus, once again your comments are thoughtful and appreciated.  Th=
anks for taking such a good look at this document.

Good, I will await the updated document, but I expect to be able to clear w=
ith the changes discussed here.

Cheers


Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB2522B58B5A59B46BBD5E163395320HE1PR0701MB2522_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







On 2019-05-07 21:22, Eric Voit (evoit) wrote=
:










Hi Magnus,


 


Thanks again for your thorough review on the overload aspect.&nb=
sp;  It is appreciated.  Some thoughts/proposals
 back to you in-line..


 




From:=
 Magnus Westerlund, May 7, 2019 8:50 AM







Hi Eric,






 






Thanks for the answers. I think we are making progre=
ss here, see below.







 






What I see is that there need to be some text change=
s in the QoS parts.







 






Regarding the priority I get the impression that it =
is not the WG's intention to clarify this. However, I would wish that the d=
ocument is a bit more explicit about the lack of any interface to affect th=
e publisher's action when it comes
 to dropping subscriptions. Yes there is this paragraph in Section 1.3: 






   A publisher MAY terminate a dynamic subscription at =
any time.


   Similarly, it MAY decide to temporarily suspend the sendi=
ng of


   notification messages for any dynamic subscription, or fo=
r one or


   more receivers of a configured subscription.  Such t=
ermination or


   suspension is driven by internal considerations of the pu=
blisher.


 


So I guess I have to drop this aspect now when the explicit reference =
to priority based actions are removed.


 









> &l=
t;eric> I agree it would be great to have a structure of subscription &g=
t; handling precedence on the publisher. However there are not any > sol=
utions that I know of being discussed today. Building
 a model > here would be hard, and would likely take quite a bit of time=
/effort. > It is primarily the time cost which is the biggest considerat=
ion at > this point. Since NETCONF got started on these subscription >=
; specifications, Google=92s GNMI alternative
 has been introduced. > GNMI has fewer overload controls, yet has gained=
 industry traction. > Based on this, it doesn=92t seem like standardized=
 handling of > subscription precedence on a publisher is a market necess=
ity yet.


Understood. And I will most definitely not insist on a solution at this =
time. I was considering if there should be more word on that this is someth=
ing suitable for future extension, but I guess it does not provide any good=
 benefit.


















 






 






On 2019-05-06 23:19, Eric Voit (evoit) wrote:






Hi Magnus,


 


Thanks very much for your comments.   Thoughts in-line...


 




From: Magnus Westerlund, May 2, 2019 8:25 AM


 


Magnus Westerlund has entered the following ballot position for


draft-ietf-netconf-subscribed-notifications-25: Discuss

 


When responding, please keep the subject line intact and reply to all =
email


addresses included in the To and CC lines. (Feel free to cut this intr=
oductory


paragraph, however.)


 


 


Please refer to https://www.ietf.org/iesg/statemen=
t/discuss-criteria.html


for more information about IESG DISCUSS and COMMENT positions.


 


 


The document, along with other ballot positions, can be found here:


https://datatracker.ietf.org/d=
oc/draft-ietf-netconf-subscribed-notifications/


 


 


 


----------------------------------------------------------------------=



DISCUSS:


----------------------------------------------------------------------=



 


My focus when reviewing this document was from a perspective of how to=



handle overload. 




 


You are absolutely correct to focus on overload.  Mitigating diff=
erent dimensions of the overload risk has been a design goal since this eff=
ort=92s inception.  And this is the reason a variety of QoS mechanisms=
 were included in the document.


 




I have a hard time understanding how this will actually work,


especially in a fashion that preservers goodput and ensure what is con=
sidered


the most important subscriptions are delivered. Not having good undert=
anding


into netconf and restconf don't hesitate to call out likely missunders=
tanding by


me and provide clarification and pointers.




 


Few of the mechanisms are specific to either RESTCONF or NETCONF. =
; For completeness reasons, let me summarize the overload mechanisms availa=
ble...


 


1. The publisher is allowed to decline a dynamic subscription.  O=
ne of these reasons is that the incremental traffic generated by a particul=
ar incremental subscription will be too high.  There are errors back t=
o the subscriber indicating this condition exist.


2. A publisher can suspend any subscription for capacity reasons, and =
a receiver must be able to gracefully accept this suspension. 

3. Much like with HTTP2 streams, higher priority subscriptions intende=
d for a particular receiver can be dequeued first from a publisher. 


4. Much like with HTTP2 streams, proportional subscription dequeuing i=
ntended for a particular receiver can be performed a publisher.<=
/pre>

5. DSCP markings can be placed on subscribed data.


6. Mechanisms for detecting and reacting to different types of subscri=
bed data loss have been embedded.


7. Methods have been included to ensure a configured receiver =93ok=92=
s=94 information push before subscribed data is sent. (This should reduce o=
ne DDoS vector.) 


8. Keep alive mechanisms are established for different transport types=
, so that subscribed data isn=92t being sent when the is no receiver listen=
ing.


 


Mechanisms (3) & (4) will likely be seen only with HTTP2 based tra=
nsports.*   This is because (as documented within draft-ietf-netc=
onf-restconf-notif section 4), these capabilities are to integrated directl=
y HTTP2 RFC-7450 sections 5.3.1 & 5.3.2.   




To me the big weakness of this mechanism are actually in the API between=
 the receiver and the publisher. The current API defined by this document d=
oes not include any information that allow the receiver to express its actu=
al view on priority for a subscription.
 It has some other tools that has completely different meanings namely:


- Transport level DSCP expressing PHB and routing priority

- Weight: Proportional bandwidth distribution


- Dependency: Deliver this only after this other subscription=



None of this expresses anything related to the priority or importance to=
 maintain a particular subscription, nor does the interface carry any infor=
mation regarding what delivery requirements the receiver have on the subscr=
iption. Thus, the behavior in overload
 situation is going to be totally random. 


So if the WG is okay with this being the case I will hold my nose. Howev=
er, I think the fact that random implementation dependent things will happe=
n in overload should be explicitly stated in the document.



<eric&=
gt; I think the documents reflect the state-of-the-art across industry play=
ers.  Attempting to layer-in something new
 which hasn=92t been considered would be non-trivial.  <=
span style=3D"color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style=
-textfill-fill-alpha:100.0%">But your inte=
nt should not be lost.  So to reflect your
 request above, how about I add the following statement at the very end of =
Section 2.3 QoS:


There are additio=
nal types over publisher capacity overload which this specification does no=
t
 address within its scope. For example, the prioritization of which subscri=
ptions have precedence when the publisher CPU is overloaded is not discusse=
d.  As a result, implementation choices will need to be made to addres=
s such considerations.


Does this=
 work for you?








Yes. 














 


 


* One background/review note...  Earlier versions of draft-ietf-n=
etconf-subscribed-notifications included specific parallels to RFC-7450 whe=
n describing (3) & (4).  However WG members wanted to abstract awa=
y what they felt were HTTP2 specific references. This is despite the fact t=
hat what was being referenced was the desired functional behavior rather th=
an anything HTTP2 specific.   I can understand the WG reviewers' =
concern.  This is already a long document, and a reader who only cares=
 about NETCONF hopefully won't need to wade through complex issues which th=
ey are unlikely to worry about in deployment.




I did a brief look at the transports. They did not answer my questions w=
hen I wrote this discuss. Also, to my understanding the HTTP/2 priority mec=
hanism is that is far from easy to use and also intended to distribute reso=
urces in an ongoing transmission.
 That doesn't actually match the higher level need of determining which sub=
scription are more important than another. Doesn't a 5 level priority value=
 cover a lot of the missing ground here?



<eric&=
gt; Agree that the HTTP2 QoS mechanisms described do not address anything o=
ther than handling dequeuing congestion between
 a publisher and a receiver as part of an ongoing transmission.  This =
actually is very relevant problem.  Early implementations of telemetry=
 for SDN have many network element publishers pushing data to a few central=
 data collectors. 









Ok












Beyond th=
is, I don=92t think the working group has ever considered a multi-level sub=
scription priority mechanism.  I believe
 the problem to be a very hard one, even if there are just 5 levels (or two=
 levels).







Ok. Just a suggestion and I agree that solution to this problem will have t=
o be in a future extension, if ever.















A) The QoS and priority sending mechanism discussed in 2.3 and furhter=
 defined


by the YANG model.


 


I do want to raise the usage of the DSCP code point to a discuss. As t=
he DSCP


defines different PHB and relative priorities in the router queues a D=
SCP value


does not provide the publisher any information about priority. I get t=
he feeling


from the text that this may be intended. If the only intention is to h=
ave the


transport perform differential treatment in the network between the pu=
blisher


and the receiver 




 


Yes, this is the case.


 




there are still more considerations are needed.


First of all I think these sentence needs a total rewrite:<=
/pre>

 


   If the publisher supports the "dscp" feature, t=
hen a subscription


   with a "dscp" leaf MUST result in a correspondi=
ng [RFC2474] DSCP


   marking being placed within the IP header of any resultin=
g


   notification messages and subscription state change notif=
ications.


   Where TCP is used, a publisher which supports the "d=
scp" feature


   SHOULD ensure that a subscription's notification messages=
 are


   returned within a single TCP transport session where all =
traffic


   shares the subscription's "dscp" leaf value.


 


I think one need to put a requriement on the transport to use a transp=
ort that


utilize the DSCP marking on its traffic. 




 


I believe you are asking for a  the publisher respect the DSCP ma=
rkings for traffic egressing an interface on a publisher.  Yes this re=
quirement was assumed, and can be explicitly added.




Please do. 


<eric&=
gt; Section 2.3 QoS now says..


A publisher MUST =
respect the DSCP markings for subscription traffic egressing that publisher=
.








I think that work, but I like to see it in its full context.














 


 




Which for the current set of connection


oriented transport protocols, TCP, SCTP, and QUIC all currently only s=
upport


using a single DSCP per connection. Implying multiple transport protoc=
ol


connections using a particular transport to enable this mapping.<=
/o:p>




 


Yes fully agree, a connection would be needed per DSCP.  &nb=
sp;  Is your objection with the text above the words "SHOULD ensu=
re" rather than "MUST ensure"?    If yes, I c=
an ask the WG objects to whether this requirement should be a MUST.




 


If you think you should use RFC 2119 language, yes then I request a MUST=
. 
However, I think reformulating this so state it as a fact that diffe=
rent DSCP code points requires different transport connections, unless a tr=
ansport supporting multiple DSCP simultanous are used (No standardized opti=
on that has reliable object or stream
 semantics exist to my knowledge). 


<eric&=
gt;  Adding a statement of fact here is not an issue. 
And thinking about your comment regarding RFC2119 language, I don=92t thi=
nk RFC2119 language is needed here.  So
 I have turned the =93SHOULD=94 into =93must=94.   =
This results=
 in the following proposed text=
:


Different DSCP co=
de points require different transport connections.  As a result where =
TCP is
 used, a publisher which supports the "dscp" feature must ensure =
that a subscription's notification messages are returned within a single TC=
P transport session where all traffic shares the subscription's "dscp&=
quot; leaf value.


Does this=
 work for you?








Yes. 














Where TCP i=
s used, a publisher which supports the "dscp" feature must ensure=
 that a subscription's notification messages are returned within a single T=
CP transport session where all traffic shares the subscription's "dscp=
" leaf value.


 




A.2 Queuing model of a publisher.


With the DSCP and the Weight and dependency model I think it is import=
ant to


clarify the model of the queueing in the publisher. So is the intentio=
n that several


subscriptions with different weights and possibly dependencies have th=
eir


individual queues that goes into a scheduler?




 


As you know, queuing models are non-trivial.   For that reas=
on we wanted to 100% adopt the functional behavior RFC-7540 Section 5.3.1 a=
nd 5.3.2 without having to re-document/mirror that content at a higher leve=
l of the network stack.   We are a hoping that a reader of networ=
k subscriptions can look to well documented, implemented HTTP2 behaviors as=
 applicable.  Providing an intermediate layer of functional descriptio=
n could easily result in some mis-alignments from what is intended.




Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540=
 is all within a single TCP connection. Thus, to avoid complexities I think=
 you at least need to be explicit that one can only perform Dependency and =
Weight operations between subscriptions
 that share DSCP, and that they become independent queues. 


<eric&=
gt; To cover this, are you ok with adding as a last sentence of Section 2.3=
:


=93Dependency=94 =
and =93weight=94 parameters will only be respected and enforced between sub=
scriptions
 that share the same =93dscp=94 leaf value.








Yes, I think that clarifies the issue. 
















To avoid complex queue


interactions on this level I think there need to be seperate scheduler=
 instances


per DSCP. I would also note that Dependency mechanism can't ensure tha=
t a


dependent stream arrive at receiver after the identified dependency if=
 they are


on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may=
 not


even guarantee it within a single connection and same DSCP due to pack=
et loss


impact. To me this model and what relationship one need to consider he=
re need


to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indica=
tion of just the


importance of considering what is in the same dependency tree and what=
 it


means to have different weighting. To conclude I think this needs a mo=
del


description and clearer definition and possibly requirements towards t=
he


transport. Espceially if you actually need an in-order delivery requir=
ement?




 


I think we have the same technical objective in mind.   And =
it is absolutely the desire to have identical behavior to RFC-7540 Section =
5.3.1 and 5.3.2.    For the current set of documents before =
the IESG, we include within draft-ietf-netconf-restconf-notif Section 4, a =
1:1 mapping between draft-ietf-netconf-subscribed-notifications and RFC-754=
0.    


 


We are hoping that the transport documents like draft-ietf-netconf-res=
tconf-notif can be the place where such supporting documentation and mappin=
gs occur.  




I still think that this document needs to have that sentence in their st=
ating that Dependency and Weight applies only per subscription sharing DSCP=
 value. Because these values are define on this document level, not on the =
mapping level that the individual
 transport exists on. And this is the interface the WG have defined for thi=
s. And as it currently stands you appear to have something that lacks a cle=
ar meaning.



<eric&=
gt; Hopefully the last suggested text covers this.







Yes, it does. 












 




B. The unpredictability of the circuit breaker overload mechanism.


 


My description of the overload handling in this document is that it is=
 a circuit


breaker based mechanism that can blow a fuse on subscriptions that it =
fails to


honor in overload situations. What worries me deply is the total unpre=
dictability


of this mechanism.




 


At the beginning of this email, there are eight methods of overflow ha=
ndling listed.  We optimized these eight mechanisms for different fail=
ure scenarios and congestion conditions.   Our goal was to depend=
 on existing mechanisms/technologies wherever possible.  Reuse of exis=
ting mechanisms should reduce at least some of the unpredictability.


 




First, is it the intention to derive what subscriptions are least impo=
rtant from the


DSCP, weighting and Dependency parameters? If it is, I think that may =
be a


misstake as priority on what subscriptions are most important to retai=
n are not


necessarily reflected in their QoS parameters.




 


At this point the document does not attempt to define "important&=
quot;.  All that is done is to provide guidance relating to some eleme=
nts of network transport.   If there is a dimension of "impo=
rtance" which an implementer would like to layer onto this solution, i=
t could be done.  For example, "importance" could applied in=
 areas such as what subscriptions should be suspended  in case of CPU =
exhaust.   However guidance on such enhancements are not included=
 in this document.




Still it is both implied and explicitly stated in one place. =



<eric&=
gt; Hopefully the changes suggested above cover this concern.











Yes, I think it is sufficiently well handled.  



















 




Secondly, what are the values when a subscription are considered to be=
 to heavy


or not be handled accordingly. Are there any parameter sets that actua=
lly


describe what SLA the subscriber expect that can be converted into tim=
eout


timers or buffer depth thresholds to indicate that publisher side isn'=
t delivering


these in time?




 


There is no guidance on this provided in the document.   As =
equipment types, subscription volumes, available memory, will vary between =
solutions, this will take a while to dimension properly.  I can imagin=
e someday that we might have something like "Erlang for subscriptions&=
quot; much like we used Erlangs in the old telephony network to dimension c=
all handling capabilities of phone switches.  But we are a long way fr=
om that. 




To be clear what I mean with SLA here is to express some boundaries on w=
hen the subscribed to information will be received by the receiver compared=
 to when it come to existence on the publisher side. However, I do hear you=
 that there is nothing defined and
 nothing in the pipeline. 


<eric&=
gt; Understood.  We simply don=92t have anything.




 


 




Third, I what I understand there are no any additional back pressure m=
echanism


between the receiver and the publisher than the transport protocols fl=
ow


control? So a receiver that is not keeping up processing the data it p=
rocess will


not read out the data out of the flow controlled buffers in the receiv=
er and thus


prevent the publisher to write to the transport conncetion, thus causi=
ng the


publisher to eventually trigger a suspension due to its queue build up=
?




 


There is nothing beyond transport flow control.  We thought about=
 it initially, but we were not ready to pick up even more complexity than w=
e already had.




Ok, which just contribute to what I call random things happen at overloa=
d. 



<eric&=
gt; agree




 


 




To my understanding the current mechanism places all subscriptions on =
the


same importance and with the same SLA. Thus likely causing short term =
overload


situations to cause subscription suspensions in random subscriptions. =
Is the WG


fine with this type of randomness occuring and expecting that normally=
 there


will be such amount of overprovisioning that being able to indicate pr=
iority and


SLA are overkill?




 


Yes.   We needed a starting point.  And there are techn=
ical solutions which can be layered on top.   But what we have no=
w took many years to finalize, and should be a big enough technical jump co=
nsidering our current knowledge.


 




At a minimal a change of this sentence in Section 2.5.1 is needed:


 


  This could


   be for reasons of an unexpected but sustained increase in=
 an event


   stream's event records, degraded CPU capacity, a more com=
plex


   referenced filter, or other higher priority subscriptions=
 which have


   usurped resources.




 


I have removed "higher priority".




Thanks.




 


 




As it states that subscriptions has priorities without reference to a =
mechanism


that provides that priority.


 


C. 2.4.5.  Killing a Dynamic Subscription


 


   The "kill-subscription" operation permits an op=
erator to end a


   dynamic subscription which is not associated with the tra=
nsport


   session used for the RPC.  A publisher MUST terminat=
e any dynamic


   subscription identified by the "id" parameter i=
n the RPC request, if


   such a subscription exists.


 


Can someone please clarify the use case for this functionality. To my<=
o:p>


understanding it allows another receiver given authority to kill the s=
ubscription


being delivered to another receiver. Based on the otherwise rather str=
ict that all


manipulations of dynamic subscriptions happens from the transport sess=
ion


context that established it I want to better understand the use case i=
t appears


out place.




 


A network operator needs a very secure mechanism to end a dynamic subs=
cription in progress which it sees as harmful.   The operator can=
not do this via configuration operations, as the dynamic subscription is no=
t configured (and therefore cannot be deleted in the configuration datastor=
e).  




Thanks, that clarification resolves my question mark. So lets close this=
 issue without any actions.





 


 




D. The Requirements on a transport supporting Configured Subscriptions=



Reading through Section 2.5 I arrived at a number of questions. I trie=
d to


understand what the requirements are for the transport that supports


Configured Subscriptions. I did note that neither draft-ietf-netconf-r=
estconf-


notif-13 nor


draft-ietf-netconf-netconf-event-notifications-17 supports configured<=
o:p>


subscriptions. Thus, there appear no template for a solution either, o=
r does


there exist another document that is being worked on defining such a t=
ransport?




 


This is the case.   Originally both of those documents *did*=
 include configured subscriptions.  However within the WG there was a =
decision not to progress configured subscriptions yet.  One reason is =
that other YANG model drafts moving in the NETCONF WG were seen as pre-requ=
isites for securely creating transport sessions via call home for the confi=
gured subscriptions.  As a result, support for configured subscription=
s was extracted from those transport documents.   It is expected =
that that updated versions of just those transport documents will be driven=
 when the YANG models complete.




Look at the responses below I see that we are in one of these situation =
where things are deliberately left open. I will simply assume that this is =
done in a way that supports those future definitions and clarifications. So=
 lets close this issue without any
 actions. 




 




Questions that arose for me related to Configured Susbription Transpor=
t where


the following: 1. Can Transport Session be initiated in both direction=
. RFC


8071 provides a solution for Publisher to Receiver initiation. It is u=
nclear if all


parts are in place to have a receiver to publisher initiated transport=
 to be bound


to the subscription. 




 


This will be up to a specific transport draft to make this determinati=
on.  


 


To see what might be viable for NETCONF, check out the earlier version=
 of the document at:


https://datatracker.ietf=
.org/doc/draft-ietf-netconf-netconf-event-notifications/10/ =



 


This was seen as a complete version of such a solution.  However =
the WG wanted a YANG model for session parameters discussed in Section 5.2.=



 




2. What is "name" really? It appears to be defined as an


empty container. Despite that it appears to have requirements on being=
 both a


security identity as well as network address. 




 


You are correct.  In previous versions of this draft, a receiver =
was identified by the combination of address + port.  However due =
to the YANG doctor reviews, and call home discussions referenced above, the=
 WG wasn't ready to finalize this YANG structure.  The compromise was =
the current structure, plus the example YANG model of Appendix A to show ho=
w this might be built out.


 




3. In Figure 9, which is stated to be


for the receiver. What information does the receiver use to determine =
the


transition (d)? And what does it do in this step. Related to Discuss p=
art B). 




 


This determination is implementation specific.


 




4. RFC


8071 appears to lack any considerations for how often and how many tim=
es it


attempts to connect to the receiver. So applying that mechanism appear=
s to


require some usage guidance to avoid causing overload situations or Do=
S


potential by misconfiguring network devices with this soltution to dia=
l out


frequently to a target.


 


As the transport solution requirements are not detail it is actually h=
ard to


determine if there are short comings in the description in Section 2.5=
 and the


corresponding YANG model. Is it an reasonable request to document thes=
e


requirements?




 


The requirements were documented for both NETCONF and RESTCONF. &=
nbsp; However these requirements were removed when the WG decided to wait u=
ntil there was a YANG model for RFC-8071 ready to go to the IESG. &nbs=
p; For a preview on what these requirements might look like, I refer you&nb=
sp; to Section 5.2 of 


https://datatracker.ietf=
.org/doc/draft-ietf-netconf-netconf-event-notifications/10/<=
/pre>



Thanks, so this is clearly something to have in mind when the WG do get =
to specify a solution for this. So I don't see a need for any actions here.





 


 




----------------------------------------------------------------------=



COMMENT:


----------------------------------------------------------------------=



 


1. Section 2.3: DSCP domains


I think the text could benefit from pointing out that the subscriber a=
ctually needs


to know what the DSCP values represents in the diffserv domain of the =
publisher.


As these could be different, they also create an interesting problems =
for


transports of how they establish a transport connection that uses a pa=
rticular


DSCP, as the receiver if initiating need to know the local DSCP value =
that


corresponds to the behavior in the publisher's domain.



 


This makes sense.  


 


I have added in Section 5.3 Transport Requirements a new entry which s=
tates:


 


"A subscriber which includes a "dscp" leaf within an &q=
uot;establish-subscription" request will need to understand and consid=
er what the corresponding DSCP value represents within the domain of the pu=
blisher."


 


Let me know if this is not sufficient.


 




2. In general I think there are more than one description that are fuz=
zy about if it


describes a publisher or receiver action/requirement.




 


It would be great if you have some specifics.   The authors =
and previous reviewers likely have looked at this often enough where things=
 look obvious which perhaps are not.




Sorry, didn't take note about those confusion.


<eric&=
gt; Magnus, once again your comments are thoughtful and appreciated.  =
Thanks for taking such a good look at this document.








Good, I will await the updated document, but I expect to be able to clea=
r with the changes discussed here.




Cheers

=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522B58B5A59B46BBD5E163395320HE1PR0701MB2522_--


From nobody Wed May  8 06:33:18 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960901200F6 for ; Wed,  8 May 2019 06:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIt_Jg8vViPY for ; Wed,  8 May 2019 06:33:14 -0700 (PDT)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (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 62680120058 for ; Wed,  8 May 2019 06:33:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:Mime-Version:Reply-To:Message-Id: Date:Subject:To:From:Sender:Cc: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=P0m5W860kxPUJUcLr8Cv0QXAQrzJFHRec7mTcCcV8lA=; b=KjcdTk7TUAxabeL9uQYqixg6d1 MPsJ4YZT0HzUUcktZ5ERYiBLEc0wCyOYqcBvghX6xIc3skPNCtYbR8pQsEblSZEojgSgoTQbkTsGw UJZGRPlPxW3DW/cpIpIKe9YBJP8VTlw0QtOw6WzqlLWquEUpPJZIgqI/E45pe++K8SZpjWp2StpQo Y17Q06SVbwWn28cxzHncsAtNisE5xVLcu8QnGAA2lryPTe/InpF+n9IuvLi4p1GPmfBjfa8uvLvRx eqEtsd4A6bUo9+RsMhg9ANAf4lE4yZRUNdf5mlFRUXVCVqvX/jl/DY19o0QpmJ81108omTqGtOW1A LwGZVQpA==;
Received: from [51.52.247.166] (port=63261 helo=[172.16.3.14]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hOMh5-00073z-Nh for netconf@ietf.org; Wed, 08 May 2019 14:33:11 +0100
From: "Jonathan Hansford" 
To: "netconf@ietf.org" 
Date: Wed, 08 May 2019 13:33:10 +0000
Message-Id: 
Reply-To: "Jonathan Hansford" 
User-Agent: eM_Client/7.2.34959.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB3FAEA49A-BB4E-4CAA-97B1-D65FB7407C58"
X-Antivirus: Avast (VPS 190508-0, 08/05/2019), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 13:33:17 -0000

--------=_MB3FAEA49A-BB4E-4CAA-97B1-D65FB7407C58
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

In RFC 6241:

Section 8.4.1 states "If the session issuing the confirmed commit is 
terminated for any reason before the confirm timeout expires, the server 
MUST restore the configuration to its state before the confirmed commit 
was issued, unless the confirmed commit also  included a  
element."

Section 8.4.5.1 states the persist parameter makes "the confirmed commit 
survive a session termination".

Appendix C states the persist parameter "is used to make a confirmed 
commit persistent. A persistent confirmed commit is not aborted if the 
NETCONF session terminates. The only way to abort a persistent confirmed 
commit is to let the timer expire, or to use the  
operation."

However:

Section 7.8, Erratum 5397 states "If a NETCONF server receives a 
 request while processing a confirmed commit (Section 
8.4) for that session, regardless of whether the confirmed commit 
included a  element, it MUST restore the configuration to its  
state before the confirmed commit was issued."

Section 7.9, Erratum 5397 states "If a NETCONF server receives a 
 request while processing a confirmed commit (Section 8.4) 
for that session, regardless of whether the confirmed commit included a 
 element, it MUST restore the configuration to its  state 
before the confirmed commit was issued."

Section 8.4.1 states "If the device reboots for any reason before the 
confirm timeout expires, the server MUST restore the configuration to 
its state before the confirmed commit was issued."

So:

Is the use of  or , or the device 
rebooting, not considered to be the session being "terminated for any 
reason"? Or is it the case that "the only way to abort a persistent 
confirmed commit is to let the timer expire, or to use the 
 operation"?

Jonathan

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--------=_MB3FAEA49A-BB4E-4CAA-97B1-D65FB7407C58
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable





Hi,

In RFC 6241:

Sect=
ion 8.4.1 states "If the session issuing the confirmed commit is terminated=
 for any reason before the confirm timeout expires, the server MUST restore=
 the configuration to its state before the confirmed commit was issued, unl=
ess the confirmed commit also=C2=A0 included a <persist> element."

Section 8.4.5.1 states the persist parameter makes=
 "the confirmed commit survive a session termination".

Appendix C states the persist parameter "is used to make a conf=
irmed commit persistent. A persistent confirmed commit is not aborted if th=
e NETCONF session terminates. The only way to abort a persistent confirmed =
commit is to let the timer expire, or to use the <cancel-commit> oper=
ation."=C2=A0

However:

Section 7.8, Erratum 5397 states "If a NETCONF server re=
ceives a <close-session> request while processing a confirmed commit =
(Section 8.4) for that session, regardless of whether the confirmed commit =
included a <persist> element, it MUST restore the configuration to it=
s=C2=A0 state before the confirmed commit was issued."

Section 7.9, Erratum 5397 states "If a NETCONF server receives a <=
;kill-session> request while processing a confirmed commit (Section 8.4)=
 for that session, regardless of whether the confirmed commit included a &l=
t;persist> element, it MUST restore the configuration to its=C2=A0 state=
 before the confirmed commit was issued."

Sectio=
n 8.4.1 states "If the device reboots for any reason before the confirm tim=
eout expires, the server MUST restore the configuration to its state before=
 the confirmed commit was issued."

So:

Is the use of <close-session> or <kill-session&g=
t;, or the device rebooting, not considered to be the session being "termin=
ated for any reason"? Or is it the case that "the only way to abort a persi=
stent confirmed commit is to let the timer expire, or to use the <cancel=
-commit> operation"?

Jonathan




	

        3D""
		Virus-=
free. www.avast.com
		
	


 

--------=_MB3FAEA49A-BB4E-4CAA-97B1-D65FB7407C58--


From nobody Wed May  8 08:28:31 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0712012D; Wed,  8 May 2019 08:28:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155732930279.22787.6280688387963736996@ietfa.amsl.com>
Date: Wed, 08 May 2019 08:28:22 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-26.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 15:28:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Subscription to YANG Event Notifications
        Authors         : Eric Voit
                          Alexander Clemm
                          Alberto Gonzalez Prieto
                          Einar Nilsen-Nygaard
                          Ambika Prasad Tripathy
	Filename        : draft-ietf-netconf-subscribed-notifications-26.txt
	Pages           : 80
	Date            : 2019-05-08

Abstract:
   This document defines a YANG data model and associated mechanisms
   enabling subscriber-specific subscriptions to a publisher's event
   streams.  Applying these elements allows a subscriber to request for
   and receive a continuous, custom feed of publisher generated
   information.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-26
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-26

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


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

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


From nobody Wed May  8 08:29:48 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2651202DF; Wed,  8 May 2019 08:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2BW8t4cCRgU; Wed,  8 May 2019 08:29:37 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B25120141; Wed,  8 May 2019 08:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29750; q=dns/txt; s=iport; t=1557329357; x=1558538957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7xOz0fcbBA2DKOlLhnbj8EnMcPdeUU1pOSjqHeHybXs=; b=LYbQ/spPV8WIikhtToZ1K2t5IJciwdgPZBEuYiUr3mRW2+F//IcLOxN3 p91lTGISO4Obc3q0t04o0aXUiz/+813wTghCCu8giIE1MqeSnE9nrcLOo WJPEACqX1l90zheby/mbe+1GXCDCw6LHPuYVzCI1GfDt65iN7yb/4+y7q Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAG9dJc/5FdJa1bAgcaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFRBQEBAQELAYFmKmlNBzAoCowijQJ+l1QUgWcJBwEBJQq?= =?us-ascii?q?EPwKCCCM0CQ4BAwEBBAEBAgEEbRwMhUoBAQEDARpSBgUCBQkCAgEIEgMDDRY?= =?us-ascii?q?EBxsXFAMOAgQBDQUIE4I8TIF7Dw+uQoRGQYUdBgWBLQGKIoErF4FAP4ERghR?= =?us-ascii?q?JNT6CYQIBAQEBgSoBCAoBBwVFhTAEincgAQMvhnlPk0tlCQKCCYYdg3BCg2O?= =?us-ascii?q?BcIIlI4IQhkSDb4U6g1qMJIZNihqEDwIRFYEwHzg1MFgRCHAVgyeCGxcUbQE?= =?us-ascii?q?DBAeHUIU+AUExAY48DxcDAYEHgSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,446,1549929600"; d="scan'208";a="545050936"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 May 2019 15:29:15 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x48FTEjm030369 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 May 2019 15:29:15 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 May 2019 11:29:13 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 8 May 2019 11:29:13 -0400
From: "Eric Voit (evoit)" 
To: Magnus Westerlund , The IESG 
CC: "draft-ietf-netconf-subscribed-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
Thread-Index: AQHVAOILPUp24ohD6UOwYws4qyBRVKZhWkZQgAAATiA=
Date: Wed, 8 May 2019 15:29:13 +0000
Message-ID: 
References: <155679988653.24963.16586553566609600202.idtracker@ietfa.amsl.com> <7efee2607c62458d865ce663f9d4fc27@XCH-RTP-013.cisco.com>  <4ac32da8a1544e26b9671f6f5e2bdf84@XCH-RTP-013.cisco.com>  <17c30fc703d74a068f1cebcd4cf13858@XCH-RTP-013.cisco.com>
In-Reply-To: <17c30fc703d74a068f1cebcd4cf13858@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.233]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 15:29:47 -0000

Hi Magnus,

All items discussed below have now been uploaded as part of:
draft-ietf-netconf-subscribed-notifications-26

Thanks again,
Eric

> From: Magnus Westerlund, May 8, 2019 5:12 AM
>=20
> On 2019-05-07 21:22, Eric Voit (evoit) wrote:
> Hi Magnus,
>=20
> Thanks again for your thorough review on the overload aspect.=A0=A0 It is
> appreciated.=A0 Some thoughts/proposals back to you in-line..
>=20
> From: Magnus Westerlund, May 7, 2019 8:50 AM Hi Eric,
>=20
> Thanks for the answers. I think we are making progress here, see below.
>=20
> What I see is that there need to be some text changes in the QoS parts.
>=20
> Regarding the priority I get the impression that it is not the WG's inten=
tion to
> clarify this. However, I would wish that the document is a bit more expli=
cit about
> the lack of any interface to affect the publisher's action when it comes =
to
> dropping subscriptions. Yes there is this paragraph in Section 1.3:
> =A0=A0=A0A publisher MAY terminate a dynamic subscription at any time.
> =A0=A0 Similarly, it MAY decide to temporarily suspend the sending of
> =A0=A0 notification messages for any dynamic subscription, or for one or
> =A0=A0 more receivers of a configured subscription.=A0 Such termination o=
r
> =A0=A0 suspension is driven by internal considerations of the publisher.
>=20
> So I guess I have to drop this aspect now when the explicit reference to =
priority
> based actions are removed.
>=20
> >  I agree it would be great to have a structure of subscription > =
handling
> precedence on the publisher. However there are not any > solutions that I=
 know
> of being discussed today. Building a model > here would be hard, and woul=
d
> likely take quite a bit of time/effort. > It is primarily the time cost w=
hich is the
> biggest consideration at > this point. Since NETCONF got started on these
> subscription > specifications, Google's GNMI alternative has been introdu=
ced. >
> GNMI has fewer overload controls, yet has gained industry traction. > Bas=
ed on
> this, it doesn't seem like standardized handling of > subscription preced=
ence on
> a publisher is a market necessity yet.
> Understood. And I will most definitely not insist on a solution at this t=
ime. I was
> considering if there should be more word on that this is something suitab=
le for
> future extension, but I guess it does not provide any good benefit.
>=20
>=20
>=20
> On 2019-05-06 23:19, Eric Voit (evoit) wrote:
> Hi Magnus,
>=20
> Thanks very much for your comments.=A0=A0 Thoughts in-line...
>=20
> From: Magnus Westerlund, May 2, 2019 8:25 AM
>=20
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-netconf-subscribed-notifications-25: Discuss
>=20
> When responding, please keep the subject line intact and reply to all ema=
il
> addresses included in the To and CC lines. (Feel free to cut this introdu=
ctory
> paragraph, however.)
>=20
>=20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notificati=
ons/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> My focus when reviewing this document was from a perspective of how to
> handle overload.
>=20
> You are absolutely correct to focus on overload.=A0 Mitigating different
> dimensions of the overload risk has been a design goal since this effort'=
s
> inception.=A0 And this is the reason a variety of QoS mechanisms were inc=
luded in
> the document.
>=20
> I have a hard time understanding how this will actually work, especially =
in a
> fashion that preservers goodput and ensure what is considered the most
> important subscriptions are delivered. Not having good undertanding into
> netconf and restconf don't hesitate to call out likely missunderstanding =
by me
> and provide clarification and pointers.
>=20
> Few of the mechanisms are specific to either RESTCONF or NETCONF.=A0 For
> completeness reasons, let me summarize the overload mechanisms available.=
..
>=20
> 1. The publisher is allowed to decline a dynamic subscription.=A0 One of =
these
> reasons is that the incremental traffic generated by a particular increme=
ntal
> subscription will be too high.=A0 There are errors back to the subscriber=
 indicating
> this condition exist.
> 2. A publisher can suspend any subscription for capacity reasons, and a r=
eceiver
> must be able to gracefully accept this suspension.
> 3. Much like with HTTP2 streams, higher priority subscriptions intended f=
or a
> particular receiver can be dequeued first from a publisher.
> 4. Much like with HTTP2 streams, proportional subscription dequeuing inte=
nded
> for a particular receiver can be performed a publisher.
> 5. DSCP markings can be placed on subscribed data.
> 6. Mechanisms for detecting and reacting to different types of subscribed=
 data
> loss have been embedded.
> 7. Methods have been included to ensure a configured receiver "ok's"
> information push before subscribed data is sent. (This should reduce one =
DDoS
> vector.) 8. Keep alive mechanisms are established for different transport=
 types,
> so that subscribed data isn't being sent when the is no receiver listenin=
g.
>=20
> Mechanisms (3) & (4) will likely be seen only with HTTP2 based transports=
.*=A0=A0 This
> is because (as documented within draft-ietf-netconf-restconf-notif sectio=
n 4),
> these capabilities are to integrated directly HTTP2 RFC-7450 sections 5.3=
.1 &
> 5.3.2. To me the big weakness of this mechanism are actually in the API b=
etween
> the receiver and the publisher. The current API defined by this document =
does
> not include any information that allow the receiver to express its actual=
 view on
> priority for a subscription. It has some other tools that has completely =
different
> meanings namely:
> - Transport level DSCP expressing PHB and routing priority
> - Weight: Proportional bandwidth distribution
> - Dependency: Deliver this only after this other subscription None of thi=
s
> expresses anything related to the priority or importance to maintain a pa=
rticular
> subscription, nor does the interface carry any information regarding what
> delivery requirements the receiver have on the subscription. Thus, the be=
havior
> in overload situation is going to be totally random.
> So if the WG is okay with this being the case I will hold my nose. Howeve=
r, I think
> the fact that random implementation dependent things will happen in overl=
oad
> should be explicitly stated in the document.
>  I think the documents reflect the state-of-the-art across industry
> players.=A0 Attempting to layer-in something new which hasn't been consid=
ered
> would be non-trivial.=A0 But your intent should not be lost.=A0 So to ref=
lect your
> request above, how about I add the following statement at the very end of
> Section 2.3 QoS:
> There are additional types over publisher capacity overload which this
> specification does not address within its scope. For example, the priorit=
ization of
> which subscriptions have precedence when the publisher CPU is overloaded =
is
> not discussed.=A0 As a result, implementation choices will need to be mad=
e to
> address such considerations.
> Does this work for you?
> Yes.
>=20
>=20
> * One background/review note...=A0 Earlier versions of draft-ietf-netconf=
-
> subscribed-notifications included specific parallels to RFC-7450 when des=
cribing
> (3) & (4).=A0 However WG members wanted to abstract away what they felt w=
ere
> HTTP2 specific references. This is despite the fact that what was being
> referenced was the desired functional behavior rather than anything HTTP2
> specific.=A0=A0 I can understand the WG reviewers' concern.=A0 This is al=
ready a long
> document, and a reader who only cares about NETCONF hopefully won't need
> to wade through complex issues which they are unlikely to worry about in
> deployment.
> I did a brief look at the transports. They did not answer my questions wh=
en I
> wrote this discuss. Also, to my understanding the HTTP/2 priority mechani=
sm is
> that is far from easy to use and also intended to distribute resources in=
 an
> ongoing transmission. That doesn't actually match the higher level need o=
f
> determining which subscription are more important than another. Doesn't a=
 5
> level priority value cover a lot of the missing ground here?
>  Agree that the HTTP2 QoS mechanisms described do not address anyth=
ing
> other than handling dequeuing congestion between a publisher and a receiv=
er as
> part of an ongoing transmission.=A0 This actually is very relevant proble=
m.=A0 Early
> implementations of telemetry for SDN have many network element publishers
> pushing data to a few central data collectors. Ok Beyond this, I don't th=
ink the
> working group has ever considered a multi-level subscription priority
> mechanism.=A0 I believe the problem to be a very hard one, even if there =
are just 5
> levels (or two levels).
> Ok. Just a suggestion and I agree that solution to this problem will have=
 to be in
> a future extension, if ever.
>=20
> A) The QoS and priority sending mechanism discussed in 2.3 and furhter de=
fined
> by the YANG model.
>=20
> I do want to raise the usage of the DSCP code point to a discuss. As the =
DSCP
> defines different PHB and relative priorities in the router queues a DSCP=
 value
> does not provide the publisher any information about priority. I get the =
feeling
> from the text that this may be intended. If the only intention is to have=
 the
> transport perform differential treatment in the network between the publi=
sher
> and the receiver
>=20
> Yes, this is the case.
>=20
> there are still more considerations are needed.
> First of all I think these sentence needs a total rewrite:
>=20
> =A0=A0 If the publisher supports the "dscp" feature, then a subscription
> =A0=A0 with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
> =A0=A0 marking being placed within the IP header of any resulting
> =A0=A0 notification messages and subscription state change notifications.
> =A0=A0 Where TCP is used, a publisher which supports the "dscp" feature
> =A0=A0 SHOULD ensure that a subscription's notification messages are
> =A0=A0 returned within a single TCP transport session where all traffic
> =A0=A0 shares the subscription's "dscp" leaf value.
>=20
> I think one need to put a requriement on the transport to use a transport=
 that
> utilize the DSCP marking on its traffic.
>=20
> I believe you are asking for a=A0 the publisher respect the DSCP markings=
 for traffic
> egressing an interface on a publisher.=A0 Yes this requirement was assume=
d, and
> can be explicitly added.
> Please do.
>  Section 2.3 QoS now says..
> A publisher MUST respect the DSCP markings for subscription traffic egres=
sing
> that publisher.
> I think that work, but I like to see it in its full context.
>=20
>=20
> Which for the current set of connection
> oriented transport protocols, TCP, SCTP, and QUIC all currently only supp=
ort
> using a single DSCP per connection. Implying multiple transport protocol
> connections using a particular transport to enable this mapping.
>=20
> Yes fully agree, a connection would be needed per DSCP.=A0=A0=A0=A0 Is yo=
ur objection
> with the text above the words "SHOULD ensure" rather than "MUST ensure"?=
=A0=A0=A0 If
> yes, I can ask the WG objects to whether this requirement should be a MUS=
T.
>=20
> If you think you should use RFC 2119 language, yes then I request a
> MUST.=A0 However, I think reformulating this so state it as a fact that d=
ifferent
> DSCP code points requires different transport connections, unless a trans=
port
> supporting multiple DSCP simultanous are used (No standardized option tha=
t has
> reliable object or stream semantics exist to my knowledge).
> =A0 Adding a statement of fact here is not an issue.=A0 And thinkin=
g about your
> comment regarding RFC2119 language, I don't think RFC2119 language is
> needed here.=A0 So I have turned the "SHOULD" into "must".=A0=A0 This res=
ults in the
> following proposed text:
> Different DSCP code points require different transport connections.=A0 As=
 a result
> where TCP is used, a publisher which supports the "dscp" feature must ens=
ure
> that a subscription's notification messages are returned within a single =
TCP
> transport session where all traffic shares the subscription's "dscp" leaf=
 value.
> Does this work for you?
> Yes.
> Where TCP is used, a publisher which supports the "dscp" feature must ens=
ure
> that a subscription's notification messages are returned within a single =
TCP
> transport session where all traffic shares the subscription's "dscp" leaf=
 value.
>=20
> A.2 Queuing model of a publisher.
> With the DSCP and the Weight and dependency model I think it is important=
 to
> clarify the model of the queueing in the publisher. So is the intention t=
hat several
> subscriptions with different weights and possibly dependencies have their
> individual queues that goes into a scheduler?
>=20
> As you know, queuing models are non-trivial.=A0=A0 For that reason we wan=
ted to
> 100% adopt the functional behavior RFC-7540 Section 5.3.1 and 5.3.2 witho=
ut
> having to re-document/mirror that content at a higher level of the networ=
k
> stack.=A0=A0 We are a hoping that a reader of network subscriptions can l=
ook to well
> documented, implemented HTTP2 behaviors as applicable.=A0 Providing an
> intermediate layer of functional description could easily result in some =
mis-
> alignments from what is intended.
> Hmm, that is fine, accept that you added DSCP to the mix, where RFC 7540 =
is all
> within a single TCP connection. Thus, to avoid complexities I think you a=
t least
> need to be explicit that one can only perform Dependency and Weight
> operations between subscriptions that share DSCP, and that they become
> independent queues.
>  To cover this, are you ok with adding as a last sentence of Sectio=
n 2.3:
> "Dependency" and "weight" parameters will only be respected and enforced
> between subscriptions that share the same "dscp" leaf value.
> Yes, I think that clarifies the issue.
> To avoid complex queue
> interactions on this level I think there need to be seperate scheduler in=
stances
> per DSCP. I would also note that Dependency mechanism can't ensure that a
> dependent stream arrive at receiver after the identified dependency if th=
ey are
> on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may no=
t
> even guarantee it within a single connection and same DSCP due to packet =
loss
> impact. To me this model and what relationship one need to consider here =
need
> to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indicatio=
n of just the
> importance of considering what is in the same dependency tree and what it
> means to have different weighting. To conclude I think this needs a model
> description and clearer definition and possibly requirements towards the
> transport. Espceially if you actually need an in-order delivery requireme=
nt?
>=20
> I think we have the same technical objective in mind.=A0=A0 And it is abs=
olutely the
> desire to have identical behavior to RFC-7540 Section 5.3.1 and 5.3.2.=A0=
=A0=A0 For the
> current set of documents before the IESG, we include within draft-ietf-ne=
tconf-
> restconf-notif Section 4, a 1:1 mapping between draft-ietf-netconf-subscr=
ibed-
> notifications and RFC-7540.
>=20
> We are hoping that the transport documents like draft-ietf-netconf-restco=
nf-
> notif can be the place where such supporting documentation and mappings
> occur. I still think that this document needs to have that sentence in th=
eir stating
> that Dependency and Weight applies only per subscription sharing DSCP val=
ue.
> Because these values are define on this document level, not on the mappin=
g
> level that the individual transport exists on. And this is the interface =
the WG have
> defined for this. And as it currently stands you appear to have something=
 that
> lacks a clear meaning.
>  Hopefully the last suggested text covers this.
> Yes, it does.
>=20
>=20
> B. The unpredictability of the circuit breaker overload mechanism.
>=20
> My description of the overload handling in this document is that it is a =
circuit
> breaker based mechanism that can blow a fuse on subscriptions that it fai=
ls to
> honor in overload situations. What worries me deply is the total unpredic=
tability
> of this mechanism.
>=20
> At the beginning of this email, there are eight methods of overflow handl=
ing
> listed.=A0 We optimized these eight mechanisms for different failure scen=
arios and
> congestion conditions.=A0=A0 Our goal was to depend on existing
> mechanisms/technologies wherever possible.=A0 Reuse of existing mechanism=
s
> should reduce at least some of the unpredictability.
>=20
> First, is it the intention to derive what subscriptions are least importa=
nt from the
> DSCP, weighting and Dependency parameters? If it is, I think that may be =
a
> misstake as priority on what subscriptions are most important to retain a=
re not
> necessarily reflected in their QoS parameters.
>=20
> At this point the document does not attempt to define "important".=A0 All=
 that is
> done is to provide guidance relating to some elements of network transpor=
t.=A0=A0 If
> there is a dimension of "importance" which an implementer would like to l=
ayer
> onto this solution, it could be done.=A0 For example, "importance" could =
applied in
> areas such as what subscriptions should be suspended=A0 in case of CPU
> exhaust.=A0=A0 However guidance on such enhancements are not included in =
this
> document.
> Still it is both implied and explicitly stated in one place.
>  Hopefully the changes suggested above cover this concern.
> Yes, I think it is sufficiently well handled.
>=20
>=20
> Secondly, what are the values when a subscription are considered to be to=
 heavy
> or not be handled accordingly. Are there any parameter sets that actually
> describe what SLA the subscriber expect that can be converted into timeou=
t
> timers or buffer depth thresholds to indicate that publisher side isn't d=
elivering
> these in time?
>=20
> There is no guidance on this provided in the document.=A0=A0 As equipment=
 types,
> subscription volumes, available memory, will vary between solutions, this=
 will
> take a while to dimension properly.=A0 I can imagine someday that we migh=
t have
> something like "Erlang for subscriptions" much like we used Erlangs in th=
e old
> telephony network to dimension call handling capabilities of phone
> switches.=A0 But we are a long way from that.
> To be clear what I mean with SLA here is to express some boundaries on wh=
en
> the subscribed to information will be received by the receiver compared t=
o when
> it come to existence on the publisher side. However, I do hear you that t=
here is
> nothing defined and nothing in the pipeline.
>  Understood.=A0 We simply don't have anything.
>=20
>=20
> Third, I what I understand there are no any additional back pressure mech=
anism
> between the receiver and the publisher than the transport protocols flow
> control? So a receiver that is not keeping up processing the data it proc=
ess will
> not read out the data out of the flow controlled buffers in the receiver =
and thus
> prevent the publisher to write to the transport conncetion, thus causing =
the
> publisher to eventually trigger a suspension due to its queue build up?
>=20
> There is nothing beyond transport flow control.=A0 We thought about it in=
itially,
> but we were not ready to pick up even more complexity than we already had=
.
> Ok, which just contribute to what I call random things happen at overload=
.
>  agree
>=20
>=20
> To my understanding the current mechanism places all subscriptions on the
> same importance and with the same SLA. Thus likely causing short term ove=
rload
> situations to cause subscription suspensions in random subscriptions. Is =
the WG
> fine with this type of randomness occuring and expecting that normally th=
ere
> will be such amount of overprovisioning that being able to indicate prior=
ity and
> SLA are overkill?
>=20
> Yes.=A0=A0 We needed a starting point.=A0 And there are technical solutio=
ns which can
> be layered on top.=A0=A0 But what we have now took many years to finalize=
, and
> should be a big enough technical jump considering our current knowledge.
>=20
> At a minimal a change of this sentence in Section 2.5.1 is needed:
>=20
> =A0 This could
> =A0=A0 be for reasons of an unexpected but sustained increase in an event
> =A0=A0 stream's event records, degraded CPU capacity, a more complex
> =A0=A0 referenced filter, or other higher priority subscriptions which ha=
ve
> =A0=A0 usurped resources.
>=20
> I have removed "higher priority".
> Thanks.
>=20
>=20
> As it states that subscriptions has priorities without reference to a mec=
hanism
> that provides that priority.
>=20
> C. 2.4.5.=A0 Killing a Dynamic Subscription
>=20
> =A0=A0 The "kill-subscription" operation permits an operator to end a
> =A0=A0 dynamic subscription which is not associated with the transport
> =A0=A0 session used for the RPC.=A0 A publisher MUST terminate any dynami=
c
> =A0=A0 subscription identified by the "id" parameter in the RPC request, =
if
> =A0=A0 such a subscription exists.
>=20
> Can someone please clarify the use case for this functionality. To my
> understanding it allows another receiver given authority to kill the subs=
cription
> being delivered to another receiver. Based on the otherwise rather strict=
 that all
> manipulations of dynamic subscriptions happens from the transport session
> context that established it I want to better understand the use case it a=
ppears
> out place.
>=20
> A network operator needs a very secure mechanism to end a dynamic
> subscription in progress which it sees as harmful.=A0=A0 The operator can=
not do this
> via configuration operations, as the dynamic subscription is not configur=
ed (and
> therefore cannot be deleted in the configuration datastore).
> Thanks, that clarification resolves my question mark. So lets close this =
issue
> without any actions.
>=20
>=20
> D. The Requirements on a transport supporting Configured Subscriptions
> Reading through Section 2.5 I arrived at a number of questions. I tried t=
o
> understand what the requirements are for the transport that supports
> Configured Subscriptions. I did note that neither draft-ietf-netconf-rest=
conf-
> notif-13 nor
> draft-ietf-netconf-netconf-event-notifications-17 supports configured
> subscriptions. Thus, there appear no template for a solution either, or d=
oes
> there exist another document that is being worked on defining such a tran=
sport?
>=20
> This is the case.=A0=A0 Originally both of those documents *did* include =
configured
> subscriptions.=A0 However within the WG there was a decision not to progr=
ess
> configured subscriptions yet.=A0 One reason is that other YANG model draf=
ts
> moving in the NETCONF WG were seen as pre-requisites for securely creatin=
g
> transport sessions via call home for the configured subscriptions.=A0 As =
a result,
> support for configured subscriptions was extracted from those transport
> documents.=A0=A0 It is expected that that updated versions of just those =
transport
> documents will be driven when the YANG models complete.
> Look at the responses below I see that we are in one of these situation w=
here
> things are deliberately left open. I will simply assume that this is done=
 in a way
> that supports those future definitions and clarifications. So lets close =
this issue
> without any actions.
>=20
> Questions that arose for me related to Configured Susbription Transport w=
here
> the following: 1. Can Transport Session be initiated in both direction. R=
FC
> 8071 provides a solution for Publisher to Receiver initiation. It is uncl=
ear if all
> parts are in place to have a receiver to publisher initiated transport to=
 be bound
> to the subscription.
>=20
> This will be up to a specific transport draft to make this determination.
>=20
> To see what might be viable for NETCONF, check out the earlier version of=
 the
> document at:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-
> notifications/10/
>=20
> This was seen as a complete version of such a solution.=A0 However the WG
> wanted a YANG model for session parameters discussed in Section 5.2.
>=20
> 2. What is "name" really? It appears to be defined as an
> empty container. Despite that it appears to have requirements on being bo=
th a
> security identity as well as network address.
>=20
> You are correct.=A0 In previous versions of this draft, a receiver was id=
entified by
> the combination of address + port.=A0 However due to the YANG doctor revi=
ews,
> and call home discussions referenced above, the WG wasn't ready to finali=
ze this
> YANG structure.=A0 The compromise was the current structure, plus the exa=
mple
> YANG model of Appendix A to show how this might be built out.
>=20
> 3. In Figure 9, which is stated to be
> for the receiver. What information does the receiver use to determine the
> transition (d)? And what does it do in this step. Related to Discuss part=
 B).
>=20
> This determination is implementation specific.
>=20
> 4. RFC
> 8071 appears to lack any considerations for how often and how many times =
it
> attempts to connect to the receiver. So applying that mechanism appears t=
o
> require some usage guidance to avoid causing overload situations or DoS
> potential by misconfiguring network devices with this soltution to dial o=
ut
> frequently to a target.
>=20
> As the transport solution requirements are not detail it is actually hard=
 to
> determine if there are short comings in the description in Section 2.5 an=
d the
> corresponding YANG model. Is it an reasonable request to document these
> requirements?
>=20
> The requirements were documented for both NETCONF and
> RESTCONF.=A0=A0 However these requirements were removed when the WG decid=
ed
> to wait until there was a YANG model for RFC-8071 ready to go to the IESG=
.=A0=A0 For
> a preview on what these requirements might look like, I refer you=A0 to S=
ection 5.2
> of
> https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-
> notifications/10/
> Thanks, so this is clearly something to have in mind when the WG do get t=
o
> specify a solution for this. So I don't see a need for any actions here.
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> 1. Section 2.3: DSCP domains
> I think the text could benefit from pointing out that the subscriber actu=
ally needs
> to know what the DSCP values represents in the diffserv domain of the pub=
lisher.
> As these could be different, they also create an interesting problems for
> transports of how they establish a transport connection that uses a parti=
cular
> DSCP, as the receiver if initiating need to know the local DSCP value tha=
t
> corresponds to the behavior in the publisher's domain.
>=20
> This makes sense.
>=20
> I have added in Section 5.3 Transport Requirements a new entry which stat=
es:
>=20
> "A subscriber which includes a "dscp" leaf within an "establish-subscript=
ion"
> request will need to understand and consider what the corresponding DSCP
> value represents within the domain of the publisher."
>=20
> Let me know if this is not sufficient.
>=20
> 2. In general I think there are more than one description that are fuzzy =
about if it
> describes a publisher or receiver action/requirement.
>=20
> It would be great if you have some specifics.=A0=A0 The authors and previ=
ous
> reviewers likely have looked at this often enough where things look obvio=
us
> which perhaps are not.
> Sorry, didn't take note about those confusion.
>  Magnus, once again your comments are thoughtful and
> appreciated.=A0 Thanks for taking such a good look at this document.
> Good, I will await the updated document, but I expect to be able to clear=
 with
> the changes discussed here.
> Cheers
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:
> mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------


From nobody Wed May  8 08:40:57 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C512012D; Wed,  8 May 2019 08:40:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155733005535.22763.6075235078278964457@ietfa.amsl.com>
Date: Wed, 08 May 2019 08:40:55 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-event-notifications-20.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 15:40:56 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Dynamic subscription to YANG Events and Datastores over NETCONF
        Authors         : Eric Voit
                          Alexander Clemm
                          Alberto Gonzalez Prieto
                          Einar Nilsen-Nygaard
                          Ambika Prasad Tripathy
	Filename        : draft-ietf-netconf-netconf-event-notifications-20.txt
	Pages           : 19
	Date            : 2019-05-08

Abstract:
   This document provides a Network Configuration Protocol (NETCONF)
   binding to the dynamic subscription capability of both subscribed
   notifications and YANG-Push.

   RFC Editor note: please replace the references to pre-RFC normative
   drafts with the actual assigned RFC numbers.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-20
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-event-notifications-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-event-notifications-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.

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


From nobody Wed May  8 08:44:33 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A6512013C; Wed,  8 May 2019 08:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aluGz2cHVDc8; Wed,  8 May 2019 08:44:30 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEA5120136; Wed,  8 May 2019 08:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2928; q=dns/txt; s=iport; t=1557330269; x=1558539869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r477+/v9Fjr/1wZqh4zPAZFRSKPiAJSC6FGSKVQC9BY=; b=Uxa2vdMYB74KiF1dl7Eq76EvRAkMqAMZbsCYPOO3itx+7QPgiUowetEf DaVfPv0GlxL4/Gh6FsfNS1Ug6XUKpXbVGCRE/towKeX+DOh6IQhZ48X3o uhZqnCcqo7Fqq5aSsmZ/fOK9GYx8MfEbcELAZZ7fLZ1YKIXvrjcwXBKwu g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAABA+NJc/5ldJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgWYqgT0wKAqEBogcjQKYUoF7CQcBAS+EPwIXgXEjNAkOAQM?= =?us-ascii?q?BAQQBAQIBBG0ohUoBAQEDASMRQwIFCwIBCBUDAgIJHQICAjAVEAIEAQ0FCIJ?= =?us-ascii?q?PS4F8D60jgS+KKoELJwGLTReBQD+EIz6ESzOCUIJYBI0qLJlsCQKCCZJHI4I?= =?us-ascii?q?Qk0eDG4kJgSGTVQIRFYEwHziBVnAVgyeQUUExj26BIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,446,1549929600"; d="scan'208";a="268935471"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 May 2019 15:44:28 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x48FiR7f000383 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 May 2019 15:44:27 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 May 2019 11:44:26 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 8 May 2019 11:44:26 -0400
From: "Eric Voit (evoit)" 
To: Dhruv Dhody , Kent Watsen 
CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" 
Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sIAAYi6AgACOyoCAAFnN8A==
Date: Wed, 8 May 2019 15:44:26 +0000
Message-ID: 
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.233]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 May 2019 15:44:32 -0000

VXBkYXRlIHBvc3RlZCBhcyAtdjIwLiAgIFdpdGggdGhlIGNvcnJlc3BvbmRpbmcgY2hhbmdlIHRv
IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcG9zdGVkIGFzIC12
MjUuDQoNCkVyaWMNCg0KPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDgsIDIwMTkgMjoyMSBBTQ0K
PiANCj4gSGkgS2VudCwgRXJpYywNCj4gDQo+IEZpbmUgd2l0aCBtZSENCj4gDQo+IFRoYW5rcyEN
Cj4gRGhydXYNCj4gDQo+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgMzoxOSBBTSBLZW50IFdhdHNl
biA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPg0KPiA+IDxlcmlj
PiBCYXNlZCBvbiBteSByZWFkaW5nIG9mIHlvdXIgcHJvY2VzcyBzdWdnZXN0aW9ucyBLZW50LCBJ
IGxpa2UgYmVzdCB0aGUNCj4g4oCcbWVudGlvbuKAnSBhcHByb2FjaCB3aGljaCB5b3UgdXNlZCBm
b3IgUkZDLTgwNzEsIFNlY3Rpb24gMS40Lg0KPiA+DQo+ID4gV2hhdCBJIHRoaW5rIGNvdWxkIGJl
IGRvbmUgdG8gY292ZXIgdGhpcyBpczoNCj4gPg0KPiA+IChBKSAgUmVtb3ZlIFNlY3Rpb24gMTE6
IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4NCj4gPiAoQikgIFBlciBLZW504oCZcyBkZXNp
cmUgdG8gYWxzbyBjb3ZlciBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBsYWNl
IHRoZQ0KPiBmb2xsb3dpbmcgc3RhdGVtZW50IGludG8gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNj
cmliZWQtbm90aWZpY2F0aW9ucyBkaXJlY3RseQ0KPiBhZnRlciBGaWd1cmUgMTANCj4gPg0KPiA+
IFtSRkMtNTI3N10gU2VjdGlvbiAyLjIuMSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNz
YWdlIGlzIHRvIGJlIHNlbnQgdG8gYQ0KPiBzdWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhICJj
cmVhdGUtc3Vic2NyaXB0aW9uIi4gICBXaXRoIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhpcw0KPiBS
RkMtNTI3NyBzdGF0ZW1lbnQgc2hvdWxkIGJlIG1vcmUgYnJvYWRseSBpbnRlcnByZXRlZCB0byBt
ZWFuIHRoYXQNCj4gbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIHNlbnQgdG8gYSBz
dWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhbg0KPiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIs
IG9yIGEgY29uZmlndXJlZCByZWNlaXZlciB3aGljaCBoYXMgYmVlbiBzZW50IGENCj4g4oCcc3Vi
c2NyaXB0aW9uLXN0YXJ0ZWTigJ0uDQo+ID4NCj4gPiBEb2VzIHRoaXMgd29yayBmb3IgYm90aCBv
ZiB5b3U/DQo+ID4NCj4gPg0KPiA+IFdvcmtzIGZvciBtZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBU
aGUgaXNzdWUgaXNuJ3QgY29uc2lzdGVuY3kgc28gbXVjaCBhcyBtZWV0aW5nIGV4cGVjdGF0aW9u
cywgcGVyIGB4bWwycmZjYCwgdGhlDQo+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0aGluZyBs
aWtlIHRoZSBmb2xsb3dpbmcgaW4gdGhlIFJlZmVyZW5jZXMgc2VjdGlvbiwNCj4gd2hpY2ggdGhl
biBhdXRvLWV4cGFuZHMgdG8gdGhlIGNvcnJlY3QgcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMg
ZGVmaW5pbmcgdGhlDQo+IGFuY2hvciAiSS1ELmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm
aWNhdGlvbnMiOg0KPiA+DQo+ID4gICAgICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuSS1E
LmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMiPz4NCj4gPg0KPiA+IDxFcmlj
PiBUaGF0IGRlZmluaXRlbHkgbWFrZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQgSSBoYXZlIGJl
ZW4gZG9pbmcuICBJIGFtDQo+IGhpdHRpbmcgYW4geG1sMnJmYyBlcnJvciB0cnlpbmcgdGhpcyBy
aWdodCBub3csIGJ1dCBJIHdpbGwgZ2V0IHRoZXJlLg0KPiA+DQo+ID4NCj4gPiBZZXMsIGl0IHdh
cyBhbiBleWUtb3BlbmVyIHdoZW4gSSBmaWd1cmVkIGl0IG91dC4gICBCZSBhd2FyZSB0aGF0LCB0
aG91Z2ggc29tZQ0KPiBleHRlcm5hbCBzb3VyY2VzIChlLmcuLCBJVFUgc3RhbmRhcmRzKSBhcmUg
c3VwcG9ydGVkLCBtYW55IGFyZSBub3QsIGFuZCBzbyBoYW5kLQ0KPiBjb2RpbmcgdGhlIDxyZWZl
cmVuY2U+IGlzIHN0aWxsIHNvbWV0aW1lcyByZXF1aXJlZC4uLg0KPiA+DQo+ID4NCj4gPiBLZW50
IC8vIHNoZXBoZXJkDQo+ID4NCj4gPg0KPiA+DQo=


From nobody Wed May  8 21:03:23 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42AF12025B; Wed,  8 May 2019 21:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 fNuDIR3eFOO2; Wed,  8 May 2019 21:03:13 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 53DA0120264; Wed,  8 May 2019 21:03:13 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id z4so566335iol.0; Wed, 08 May 2019 21:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5QQMZ929+wacsGBuhjCLfY+y7FGKryJPsvoIVE7BVKc=; b=DIvqaj/27Hc6foVZLdLEAxPRnW4R3LDEbUA+V1so5P9p1Ypuhgg4CxqI3vHmNntL2w Kknnv9nn3vukuq2Lrp7GComb1BnzQgYUQrqLBWr5T9CTAPTaWgVWvJbsmtjWTLZOgnee cZP8QwWCU3qdC/3mp+zlX+rwZxMFIbZMyDBZdhm5HqTrnQ0LF6JLffoEGX72JJOr1RZX jABuPbI7I2eFcq7061vy+MX909ILjmRYlzqbf4geR2i+mgF8MNddfNCkgEHfOy0MkVQV LUK9M8w8VYsS/3WqfSJw2OU9HwlHUm+2As2gItGfRPeIlcotlmU70Pesi12M0kHt6Fmr xglg==
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:content-transfer-encoding; bh=5QQMZ929+wacsGBuhjCLfY+y7FGKryJPsvoIVE7BVKc=; b=npMCgAt3hKcgjprmJ1eKUPVBNkNUrBpj+EgzEVDprmmeg/9rhRX3igpPfqUGMDfMzs OUgEGLzzcd1kVpCREFDkyPUYR8Km9RCMSNEF6DUYiz7yaU4R7c+skQtiMixGX+d3yGyY bj3C+f19N642u1KxANIL4fT6l4qA50W5OD54ftvZcHhE6a6D+39OER2Fqv0On5Ise04X QsO7GHZF4dv3leFIyZGFYBTwJUbWuJWhqDlnD/FLty0Zv8Z7I3VpRgBrVrLKEng4CDzQ I00YRRUsne7Y3mORKpDHPaS4EebgLeqdC2c5RI+yhb+bhSWPGtTA7b8MpbE9wGDfuAt+ dRjg==
X-Gm-Message-State: APjAAAVISKX9t4lYgVO/Hkw0UAjmfn/5M51aeQvVxSSBIiMAci91bYyo Yg2iU7VnuNN3Eb4BZFGj6uZm1MriEHGyAuXsJiY=
X-Google-Smtp-Source: APXvYqzNvnT75htL2kMUWtBDvKorKkLcw1qkb07ca6t7U+tkNUAJhXiIHPD1HjqZJSL1yNpTrK7urWk67KHJloNrIdc=
X-Received: by 2002:a5e:9b05:: with SMTP id j5mr1113170iok.158.1557374592410;  Wed, 08 May 2019 21:03:12 -0700 (PDT)
MIME-Version: 1.0
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>  
In-Reply-To: 
From: Dhruv Dhody 
Date: Thu, 9 May 2019 09:32:35 +0530
Message-ID: 
To: "Eric Voit (evoit)" 
Cc: Kent Watsen , "rtg-dir@ietf.org" ,  "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" ,  "netconf@ietf.org" , Dhruv Dhody ,  "" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 May 2019 04:03:16 -0000

Hi Eric,

Thanks for the update. I see one minor comment that is not handled.
Maybe you missed it? Or you disagree, that some more text is required?

> Minor Issues:
> -------------
> (1) Abstract & Introduction, It is not clear what does the 'binding' mean=
 and who
> are the parties to this binding? If this is the document that mentions 'b=
inding'
> first, so please add some more clarifying text.

Thanks!
Dhruv

On Wed, May 8, 2019 at 9:14 PM Eric Voit (evoit)  wrote:
>
> Update posted as -v20.   With the corresponding change to draft-ietf-netc=
onf-subscribed-notifications posted as -v25.
>
> Eric
>
> > From: Dhruv Dhody, May 8, 2019 2:21 AM
> >
> > Hi Kent, Eric,
> >
> > Fine with me!
> >
> > Thanks!
> > Dhruv
> >
> > On Wed, May 8, 2019 at 3:19 AM Kent Watsen  wrote=
:
> > >
> > >
> > >
> > >  Based on my reading of your process suggestions Kent, I like b=
est the
> > =E2=80=9Cmention=E2=80=9D approach which you used for RFC-8071, Section=
 1.4.
> > >
> > > What I think could be done to cover this is:
> > >
> > > (A)  Remove Section 11: Notes to the RFC Editor
> > >
> > > (B)  Per Kent=E2=80=99s desire to also cover draft-ietf-netconf-restc=
onf-notif, place the
> > following statement into draft-ietf-netconf-subscribed-notifications di=
rectly
> > after Figure 10
> > >
> > > [RFC-5277] Section 2.2.1 states that a notification message is to be =
sent to a
> > subscriber which initiated a "create-subscription".   With this specifi=
cation, this
> > RFC-5277 statement should be more broadly interpreted to mean that
> > notification messages can also be sent to a subscriber which initiated =
an
> > "establish-subscription", or a configured receiver which has been sent =
a
> > =E2=80=9Csubscription-started=E2=80=9D.
> > >
> > > Does this work for both of you?
> > >
> > >
> > > Works for me.
> > >
> > >
> > >
> > > The issue isn't consistency so much as meeting expectations, per `xml=
2rfc`, the
> > document should have something like the following in the References sec=
tion,
> > which then auto-expands to the correct reference text, as well as defin=
ing the
> > anchor "I-D.ietf-netconf-subscribed-notifications":
> > >
> > >         
> > >
> > >  That definitely makes things easier than what I have been doin=
g.  I am
> > hitting an xml2rfc error trying this right now, but I will get there.
> > >
> > >
> > > Yes, it was an eye-opener when I figured it out.   Be aware that, tho=
ugh some
> > external sources (e.g., ITU standards) are supported, many are not, and=
 so hand-
> > coding the  is still sometimes required...
> > >
> > >
> > > Kent // shepherd
> > >
> > >
> > >


From nobody Thu May  9 09:26:38 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1182512016A for ; Thu,  9 May 2019 09:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODLYO07Nin2b for ; Thu,  9 May 2019 09:26:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02056120145 for ; Thu,  9 May 2019 09:26:34 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0971F7BC22F9834D8777 for ; Thu,  9 May 2019 17:26:32 +0100 (IST)
Received: from sineml703-chm.china.huawei.com (10.223.161.110) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 9 May 2019 17:26:31 +0100
Received: from sineml705-chm.china.huawei.com (10.223.161.112) by sineml703-chm.china.huawei.com (10.223.161.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 10 May 2019 00:26:29 +0800
Received: from sineml705-chm.china.huawei.com ([10.223.161.112]) by sineml705-chm.china.huawei.com ([10.223.161.112]) with mapi id 15.01.1713.004; Fri, 10 May 2019 00:26:29 +0800
From: Wang Haiguang 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [netconf] ietf crypto types - identities
Thread-Index: AQHVAYDDQw6NNz34aE2qTUwOHqkIFaZjAwR+
Date: Thu, 9 May 2019 16:26:29 +0000
Message-ID: 
References: <20190503.092032.2009186244613537120.mbj@tail-f.com>
In-Reply-To: <20190503.092032.2009186244613537120.mbj@tail-f.com>
Accept-Language: en-SG, en-US
Content-Language: en-SG
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.52.43.221]
Content-Type: multipart/alternative; boundary="_000_d0fb4dbd25664c8698678c8a0356c45bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netconf] ietf crypto types - identities
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 May 2019 16:26:36 -0000

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

Hi, Martin,


Sorry for the late reply.


Thanks very much to point out the mistake. I think it is a careless mistake=
 and I am going to check draft and try to fix the errors in next version.


Regarding the reference, if I am not wrong, RFC 6090 explains the mathemati=
cal formulas used by the ECDSA, RFC 5480 gives an object identifier of the =
curve.


I did some search found the NIST report FIPS 186-3  not only explains the m=
athematical formulas, but also list the recommended parameters. How do you =
think we put FIPS 186-3 as an additional reference for secp192r1, ...


https://csrc.nist.gov/csrc/media/publications/fips/186/3/archive/2009-06-25=
/documents/fips_186-3.pdf


Best regards.


Haiguang

________________________________
From: netconf  on behalf of Martin Bjorklund 
Sent: Friday, 3 May 2019 3:20:32 PM
To: netconf@ietf.org
Subject: [netconf] ietf crypto types - identities

Hi,

It seems all sec* identities have the same description:

     identity secp192r1 {
       base asymmetric-key-algorithm;
       description
         "The ECDSA algorithm using a NIST P256 Curve.";
       reference
         "RFC 6090:
            Fundamental Elliptic Curve Cryptography Algorithms.";
     }

This I assume should have been "NIST P191 Curve".

Also, it wasn't clear to me by looking at the reference what this
actually means.  I had to google for "secp192r1", which lead me to RFC
5480 which defines the *curve* "secp192r1".  So I wonder if the
reference needs to be updated, and if the name of this identity is
really correct?


/martin

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

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















Hi, Martin,







Sorry for the late reply. 







Thanks very much to point out the mistake. I think it is a careless mist=
ake and I am going to check draft and try to fix the errors in next version=
. 







Regarding the reference, if I am not wrong, RFC 6090 explains the m=
athematical formulas used by the ECDSA, RFC 5480 gives an object ident=
ifier of the curve. 







I did some search found the NIST report FIPS 186-3  not only e=
xplains the mathematical formulas, but also list the recommended parameters=
. How do you think we put FIPS 186-3 as an additional reference for secp192=
r1, ... 







https://csrc.nist.gov/csrc/media/publications/fips/186/3/archive/2=
009-06-25/documents/fips_186-3.pdf









Best regards.







Haiguang






From: netconf <netconf=
-bounces@ietf.org> on behalf of Martin Bjorklund <mbj@tail-f.com><=
br>
Sent: Friday, 3 May 2019 3:20:32 PM

To: netconf@ietf.org

Subject: [netconf] ietf crypto types - identities

 







Hi,



It seems all sec* identities have the same description:



     identity secp192r1 {

       base asymmetric-key-algorithm;

       description

         "The ECDSA algorithm =
using a NIST P256 Curve.";

       reference

         "RFC 6090:

            Fundamen=
tal Elliptic Curve Cryptography Algorithms.";

     }



This I assume should have been "NIST P191 Curve".



Also, it wasn't clear to me by looking at the reference what this

actually means.  I had to google for "secp192r1", which lead=
 me to RFC

5480 which defines the *curve* "secp192r1".  So I wonder if =
the

reference needs to be updated, and if the name of this identity is

really correct?





/martin



_______________________________________________

netconf mailing list

netconf@ietf.org

https://www.ietf.=
org/mailman/listinfo/netconf







--_000_d0fb4dbd25664c8698678c8a0356c45bhuaweicom_--


From nobody Thu May  9 13:47:43 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7743E1200DE; Thu,  9 May 2019 13:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEPEZsopt7QG; Thu,  9 May 2019 13:47:40 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDCE612009C; Thu,  9 May 2019 13:47:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5014; q=dns/txt; s=iport; t=1557434859; x=1558644459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fe08GN/4ONqB/3ECqbgrx3gPLg19ykkOYX6Zmmxzo1I=; b=VlySrsFguTO/kQNZNqL4x8wKU/lXtBuWJVx7u1KexTyNS1ywtr+TTQOB GBLcSDENfjpFTDT2dmn5VGgZ2PN0EXv4yC5f0rBsAN1ZY9YE9mCx+bgRX 0L0Q3EUO23MQU2tgoRaPKP9XpnQYaAjdQWNEOetob+z9AJje5Jqwai6Bd s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAADokNRc/5JdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBVAQBAQsBgWYqgT0wKAqEB5Uemk4JAQEBDAEBLwEBhEACF4FxIzcGDgE?= =?us-ascii?q?DAQEEAQECAQRtKIVKAQEBAwEjEUMCBQsCAQgVAwICCR0CAgIwFRACBA4FCIJ?= =?us-ascii?q?PS4F8D603gS+KMoELJwGLTheBQD+EIz6ESzOCUIJYBIsZA4IPLJluCQKCCZJ?= =?us-ascii?q?MI4IQhkYFjH6DG4ork1YCERWBMDUigVdwFYMnkFFBMY5egSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,450,1549929600"; d="scan'208";a="557414181"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2019 20:47:38 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x49Klcsp005052 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 20:47:38 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 16:47:37 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Thu, 9 May 2019 16:47:37 -0400
From: "Eric Voit (evoit)" 
To: Dhruv Dhody 
CC: Kent Watsen , "rtg-dir@ietf.org" ,  "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , Dhruv Dhody , "" 
Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sIAAYi6AgACOyoCAAFnN8IABEe2AgADU50A=
Date: Thu, 9 May 2019 20:47:37 +0000
Message-ID: 
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 May 2019 20:47:42 -0000

SGkgRGhydXYsDQoNCj4gRnJvbTogRGhydXYgRGhvZHksIE1heSA5LCAyMDE5IDEyOjAzIEFNDQo+
IA0KPiBIaSBFcmljLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgdXBkYXRlLiBJIHNlZSBvbmUgbWlu
b3IgY29tbWVudCB0aGF0IGlzIG5vdCBoYW5kbGVkLg0KPiBNYXliZSB5b3UgbWlzc2VkIGl0PyBP
ciB5b3UgZGlzYWdyZWUsIHRoYXQgc29tZSBtb3JlIHRleHQgaXMgcmVxdWlyZWQ/DQo+IA0KPiA+
IE1pbm9yIElzc3VlczoNCj4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gKDEpIEFic3RyYWN0ICYgSW50
cm9kdWN0aW9uLCBJdCBpcyBub3QgY2xlYXIgd2hhdCBkb2VzIHRoZSAnYmluZGluZycNCj4gPiBt
ZWFuIGFuZCB3aG8gYXJlIHRoZSBwYXJ0aWVzIHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0
aGUgZG9jdW1lbnQgdGhhdA0KPiBtZW50aW9ucyAnYmluZGluZycNCj4gPiBmaXJzdCwgc28gcGxl
YXNlIGFkZCBzb21lIG1vcmUgY2xhcmlmeWluZyB0ZXh0Lg0KDQpUaGlzIGlzIG5vdCB0aGUgZmly
c3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBmaXJzdC4gIFRoZSBkb2N1bWVu
dCB3aGljaCBkb2VzIHRoaXMgZmlyc3QgaXMgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQt
bm90aWZpY2F0aW9ucy4gICBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCwgdGhhdCBk
cmFmdCBpcyBub3QgZXhwbGljaXRseSBsaXN0ZWQgYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rv
b2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1c2UgcmVmZXJlbmNlcyBpbiBhYnN0cmFjdHMpLiAg
QnV0IGl0IGlzIGxpc3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KDQpUbyBtYWtlIHRoaXMgY2xl
YXJlciBmb3IgeW91IGluIHRoaXMgZG9jdW1lbnQsIHBlcmhhcHMgInRyYW5zcG9ydCBiaW5kaW5n
IiBpbnN0ZWFkIG9mICJiaW5kaW5nIj8gICBJIHJlYWxseSBkb24ndCBoYXZlIG1hbnkgYWx0ZXJu
YXRpdmVzIEkgY2FuIHRoaW5rIG9mIHdoaWNoIGFsc28ga2VlcHMgdGhlIHRleHQgYnJpZWYuICAg
VGhpcyBwYXJ0aWN1bGFyIHRleHQgaGFzIGJlZW4gZnJlcXVlbnRseSB0d2Vha2VkIGluIHRoZSBw
YXN0Lg0KDQpUaGFua3MuDQpFcmljDQoNCiANCj4gVGhhbmtzIQ0KPiBEaHJ1dj4gDQo+IE9uIFdl
ZCwgTWF5IDgsIDIwMTkgYXQgOToxNCBQTSBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28u
Y29tPiB3cm90ZToNCj4gPg0KPiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBXaXRoIHRoZSBj
b3JyZXNwb25kaW5nIGNoYW5nZSB0byBkcmFmdC1pZXRmLW5ldGNvbmYtDQo+IHN1YnNjcmliZWQt
bm90aWZpY2F0aW9ucyBwb3N0ZWQgYXMgLXYyNS4NCj4gPg0KPiA+IEVyaWMNCj4gPg0KPiA+ID4g
RnJvbTogRGhydXYgRGhvZHksIE1heSA4LCAyMDE5IDI6MjEgQU0NCj4gPiA+DQo+ID4gPiBIaSBL
ZW50LCBFcmljLA0KPiA+ID4NCj4gPiA+IEZpbmUgd2l0aCBtZSENCj4gPiA+DQo+ID4gPiBUaGFu
a3MhDQo+ID4gPiBEaHJ1dg0KPiA+ID4NCj4gPiA+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgMzox
OSBBTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+IHdyb3RlOg0KPiA+ID4g
Pg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA8ZXJpYz4gQmFzZWQgb24gbXkgcmVhZGluZyBv
ZiB5b3VyIHByb2Nlc3Mgc3VnZ2VzdGlvbnMgS2VudCwgSQ0KPiA+ID4gPiBsaWtlIGJlc3QgdGhl
DQo+ID4gPiDigJxtZW50aW9u4oCdIGFwcHJvYWNoIHdoaWNoIHlvdSB1c2VkIGZvciBSRkMtODA3
MSwgU2VjdGlvbiAxLjQuDQo+ID4gPiA+DQo+ID4gPiA+IFdoYXQgSSB0aGluayBjb3VsZCBiZSBk
b25lIHRvIGNvdmVyIHRoaXMgaXM6DQo+ID4gPiA+DQo+ID4gPiA+IChBKSAgUmVtb3ZlIFNlY3Rp
b24gMTE6IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+DQo+ID4gPiA+IChCKSAgUGVy
IEtlbnTigJlzIGRlc2lyZSB0byBhbHNvIGNvdmVyDQo+ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29u
Zi1yZXN0Y29uZi1ub3RpZiwgcGxhY2UgdGhlDQo+ID4gPiBmb2xsb3dpbmcgc3RhdGVtZW50IGlu
dG8gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gZGly
ZWN0bHkgYWZ0ZXIgRmlndXJlIDEwDQo+ID4gPiA+DQo+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlv
biAyLjIuMSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHRvDQo+ID4gPiA+
IGJlIHNlbnQgdG8gYQ0KPiA+ID4gc3Vic2NyaWJlciB3aGljaCBpbml0aWF0ZWQgYSAiY3JlYXRl
LXN1YnNjcmlwdGlvbiIuICAgV2l0aCB0aGlzIHNwZWNpZmljYXRpb24sDQo+IHRoaXMNCj4gPiA+
IFJGQy01Mjc3IHN0YXRlbWVudCBzaG91bGQgYmUgbW9yZSBicm9hZGx5IGludGVycHJldGVkIHRv
IG1lYW4gdGhhdA0KPiA+ID4gbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIHNlbnQg
dG8gYSBzdWJzY3JpYmVyIHdoaWNoDQo+ID4gPiBpbml0aWF0ZWQgYW4gImVzdGFibGlzaC1zdWJz
Y3JpcHRpb24iLCBvciBhIGNvbmZpZ3VyZWQgcmVjZWl2ZXINCj4gPiA+IHdoaWNoIGhhcyBiZWVu
IHNlbnQgYSDigJxzdWJzY3JpcHRpb24tc3RhcnRlZOKAnS4NCj4gPiA+ID4NCj4gPiA+ID4gRG9l
cyB0aGlzIHdvcmsgZm9yIGJvdGggb2YgeW91Pw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBX
b3JrcyBmb3IgbWUuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBpc3N1
ZSBpc24ndCBjb25zaXN0ZW5jeSBzbyBtdWNoIGFzIG1lZXRpbmcgZXhwZWN0YXRpb25zLCBwZXIN
Cj4gPiA+ID4gYHhtbDJyZmNgLCB0aGUNCj4gPiA+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0
aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgaW4gdGhlIFJlZmVyZW5jZXMNCj4gPiA+IHNlY3Rpb24s
IHdoaWNoIHRoZW4gYXV0by1leHBhbmRzIHRvIHRoZSBjb3JyZWN0IHJlZmVyZW5jZSB0ZXh0LCBh
cw0KPiA+ID4gd2VsbCBhcyBkZWZpbmluZyB0aGUgYW5jaG9yICJJLUQuaWV0Zi1uZXRjb25mLXN1
YnNjcmliZWQtbm90aWZpY2F0aW9ucyI6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPD9yZmMN
Cj4gPiA+ID4gaW5jbHVkZT0icmVmZXJlbmNlLkktRC5pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1u
b3RpZmljYXRpb25zIj8+DQo+ID4gPiA+DQo+ID4gPiA+IDxFcmljPiBUaGF0IGRlZmluaXRlbHkg
bWFrZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQgSSBoYXZlIGJlZW4NCj4gPiA+ID4gZG9pbmcu
ICBJIGFtDQo+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMgZXJyb3IgdHJ5aW5nIHRoaXMgcmlnaHQg
bm93LCBidXQgSSB3aWxsIGdldCB0aGVyZS4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gWWVz
LCBpdCB3YXMgYW4gZXllLW9wZW5lciB3aGVuIEkgZmlndXJlZCBpdCBvdXQuICAgQmUgYXdhcmUg
dGhhdCwgdGhvdWdoDQo+IHNvbWUNCj4gPiA+IGV4dGVybmFsIHNvdXJjZXMgKGUuZy4sIElUVSBz
dGFuZGFyZHMpIGFyZSBzdXBwb3J0ZWQsIG1hbnkgYXJlIG5vdCwNCj4gPiA+IGFuZCBzbyBoYW5k
LSBjb2RpbmcgdGhlIDxyZWZlcmVuY2U+IGlzIHN0aWxsIHNvbWV0aW1lcyByZXF1aXJlZC4uLg0K
PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBLZW50IC8vIHNoZXBoZXJkDQo+ID4gPiA+DQo+ID4g
PiA+DQo+ID4gPiA+DQo=


From nobody Thu May  9 20:28:28 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC525120098; Thu,  9 May 2019 20:28:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndpfxbhldtKR; Thu,  9 May 2019 20:28:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AEF12006E; Thu,  9 May 2019 20:28:23 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B184870B0F97F5C4BB1D; Fri, 10 May 2019 04:28:21 +0100 (IST)
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 10 May 2019 04:28:20 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.86]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Fri, 10 May 2019 08:58:07 +0530
From: Dhruv Dhody 
To: "Eric Voit (evoit)" , Dhruv Dhody 
CC: Kent Watsen , "rtg-dir@ietf.org" ,  "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , "" 
Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xDB/M0APTVwV06CgM5HTxBRkKZUnleAgAHkuICACVqOAIAABZqAgACOyoCAAJ1+AIAAzj2AgAEYzYCAAMiuUA==
Date: Fri, 10 May 2019 03:28:06 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com>
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>    
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 May 2019 03:28:26 -0000

SGkgRXJpYywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmljIFZv
aXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NCj4gU2VudDogMTAgTWF5IDIwMTkg
MDI6MTgNCj4gVG86IERocnV2IERob2R5IDxkaHJ1di5pZXRmQGdtYWlsLmNvbT4NCj4gQ2M6IEtl
bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0
LWlldGYtDQo+IG5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zLmFsbEBpZXRmLm9y
ZzsgbmV0Y29uZkBpZXRmLm9yZzsgRGhydXYNCj4gRGhvZHkgPGRocnV2LmRob2R5QGh1YXdlaS5j
b20+OyA8cnRnLWFkc0BpZXRmLm9yZz4gPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJF
OiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC0NCj4gbm90
aWZpY2F0aW9ucy0xNw0KPiANCj4gSGkgRGhydXYsDQo+IA0KPiA+IEZyb206IERocnV2IERob2R5
LCBNYXkgOSwgMjAxOSAxMjowMyBBTQ0KPiA+DQo+ID4gSGkgRXJpYywNCj4gPg0KPiA+IFRoYW5r
cyBmb3IgdGhlIHVwZGF0ZS4gSSBzZWUgb25lIG1pbm9yIGNvbW1lbnQgdGhhdCBpcyBub3QgaGFu
ZGxlZC4NCj4gPiBNYXliZSB5b3UgbWlzc2VkIGl0PyBPciB5b3UgZGlzYWdyZWUsIHRoYXQgc29t
ZSBtb3JlIHRleHQgaXMgcmVxdWlyZWQ/DQo+ID4NCj4gPiA+IE1pbm9yIElzc3VlczoNCj4gPiA+
IC0tLS0tLS0tLS0tLS0NCj4gPiA+ICgxKSBBYnN0cmFjdCAmIEludHJvZHVjdGlvbiwgSXQgaXMg
bm90IGNsZWFyIHdoYXQgZG9lcyB0aGUgJ2JpbmRpbmcnDQo+ID4gPiBtZWFuIGFuZCB3aG8gYXJl
IHRoZSBwYXJ0aWVzIHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0aGUNCj4gPiA+IGRvY3Vt
ZW50IHRoYXQNCj4gPiBtZW50aW9ucyAnYmluZGluZycNCj4gPiA+IGZpcnN0LCBzbyBwbGVhc2Ug
YWRkIHNvbWUgbW9yZSBjbGFyaWZ5aW5nIHRleHQuDQo+IA0KPiBUaGlzIGlzIG5vdCB0aGUgZmly
c3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBmaXJzdC4gIFRoZQ0KPiBkb2N1
bWVudCB3aGljaCBkb2VzIHRoaXMgZmlyc3QgaXMgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli
ZWQtDQo+IG5vdGlmaWNhdGlvbnMuICAgDQpbW0RocnV2IERob2R5XV0gZHJhZnQtaWV0Zi1uZXRj
b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBzYXlzIHRoaXMgaW4gdGhlIEludHJvZHVjdGlv
biAtIA0KDQogICBXaGlsZSB0aGUgZnVuY3Rpb25hbGl0eSBkZWZpbmVkIGluIHRoaXMgZG9jdW1l
bnQgaXMgdHJhbnNwb3J0LQ0KICAgYWdub3N0aWMsIHRyYW5zcG9ydHMgbGlrZSBORVRDT05GIFtS
RkM2MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0MF0gY2FuDQogICBiZSB1c2VkIHRvIGNvbmZpZ3Vy
ZSBvciBkeW5hbWljYWxseSBzaWduYWwgc3Vic2NyaXB0aW9ucywgYW5kIHRoZXJlDQogICBhcmUg
YmluZGluZ3MgZGVmaW5lZCBmb3Igc3Vic2NyaWJlZCBldmVudCByZWNvcmQgZGVsaXZlcnkgZm9y
IE5FVENPTkYNCiAgIHdpdGhpbiBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50
LW5vdGlmaWNhdGlvbnNdLCBhbmQgZm9yDQogICBSRVNUQ09ORiB3aXRoaW4gW0ktRC5kcmFmdC1p
ZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWZdLg0KDQpJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1l
IGJpbmRpbmcgaXMgdXNlZCBpbiB0aGlzIGNvbnRleHQuIA0KQW5kIG5vdyB0aGlzIEktRCBzYXlz
IC0gDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVudHMgc3Ry
ZWFtZWQgb3ZlciB0aGUgTkVUQ09ORg0KICAgcHJvdG9jb2wgW1JGQzYyNDFdIGZvciBkeW5hbWlj
IHN1YnNjcmlwdGlvbnMgYXMgZGVmaW5lZCBpbg0KICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYt
c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCg0KQW5kIHlvdSBkb27igJl0IHVzZSB0aGlzIHRl
cm0gZXZlciBhZ2Fpbi4gDQoNClRvIG1lIHRoaXMgaXMgYml0IGNpcmN1bGFyIGFuZCB0aGUgdGVy
bSBiaW5kaW5nIGlzIHVzZWQgbG9vc2VseS4gQW5kIHRodXMgSSBmbGFnZ2VkIGl0LiBJIHdpbGwg
bGV0IHlvdSBhbmQgS2VudCBkZWNpZGUgdGhlIHJpZ2h0IGFwcHJvYWNoLiANCg0KVGhhbmtzISAN
CkRocnV2DQoNCg0KPiBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCwgdGhhdCBkcmFm
dCBpcyBub3QNCj4gZXhwbGljaXRseSBsaXN0ZWQgYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rv
b2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1c2UNCj4gcmVmZXJlbmNlcyBpbiBhYnN0cmFjdHMp
LiAgQnV0IGl0IGlzIGxpc3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiANCj4gVG8gbWFrZSB0
aGlzIGNsZWFyZXIgZm9yIHlvdSBpbiB0aGlzIGRvY3VtZW50LCBwZXJoYXBzICJ0cmFuc3BvcnQg
YmluZGluZyINCj4gaW5zdGVhZCBvZiAiYmluZGluZyI/ICAgSSByZWFsbHkgZG9uJ3QgaGF2ZSBt
YW55IGFsdGVybmF0aXZlcyBJIGNhbiB0aGluaw0KPiBvZiB3aGljaCBhbHNvIGtlZXBzIHRoZSB0
ZXh0IGJyaWVmLiAgIFRoaXMgcGFydGljdWxhciB0ZXh0IGhhcyBiZWVuDQo+IGZyZXF1ZW50bHkg
dHdlYWtlZCBpbiB0aGUgcGFzdC4NCj4gDQo+IFRoYW5rcy4NCj4gRXJpYw0KPiANCj4gDQo+ID4g
VGhhbmtzIQ0KPiA+IERocnV2Pg0KPiA+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgOToxNCBQTSBF
cmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBV
cGRhdGUgcG9zdGVkIGFzIC12MjAuICAgV2l0aCB0aGUgY29ycmVzcG9uZGluZyBjaGFuZ2UgdG8g
ZHJhZnQtaWV0Zi0NCj4gbmV0Y29uZi0NCj4gPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcG9z
dGVkIGFzIC12MjUuDQo+ID4gPg0KPiA+ID4gRXJpYw0KPiA+ID4NCj4gPiA+ID4gRnJvbTogRGhy
dXYgRGhvZHksIE1heSA4LCAyMDE5IDI6MjEgQU0NCj4gPiA+ID4NCj4gPiA+ID4gSGkgS2VudCwg
RXJpYywNCj4gPiA+ID4NCj4gPiA+ID4gRmluZSB3aXRoIG1lIQ0KPiA+ID4gPg0KPiA+ID4gPiBU
aGFua3MhDQo+ID4gPiA+IERocnV2DQo+ID4gPiA+DQo+ID4gPiA+IE9uIFdlZCwgTWF5IDgsIDIw
MTkgYXQgMzoxOSBBTSBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+ID4gd3Jv
dGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPGVyaWM+IEJh
c2VkIG9uIG15IHJlYWRpbmcgb2YgeW91ciBwcm9jZXNzIHN1Z2dlc3Rpb25zIEtlbnQsIEkNCj4g
PiA+ID4gPiBsaWtlIGJlc3QgdGhlDQo+ID4gPiA+IOKAnG1lbnRpb27igJ0gYXBwcm9hY2ggd2hp
Y2ggeW91IHVzZWQgZm9yIFJGQy04MDcxLCBTZWN0aW9uIDEuNC4NCj4gPiA+ID4gPg0KPiA+ID4g
PiA+IFdoYXQgSSB0aGluayBjb3VsZCBiZSBkb25lIHRvIGNvdmVyIHRoaXMgaXM6DQo+ID4gPiA+
ID4NCj4gPiA+ID4gPiAoQSkgIFJlbW92ZSBTZWN0aW9uIDExOiBOb3RlcyB0byB0aGUgUkZDIEVk
aXRvcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gKEIpICBQZXIgS2VudOKAmXMgZGVzaXJlIHRvIGFs
c28gY292ZXINCj4gPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBs
YWNlIHRoZQ0KPiA+ID4gPiBmb2xsb3dpbmcgc3RhdGVtZW50IGludG8NCj4gPiA+ID4gZHJhZnQt
aWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gPiBkaXJlY3RseSBh
ZnRlciBGaWd1cmUgMTANCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlvbiAy
LjIuMSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzDQo+ID4gPiA+ID4gdG8g
YmUgc2VudCB0byBhDQo+ID4gPiA+IHN1YnNjcmliZXIgd2hpY2ggaW5pdGlhdGVkIGEgImNyZWF0
ZS1zdWJzY3JpcHRpb24iLiAgIFdpdGggdGhpcw0KPiBzcGVjaWZpY2F0aW9uLA0KPiA+IHRoaXMN
Cj4gPiA+ID4gUkZDLTUyNzcgc3RhdGVtZW50IHNob3VsZCBiZSBtb3JlIGJyb2FkbHkgaW50ZXJw
cmV0ZWQgdG8gbWVhbiB0aGF0DQo+ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBjYW4gYWxz
byBiZSBzZW50IHRvIGEgc3Vic2NyaWJlciB3aGljaA0KPiA+ID4gPiBpbml0aWF0ZWQgYW4gImVz
dGFibGlzaC1zdWJzY3JpcHRpb24iLCBvciBhIGNvbmZpZ3VyZWQgcmVjZWl2ZXINCj4gPiA+ID4g
d2hpY2ggaGFzIGJlZW4gc2VudCBhIOKAnHN1YnNjcmlwdGlvbi1zdGFydGVk4oCdLg0KPiA+ID4g
PiA+DQo+ID4gPiA+ID4gRG9lcyB0aGlzIHdvcmsgZm9yIGJvdGggb2YgeW91Pw0KPiA+ID4gPiA+
DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXb3JrcyBmb3IgbWUuDQo+ID4gPiA+ID4NCj4gPiA+ID4g
Pg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIGlzc3VlIGlzbid0IGNvbnNpc3RlbmN5IHNvIG11
Y2ggYXMgbWVldGluZyBleHBlY3RhdGlvbnMsIHBlcg0KPiA+ID4gPiA+IGB4bWwycmZjYCwgdGhl
DQo+ID4gPiA+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dp
bmcgaW4gdGhlDQo+ID4gPiA+IFJlZmVyZW5jZXMgc2VjdGlvbiwgd2hpY2ggdGhlbiBhdXRvLWV4
cGFuZHMgdG8gdGhlIGNvcnJlY3QNCj4gPiA+ID4gcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMg
ZGVmaW5pbmcgdGhlIGFuY2hvciAiSS1ELmlldGYtbmV0Y29uZi0NCj4gc3Vic2NyaWJlZC1ub3Rp
ZmljYXRpb25zIjoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICAgICAgPD9yZmMNCj4gPiA+ID4g
PiBpbmNsdWRlPSJyZWZlcmVuY2UuSS1ELmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNh
dGlvbnMiPz4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDxFcmljPiBUaGF0IGRlZmluaXRlbHkgbWFr
ZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQgSSBoYXZlIGJlZW4NCj4gPiA+ID4gPiBkb2luZy4g
IEkgYW0NCj4gPiA+ID4gaGl0dGluZyBhbiB4bWwycmZjIGVycm9yIHRyeWluZyB0aGlzIHJpZ2h0
IG5vdywgYnV0IEkgd2lsbCBnZXQgdGhlcmUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4g
PiA+IFllcywgaXQgd2FzIGFuIGV5ZS1vcGVuZXIgd2hlbiBJIGZpZ3VyZWQgaXQgb3V0LiAgIEJl
IGF3YXJlIHRoYXQsDQo+IHRob3VnaA0KPiA+IHNvbWUNCj4gPiA+ID4gZXh0ZXJuYWwgc291cmNl
cyAoZS5nLiwgSVRVIHN0YW5kYXJkcykgYXJlIHN1cHBvcnRlZCwgbWFueSBhcmUNCj4gPiA+ID4g
bm90LCBhbmQgc28gaGFuZC0gY29kaW5nIHRoZSA8cmVmZXJlbmNlPiBpcyBzdGlsbCBzb21ldGlt
ZXMNCj4gcmVxdWlyZWQuLi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gS2VudCAv
LyBzaGVwaGVyZA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0K


From nobody Fri May 10 02:15:07 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9312008C; Fri, 10 May 2019 02:15:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-subscribed-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund 
Message-ID: <155747970600.2789.18334490927763495053.idtracker@ietfa.amsl.com>
Date: Fri, 10 May 2019 02:15:06 -0700
Archived-At: 
Subject: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-subscribed-notifications-26: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 May 2019 09:15:06 -0000

Magnus Westerlund has entered the following ballot position for
draft-ietf-netconf-subscribed-notifications-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing the discuss and issues. I understand that there is
significant work in defining a solution that actually is capable of expressing
the receiver's need and provides the publisher with reasonable to process rules
and avoids the randomness in what happens in an overload situation. I hope the
community will consider how they deal with this issue going forward.



From nobody Fri May 10 08:39:02 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEFF12010E for ; Fri, 10 May 2019 08:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Cb5Sie8xSPPd for ; Fri, 10 May 2019 08:38:56 -0700 (PDT)
Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [216.205.24.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872BD1201DB for ; Fri, 10 May 2019 08:38:50 -0700 (PDT)
Received: from ex-hc2.corp.adtran.com (ex-hc3.adtran.com [76.164.174.83]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-323-v_N-I3JHNmeXLUYMMI0zFw-1; Fri, 10 May 2019 11:38:44 -0400
Received: from ex-mb3.corp.adtran.com ([fe80::60aa:f95:ad49:a0f1]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0382.000; Fri, 10 May 2019 10:38:43 -0500
From: Nick Hancock 
To: Kent Watsen 
CC: "netconf@ietf.org" 
Thread-Topic: [netconf] draft-ietf-netconf-keystore-09.txt
Thread-Index: AdT/Ypeae5Jx2/tnSQGaoI1kbpVxTQBV+RMAAAPy5nABIM/7AABubAow
Date: Fri, 10 May 2019 15:38:43 +0000
Message-ID: 
References:  <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@email.amazonses.com>  <0100016a9465d3e2-9e05e8e7-824c-41f8-985a-fc767147bc9c-000000@email.amazonses.com>
In-Reply-To: <0100016a9465d3e2-9e05e8e7-824c-41f8-985a-fc767147bc9c-000000@email.amazonses.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0FEVFJBTiIsImlkIjoiODdiMjFhYjctYTdkYi00OTM2LWJkZTMtOTY5ZDVkNmJhZjg5IiwicHJvcHMiOlt7Im4iOiJDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiR0IifV19LHsibiI6IlF1ZXN0aW9uMSIsInZhbHMiOltdfSx7Im4iOiJRdWVzdGlvbjIiLCJ2YWxzIjpbXX0seyJuIjoiUXVlc3Rpb24zIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTcuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkkzdGRtUVlKXC8zbEtzN1U0ZlhkbDhPYkdQNUhDYStxUUJPZkMwbjhaSlFoYzZGcnUra2tGeGJxQlFqWG85WmZoIn0=
x-originating-ip: [172.20.62.169]
x-c2processedorg: 13f501ad-3ef3-410f-a3f9-976ea23ce952
MIME-Version: 1.0
X-MC-Unique: v_N-I3JHNmeXLUYMMI0zFw-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 May 2019 15:39:00 -0000

Hi Kent,=20

> -----Original Message-----
> From: Kent Watsen 
> Sent: 08 May 2019 00:24
> To: Nick Hancock 
> Cc: netconf@ietf.org
> Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt
>=20
> Hi Nick,
>=20
>=20
> > Given that a client has the required permissions, the current model
> > allows a client to create an entry in the list 'asymmetric-key'
> > without the 3-tuple leafs 'algorithm', 'public-key' and 'private-key'
> > as allowed via the must statement on the list. At this point there
> > would be no 3-tuple in  either. Defining the 3-tuple in
> >  or  would be a second step, such as invoking
> > the action 'generate-hidden-key'. Since there is, as you indicated,
> > no 'must' statement relevant to the 'certificate' list, the model
> > also allows a client to configure a certificate (chain) on an entry
> > in the list 'asymmetric-key' without the 3-tuple in either 
> > or . The asymmetric key entry would not be able to be
> > used to establish a TLS session due to the missing 3-tuple, of course.
> >=20
> > Is this a valid use case? Possibly. I could argue that a client may
> > wish to 'park' certificate chains in the keystore without necessary
> > immediately using them on the server or even just pre-provision them
> > and then provide the actual public key later maybe through some other
> > process based on an operator's security policies? It makes no sense
> > to reference a certificate in the keystore that is missing the
> > 3-tuple as the server identity of a NETCONF server or client identity
> > of a NETCONF client as it cannot be used, so the question is whether
> > it would make more sense to constrain the actual reference to
> > reference certificates that have 3-tuple, if this is at all possible
> > considering that the 3-tuple may only be in ?
>=20
> If you look at my "wide-screen needed" email from last Friday, you'll see=
 that I'm
> trying to make a case that these 3-tuple nodes should be "mandatory true"=
. =A0 If
> that discussion falls apart, then we can revisit your proposal here.
>=20
> BTW, please jump into that discussion, as comments from implementations a=
re
> highly valued.
>=20
>=20
>=20
> > During analysis of deploying the keystore and truststore in our
> > implementation, I have made some further observations that may be of
> > interest:
>=20
> I see you're calling it "truststore", which I take as a confirmation for =
the rename
> proposal sent out last Thursday.
>=20
>=20
> >=20
> > 1. There is nothing in the model to prevent a client configuring a
> >=A0=A0certificate to an asymmetric key that is not applicable to that
> > =A0=A0asymmetric key or even a certificate chain in the keystore or
> > =A0=A0truststore that is incompatible to the required type
> > =A0=A0('end-entity-cert-cms' or 'trust-anchor-cert-cms' respectively)
> > =A0=A0or is this to be rejected by the implementation, in which case
> >=A0=A0this behavior is not described in the YANG?
>=20
> Such incompatibilities must not be allowed. =A0As neither issue can be en=
forced via
> YANG validation constraints, the best we can do is add comments to the
> description statements.
>=20
> For the latter case, I believe that both the=A0'end-entity-cert-cms' or '=
trust-anchor-
> cert-cms' description statements have a sufficient number of MUST stateme=
nts.
> - agreed?
>=20

Agreed.

> For the former, how about this:
>=20
> @@ -1614,7 +1624,9 @@=A0module ietf-crypto-types {
>=20
> =A0 =A0grouping asymmetric-key-pair-with-cert-grouping {
> =A0 =A0 =A0description
> -=A0 =A0 =A0=A0"A private/public key pair and an associated=A0certificate=
.";
> +=A0 =A0 =A0=A0"A private/public key pair and an associated=A0certificate=
.
> +=A0=A0 =A0 =A0=A0Implementations SHOULD assert that certificates=A0conta=
in
> +=A0=A0 =A0 =A0=A0the matching public key.";
>=20
> =A0 =A0 =A0uses asymmetric-key-pair-grouping;
> =A0 =A0 =A0uses end-entity-cert-grouping;
> @@ -1692,7 +1704,9 @@=A0module ietf-crypto-types {
>=20
> =A0 =A0grouping asymmetric-key-pair-with-certs-grouping {
> =A0 =A0 =A0description
> -=A0 =A0 =A0=A0"A private/public key pair and associated=A0certificates."=
;
> +=A0 =A0 =A0=A0"A private/public key pair and associated=A0certificates.
> +=A0=A0 =A0 =A0=A0Implementations SHOULD assert that certificates=A0conta=
in
> +=A0=A0 =A0 =A0=A0the matching public key.";
> =A0 =A0 =A0uses asymmetric-key-pair-grouping;
> =A0 =A0 =A0container certificates {
>=20

Yes, but I believe that these SHOULD statements should also be=20
included on the description statement of 'cert' leafs as well as they=20
may get overlooked, if they are only to be found in the description=20
statement on the groupings.

>=20
>=20
>=20
> > 2. I am not convinced whether the use of the prefix 'pinned-' on the
> >=A0containers and lists in ietf-trust-anchors is correct. The
> >=A0=A0certificates are available in the truststore for pinning, yes, but
> >=A0=A0does not the 'pinning' actually take place when the certificates
> >=A0=A0are configured for client authentication on a server or server
> >=A0=A0authentication on a client? So I would argue that a certificate
> >=A0=A0may be in the trust store, but not necessarily pinned, so the name
> >=A0=A0may be misleading or am I missing something? Thus, I would have
> >=A0=A0expected the containers and lists to be without the 'pinned-'
> >=A0=A0prefix within the truststore itself. The 'pinned-' prefix being
> >=A0=A0only on the references, which is the case in the NETCONF client
> >=A0=A0and server models.
>=20
>=20
> Agreed, especially with renaming the module and top-level container node =
to
> "truststore" (what else would a truststore contain, right?). =A0I just al=
l the "pinned"
> prefixes in my local copy (s/pinned.//g)
>=20
>=20
>=20
>=20
> > 3. As an initial step we are analyzing the standalone use of the
> > =A0=A0keystore in truststore modules and were considering some
> >=A0=A0proprietary notifications that would include the certificate
> >=A0=A0(chain) received during TLS session establishment, but could not
> >=A0=A0'use' the groupings in ietf-crypt-types because they include
> >=A0=A0actions and notifications, which are not allowed in notifications.
> >=A0=A0Maybe it would be advantageous to provide basic groupings without
> >=A0=A0actions and notifications for use in proprietary RPCs and
> >=A0=A0notifications and provide refined versions of these groupings that
> >=A0=A0include the actions and notifications? Obviously this would mean
> >=A0=A0even more groupings, but wouldn't this increase their reusability?
>=20
> I don't understand "standalone use of the keystore in truststore modules"=
 -
> maybe you meant "and"?

Yes, I meant 'and'.

>=20
> I know what you mean. =A0 I recently wanted to use some groupings from an=
other
> module but couldn't for a similar reason, and hence had a similar copy/pa=
ste
> yuck experience.
>=20
> If I understand you correctly, you're saying that tooling such as `pyang`=
 or
> `yanglint` is complaining because your notification "uses" the crypto-typ=
e
> grouping, which itself defines a notification - yes?

Yes, that is correct.

>=20
> RFC 7950 Section 7.16 says"
>=20
>    A notification MUST NOT be defined within an rpc, action, or another
>    notification, i.e., a notification node MUST NOT have an rpc, action,
>    or a notification node as one of its ancestors in the schema tree.
>    For example, this means that it is an error if a grouping that
>    contains a notification somewhere in its node hierarchy is used in an
>    rpc definition.
>=20
> Ouch, that's rather specific. =A0I was hoping there might be some wiggle =
room
> allowing for "inner" notifications to just be ignored. =A0That sounds lik=
e a better
> solution, don't you think, perhaps a YANG-Next candidate?
>=20

It would be a possible solution, but that is something for the future thoug=
h.

> You're right in guessing we're reluctant to create more groupings unneces=
sarily
> and, in this case, these groupings are very small - just a single "leaf" =
or "leaf-
> list", so the yuck isn't all that much. =A0Copy/paste might be reasonable=
 in this
> case, no?
>=20

Yes, copy/paste is always an option, but this also has its drawbacks,=20
including having multiple duplicate definitions within the YANG model;=20
the opportunity to modify the copy, intentionally or unintentionally,=20
such as to change the names of leafs; but most importantly copying and=20
pasting would mean that copy will not follow any changes made to=20
the original grouping, such as corrections and the addition of new=20
nodes in newer revisions, meaning additional maintenance and possible=20
discrepancies across YANG models going forward. =20
And this is why I am a keen user of groupings to ensure consistency=20
across models, even though it makes the YANG modules even harder to=20
read. If something is the same then it should always be the same=20
wherever is appears in the model and using a grouping does just that.

Regards
Nick


>=20
> Kent // contributor
>=20
>=20
>=20


From nobody Fri May 10 11:39:12 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0712003E; Fri, 10 May 2019 11:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgjODe7fn2rh; Fri, 10 May 2019 11:39:08 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C698712000E; Fri, 10 May 2019 11:39:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10194; q=dns/txt; s=iport; t=1557513548; x=1558723148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9SF5HdEyYvyBYH1mpU7EAjP/JYYW3nzLusiedPUdqh0=; b=RL0Z7zhClOYIJlTPLjTv1ECTeJpkc0vQ4FMbhvC9gnnxOf2Mt3sHMOEU IPjwOTcAIBhuvRtXOsqAwaV+EAKQ8aPAY5jqt2qhPNutCYT6Inru1mKuI sj6RViRjuNspR10kH0peCQovKBG443iObmGsbLl+9DViKcXIKJgFMTsi/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAADUxNVc/4sNJK1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYFmKoE9MCgKhAeIHI0DiT+PFIF7CQEBAQwBAS8BAYR?= =?us-ascii?q?AAheBdCM0CQ4BAwEBBAEBAgEEbSiFSgEBAQMBIxFDAgUHBAIBCBEEAQEBAgI?= =?us-ascii?q?JGgMCAgIfERQBCAgCBAENBQiCT0uBawMOD6xlgS+IAA2CI4ELJwGLTheBQD+?= =?us-ascii?q?EIz6CGoIxM4JQglgEixsDgg8smT45CQKCCYomhF6DTSOCE4ZLBY0GgyCJEYE?= =?us-ascii?q?ihwCMYQIRFYEwHziBV3AVgyeQUUExj1iBIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,454,1549929600"; d="scan'208";a="271621247"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 May 2019 18:39:06 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4AId6AE028349 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 May 2019 18:39:06 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 14:39:05 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Fri, 10 May 2019 14:39:05 -0400
From: "Eric Voit (evoit)" 
To: Dhruv Dhody , Dhruv Dhody ,  Kent Watsen 
CC: "rtg-dir@ietf.org" , "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" , "" 
Thread-Topic: RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZU7OSwgAI1bICACP37sIAAYi6AgACOyoCAAFnN8IABEe2AgADU50CAALPMAIAAqWnw
Date: Fri, 10 May 2019 18:39:05 +0000
Message-ID: <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com>
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>     <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.232]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 May 2019 18:39:11 -0000

SGkgRGhydXYsDQpIaSBLZW50LA0KDQo+IEZyb206IERocnV2IERob2R5LCBNYXkgOSwgMjAxOSAx
MToyOCBQTQ0KPiANCj4gSGkgRXJpYywNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gPiBGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0N
Cj4gPiBTZW50OiAxMCBNYXkgMjAxOSAwMjoxOA0KPiA+IFRvOiBEaHJ1diBEaG9keSA8ZGhydXYu
aWV0ZkBnbWFpbC5jb20+DQo+ID4gQ2M6IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5l
dD47IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQo+ID4gbmV0Y29uZi1uZXRjb25mLWV2
ZW50LW5vdGlmaWNhdGlvbnMuYWxsQGlldGYub3JnOyBuZXRjb25mQGlldGYub3JnOw0KPiA+IERo
cnV2IERob2R5IDxkaHJ1di5kaG9keUBodWF3ZWkuY29tPjsgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+
ID4gPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6IGRy
YWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LQ0KPiA+IG5vdGlmaWNhdGlvbnMtMTcNCj4g
Pg0KPiA+IEhpIERocnV2LA0KPiA+DQo+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDksIDIw
MTkgMTI6MDMgQU0NCj4gPiA+DQo+ID4gPiBIaSBFcmljLA0KPiA+ID4NCj4gPiA+IFRoYW5rcyBm
b3IgdGhlIHVwZGF0ZS4gSSBzZWUgb25lIG1pbm9yIGNvbW1lbnQgdGhhdCBpcyBub3QgaGFuZGxl
ZC4NCj4gPiA+IE1heWJlIHlvdSBtaXNzZWQgaXQ/IE9yIHlvdSBkaXNhZ3JlZSwgdGhhdCBzb21l
IG1vcmUgdGV4dCBpcyByZXF1aXJlZD8NCj4gPiA+DQo+ID4gPiA+IE1pbm9yIElzc3VlczoNCj4g
PiA+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiAoMSkgQWJzdHJhY3QgJiBJbnRyb2R1Y3Rpb24s
IEl0IGlzIG5vdCBjbGVhciB3aGF0IGRvZXMgdGhlICdiaW5kaW5nJw0KPiA+ID4gPiBtZWFuIGFu
ZCB3aG8gYXJlIHRoZSBwYXJ0aWVzIHRvIHRoaXMgYmluZGluZz8gSWYgdGhpcyBpcyB0aGUNCj4g
PiA+ID4gZG9jdW1lbnQgdGhhdA0KPiA+ID4gbWVudGlvbnMgJ2JpbmRpbmcnDQo+ID4gPiA+IGZp
cnN0LCBzbyBwbGVhc2UgYWRkIHNvbWUgbW9yZSBjbGFyaWZ5aW5nIHRleHQuDQo+ID4NCj4gPiBU
aGlzIGlzIG5vdCB0aGUgZmlyc3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBm
aXJzdC4gIFRoZQ0KPiA+IGRvY3VtZW50IHdoaWNoIGRvZXMgdGhpcyBmaXJzdCBpcyBkcmFmdC1p
ZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC0NCj4gPiBub3RpZmljYXRpb25zLg0KPiBbW0RocnV2IERo
b2R5XV0gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBzYXlzIHRo
aXMgaW4gdGhlDQo+IEludHJvZHVjdGlvbiAtDQo+IA0KPiAgICBXaGlsZSB0aGUgZnVuY3Rpb25h
bGl0eSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgdHJhbnNwb3J0LQ0KPiAgICBhZ25vc3Rp
YywgdHJhbnNwb3J0cyBsaWtlIE5FVENPTkYgW1JGQzYyNDFdIG9yIFJFU1RDT05GIFtSRkM4MDQw
XSBjYW4NCj4gICAgYmUgdXNlZCB0byBjb25maWd1cmUgb3IgZHluYW1pY2FsbHkgc2lnbmFsIHN1
YnNjcmlwdGlvbnMsIGFuZCB0aGVyZQ0KPiAgICBhcmUgYmluZGluZ3MgZGVmaW5lZCBmb3Igc3Vi
c2NyaWJlZCBldmVudCByZWNvcmQgZGVsaXZlcnkgZm9yIE5FVENPTkYNCj4gICAgd2l0aGluIFtJ
LUQuZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9uc10sIGFuZCBm
b3INCj4gICAgUkVTVENPTkYgd2l0aGluIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m
LW5vdGlmXS4NCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBvbmx5IHRpbWUgYmluZGluZyBpcyB1c2Vk
IGluIHRoaXMgY29udGV4dC4NCj4gQW5kIG5vdyB0aGlzIEktRCBzYXlzIC0NCj4gDQo+ICAgIFRo
aXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVudHMgc3RyZWFtZWQgb3ZlciB0
aGUgTkVUQ09ORg0KPiAgICBwcm90b2NvbCBbUkZDNjI0MV0gZm9yIGR5bmFtaWMgc3Vic2NyaXB0
aW9ucyBhcyBkZWZpbmVkIGluDQo+ICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli
ZWQtbm90aWZpY2F0aW9uc10uDQo+IA0KPiBBbmQgeW91IGRvbuKAmXQgdXNlIHRoaXMgdGVybSBl
dmVyIGFnYWluLg0KPiANCj4gVG8gbWUgdGhpcyBpcyBiaXQgY2lyY3VsYXIgYW5kIHRoZSB0ZXJt
IGJpbmRpbmcgaXMgdXNlZCBsb29zZWx5LiBBbmQgdGh1cyBJIGZsYWdnZWQNCj4gaXQuIEkgd2ls
bCBsZXQgeW91IGFuZCBLZW50IGRlY2lkZSB0aGUgcmlnaHQgYXBwcm9hY2guDQoNCkkgcmVhbGx5
IGFtIG9rIHdpdGggbWFueSBvcHRpb25zIGhlcmU6DQogKGEpICBrZWVwIHRoZSBjdXJyZW50IHRl
eHQuICANCiAoYikgIHVzZSBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgYWJzdHJhY3QuICANCiAo
YykgIHJlcGxhY2UgdGhlIHdvcmQgYmluZGluZyB3aXRoIHNvbWUgb3RoZXIgdGV4dC4gICANCg0K
R2V0dGluZyB0aGUgcmlnaHQgd29yZHMgaGVyZSBuYWlsZWQgZG93biBoYXNuJ3QgYmVlbiBmcm9t
IGxhY2sgb2YgZWZmb3J0LiAgVG8gZ2l2ZSB5b3UgYW4gaWRlYSwgYmVsb3cgYXJlIGZvdXIgcHJl
dmlvdXMgYXR0ZW1wdHMgYXQgdGhlIGFic3RyYWN0Lg0KDQpGcm9tIC12NQ0KDQogICBUaGlzIGRv
Y3VtZW50IGRlZmluZXMgaG93IHRvIHRyYW5zcG9ydCBuZXR3b3JrIHN1YnNjcmlwdGlvbnMgYW5k
DQogICBldmVudCBtZXNzYWdlcyBvbiB0b3Agb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBw
cm90b2NvbA0KICAgKE5FVENPTkYpLiAgVGhpcyBpbmNsdWRlcyB0aGUgZnVsbCBzZXQgb2YgUlBD
cywgc3Vic2NyaXB0aW9uIHN0YXRlDQogICBjaGFuZ2VzLCBhbmQgc3Vic2NyaWJlZCBjb250ZW50
IG5lZWRpbmcgYXN5bmNocm9ub3VzIGRlbGl2ZXJ5Lg0KDQoNCkZyb20gLXY2IA0KIA0KICAgVGhp
cyBkb2N1bWVudCBwcm92aWRlcyBhIE5FVENPTkYgYmluZGluZyBmb3INCiAgIFtJLUQuZHJhZnQt
aWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10uICBJbmNsdWRlZCBhcmU6DQoN
CiAgIG8gIFRyYW5zcG9ydCBtYXBwaW5ncyBmb3Igc3Vic2NyaXB0aW9uIFJQQ3MsIHN0YXRlIGNo
YW5nZQ0KICAgICAgbm90aWZpY2F0aW9ucywgYW5kIG5vdGlmaWNhdGlvbiBtZXNzYWdlcw0KDQog
ICBvICBGdW5jdGlvbmFsaXR5IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdpdGggTkVUQ09ORg0K
DQogICBvICBFeGFtcGxlcyBpbiBhcHBlbmRpY2VzDQoNCg0KRnJvbSAtdjcNCg0KICAgVGhpcyBk
b2N1bWVudCBwcm92aWRlcyBhIE5FVENPTkYgYmluZGluZyBmb3INCiAgIFtJLUQuZHJhZnQtaWV0
Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10gYW5kDQogICBbSS1ELmlldGYtbmV0
Y29uZi15YW5nLXB1c2hdLiAgSW5jbHVkZWQgYXJlOg0KDQogICBvICB0cmFuc3BvcnQgbWFwcGlu
Z3MgZm9yIHN1YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFuZ2UNCiAgICAgIG5vdGlmaWNhdGlv
bnMsIGFuZCBub3RpZmljYXRpb24gbWVzc2FnZXMsDQogICBvICBmdW5jdGlvbmFsIHJlcXVpcmVt
ZW50cywgYW5kDQogICBvICBleGFtcGxlcw0KDQoNCkZyb20gLXY4DQoNCiAgIFRoaXMgZG9jdW1l
bnQgcHJvdmlkZXMgYSBORVRDT05GIGJpbmRpbmcgdG8gc3Vic2NyaWJlZCBub3RpZmljYXRpb25z
DQogICBhbmQgdG8gWUFORyBwdXNoLg0KDQoNCkhvbmVzdGx5IEkgbGlrZSB0aGUgdjUgdmVyc2lv
bi4gICBCdXQgcHJldmlvdXMgcmV2aWV3ZXJzIGhhdmUgaW5jcmVtZW50YWxseSBkcml2ZW4gdGhp
bmdzIHRvIHRoZSBjdXJyZW50IHRleHQuICAgIElmIEtlbnQgeW91IHByZWZlciBzb21ldGhpbmcg
b3RoZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0LCBsZXQgbWUga25vdyB3aGF0IGl0IGlzLiAgSSBh
bSBzdXJlIEkgd2lsbCBsaWtlIGl0IHRvby4NCg0KRXJpYyANCg0KDQo+IFRoYW5rcyENCj4gRGhy
dXYNCj4gDQo+IA0KPiA+IEluIHRoZSBhYnN0cmFjdCBvZiB0aGlzIGRvY3VtZW50LCB0aGF0IGRy
YWZ0IGlzIG5vdCBleHBsaWNpdGx5IGxpc3RlZA0KPiA+IGJ5IHJlZmVyZW5jZSAoYXMgSSB1bmRl
cnN0b29kIHdlIGFyZSBub3Qgc3VwcG9zZWQgdG8gdXNlIHJlZmVyZW5jZXMgaW4NCj4gPiBhYnN0
cmFjdHMpLiAgQnV0IGl0IGlzIGxpc3RlZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiA+DQo+ID4g
VG8gbWFrZSB0aGlzIGNsZWFyZXIgZm9yIHlvdSBpbiB0aGlzIGRvY3VtZW50LCBwZXJoYXBzICJ0
cmFuc3BvcnQgYmluZGluZyINCj4gPiBpbnN0ZWFkIG9mICJiaW5kaW5nIj8gICBJIHJlYWxseSBk
b24ndCBoYXZlIG1hbnkgYWx0ZXJuYXRpdmVzIEkgY2FuIHRoaW5rDQo+ID4gb2Ygd2hpY2ggYWxz
byBrZWVwcyB0aGUgdGV4dCBicmllZi4gICBUaGlzIHBhcnRpY3VsYXIgdGV4dCBoYXMgYmVlbg0K
PiA+IGZyZXF1ZW50bHkgdHdlYWtlZCBpbiB0aGUgcGFzdC4NCj4gPg0KPiA+IFRoYW5rcy4NCj4g
PiBFcmljDQo+ID4NCj4gPg0KPiA+ID4gVGhhbmtzIQ0KPiA+ID4gRGhydXY+DQo+ID4gPiBPbiBX
ZWQsIE1heSA4LCAyMDE5IGF0IDk6MTQgUE0gRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2Nv
LmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBX
aXRoIHRoZSBjb3JyZXNwb25kaW5nIGNoYW5nZSB0byBkcmFmdC1pZXRmLQ0KPiA+IG5ldGNvbmYt
DQo+ID4gPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcG9zdGVkIGFzIC12MjUuDQo+ID4gPiA+
DQo+ID4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5
IDgsIDIwMTkgMjoyMSBBTQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgS2VudCwgRXJpYywNCj4g
PiA+ID4gPg0KPiA+ID4gPiA+IEZpbmUgd2l0aCBtZSENCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRo
YW5rcyENCj4gPiA+ID4gPiBEaHJ1dg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gV2VkLCBNYXkg
OCwgMjAxOSBhdCAzOjE5IEFNIEtlbnQgV2F0c2VuDQo+ID4gPiA+ID4gPGtlbnQraWV0ZkB3YXRz
ZW4ubmV0Pg0KPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiA8ZXJpYz4gQmFzZWQgb24gbXkgcmVhZGluZyBvZiB5b3VyIHByb2Nl
c3Mgc3VnZ2VzdGlvbnMgS2VudCwgSQ0KPiA+ID4gPiA+ID4gbGlrZSBiZXN0IHRoZQ0KPiA+ID4g
PiA+IOKAnG1lbnRpb27igJ0gYXBwcm9hY2ggd2hpY2ggeW91IHVzZWQgZm9yIFJGQy04MDcxLCBT
ZWN0aW9uIDEuNC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBXaGF0IEkgdGhpbmsgY291bGQg
YmUgZG9uZSB0byBjb3ZlciB0aGlzIGlzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IChBKSAg
UmVtb3ZlIFNlY3Rpb24gMTE6IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+ID4gPg0K
PiA+ID4gPiA+ID4gKEIpICBQZXIgS2VudOKAmXMgZGVzaXJlIHRvIGFsc28gY292ZXINCj4gPiA+
ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiwgcGxhY2UgdGhlDQo+ID4g
PiA+ID4gZm9sbG93aW5nIHN0YXRlbWVudCBpbnRvDQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi1uZXRj
b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gPiA+IGRpcmVjdGx5IGFmdGVyIEZp
Z3VyZSAxMA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlvbiAyLjIu
MSBzdGF0ZXMgdGhhdCBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzDQo+ID4gPiA+ID4gPiB0byBi
ZSBzZW50IHRvIGENCj4gPiA+ID4gPiBzdWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhICJjcmVh
dGUtc3Vic2NyaXB0aW9uIi4gICBXaXRoIHRoaXMNCj4gPiBzcGVjaWZpY2F0aW9uLA0KPiA+ID4g
dGhpcw0KPiA+ID4gPiA+IFJGQy01Mjc3IHN0YXRlbWVudCBzaG91bGQgYmUgbW9yZSBicm9hZGx5
IGludGVycHJldGVkIHRvIG1lYW4NCj4gPiA+ID4gPiB0aGF0IG5vdGlmaWNhdGlvbiBtZXNzYWdl
cyBjYW4gYWxzbyBiZSBzZW50IHRvIGEgc3Vic2NyaWJlcg0KPiA+ID4gPiA+IHdoaWNoIGluaXRp
YXRlZCBhbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIsIG9yIGEgY29uZmlndXJlZA0KPiA+ID4g
PiA+IHJlY2VpdmVyIHdoaWNoIGhhcyBiZWVuIHNlbnQgYSDigJxzdWJzY3JpcHRpb24tc3RhcnRl
ZOKAnS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBEb2VzIHRoaXMgd29yayBmb3IgYm90aCBv
ZiB5b3U/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFdvcmtzIGZvciBt
ZS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRo
ZSBpc3N1ZSBpc24ndCBjb25zaXN0ZW5jeSBzbyBtdWNoIGFzIG1lZXRpbmcgZXhwZWN0YXRpb25z
LA0KPiA+ID4gPiA+ID4gcGVyIGB4bWwycmZjYCwgdGhlDQo+ID4gPiA+ID4gZG9jdW1lbnQgc2hv
dWxkIGhhdmUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyBpbiB0aGUNCj4gPiA+ID4gPiBS
ZWZlcmVuY2VzIHNlY3Rpb24sIHdoaWNoIHRoZW4gYXV0by1leHBhbmRzIHRvIHRoZSBjb3JyZWN0
DQo+ID4gPiA+ID4gcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMgZGVmaW5pbmcgdGhlIGFuY2hv
cg0KPiA+ID4gPiA+ICJJLUQuaWV0Zi1uZXRjb25mLQ0KPiA+IHN1YnNjcmliZWQtbm90aWZpY2F0
aW9ucyI6DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgICA8P3JmYw0KPiA+ID4gPiA+
ID4gaW5jbHVkZT0icmVmZXJlbmNlLkktRC5pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmlj
YXRpb25zIj8NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA8RXJpYz4g
VGhhdCBkZWZpbml0ZWx5IG1ha2VzIHRoaW5ncyBlYXNpZXIgdGhhbiB3aGF0IEkgaGF2ZQ0KPiA+
ID4gPiA+ID4gYmVlbiBkb2luZy4gIEkgYW0NCj4gPiA+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMg
ZXJyb3IgdHJ5aW5nIHRoaXMgcmlnaHQgbm93LCBidXQgSSB3aWxsIGdldCB0aGVyZS4NCj4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gWWVzLCBpdCB3YXMgYW4gZXllLW9wZW5l
ciB3aGVuIEkgZmlndXJlZCBpdCBvdXQuICAgQmUgYXdhcmUgdGhhdCwNCj4gPiB0aG91Z2gNCj4g
PiA+IHNvbWUNCj4gPiA+ID4gPiBleHRlcm5hbCBzb3VyY2VzIChlLmcuLCBJVFUgc3RhbmRhcmRz
KSBhcmUgc3VwcG9ydGVkLCBtYW55IGFyZQ0KPiA+ID4gPiA+IG5vdCwgYW5kIHNvIGhhbmQtIGNv
ZGluZyB0aGUgPHJlZmVyZW5jZT4gaXMgc3RpbGwgc29tZXRpbWVzDQo+ID4gcmVxdWlyZWQuLi4N
Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gS2VudCAvLyBzaGVwaGVyZA0K
PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0K


From nobody Fri May 10 14:55:28 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8231812006B; Fri, 10 May 2019 14:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 header.b=LZp96nKV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AcP/BLXL
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlG9W7WizfHl; Fri, 10 May 2019 14:55:13 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866B012004B; Fri, 10 May 2019 14:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15146; q=dns/txt; s=iport; t=1557525312; x=1558734912; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/REhYnrUTkB7BicMPE2phFOGJV7XTwSFx9NdBzAgk2M=; b=LZp96nKVttHptVcjijIQGJ99Scvic+IWjbAFXgL6xFDrux6KWebL13if Rftv1SC2VZJvRmgGFodnbSSyrGD4HpH6fYhe5FgPb4ruxdy78s+dBZuym opPP3WvwT4I4xAJ13oqqiGmOcsLgazmPBDzmNwwUY+cGEDp7PH8ElU8UH w=;
IronPort-PHdr: =?us-ascii?q?9a23=3AtfH9fxZ80gJdQAl4rk0QE4z/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwdSU6Gc1EfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AABb8tVc/51dJa1kDhABBgcGgVE?= =?us-ascii?q?JCwGBPSknA2lVIAQLKAqEB4NHA45+mXyBLhSBEANUCQEBAQwBASMKAgEBhEA?= =?us-ascii?q?CF4F0IzQJDgEDAQEEAQECAQRtHAyFSwIEEhERDAEBNwEPAgEIGgIJHQICAjA?= =?us-ascii?q?VEAIEAQ0FIoI1SwGBagMdAQ6iQgKBNYhfcYEvgnkBAQWBMgETQYJ5GIIPAwa?= =?us-ascii?q?BCycBi04XgUA/gREnH4JMPoJhAgECAYFFAi0hAoJQMoImiyKCO5l3CQKCCYY?= =?us-ascii?q?fhDiEMYNRG4IThkuNC4tqR4UwgSSOLwIEAgQFAg4BAQWBTzgpgRURCHAVOyo?= =?us-ascii?q?BgkGCDwwXFG0BCIJChRSFBDoBcgGBKI4tAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.60,454,1549929600"; d="scan'208";a="558025084"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 May 2019 21:55:11 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4ALtB1b030676 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 May 2019 21:55:11 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 16:55:10 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 16:55:10 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 10 May 2019 16:55:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/REhYnrUTkB7BicMPE2phFOGJV7XTwSFx9NdBzAgk2M=; b=AcP/BLXLiN3MGoGXePXbeoUZVcG592/VMyUBQZlryvux6PyKLldDWMyIRv4swPiPVGWyKclclZmR2iaPqbHkAvonBY6f0kCK9T2nlWA5T60BYzb7lbqwRG8d3rJTs5NpAHX5IIrI3n0oIVRxm/yvolz6wIucMI2yCFhpgJ6QHEo=
Received: from CY4PR1101MB2102.namprd11.prod.outlook.com (10.172.79.15) by CY4PR1101MB2167.namprd11.prod.outlook.com (10.172.77.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Fri, 10 May 2019 21:55:08 +0000
Received: from CY4PR1101MB2102.namprd11.prod.outlook.com ([fe80::74d1:4a6:a89c:6e04]) by CY4PR1101MB2102.namprd11.prod.outlook.com ([fe80::74d1:4a6:a89c:6e04%6]) with mapi id 15.20.1856.012; Fri, 10 May 2019 21:55:08 +0000
From: "Reshad Rahman (rrahman)" 
To: Benjamin Kaduk , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
Thread-Index: AQHVBRe+rV3duncRlUSQ6Gy9iRmrQ6ZkqNGA
Date: Fri, 10 May 2019 21:55:08 +0000
Message-ID: <6F96C6CD-B0F1-44F2-A2BE-E2FD23B309CC@cisco.com>
References: <155726272794.32635.6531627027808857417.idtracker@ietfa.amsl.com>
In-Reply-To: <155726272794.32635.6531627027808857417.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.94]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eee63999-0fdc-4909-9b86-08d6d5922b50
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR1101MB2167; 
x-ms-traffictypediagnostic: CY4PR1101MB2167:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(136003)(376002)(189003)(51914003)(199004)(256004)(66066001)(478600001)(4326008)(14444005)(54906003)(966005)(11346002)(446003)(2906002)(82746002)(102836004)(58126008)(186003)(6506007)(316002)(25786009)(76176011)(5660300002)(110136005)(26005)(81156014)(68736007)(6306002)(36756003)(6116002)(3846002)(83716004)(53936002)(33656002)(6436002)(305945005)(64756008)(6512007)(229853002)(73956011)(66556008)(8676002)(486006)(71200400001)(99286004)(66476007)(76116006)(91956017)(2171002)(71190400001)(66946007)(8936002)(476003)(81166006)(14454004)(2616005)(7736002)(6246003)(86362001)(6486002)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2167; H:CY4PR1101MB2102.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ZoRfBfvdUY577jwN7UReMvSMBjPO8Xp1YfbingxSahyTsXfBlu7iw/XyaeeiOPg4IqYFdZ91lL7AUwlx1kxVnISedKhWhDn1EAZi7Q+wYlXrDN1KOLsvVmT+LjC5s3oEaNwFBEduHxw7a09Zdj0HlFCLJsnm5585ivcjill4Uq+9z3TMl8514yJrakb362Jlr6HM+AHBSfT1sZfmcq9EM/1AEO6vvjeOh0qL2Z178wnJWwQJpY+H824vIxmqwBzZsT+i9ioJosVKt2v38bX306zJ1FeVfT0mTxvk+xMS1ipZ7b/86nAY/SDyJ0lKqIPNTHEQiX63VM+vR72DaNpYXozuPILs0ZFvdkMw/25C5//ZL/U/x66duDbOyw34MNLcj1YkMnd2cwLHbS5z2KHTKL0fmGCCLx8biY2VI4kkw9Q=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: eee63999-0fdc-4909-9b86-08d6d5922b50
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 21:55:08.7097 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2167
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 May 2019 21:55:17 -0000

SGksDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldywgcGxlYXNlIHNlZSBpbmxpbmUuDQoNCu+7v09u
IDIwMTktMDUtMDcsIDQ6NTkgUE0sICJCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIiIDxu
b3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIEJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVk
IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRyYWZ0LWlldGYtbmV0Y29u
Zi1yZXN0Y29uZi1ub3RpZi0xMzogRGlzY3Vzcw0KICAgICAgICANCiAgICBQbGVhc2UgcmVmZXIg
dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o
dG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01N
RU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg
b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlm
Lw0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBESVNDVVNTOg0KICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICBUaGFua3MgZm9yIHRoZSB3ZWxsLXdyaXR0ZW4gZG9j
dW1lbnQhICBJICBqdXN0IGhhdmUgc29tZSBib3JpbmcgaG91c2VjbGVhbmluZw0KICAgIHBvaW50
cyB0aGF0IHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUuDQogICAgDQogICAgU2VjdGlvbiAzLjIg
c3RhdGVzOg0KICAgIA0KICAgICAgIFN1YnNjcmliZXJzIGNhbiBsZWFybiB3aGF0IGV2ZW50IHN0
cmVhbXMgYSBSRVNUQ09ORiBzZXJ2ZXIgc3VwcG9ydHMNCiAgICAgICBieSBxdWVyeWluZyB0aGUg
InN0cmVhbXMiIGNvbnRhaW5lciBvZiBpZXRmLXN1YnNjcmliZWQtDQogICAgICAgbm90aWZpY2F0
aW9uLnlhbmcgaW4NCiAgICAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v
dGlmaWNhdGlvbnNdLiAgU3VwcG9ydCBmb3IgdGhlDQogICAgICAgInN0cmVhbXMiIGNvbnRhaW5l
ciBvZiBpZXRmLXJlc3Rjb25mLW1vbml0b3JpbmcueWFuZyBpbiBbUkZDODA0MF0gaXMNCiAgICAg
ICBub3QgcmVxdWlyZWQuICBJZiBpdCBpcyBzdXBwb3J0ZWQsIHRoZSBldmVudCBzdHJlYW1zIHdo
aWNoIGFyZSBpbiB0aGUNCiAgICAgICAic3RyZWFtcyIgY29udGFpbmVyIG9mIGlldGYtc3Vic2Ny
aWJlZC1ub3RpZmljYXRpb25zLnlhbmcgU0hPVUxEIGFsc28NCiAgICAgICBiZSBpbiB0aGUgInN0
cmVhbXMiIGNvbnRhaW5lciBvZiBpZXRmLXJlc3Rjb25mLW1vbml0b3JpbmcueWFuZy4NCiAgICAN
CiAgICBUaGlzICJTSE9VTEQiIHNlZW1zIHRvIGJlIGF0dGVtcHRpbmcgdG8gaW1wb3NlIGEgbm9y
bWF0aXZlIHJlcXVpcmVtZW50DQogICAgb24gc3BlY2lmaWNhdGlvbnMgdGhhdCBpbXBsZW1lbnQN
CiAgICBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGFuZCBSRkMg
ODA0MCBzdHJlYW1zLA0KICAgIHdpdGhvdXQgcmVnYXJkIHRvIHdoZXRoZXIgdGhleSBpbXBsZW1l
bnQgdGhpcyBzcGVjaWZpY2F0aW9uLiAgSXQgc2VlbXMNCiAgICBiZXR0ZXItcGxhY2VkIGluIGRy
YWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMuDQo8UlI+IFJGQzgwNDAg
aXMgdGhlIFJFU1RDT05GIFJGQyBhbmQgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGlzIG5vdCB0
cmFuc3BvcnQgc3BlY2lmaWMuIFNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgZm9yIFJFU1RDT05GLCB0
aGlzIGlzIHdoeSB3ZSBoYXZlIGFkZGVkIHRoaXMgc3RhdGVtZW50IGluIHRoaXMgZG9jdW1lbnQu
DQoNCiAgICBTaW1pbGFybHksIHdoZW4gU2VjdGlvbiA0IHdyaXRlczoNCiAgICANCiAgICAgICBU
byBtZWV0IHN1YnNjcmlwdGlvbiBxdWFsaXR5IG9mIHNlcnZpY2UgcHJvbWlzZXMsIHRoZSBwdWJs
aXNoZXIgTVVTVA0KICAgICAgIHRha2UgYW55IGV4aXN0aW5nIHN1YnNjcmlwdGlvbiAiZHNjcCIg
YW5kIGFwcGx5IGl0IHRvIHRoZSBEU0NQDQogICAgICAgbWFya2luZyBpbiB0aGUgSVAgaGVhZGVy
Lg0KICAgIA0KICAgIHRoYXQgc2VlbXMgdG8gYmUgZHVwbGljYXRpbmcgYSBub3JtYXRpdmUgcmVx
dWlyZW1lbnQgZnJvbSB0aGUgY29yZQ0KICAgIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBkb2N1
bWVudC4gIChBbmQgSSdtIHN1cmUgTWFnbnVzIHdpbGwgaGF2ZQ0KICAgIGZ1cnRoZXIgZm9sbG93
LXVwIGFib3V0IGhvdyBEU0NQIG1hcmtpbmdzIGFyZSBwZXItY29ubmVjdGlvbiBmb3IgdGhlDQog
ICAgc3RyZWFtIHRyYW5zcG9ydHMgd2UgaGF2ZSBhdmFpbGFibGUsIGFzIHdlbGwuKQ0KPFJSPiBZ
b3UgYXJlIGNvcnJlY3QsIHRoaXMgdGV4dCBjYW4gYmUgcmVtb3ZlZC4gICBJIGNhbiByZXBsYWNl
IGl0IHdpdGggYSByZWZlcmVuY2UgdG8gdGhlIHNlY3Rpb24gaW4gc3Vic2NyaWJlZC1ub3RpZmlj
YXRpb25zLCB3b3VsZCB0aGF0IHdvcmsgZm9yIHlvdT8NCg0KICAgIA0KICAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICBUaGUgY29yZSBz
dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgZG9jdW1lbnQgbm90ZXMgdGhhdCBkeW5hbWljDQogICAg
c3Vic2NyaXB0aW9ucyBvbmx5IGxhc3QgYXMgbG9uZyBhcyB0aGUgdW5kZXJseWluZyB0cmFuc3Bv
cnQuICBJbiB0aGlzDQogICAgZG9jdW1lbnQsIHdlIGhhdmUgdHdvIGNvbm5lY3Rpb25zIGluIEZp
Z3VyZSAxLCB3aGljaCBjb3VsZCBwb3RlbnRpYWxseQ0KICAgIGJlIHNlcGFyYXRlIFRDUC9UTFMg
Y29ubmVjdGlvbnMgKG9yIEhUVFAvMiBzdHJlYW1zKS4gIEluIHRoZSAidHdvIFRDUA0KICAgIGNv
bm5lY3Rpb25zIiBjYXNlLCBkb2VzIHRlcm1pbmF0aW5nIGVpdGhlciBvbmUgY2F1c2UgdGhlIGNl
c3NhdGlvbiBvZg0KICAgIHRoZSBzdWJzY3JpcHRpb24sIG9yIGp1c3QgKGIpPw0KPFJSPiBUaGVy
ZSBhcmUgbm8gImxvbmctbGl2ZWQgUkVTVENPTkYgc2Vzc2lvbnMiLiBUZXJtaW5hdGluZyAoYSkg
ZG9lcyBub3QgdGVybWluYXRlIHRoZSBzdWJzY3JpcHRpb24uDQogICAgDQogICAgU2VjdGlvbiAy
DQogICAgDQogICAgUGxlYXNlIHVzZSB0aGUgYm9pbGVycGxhdGUgZnJvbSBSRkMgODE3NC4NCjxS
Uj4gQWNrLCB3aWxsIGRvIGluIG5leHQgcmV2Lg0KICAgIA0KICAgIFNlY3Rpb24gMw0KICAgIA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWUFORyBkYXRhc3RvcmUg
c3Vic2NyaXB0aW9uIGlzDQogICAgICAgYWNjb21wbGlzaGVkIHZpYSBhdWdtZW50YXRpb25zIHRv
DQogICAgICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z
XSBhcyBkZXNjcmliZWQgd2l0aGluDQogICAgICAgW0ktRC5pZXRmLW5ldGNvbmYteWFuZy1wdXNo
XSBTZWN0aW9uIDQuNC4NCiAgICANCiAgICBJIHNlZSBzb21lIHJldmlld2VycyBjb21tZW50ZWQg
dGhhdCB0aGluZ3Mgd2VyZSBhIGJpdCB0ZXJzZS9hcmNhbmU7IEkNCiAgICBtaWdodCBzdWdnZXN0
IHRoYXQgInZpYSBhdWdtZW50YXRpb25zIHRvIFtzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnNdIiBp
cw0KICAgIG5vdCByZWFsbHkgYWRkaW5nIG11Y2ggaGVyZSwgYW5kIHRoZSB5YW5nLXB1c2ggUlBD
cyBhcmUgdGhlIGltcG9ydGFudA0KICAgIHBhcnQuDQo8UlI+IFRoZSBhdWdtZW50YXRpb24gdG8g
c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGlzIG1lbnRpb25lZCBiZWNhdXNlIGl0IGlzIG5lZWRl
ZCBmb3IgUkVTVENPTkYuIEFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBjaGFuZ2UgdGhpcyB0byAiLi4u
YWNjb21wbGlzaGVkIGFzIGRlc2NyaWJlZCBpbiAgW0ktRC5pZXRmLW5ldGNvbmYteWFuZy1wdXNo
XSBTZWN0aW9uIDQuNC4iPw0KICAgIA0KICAgIFNlY3Rpb24gMy4xDQogICAgDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hlcmUg
cXVpY2sNCiAgICAgICByZWNvZ25pdGlvbiBvZiB0aGUgbG9zcyBvZiBhIHB1Ymxpc2hlciBpcyBy
ZXF1aXJlZCwgYSBzdWJzY3JpYmVyDQogICAgICAgU0hPVUxEIHVzZSBhIFRMUyBoZWFydGJlYXQg
W1JGQzY1MjBdLCBqdXN0IGZyb20gcmVjZWl2ZXIgdG8NCiAgICAgICBwdWJsaXNoZXIsIHRvIHRy
YWNrIEhUVFAgc2Vzc2lvbiBjb250aW51aXR5Lg0KICAgIA0KICAgIFRMUyBoZWFydGJlYXRzIHJl
cXVpcmUgaW5pdGlhdGlvbiBieSB0aGUgVExTIGNsaWVudCwgYnkgdmlydHVlIG9mDQogICAgaW5j
bHVkaW5nIHRoZSBIZWFydGJlYXRFeHRlbnNpb24gaW4gdGhlIENsaWVudEhlbGxvLiAgV2hvIGlz
IGdvaW5nIHRvIGJlDQogICAgbWFraW5nIHRoZSBkZXRlcm1pbmF0aW9uIHRoYXQgcXVpY2sgcmVj
b2duaXRpb24gaXMgcmVxdWlyZWQsIGFuZCBpZg0KICAgIHRoYXQncyB0aGUgcHVibGlzaGVyLCBo
b3cgZG9lcyB0aGUgc3Vic2NyaWJlciBrbm93IHRvIHVzZSBUTFMNCiAgICBoZWFydGJlYXRzPw0K
PFJSPiBUaGUgc3Vic2NyaWJlciBpcyB0aGUgb25lIG1ha2luZyB0aGF0IGRldGVybWluYXRpb24g
c2luY2UgdGhpcyBpcyB0byByZWNvZ25pemUgdGhlIGxvc3Mgb2YgdGhlIHB1Ymxpc2hlci4NCiAg
ICANCiAgICBuaXQ6IEl0J3MgaW50ZXJlc3RpbmcgdGhhdCB3ZSBzZWVtIHRvIGJlIHVzaW5nIGJv
dGggInN1YnNjcmliZXIiIGFuZA0KICAgICJyZWNlaXZlciIgdG8gdGFsayBhYm91dCB0aGUgVExT
IGNsaWVudCwgaW4gdGhlIHNhbWUgc2VudGVuY2UuDQo8UlI+IFdpbGwgY2hhbmdlIHRvIHN1YnNj
cmliZXIuDQogICAgDQogICAgc2lkZSBub3RlOiBwZXIgaHR0cHM6Ly9naXRodWIuY29tL29wZW5z
c2wvb3BlbnNzbC9wdWxsLzE5MjgsIE9wZW5TU0wNCiAgICB3aWxsIG5vdCBzdXBwb3J0IFRMUyBv
ciBEVExTIGhlYXJ0YmVhdHMgb2YgYW55IGZvcm0gaW4gaXRzIG5leHQgbWFqb3INCiAgICByZWxl
YXNlICgzLjAuMCkuDQogICAgDQogICAgICAgTG9zcyBvZiB0aGUgaGVhcnRiZWF0IE1VU1QgcmVz
dWx0IGluIGFueSBzdWJzY3JpcHRpb24gcmVsYXRlZCBUQ1ANCiAgICAgICBzZXNzaW9ucyBiZXR3
ZWVuIHRob3NlIGVuZHBvaW50cyBiZWluZyB0b3JuIGRvd24uICBBIHN1YnNjcmliZXIgY2FuDQog
ICAgICAgdGhlbiBhdHRlbXB0IHRvIHJlLWVzdGFibGlzaCB0aGUgZHluYW1pYyBzdWJzY3JpcHRp
b24gYnkgdXNpbmcgdGhlDQogICAgICAgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu
DQogICAgDQogICAgUkZDIDY1MjAgZG9lcyBub3Qgc3BlY2lmeSByZXRyYW5zbWl0IG51bWJlcnMg
b3IgaW50ZXJ2YWxzIHRvIGJlIHVzZWQgdG8NCiAgICBkZXRlcm1pbmUgdGhhdCBhIHBlZXIgaXMg
bm9ucmVzcG9uc2l2ZSAoaS5lLiwgImxvc3QiKSwgc28gdGhpcyB0ZXh0DQogICAgc2VlbXMgdW5k
ZXItc3BlY2lmaWVkLiAgSXMgdGhlIGludGVudCB0byBsZWF2ZSB0aGVzZSBkZWNpc2lvbnMgdG8g
YmUNCiAgICBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYz8NCjxSUj4gWWVzIHRoaXMgaXMgdGhlIGlu
dGVudCBzaW5jZSBpdCBhbGwgZGVwZW5kcyBvbiB3aGF0IHRoZSBzdWJzY3JpYmVyIG5lZWRzL3dp
c2hlcy4NCiAgICANCiAgICBTZWN0aW9uIDMuMw0KICAgIA0KICAgIEkgc2VlIHRoYXQgZHJhZnQt
aWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyAoc2VjdGlvbiAyLjQuNikNCiAg
ICBhZG1vbmlzaGVzIHVzIHRvIGNoZWNrIGZvciB0cmFuc3BvcnQtbGF5ZXIgZXJyb3JzIChhbmQg
QUNMcyEpIGJlZm9yZQ0KICAgIFJQQy1sZXZlbCBlcnJvcnM7IGlzIHRoZSB0ZXh0IGhlcmUgYWJv
dXQgImZhaWxzIHRvIHNlcnZlIHRoZSBSUEMNCiAgICByZXF1ZXN0IiBhbmQgb3VyIGRlc2NyaXB0
aW9uIG9mIGVycm9yIGhhbmRsaW5nIGNvbnNpc3RlbnQgd2l0aCB0aGUNCiAgICBzZXBhcmF0ZSB0
cmFuc3BvcnQtbGF5ZXIgZXJyb3IgaGFuZGxpbmc/ICAoSSB0aGluayBpdCBjYW4gYmUsIHdpdGgg
YQ0KICAgIGNhcmVmdWwgcmVhZGluZyBvZiAib25lIG9mIHRoZSByZWFzb25zIGluZGljYXRlZCBp
biBbXSBTZWN0aW9uIDIuNC42IiwNCiAgICBidXQgcGVyaGFwcyBvdGhlciByZWFkaW5ncyBhcmUg
cG9zc2libGUuKQ0KPFJSPiBZZXMgdGhpcyBzZWN0aW9uIGlzIGZvciBSUEMtbGV2ZWwgZXJyb3Jz
LCBpdCByZWZlcmVuY2VzIDIuNC42IG9mIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyB3aGljaCBw
cm92aWRlZCBhIGxpc3Qgb2YgcG9zc2libGUgZXJyb3JzLg0KICAgIA0KICAgICAgICAgIFRoZSB5
YW5nLWRhdGEgaW5jbHVkZWQgd2l0aGluICJlcnJvci1pbmZvIiBTSE9VTEQgTk9UIGluY2x1ZGUg
dGhlDQogICAgICAgICAgb3B0aW9uYWwgbGVhZiAiZXJyb3ItcmVhc29uIiwgYXMgc3VjaCBhIGxl
YWYgd291bGQgYmUgcmVkdW5kYW50DQogICAgICAgICAgd2l0aCBpbmZvcm1hdGlvbiB0aGF0IGlz
IGFscmVhZHkgcGxhY2VkIHdpdGhpbiB0aGUNCiAgICAgICAgICAiZXJyb3ItYXBwLXRhZyIuDQog
ICAgDQogICAgSSdtIG5vdCBzdXJlIHdoZXJlIHRoaXMgImVycm9yLXJlYXNvbiIgbGVhZiBpcyBk
ZWZpbmVkIC0tIEkgZG9uJ3Qgc2VlIGl0DQogICAgaW4gYW55IG9mIHN1YnNjcmliZWQtbm90aWZp
Y2F0aW9ucywgeWFuZy1wdXNoLCBvciBSRkMgODA0MC4NCjxSUj5Hb29kIGNhdGNoLCAgSSB0aGlu
ayB0aGlzIHNob3VsZCBiZSAicmVhc29uIiBmcm9tIHlhbmctcHVzaCwgd2lsbCBjaGVjay4gICAg
DQoNCiAgICBTZWN0aW9uIDMuNA0KICAgIA0KICAgIEknbSBub3Qgc3VyZSB0aGF0IEkndmUgcHJl
dmlvdXNseSBlbmNvdW50ZXJlZCB1c2luZyB0aGUgc2VjdGlvbiBoZWFkaW5nDQogICAgdG8gaW50
cm9kdWNlIGFuIGFjcm9ueW0gKGFzIGlzIGRvbmUgaGVyZSBmb3IgU1NFKS4gIEkgYmV0IHRoZSBS
RkMgRWRpdG9yDQogICAgd2lsbCBkbyB0aGUgcmlnaHQgdGhpbmcsIHRob3VnaC4NCjxSUj4gSSds
bCBtb3ZlIHRoZSBhY3JvbnltIHRvIHRoZSBzZWN0aW9uIHRleHQNCiAgICANCiAgICAgICBvICBJ
biBhZGRpdGlvbiB0byBhbiBSUEMgcmVzcG9uc2UgZm9yIGEgIm1vZGlmeS1zdWJzY3JpcHRpb24i
IFJQQw0KICAgICAgICAgIHRyYXZlbGluZyBvdmVyIChhKSwgYSAic3Vic2NyaXB0aW9uLW1vZGlm
aWVkIiBzdGF0ZSBjaGFuZ2UNCiAgICAgICAgICBub3RpZmljYXRpb24gTVVTVCBiZSBzZW50IHdp
dGhpbiAoYikuICBUaGlzIGFsbG93cyB0aGUgcmVjZWl2ZXIgdG8NCiAgICAgICAgICBrbm93IGV4
YWN0bHkgd2hlbiB0aGUgbmV3IHRlcm1zIG9mIHRoZSBzdWJzY3JpcHRpb24gaGF2ZSBiZWVuDQog
ICAgICAgICAgYXBwbGllZCB0byB0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2VzLiAgU2VlIGFycm93
IChjKS4NCiAgICANCiAgICBuaXQ6IEkgbWlnaHQgc3VnZ2VzdCBzb21lIGxhbmd1YWdlIGFib3V0
ICJvcmRlciB3aXRoaW4gdGhlIG5vdGlmaWNhdGlvbnMNCiAgICBzdHJlYW0iIGZvciB0aGlzIHN0
YXRlIGNoYW5nZSwgYnV0IHRoYXQncyBwdXJlbHkgZWRpdG9yaWFsLg0KPFJSPiBTbyB5b3Ugd291
bGQgbGlrZSB0aGlzIHRleHQgY2hhbmdlZCB0byBjbGFyaWZ5IHRoZSBvcmRlciBvZiBldmVudHM/
DQogICAgDQogICAgICAgbyAgSW4gYWRkaXRpb24gdG8gYW55IHJlcXVpcmVkIGFjY2VzcyBwZXJt
aXNzaW9ucyAoZS5nLiwgTkFDTSksIFJQQ3MNCiAgICAgICAgICBtb2RpZnktc3Vic2NyaXB0aW9u
LCByZXN5bmMtc3Vic2NyaXB0aW9uIGFuZCBkZWxldGUtc3Vic2NyaXB0aW9uDQogICAgICAgICAg
U0hPVUxEIG9ubHkgYmUgYWxsb3dlZCBieSB0aGUgc2FtZSBSRVNUQ09ORiB1c2VybmFtZSBbUkZD
ODA0MF0NCiAgICAgICAgICB3aGljaCBpbnZva2VkIGVzdGFibGlzaC1zdWJzY3JpcHRpb24uDQog
ICAgDQogICAgSSdtIGNvbmZ1c2VkIGFib3V0IHRoaXMgIlNIT1VMRCIgKHRoZSBzZWNkaXIgcmV2
aWV3ZXIgbm90ZWQgaXQgYXMgd2VsbCkNCiAgICAtLSBpbiBteSB1bmRlcnN0YW5kaW5nLCB0aGUg
Y29yZSBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgcmVxdWlyZXMgdGhhdA0KICAgIHN1Y2ggUlBD
cyBtdXN0IGJlIGRvbmUgb24gdGhlIHNhbWUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gYXMgdGhlIG9u
ZSB1c2VkDQogICAgdG8gY3JlYXRlIGEgZHluYW1pYyBzdWJzY3JpcHRpb24gKGkuZS4sIGxpbmUg
KGEpIGluIEZpZ3VyZSAxKSwgYW5kIHNpbmNlDQogICAgUkZDIDgwNDAgYXV0aGVudGljYXRlZCBj
bGllbnQgaWRlbnRpdGllcyBhcmUgYXQgdGhlIGNvbm5lY3Rpb24gbGV2ZWwsDQogICAgdGhlcmUg
Y291bGQgbmV2ZXIgYmUgYW55IGNoYW5nZSBvZiB1c2VybmFtZSBhY3Jvc3MgdGhlIGNhbGxzLg0K
PFJSPiBXaGF0IHlvdSBkZXNjcmliZSBhYm92ZSBpcyB0cnVlIGZvciBuZXRjb25mIChhbGwgZG9u
ZSBvbiBzYW1lIHNlc3Npb24uIA0KSG93ZXZlciByZXN0Y29uZiBkb2Vzbid0IHdvcmsgdGhlIHNh
bWUgd2F5IChubyBsb25nLWxpdmVkIHNlc3Npb25zKSwgc28gc3Vic2VxdWVudCBSUENzIGNvdWxk
IGFjdHVhbGx5IGJlIG9uIGEgZGlmZmVyZW50IHRyYW5zcG9ydCBjb25uZWN0aW9uLg0KSSBkbyBy
ZWNhbGwgdGhlIHNlY2RpciBjb21tZW50cyBhbmQgeW91ciBjb21tZW50cyB0byBteSByZXNwb25z
ZSwgSSB3aWxsIGluY2x1ZGUgdGhlIHRleHQgeW91IGhhZCBzdWdnZXN0ZWQgdG8ganVzdGlmeSB0
aGUgU0hPVUxELg0KICAgIA0KICAgICAgIG8gIExvc3Mgb2YgVExTIGhlYXJ0YmVhdA0KICAgIA0K
ICAgIChBcyBub3RlZCBhYm92ZSwgdGhpcyBpcyB1bmRlci1zcGVjaWZpZWQgYXQgcHJlc2VudC4p
DQogICAgDQogICAgU2VjdGlvbiA5DQogICAgDQogICAgSSB3b3VsZCBzdWdnZXN0IGFsc28gcmVj
b21tZW5kaW5nIHRoYXQgdGhlICd1cmknIHZhbHVlcyBub3QgaGF2ZSBhDQogICAgcHJlZGljdGFi
bGUgc3RydWN0dXJlIG9yIGJlIGd1ZXNzYWJsZS4gIFdoaWxlIHdlIGRvIGhhdmUgc29saWQgYWNj
ZXNzDQogICAgY29udHJvbCBpbiBwbGFjZSB2aWEgTkFDTS9ldGMuLCB0aGVyZSBpcyBzdGlsbCBh
IHJpc2sgb2Ygc2lkZS1jaGFubmVsDQogICAgbGVha2FnZSBpZiB0aGVyZSdzIGEgZGlzdGluY3Rp
b24gYmV0d2VlbiAicmVzb3VyY2UgZG9lcyBub3QgZXhpc3QiIGFuZA0KICAgICJub3QgYXV0aG9y
aXplZCIuICAoRllJIHdlIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB1bmd1ZXNzYWJsZSBV
UklzDQogICAgaW4gdGhlIGNvbnRleHQgb2YgZHJhZnQtaWV0Zi1hY21lLWFjbWUsIHdoaWNoIGhh
ZCBhIG11Y2ggd2Vha2VyDQogICAgYWNjZXNzLWNvbnRyb2wgc3RvcnkgYW5kIGNvdWxkIGluIHNv
bWUgc2Vuc2UgYmUgc2FpZCB0byB1c2UgImNhcGFiaWxpdHkNCiAgICBVUklzIiwgaWYgYW55b25l
IHdhbnRzIHRvIGRvIHNvbWUgYmFja2dyb3VuZCByZWFkaW5nLikNCiAgICAoT25lIG1pZ2h0IHNl
ZSBhbHNvIGRyYWZ0LWdvbnQtbnVtZXJpYy1pZHMtc2VjLWNvbnNpZGVyYXRpb25zLikNCjxSUj4g
U2VjdGlvbiA5IHNheXMgIlRoZSBzdWJzY3JpcHRpb24gVVJJIGlzIGltcGxlbWVudGF0aW9uIHNw
ZWNpZmljIC4uLiIuIEkgY2FuIGFkZCB0ZXh0LCBhcyB5b3Ugc3VnZ2VzdGVkLCB0byByZWNvbW1l
bmQgdGhhdCB0aGUgdXJpIHZhbHVlcyBub3QgYmUgcHJlZGljdGFibGUuDQogICAgDQogICAgSSBz
ZWUgdGhhdCB0aGUgc3Vic2NyaXB0aW9uLWlkIHR5cGUgaXMgb25seSBvZiB0eXBlIHVpbnQzMiBp
bg0KICAgIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMsIHdoaWNo
IHRvIHNvbWUgZXh0ZW50IGxpbWl0cw0KICAgIHRoZSB1bmd1ZXNzYWJpbGl0eSBwcm9wZXJ0eSB0
byB0aGUgVVJJcyBhbmQgbm90IGFzIG11Y2ggZm9yIHRoZSBJRHMNCiAgICB0aGVtc2VsdmVzICh0
aG91Z2ggcmFuZG9taXphdGlvbiB3aXRoaW4gYSAzMi1iaXQgc3BhY2UgaXMgbm90IHdpdGhvdXQN
CiAgICB2YWx1ZSkuDQogICAgDQogICAgQXBwZW5kaXggQQ0KICAgIA0KICAgIENvbnNpc3RlbnQg
d2l0aCBteSBzdWdnZXN0aW9uIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgSSdkIGNo
YW5nZQ0KICAgIHRoZSByZXR1cm5lZCBVUkkgaGVyZSBvciBhdCBsZWFzdCBub3RlIHRoYXQgdGhl
ICIyMiIsICIyMyIsIGV0Yy4gYXJlDQogICAgcGxhY2Vob2xkZXJzIGFuZCBub3QgaW5kaWNhdGl2
ZSBvZiBleHBlY3RlZCB1c2FnZS4NCjxSUj4gSSB3aWxsIGFkZCBhIG5vdGUuDQogICAgDQogICAg
KFRoaXMgc25pcHBldCBmcm9tIEEuMS4xKQ0KICAgIA0KICAgICAgIHsNCiAgICAgICAgICAiaWV0
Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6aW5wdXQiOiB7DQogICAgICAgICAgICAgInN0cmVh
bS14cGF0aC1maWx0ZXIiOiAiL2V4YW1wbGUtbW9kdWxlOmZvby8iLA0KICAgICAgICAgICAgICJz
dHJlYW0iOiAiTkVUQ09ORiIsDQogICAgICAgICAgICAgImRzY3AiOiAiMTAiDQogICAgICAgICAg
fQ0KICAgICAgIH0NCiAgICANCiAgICBUaGUgYW1iaWd1aXR5IG9mICIxMCIgaGFzIGJlZW4gbm90
ZWQgZWxzZXdoZXJlLCBidXQgc2luY2UgaXQncyBhIHVpbnQ4DQogICAgKHJhbmdlICIwLi42MyIp
IHdvdWxkbid0IGl0IGJlIGEgSlNPTiBudW1iZXIsIG5vdCBhIEpTT04gc3RyaW5nPw0KPFJSPiBZ
b3UgYXJlIGNvcnJlY3QsIHdpbGwgY2hhbmdlIHRvIDEwDQogICAgDQogICAgU2ltaWxhcmx5LCBz
dWJzY3JpcHRpb24gSURzIGFyZSB1aW50MzIsIHdoaWNoIElJVUMgZ2V0cyBlbmNvZGVkIGFzIGEN
CiAgICBudW1iZXIuDQo8UlI+IENvcnJlY3QgYWdhaW4uICAgIA0KICAgIA0KUmVnYXJkcywNClJl
c2hhZC4NCg0K


From nobody Sat May 11 07:43:37 2019
Return-Path: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E57120020 for ; Sat, 11 May 2019 07:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, T_REMOTE_IMAGE=0.01] 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 aq6qsd1lfzJl for ; Sat, 11 May 2019 07:43:33 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BA612001E for ; Sat, 11 May 2019 07:43:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557585811; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BzUsK80cMFPY2zi1+8iil6+NHIsWAN7V//18EJ8VL5Q=; b=N2tkMknprZnp/659BwZ3bJy1ZGUCpItaTAechbuLgU4wdSsN+pef8HEftmie0NTQ wBjtcM2BCTHFswrs0utdTIfze2In3tFQbJO2q1sz3A1GH6HiNTsph4nA+Z56CVwGIHn 2hxlkBwQWCsv5kLq82FaeDL7BDY7p9rOMX4n41Ac=
From: Kent Watsen 
Message-ID: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_74B477DA-78B3-44C9-9096-CD7DFFD4659A"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sat, 11 May 2019 14:43:31 +0000
In-Reply-To: 
Cc: "netconf@ietf.org" 
To: Jonathan Hansford 
References: 
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.11-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 May 2019 14:43:35 -0000

--Apple-Mail=_74B477DA-78B3-44C9-9096-CD7DFFD4659A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

It seems that the "for any reason" clause should be qualified modulo the =
"persist" element (please file an errata report).  Note also the last =
paragraph in Section 8.4.1, which shows RFC 624 straddling capability =
versions, hence the wonky text.=20

To answer your question. it is the latter: the only way to abort a =
persistent confirmed commit is to let the timer expire, or to use the =
 operation.

Kent // contributor


> On May 8, 2019, at 9:33 AM, Jonathan Hansford  =
wrote:
>=20
> Hi,
>=20
> In RFC 6241:
>=20
> Section 8.4.1 states "If the session issuing the confirmed commit is =
terminated for any reason before the confirm timeout expires, the server =
MUST restore the configuration to its state before the confirmed commit =
was issued, unless the confirmed commit also  included a  =
element."
>=20
> Section 8.4.5.1 states the persist parameter makes "the confirmed =
commit survive a session termination".
>=20
> Appendix C states the persist parameter "is used to make a confirmed =
commit persistent. A persistent confirmed commit is not aborted if the =
NETCONF session terminates. The only way to abort a persistent confirmed =
commit is to let the timer expire, or to use the  =
operation."=20
>=20
> However:
>=20
> Section 7.8, Erratum 5397 states "If a NETCONF server receives a =
 request while processing a confirmed commit (Section =
8.4) for that session, regardless of whether the confirmed commit =
included a  element, it MUST restore the configuration to its  =
state before the confirmed commit was issued."
>=20
> Section 7.9, Erratum 5397 states "If a NETCONF server receives a =
 request while processing a confirmed commit (Section 8.4) =
for that session, regardless of whether the confirmed commit included a =
 element, it MUST restore the configuration to its  state =
before the confirmed commit was issued."
>=20
> Section 8.4.1 states "If the device reboots for any reason before the =
confirm timeout expires, the server MUST restore the configuration to =
its state before the confirmed commit was issued."
>=20
> So:
>=20
> Is the use of  or , or the device =
rebooting, not considered to be the session being "terminated for any =
reason"? Or is it the case that "the only way to abort a persistent =
confirmed commit is to let the timer expire, or to use the =
 operation"?
>=20
> Jonathan
>=20
>  =
	Virus-free. =
www.avast.com =
 =
________________________=
_______________________
> netconf mailing list
> netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =


--Apple-Mail=_74B477DA-78B3-44C9-9096-CD7DFFD4659A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

It =
seems that the "for any reason" clause should be qualified modulo the =
"persist" element (please file an errata report).  Note also the =
last paragraph in Section 8.4.1, which shows RFC 624 straddling =
capability versions, hence the wonky text. 

To answer your question. it is the latter: the only way =
to abort a persistent confirmed commit is to let the timer expire, or to =
use the <cancel-commit> operation.

Kent // contributor


On May 8, 2019, at 9:33 AM, Jonathan Hansford =
<jonathan@hansfords.net> wrote:

Hi,

In RFC 6241:

Section 8.4.1 states "If the session =
issuing the confirmed commit is terminated for any reason before the =
confirm timeout expires, the server MUST restore the configuration to =
its state before the confirmed commit was issued, unless the confirmed =
commit also  included a <persist> element."

Section 8.4.5.1 states the persist =
parameter makes "the confirmed commit survive a session =
termination".

Appendix C states the persist =
parameter "is used to make a confirmed commit persistent. A persistent =
confirmed commit is not aborted if the NETCONF session terminates. The =
only way to abort a persistent confirmed commit is to let the timer =
expire, or to use the <cancel-commit> operation." 

However:

Section 7.8, Erratum 5397 states "If a NETCONF server =
receives a <close-session> request while processing a confirmed =
commit (Section 8.4) for that session, regardless of whether the =
confirmed commit included a <persist> element, it MUST restore the =
configuration to its  state before the confirmed commit was =
issued."

Section 7.9, Erratum 5397 states "If a NETCONF server =
receives a <kill-session> request while processing a confirmed =
commit (Section 8.4) for that session, regardless of whether the =
confirmed commit included a <persist> element, it MUST restore the =
configuration to its  state before the confirmed commit was =
issued."

Section 8.4.1 states "If the device reboots for any =
reason before the confirm timeout expires, the server MUST restore the =
configuration to its state before the confirmed commit was =
issued."

So:

Is the use of <close-session> or =
<kill-session>, or the device rebooting, not considered to be the =
session being "terminated for any reason"? Or is it the case that "the =
only way to abort a persistent confirmed commit is to let the timer =
expire, or to use the <cancel-commit> operation"?

Jonathan

3D""Virus-free. www.avast.com
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

=

--Apple-Mail=_74B477DA-78B3-44C9-9096-CD7DFFD4659A--


From nobody Sat May 11 08:15:41 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D33412002E for ; Sat, 11 May 2019 08:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 BEftoZr64crb for ; Sat, 11 May 2019 08:15:35 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 CDA1712001E for ; Sat, 11 May 2019 08:15:34 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id n22so6111472lfe.12 for ; Sat, 11 May 2019 08:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ucSKDdRwufveGrPkXgNjQle+RGeNDbZfXX6KeIoWisA=; b=ZPP+Kp9IYU06bUNuGY5Kf8Ysnh8Cj9czo7xpPBLNE/F3DtPs6OBBXVvqn+VWHkOXKR hpbrtIU4TTC3oDzfEfs5vmFwIYHofqF0kyA4JyKdLJwx5FakJoH8Bjc0LvgxgjNaBhrf 0U9uOVRfutKeLnKoNow1GDho95+wJ6unf0HlEW2xew+EA2WSwZ4bBQbfbcDIlxgc4FhZ thP9snelwbTpZKIHHAl0j2IwTUH99aeRuQG80JPznHzKx9d3jk+OmmYNE/Vg5CoSjRBN mdeX8uxN7oaewXiUa9YwFrIwiyS81klk1VxW/r3VQK+4QAMzqEhTOErlNiV4U2hMYBib O8OA==
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=ucSKDdRwufveGrPkXgNjQle+RGeNDbZfXX6KeIoWisA=; b=uXFvJF4nLVLk/fhPwyZm/f5coREIU9tMGUs2FxBquj2varlnzmmHgpNIKuktkQG1zI NAtuswIom7BIFE61yrZZda+WQSF3VyxTVG7IWpZydoQ1ERZSug1DysvXqpBvZR/Jwu2I 9RK1dUG/xjz8LpF1OsvtxM7WxkEx3Q475FaGE+QXf6SCr5tJ/RwTmHFgrrg7zxXSfW3V 8kvAtLBeBlu6PEVUpqgw+XxQb+/6hKwsFc5k2vi380b73RVJTVsIX6JDy/nLz8siWdFP OWuOD7yG2Qai06MVJ6za9c01UjMC90RLI4Y8k1+rZnOqAm5qT+rYXDDrH8RxfDJZ3U+B oR4w==
X-Gm-Message-State: APjAAAVESrzdCj3jt9o/zyDDBBY08C3aCwxF8ESRzy33F9jRLLnxVG2F ePf2Axy80suSunA1z9tiLe/HaO1zFWDy/DSZJIu10w==
X-Google-Smtp-Source: APXvYqw6s0O71p8mKs7/uMTF3s7AYdv+u9dUX849eoMTKqOYhkmTGNKinZgSs1gwKhDQpiCfD+sP6kH3tfYohqjeLHs=
X-Received: by 2002:ac2:5621:: with SMTP id b1mr9387664lff.27.1557587732880; Sat, 11 May 2019 08:15:32 -0700 (PDT)
MIME-Version: 1.0
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>
In-Reply-To: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>
From: Andy Bierman 
Date: Sat, 11 May 2019 08:15:21 -0700
Message-ID: 
To: Kent Watsen 
Cc: Jonathan Hansford , "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000008680aa05889e27be"
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 May 2019 15:15:39 -0000

--0000000000008680aa05889e27be
Content-Type: text/plain; charset="UTF-8"

On Sat, May 11, 2019 at 7:43 AM Kent Watsen  wrote:

> It seems that the "for any reason" clause should be qualified modulo the
> "persist" element (please file an errata report).  Note also the last
> paragraph in Section 8.4.1, which shows RFC 624 straddling capability
> versions, hence the wonky text.
>
> To answer your question. it is the latter: the only way to abort a
> persistent confirmed commit is to let the timer expire, or to use the
>  operation.
>
> Kent // contributor
>
>
> On May 8, 2019, at 9:33 AM, Jonathan Hansford 
> wrote:
>
> Hi,
>
> In RFC 6241:
>
> Section 8.4.1 states "If the session issuing the confirmed commit is
> terminated for any reason before the confirm timeout expires, the server
> MUST restore the configuration to its state before the confirmed commit was
> issued, unless the confirmed commit also  included a  element."
>
> Section 8.4.5.1 states the persist parameter makes "the confirmed commit
> survive a session termination".
>
> Appendix C states the persist parameter "is used to make a confirmed
> commit persistent. A persistent confirmed commit is not aborted if the
> NETCONF session terminates. The only way to abort a persistent confirmed
> commit is to let the timer expire, or to use the 
> operation."
>
>

> However:
>
> Section 7.8, Erratum 5397 states "If a NETCONF server receives a
>  request while processing a confirmed commit (Section 8.4)
> for that session, regardless of whether the confirmed commit included a
>  element, it MUST restore the configuration to its  state before
> the confirmed commit was issued."
>
>



I do not agree with this Errata and will never implement it as part of RFC
6241 conformance.
The entire point of the "persist" mechanism is to tie the confirmed commit
to a client, not to a session.
Cancelling the CC because a client sends a  (instead of
dropping the transport session)
is obviously counter-productive.  Using  instead of dropping
the session is
considered the best current practice.





> Section 7.9, Erratum 5397 states "If a NETCONF server receives a
>  request while processing a confirmed commit (Section 8.4)
> for that session, regardless of whether the confirmed commit included a
>  element, it MUST restore the configuration to its  state before
> the confirmed commit was issued."
>
>

This solution (and also 7.8) directly contradict the text cited in 8.4.1


Section 8.4.1 states "If the device reboots for any reason before the
> confirm timeout expires, the server MUST restore the configuration to its
> state before the confirmed commit was issued."
>
> So:
>
> Is the use of  or , or the device rebooting,
> not considered to be the session being "terminated for any reason"? Or is
> it the case that "the only way to abort a persistent confirmed commit is to
> let the timer expire, or to use the  operation"?
>
> Jonathan
>
>

Andy


>
> 
> Virus-free. www.avast.com
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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




=

On Sat, May 11, 2019 at 7:43 AM Kent =
Watsen <kent@watsen.net> wrote=
:
It seems that the "for any reason" cl=
ause should be qualified modulo the "persist" element (please fil=
e an errata report).=C2=A0 Note also the last paragraph in Section 8.4.1, w=
hich shows RFC 624 straddling capability versions, hence the wonky text.=C2=
=A0

To answer your question. it is the latter: the only way to=
 abort a persistent confirmed commit is to let the timer expire, or to use=
=C2=A0the <cancel-commit> operation.

Kent //=
 contributor


On=
 May 8, 2019, at 9:33 AM, Jonathan Hansford <jonathan@hansfords.net> wrote:
Hi,

In RFC 62=
41:

Section 8.4.1 states "If the session issuing the confirmed com=
mit is terminated for any reason before the confirm timeout expires, the se=
rver MUST restore the configuration to its state before the confirmed commi=
t was issued, unless the confirmed commit also=C2=A0 included a <persist=
> element."

Section 8.4.5.1 states the persist parameter makes =
"the confirmed commit survive a session termination".

Ap=
pendix C states the persist parameter "is used to make a confirmed com=
mit persistent. A persistent confirmed commit is not aborted if the NETCONF=
 session terminates. The only way to abort a persistent confirmed commit is=
 to let the timer expire, or to use the <cancel-commit> operation.&qu=
ot;=C2=A0


However:

Section 7.8, Erratum 5397 states "If a NET=
CONF server receives a <close-session> request while processing a con=
firmed commit (Section 8.4) for that session, regardless of whether the con=
firmed commit included a <persist> element, it MUST restore the confi=
guration to its=C2=A0 state before the confirmed commit was issued."





I do not agree with this Errata a=
nd will never implement it as part of RFC 6241 conformance.
The e=
ntire point of the "persist" mechanism is to tie the confirmed co=
mmit to a client, not to a session.
Cancelling the CC because a c=
lient sends a <close-session> (instead of dropping the transport sess=
ion)
is obviously counter-productive.=C2=A0 Using <close-sessi=
on> instead of dropping the session is
considered the best cur=
rent practice.



=C2=A0
Section 7.9, Erratum 5397 states "If a NETCONF server =
receives a <kill-session> request while processing a confirmed commit=
 (Section 8.4) for that session, regardless of whether the confirmed commit=
 included a <persist> element, it MUST restore the configuration to i=
ts=C2=A0 state before the confirmed commit was issued."



This solution (and also 7.8) dir=
ectly contradict the text cited in 8.4.1


Section 8.4.1 states =
"If the device reboots for any reason before the confirm timeout expir=
es, the server MUST restore the configuration to its state before the confi=
rmed commit was issued."

So:
=

Is the use of <close-session&g=
t; or <kill-session>, or the device rebooting, not considered to be t=
he session being "terminated for any reason"? Or is it the case t=
hat "the only way to abort a persistent confirmed commit is to let the=
 timer expire, or to use the <cancel-commit> operation"?

Jon=
athan

<=
/div>


Andy
=
=C2=A0
3D""Virus-free.=C2=A0www.avast.com
_______________________________________________
net=
conf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

_____________________________________=
__________

netconf mailing list

netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




--0000000000008680aa05889e27be--


From nobody Sat May 11 09:18:43 2019
Return-Path: <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FD41200CD for ; Sat, 11 May 2019 09:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gL8iOtxWCxML for ; Sat, 11 May 2019 09:18:40 -0700 (PDT)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BB912001E for ; Sat, 11 May 2019 09:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557591518; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=ENzR9IWw4noPnAL22Z6SIxxrGXo1EwclU/9oMyEQCHQ=; b=NpnllWoDMqq+Bfuu+R1aHkXIkwCErggQknkSnVh0rpoGB3sbgZ5Xzie/SxcUspgv axaqMjIAYrGSGNs3m6TF0M8EYL6NM9z0SgUzMJi1cdCUjnzLs93W0DaB1N3Pb3h5fC6 ZcGJgDurkFL0hwP/eKU9J/asw5r9gKiRk6kPKOfA=
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: <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de>
Date: Sat, 11 May 2019 16:18:38 +0000
Cc: "netconf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com>
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com>  <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.11-54.240.8.64
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 May 2019 16:18:42 -0000

Hi Juergen,


>> I discussed this option in my "wide-screen needed" email from last =
Friday.
>> There are 3 cases to consider:
>>=20
>> 1) the manufacturer creates the (most likely "hidden") key pair and =
associated certificate.
>>      - these nodes MUST originate in  (origin=3D"system")
>>      - clients MUST replicate their (potentially encrypted or =
"permanently-hidden"
>>        enumerated) content into  in order reference the key =
and/or cert.
>=20
> The question is what or how much needs replication. We refer to
> hardware interfaces created by the manufacturer (and identified during
> system startup - or during hotplug procedures) by having a name
> binding of config in  to operational state in .
> If you configure eth0, then this config binds to an 
> interface with the same name. So if there is a key pair created by the
> vendor, perhaps all we need is a kind of a name that can be used to
> bind the config to the key.

True, it could to a handle, but it's unclear what the handle would be.  =
We'd probably have to create one just to resolve this issue.


>> 2) the client wishes to generate a key (hidden or not) without ever =
touching the
>>    private key.
>>      - presumably this occurs via a "generate-key" action (open to =
ideas)
>>      - this key ultimately MUST be in  in order to be =
referenced by config.
>=20
> Perhaps the question is whether this is 'the key' or 'the name of the
> key'.

Same as above.


>>      - ideally it shows up in  as consequence of invoking =
the action.
>>      - less ideal, as in (1), a / sequence could =
be used
>>        to bring the key into .
>=20
> Would it help if "generate-key" simply returns a name for the new key?

Perhaps, I'd have to think through it more but, first, I want to dig a =
little more on the "crypt-hash" approach (see below).


>> 3) the client wished to installed a hidden key.
>>      - note that we don't discuss installing a non-hidden key here, =
because
>>        that is exactly what a standard  operation does.
>>      - presumably this occurs via a "install-key" action (open to =
ideas)
>>      - this is a weird case because the client is initially okay with =
touching the
>>        private key, but thereafter wants it to be protected by the =
system.
>>      - again, as with (2), ideally the key shows up in running as =
consequence
>>        of the action, but a round-trip could also get it there.
>=20
> /js



Switching gears, I'd like to explore more the idea of reverting the =
3-tuple back to "mandatory true" as discussed here: =
https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY =
but, instead of using `action` statements, perhaps we can use something =
similar to "crypt-hash".

=46rom RFC 7317:

     typedef crypt-hash {
       type string {
         pattern
           '$0$.*'
         + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
         + '|$5$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
         + '|$6$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
       }
       description
         "The crypt-hash type is used to store passwords using
          a hash function.  The algorithms for applying the hash
          function and encoding the result are implemented in
          various UNIX systems as the function crypt(3).

          A value of this type matches one of the forms:

            $0$
            $$$
            $$$$

          The '$0$' prefix signals that the value is clear text.  When
          such a value is received by the server, a hash value is
          calculated, and the string '$$$' or
          $$$$ is prepended to the result.  This
          value is stored in the configuration data store.
     


Note that the last sentence says "stored in the configuration data =
store".
So how about this (note: all 3 values are "mandatory true"):


    leaf algorithm {
      nacm:default-deny-write;
      type asymmetric-key-algorithm-ref;
      mandatory true;
      description
        "Identifies the key's algorithm.";
    }


    leaf public-key {
      nacm:default-deny-write;
      type union {
        type binary;
        type string {
          pattern
          + ''
          + '|[A-Za-z0-9+/]+[=3D]{1,3}';
        }
      mandatory true;
      description
        "
        Binary is used for a standard configuration value.

        Prefix values are used to support special use-cases as follows:

          

            An input value that is used to request the system to=20
            generate the key-pair.

            Without the optional '-and-hidden' postfix, the generated
            key pair is stored in the configuration data store.  This
            is used to support the security best practice use case
            whereby the client doesn't touch the private key.

            With the optional '-and-hidden' postfix, the key pair is
            generated in such a way that it will thereafter be reported
            either using '' or ''.=
           =20
           =20
            When the '' prefix is
            used, it MUST be used in both the 'public-key' and 'private-
            key' values.

          [A-Za-z0-9+/]+[=3D]{1,3}

            An input value that is used to request the system to=20
            store the provided key-pair in such a way that it will
            thereafter be reported either as ''
            or '*'.

            Following the prefix is the base64-encoded value of the
            public key.

            When the '' prefix is used, it MUST be=20=

            used in both the 'public-key' and 'private-key' values.
        ";
    }


    leaf private-key {
      nacm:default-deny-all;
      type union {
        type binary;
        type string {
          pattern
            ''
          + '|[A-Za-z0-9+/]+[=3D]{1,3}'
          + '|'
          + '|[A-Za-z0-9+/]+[=3D]{1,3}';
        }
      mandatory true;
      description
        "
        Binary is used for a standard configuration value.

        Prefix values are used to support special use-cases as follows:

          

            An output value that is used by the system to indicate
            that the private key value is not available in any form.

          [A-Za-z0-9+/]+[=3D]{1,3}

            An output value that is used by the system to indicate
            that the private key value is encrypted using the key
            identified by the 'by' attribute.

            Following the prefix is the base64-encoded value of the
            encrypted private key.=20

          

            An input value that is used to request the system to=20
            generate the key-pair.

            Without the optional '-and-hidden' postfix, the generated
            key pair is stored in the configuration data store.  This
            is used to support the security best practice use case
            whereby the client doesn't touch the private key.

            With the optional '-and-hidden' postfix, the key pair is
            generated in such a way that it will thereafter be reported
            either using '' or ''.=


            When the '' prefix is
            used, it MUST be used in both the 'public-key' and 'private-
            key' values.

          [A-Za-z0-9+/]+[=3D]{1,3}

            An input value that is used to request the system to=20
            store the provided key-pair in such a way that it will
            thereafter be reported either as ''
            or '*'.

            Following the prefix is the base64-encoded value of the
            private key.

            When the '' prefix is used, it MUST be=20=

            used in both the 'public-key' and 'private-key' values.
        ";
    }



Kent // contributor



From nobody Sat May 11 09:19:16 2019
Return-Path: <0100016aa7b0f010-847d1ae5-d20b-4fc4-90ac-77006c2ac941-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C671200CD for ; Sat, 11 May 2019 09:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_dlS8f1xEjV for ; Sat, 11 May 2019 09:19:13 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F9F12001E for ; Sat, 11 May 2019 09:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557591552; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=OeZp/3uaZ8Wd2aHvn9KJOR2T0y2PwG6aNNrOR3mZ/Ag=; b=P5McPOJHffDX+JeRXQDBY9b9BiEERYWn00cDK6NAmuBE7uS5VrC33PDK8a6xvU83 lxp5DMtzH+0VEqtySwVEFaldZRkz1DyTH3J/H6L1uKF5DnVO3YBgyK1fBtP0SaUsEJb iEwYSyj71CnYeAnKbwn1KWUWltO/gaF7dDz+Q/bs=
From: Kent Watsen 
Message-ID: <0100016aa7b0f010-847d1ae5-d20b-4fc4-90ac-77006c2ac941-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2EB32E02-CD44-4FB6-BA7E-D1AE21EEB152"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sat, 11 May 2019 16:19:12 +0000
In-Reply-To: 
Cc: "netconf@ietf.org" 
To: Nick Hancock 
References:  <0100016a766b430d-005d7041-a607-42d6-b91a-558bbb93e4c6-000000@email.amazonses.com>  <0100016a9465d3e2-9e05e8e7-824c-41f8-985a-fc767147bc9c-000000@email.amazonses.com> 
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.11-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] draft-ietf-netconf-keystore-09.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 May 2019 16:19:15 -0000

--Apple-Mail=_2EB32E02-CD44-4FB6-BA7E-D1AE21EEB152
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> Yes, but I believe that these SHOULD statements should also be=20
> included on the description statement of 'cert' leafs as well as they=20=

> may get overlooked, if they are only to be found in the description=20
> statement on the groupings.

Good idea.  I just added this as well:

  grouping end-entity-cert-grouping {
     description
       "An end entity certificate, and a notification for when
-       it is about to (or already has) expire.";
+       it is about to (or already has) expire.  Implementations
+       SHOULD assert that, where used, the end entity certificate
+       contains the expected public key.";



> It would be a possible solution, but that is something for the future =
though.

True, but we do what we can to make the future better  :)
https://github.com/netmod-wg/yang-next/issues/84



> Yes, copy/paste is always an option, but this also has its drawbacks,=20=

> including having multiple duplicate definitions within the YANG model;=20=

> the opportunity to modify the copy, intentionally or unintentionally,=20=

> such as to change the names of leafs; but most importantly copying and=20=

> pasting would mean that copy will not follow any changes made to=20
> the original grouping, such as corrections and the addition of new=20
> nodes in newer revisions, meaning additional maintenance and possible=20=

> discrepancies across YANG models going forward. =20
> And this is why I am a keen user of groupings to ensure consistency=20
> across models, even though it makes the YANG modules even harder to=20
> read. If something is the same then it should always be the same=20
> wherever is appears in the model and using a grouping does just that.

Okay, let's see what we can do.  Firstly, please see my response just =
now in the other thread where I'm suggesting the remove the `action` =
statements entirely (via an idea similar to "crypt-hash").   If =
accepted, then we only have to create "data-only" groupings for those =
groupings that containing `notification` statements.=20

Kent // contributor





--Apple-Mail=_2EB32E02-CD44-4FB6-BA7E-D1AE21EEB152
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



Yes, but I believe that these SHOULD =
statements should also be 
included on the description =
statement of 'cert' leafs as well as they 
may get =
overlooked, if they are only to be found in the description 
statement on the groupings.

Good =
idea.  I just added this as well:

  grouping end-entity-cert-grouping {
     description
    =
   "An end entity certificate, and a notification for when
-       it is about to (or already =
has) expire.";
+       it is =
about to (or already has) expire.  Implementations
+       SHOULD assert that, where =
used, the end entity certificate
+     =
  contains the expected public key.";



It would be a possible solution, but that is something for =
the future though.

True, but we do what we can to make the future =
better  :)
=



Yes, copy/paste =
is always an option, but this also has its drawbacks, 
including having multiple duplicate definitions within the =
YANG model; 
the opportunity to modify the copy, =
intentionally or unintentionally, 
such as to change the =
names of leafs; but most importantly copying and 
pasting =
would mean that copy will not follow any changes made to 
the original grouping, such as corrections and the addition =
of new 
nodes in newer revisions, meaning additional =
maintenance and possible 
discrepancies across YANG models =
going forward.  
And this is why I am a keen user of =
groupings to ensure consistency 
across models, even =
though it makes the YANG modules even harder to 
read. If =
something is the same then it should always be the same 
wherever is appears in the model and using a grouping does =
just that.

Okay, let's see what we can do.  Firstly, =
please see my response just now in the other thread where I'm suggesting =
the remove the `action` statements entirely (via an idea similar to =
"crypt-hash").   If accepted, then we only have to create =
"data-only" groupings for those groupings that containing `notification` =
statements. 

Kent // =
contributor




=

--Apple-Mail=_2EB32E02-CD44-4FB6-BA7E-D1AE21EEB152--


From nobody Mon May 13 03:29:44 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF381200DE; Mon, 13 May 2019 03:29:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= 
Message-ID: <155774338369.23590.5769393248718412373.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 03:29:43 -0700
Archived-At: 
Subject: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-restconf-notif-13=3A_=28with_COMMENT=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 10:29:44 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One question (and this is probably just because of my lack of detailed knowledge about RESTCONF):

Sec 4 says: "To meet subscription quality of service promises, the publisher MUST
   take any existing subscription "dscp" and apply it to the DSCP
   marking in the IP header."
What does "existing subscription "dscp"" mean here?



From nobody Mon May 13 03:43:45 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B67D12006F for ; Mon, 13 May 2019 03:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqhPDWckS8ae for ; Mon, 13 May 2019 03:43:40 -0700 (PDT)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (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 5943E120103 for ; Mon, 13 May 2019 03:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1eArQeDGwJtCiVNjuX/QqSo2bC9M+Da1vxkJgbJKT48=; b=g/tmxnEi2kXV/sbEcecufoYdl 1SvT5JwZ1816MZ0bUcH2YnrqU0f9DE70qUjlk0wdGnGQqwvx1k9JXA2Gf/t74KG+RqhV/DqVZ0cSB YwmPY/lGr36Ea+/8f9yWExnnxFz8MFu+qCNfHEHcPiOrjfl2eW6BoqYfXdY/V/TFL1bP3wlUzb26P n4S8R47VKZ/W765DcA0SuvNe89yJ/oFK6VqL0T65UNy/H3EYxoScZsXaGlKpD7zReILUtyATNyxGl NG5LrogLsNWtJZO0AVYdr10B2UXD7xDRvBhgCDnGzigHKED8PHt53V36I3sUWAyLFA8oED6EcGEkW /EjMOzHWQ==;
Received: from [51.52.247.166] (port=59216 helo=[172.16.3.14]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hQ8Qj-0004vx-NR; Mon, 13 May 2019 11:43:37 +0100
From: "Jonathan Hansford" 
To: "Andy Bierman" , "Kent Watsen" 
Cc: "netconf@ietf.org" 
Date: Mon, 13 May 2019 10:43:36 +0000
Message-Id: 
In-Reply-To: 
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com> 
Reply-To: "Jonathan Hansford" 
User-Agent: eM_Client/7.2.34959.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBA581F048-1E08-4624-9CA7-0F49BE35C483"
X-Antivirus: Avast (VPS 190513-0, 13/05/2019), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 10:43:44 -0000

--------=_MBA581F048-1E08-4624-9CA7-0F49BE35C483
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

So I need to contact the RFC Editor to correct Erratum 5397, with the 
relevant text in sections 7.8 and 7.9 being changed to something like:

>7.8: "If a NETCONF server receives a  request while 
>processing a confirmed commit (Section 8.4) for that session, unless 
>the confirmed commit is a persistent confirmed commit, it MUST restore 
>the configuration to its state before the confirmed commit was issued. 
>A persistent confirmed commit MUST survive session termination."
>
>7.9: "If a NETCONF server receives a  request while 
>processing a confirmed commit (Section 8.4) for the session to be 
>killed, unless the confirmed commit is a persistent confirmed commit, 
>it MUST restore the configuration to its state before the confirmed 
>commit was issued. A persistent confirmed commit MUST survive session 
>termination."

I also need to contact the RFC Editor to correct Erratum 3821 to change:

>If the session issuing a sequence of one or more confirmed commits is
>terminated for any reason before the confirm timeout expires, the 
>server
>MUST restore the configuration to its state before the sequence of
>confirmed commits was issued, unless the last confirmed commit also
>included a  element.
>
>If the device reboots for any reason before the confirm timeout
>expires, the server MUST restore the configuration to its state
>before the sequence of confirmed commits was issued.

to something like:

>If the session issuing a sequence of one or more confirmed commits is
>terminated for any reason before the confirm timeout expires, the 
>server
>MUST restore the configuration to its state before the sequence of
>confirmed commits was issued, unless the confirmed commit is a
>persistent confirmed commit.
>
>If the device reboots for any reason before the confirm timeout
>expires, unless a persistent confirmed commit is in progress, the
>server MUST restore the configuration to its state before the
>sequence of confirmed commits was issued.
>
>  A persistent confirmed commit MUST survive session termination.
>
Are those errata OK?


On 11/05/2019 16:15:21, "Andy Bierman"  wrote:

>
>
>On Sat, May 11, 2019 at 7:43 AM Kent Watsen  wrote:
>>It seems that the "for any reason" clause should be qualified modulo 
>>the "persist" element (please file an errata report).  Note also the 
>>last paragraph in Section 8.4.1, which shows RFC 624 straddling 
>>capability versions, hence the wonky text.
>>
>>To answer your question. it is the latter: the only way to abort a 
>>persistent confirmed commit is to let the timer expire, or to use the 
>> operation.
>>
>>Kent // contributor
>>
>>
>>>On May 8, 2019, at 9:33 AM, Jonathan Hansford 
>>> wrote:
>>>
>>>Hi,
>>>
>>>In RFC 6241:
>>>
>>>Section 8.4.1 states "If the session issuing the confirmed commit is 
>>>terminated for any reason before the confirm timeout expires, the 
>>>server MUST restore the configuration to its state before the 
>>>confirmed commit was issued, unless the confirmed commit also  
>>>included a  element."
>>>
>>>Section 8.4.5.1 states the persist parameter makes "the confirmed 
>>>commit survive a session termination".
>>>
>>>Appendix C states the persist parameter "is used to make a confirmed 
>>>commit persistent. A persistent confirmed commit is not aborted if 
>>>the NETCONF session terminates. The only way to abort a persistent 
>>>confirmed commit is to let the timer expire, or to use the 
>>> operation."
>
>>>
>>>However:
>>>
>>>Section 7.8, Erratum 5397 states "If a NETCONF server receives a 
>>> request while processing a confirmed commit (Section 
>>>8.4) for that session, regardless of whether the confirmed commit 
>>>included a  element, it MUST restore the configuration to 
>>>its  state before the confirmed commit was issued."
>>>
>
>
>
>
>I do not agree with this Errata and will never implement it as part of 
>RFC 6241 conformance.
>The entire point of the "persist" mechanism is to tie the confirmed 
>commit to a client, not to a session.
>Cancelling the CC because a client sends a  (instead of 
>dropping the transport session)
>is obviously counter-productive.  Using  instead of 
>dropping the session is
>considered the best current practice.
>
>
>
>
>>>Section 7.9, Erratum 5397 states "If a NETCONF server receives a 
>>> request while processing a confirmed commit (Section 
>>>8.4) for that session, regardless of whether the confirmed commit 
>>>included a  element, it MUST restore the configuration to 
>>>its  state before the confirmed commit was issued."
>>>
>
>
>This solution (and also 7.8) directly contradict the text cited in 
>8.4.1
>
>
>>>Section 8.4.1 states "If the device reboots for any reason before the 
>>>confirm timeout expires, the server MUST restore the configuration to 
>>>its state before the confirmed commit was issued."
>>>
>>>So:
>>>
>>>Is the use of  or , or the device 
>>>rebooting, not considered to be the session being "terminated for any 
>>>reason"? Or is it the case that "the only way to abort a persistent 
>>>confirmed commit is to let the timer expire, or to use the 
>>> operation"?
>>>
>>>Jonathan
>>>
>
>
>Andy
>
>>> 
>>>Virus-free. www.avast.com 
>>>
>>>_______________________________________________
>>>netconf mailing list
>>>netconf@ietf.org
>>>https://www.ietf.org/mailman/listinfo/netconf
>>
>>_______________________________________________
>>netconf mailing list
>>netconf@ietf.org
>>https://www.ietf.org/mailman/listinfo/netconf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--------=_MBA581F048-1E08-4624-9CA7-0F49BE35C483
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

So I need to contact the RFC Editor to correct Erratum 5397, with the rele=
vant text in sections 7.8 and 7.9 being changed to something like:
7.8: "If a NETCONF server receives a <close-session> re=
quest while processing a confirmed commit (Section 8.4) for that session, u=
nless the confirmed commit is a persistent confirmed commit, it MUST restor=
e the configuration to its state before the confirmed commit was issued. A=
 persistent confirmed commit MUST survive session termination."
7.9: "If a NETCONF server receives a <kill-session> re=
quest while processing a confirmed commit (Section 8.4) for the session to=
 be killed,=C2=A0unless the confirmed commit is a persistent confirmed commi=
t,=C2=A0it MUST restore the configuration to its state before the confirmed =
commit was issued.=C2=A0A persistent confirmed commit MUST survive session =
termination."

I also need to=C2=A0=
contact the RFC Editor to correct Erratum 3821=C2=A0to change:
If the session issuing a sequence of one or more confirmed commit=
s is
terminated for any reason before the confirm timeout expires=
, the server
MUST restore the configuration to its state before t=
he sequence of
confirmed commits was issued, unless the last conf=
irmed commit also
included a <persist> element.
<=
br />
If the device reboots for any reason before the confirm tim=
eout
expires, the server MUST restore the configuration to its st=
ate
before the sequence of confirmed commits was issued.

to something like:

If the session issuing a sequence of one or more confirmed comm=
its is
terminated for any reason before th=
e confirm timeout expires, the server
MUST restore the =
configuration to its state before the sequence of
con=
firmed commits was issued, unless the confirmed commit is a
persistent confirmed commit.

<=
div>
If the device reboots for any reason before the confirm timeout
expires, unless a persistent confirmed commit is in prog=
ress, the=C2=A0
server MUST restore the config=
uration to its state=C2=A0before the
sequence=
 of confirmed commits was issued.

<=
div id=3D"x93822eff4ee44f758027e13d068defdf">
=C2=A0A persistent c=
onfirmed commit MUST survive session termination.

Are those errata OK?=C2=A0






On 11/05/2019 16:15:21, "Andy Bierman" <andy@yumaworks.com> wrote:







On Sat, May 11, 2019 at 7:43 AM K=
ent Watsen <kent@watsen.net> w=
rote:
It seems that the "for any reason" clause =
should be qualified modulo the "persist" element (please file an errata re=
port).=C2=A0 Note also the last paragraph in Section 8.4.1, which shows RFC =
624 straddling capability versions, hence the wonky text.=C2=A0

=

To answer your question. it is the latter: the only way to abort a per=
sistent confirmed commit is to let the timer expire, or to use=C2=A0the <=
;cancel-commit> operation.

Kent // contributo=
r


On May 8, 2019, at 9:33 AM, Jonathan Hansford <jonathan@hansfords.net> wrote:

Hi,

In RFC =
6241:

Section 8.4.1 states "If the session issuing the confirmed com=
mit is terminated for any reason before the confirm timeout expires, the se=
rver MUST restore the configuration to its state before the confirmed commi=
t was issued, unless the confirmed commit also=C2=A0 included a <persist=
> element."

Section 8.4.5.1 states the persist parameter makes "t=
he confirmed commit survive a session termination".

Appendix C s=
tates the persist parameter "is used to make a confirmed commit persistent. =
A persistent confirmed commit is not aborted if the NETCONF session termin=
ates. The only way to abort a persistent confirmed commit is to let the tim=
er expire, or to use the <cancel-commit> operation."=C2=A0


However:

Section 7.8, Erratum 5397 states "If a NETCONF =
server receives a <close-session> request while processing a confirm=
ed commit (Section 8.4) for that session, regardless of whether the confirm=
ed commit included a <persist> element, it MUST restore the configura=
tion to its=C2=A0 state before the confirmed commit was issued."





I do not agree with this Errata=
 and will never implement it as part of RFC 6241 conformance.
The=
 entire point of the "persist" mechanism is to tie the confirmed commit to a =
client, not to a session.
Cancelling the CC because a client sen=
ds a <close-session> (instead of dropping the transport session)
is obviously counter-productive.=C2=A0 Using <close-session> in=
stead of dropping the session is
considered the best current prac=
tice.



=C2=A0
Section 7.9, Erratum 5397 states "If a NETCONF =
server receives a <kill-session> request while processing a confirme=
d commit (Section 8.4) for that session, regardless of whether the confirme=
d commit included a <persist> element, it MUST restore the configurat=
ion to its=C2=A0 state before the confirmed commit was issued."

=



This solution (and also =
7.8) directly contradict the text cited in 8.4.1


Section 8.4.1 states "If the device reboots for any reason before =
the confirm timeout expires, the server MUST restore the configuration to=
 its state before the confirmed commit was issued."

So:

Is the u=
se of <close-session> or <kill-session>, or the device rebootin=
g, not considered to be the session being "terminated for any reason"? Or i=
s it the case that "the only way to abort a persistent confirmed commit is=
 to let the timer expire, or to use the <cancel-commit> operation"?

Jonathan



And=
y
=C2=A0
<=
div style=3D"overflow-wrap: break-word;">
3D""Virus-free.=C2=A0www.avast.com
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________

netconf mailing list

netconf@ietf.org

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





--------=_MBA581F048-1E08-4624-9CA7-0F49BE35C483--


From nobody Mon May 13 09:02:46 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C06EF1200CD; Mon, 13 May 2019 09:02:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= 
Message-ID: <155776336478.23641.7579515397254467186.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 09:02:44 -0700
Archived-At: 
Subject: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-restconf-notif-13=3A_=28with_COMMENT=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 16:02:45 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One question (and this is probably just because of my lack of detailed
knowledge about RESTCONF):

Sec 4 says: "To meet subscription quality of service promises, the publisher
MUST
   take any existing subscription "dscp" and apply it to the DSCP
   marking in the IP header."
What does "existing subscription "dscp"" mean here?

Related update: please also consider the comment from the TSV-ART review about
the example DSCP value (Thanks Wes!). I actually would also appreciate to add a
comment that this is an internal value that depends on the network
configuration (in order to avoid that people just randomly copy this example
value and suddenly always use 10)!



From nobody Mon May 13 09:05:25 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF958120158; Mon, 13 May 2019 09:05:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= 
To: "The IESG" 
Cc: draft-ietf-netconf-netconf-event-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= 
Message-ID: <155776351790.23709.1919363447264047394.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 09:05:17 -0700
Archived-At: 
Subject: [netconf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-netconf-event-notifications-20=3A_=28with_COMME?= =?utf-8?b?TlQp?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 16:05:18 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netconf-netconf-event-notifications-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please also consider the comment from the TSV-ART review about the example DSCP
value (Thanks Wes!). I actually would also appreciate to add a comment that
this is an internal value that depends on the network configuration (in order
to avoid that people just randomly copy this example value and suddenly always
use 10)!



From nobody Mon May 13 10:57:37 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308F712001E; Mon, 13 May 2019 10:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EZmFODsg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PxUNvvL4
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzd4Pwx2gpdG; Mon, 13 May 2019 10:57:33 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4F212023C; Mon, 13 May 2019 10:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2726; q=dns/txt; s=iport; t=1557770251; x=1558979851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+mGJn7DcQj/QkrxzNd4Tqt1TDByKWibNuJ8P6QH8tEY=; b=EZmFODsgq5O2XhqhvZhFuTqrc2dWXYJoqSSxlk/2lmi8g+yaSVIdj4fR WnNXDOCt2FE6Ycxbll8SH4du3PWyliiTFoiMmksVCpSNa3SvXhsW3p2OO A22ZxWIFuxOKGF9A4Q1JLjZ8LkWlv9+YagunqgDgVNtgMNf+vj0t3yLhG Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALK5XOxyLDs6OB93XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufE0T7KffsRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBgACr9lc/5JdJa1kH4F4gT5QA2l?= =?us-ascii?q?VIAQLKIQRg0cDjn6CMpdKgS4UgRADVAkBAQEMAQEjCgIBAYRAAheBfCM0CQ4?= =?us-ascii?q?BAwEBBAEBAgEEbRwMhUsCBBIREQwBATcBDwIBCBoCCR0CAgIwFQULAgQBDQU?= =?us-ascii?q?igwABgWoDHQEOoQYCgTWIX3GBL4J5AQEFgUZBgn4Ygg8DBoELKItPF4FAP4E?= =?us-ascii?q?RJwwTgkw+gmECAQIBgSoBEgEfF4JzMoImin8kgjuZHF8JAoIJhiCEOYQxg1I?= =?us-ascii?q?bghOGTI0NgxOJH4EihTSOMAIEAgQFAg4BAQWBTzgpPVgRCHAVZQGCQYJGgzi?= =?us-ascii?q?FFIU/cgGBKIwjgkMBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,465,1549929600"; d="scan'208";a="274873557"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 May 2019 17:57:30 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x4DHvULb017000 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 May 2019 17:57:30 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 May 2019 12:57:29 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 May 2019 13:57:13 -0400
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 13 May 2019 13:57:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+mGJn7DcQj/QkrxzNd4Tqt1TDByKWibNuJ8P6QH8tEY=; b=PxUNvvL46T6oAfRgz5qlNqGkDhPG9EBR0z1EIPG3SQ1ZPs1/wa8X6OPKOC44we0HPEjV0QpbqOs8Z7WwF16Eti6PI60PBnGr32dy3PvY+WONCOiEYNExnHr0dATIlIaXXOIPxAfs1rh3NOnpnaZO31peymUg58cQnMeQwwasv1M=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2169.namprd11.prod.outlook.com (10.174.104.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Mon, 13 May 2019 17:57:12 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1878.024; Mon, 13 May 2019 17:57:12 +0000
From: "Reshad Rahman (rrahman)" 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-netconf-restconf-notif-13:_(with_COMMENT)?=
Thread-Index: AQHVCaVdp/OKn2KY1kmBszDth6Cp96ZpFDqA
Date: Mon, 13 May 2019 17:57:12 +0000
Message-ID: <6AA3C49F-28F9-43A3-9712-CF3CB26102EA@cisco.com>
References: <155776336478.23641.7579515397254467186.idtracker@ietfa.amsl.com>
In-Reply-To: <155776336478.23641.7579515397254467186.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a6b9eadb-af08-415b-530d-08d6d7cc6d33
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2169; 
x-ms-traffictypediagnostic: DM5PR1101MB2169:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(14454004)(46003)(446003)(11346002)(486006)(476003)(83716004)(186003)(966005)(2616005)(102836004)(6506007)(6246003)(71200400001)(71190400001)(305945005)(7736002)(224303003)(76176011)(99286004)(478600001)(81166006)(81156014)(66574012)(8936002)(53936002)(110136005)(25786009)(68736007)(82746002)(54906003)(5660300002)(256004)(14444005)(4326008)(6116002)(36756003)(6306002)(58126008)(6512007)(6486002)(6436002)(229853002)(86362001)(66946007)(2906002)(66476007)(66556008)(64756008)(66446008)(33656002)(316002)(73956011)(91956017)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2169; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XpyaNw8PzdQw+EmgcBmSe7sw3sw8pi/hbXWnl5Wtqce//L3SuzpGXCXpAU43LqPSI1mutj5W9wmyQNx6Qzd4l++7GvC338Ji5kfGRN1wD482P49sKzVZKwYbjAm4eb2nmkcNlV/9RejTmvBFYUL1rVHeizPtWLjXBrpLriSSqK2Jf0ci3PcO7yrn0bmiWaDjbk8TlB7//U3+EHYlFAwM5nPkq1K9PhmTmSY66xsdBELjkWg8uZobgGUMP1NyVy+5P8Oyb2RcjOTMG1Lxqt2QEgXU1/jMPSY6qQsyDIuvBeIyCn6P4W1eB3GSbG/YjvAFmQFeDMG6el9vUqFjK930ru3w9aUhnszhK87tKiKzSAYr+ygmRID2K3w/pgaKa7rfh1yymLC8BD7ATm+XNzSWBGzkZLyBVZmYbuSxeE7FyCs=
Content-Type: text/plain; charset="utf-8"
Content-ID: <570D703ED4B8C646B30D96906ED80DB6@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a6b9eadb-af08-415b-530d-08d6d7cc6d33
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2019 17:57:12.3112 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2169
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netconf]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-restconf-notif-13=3A_=28with_COMMENT=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 May 2019 17:57:35 -0000

DQoNCkhpLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZS4N
Cg0KDQrvu79PbiAyMDE5LTA1LTEzLCAxMjowMyBQTSwgIk1pcmphIEvDvGhsZXdpbmQgdmlhIERh
dGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBNaXJqYSBLw7xobGV3
aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRy
YWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZi0xMzogTm8gT2JqZWN0aW9uDQogICAgDQog
ICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh
bmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh
bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFy
YWdyYXBoLCBob3dldmVyLikNCiAgICANCiAgICANCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAg
Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0
aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs
bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLw0KICAgIA0K
ICAgIA0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCiAgICANCiAgICBPbmUgcXVlc3Rpb24gKGFuZCB0aGlzIGlzIHByb2JhYmx5IGp1c3Qg
YmVjYXVzZSBvZiBteSBsYWNrIG9mIGRldGFpbGVkDQogICAga25vd2xlZGdlIGFib3V0IFJFU1RD
T05GKToNCiAgICANCiAgICBTZWMgNCBzYXlzOiAiVG8gbWVldCBzdWJzY3JpcHRpb24gcXVhbGl0
eSBvZiBzZXJ2aWNlIHByb21pc2VzLCB0aGUgcHVibGlzaGVyDQogICAgTVVTVA0KICAgICAgIHRh
a2UgYW55IGV4aXN0aW5nIHN1YnNjcmlwdGlvbiAiZHNjcCIgYW5kIGFwcGx5IGl0IHRvIHRoZSBE
U0NQDQogICAgICAgbWFya2luZyBpbiB0aGUgSVAgaGVhZGVyLiINCiAgICBXaGF0IGRvZXMgImV4
aXN0aW5nIHN1YnNjcmlwdGlvbiAiZHNjcCIiIG1lYW4gaGVyZT8NClRoaXMgaXMgcmVmZXJyaW5n
IHRvIHRoZSAiZHNjcCIgbGVhZiBub2RlIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnMuIEJ1dCBhcyBCZW5qYW1pbiBwb2ludGVkIG91dCwgd2Ugd2lsbCBiZSBy
ZW1vdmluZyB0aGlzIHNlY3Rpb24gZnJvbSB0aGlzIGRyYWZ0IHNpbmNlIHRoZSB0ZXh0IGdvdCBh
ZGRlZCB0byBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMuDQoNCiAgICANCiAgICBSZWxhdGVkIHVw
ZGF0ZTogcGxlYXNlIGFsc28gY29uc2lkZXIgdGhlIGNvbW1lbnQgZnJvbSB0aGUgVFNWLUFSVCBy
ZXZpZXcgYWJvdXQNCiAgICB0aGUgZXhhbXBsZSBEU0NQIHZhbHVlIChUaGFua3MgV2VzISkuIEkg
YWN0dWFsbHkgd291bGQgYWxzbyBhcHByZWNpYXRlIHRvIGFkZCBhDQogICAgY29tbWVudCB0aGF0
IHRoaXMgaXMgYW4gaW50ZXJuYWwgdmFsdWUgdGhhdCBkZXBlbmRzIG9uIHRoZSBuZXR3b3JrDQog
ICAgY29uZmlndXJhdGlvbiAoaW4gb3JkZXIgdG8gYXZvaWQgdGhhdCBwZW9wbGUganVzdCByYW5k
b21seSBjb3B5IHRoaXMgZXhhbXBsZQ0KICAgIHZhbHVlIGFuZCBzdWRkZW5seSBhbHdheXMgdXNl
IDEwKSENCk5vdGVkLg0KDQpSZWdhcmRzLA0KUmVzaGFkLiAgDQogICAgDQogICAgDQoNCg==


From nobody Tue May 14 01:41:42 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D721200FA; Tue, 14 May 2019 01:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3e8KPxQ2YDw; Tue, 14 May 2019 01:41:31 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 802191200CE; Tue, 14 May 2019 01:41:31 -0700 (PDT)
Received: from 200116b82cebde00487f6fba2997f96c.dip.versatel-1u1.de ([2001:16b8:2ceb:de00:487f:6fba:2997:f96c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hQSzu-0005T3-MH; Tue, 14 May 2019 10:41:18 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind 
In-Reply-To: <6AA3C49F-28F9-43A3-9712-CF3CB26102EA@cisco.com>
Date: Tue, 14 May 2019 10:41:18 +0200
Cc: The IESG , "draft-ietf-netconf-restconf-notif@ietf.org" ,  Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E5187F0-B326-40BB-8966-F182A8D8B738@kuehlewind.net>
References: <155776336478.23641.7579515397254467186.idtracker@ietfa.amsl.com> <6AA3C49F-28F9-43A3-9712-CF3CB26102EA@cisco.com>
To: "Reshad Rahman (rrahman)" 
X-Mailer: Apple Mail (2.3445.104.8)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1557823291;7e015073;
X-HE-SMSGID: 1hQSzu-0005T3-MH
Archived-At: 
Subject: Re: [netconf]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-netconf-restconf-notif-13=3A_=28with_COMMENT=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 08:41:35 -0000

Hi Reshad,

Okay. Thanks for the info!

Mirja


> On 13. May 2019, at 19:57, Reshad Rahman (rrahman)  =
wrote:
>=20
>=20
>=20
> Hi,
>=20
> Thank you for your review. Please see inline.
>=20
>=20
> =EF=BB=BFOn 2019-05-13, 12:03 PM, "Mirja K=C3=BChlewind via =
Datatracker"  wrote:
>=20
>    Mirja K=C3=BChlewind has entered the following ballot position for
>    draft-ietf-netconf-restconf-notif-13: No Objection
>=20
>    When responding, please keep the subject line intact and reply to =
all
>    email addresses included in the To and CC lines. (Feel free to cut =
this
>    introductory paragraph, however.)
>=20
>=20
>    Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
>    for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
>    The document, along with other ballot positions, can be found here:
>    https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/
>=20
>=20
>=20
>    =
----------------------------------------------------------------------
>    COMMENT:
>    =
----------------------------------------------------------------------
>=20
>    One question (and this is probably just because of my lack of =
detailed
>    knowledge about RESTCONF):
>=20
>    Sec 4 says: "To meet subscription quality of service promises, the =
publisher
>    MUST
>       take any existing subscription "dscp" and apply it to the DSCP
>       marking in the IP header."
>    What does "existing subscription "dscp"" mean here?
> This is referring to the "dscp" leaf node in =
draft-ietf-netconf-subscribed-notifications. But as Benjamin pointed =
out, we will be removing this section from this draft since the text got =
added to subscribed-notifications.
>=20
>=20
>    Related update: please also consider the comment from the TSV-ART =
review about
>    the example DSCP value (Thanks Wes!). I actually would also =
appreciate to add a
>    comment that this is an internal value that depends on the network
>    configuration (in order to avoid that people just randomly copy =
this example
>    value and suddenly always use 10)!
> Noted.
>=20
> Regards,
> Reshad. =20
>=20
>=20
>=20


From nobody Tue May 14 04:47:47 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0212B12023E; Tue, 14 May 2019 04:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level: 
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqRHTGlxOHfu; Tue, 14 May 2019 04:47:43 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40136.outbound.protection.outlook.com [40.107.4.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6C512011D; Tue, 14 May 2019 04:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kwz28VGWEARLQp01ztODptTCgO8hcRfpGm7UyIv44kA=; b=jRn2JYF7qMrYFUPvltAoqCXq0H83TRtatQOGiKfshKB5CFpYZsJQY3vWa5thSt9es2WeqlYi1+jKYKF9PDlQDCwM+n+RcIycqTf1nKFC84x2lfT299XTLrR49owF5JqZ1uyffYPtIY/ar+1I69D2/5S3Hb9dIw2DMXEXNBz/fwU=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB4573.eurprd07.prod.outlook.com (20.177.56.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.5; Tue, 14 May 2019 11:47:40 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1900.010; Tue, 14 May 2019 11:47:40 +0000
From: tom petch 
To: "Eric Voit (evoit)" , Dhruv Dhody , Kent Watsen 
CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "rtg-dir@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHVCkrVRLH1NGoaRE+6tKjUhBK41g==
Date: Tue, 14 May 2019 11:47:39 +0000
Message-ID: <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net>
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>     <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0339.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::15) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dddd2f64-f8b4-4ee9-a425-08d6d861f76e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4573; 
x-ms-traffictypediagnostic: VI1PR07MB4573:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(376002)(366004)(39860400002)(51444003)(51914003)(199004)(189003)(13464003)(53546011)(50226002)(3846002)(476003)(6512007)(110136005)(446003)(54906003)(102836004)(486006)(86362001)(14454004)(9686003)(8936002)(2906002)(81156014)(81166006)(66066001)(71200400001)(229853002)(52116002)(68736007)(6436002)(84392002)(76176011)(386003)(44736005)(81686011)(81816011)(6506007)(6486002)(316002)(61296003)(53936002)(25786009)(305945005)(1556002)(7736002)(4326008)(5660300002)(6116002)(14496001)(86152003)(186003)(99286004)(44716002)(26005)(62236002)(478600001)(14444005)(256004)(66446008)(8676002)(73956011)(66556008)(15650500001)(64756008)(66946007)(66476007)(4720700003)(6246003)(71190400001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4573; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AheCw2HFrYWbrgbNSbvFmeUZ6hwivuyZF0f8Fr109tE138doL4JEypNM1CPQKL/EV7D0+Bf1EdZ9A+kywxixCAAhpLlVD/RLJvIG1tqaXzOj4ILJG15btcNJ/qm0EzMYLrtvbE3rxQDWP6HQVT3iVsuq1jcsabEPntZEobeLJ50+mtpW0pBRlFQrwzEm7menZ3xNbrjSYrFAGUvJLayokIK3cFroMtFUeMGrN+qewxplqXDkzQPw8Nn7OPu0fdSuLhWoslN1mV7riHrVpxzWmH93bI9XxvyfGr60zwm70sZzCvWxSJudbvIi9j2mR50Hmb6eadOGlC329cGAooaH1jOIlNu5m+M6QH7zsGnaCyuzDwaSo8jnJBisIGYFEL455xA9/6jR52wHVuyiSpf2YSWLDB7oKgtPRRQHyLeInPA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3883871607C4DE4BA71C674F975A5E31@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dddd2f64-f8b4-4ee9-a425-08d6d861f76e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 11:47:39.8492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4573
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 11:47:46 -0000

RXJpYw0KDQpBIHF1aWNrIGJyb3dzZSB0ZWxscyBtZSB0aGF0IGluIHRoZSBSRkMgSSByZWd1bGFy
bHkgcmVmZXIgdG8sICdiaW5kaW5nJw0KaXMgdXNlZCBpbiBvdmVyIDMwMCBvZiB0aGVtIGJ1dCB0
aGF0IGluIGFsbCB0aG9zZSB0aGF0IEkgbG9va2VkIGF0LCBpdA0KaXMgYWx3YXlzIGJpbmRpbmcg
YW4gZWxlbWVudCBvZiBhIHNldCB0byBhbiBlbGVtZW50IG9mIHRoZSBzYW1lIG9yIGENCmRpZmZl
cmVudCBzZXQsIHdoZXJlIHRoZSBzZXRzIGFyZSBzaW1pbGFyIGluIG5hdHVyZS4gIFRodXMgQVJQ
IGJpbmRzIGFuDQpJUCBhZGRyZXNzIHRvIGEgTUFDIGFkZHJlc3Mgb3IgYSBiaWRpcmVjdGlvbmFs
IE1QTFMgTFNQIGJpbmRzIG9uZQ0KdW5pZGlyZWN0aW9uYWwgTFNQIHRvIGFub3RoZXIgYW5kIHNv
IG9uZS4NCg0KV2hhdCBJIGRvIG5vdCBsZWFybiBoZXJlIGlzIHdoYXQgaXMgYmVpbmcgYm91bmQg
dG8gd2hhdC4NCg0KUGVyaGFwcw0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGJpbmRp
bmcgb2YgYSBzdHJlYW0gb2YgZXZlbnRzIHdoaWNoIGZvcm0NCnBhcnQgb2YgYSBkeW5hbWljIHN1
YnNjcmlwdGlvbiB0byB0aGUgTkVUQ09ORg0KICAgcHJvdG9jb2wgW1JGQzYyNDFdLiAgRHluYW1p
YyBzdWJzY3JpcHRpb25zIGFyZSBkZWZpbmVkIGluDQogICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29u
Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLg0KDQpUaGUgY3J1eCBpcyAiYmluZGluZyAuLi4g
dG8gLi4uIiB3aGljaCBpcyBjdXJyZW50bHkgbGFja2luZy4NCg0KTW9yZSBnZW5lcmFsbHk6LSgN
CkkgZG8gZmluZCB0aGlzIEktRCBoYXJkIHRvIHVuZGVyc3RhbmQuICBJIHRoaW5rIHRoYXQgdGhl
IGtleSBpcyB0aGF0DQp0aGlzIEktRCwgbW9yZSB0aGFuIGFueSBvdGhlciBJIGNhbiB0aGluayBv
ZiwgaXMgc28gZGVwZW5kZW50IG9uIG9uZSBvZg0KaXRzIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLCB0
byB3aGl0LCBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnM7IEkgdGhpbmsNCnRoYXQgdGhhdCBuZWVk
cyBjYWxsaW5nIG91dCBzbyBJIHdvdWxkIGFkZA0KIlRoaXMgbWVtbyBhc3N1bWVzIHRoYXQgdGhl
IHJlYWRlciBpcyBmYW1pbGlhciB3aXRoIHRoZSB0ZXJtaW5vbG9neSBhbmQNCmNvbmNlcHRzIGRl
ZmluZWQgaW4gW3N1YnNjcmliZWQtbm90aWZpY2F0aW9uc10iDQoNClllcywgdGhhdCBpcyB3aGF0
IGEgTm9ybWF0aXZlIFJlZmVyZW5jZSBtZWFucyBidXQgSSBmaW5kIHRoaXMgZXhhbXBsZSBzbw0K
ZXh0cmVtZSB0aGF0IEkgdGhpbmsgaXQgbmVlZHMgY2FsbGluZyBvdXQuICBFYWNoIHRpbWUgaW4g
dGhlIHBhc3Qgc2l4DQptb250aHMgSSBoYXZlIHR1cm5lZCB0byB0aGlzIEktRCAoaXQgaXMgdGhl
IHNtYWxsZXN0IG9mIHRoZSB2ZXJ5IGxhcmdlDQpzZXQgb2YgbmV0Y29uZiBJLURzOi0pLCBJIGhh
dmUgZ2l2ZW4gdXAsIGV2ZW50dWFsbHkgd29ya2luZyBvdXQgdGhhdA0KZmlyc3QgSSBtdXN0IG1h
c3RlciB0aGUgODAgcGFnZXMgb2Ygc3Vic2NyaWJlZCBub3RpZmljYXRpb25zLiAgVGhpcyBtYXkN
Cm5vdCBiZSBzbyBvYnZpb3VzIHRvIHRob3NlIGludm9sdmVkIGF0IExhc3QgQ2FsbCB0aW1lLg0K
DQpUb20gUGV0Y2gNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiRXJp
YyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+DQpTZW50OiBGcmlkYXksIE1heSAxMCwg
MjAxOSA3OjM5IFBNDQoNCg0KPiBIaSBEaHJ1diwNCj4gSGkgS2VudCwNCj4NCj4gPiBGcm9tOiBE
aHJ1diBEaG9keSwgTWF5IDksIDIwMTkgMTE6MjggUE0NCj4gPg0KPiA+IEhpIEVyaWMsDQo+ID4N
Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBFcmljIFZvaXQg
KGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NCj4gPiA+IFNlbnQ6IDEwIE1heSAyMDE5
IDAyOjE4DQo+ID4gPiBIaSBEaHJ1diwNCj4gPiA+DQo+ID4gPiA+IEZyb206IERocnV2IERob2R5
LCBNYXkgOSwgMjAxOSAxMjowMyBBTQ0KPiA+ID4gPg0KPiA+ID4gPiBIaSBFcmljLA0KPiA+ID4g
Pg0KPiA+ID4gPiBUaGFua3MgZm9yIHRoZSB1cGRhdGUuIEkgc2VlIG9uZSBtaW5vciBjb21tZW50
IHRoYXQgaXMgbm90DQpoYW5kbGVkLg0KPiA+ID4gPiBNYXliZSB5b3UgbWlzc2VkIGl0PyBPciB5
b3UgZGlzYWdyZWUsIHRoYXQgc29tZSBtb3JlIHRleHQgaXMNCnJlcXVpcmVkPw0KPiA+ID4gPg0K
PiA+ID4gPiA+IE1pbm9yIElzc3VlczoNCj4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+
ID4gKDEpIEFic3RyYWN0ICYgSW50cm9kdWN0aW9uLCBJdCBpcyBub3QgY2xlYXIgd2hhdCBkb2Vz
IHRoZQ0KJ2JpbmRpbmcnDQo+ID4gPiA+ID4gbWVhbiBhbmQgd2hvIGFyZSB0aGUgcGFydGllcyB0
byB0aGlzIGJpbmRpbmc/IElmIHRoaXMgaXMgdGhlDQo+ID4gPiA+ID4gZG9jdW1lbnQgdGhhdA0K
PiA+ID4gPiBtZW50aW9ucyAnYmluZGluZycNCj4gPiA+ID4gPiBmaXJzdCwgc28gcGxlYXNlIGFk
ZCBzb21lIG1vcmUgY2xhcmlmeWluZyB0ZXh0Lg0KPiA+ID4NCj4gPiA+IFRoaXMgaXMgbm90IHRo
ZSBmaXJzdCBkb2N1bWVudCB3aGljaCBtZW50aW9ucyAnYmluZGluZycgIGZpcnN0Lg0KVGhlDQo+
ID4gPiBkb2N1bWVudCB3aGljaCBkb2VzIHRoaXMgZmlyc3QgaXMgZHJhZnQtaWV0Zi1uZXRjb25m
LXN1YnNjcmliZWQtDQo+ID4gPiBub3RpZmljYXRpb25zLg0KPiA+IFtbRGhydXYgRGhvZHldXSBk
cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHNheXMNCnRoaXMgaW4g
dGhlDQo+ID4gSW50cm9kdWN0aW9uIC0NCj4gPg0KPiA+ICAgIFdoaWxlIHRoZSBmdW5jdGlvbmFs
aXR5IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyB0cmFuc3BvcnQtDQo+ID4gICAgYWdub3N0
aWMsIHRyYW5zcG9ydHMgbGlrZSBORVRDT05GIFtSRkM2MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0
MF0NCmNhbg0KPiA+ICAgIGJlIHVzZWQgdG8gY29uZmlndXJlIG9yIGR5bmFtaWNhbGx5IHNpZ25h
bCBzdWJzY3JpcHRpb25zLCBhbmQNCnRoZXJlDQo+ID4gICAgYXJlIGJpbmRpbmdzIGRlZmluZWQg
Zm9yIHN1YnNjcmliZWQgZXZlbnQgcmVjb3JkIGRlbGl2ZXJ5IGZvcg0KTkVUQ09ORg0KPiA+ICAg
IHdpdGhpbiBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlv
bnNdLCBhbmQNCmZvcg0KPiA+ICAgIFJFU1RDT05GIHdpdGhpbiBbSS1ELmRyYWZ0LWlldGYtbmV0
Y29uZi1yZXN0Y29uZi1ub3RpZl0uDQo+ID4NCj4gPiBJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1l
IGJpbmRpbmcgaXMgdXNlZCBpbiB0aGlzIGNvbnRleHQuDQo+ID4gQW5kIG5vdyB0aGlzIEktRCBz
YXlzIC0NCj4gPg0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBl
dmVudHMgc3RyZWFtZWQgb3ZlciB0aGUNCk5FVENPTkYNCj4gPiAgICBwcm90b2NvbCBbUkZDNjI0
MV0gZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBhcyBkZWZpbmVkIGluDQo+ID4gICAgW0ktRC5k
cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCj4gPg0KPiA+IEFu
ZCB5b3UgZG9u4oCZdCB1c2UgdGhpcyB0ZXJtIGV2ZXIgYWdhaW4uDQo+ID4NCj4gPiBUbyBtZSB0
aGlzIGlzIGJpdCBjaXJjdWxhciBhbmQgdGhlIHRlcm0gYmluZGluZyBpcyB1c2VkIGxvb3NlbHku
IEFuZA0KdGh1cyBJIGZsYWdnZWQNCj4gPiBpdC4gSSB3aWxsIGxldCB5b3UgYW5kIEtlbnQgZGVj
aWRlIHRoZSByaWdodCBhcHByb2FjaC4NCj4NCj4gSSByZWFsbHkgYW0gb2sgd2l0aCBtYW55IG9w
dGlvbnMgaGVyZToNCj4gIChhKSAga2VlcCB0aGUgY3VycmVudCB0ZXh0Lg0KPiAgKGIpICB1c2Ug
cHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIGFic3RyYWN0Lg0KPiAgKGMpICByZXBsYWNlIHRoZSB3
b3JkIGJpbmRpbmcgd2l0aCBzb21lIG90aGVyIHRleHQuDQo+DQo+IEdldHRpbmcgdGhlIHJpZ2h0
IHdvcmRzIGhlcmUgbmFpbGVkIGRvd24gaGFzbid0IGJlZW4gZnJvbSBsYWNrIG9mDQplZmZvcnQu
ICBUbyBnaXZlIHlvdSBhbiBpZGVhLCBiZWxvdyBhcmUgZm91ciBwcmV2aW91cyBhdHRlbXB0cyBh
dCB0aGUNCmFic3RyYWN0Lg0KPg0KPiBGcm9tIC12NQ0KPg0KPiAgICBUaGlzIGRvY3VtZW50IGRl
ZmluZXMgaG93IHRvIHRyYW5zcG9ydCBuZXR3b3JrIHN1YnNjcmlwdGlvbnMgYW5kDQo+ICAgIGV2
ZW50IG1lc3NhZ2VzIG9uIHRvcCBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIHByb3RvY29s
DQo+ICAgIChORVRDT05GKS4gIFRoaXMgaW5jbHVkZXMgdGhlIGZ1bGwgc2V0IG9mIFJQQ3MsIHN1
YnNjcmlwdGlvbiBzdGF0ZQ0KPiAgICBjaGFuZ2VzLCBhbmQgc3Vic2NyaWJlZCBjb250ZW50IG5l
ZWRpbmcgYXN5bmNocm9ub3VzIGRlbGl2ZXJ5Lg0KPg0KPg0KPiBGcm9tIC12Ng0KPg0KPiAgICBU
aGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5nIGZvcg0KPiAgICBbSS1ELmRy
YWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLiAgSW5jbHVkZWQgYXJl
Og0KPg0KPiAgICBvICBUcmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1YnNjcmlwdGlvbiBSUENzLCBz
dGF0ZSBjaGFuZ2UNCj4gICAgICAgbm90aWZpY2F0aW9ucywgYW5kIG5vdGlmaWNhdGlvbiBtZXNz
YWdlcw0KPg0KPiAgICBvICBGdW5jdGlvbmFsaXR5IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdp
dGggTkVUQ09ORg0KPg0KPiAgICBvICBFeGFtcGxlcyBpbiBhcHBlbmRpY2VzDQo+DQo+DQo+IEZy
b20gLXY3DQo+DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBORVRDT05GIGJpbmRpbmcg
Zm9yDQo+ICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u
c10gYW5kDQo+ICAgIFtJLUQuaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0uICBJbmNsdWRlZCBhcmU6
DQo+DQo+ICAgIG8gIHRyYW5zcG9ydCBtYXBwaW5ncyBmb3Igc3Vic2NyaXB0aW9uIFJQQ3MsIHN0
YXRlIGNoYW5nZQ0KPiAgICAgICBub3RpZmljYXRpb25zLCBhbmQgbm90aWZpY2F0aW9uIG1lc3Nh
Z2VzLA0KPiAgICBvICBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cywgYW5kDQo+ICAgIG8gIGV4YW1w
bGVzDQo+DQo+DQo+IEZyb20gLXY4DQo+DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBO
RVRDT05GIGJpbmRpbmcgdG8gc3Vic2NyaWJlZA0Kbm90aWZpY2F0aW9ucw0KPiAgICBhbmQgdG8g
WUFORyBwdXNoLg0KPg0KPg0KPiBIb25lc3RseSBJIGxpa2UgdGhlIHY1IHZlcnNpb24uICAgQnV0
IHByZXZpb3VzIHJldmlld2VycyBoYXZlDQppbmNyZW1lbnRhbGx5IGRyaXZlbiB0aGluZ3MgdG8g
dGhlIGN1cnJlbnQgdGV4dC4gICAgSWYgS2VudCB5b3UgcHJlZmVyDQpzb21ldGhpbmcgb3RoZXIg
dGhhbiB0aGUgY3VycmVudCB0ZXh0LCBsZXQgbWUga25vdyB3aGF0IGl0IGlzLiAgSSBhbQ0Kc3Vy
ZSBJIHdpbGwgbGlrZSBpdCB0b28uDQo+DQo+IEVyaWMNCj4NCj4NCj4gPiBUaGFua3MhDQo+ID4g
RGhydXYNCj4gPg0KPiA+DQo+ID4gPiBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCwg
dGhhdCBkcmFmdCBpcyBub3QgZXhwbGljaXRseQ0KbGlzdGVkDQo+ID4gPiBieSByZWZlcmVuY2Ug
KGFzIEkgdW5kZXJzdG9vZCB3ZSBhcmUgbm90IHN1cHBvc2VkIHRvIHVzZQ0KcmVmZXJlbmNlcyBp
bg0KPiA+ID4gYWJzdHJhY3RzKS4gIEJ1dCBpdCBpcyBsaXN0ZWQgaW4gdGhlIEludHJvZHVjdGlv
bi4NCj4gPiA+DQo+ID4gPiBUbyBtYWtlIHRoaXMgY2xlYXJlciBmb3IgeW91IGluIHRoaXMgZG9j
dW1lbnQsIHBlcmhhcHMgInRyYW5zcG9ydA0KYmluZGluZyINCj4gPiA+IGluc3RlYWQgb2YgImJp
bmRpbmciPyAgIEkgcmVhbGx5IGRvbid0IGhhdmUgbWFueSBhbHRlcm5hdGl2ZXMgSQ0KY2FuIHRo
aW5rDQo+ID4gPiBvZiB3aGljaCBhbHNvIGtlZXBzIHRoZSB0ZXh0IGJyaWVmLiAgIFRoaXMgcGFy
dGljdWxhciB0ZXh0IGhhcw0KYmVlbg0KPiA+ID4gZnJlcXVlbnRseSB0d2Vha2VkIGluIHRoZSBw
YXN0Lg0KPiA+ID4NCj4gPiA+IFRoYW5rcy4NCj4gPiA+IEVyaWMNCj4gPiA+DQo+ID4gPg0KPiA+
ID4gPiBUaGFua3MhDQo+ID4gPiA+IERocnV2Pg0KPiA+ID4gPiBPbiBXZWQsIE1heSA4LCAyMDE5
IGF0IDk6MTQgUE0gRXJpYyBWb2l0IChldm9pdCkNCjxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0K
PiA+ID4gPiA+DQo+ID4gPiA+ID4gVXBkYXRlIHBvc3RlZCBhcyAtdjIwLiAgIFdpdGggdGhlIGNv
cnJlc3BvbmRpbmcgY2hhbmdlIHRvDQpkcmFmdC1pZXRmLQ0KPiA+ID4gbmV0Y29uZi0NCj4gPiA+
ID4gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHBvc3RlZCBhcyAtdjI1Lg0KPiA+ID4gPiA+DQo+
ID4gPiA+ID4gRXJpYw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwg
TWF5IDgsIDIwMTkgMjoyMSBBTQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIEtlbnQsIEVy
aWMsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gRmluZSB3aXRoIG1lIQ0KPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+IFRoYW5rcyENCj4gPiA+ID4gPiA+IERocnV2DQo+ID4gPiA+ID4gPg0KPiA+
ID4gPiA+ID4gT24gV2VkLCBNYXkgOCwgMjAxOSBhdCAzOjE5IEFNIEtlbnQgV2F0c2VuDQo+ID4g
PiA+ID4gPiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA8ZXJpYz4g
QmFzZWQgb24gbXkgcmVhZGluZyBvZiB5b3VyIHByb2Nlc3Mgc3VnZ2VzdGlvbnMNCktlbnQsIEkN
Cj4gPiA+ID4gPiA+ID4gbGlrZSBiZXN0IHRoZQ0KPiA+ID4gPiA+ID4g4oCcbWVudGlvbuKAnSBh
cHByb2FjaCB3aGljaCB5b3UgdXNlZCBmb3IgUkZDLTgwNzEsIFNlY3Rpb24gMS40Lg0KPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXaGF0IEkgdGhpbmsgY291bGQgYmUgZG9uZSB0byBjb3Zl
ciB0aGlzIGlzOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAoQSkgIFJlbW92ZSBTZWN0
aW9uIDExOiBOb3RlcyB0byB0aGUgUkZDIEVkaXRvcg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiAoQikgIFBlciBLZW504oCZcyBkZXNpcmUgdG8gYWxzbyBjb3Zlcg0KPiA+ID4gPiA+ID4g
PiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBsYWNlIHRoZQ0KPiA+ID4gPiA+
ID4gZm9sbG93aW5nIHN0YXRlbWVudCBpbnRvDQo+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLW5ldGNv
bmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4gPiA+ID4gPiBkaXJlY3RseSBhZnRlciBG
aWd1cmUgMTANCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gW1JGQy01Mjc3XSBTZWN0aW9u
IDIuMi4xIHN0YXRlcyB0aGF0IGEgbm90aWZpY2F0aW9uDQptZXNzYWdlIGlzDQo+ID4gPiA+ID4g
PiA+IHRvIGJlIHNlbnQgdG8gYQ0KPiA+ID4gPiA+ID4gc3Vic2NyaWJlciB3aGljaCBpbml0aWF0
ZWQgYSAiY3JlYXRlLXN1YnNjcmlwdGlvbiIuICAgV2l0aA0KdGhpcw0KPiA+ID4gc3BlY2lmaWNh
dGlvbiwNCj4gPiA+ID4gdGhpcw0KPiA+ID4gPiA+ID4gUkZDLTUyNzcgc3RhdGVtZW50IHNob3Vs
ZCBiZSBtb3JlIGJyb2FkbHkgaW50ZXJwcmV0ZWQgdG8NCm1lYW4NCj4gPiA+ID4gPiA+IHRoYXQg
bm90aWZpY2F0aW9uIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIHNlbnQgdG8gYSBzdWJzY3JpYmVyDQo+
ID4gPiA+ID4gPiB3aGljaCBpbml0aWF0ZWQgYW4gImVzdGFibGlzaC1zdWJzY3JpcHRpb24iLCBv
ciBhIGNvbmZpZ3VyZWQNCj4gPiA+ID4gPiA+IHJlY2VpdmVyIHdoaWNoIGhhcyBiZWVuIHNlbnQg
YSDigJxzdWJzY3JpcHRpb24tc3RhcnRlZOKAnS4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gRG9lcyB0aGlzIHdvcmsgZm9yIGJvdGggb2YgeW91Pw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBXb3JrcyBmb3IgbWUuDQo+ID4gPiA+ID4gPiA+DQo+ID4g
PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoZSBpc3N1ZSBpc24ndCBj
b25zaXN0ZW5jeSBzbyBtdWNoIGFzIG1lZXRpbmcNCmV4cGVjdGF0aW9ucywNCj4gPiA+ID4gPiA+
ID4gcGVyIGB4bWwycmZjYCwgdGhlDQo+ID4gPiA+ID4gPiBkb2N1bWVudCBzaG91bGQgaGF2ZSBz
b21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIGluIHRoZQ0KPiA+ID4gPiA+ID4gUmVmZXJlbmNl
cyBzZWN0aW9uLCB3aGljaCB0aGVuIGF1dG8tZXhwYW5kcyB0byB0aGUgY29ycmVjdA0KPiA+ID4g
PiA+ID4gcmVmZXJlbmNlIHRleHQsIGFzIHdlbGwgYXMgZGVmaW5pbmcgdGhlIGFuY2hvcg0KPiA+
ID4gPiA+ID4gIkktRC5pZXRmLW5ldGNvbmYtDQo+ID4gPiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlv
bnMiOg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiAgICAgICAgIDw/cmZjDQo+ID4gPiA+
ID4gPiA+DQppbmNsdWRlPSJyZWZlcmVuY2UuSS1ELmlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v
dGlmaWNhdGlvbnMiPw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g
PiA+IDxFcmljPiBUaGF0IGRlZmluaXRlbHkgbWFrZXMgdGhpbmdzIGVhc2llciB0aGFuIHdoYXQg
SQ0KaGF2ZQ0KPiA+ID4gPiA+ID4gPiBiZWVuIGRvaW5nLiAgSSBhbQ0KPiA+ID4gPiA+ID4gaGl0
dGluZyBhbiB4bWwycmZjIGVycm9yIHRyeWluZyB0aGlzIHJpZ2h0IG5vdywgYnV0IEkgd2lsbA0K
Z2V0IHRoZXJlLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBZ
ZXMsIGl0IHdhcyBhbiBleWUtb3BlbmVyIHdoZW4gSSBmaWd1cmVkIGl0IG91dC4gICBCZQ0KYXdh
cmUgdGhhdCwNCj4gPiA+IHRob3VnaA0KPiA+ID4gPiBzb21lDQo+ID4gPiA+ID4gPiBleHRlcm5h
bCBzb3VyY2VzIChlLmcuLCBJVFUgc3RhbmRhcmRzKSBhcmUgc3VwcG9ydGVkLCBtYW55DQphcmUN
Cj4gPiA+ID4gPiA+IG5vdCwgYW5kIHNvIGhhbmQtIGNvZGluZyB0aGUgPHJlZmVyZW5jZT4gaXMg
c3RpbGwgc29tZXRpbWVzDQo+ID4gPiByZXF1aXJlZC4uLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBLZW50IC8vIHNoZXBoZXJkDQo+ID4gPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+DQo+DQoNCg==


From nobody Tue May 14 08:00:14 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E562D120139; Tue, 14 May 2019 08:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh1U3TASQvtS; Tue, 14 May 2019 08:00:09 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E61612013A; Tue, 14 May 2019 07:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14106; q=dns/txt; s=iport; t=1557845985; x=1559055585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xBhrQ00WbNdEEd4CkbWCM0qyYYsDnjaf+x8oK4VBzAA=; b=OERUWC9C+MbutOy5DQBf0AgE1gIMfDt2F5Xuw6g8mPgGN5e5Wzc3J8XV /5lxfheKtjMkIdYu6B+EPYg/fLTZawRCz38H8Ktzzqg/UObPN9DusDRLA RJ6Rx9OkuFB+QqGyEGoub2RxR4czzW7rkbjOsVFO2NWaDEX4H9xGl7IF8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AgC+1tpc/4kNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYFnKoE9MCgKhAeVH5pOCQEBAQwBAS8BAYRAAheCBiM4EwEDAQEEAQE?= =?us-ascii?q?CAQRtKIVKAQEBAwEjEUMCBQcEAgEIFQECAgIJGgMCAgIwFAEQAgQBDQUIgk9?= =?us-ascii?q?LgXwPrlCBL4oxgQsoi08XgUA/hCM+hEszglCCWASLHgOCO5l9CQKCCZJWI4I?= =?us-ascii?q?UhkwFjQmDIIkUgSKTaAIRFYEwNiGBV3AVgyeQUUExj06BIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,469,1549929600"; d="scan'208";a="270275950"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2019 14:59:44 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EExidI021780 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 May 2019 14:59:44 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 May 2019 10:59:43 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 14 May 2019 10:59:43 -0400
From: "Eric Voit (evoit)" 
To: tom petch , Dhruv Dhody , Kent Watsen 
CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "rtg-dir@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZqyZ/Q
Date: Tue, 14 May 2019 14:59:43 +0000
Message-ID: <23a9e41d7bcb41d7a6b7a9eeb50aaa18@XCH-RTP-013.cisco.com>
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>     <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 15:00:12 -0000

SGkgVG9tLA0KDQo+IEZyb206IHRvbSBwZXRjaCwgTWF5IDE0LCAyMDE5IDc6NDggQU0NCj4gDQo+
IEVyaWMNCj4gDQo+IEEgcXVpY2sgYnJvd3NlIHRlbGxzIG1lIHRoYXQgaW4gdGhlIFJGQyBJIHJl
Z3VsYXJseSByZWZlciB0bywgJ2JpbmRpbmcnDQo+IGlzIHVzZWQgaW4gb3ZlciAzMDAgb2YgdGhl
bSBidXQgdGhhdCBpbiBhbGwgdGhvc2UgdGhhdCBJIGxvb2tlZCBhdCwgaXQgaXMgYWx3YXlzDQo+
IGJpbmRpbmcgYW4gZWxlbWVudCBvZiBhIHNldCB0byBhbiBlbGVtZW50IG9mIHRoZSBzYW1lIG9y
IGEgZGlmZmVyZW50IHNldCwgd2hlcmUNCj4gdGhlIHNldHMgYXJlIHNpbWlsYXIgaW4gbmF0dXJl
LiAgVGh1cyBBUlAgYmluZHMgYW4gSVAgYWRkcmVzcyB0byBhIE1BQyBhZGRyZXNzIG9yDQo+IGEg
YmlkaXJlY3Rpb25hbCBNUExTIExTUCBiaW5kcyBvbmUgdW5pZGlyZWN0aW9uYWwgTFNQIHRvIGFu
b3RoZXIgYW5kIHNvIG9uZS4NCj4gDQo+IFdoYXQgSSBkbyBub3QgbGVhcm4gaGVyZSBpcyB3aGF0
IGlzIGJlaW5nIGJvdW5kIHRvIHdoYXQuDQo+IA0KPiBQZXJoYXBzDQo+ICAgIFRoaXMgZG9jdW1l
bnQgc3BlY2lmaWVzIHRoZSBiaW5kaW5nIG9mIGEgc3RyZWFtIG9mIGV2ZW50cyB3aGljaCBmb3Jt
IHBhcnQgb2YgYQ0KPiBkeW5hbWljIHN1YnNjcmlwdGlvbiB0byB0aGUgTkVUQ09ORg0KPiAgICBw
cm90b2NvbCBbUkZDNjI0MV0uICBEeW5hbWljIHN1YnNjcmlwdGlvbnMgYXJlIGRlZmluZWQgaW4N
Cj4gICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4N
Cg0KSSBhbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBmaXJzdCBzZW50
ZW5jZSBvZiB0aGUgSW50cm8gaGVyZSwgYXMgZG9jdW1lbnQgcmVmZXJlbmNlcyBhcmUgbm90IGlu
IGFic3RyYWN0cy4NCg0KVGhpcyB0ZXh0IHdvcmtzIGZvciBtZS4gICBBbnkgb2JqZWN0aW9ucyBh
bnlvbmU/DQogDQo+IFRoZSBjcnV4IGlzICJiaW5kaW5nIC4uLiB0byAuLi4iIHdoaWNoIGlzIGN1
cnJlbnRseSBsYWNraW5nLg0KPiANCj4gTW9yZSBnZW5lcmFsbHk6LSgNCj4gSSBkbyBmaW5kIHRo
aXMgSS1EIGhhcmQgdG8gdW5kZXJzdGFuZC4gIEkgdGhpbmsgdGhhdCB0aGUga2V5IGlzIHRoYXQg
dGhpcyBJLUQsIG1vcmUNCj4gdGhhbiBhbnkgb3RoZXIgSSBjYW4gdGhpbmsgb2YsIGlzIHNvIGRl
cGVuZGVudCBvbiBvbmUgb2YgaXRzIE5vcm1hdGl2ZQ0KPiBSZWZlcmVuY2VzLCB0byB3aGl0LCBz
dWJzY3JpYmVkIG5vdGlmaWNhdGlvbnM7IEkgdGhpbmsgdGhhdCB0aGF0IG5lZWRzIGNhbGxpbmcg
b3V0DQo+IHNvIEkgd291bGQgYWRkICJUaGlzIG1lbW8gYXNzdW1lcyB0aGF0IHRoZSByZWFkZXIg
aXMgZmFtaWxpYXIgd2l0aCB0aGUNCj4gdGVybWlub2xvZ3kgYW5kIGNvbmNlcHRzIGRlZmluZWQg
aW4gW3N1YnNjcmliZWQtbm90aWZpY2F0aW9uc10iDQoNCkFzIHRoZSBsYXN0IHNlbnRlbmNlIGlu
IHRoZSBJbnRybyBzZWN0aW9uLCBJIGhhdmUgYWRkZWQ6IA0KIlRoaXMgZG9jdW1lbnQgYXNzdW1l
cyB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aCB0aGUgdGVybWlub2xvZ3kgYW5kIGNv
bmNlcHRzIGRlZmluZWQgaW4gW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp
ZmljYXRpb25zXS4iDQogDQo+IFllcywgdGhhdCBpcyB3aGF0IGEgTm9ybWF0aXZlIFJlZmVyZW5j
ZSBtZWFucyBidXQgSSBmaW5kIHRoaXMgZXhhbXBsZSBzbw0KPiBleHRyZW1lIHRoYXQgSSB0aGlu
ayBpdCBuZWVkcyBjYWxsaW5nIG91dC4gIEVhY2ggdGltZSBpbiB0aGUgcGFzdCBzaXggbW9udGhz
IEkgaGF2ZQ0KPiB0dXJuZWQgdG8gdGhpcyBJLUQgKGl0IGlzIHRoZSBzbWFsbGVzdCBvZiB0aGUg
dmVyeSBsYXJnZSBzZXQgb2YgbmV0Y29uZiBJLURzOi0pLCBJIGhhdmUNCj4gZ2l2ZW4gdXAsIGV2
ZW50dWFsbHkgd29ya2luZyBvdXQgdGhhdCBmaXJzdCBJIG11c3QgbWFzdGVyIHRoZSA4MCBwYWdl
cyBvZg0KPiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMuICBUaGlzIG1heSBub3QgYmUgc28gb2J2
aW91cyB0byB0aG9zZSBpbnZvbHZlZCBhdCBMYXN0DQo+IENhbGwgdGltZS4NCg0KVW5kZXJzdG9v
ZC4gIEFuZCBpdCBpcyB0cnVlIHRoYXQgdW5kZXJzdGFuZGluZyBzdWJzY3JpYmVkLW5vdGlmaWNh
dGlvbnMgaXMgYSBwcmVyZXF1aXNpdGUuDQoNCkVyaWMNCg0KPiBUb20gUGV0Y2gNCj4gDQo+IA0K
PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJFcmljIFZvaXQgKGV2b2l0
KSIgPGV2b2l0QGNpc2NvLmNvbT4NCj4gU2VudDogRnJpZGF5LCBNYXkgMTAsIDIwMTkgNzozOSBQ
TQ0KPiANCj4gDQo+ID4gSGkgRGhydXYsDQo+ID4gSGkgS2VudCwNCj4gPg0KPiA+ID4gRnJvbTog
RGhydXYgRGhvZHksIE1heSA5LCAyMDE5IDExOjI4IFBNDQo+ID4gPg0KPiA+ID4gSGkgRXJpYywN
Cj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206
IEVyaWMgVm9pdCAoZXZvaXQpIFttYWlsdG86ZXZvaXRAY2lzY28uY29tXQ0KPiA+ID4gPiBTZW50
OiAxMCBNYXkgMjAxOSAwMjoxOA0KPiA+ID4gPiBIaSBEaHJ1diwNCj4gPiA+ID4NCj4gPiA+ID4g
PiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDksIDIwMTkgMTI6MDMgQU0NCj4gPiA+ID4gPg0KPiA+
ID4gPiA+IEhpIEVyaWMsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGFua3MgZm9yIHRoZSB1cGRh
dGUuIEkgc2VlIG9uZSBtaW5vciBjb21tZW50IHRoYXQgaXMgbm90DQo+IGhhbmRsZWQuDQo+ID4g
PiA+ID4gTWF5YmUgeW91IG1pc3NlZCBpdD8gT3IgeW91IGRpc2FncmVlLCB0aGF0IHNvbWUgbW9y
ZSB0ZXh0IGlzDQo+IHJlcXVpcmVkPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBNaW5vciBJc3N1
ZXM6DQo+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiAoMSkgQWJzdHJhY3Qg
JiBJbnRyb2R1Y3Rpb24sIEl0IGlzIG5vdCBjbGVhciB3aGF0IGRvZXMgdGhlDQo+ICdiaW5kaW5n
Jw0KPiA+ID4gPiA+ID4gbWVhbiBhbmQgd2hvIGFyZSB0aGUgcGFydGllcyB0byB0aGlzIGJpbmRp
bmc/IElmIHRoaXMgaXMgdGhlDQo+ID4gPiA+ID4gPiBkb2N1bWVudCB0aGF0DQo+ID4gPiA+ID4g
bWVudGlvbnMgJ2JpbmRpbmcnDQo+ID4gPiA+ID4gPiBmaXJzdCwgc28gcGxlYXNlIGFkZCBzb21l
IG1vcmUgY2xhcmlmeWluZyB0ZXh0Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIGlzIG5vdCB0aGUg
Zmlyc3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRpbmcnICBmaXJzdC4NCj4gVGhlDQo+
ID4gPiA+IGRvY3VtZW50IHdoaWNoIGRvZXMgdGhpcyBmaXJzdCBpcyBkcmFmdC1pZXRmLW5ldGNv
bmYtc3Vic2NyaWJlZC0NCj4gPiA+ID4gbm90aWZpY2F0aW9ucy4NCj4gPiA+IFtbRGhydXYgRGhv
ZHldXSBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIHNheXMNCj4g
dGhpcyBpbiB0aGUNCj4gPiA+IEludHJvZHVjdGlvbiAtDQo+ID4gPg0KPiA+ID4gICAgV2hpbGUg
dGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIHRyYW5zcG9ydC0N
Cj4gPiA+ICAgIGFnbm9zdGljLCB0cmFuc3BvcnRzIGxpa2UgTkVUQ09ORiBbUkZDNjI0MV0gb3Ig
UkVTVENPTkYgW1JGQzgwNDBdDQo+IGNhbg0KPiA+ID4gICAgYmUgdXNlZCB0byBjb25maWd1cmUg
b3IgZHluYW1pY2FsbHkgc2lnbmFsIHN1YnNjcmlwdGlvbnMsIGFuZA0KPiB0aGVyZQ0KPiA+ID4g
ICAgYXJlIGJpbmRpbmdzIGRlZmluZWQgZm9yIHN1YnNjcmliZWQgZXZlbnQgcmVjb3JkIGRlbGl2
ZXJ5IGZvcg0KPiBORVRDT05GDQo+ID4gPiAgICB3aXRoaW4gW0ktRC5kcmFmdC1pZXRmLW5ldGNv
bmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zXSwgYW5kDQo+IGZvcg0KPiA+ID4gICAgUkVT
VENPTkYgd2l0aGluIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmXS4NCj4g
PiA+DQo+ID4gPiBJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1lIGJpbmRpbmcgaXMgdXNlZCBpbiB0
aGlzIGNvbnRleHQuDQo+ID4gPiBBbmQgbm93IHRoaXMgSS1EIHNheXMgLQ0KPiA+ID4NCj4gPiA+
ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVudHMgc3RyZWFtZWQg
b3ZlciB0aGUNCj4gTkVUQ09ORg0KPiA+ID4gICAgcHJvdG9jb2wgW1JGQzYyNDFdIGZvciBkeW5h
bWljIHN1YnNjcmlwdGlvbnMgYXMgZGVmaW5lZCBpbg0KPiA+ID4gICAgW0ktRC5kcmFmdC1pZXRm
LW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCj4gPiA+DQo+ID4gPiBBbmQgeW91
IGRvbuKAmXQgdXNlIHRoaXMgdGVybSBldmVyIGFnYWluLg0KPiA+ID4NCj4gPiA+IFRvIG1lIHRo
aXMgaXMgYml0IGNpcmN1bGFyIGFuZCB0aGUgdGVybSBiaW5kaW5nIGlzIHVzZWQgbG9vc2VseS4g
QW5kDQo+IHRodXMgSSBmbGFnZ2VkDQo+ID4gPiBpdC4gSSB3aWxsIGxldCB5b3UgYW5kIEtlbnQg
ZGVjaWRlIHRoZSByaWdodCBhcHByb2FjaC4NCj4gPg0KPiA+IEkgcmVhbGx5IGFtIG9rIHdpdGgg
bWFueSBvcHRpb25zIGhlcmU6DQo+ID4gIChhKSAga2VlcCB0aGUgY3VycmVudCB0ZXh0Lg0KPiA+
ICAoYikgIHVzZSBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgYWJzdHJhY3QuDQo+ID4gIChjKSAg
cmVwbGFjZSB0aGUgd29yZCBiaW5kaW5nIHdpdGggc29tZSBvdGhlciB0ZXh0Lg0KPiA+DQo+ID4g
R2V0dGluZyB0aGUgcmlnaHQgd29yZHMgaGVyZSBuYWlsZWQgZG93biBoYXNuJ3QgYmVlbiBmcm9t
IGxhY2sgb2YNCj4gZWZmb3J0LiAgVG8gZ2l2ZSB5b3UgYW4gaWRlYSwgYmVsb3cgYXJlIGZvdXIg
cHJldmlvdXMgYXR0ZW1wdHMgYXQgdGhlIGFic3RyYWN0Lg0KPiA+DQo+ID4gRnJvbSAtdjUNCj4g
Pg0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBob3cgdG8gdHJhbnNwb3J0IG5ldHdvcmsg
c3Vic2NyaXB0aW9ucyBhbmQNCj4gPiAgICBldmVudCBtZXNzYWdlcyBvbiB0b3Agb2YgdGhlIE5l
dHdvcmsgQ29uZmlndXJhdGlvbiBwcm90b2NvbA0KPiA+ICAgIChORVRDT05GKS4gIFRoaXMgaW5j
bHVkZXMgdGhlIGZ1bGwgc2V0IG9mIFJQQ3MsIHN1YnNjcmlwdGlvbiBzdGF0ZQ0KPiA+ICAgIGNo
YW5nZXMsIGFuZCBzdWJzY3JpYmVkIGNvbnRlbnQgbmVlZGluZyBhc3luY2hyb25vdXMgZGVsaXZl
cnkuDQo+ID4NCj4gPg0KPiA+IEZyb20gLXY2DQo+ID4NCj4gPiAgICBUaGlzIGRvY3VtZW50IHBy
b3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5nIGZvcg0KPiA+ICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRj
b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10uICBJbmNsdWRlZCBhcmU6DQo+ID4NCj4gPiAg
ICBvICBUcmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFu
Z2UNCj4gPiAgICAgICBub3RpZmljYXRpb25zLCBhbmQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzDQo+
ID4NCj4gPiAgICBvICBGdW5jdGlvbmFsaXR5IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdpdGgg
TkVUQ09ORg0KPiA+DQo+ID4gICAgbyAgRXhhbXBsZXMgaW4gYXBwZW5kaWNlcw0KPiA+DQo+ID4N
Cj4gPiBGcm9tIC12Nw0KPiA+DQo+ID4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIE5FVENP
TkYgYmluZGluZyBmb3INCj4gPiAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnNdIGFuZA0KPiA+ICAgIFtJLUQuaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0u
ICBJbmNsdWRlZCBhcmU6DQo+ID4NCj4gPiAgICBvICB0cmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1
YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFuZ2UNCj4gPiAgICAgICBub3RpZmljYXRpb25zLCBh
bmQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzLA0KPiA+ICAgIG8gIGZ1bmN0aW9uYWwgcmVxdWlyZW1l
bnRzLCBhbmQNCj4gPiAgICBvICBleGFtcGxlcw0KPiA+DQo+ID4NCj4gPiBGcm9tIC12OA0KPiA+
DQo+ID4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIE5FVENPTkYgYmluZGluZyB0byBzdWJz
Y3JpYmVkDQo+IG5vdGlmaWNhdGlvbnMNCj4gPiAgICBhbmQgdG8gWUFORyBwdXNoLg0KPiA+DQo+
ID4NCj4gPiBIb25lc3RseSBJIGxpa2UgdGhlIHY1IHZlcnNpb24uICAgQnV0IHByZXZpb3VzIHJl
dmlld2VycyBoYXZlDQo+IGluY3JlbWVudGFsbHkgZHJpdmVuIHRoaW5ncyB0byB0aGUgY3VycmVu
dCB0ZXh0LiAgICBJZiBLZW50IHlvdSBwcmVmZXINCj4gc29tZXRoaW5nIG90aGVyIHRoYW4gdGhl
IGN1cnJlbnQgdGV4dCwgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy4gIEkgYW0gc3VyZSBJIHdpbGwN
Cj4gbGlrZSBpdCB0b28uDQo+ID4NCj4gPiBFcmljDQo+ID4NCj4gPg0KPiA+ID4gVGhhbmtzIQ0K
PiA+ID4gRGhydXYNCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBJbiB0aGUgYWJzdHJhY3Qgb2YgdGhp
cyBkb2N1bWVudCwgdGhhdCBkcmFmdCBpcyBub3QgZXhwbGljaXRseQ0KPiBsaXN0ZWQNCj4gPiA+
ID4gYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rvb2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1
c2UNCj4gcmVmZXJlbmNlcyBpbg0KPiA+ID4gPiBhYnN0cmFjdHMpLiAgQnV0IGl0IGlzIGxpc3Rl
ZCBpbiB0aGUgSW50cm9kdWN0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBUbyBtYWtlIHRoaXMgY2xl
YXJlciBmb3IgeW91IGluIHRoaXMgZG9jdW1lbnQsIHBlcmhhcHMgInRyYW5zcG9ydA0KPiBiaW5k
aW5nIg0KPiA+ID4gPiBpbnN0ZWFkIG9mICJiaW5kaW5nIj8gICBJIHJlYWxseSBkb24ndCBoYXZl
IG1hbnkgYWx0ZXJuYXRpdmVzIEkNCj4gY2FuIHRoaW5rDQo+ID4gPiA+IG9mIHdoaWNoIGFsc28g
a2VlcHMgdGhlIHRleHQgYnJpZWYuICAgVGhpcyBwYXJ0aWN1bGFyIHRleHQgaGFzDQo+IGJlZW4N
Cj4gPiA+ID4gZnJlcXVlbnRseSB0d2Vha2VkIGluIHRoZSBwYXN0Lg0KPiA+ID4gPg0KPiA+ID4g
PiBUaGFua3MuDQo+ID4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBUaGFu
a3MhDQo+ID4gPiA+ID4gRGhydXY+DQo+ID4gPiA+ID4gT24gV2VkLCBNYXkgOCwgMjAxOSBhdCA5
OjE0IFBNIEVyaWMgVm9pdCAoZXZvaXQpDQo+IDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBXaXRoIHRoZSBj
b3JyZXNwb25kaW5nIGNoYW5nZSB0bw0KPiBkcmFmdC1pZXRmLQ0KPiA+ID4gPiBuZXRjb25mLQ0K
PiA+ID4gPiA+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBwb3N0ZWQgYXMgLXYyNS4NCj4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBGcm9t
OiBEaHJ1diBEaG9keSwgTWF5IDgsIDIwMTkgMjoyMSBBTQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gPiBIaSBLZW50LCBFcmljLA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBGaW5l
IHdpdGggbWUhDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoYW5rcyENCj4gPiA+ID4g
PiA+ID4gRGhydXYNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gT24gV2VkLCBNYXkgOCwg
MjAxOSBhdCAzOjE5IEFNIEtlbnQgV2F0c2VuDQo+ID4gPiA+ID4gPiA+IDxrZW50K2lldGZAd2F0
c2VuLm5ldD4NCj4gPiA+ID4gPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA8ZXJpYz4gQmFzZWQgb24gbXkg
cmVhZGluZyBvZiB5b3VyIHByb2Nlc3Mgc3VnZ2VzdGlvbnMNCj4gS2VudCwgSQ0KPiA+ID4gPiA+
ID4gPiA+IGxpa2UgYmVzdCB0aGUNCj4gPiA+ID4gPiA+ID4g4oCcbWVudGlvbuKAnSBhcHByb2Fj
aCB3aGljaCB5b3UgdXNlZCBmb3IgUkZDLTgwNzEsIFNlY3Rpb24gMS40Lg0KPiA+ID4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiA+ID4gV2hhdCBJIHRoaW5rIGNvdWxkIGJlIGRvbmUgdG8gY292ZXIg
dGhpcyBpczoNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IChBKSAgUmVtb3ZlIFNl
Y3Rpb24gMTE6IE5vdGVzIHRvIHRoZSBSRkMgRWRpdG9yDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+
ID4gPiA+ID4gPiAoQikgIFBlciBLZW504oCZcyBkZXNpcmUgdG8gYWxzbyBjb3Zlcg0KPiA+ID4g
PiA+ID4gPiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiwgcGxhY2UgdGhlDQo+
ID4gPiA+ID4gPiA+IGZvbGxvd2luZyBzdGF0ZW1lbnQgaW50bw0KPiA+ID4gPiA+ID4gPiBkcmFm
dC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4gPiA+ID4gPiA+IGRp
cmVjdGx5IGFmdGVyIEZpZ3VyZSAxMA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
W1JGQy01Mjc3XSBTZWN0aW9uIDIuMi4xIHN0YXRlcyB0aGF0IGEgbm90aWZpY2F0aW9uDQo+IG1l
c3NhZ2UgaXMNCj4gPiA+ID4gPiA+ID4gPiB0byBiZSBzZW50IHRvIGENCj4gPiA+ID4gPiA+ID4g
c3Vic2NyaWJlciB3aGljaCBpbml0aWF0ZWQgYSAiY3JlYXRlLXN1YnNjcmlwdGlvbiIuICAgV2l0
aA0KPiB0aGlzDQo+ID4gPiA+IHNwZWNpZmljYXRpb24sDQo+ID4gPiA+ID4gdGhpcw0KPiA+ID4g
PiA+ID4gPiBSRkMtNTI3NyBzdGF0ZW1lbnQgc2hvdWxkIGJlIG1vcmUgYnJvYWRseSBpbnRlcnBy
ZXRlZCB0bw0KPiBtZWFuDQo+ID4gPiA+ID4gPiA+IHRoYXQgbm90aWZpY2F0aW9uIG1lc3NhZ2Vz
IGNhbiBhbHNvIGJlIHNlbnQgdG8gYSBzdWJzY3JpYmVyDQo+ID4gPiA+ID4gPiA+IHdoaWNoIGlu
aXRpYXRlZCBhbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIsIG9yIGEgY29uZmlndXJlZA0KPiA+
ID4gPiA+ID4gPiByZWNlaXZlciB3aGljaCBoYXMgYmVlbiBzZW50IGEg4oCcc3Vic2NyaXB0aW9u
LXN0YXJ0ZWTigJ0uDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBEb2VzIHRoaXMg
d29yayBmb3IgYm90aCBvZiB5b3U/DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0K
PiA+ID4gPiA+ID4gPiA+IFdvcmtzIGZvciBtZS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBUaGUgaXNzdWUgaXNuJ3Qg
Y29uc2lzdGVuY3kgc28gbXVjaCBhcyBtZWV0aW5nDQo+IGV4cGVjdGF0aW9ucywNCj4gPiA+ID4g
PiA+ID4gPiBwZXIgYHhtbDJyZmNgLCB0aGUNCj4gPiA+ID4gPiA+ID4gZG9jdW1lbnQgc2hvdWxk
IGhhdmUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyBpbiB0aGUNCj4gPiA+ID4gPiA+ID4g
UmVmZXJlbmNlcyBzZWN0aW9uLCB3aGljaCB0aGVuIGF1dG8tZXhwYW5kcyB0byB0aGUgY29ycmVj
dA0KPiA+ID4gPiA+ID4gPiByZWZlcmVuY2UgdGV4dCwgYXMgd2VsbCBhcyBkZWZpbmluZyB0aGUg
YW5jaG9yDQo+ID4gPiA+ID4gPiA+ICJJLUQuaWV0Zi1uZXRjb25mLQ0KPiA+ID4gPiBzdWJzY3Jp
YmVkLW5vdGlmaWNhdGlvbnMiOg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gICAg
ICAgICA8P3JmYw0KPiA+ID4gPiA+ID4gPiA+DQo+IGluY2x1ZGU9InJlZmVyZW5jZS5JLUQuaWV0
Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyI/DQo+ID4gPiA+ID4gPiA+ID4gPg0K
PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPEVyaWM+IFRoYXQgZGVmaW5pdGVseSBt
YWtlcyB0aGluZ3MgZWFzaWVyIHRoYW4gd2hhdCBJDQo+IGhhdmUNCj4gPiA+ID4gPiA+ID4gPiBi
ZWVuIGRvaW5nLiAgSSBhbQ0KPiA+ID4gPiA+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMgZXJyb3Ig
dHJ5aW5nIHRoaXMgcmlnaHQgbm93LCBidXQgSSB3aWxsDQo+IGdldCB0aGVyZS4NCj4gPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gWWVzLCBpdCB3YXMgYW4g
ZXllLW9wZW5lciB3aGVuIEkgZmlndXJlZCBpdCBvdXQuICAgQmUNCj4gYXdhcmUgdGhhdCwNCj4g
PiA+ID4gdGhvdWdoDQo+ID4gPiA+ID4gc29tZQ0KPiA+ID4gPiA+ID4gPiBleHRlcm5hbCBzb3Vy
Y2VzIChlLmcuLCBJVFUgc3RhbmRhcmRzKSBhcmUgc3VwcG9ydGVkLCBtYW55DQo+IGFyZQ0KPiA+
ID4gPiA+ID4gPiBub3QsIGFuZCBzbyBoYW5kLSBjb2RpbmcgdGhlIDxyZWZlcmVuY2U+IGlzIHN0
aWxsIHNvbWV0aW1lcw0KPiA+ID4gPiByZXF1aXJlZC4uLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g
PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBLZW50IC8vIHNoZXBoZXJkDQo+ID4gPiA+ID4g
PiA+ID4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4NCg0K


From nobody Tue May 14 11:45:24 2019
Return-Path: <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D09120267 for ; Tue, 14 May 2019 11:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hRxHtGFzRCw4 for ; Tue, 14 May 2019 11:45:13 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E02C120283 for ; Tue, 14 May 2019 11:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557859512; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=VncKDD/CdD4+ElvribSERuAjzufSLfv8F4q9ks/6I0U=; b=LSSNj3QVgAGYg/svMkVDSA1WBma+ekgUeFhjGnxpvbxnSObVrbTDiY4mTpkMzvlj kXtqmsloQwwNzRzBG6Q2IsBDuC9WnpceHIppIuh4z99etf6f8HQ34jEnYdZFNYeC/o5 TwYSEJ2wlykzM1xpLTlfSlpK+LCNSlWUR5sEoyJ4=
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: 
Date: Tue, 14 May 2019 18:45:12 +0000
Cc: Andy Bierman , "netconf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>  
To: Jonathan Hansford 
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.14-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 18:45:18 -0000

> So I need to contact the RFC Editor to correct Erratum 5397, with the =
relevant text in sections 7.8 and 7.9 being changed to something like:
>=20
> 7.8: "If a NETCONF server receives a  request while =
processing a confirmed commit (Section 8.4) for that session, unless the =
confirmed commit is a persistent confirmed commit, it MUST restore the =
configuration to its state before the confirmed commit was issued. A =
persistent confirmed commit MUST survive session termination."
>=20
> 7.9: "If a NETCONF server receives a  request while =
processing a confirmed commit (Section 8.4) for the session to be =
killed, unless the confirmed commit is a persistent confirmed commit, it =
MUST restore the configuration to its state before the confirmed commit =
was issued. A persistent confirmed commit MUST survive session =
termination."

Ideally, Errata 5397 is deleted (because I think that it's clear that =
Section 8.4 overrides the 7.8 behavior) but, if we have to patch the =
errata, I might suggests:

For Section 7.8
  OLD (in RFC 6241)

    The server will release any locks
    and resources associated with the session and gracefully close any
    associated connections.

  NEW:

    The server will release any locks
    and resources, associated with the session and gracefully close any
    associated connections.  As an exception to the previous sentence, =
if
    the session is processing a persistent confirmed commit (Section =
8.4),
    the resources necessary for supporting confirmed commit are not =
released.

For Section 7.9:
  OLD (in RFC 6241)

      If a NETCONF server receives a  request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

  NEW:
      What you have above seems fine, though I'd leave off the last =
sentence.


> I also need to contact the RFC Editor to correct Erratum 3821 to =
change:
>=20
> If the session issuing a sequence of one or more confirmed commits is
> terminated for any reason before the confirm timeout expires, the =
server
> MUST restore the configuration to its state before the sequence of
> confirmed commits was issued, unless the last confirmed commit also
> included a  element.
>=20
> If the device reboots for any reason before the confirm timeout
> expires, the server MUST restore the configuration to its state
> before the sequence of confirmed commits was issued.
>=20
> to something like:
>=20
> If the session issuing a sequence of one or more confirmed commits is
> terminated for any reason before the confirm timeout expires, the =
server
> MUST restore the configuration to its state before the sequence of
> confirmed commits was issued, unless the confirmed commit is a
> persistent confirmed commit.
>=20
> If the device reboots for any reason before the confirm timeout
> expires, unless a persistent confirmed commit is in progress, the=20
> server MUST restore the configuration to its state before the
> sequence of confirmed commits was issued.
>=20
>  A persistent confirmed commit MUST survive session termination.
>=20

This seems okay but, again, I'd leave out the last sentence.


Side note: huge errata are hard to read without a diff.  If a lot of =
text, then the NEW (or the NOTES) should include a diff highlighting =
exactly what changed.

Kent // contributor



> Are those errata OK?=20
>=20


From nobody Tue May 14 13:44:24 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C512010C; Tue, 14 May 2019 13:44:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper 
Message-ID: <155786665488.30110.1029818535148238046.idtracker@ietfa.amsl.com>
Date: Tue, 14 May 2019 13:44:14 -0700
Archived-At: 
Subject: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 20:44:15 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 9 =

        "Access control must be set so that only someone
      with proper access permissions, and perhaps even HTTP session has
      the ability to access this resource."

There is a grammar error in this sentence -- "perhaps even HTTP session"
doesn't follow from the antecedent.



From nobody Tue May 14 13:44:58 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92A712010C; Tue, 14 May 2019 13:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=ktG36Zgx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EO0bR6nS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HNUXgttb374; Tue, 14 May 2019 13:44:46 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7819812011A; Tue, 14 May 2019 13:44:46 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B089D23F9B; Tue, 14 May 2019 16:44:45 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 14 May 2019 16:44:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=0 36YQ6hBHzqoQyASxfHS/XHkIuOBwYPaUnji782HRp4=; b=ktG36Zgxhe1p7KPb5 /THTQh9TdzpNIglG1HJyBFxUnsbrhqLZr+djcewBRGGWcuIkSDiMLLX5x2OoPOYa 0fH1bghDSDtnAcrFQaQQN5SkeUYmwtkYSWaHT2W8O/VLfeOm4DVlWbZOz1QMcvcr bYCqhZARQqfGQTFRqc+l13eG/oUdZeV8KWkdqEKSW9ANS/CvGH3FgP2dbngvADOX FoiZ47mnUyJHM7YZ1nYvDW1jg9CR7y7aNZioRas0qe7/tb+PL/H+qnn9Jk3CU3Pf bvBiGX26fRDDRSryRTN57GHxr5nSDmLwH9oBTvAzJN04/Su+7/W/PKK56Ft9NUjx ESGlg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=036YQ6hBHzqoQyASxfHS/XHkIuOBwYPaUnji782HR p4=; b=EO0bR6nSLobTw12DMbZwJQHroBPLq8phkkyfzpVXl5zoaMqOR1mh52zXD H4wCDQYMxFsQXBHdpsvN3hjTs5eHzbI5C8wIubE3sEBTa8v3MkBNLXOpRFH7vt2Z 7U6P/xz+HiPAITbJqiQhwQxdm9WnPUD9Xy/Q+A6Jd0SWk4XhjorqhEnkR8JThP6b AezvntqZrQHrDmfJnKR1kYMzo9mfP4FVSd329wztUAV1+b4uCzDZyRXtp2KO6jIB OO6G7jwaQ6ocuQz/upAIvb3dB3emEhhawpA4StmISYAx5fcTMsnQ8w+4frlHpgRf SAB/6NxbJ03rdjlsrrXfd/lOlkCzQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleeigdduheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeejnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy:    
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id A742980061; Tue, 14 May 2019 16:44:44 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper 
In-Reply-To: <08861E62-97B9-499F-9B69-6E685FA6258A@cisco.com>
Date: Tue, 14 May 2019 16:44:42 -0400
Cc: "gen-art@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" ,  "netconf@ietf.org" , "ietf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C276F8D-2523-42D8-8B47-01D6AEBBD44B@cooperw.in>
References: <155491304260.9197.1007765785277967184@ietfa.amsl.com> <08861E62-97B9-499F-9B69-6E685FA6258A@cisco.com>
To: "Reshad Rahman (rrahman)" , Robert Sparks 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netconf] [Gen-art] Genart last call review of draft-ietf-netconf-restconf-notif-13
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 May 2019 20:44:49 -0000

Robert, thanks for your review. Reshad, thanks for your response. I =
entered a No Objection ballot.

Alissa


> On Apr 12, 2019, at 5:12 PM, Reshad Rahman (rrahman) =
 wrote:
>=20
> Hi Robert,
>=20
> Thank you for the review, please see inline.
>=20
> =EF=BB=BFOn 2019-04-10, 12:17 PM, "Robert Sparks via Datatracker" =
 wrote:
>=20
>    Reviewer: Robert Sparks
>    Review result: Ready
>=20
>    I am the assigned Gen-ART reviewer for this draft. The General Area
>    Review Team (Gen-ART) reviews all IETF documents being processed
>    by the IESG for the IETF Chair.  Please treat these comments just
>    like any other last call comments.
>=20
>    For more information, please see the FAQ at
>=20
>    .
>=20
>    Document: draft-ietf-netconf-restconf-notif-13
>    Reviewer: Robert Sparks
>    Review Date: 2019-04-10
>    IETF LC End Date: 2019-04-12
>    IESG Telechat date: Not scheduled for a telechat
>=20
>    Summary: Ready for publication as a proposed standard
>=20
>    Nits/editorial comments:
>=20
>    The abstract is quite terse. Please consider expanding it to =
something that
>    stands better by itself.
> TBH I'm not sure what else to add. I'll discuss with the other =
authors.=20
>=20
>    The sentence that starts "Driving these requirements" in the =
introduction does
>    not follow where it sits in the paragraph. There is no antecedent =
for "these
>    requirements". I suggest replacing the sentence with "Requirements =
for these
>    mechanisms are captured in [RFC7923].
> Makes sense, I'll make the change.
>=20
>    The second sentence in the first paragraph of section 3 is a =
run-on. I suggest
>    s/2.4, the/2.4. The/
> Sure.
>=20
> Regards,
> Reshad.   =20
>=20
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Tue May 14 19:54:05 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55383120127; Tue, 14 May 2019 19:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pMNTKxRAS5nR; Tue, 14 May 2019 19:54:01 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 1400A12003E; Tue, 14 May 2019 19:54:00 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([71.178.248.224]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MDyDQ-1habQH2nh6-009w5p;  Wed, 15 May 2019 04:53:57 +0200
From: "Alexander Clemm" 
To: "'Benjamin Kaduk'" , "'The IESG'" 
Cc: , , 
References: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com>
In-Reply-To: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com>
Date: Tue, 14 May 2019 19:53:52 -0700
Message-ID: <043c01d50ac9$7099a780$51ccf680$@clemm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ3PF2dFB47j2Iq/ZH31Feu7eo0t6UmyTCA
Content-Language: en-us
X-Provags-ID: V03:K1:FYiw6WV1bArY7fqK39sG7fv6BJUBJp5u7bYJDEq4GA8qO+HDQ4c jniVlTAogG/FjLfnzw4koqwM6e51rq07qvhT699GdfgYh6wUzMQ1/+HR+ImtWRWWTvLG6q1 q5HdOaZIc8pwmNwNTtaHKpfh69iCW9CXi+awKQ+0wd20BchMUlbvojzQ9b6xXRRX8Njt9eL P5HgyflXh8jpId901pAjQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:DWii6VaFEME=:iIVgLtTfeuVqRQukdst+mL RcJdFUK2DGdWZiXkSAb8Nlnz6QavwARYlToA74Fd/p/tOVqphyGJpWBT5nI1PWFL2yI/7MyIr 61gw4oONlp/xcasYzeTcxjq+/2XvvHS0aBG4hcWboFXCCP/6y09fwqNvsJwm19lnbUupw/0V8 9MoC8pnmztbs3ZSvj8WivnxZnkdihC3sbYdh7nPZnXyJ0bYBK7aBtzDHDMtbmTPq+DtAEve3a TvUBIDbFz0AKfFEttS6OzcJGuMdDFD6lfu4FBgGuApFP3J9OuyF9x0F9ZlG3s2F2BC6w0PLhj KbtErAsSLT9oMBgUsmqFdx14nooKP287wxmtZXc/hz6/LF/cJwPuoq0WMTqAyYe9d1CvWysRz aTf9bGkw/CAZ/rszkKIhHdd8JEfGx/QkdnZiFPQmX/luSgVhLbmM6lg76A7N4cQ39j+fxeHbM crHkirSUSfJ/AINq5VeLtiZIbx4bh3STekiLoZVjuk3ByCe1ZKBREqTJtc6ojdhMfG6G9XFVR Bz3i+Sg+ncNasE4jjeiM82oh79sOqezoRiZxLPHGkmwsrStzgNOJbZAdmpIBiegC1SXuQzTtt r06DYjxiKAkPlAvsJDxBQCAZRd17oGpoAmtqKwEWYmsTly8RKirDAYKJMYGBr7T0hP2NvhKE6 7Khre+2KvnbaA6NqnD5Dxwb+ZpETKTPjERQgjLJ12KDxb7IcjEipMRuoUFxrFmIpTkWnUalhf OOd3OPi8F6Jv0B8eb1KxRY8R3Wa8LB8v1srSS7vq3uP3hYe2k0JEQSH0Zy8=
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 02:54:04 -0000

Hi Benjamin,

Thank you for your review!  Replies inline, .  Update will be
reflected in -24, to be posted shortly.  

--- Alex

-----Original Message-----
From: netconf  On Behalf Of Benjamin Kaduk via
Datatracker
Sent: Wednesday, May 1, 2019 12:08 PM
To: The IESG 
Cc: netconf@ietf.org; draft-ietf-netconf-yang-push@ietf.org;
netconf-chairs@ietf.org
Subject: [netconf] Benjamin Kaduk's Discuss on
draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-yang-push-23: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Note that I reviewed the -22 and the current version is -23.  Briefly
skimming the diff, it seems that some changes touch on points I make in my
review, but there is probably still discussion to have on them.

(pro-forma) I see the GenArt reviewer noted the author count (seven)
already, but I couldn't find a response or note in the ballot or shephert
writeup acknowledging this.  So failing that, I'll put up a discuss point
until the responsible AD says it's fine.

[See also discussion on draft-ietf-netconf-subscribed notifications about
the pre-RFC5378 boilerplate and whether or not it can be removed from this
document]

 Several of the authors have graciously agreed to step down and be
listed as contributors. 

Section 3.3 states:

            In order for a subscriber to determine whether objects
   support on-change subscriptions, objects are marked accordingly on a
   publisher.  Accordingly, when subscribing, it is the responsibility
   of the subscriber to ensure it is aware of which objects support on-
   change and which do not.  For more on how objects are so marked, see
   Section 3.10.

Chasing the reference, we see that this marking is left for future work or
implementation-specific usage.  I'm not very comfortable with the way we are
describing this situation, as it seems pretty fragile in the face of
different implementations trying to interoperate.

 The working group decided to pull this item out of this draft.  It is
being addressed in draft-ietf-netconf-notification-capabilities
(https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabiliti
es/) 

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the very thoughtful document!  I've lost track of the number
of places where I started writing a comment only to note that my concern had
already been addressed in the following text.  In general the writing style
is great, though I did find some grammar and clarity nits (noted inline).

Abstract

               Providing such visibility into updates enables new
   capabilities based on the remote mirroring and monitoring of
   configuration and operational state.

This phrasing ("new capabilities based on") is hard for me to follow,
particularly about whether these are protocol-level capabilities and what
actors are granted the new capabilities.

 The capabilities are clearly not related to protocol-level
capabilities, but capabilities for applications that have uses for
information obtained from YANG datastores.  If it's okay, at this point we
would like to keep it as-is. 

Section 1

   Traditional approaches to providing visibility into managed entities
   from remote have been built on polling.  [...]

nit: "remote" is an adjective and needs a noun to bind to; "from remote
systems", "from remote vantages", or "from afar" would all be fine wordings
here.

 changed to  "from a remote system".   

   o  Polling incurs significant latency.  This latency prohibits many
      application types.

nit: I'd suggest wording as "types of application", since on my first
reading I thought this was referring to some sort of codepoint.

 changed 

   o  Polling cycles may be missed, requests may be delayed or get lost,
      often when the network is under stress and the need for the data
      is the greatest.

nit: the grammar is a bit weird, here, as if a comma splice.  I think
replacing the first comma with a colon or em dash would suffice.

 replaced first comma with "and", to read: "Polling cycles may be
missed and requests may be delayed or get lost, often when the network is
under stress and the need for the data is the greatest." 

   o  Datastore node update: A data item containing the current value of
      a datastore node at the time the datastore node update was
      created, as well as the path to the datastore node.

Is this storing the "new" or the "old" value as the "current value"?

 I don't understand the question.  I think the statement is
clear.

Section 3.1

         +  Dampening period: In an on-change subscription, detected
            [...]
            is included.  The dampening period goes into effect every
            time an update record completes assembly.

Just to double-check: this means that after a long hiatus, the first change
to the monitored subtree(s) triggers an immediate push with just the single
update, and only then does the dampening period kick in and defer delivery
of potential subsequent updates?

 Yes, this is correct 

Section 3.5.2

This bit about the "create" and "delete" errors from RFC 8072 Section
2.5 not being errors in our usage is a little interesting, process-wise.
In one sense, we are changing the semantics of an already published RFC, and
would need to apply an "Updates:" relationship to indicate that, but in the
other sense we are building a new custom thing that reuses a lot of the
syntax/semantics of YANG patch but is fundamentally a new
(different) thing.  The phrasing we use to talk about it can affect which
case the reader perceives us to be in...

The discussion on the "change-type" enumeration seems to pretty clearly
place us in the latter case, which is good.

 Keeping this as is. 

Section 3.6

Thank you for the note about the power of XPath expressions and the duty of
the receiver to understand what it's asking for -- that sort of statement
would potentially even be appropriate in the Security Considerations (but is
fine where it is)!

 Keeping this as is.  

Section 3.7

   Of note in the above example is the 'patch-id' with a value of '0'.
   Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG
   Push, the publisher SHOULD put into the 'patch-id' a counter starting
   at '0' which increments with every 'push-change-update' generated for
   a subscription.  If used as a counter, this counter MUST be reset to
   '0' anytime a resynchronization occurs (i.e., with the sending of a
   'push-update').  Also if used as a counter, the counter MUST be reset
   to '0' after passing a maximum value of '4294967295' (i.e. maximum
   value that can be represented using uint32 data type).  Such a
   mechanism allows easy identification of lost or out-of-sequence
   update records.

It's not really clear to me how much value there is in this counter
mechanism if the client' can't rely on the server's behavior actually being
to use a counter (the requirement is only "SHOULD").  Can this be a "MUST"
(or maybe "MUST excpet when [...]") instead?

 Would prefer to not introduce no MUST requirements at this point and
keep this as a SHOULD.  

Section 3.9

                                                          Empty "push-
   change-update" messages (in case of an on-change subscription) MUST
   NOT be sent.  This is required to ensure that clients cannot
   surreptitiously monitor objects that they do not have access to via
   carefully crafted selection filters.  By the same token, changes to
   objects that are filtered MUST NOT affect any dampening intervals.

I appreciate this attention to security-relevant detail; thank you!

 thanks! 

Section 3.11.1

Do we want to give any guidance for the "incomplete-update" case about
whether a subscriber should wait and give the publisher a chance to provide
a full "push-update" for resynchronization (per Section 4.3.2) versus
perform a normal query for the datastore contents and effectuating its own
resynchronization?

 This should be up to the subscriber to decide, and what to do may
differ for different applications.  In some instances, it can afford to
simply wait; in other cases or when specifically interested in one
particular closely-monitored item it may decide not to and sync immediately.

Section 4

   o  For on-change subscriptions, assuming any dampening period has
      completed, triggering occurs whenever a change in the subscribed
      information is detected.  On-change subscriptions have more
      complex semantics that is guided by its own set of parameters:

nit: singular/plural mismatch "semantics"/"is"

 changed to "On-change subscriptions have more complex semantics that
are guided by their own set of parameters" 

Section 4.3.2


   A "time-of-update" which represents the time an update record
   snapshot was generated.  A receiver MAY assume that at this point in
   time a publisher's objects have the values that were pushed.

nit: I think "had the values" (past tense) is more appropriate.

 changed 

Section 4.4.1

   a publisher that cannot serve on-change updates but periodic updates
   might return the following NETCONF response:

nit: "but can serve periodic updates"

 changed 

Section 4.4.2

   The specific parameters to be returned in as part of the RPC error
   response depend on the specific transport that is used to manage the
   subscription.  For NETCONF, those parameters are specified in
   [I-D.draft-ietf-netconf-netconf-event-notifications].

nit: "in" and "as part of" are redundant.

 removed "in" 

Section 5

It is slightly interesting to note that (apparently) the
update-policy-modifiable grouping allows for a subscription to switch
between periodic and triggered at runtime (by virtue of wanting a single
grouping to cover all the cases and needing to be able to modify the
parameters for each case).  I would mostly expect implementations to deny
such modification requests due to the needed complexity, but I'm also not
sure that there's a need to mention this explicitly in the document.

  I think it is implied that a modification request can always be
denied if not supported by a server.  At the same time, clearly in general
you would not change between on-change and periodic.  Keeping as is. 

            leaf period {
              type centiseconds;
              mandatory true;
              description
                "Duration of time which should occur between periodic
                 push updates, in one hundredths of a second.";

It would probably be okay to skip "in one hundredths of a second" given the
usage of the centiseconds typedef.

 doesn't hurt to be explicit; keeping as is 

    rc:yang-data resync-subscription-error {
      container resync-subscription-error {
        description
          "If a 'resync-subscription' RPC fails, the subscription is
           not resynced and the RPC error response MUST indicate the
           reason for this failure.  This yang-data MAY be inserted as
           structured data within a subscription's RPC error response
           to indicate the failure reason.";

It's a little weird to have the normative language here constraining the RPC
error response that must be returned for a specific RPC, since this is not
the description of that RPC.  (It's probably also duplicating langauge
elsewhere but I didn't double-check.)

 Keeping as is since it is clear what is happening.  Note that there
are limitations to the RPC semantics you can formally define in YANG, hence
the description. 

    rc:yang-data establish-subscription-datastore-error-info {
      container establish-subscription-datastore-error-info {
        description
          "If any 'establish-subscription' RPC parameters are
           unsupportable against the datastore, a subscription is not
           created and the RPC error response MUST indicate the reason
           why the subscription failed to be created.  This yang-data
           MAY be inserted as structured data within a subscription's
           RPC error response to indicate the failure reason.  This
           yang-data MUST be inserted if hints are to be provided back
           to the subscriber.";

(ditto)

Contrast to modify-subscription-datastore-error-info, which only has
normative language about the yang-data being described and not the RPCs that
(might) use it.

 Would keep as is.  I think the semantics are clear.  

nit: push-update and push-change-update use different langauge about "does
not constitute a general-purpose notification" and I'm not sure there's a
reason to diverge.
Their "incomplete-update" leaves also have divergent descriptions, but I
think that latter divergence is more reasonable.

 Updated the description of push-change-update to align this part of
the description of the notifications.  
 
    augment "/sn:subscription-modified/sn:target" {
      [...]
      case datastore {
        uses datastore-criteria {
          refine "selection-filter/within-subscription" {
            description
              "Specifies where the selection filter, and where it came
               from within the subscription and then populated within
               this notification.  If the 'selection-filter-ref' is

nit: "where the selection filter" seems like an incomplete clause.

 Updating this to  "Specifies the selection filter and where it
originated  from.  If the 'selection-filter-ref' is ...".  This way, the
description also aligns better with the augment to
sn:subscription-started/sn:target. 
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


From nobody Tue May 14 19:54:18 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1189120127; Tue, 14 May 2019 19:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MuLi6bg37uJ; Tue, 14 May 2019 19:54:03 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 F28CB1201D0; Tue, 14 May 2019 19:54:02 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([71.178.248.224]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M6DvY-1hK7Hq1pUG-006dFd;  Wed, 15 May 2019 04:53:58 +0200
From: "Alexander Clemm" 
To: "'Daniele Ceccarelli'" , 
Cc: , , 
References: 
In-Reply-To: 
Date: Tue, 14 May 2019 19:53:52 -0700
Message-ID: <043d01d50ac9$710eb070$532c1150$@clemm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_043E_01D50A8E.C4B27080"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIX4Hao3662Ojb5sUX1GhdIgG7VPqXlc/bA
Content-Language: en-us
X-Provags-ID: V03:K1:RHK5NVZ8+kA2vDXXzHhtRAoUUfKtHGu1xX+Sxbc0I68VMqkLBpD 0u9VFOD7deGgccsnwBH2BWyqlDRVnO6SiKxyOqy0PO6BdvKr6bNqzVfrChOicFjgEi0nwxg MUTAfcZ2negrOEHzEGATpdq58DIjCi9KwyBOIvAw7xevTwUFWjYq7wwsVoS72F8lx4OUeip SyHUsyOQYVOBtK5PW/3LA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Dz8gmBzMHj8=:fYALs2uD1Otzh/Gkkdppf8 0zApgCOi7M1qJm6GtgIhULanfSisk2am+4b5aP5NHzP2G5JTdV4A5pIxgdGsvUz3c0loIm4pC EBjKbK8Zg7gluID7retTuPUjEC2tWF1G4ctpIJTRStQ/XuzX1VFQqOXrp27P7Hw6lpk0FhQM6 1NJI1a6tnzRLRAkeGHWGPsUAh2BdEa6z/3Oy5UbnqFURNdVUX4PJC4YMEWcexTBtdmddhFNDh 2wyqF8aikkG6VKl7lOX0zfbHySVGNGhTSpm5eU61rCASSEjqc6JMsUDyaja9AjmJra09jWVYF gOpDzlwJs1qZGXcns/Z/d4/yuN446HHQvn7FWXu91JflFxh5h9+zY+VRpxZovtz8+YjLlI9ub zsf7sUv3yz/H0UDLzbzPx8hEwcPdI/RcJW4Y1E3yzVkzU4qddl5N/guVGW/vNSvm6J08dM+pO ks6p7ZF6RqvSasTsE756i8kv7XiZlwAUKDbBU4aJSxPgSvZFEycJJods9tJSQwQGeQhjX7+zN P1PUV8eEkOgiZ1RNwCfRelUHaCbhfFL9YFH0uO5pqY5hWihKPgcim1eYYgUz+B48iWTRQ6xPR ULIbZMLMukMTlWEWjXlQLR1CmHQ5Tp6I+va8bMBBbDMo+nlShj9c30ACfh8PvgPXoTPdSAMCG 7lMPTwrZP6GQaBmGPTFUvVy+OYiCjQt76EGksCW9l7ebhE7dH/V2xB5X4Fvn3XAY3oEAuTVVb RxMWc3yVyfwRYJXG9E+Vm0WVQI1Z/oNqG3ui2zBbPcymogPCL2mPvgXJcro=
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 02:54:06 -0000

This is a multipart message in MIME format.

------=_NextPart_000_043E_01D50A8E.C4B27080
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello Daniele,

=20

Thank you for your review!  Responses inline, .  Updates will be =
reflected in -24, to be published shortly. =20

=20

Kind regards

--- Alex

=20

From: netconf  On Behalf Of Daniele Ceccarelli
Sent: Tuesday, April 30, 2019 12:24 PM
To:  (rtg-ads@ietf.org) 
Cc: rtg-dir@ietf.org; draft-ietf-netconf-yang-push.all@ietf.org; =
netconf@ietf.org
Subject: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22

=20

Hello,

I have been selected as the Routing Directorate reviewer for this draft. =
The Routing Directorate seeks to review all routing or routing-related =
drafts as they pass through IETF last call and IESG review, and =
sometimes on special request. The purpose of the review is to provide =
assistance to the Routing ADs. For more information about the Routing =
Directorate, please see  =
 =
=E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it =
would be helpful if you could consider them along with any other IETF =
Last Call comments that you receive, and strive to resolve them through =
discussion or by updating the draft.

Document: draft-ietf-netconf-yang-push-22
Reviewer: Daniele ceccarelli=20
Review Date: 2019-04-30
IETF LC End Date:=20
Intended Status: Standards Track

Summary:=20

*	This document is basically ready for publication, but has nits that =
should be considered prior to publication.

Comments:

*	The draft is well structured and covers a lot of different aspects of =
the proposed method. I only have some concerns on readability and =
quality of English. A review from a mother tongue would improve it =
significantly. (maybe the RFC editor should be enough).

Major Issues:

*	No major issues found

Minor Issues:

*	Number of authors on the front page: shouldn=E2=80=99t it be 5 max?

 Several of the authors have graciously agreed to step down and be =
listed as contributors. 

*	Section 3: =E2=80=9CThis solution supports dynamic as well as =
configured subscriptions to updates of datastore node=E2=80=9D. What =
does dynamic and configured mean? It=E2=80=99s probably defined in other =
documents?=20

 Yes, these are defined in the Subscribed Notifications draft =
which YANG-Push builds on, as explained in the Introduction.  

*	Section 3.2. =E2=80=9CHowever, there are no guarantees that subsequent =
requests which consider these hints will be accepted.=E2=80=9D What =
happens then? Undefined number of retries?

 It is up to the client application.  When making a subsequent =
request, it should presumably =E2=80=9Clower=E2=80=9D its demands.  The =
idea of the hint is to provide an idea which request would result in a =
load that is still acceptable, a =E2=80=9Cpoor man=E2=80=99s =
negotiation=E2=80=9D if you will that will reduce the number of retries =
that might otherwise result.  

*	3.5.1.  Periodic Subscriptions:=E2=80=9DIn a periodic subscription, =
the data included as part of an update record corresponds to data that =
could have been read using a retrieval operation.=E2=80=9D. Is it not =
possible to have periodic subscriptions with just the delta between the =
previous update and the last one? Everything needs to be sent at any =
time?=20

 In that case, you would request an on-change subscription.  In =
case of a high rate of changes, the dampening period will in effect =
result in periodic updates of changes only.  =20

Nits:

*	Abstract: suggest to change =E2=80=9Ccontinuous, customized=E2=80=9D =
with =E2=80=9Ccontinuous and customized=E2=80=9D.

 see next bullet item 

*	Maybe it=E2=80=99s better to change the first sentence entirely. How =
about: =E2=80=9C  This document describes a mechanism that allows =
subscriber applications requesting a continuous and customized stream of =
updates from a YANG datastore.=E2=80=9D

 This sounds fine to me. Perhaps we have edited the sentence too =
much in the past.  I am making the change, but replacing =
=E2=80=9Crequesting=E2=80=9D with =E2=80=9Cto request=E2=80=9D, to read =
=E2=80=9CThis document describes a mechanism that allows subscriber =
applications to request a continuous and customized stream of updates =
from a YANG datastore.=E2=80=9D 

*	=E2=80=9CTraditional approaches to providing=E2=80=9D, =
shouldn=E2=80=99t this be =E2=80=9Cto provide=E2=80=9D or =E2=80=9Cof =
providing=E2=80=9D?

 OK, change made 

*	Polling incurs significant latency. This latency prohibits many =
application types. =E2=80=93 Also this sentence doesn=E2=80=99t look =
very correct. Actually the entire section can be improved from a =
language perspective. (e.g. =E2=80=9Cyet for which applications need to =
be quickly notified whenever a change does occur with minimal =
delay.=E2=80=9D)

 Prefer to keep as-is at this point.  Would leave copy edits to =
RFC-editor.  

*	[I-D.draft-ietf-netconf-subscribed-notifications] usually a more =
friendly reference is used, e.g. [SUB-NOT]

 Keeping this as-is, as this will be replaced by the corresponding =
RFC reference anyhow.  

BR

Daniele =20

=20


------=_NextPart_000_043E_01D50A8E.C4B27080
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hello Daniele,
 
Thank you =
for your review!  Responses inline, <ALEX>.  Updates =
will be reflected in -24, to be published shortly.  =

 
Kind regards
--- =
Alex
 
From: netconf =
<netconf-bounces@ietf.org> On Behalf Of Daniele =
Ceccarelli
Sent: Tuesday, April 30, 2019 12:24 =
PM
To: <rtg-ads@ietf.org> (rtg-ads@ietf.org) =
<rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org; =
draft-ietf-netconf-yang-push.all@ietf.org; =
netconf@ietf.org
Subject: [netconf] RtgDir review: =
draft-ietf-netconf-yang-push-22
 
H=
ello,
I=
 have been selected as the Routing Directorate reviewer for this draft. =
The Routing Directorate seeks to review all routing or routing-related =
drafts as they pass through IETF last call and IESG review, and =
sometimes on special request. The purpose of the review is to provide =
assistance to the Routing ADs. For more information about the Routing =
Directorate, please see <=
a href=3D"http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir">=E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg=
Dir<=
o:p>
A=
lthough these comments are primarily for the use of the Routing ADs, it =
would be helpful if you could consider them along with any other IETF =
Last Call comments that you receive, and strive to resolve them through =
discussion or by updating the draft.
D=
ocument: draft-ietf-netconf-yang-push-22
Reviewer: Daniele =
ceccarelli 
Review Date: 2019-04-30
IETF LC End Date: =

Intended Status: Standards Track
Summary: 
  • This document is basically ready for publication, but has =
nits that should be considered prior to =
publication.
Comments:
  • The draft is well structured and covers a lot of different =
aspects of the proposed method. I only have some concerns on readability =
and quality of English. A review from a mother tongue would improve it =
significantly. (maybe the RFC editor should be =
enough).
Major Issues:
  • No major issues found
Minor Issues:
  • Number of authors on the front page: shouldn=E2=80=99t it be =
5 max?
<ALEX> Several of the =
authors have graciously agreed to step down and be listed as =
contributors. </ALEX>
  • Section 3: =E2=80=9CThis solution supports dynamic as well as =
configured subscriptions to updates of datastore node=E2=80=9D. What =
does dynamic and configured mean? It=E2=80=99s probably defined in other =
documents? 
<ALEX> Yes, these are =
defined in the Subscribed Notifications draft which YANG-Push builds on, =
as explained in the Introduction.  =
</ALEX>
  • Section 3.2. =E2=80=9CHowever, there are no guarantees that =
subsequent requests which consider these hints will be =
accepted.=E2=80=9D What happens then? Undefined number of =
retries?
<ALEX> It is up to =
the client application.  When making a subsequent request, it =
should presumably =E2=80=9Clower=E2=80=9D its demands.  The idea of =
the hint is to provide an idea which request would result in a load that =
is still acceptable, a =E2=80=9Cpoor man=E2=80=99s negotiation=E2=80=9D =
if you will that will reduce the number of retries that might otherwise =
result.  </ALEX>
  • 3.5.1.  Periodic Subscriptions:=E2=80=9DIn a periodic =
subscription, the data included as part of an update record corresponds =
to data that could have been read using a retrieval operation.=E2=80=9D. =
Is it not possible to have periodic subscriptions with just the delta =
between the previous update and the last one? Everything needs to be =
sent at any time? 
<ALEX> In that case, =
you would request an on-change subscription.  In case of a high =
rate of changes, the dampening period will in effect result in periodic =
updates of changes only. </ALEX>  
Nits:
  • Abstract: suggest to change =E2=80=9Ccontinuous, =
customized=E2=80=9D with =E2=80=9Ccontinuous and =
customized=E2=80=9D.
<ALEX> see next =
bullet item </ALEX>
  • Maybe it=E2=80=99s better to change the first sentence =
entirely. How about: =E2=80=9C  This document describes a mechanism =
that allows subscriber applications requesting a continuous and =
customized stream of updates from a YANG =
datastore.=E2=80=9D
<ALEX> This sounds =
fine to me. Perhaps we have edited the sentence too much in the =
past.  I am making the change, but replacing =
=E2=80=9Crequesting=E2=80=9D with =E2=80=9Cto request=E2=80=9D, to read =
=E2=80=9CThis document describes a mechanism that allows =
subscriber applications to request a continuous and customized stream of =
updates from a YANG datastore.=E2=80=9D =
</ALEX>
  • =E2=80=9CTraditional approaches to providing=E2=80=9D, =
shouldn=E2=80=99t this be =E2=80=9Cto provide=E2=80=9D or =E2=80=9Cof =
providing=E2=80=9D?
<ALEX> OK, change =
made </ALEX>
  • Polling incurs significant latency. This latency prohibits =
many application types. =E2=80=93 Also this sentence doesn=E2=80=99t =
look very correct. Actually the entire section can be improved from a =
language perspective. (e.g. =E2=80=9Cyet for which applications need to =
be quickly notified whenever a change does occur with minimal =
delay.=E2=80=9D)
<ALEX> Prefer to keep =
as-is at this point.  Would leave copy edits to RFC-editor.  =
</ALEX>
  • [I-D.draft-ietf-netconf-subscribed-notifications] usually a =
more friendly reference is used, e.g. =
[SUB-NOT]
<ALEX> Keeping this =
as-is, as this will be replaced by the corresponding RFC reference =
anyhow.  </ALEX>
BR
Daniele  
 

------=_NextPart_000_043E_01D50A8E.C4B27080--


From nobody Wed May 15 00:20:27 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80882120255; Wed, 15 May 2019 00:20:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach 
Message-ID: <155790481851.17474.3456985672733157831.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 00:20:18 -0700
Archived-At: 
Subject: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 07:20:19 -0000

Adam Roach has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for all the work that the authors and other contributors have
put into this document. I have two comments that need to be addressed
before publication, but they should both be very easy to fix.

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


§3.3:

>  If a publisher fails to serve the RPC request for one of the reasons
>  indicated in [I-D.draft-ietf-netconf-subscribed-notifications]
>  Section 2.4.6 or [I-D.ietf-netconf-yang-push] Appendix A, this will
>  be indicated by "406" status code transported in the HTTP response.

This really isn't what 406 means. 406 means "you sent one or more of the
'Accept', 'Accept-Charset', 'Accept-Encoding', or 'Accept-Language' header
fields, and I can't generate a response that satisfies what you've asked for."

For some of the errors listed in the two cited sections, there is a reasonable
semantic mapping onto existing HTTP response codes; e.g. the
"no-such-subscription" errors could all reasonably map on to HTTP 404.  I'll
note that RFC 8040 section 7 performs exactly this kind of mapping, so the
approach seems to be consistent with the way that RESTCONF has elected to use
HTTP response codes. In fact, this document already maps from the cited errors
to error tags already, and that table maps from error-tag to
HTTP response codes, so fixing this should be the relatively straightforward
exercise of updaing the tables in this section to also include the HTTP response
code that RFC 8040 maps to the indicated error-tag. For example:

     error identity         uses error-tag             HTTP Response
     ---------------------- --------------             -------------
     dscp-unavailable       invalid-value              400
     encoding-unsupported   invalid-value              400
     filter-unsupported     invalid-value              400
     insufficient-resources resource-denied            409
     no-such-subscription   invalid-value              404
     replay-unsupported     operation-not-supported    501

     error identity              uses error-tag          HTTP Response
     ----------------------      --------------          -------------
     cant-exclude                operation-not-supported 501
     datastore-not-subscribable  invalid-value           400
     no-such-subscription-resync invalid-value           404
     on-change-unsupported       operation-not-supported 501
     on-change-sync-unsupported  operation-not-supported 501
     period-unsupported          invalid-value           400
     update-too-big              too-big                 400
     sync-too-big                too-big                 400
     unchanging-selection        operation-failed        500

However you choose to address this, if the error isn't related to any of the
four header fields I mention above, then you can't specify the use of a 406.

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

§3.4:

This section is unclear about how Server-Sent Events are to be used (in
particular, they don't say anything about event type to be used). Based on the
one example in Appendix A that shows SSE syntax, I'm assuming you probably do
not intend to use SSE "event type" fields to distinguish between events in any
way.  This would mean that you need to specify that all SSE messages are sent
with an event type of "message," which the server may omit (as it is the
default specified in the Server-Side Events specification).  This means that
clients will need to accept both:

data: {
data:   "ietf-restconf:notification" : {
data:     "eventTime": "2007-09-01T10:00:00Z",
data:     "ietf-subscribed-notifications:subscription-modified": {
data:       "id": "39",
data:       "uri": "https://example.com/restconf/subscriptions/22"
data:       "stream-xpath-filter": "/example-module:foo",
data:       "stream": {
data:          "ietf-netconf-subscribed-notifications" : "NETCONF"
data:       }
data:     }
data:   }
data: }

...and...

event: message
data: {
data:   "ietf-restconf:notification" : {
data:     "eventTime": "2007-09-01T10:00:00Z",
data:     "ietf-subscribed-notifications:subscription-modified": {
data:       "id": "39",
data:       "uri": "https://example.com/restconf/subscriptions/22"
data:       "stream-xpath-filter": "/example-module:foo",
data:       "stream": {
data:          "ietf-netconf-subscribed-notifications" : "NETCONF"
data:       }
data:     }
data:   }
data: }

It may be helpful to incorporate the SSE syntax into all of the notification
examples in Appendix A (that is, all of the examples in A.2 and A.3). I would
recommend a mix of examples with and without "event: message".


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General comment:

It's a bit unclear about what the normative relationship between a Server-Sent
Events connection and a subscription is intended to be. For example: if I send
an RPC command to create a subscription, and then make two different SSE
connections to the resulting URL, will they both receive events associated
with that subscription? If so, does a TLS heartbeat failure on one of them
cause the entire subscription to go away? (If not, what happens?)

If I have only one connection related to a subscription, and I close the TCP
connection, does that necessarily make the subscription go away? What if I
set up a new TCP connection right away after closing the first one? Will
that work?

What if I use RPC to set up a new subscription, and then wait a few minutes
before connecting to the subscription URL?

I don't think you need to answer all of these corner cases per se (although it
would be nice), but minimally a couple of statements that clearly spell out
the relationship between subscriptions and the connections used to deliver
related events would help implementors figure out the answers to these
questions.

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

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please use the boilerplate specified by RFC 8174.

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

§3.1:

>  As stated in Section 2.1 of [RFC8040], a subscriber MUST establish
>  the HTTP session over TLS [RFC5246] in order to secure the content in
>  transit.

Is the intention here to restrict clients to TLS 1.2? If not, please cite
RFC 8446 instead of RFC 5246. If so, please add text that explains why.

(This comment also applies to section 9)

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

§3.1:

>  Loss of the heartbeat MUST result in any subscription related TCP

nit: "...subcription-related..."



From nobody Wed May 15 03:24:51 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC8A120047 for ; Wed, 15 May 2019 03:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo1h65gOTizZ for ; Wed, 15 May 2019 03:24:47 -0700 (PDT)
Received: from mail.myfast.site (mail.myfast.site [109.203.117.12]) (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 8E89612002E for ; Wed, 15 May 2019 03:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:Mime-Version:Reply-To:References: In-Reply-To:Message-Id:Date:Cc:Subject:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DXPHlKfhZM42+TDdII5X1XhWma7V44XNdvm7oyJlmmY=; b=fyhUcrCRouZKm//c3ufey7CPq thIUSgtRqoO/RTQhf8h+xLUji3JsBYv75QF2nm2MxP+D3eL6pF2wNh9wref5l1eAIvTGobBRo4raE XUDp73oCGjQGBa7prtB//vcx+X4wsNF51yKxg45jpDR8K6yDqcTQS+rvBqvAAodeibo7g9qUma8dd Rx/vYM7E/s6EqJhstPhnadfeVPhbWE5tvCJM8FSSJ4tcVqVS/lg72iFP5e8ldiyFFlsAsQxovRwmh lX++tby3+S0gV0EYCwfWVnKAqoP+EOkNbobB/TeJf6+Xs3o4k7tJWZn9GIxmyuhz306+QOUdznIfq JiLE+toYQ==;
Received: from [51.52.247.166] (port=52628 helo=[172.16.3.14]) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hQr5Y-0007fn-JV; Wed, 15 May 2019 11:24:44 +0100
From: "Jonathan Hansford" 
To: "Kent Watsen" 
Cc: "Andy Bierman" , "netconf@ietf.org" 
Date: Wed, 15 May 2019 10:24:46 +0000
Message-Id: 
In-Reply-To: <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>
Reply-To: "Jonathan Hansford" 
User-Agent: eM_Client/7.2.34959.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB205F4328-83AA-45FD-994B-642C0A13368D"
X-Antivirus: Avast (VPS 190515-0, 15/05/2019), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 10:24:50 -0000

--------=_MB205F4328-83AA-45FD-994B-642C0A13368D
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Kent,

I don't think Erratum 5397 should be deleted. Though the original 
section 7.8 makes no mention of confirmed commits, section 7.9 does, but 
does not differentiate between a vanilla confirmed commit and a 
persistent confirmed commit. Since a persistent confirmed commit is 
still a type of confirmed commit, without clarification the second 
paragraph of the description would seem to apply.

With the diff, should that be against the original text or the original 
erratum?

Thanks,

Jonathan


On 14/05/2019 19:45:12, "Kent Watsen"  wrote:

>
>>  So I need to contact the RFC Editor to correct Erratum 5397, with the r=
elevant text in sections 7.8 and 7.9 being changed to something like:
>>
>>  7.8: "If a NETCONF server receives a  request while proc=
essing a confirmed commit (Section 8.4) for that session, unless the confir=
med commit is a persistent confirmed commit, it MUST restore the configurat=
ion to its state before the confirmed commit was issued. A persistent confi=
rmed commit MUST survive session termination."
>>
>>  7.9: "If a NETCONF server receives a  request while proce=
ssing a confirmed commit (Section 8.4) for the session to be killed, unless=
 the confirmed commit is a persistent confirmed commit, it MUST restore the=
 configuration to its state before the confirmed commit was issued. A persi=
stent confirmed commit MUST survive session termination."
>
>Ideally, Errata 5397 is deleted (because I think that it's clear that Sect=
ion 8.4 overrides the 7.8 behavior) but, if we have to patch the errata, I =
might suggests:
>
>For Section 7.8
>   OLD (in RFC 6241)
>
>     The server will release any locks
>     and resources associated with the session and gracefully close any
>     associated connections.
>
>   NEW:
>
>     The server will release any locks
>     and resources, associated with the session and gracefully close any
>     associated connections.  As an exception to the previous sentence, if=

>     the session is processing a persistent confirmed commit (Section 8.4)=
,
>     the resources necessary for supporting confirmed commit are not relea=
sed.
>
>For Section 7.9:
>   OLD (in RFC 6241)
>
>       If a NETCONF server receives a  request while
>       processing a confirmed commit (Section 8.4), it MUST restore the
>       configuration to its state before the confirmed commit was issued.
>
>   NEW:
>       What you have above seems fine, though I'd leave off the last sente=
nce.
>
>
>>  I also need to contact the RFC Editor to correct Erratum 3821 to change=
:
>>
>>  If the session issuing a sequence of one or more confirmed commits is
>>  terminated for any reason before the confirm timeout expires, the serve=
r
>>  MUST restore the configuration to its state before the sequence of
>>  confirmed commits was issued, unless the last confirmed commit also
>>  included a  element.
>>
>>  If the device reboots for any reason before the confirm timeout
>>  expires, the server MUST restore the configuration to its state
>>  before the sequence of confirmed commits was issued.
>>
>>  to something like:
>>
>>  If the session issuing a sequence of one or more confirmed commits is
>>  terminated for any reason before the confirm timeout expires, the serve=
r
>>  MUST restore the configuration to its state before the sequence of
>>  confirmed commits was issued, unless the confirmed commit is a
>>  persistent confirmed commit.
>>
>>  If the device reboots for any reason before the confirm timeout
>>  expires, unless a persistent confirmed commit is in progress, the
>>  server MUST restore the configuration to its state before the
>>  sequence of confirmed commits was issued.
>>
>>   A persistent confirmed commit MUST survive session termination.
>>
>
>This seems okay but, again, I'd leave out the last sentence.
>
>
>Side note: huge errata are hard to read without a diff.  If a lot of text,=
 then the NEW (or the NOTES) should include a diff highlighting exactly wha=
t changed.
>
>Kent // contributor
>
>
>
>>  Are those errata OK?
>>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--------=_MB205F4328-83AA-45FD-994B-642C0A13368D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable




Kent,

I don't think Erratum 539=
7 should be deleted. Though the original section 7.8 makes no mention of co=
nfirmed commits, section 7.9 does, but does not differentiate between a van=
illa confirmed commit and a persistent confirmed commit. Since  a persisten=
t confirmed commit is still a type of confirmed commit, without clarificati=
on the second paragraph of the description would seem to apply.=C2=A0
=


With the diff, should that be against the original te=
xt or the original erratum?

Thanks,
Jonathan






On 14/05/2019 19:45:12, "Kent Watsen" <kent@watsen.net> wrote:






=C2=A0




 So I need to contact the RFC Editor to correct E=
rratum 5397, with the relevant text in sections 7.8 and 7.9 being changed t=
o something like:


=C2=A0


 7.8: "If a NETCONF server receives a <close-s=
ession> request while processing a confirmed commit (Section 8.4) for th=
at session, unless the confirmed commit is a persistent confirmed commit, i=
t MUST restore the configuration to its state before the confirmed commit w=
as issued. A persistent confirmed commit MUST survive session termination."=



=C2=A0


 7.9: "If a NETCONF server receives a <kill-se=
ssion> request while processing a confirmed commit (Section 8.4) for the=
 session to be killed, unless the confirmed commit is a persistent confirme=
d commit, it MUST restore the configuration to its state before the confirm=
ed commit was issued. A persistent confirmed commit MUST survive session te=
rmination."




=C2=A0


Ideally, Errata 5397 is deleted (because I think =
that it's clear that Section 8.4 overrides the 7.8 behavior) but, if we hav=
e to patch the errata, I might suggests:


=C2=A0


For Section 7.8


  OLD (in RFC 6241)


=C2=A0


    The server will release any locks


    and resources associated with the session and=
 gracefully close any


    associated connections.


=C2=A0


  NEW:


=C2=A0


    The server will release any locks


    and resources, associated with the session an=
d gracefully close any


    associated connections.  As an exception to t=
he previous sentence, if


    the session is processing a persistent confir=
med commit (Section 8.4),


    the resources necessary for supporting confir=
med commit are not released.


=C2=A0


For Section 7.9:


  OLD (in RFC 6241)


=C2=A0


      If a NETCONF server receives a <kill-ses=
sion> request while


      processing a confirmed commit (Section 8.4)=
, it MUST restore the


      configuration to its state before the confi=
rmed commit was issued.


=C2=A0


  NEW:


      What you have above seems fine, though I'd =
leave off the last sentence.


=C2=A0


=C2=A0




 I also need to contact the RFC Editor to correct=
 Erratum 3821 to change:


=C2=A0


 If the session issuing a sequence of one or more=
 confirmed commits is


 terminated for any reason before the confirm tim=
eout expires, the server


 MUST restore the configuration to its state befo=
re the sequence of


 confirmed commits was issued, unless the last co=
nfirmed commit also


 included a <persist> element.


=C2=A0


 If the device reboots for any reason before the =
confirm timeout


 expires, the server MUST restore the configurati=
on to its state


 before the sequence of confirmed commits was iss=
ued.


=C2=A0


 to something like:


=C2=A0


 If the session issuing a sequence of one or more=
 confirmed commits is


 terminated for any reason before the confirm tim=
eout expires, the server


 MUST restore the configuration to its state befo=
re the sequence of


 confirmed commits was issued, unless the confirm=
ed commit is a


 persistent confirmed commit.


=C2=A0


 If the device reboots for any reason before the =
confirm timeout


 expires, unless a persistent confirmed commit is=
 in progress, the


 server MUST restore the configuration to its sta=
te before the


 sequence of confirmed commits was issued.


=C2=A0


  A persistent confirmed commit MUST survive sess=
ion termination.


=C2=A0




=C2=A0


This seems okay but, again, I'd leave out the las=
t sentence.


=C2=A0


=C2=A0


Side note: huge errata are hard to read without a=
 diff.  If a lot of text, then the NEW (or the NOTES) should include a diff=
 highlighting exactly what changed.


=C2=A0


Kent // contributor


=C2=A0


=C2=A0


=C2=A0




 Are those errata OK?


=C2=A0




=C2=A0








	

        3D""
		Virus-=
free. www.avast.com
		
	


 

--------=_MB205F4328-83AA-45FD-994B-642C0A13368D--


From nobody Wed May 15 05:48:29 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3D41200BA; Wed, 15 May 2019 05:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SAcWpUCF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZAI0rIEO
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l0FqCbY_8R4; Wed, 15 May 2019 05:48:19 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9E312007A; Wed, 15 May 2019 05:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2468; q=dns/txt; s=iport; t=1557924499; x=1559134099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lIlWUV2YSysl8bI6minrLE+Sv22Zsa/l1vuejrSnwBs=; b=SAcWpUCFakpjIAzPzPa2DH7HUb1QKx9sUE/XxBAyQpy3eOTLq6wZ4CEF 9+JsylfGwVX3EcHINjxUS1ZnwDditWeinnAPsJElqfAaiHN2HOu7PzRAC cDRaPnW1CeJj4tAgn5/9HJgFbEeMmepOTAAvNHOnNbv+LT5U53Q/rq9T4 U=;
IronPort-PHdr: =?us-ascii?q?9a23=3Alm7WURQ0d7xThXXQWqqaujfd/9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYgFcRHXVlN9HCgOk8TE8H7NBXf?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAAC7Cdxc/5BdJa1kHQEBBQEHBQG?= =?us-ascii?q?BUQgBCwGBPVADaVUgBAsoCoQHg0cDhFKKH4Iyl0qBLhSBEANUCQEBAQwBASM?= =?us-ascii?q?KAgEBhEACF4IUIzQJDgEDAQEEAQECAQRtHAyFSwIEEhERDAEBNwEPAgEIGgI?= =?us-ascii?q?JHQICAjAVEAIEAQ0FIoMAAYFqAx0BDqBtAoE1iF9xgS+CeQEBBYFGQYJ5GII?= =?us-ascii?q?PAwaBCygBi04XgUA/gTgME4JMPoJhAgECAYEqARIBHxeCczKCJoslgjuZfQk?= =?us-ascii?q?CggmGIYhrg1IbghSGTI0OjDSGWI4yAgQCBAUCDgEBBYFPOGZYEQhwFWUBgkG?= =?us-ascii?q?CDzeDOIUUhT9yAYEojQOBIgGBIAEB?=
X-IronPort-AV: E=Sophos;i="5.60,472,1549929600"; d="scan'208";a="271454656"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2019 12:48:17 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x4FCmHFH028403 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2019 12:48:17 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 May 2019 07:48:17 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 May 2019 07:48:16 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 15 May 2019 07:48:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lIlWUV2YSysl8bI6minrLE+Sv22Zsa/l1vuejrSnwBs=; b=ZAI0rIEO7ebZ64ww5msx7cxWpxI6bUa+oGW/0pjRTZyI8gVpOFsITaXA3gXsupWlJVEj0z17tYFGSiKv7gulOPHKwac4h8tBKr+E5yadOGUUcN/zKAZNsrvFn5Wo+7Cx6y6/E6Qv6yS+f5Wn5VKHzHaSmQ67W8rA5W+BK06KJmE=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5SPR00MB244.namprd11.prod.outlook.com (10.171.161.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Wed, 15 May 2019 12:48:15 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1900.010; Wed, 15 May 2019 12:48:15 +0000
From: "Reshad Rahman (rrahman)" 
To: Alissa Cooper , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
Thread-Index: AQHVCpXPnAkYvjnvLUmX8Jbbjw/JgaZr4LEA
Date: Wed, 15 May 2019 12:48:15 +0000
Message-ID: <194B007F-1267-4DFD-B530-632D9A436B33@cisco.com>
References: <155786665488.30110.1029818535148238046.idtracker@ietfa.amsl.com>
In-Reply-To: <155786665488.30110.1029818535148238046.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7883c656-e905-4333-a230-08d6d93398ec
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5SPR00MB244; 
x-ms-traffictypediagnostic: DM5SPR00MB244:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0038DE95A2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(366004)(346002)(396003)(199004)(189003)(6486002)(26005)(54906003)(110136005)(8936002)(186003)(83716004)(7736002)(76176011)(102836004)(81156014)(8676002)(81166006)(58126008)(476003)(2616005)(486006)(36756003)(14454004)(446003)(11346002)(66066001)(3846002)(966005)(6246003)(6116002)(71190400001)(71200400001)(316002)(25786009)(76116006)(86362001)(2906002)(4326008)(305945005)(68736007)(6306002)(6512007)(6506007)(229853002)(66446008)(66476007)(66946007)(478600001)(6436002)(66556008)(256004)(64756008)(14444005)(5660300002)(91956017)(99286004)(73956011)(82746002)(53936002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB244; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: EeeOIX78EmLeSPt90ozA1EIYd2H+JAzMOUVALQBAIEbZmi6jGCsvBRKyfKZV2JIq9XLToPeLfUdQV1PT+oznaguh0/qOEu5y4lVWq/4RzEIOGrtA84TKauyN+OrYebX13+LAyEkyt9rzpad7VJO2z8NwWtECT7vySBA7uGvmYyrA60C2C7DG4naPdhJeGe3Ccsk6otLFfRC8SL6rXx0mXvAT5BoMI7F0AULZkEuyc9NGJ3yormge6d8XWaFEWiBFdx8QKZhAC73BeD7jDQUEHWCdSzRqZ5M0yvGkAwRzvjTNxzTLY4WoYOmHIcyhnouFj3QZPw+A0Y+y/FcUrtNq7NmmYIdL9sUgsZz3l4igags8W9nGABphFs2HvpOPFjVb8sah+Mv2EXG84APr9k1f4yS3Ijbh/iVz8ta1azcKUJY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1248FD13FB74B04EB8D65FC044CDE520@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7883c656-e905-4333-a230-08d6d93398ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2019 12:48:15.0807 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB244
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: 
Subject: Re: [netconf] Alissa Cooper's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 12:48:21 -0000

SGkgQWxpc3NhLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcsIHBsZWFzZSBzZWUgaW5saW5l
Lg0KDQoNCu+7v09uIDIwMTktMDUtMTQsIDQ6NDQgUE0sICJBbGlzc2EgQ29vcGVyIHZpYSBEYXRh
dHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgQWxpc3NhIENvb3BlciBo
YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1p
ZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYtMTM6IE5vIE9iamVjdGlvbg0KICAgIA0KICAgIFdo
ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl
cGx5IHRvIGFsbA0KICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND
IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFw
aCwgaG93ZXZlci4pDQogICAgDQogICAgDQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3
LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBt
b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu
DQogICAgDQogICAgDQogICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw
b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZi8NCiAgICANCiAgICAN
CiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQogICAgDQogICAgPSBTZWN0aW9uIDkgPQ0KICAgIA0KICAgICAgICAgICAgIkFjY2VzcyBjb250
cm9sIG11c3QgYmUgc2V0IHNvIHRoYXQgb25seSBzb21lb25lDQogICAgICAgICAgd2l0aCBwcm9w
ZXIgYWNjZXNzIHBlcm1pc3Npb25zLCBhbmQgcGVyaGFwcyBldmVuIEhUVFAgc2Vzc2lvbiBoYXMN
CiAgICAgICAgICB0aGUgYWJpbGl0eSB0byBhY2Nlc3MgdGhpcyByZXNvdXJjZS4iDQogICAgDQog
ICAgVGhlcmUgaXMgYSBncmFtbWFyIGVycm9yIGluIHRoaXMgc2VudGVuY2UgLS0gInBlcmhhcHMg
ZXZlbiBIVFRQIHNlc3Npb24iDQogICAgZG9lc24ndCBmb2xsb3cgZnJvbSB0aGUgYW50ZWNlZGVu
dC4NClllcyB0aGlzIHRleHQgaXMgbm90IGNsZWFyLCBnb29kIGNhdGNoLiBJIHdpbGwgY2hhbmdl
IGl0IHRvIHRoZSBmb2xsb3dpbmcNCiAgICAgICAgbyAgInVyaSI6IGxlYWYgd2lsbCBzaG93IHdo
ZXJlIHN1YnNjcmliZWQgcmVzb3VyY2VzIG1pZ2h0IGJlIGxvY2F0ZWQNCiAgICAgICAgICAgb24g
YSBwdWJsaXNoZXIuICBBY2Nlc3MgY29udHJvbCBtdXN0IGJlIHNldCBzbyB0aGF0IG9ubHkgc29t
ZW9uZQ0KICAgICAgICAgICB3aXRoIHByb3BlciBhY2Nlc3MgcGVybWlzc2lvbnMsIGkuZS4sIHRo
ZSBzYW1lIFJFU1RDT05GIFtSRkM4MDQwXQ0KICAgICAgICAgICB1c2VyIGNyZWRlbnRpYWxzIHdo
aWNoIGludm9rZWQgdGhlIGNvcnJlc3BvbmRpbmcNCiAgICAgICAgICAgImVzdGFibGlzaC1zdWJz
Y3JpcHRpb24iLCBoYXMgdGhlIGFiaWxpdHkgdG8gYWNjZXNzIHRoaXMgcmVzb3VyY2UuDQoNClJl
Z2FyZHMsDQpSZXNoYWQuICAgIA0KICAgIA0KICAgIA0KDQo=


From nobody Wed May 15 08:00:39 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5E120100; Wed, 15 May 2019 08:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX1PEXV_Hl0R; Wed, 15 May 2019 08:00:31 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9633C1200B2; Wed, 15 May 2019 07:59:52 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4FExkjU029080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 May 2019 10:59:48 -0400
Date: Wed, 15 May 2019 09:59:45 -0500
From: Benjamin Kaduk 
To: Alexander Clemm 
Cc: "'The IESG'" , netconf@ietf.org, draft-ietf-netconf-yang-push@ietf.org, netconf-chairs@ietf.org
Message-ID: <20190515145945.GD14483@kduck.mit.edu>
References: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com> <043c01d50ac9$7099a780$51ccf680$@clemm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <043c01d50ac9$7099a780$51ccf680$@clemm.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 15:00:37 -0000

On Tue, May 14, 2019 at 07:53:52PM -0700, Alexander Clemm wrote:
> Hi Benjamin,
> 
> Thank you for your review!  Replies inline, .  Update will be
> reflected in -24, to be posted shortly.  
> 
> --- Alex
> 
> -----Original Message-----
> From: netconf  On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Wednesday, May 1, 2019 12:08 PM
> To: The IESG 
> Cc: netconf@ietf.org; draft-ietf-netconf-yang-push@ietf.org;
> netconf-chairs@ietf.org
> Subject: [netconf] Benjamin Kaduk's Discuss on
> draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netconf-yang-push-23: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Note that I reviewed the -22 and the current version is -23.  Briefly
> skimming the diff, it seems that some changes touch on points I make in my
> review, but there is probably still discussion to have on them.
> 
> (pro-forma) I see the GenArt reviewer noted the author count (seven)
> already, but I couldn't find a response or note in the ballot or shephert
> writeup acknowledging this.  So failing that, I'll put up a discuss point
> until the responsible AD says it's fine.
> 
> [See also discussion on draft-ietf-netconf-subscribed notifications about
> the pre-RFC5378 boilerplate and whether or not it can be removed from this
> document]
> 
>  Several of the authors have graciously agreed to step down and be
> listed as contributors. 

Thanks to them!

> Section 3.3 states:
> 
>             In order for a subscriber to determine whether objects
>    support on-change subscriptions, objects are marked accordingly on a
>    publisher.  Accordingly, when subscribing, it is the responsibility
>    of the subscriber to ensure it is aware of which objects support on-
>    change and which do not.  For more on how objects are so marked, see
>    Section 3.10.
> 
> Chasing the reference, we see that this marking is left for future work or
> implementation-specific usage.  I'm not very comfortable with the way we are
> describing this situation, as it seems pretty fragile in the face of
> different implementations trying to interoperate.
> 
>  The working group decided to pull this item out of this draft.  It is
> being addressed in draft-ietf-netconf-notification-capabilities
> (https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabiliti
> es/) 

I guess I'll see what the -24 looks like, but I'm not sure yet whether
"pull this item out of the draft" is describing a previous decision that
left it in this state or a current decision starting from this state.  (The
latter would seem to make more sense to me, but I can wait and see.)

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the very thoughtful document!  I've lost track of the number
> of places where I started writing a comment only to note that my concern had
> already been addressed in the following text.  In general the writing style
> is great, though I did find some grammar and clarity nits (noted inline).
> 
> Abstract
> 
>                Providing such visibility into updates enables new
>    capabilities based on the remote mirroring and monitoring of
>    configuration and operational state.
> 
> This phrasing ("new capabilities based on") is hard for me to follow,
> particularly about whether these are protocol-level capabilities and what
> actors are granted the new capabilities.
> 
>  The capabilities are clearly not related to protocol-level
> capabilities, but capabilities for applications that have uses for
> information obtained from YANG datastores.  If it's okay, at this point we
> would like to keep it as-is. 

It's your prerogative to keep it as-is, though the RFC Editor may also take
a crack at the wording.

> Section 1
> 
>    Traditional approaches to providing visibility into managed entities
>    from remote have been built on polling.  [...]
> 
> nit: "remote" is an adjective and needs a noun to bind to; "from remote
> systems", "from remote vantages", or "from afar" would all be fine wordings
> here.
> 
>  changed to  "from a remote system".   
> 
>    o  Polling incurs significant latency.  This latency prohibits many
>       application types.
> 
> nit: I'd suggest wording as "types of application", since on my first
> reading I thought this was referring to some sort of codepoint.
> 
>  changed 
> 
>    o  Polling cycles may be missed, requests may be delayed or get lost,
>       often when the network is under stress and the need for the data
>       is the greatest.
> 
> nit: the grammar is a bit weird, here, as if a comma splice.  I think
> replacing the first comma with a colon or em dash would suffice.
> 
>  replaced first comma with "and", to read: "Polling cycles may be
> missed and requests may be delayed or get lost, often when the network is
> under stress and the need for the data is the greatest." 

Thanks!

>    o  Datastore node update: A data item containing the current value of
>       a datastore node at the time the datastore node update was
>       created, as well as the path to the datastore node.
> 
> Is this storing the "new" or the "old" value as the "current value"?
> 
>  I don't understand the question.  I think the statement is
> clear.

This sounds like it's conceptually "take a copy of some data as you make an
update it, to have a historical record of what changed".  I mostly assume
that the copy operation happens before the update, so the old/previous
value is recorded in the record, but the text seems to describe them
happening at the same time, without a specified ordering between them.
(That said, IIRC, there is some text later in the document that helps
clarify the intent, but that is not a free pass for leaving things unclear
here.)

> Section 3.1
> 
>          +  Dampening period: In an on-change subscription, detected
>             [...]
>             is included.  The dampening period goes into effect every
>             time an update record completes assembly.
> 
> Just to double-check: this means that after a long hiatus, the first change
> to the monitored subtree(s) triggers an immediate push with just the single
> update, and only then does the dampening period kick in and defer delivery
> of potential subsequent updates?
> 
>  Yes, this is correct 
> 
> Section 3.5.2
> 
> This bit about the "create" and "delete" errors from RFC 8072 Section
> 2.5 not being errors in our usage is a little interesting, process-wise.
> In one sense, we are changing the semantics of an already published RFC, and
> would need to apply an "Updates:" relationship to indicate that, but in the
> other sense we are building a new custom thing that reuses a lot of the
> syntax/semantics of YANG patch but is fundamentally a new
> (different) thing.  The phrasing we use to talk about it can affect which
> case the reader perceives us to be in...
> 
> The discussion on the "change-type" enumeration seems to pretty clearly
> place us in the latter case, which is good.
> 
>  Keeping this as is. 
> 
> Section 3.6
> 
> Thank you for the note about the power of XPath expressions and the duty of
> the receiver to understand what it's asking for -- that sort of statement
> would potentially even be appropriate in the Security Considerations (but is
> fine where it is)!
> 
>  Keeping this as is.  
> 
> Section 3.7
> 
>    Of note in the above example is the 'patch-id' with a value of '0'.
>    Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG
>    Push, the publisher SHOULD put into the 'patch-id' a counter starting
>    at '0' which increments with every 'push-change-update' generated for
>    a subscription.  If used as a counter, this counter MUST be reset to
>    '0' anytime a resynchronization occurs (i.e., with the sending of a
>    'push-update').  Also if used as a counter, the counter MUST be reset
>    to '0' after passing a maximum value of '4294967295' (i.e. maximum
>    value that can be represented using uint32 data type).  Such a
>    mechanism allows easy identification of lost or out-of-sequence
>    update records.
> 
> It's not really clear to me how much value there is in this counter
> mechanism if the client' can't rely on the server's behavior actually being
> to use a counter (the requirement is only "SHOULD").  Can this be a "MUST"
> (or maybe "MUST excpet when [...]") instead?
> 
>  Would prefer to not introduce no MUST requirements at this point and
> keep this as a SHOULD.  

This is only a non-blocking comment, so go ahead.

> Section 3.9
> 
>                                                           Empty "push-
>    change-update" messages (in case of an on-change subscription) MUST
>    NOT be sent.  This is required to ensure that clients cannot
>    surreptitiously monitor objects that they do not have access to via
>    carefully crafted selection filters.  By the same token, changes to
>    objects that are filtered MUST NOT affect any dampening intervals.
> 
> I appreciate this attention to security-relevant detail; thank you!
> 
>  thanks! 
> 
> Section 3.11.1
> 
> Do we want to give any guidance for the "incomplete-update" case about
> whether a subscriber should wait and give the publisher a chance to provide
> a full "push-update" for resynchronization (per Section 4.3.2) versus
> perform a normal query for the datastore contents and effectuating its own
> resynchronization?
> 
>  This should be up to the subscriber to decide, and what to do may
> differ for different applications.  In some instances, it can afford to
> simply wait; in other cases or when specifically interested in one
> particular closely-monitored item it may decide not to and sync immediately.
> 

Okay.

> Section 4
> 
>    o  For on-change subscriptions, assuming any dampening period has
>       completed, triggering occurs whenever a change in the subscribed
>       information is detected.  On-change subscriptions have more
>       complex semantics that is guided by its own set of parameters:
> 
> nit: singular/plural mismatch "semantics"/"is"
> 
>  changed to "On-change subscriptions have more complex semantics that
> are guided by their own set of parameters" 
> 
> Section 4.3.2
> 
> 
>    A "time-of-update" which represents the time an update record
>    snapshot was generated.  A receiver MAY assume that at this point in
>    time a publisher's objects have the values that were pushed.
> 
> nit: I think "had the values" (past tense) is more appropriate.
> 
>  changed 
> 
> Section 4.4.1
> 
>    a publisher that cannot serve on-change updates but periodic updates
>    might return the following NETCONF response:
> 
> nit: "but can serve periodic updates"
> 
>  changed 
> 
> Section 4.4.2
> 
>    The specific parameters to be returned in as part of the RPC error
>    response depend on the specific transport that is used to manage the
>    subscription.  For NETCONF, those parameters are specified in
>    [I-D.draft-ietf-netconf-netconf-event-notifications].
> 
> nit: "in" and "as part of" are redundant.
> 
>  removed "in" 
> 
> Section 5
> 
> It is slightly interesting to note that (apparently) the
> update-policy-modifiable grouping allows for a subscription to switch
> between periodic and triggered at runtime (by virtue of wanting a single
> grouping to cover all the cases and needing to be able to modify the
> parameters for each case).  I would mostly expect implementations to deny
> such modification requests due to the needed complexity, but I'm also not
> sure that there's a need to mention this explicitly in the document.
> 
>   I think it is implied that a modification request can always be
> denied if not supported by a server.  At the same time, clearly in general
> you would not change between on-change and periodic.  Keeping as is. 
> 
>             leaf period {
>               type centiseconds;
>               mandatory true;
>               description
>                 "Duration of time which should occur between periodic
>                  push updates, in one hundredths of a second.";
> 
> It would probably be okay to skip "in one hundredths of a second" given the
> usage of the centiseconds typedef.
> 
>  doesn't hurt to be explicit; keeping as is 
> 
>     rc:yang-data resync-subscription-error {
>       container resync-subscription-error {
>         description
>           "If a 'resync-subscription' RPC fails, the subscription is
>            not resynced and the RPC error response MUST indicate the
>            reason for this failure.  This yang-data MAY be inserted as
>            structured data within a subscription's RPC error response
>            to indicate the failure reason.";
> 
> It's a little weird to have the normative language here constraining the RPC
> error response that must be returned for a specific RPC, since this is not
> the description of that RPC.  (It's probably also duplicating langauge
> elsewhere but I didn't double-check.)
> 
>  Keeping as is since it is clear what is happening.  Note that there
> are limitations to the RPC semantics you can formally define in YANG, hence
> the description. 
> 
>     rc:yang-data establish-subscription-datastore-error-info {
>       container establish-subscription-datastore-error-info {
>         description
>           "If any 'establish-subscription' RPC parameters are
>            unsupportable against the datastore, a subscription is not
>            created and the RPC error response MUST indicate the reason
>            why the subscription failed to be created.  This yang-data
>            MAY be inserted as structured data within a subscription's
>            RPC error response to indicate the failure reason.  This
>            yang-data MUST be inserted if hints are to be provided back
>            to the subscriber.";
> 
> (ditto)
> 
> Contrast to modify-subscription-datastore-error-info, which only has
> normative language about the yang-data being described and not the RPCs that
> (might) use it.
> 
>  Would keep as is.  I think the semantics are clear.  

You can certainly keep it as-is and I won't complain further; I just want
to note that my complaint was not "the semantics are unclear if I read the
whole document" but rather "the semantics are described in a different
place than a naive reader might expect".  Yes, the reader is generally
going to have to look up the description of the data types involved in the
RPC as well as the RPC description itself to actually use it, but I can
imagine some cases where that doesn't work as well as it could.

> nit: push-update and push-change-update use different langauge about "does
> not constitute a general-purpose notification" and I'm not sure there's a
> reason to diverge.
> Their "incomplete-update" leaves also have divergent descriptions, but I
> think that latter divergence is more reasonable.
> 
>  Updated the description of push-change-update to align this part of
> the description of the notifications.  

Thanks!

-Ben

>     augment "/sn:subscription-modified/sn:target" {
>       [...]
>       case datastore {
>         uses datastore-criteria {
>           refine "selection-filter/within-subscription" {
>             description
>               "Specifies where the selection filter, and where it came
>                from within the subscription and then populated within
>                this notification.  If the 'selection-filter-ref' is
> 
> nit: "where the selection filter" seems like an incomplete clause.
> 
>  Updating this to  "Specifies the selection filter and where it
> originated  from.  If the 'selection-filter-ref' is ...".  This way, the
> description also aligns better with the augment to
> sn:subscription-started/sn:target. 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Wed May 15 10:13:04 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15503120302; Wed, 15 May 2019 10:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuzJJifJAMMA; Wed, 15 May 2019 10:12:53 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AAB87120326; Wed, 15 May 2019 10:12:26 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4FHCKxG030523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 May 2019 13:12:22 -0400
Date: Wed, 15 May 2019 12:12:20 -0500
From: Benjamin Kaduk 
To: "Reshad Rahman (rrahman)" 
Cc: The IESG , "draft-ietf-netconf-restconf-notif@ietf.org" ,  Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Message-ID: <20190515171219.GF14483@kduck.mit.edu>
References: <155726272794.32635.6531627027808857417.idtracker@ietfa.amsl.com> <6F96C6CD-B0F1-44F2-A2BE-E2FD23B309CC@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6F96C6CD-B0F1-44F2-A2BE-E2FD23B309CC@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 17:12:57 -0000

On Fri, May 10, 2019 at 09:55:08PM +0000, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> Thanks for the review, please see inline.
> 
> On 2019-05-07, 4:59 PM, "Benjamin Kaduk via Datatracker"  wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-netconf-restconf-notif-13: Discuss
>         
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/
>     
>     
>     
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>     
>     Thanks for the well-written document!  I  just have some boring housecleaning
>     points that should be easy to resolve.
>     
>     Section 3.2 states:
>     
>        Subscribers can learn what event streams a RESTCONF server supports
>        by querying the "streams" container of ietf-subscribed-
>        notification.yang in
>        [I-D.draft-ietf-netconf-subscribed-notifications].  Support for the
>        "streams" container of ietf-restconf-monitoring.yang in [RFC8040] is
>        not required.  If it is supported, the event streams which are in the
>        "streams" container of ietf-subscribed-notifications.yang SHOULD also
>        be in the "streams" container of ietf-restconf-monitoring.yang.
>     
>     This "SHOULD" seems to be attempting to impose a normative requirement
>     on specifications that implement
>     draft-ietf-netconf-subscribed-notifications and RFC 8040 streams,
>     without regard to whether they implement this specification.  It seems
>     better-placed in draft-ietf-netconf-subscribed-notifications.
>  RFC8040 is the RESTCONF RFC and subscribed-notifications is not
>   transport specific. Since this document is for RESTCONF, this is why we

Ah, of course; I failed to internalize that RFC 8040 is RESTCONF-specific
in my quick check of the reference.

>   have added this statement in this document.

So I agree that this document is the only reasonable place to convey this
information, but the current presentation still feels rather odd to me.
Just to check my understanding, the situation could be summarized as
"[subscribed-notifications] defines a "streams" container, and 8040
describes a different "streams" container, but if both containers are
present/supported, then anything in the one from [subscribed-notifications]
should also be visible in the one from 8040"?

To me, this has a large component of "document A specifying the interaction
of documents B and C", which normally would require an "Updates"
relationship to either B or C (or, if B or C are not RFCs yet, just moving
the text).  I understand that in this case things are somewhat different,
as document A (i.e., this document) is specifying the transport scheme for
document B (subscribed-notifications) using the protocol from document C.
As such, anything that describes interactions about document B that are
specific to when it is carried over document C must be in this document,
but this specific matter feels less like something about how the protocol
is encoded (i.e., the main focus of this document) and rather an
interaction between protcol features.

I don't have a great proposal for anything specific to change that would
alleviate my concern, though (and as such I will stop holding this as a
Discuss point), though I hope my colleagues on the IESG may have some
additional thoughts.  The best thing I can come up with right now would be
to say:

  In the case when the RESTCONF binding specified by this document is used
  to convey the "streams" container from ietf-restconf-monitoring.yang
  (i.e., that feature is supported), any event streams contained therein
  are also expected to be present in the "streams" container of
  ietf-restconf-monitoring.yang.

Feedback is welcome!

>     Similarly, when Section 4 writes:
>     
>        To meet subscription quality of service promises, the publisher MUST
>        take any existing subscription "dscp" and apply it to the DSCP
>        marking in the IP header.
>     
>     that seems to be duplicating a normative requirement from the core
>     subscribed-notifications document.  (And I'm sure Magnus will have
>     further follow-up about how DSCP markings are per-connection for the
>     stream transports we have available, as well.)
>  You are correct, this text can be removed.   I can replace it with a reference to the section in subscribed-notifications, would that work for you?

That works for me; thanks.

>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     The core subscribed-notifications document notes that dynamic
>     subscriptions only last as long as the underlying transport.  In this
>     document, we have two connections in Figure 1, which could potentially
>     be separate TCP/TLS connections (or HTTP/2 streams).  In the "two TCP
>     connections" case, does terminating either one cause the cessation of
>     the subscription, or just (b)?
>  There are no "long-lived RESTCONF sessions". Terminating (a) does not terminate the subscription.

Okay.  This was not clear to me, a non-expert in the field, but if you
think it's clear to the target audience I won't ask for any text changes
to clarify.

>     Section 2
>     
>     Please use the boilerplate from RFC 8174.
>  Ack, will do in next rev.
>     
>     Section 3
>     
>                                           YANG datastore subscription is
>        accomplished via augmentations to
>        [I-D.draft-ietf-netconf-subscribed-notifications] as described within
>        [I-D.ietf-netconf-yang-push] Section 4.4.
>     
>     I see some reviewers commented that things were a bit terse/arcane; I
>     might suggest that "via augmentations to [subscribed notifications]" is
>     not really adding much here, and the yang-push RPCs are the important
>     part.
>  The augmentation to subscribed-notifications is mentioned because it is needed for RESTCONF. Are you suggesting we change this to "...accomplished as described in  [I-D.ietf-netconf-yang-push] Section 4.4."?

That's my suggestion, yes (but feel free to ignore it).

>     Section 3.1
>     
>                                                              Where quick
>        recognition of the loss of a publisher is required, a subscriber
>        SHOULD use a TLS heartbeat [RFC6520], just from receiver to
>        publisher, to track HTTP session continuity.
>     
>     TLS heartbeats require initiation by the TLS client, by virtue of
>     including the HeartbeatExtension in the ClientHello.  Who is going to be
>     making the determination that quick recognition is required, and if
>     that's the publisher, how does the subscriber know to use TLS
>     heartbeats?
>  The subscriber is the one making that determination since this is to recognize the loss of the publisher.

Okay.  I think that means all the technical pieces work together as needed,
but there could perhaps be more precision in the text about the expected
behavior.  (Note that this is a non-blocking comment, of course.)

>     nit: It's interesting that we seem to be using both "subscriber" and
>     "receiver" to talk about the TLS client, in the same sentence.
>  Will change to subscriber.
>     
>     side note: per https://github.com/openssl/openssl/pull/1928, OpenSSL
>     will not support TLS or DTLS heartbeats of any form in its next major
>     release (3.0.0).
>     
>        Loss of the heartbeat MUST result in any subscription related TCP
>        sessions between those endpoints being torn down.  A subscriber can
>        then attempt to re-establish the dynamic subscription by using the
>        procedure described in Section 3.
>     
>     RFC 6520 does not specify retransmit numbers or intervals to be used to
>     determine that a peer is nonresponsive (i.e., "lost"), so this text
>     seems under-specified.  Is the intent to leave these decisions to be
>     implementation-specific?
>  Yes this is the intent since it all depends on what the subscriber needs/wishes.

It may be worth mentioning explicitly that this is to be
implementation-specific, but it's your call.

>     Section 3.3
>     
>     I see that draft-ietf-netconf-subscribed-notifications (section 2.4.6)
>     admonishes us to check for transport-layer errors (and ACLs!) before
>     RPC-level errors; is the text here about "fails to serve the RPC
>     request" and our description of error handling consistent with the
>     separate transport-layer error handling?  (I think it can be, with a
>     careful reading of "one of the reasons indicated in [] Section 2.4.6",
>     but perhaps other readings are possible.)
>  Yes this section is for RPC-level errors, it references 2.4.6 of subscribed-notifications which provided a list of possible errors.

Thanks for checking.

>           The yang-data included within "error-info" SHOULD NOT include the
>           optional leaf "error-reason", as such a leaf would be redundant
>           with information that is already placed within the
>           "error-app-tag".
>     
>     I'm not sure where this "error-reason" leaf is defined -- I don't see it
>     in any of subscribed-notifications, yang-push, or RFC 8040.
> Good catch,  I think this should be "reason" from yang-push, will check.    

Thanks; it's good to know there's probably a reason why I was confused :)

>     Section 3.4
>     
>     I'm not sure that I've previously encountered using the section heading
>     to introduce an acronym (as is done here for SSE).  I bet the RFC Editor
>     will do the right thing, though.
>  I'll move the acronym to the section text
>     
>        o  In addition to an RPC response for a "modify-subscription" RPC
>           traveling over (a), a "subscription-modified" state change
>           notification MUST be sent within (b).  This allows the receiver to
>           know exactly when the new terms of the subscription have been
>           applied to the notification messages.  See arrow (c).
>     
>     nit: I might suggest some language about "order within the notifications
>     stream" for this state change, but that's purely editorial.
>  So you would like this text changed to clarify the order of events?

If I was writing it, I'd say "allows the receiver to know exactly when,
within the stream of events, the new terms of the subscription have been
applied [...]".  But you're writing it, not me, so my opinion doesn't count
for much.

>        o  In addition to any required access permissions (e.g., NACM), RPCs
>           modify-subscription, resync-subscription and delete-subscription
>           SHOULD only be allowed by the same RESTCONF username [RFC8040]
>           which invoked establish-subscription.
>     
>     I'm confused about this "SHOULD" (the secdir reviewer noted it as well)
>     -- in my understanding, the core subscribed-notifications requires that
>     such RPCs must be done on the same transport connection as the one used
>     to create a dynamic subscription (i.e., line (a) in Figure 1), and since
>     RFC 8040 authenticated client identities are at the connection level,
>     there could never be any change of username across the calls.
>  What you describe above is true for netconf (all done on same session. 
> However restconf doesn't work the same way (no long-lived sessions), so subsequent RPCs could actually be on a different transport connection.
> I do recall the secdir comments and your comments to my response, I will include the text you had suggested to justify the SHOULD.

Thanks.

>        o  Loss of TLS heartbeat
>     
>     (As noted above, this is under-specified at present.)
>     
>     Section 9
>     
>     I would suggest also recommending that the 'uri' values not have a
>     predictable structure or be guessable.  While we do have solid access
>     control in place via NACM/etc., there is still a risk of side-channel
>     leakage if there's a distinction between "resource does not exist" and
>     "not authorized".  (FYI we had a long discussion about unguessable URIs
>     in the context of draft-ietf-acme-acme, which had a much weaker
>     access-control story and could in some sense be said to use "capability
>     URIs", if anyone wants to do some background reading.)
>     (One might see also draft-gont-numeric-ids-sec-considerations.)
>  Section 9 says "The subscription URI is implementation specific ...". I can add text, as you suggested, to recommend that the uri values not be predictable.

Please do -- I think this is easy to do and improves the robustness of the
system, so we should recommend implementations to do it even if there's not
a strict functional requirement to do so.

>     I see that the subscription-id type is only of type uint32 in
>     draft-ietf-netconf-subscribed-notifications, which to some extent limits
>     the unguessability property to the URIs and not as much for the IDs
>     themselves (though randomization within a 32-bit space is not without
>     value).
>     
>     Appendix A
>     
>     Consistent with my suggestion in the Security Considerations, I'd change
>     the returned URI here or at least note that the "22", "23", etc. are
>     placeholders and not indicative of expected usage.
>  I will add a note.

Thanks!

-Ben

>     (This snippet from A.1.1)
>     
>        {
>           "ietf-subscribed-notifications:input": {
>              "stream-xpath-filter": "/example-module:foo/",
>              "stream": "NETCONF",
>              "dscp": "10"
>           }
>        }
>     
>     The ambiguity of "10" has been noted elsewhere, but since it's a uint8
>     (range "0..63") wouldn't it be a JSON number, not a JSON string?
>  You are correct, will change to 10
>     
>     Similarly, subscription IDs are uint32, which IIUC gets encoded as a
>     number.
>  Correct again.    
>     
> Regards,
> Reshad.
> 


From nobody Wed May 15 11:04:17 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC112047D; Wed, 15 May 2019 11:04:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-netconf-event-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <155794345628.30726.16513916652364715189.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 11:04:16 -0700
Archived-At: 
Subject: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 18:04:16 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-netconf-event-notifications-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 6

   Notification messages transported over the NETCONF protocol MUST be
   encoded in a  message as defined within [RFC5277],
   Section 4.  And per [RFC5277]'s "eventTime" object definition, the
   "eventTime" populated with the event occurrence time.

nit: I think the last sentence is actually a sentence fragment.

Section 7

This "Either it will correspond to [...] Or this 'error-tag' will
correspond to [...]" seems to preclude future extensions; do we want to
add some weakening language like "for the mechanisms specified in this
document"?

                                                  The specific identity
      to use depends on the RPC for which the error occurred.  Each
      error identity will be inserted as the "error-app-tag" following
      the form :.  An example of such as valid
      encoding would be "ietf-subscribed-notifications:no-such-
      subscription".  Viable errors for different RPCs are as follows:

            RPC                     use base identity
            ----------------------  ----------------------------
            establish-subscription  establish-subscription-error
            modify-subscription     modify-subscription-error
            delete-subscription     delete-subscription-error
            kill-subscription       delete-subscription-error
            resync-subscription     resync-subscription-error

This is probably just my lack of familiarity with the protocol, but the
text doesn't do much to indicate how the "base identity" concept in the
table corresponds to the ":" syntax or the
specific example given.  I think that this just means that the
 must be of the base type or derived from it, so maybe
"derive from" or "have" instead of "use" in the table heading would be
more clear.

      The yang-data included within "error-info" SHOULD NOT include the
      optional leaf "error-reason", as such a leaf would be redundant
      with information that is already placed within the
      "error-app-tag".

I'm not sure where this "error-reason" leaf is defined -- I don't  see
it in any of subscribed-notifications, yang-push, or RFC 6241.

Section 8

                                                                     The
   publisher MAY also suspend or terminate a subset of the active
   subscriptions on that NETCONF session.

I'd suggest saying/repeating why the publisher might do this, i.e., "MAY
also suspend or terminate [...], in order to reclaim resources and
preserve normal operation for the other subscriptions."

Appendix A.2

I'd suggest adding a note that the "id" values of 22, 23, and 39 are
just examples, and that actual values may not be small integers (akin to
my comment on the RESTCONF document).



From nobody Wed May 15 11:59:23 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BF1120728; Wed, 15 May 2019 11:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FkFPSP75qvLX; Wed, 15 May 2019 11:59:16 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 3696E1201BE; Wed, 15 May 2019 11:59:16 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([108.28.104.68]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1Mowvi-1gtZWh413W-00qRbt;  Wed, 15 May 2019 20:59:14 +0200
From: "Alexander Clemm" 
To: "'Benjamin Kaduk'" 
Cc: "'The IESG'" , , , 
References: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com> <043c01d50ac9$7099a780$51ccf680$@clemm.org> <20190515145945.GD14483@kduck.mit.edu>
In-Reply-To: <20190515145945.GD14483@kduck.mit.edu>
Date: Wed, 15 May 2019 11:59:11 -0700
Message-ID: <052101d50b50$49cbf450$dd63dcf0$@clemm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ3PF2dFB47j2Iq/ZH31Feu7eo0twH9HjRjAiM3vTWlBxuWYA==
Content-Language: en-us
X-Provags-ID: V03:K1:4EojyIqcEp3NEWEdyvwJsWaB3AYZr4KRGuZgpw3KYAEm6rXSqOI mKjOPPHrXGZ7kRHP+Eo6iCeNubXoOJwuCQgfe1kJyPjCOhBPt33fwRFm0NvAGrdjXAIbogQ 3Jh7CaKIgsa+/31vqaT8l67gQoWYrP9ufc9ljCG3/dB5lNYhW9BaGP7wSnSGFvATpF9diEG 9vuq9oEk9/V39on6py/YA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:LfkoDdGKCBY=:26vvL1Nd42FbbMYzI2pRp5 +7XnAaHT+eQw21TL6oGlQX1kn8uPB7HQutyN7zYSa5LRN1lrxdFS8qSKKSVl54aMscCWHmE7n RFX2LvKUHK0WqBA7VaaYUGtctPNsdclZ4NIdXRNPg0zDmHOCBzh43yzFl0KXnfUNBeclZawVX xB28/p581HgTKxmoDS55dpgZpIyRSxZHAF6mOkkEl6YzSUnK+LDy770Tno8NuR1RgvPWhwkIZ S3gKBd1c8DwCuPWLWOeBJkpV+z2HrihmxxhDtU3G4AN4Y0Vv1QTs8Oy6gyeEewRAKVPEZx985 mHGklq41CnXvaJDhBtPZfQwRomY2/qRXrQxn+eHPEirMrjw8j973m2fJS3WRtv855o1IOAbdv 08E/3ugFyPPLif2UvNfMo4WXUtN35YtK81jTgWAc9Ltv+6Viz/wSOus5L5fIZUNqpvxyr1HF9 42/FQlgF+Zgk1NR3py5K6PiVVAQF+nLtlifEZeFKdP5d+jvRYH1anil9WMCd+TCeihcMmyOqB VwowC8/xQ9Q/nghepmWpnoBPzNr49f0z3SgiiqZ3j9cNC7c/gZ+vbjVdeeON5hrAERmnVAGWV MD1gjmy2xREUHlxPhbWtgPrNpRsW2mIy92k5NCvHiOox3cEOgop+M4PzdvB2YFLDBtX7Aa5ms 1REpXophKkauHWzLFChtFnlkxlzR3fiVcsNITtrwukVeqbid+S0OYUd6SbmW5kkTLKk1S/3/O CN6+KL/IbKrbpbuRufXYbfNovK+6dxOAIGALi0cAzcp58BvcwL59l8FJPFw=
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 18:59:21 -0000

Hi, 
Responses inline, 
Thanks
--- Alex

-----Original Message-----
From: Benjamin Kaduk  
Sent: Wednesday, May 15, 2019 8:00 AM
To: Alexander Clemm 
Cc: 'The IESG' ; netconf@ietf.org;
draft-ietf-netconf-yang-push@ietf.org; netconf-chairs@ietf.org
Subject: Re: [netconf] Benjamin Kaduk's Discuss on
draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)

On Tue, May 14, 2019 at 07:53:52PM -0700, Alexander Clemm wrote:
> Hi Benjamin,
> 
> Thank you for your review!  Replies inline, .  Update will be 
> reflected in -24, to be posted shortly.
> 
> --- Alex
> 
> -----Original Message-----
> From: netconf  On Behalf Of Benjamin Kaduk 
> via Datatracker
> Sent: Wednesday, May 1, 2019 12:08 PM
> To: The IESG 
> Cc: netconf@ietf.org; draft-ietf-netconf-yang-push@ietf.org;
> netconf-chairs@ietf.org
> Subject: [netconf] Benjamin Kaduk's Discuss on
> draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netconf-yang-push-23: Discuss
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Note that I reviewed the -22 and the current version is -23.  Briefly 
> skimming the diff, it seems that some changes touch on points I make 
> in my review, but there is probably still discussion to have on them.
> 
> (pro-forma) I see the GenArt reviewer noted the author count (seven) 
> already, but I couldn't find a response or note in the ballot or 
> shephert writeup acknowledging this.  So failing that, I'll put up a 
> discuss point until the responsible AD says it's fine.
> 
> [See also discussion on draft-ietf-netconf-subscribed notifications 
> about the pre-RFC5378 boilerplate and whether or not it can be removed 
> from this document]
> 
>  Several of the authors have graciously agreed to step down and 
> be listed as contributors. 

Thanks to them!

> Section 3.3 states:
> 
>             In order for a subscriber to determine whether objects
>    support on-change subscriptions, objects are marked accordingly on a
>    publisher.  Accordingly, when subscribing, it is the responsibility
>    of the subscriber to ensure it is aware of which objects support on-
>    change and which do not.  For more on how objects are so marked, see
>    Section 3.10.
> 
> Chasing the reference, we see that this marking is left for future 
> work or implementation-specific usage.  I'm not very comfortable with 
> the way we are describing this situation, as it seems pretty fragile 
> in the face of different implementations trying to interoperate.
> 
>  The working group decided to pull this item out of this draft.  
> It is being addressed in draft-ietf-netconf-notification-capabilities
> (https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capa
> biliti
> es/) 

I guess I'll see what the -24 looks like, but I'm not sure yet whether "pull
this item out of the draft" is describing a previous decision that left it
in this state or a current decision starting from this state.  (The latter
would seem to make more sense to me, but I can wait and see.)

 To give a bit of history, in a set of earlier revisions we did
describe a mechanism for this.  There was quite a bit of discussion around
this and various options were considered, from introducing a YANG extension
(see e.g. rev 12 section 3.10) to the mechanism that is now described in the
separate draft.  There were also discussions whether such mechanism should
be generalized further - for example, what if you wanted to express not only
whether an item supports on-change subscriptions, but wants to give an
indication of the "size" of the change?  The WG ultimately decided to not
overburden the draft and slow progress down further and address this item
separately.  There was also at some point discussion about keeping it
simpler and take an all-or-nothing approach (require a server to either
support on-change for all objects or none), which however was deemed to be
too restrictive and we did want to allow for the possibility of a
differentiated approach. 
Bottom line, I would like to ask please accept the previous decision.   
   

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the very thoughtful document!  I've lost track of the 
> number of places where I started writing a comment only to note that 
> my concern had already been addressed in the following text.  In 
> general the writing style is great, though I did find some grammar and
clarity nits (noted inline).
> 
> Abstract
> 
>                Providing such visibility into updates enables new
>    capabilities based on the remote mirroring and monitoring of
>    configuration and operational state.
> 
> This phrasing ("new capabilities based on") is hard for me to follow, 
> particularly about whether these are protocol-level capabilities and 
> what actors are granted the new capabilities.
> 
>  The capabilities are clearly not related to protocol-level 
> capabilities, but capabilities for applications that have uses for 
> information obtained from YANG datastores.  If it's okay, at this 
> point we would like to keep it as-is. 

It's your prerogative to keep it as-is, though the RFC Editor may also take
a crack at the wording.

 Sure.  Kept as is for now. 

> Section 1
> 
>    Traditional approaches to providing visibility into managed entities
>    from remote have been built on polling.  [...]
> 
> nit: "remote" is an adjective and needs a noun to bind to; "from 
> remote systems", "from remote vantages", or "from afar" would all be 
> fine wordings here.
> 
>  changed to  "from a remote system".  
> 
>    o  Polling incurs significant latency.  This latency prohibits many
>       application types.
> 
> nit: I'd suggest wording as "types of application", since on my first 
> reading I thought this was referring to some sort of codepoint.
> 
>  changed 
> 
>    o  Polling cycles may be missed, requests may be delayed or get lost,
>       often when the network is under stress and the need for the data
>       is the greatest.
> 
> nit: the grammar is a bit weird, here, as if a comma splice.  I think 
> replacing the first comma with a colon or em dash would suffice.
> 
>  replaced first comma with "and", to read: "Polling cycles may 
> be missed and requests may be delayed or get lost, often when the 
> network is under stress and the need for the data is the greatest." 
> 

Thanks!

>    o  Datastore node update: A data item containing the current value of
>       a datastore node at the time the datastore node update was
>       created, as well as the path to the datastore node.
> 
> Is this storing the "new" or the "old" value as the "current value"?
> 
>  I don't understand the question.  I think the statement is 
> clear.

This sounds like it's conceptually "take a copy of some data as you make an
update it, to have a historical record of what changed".  I mostly assume
that the copy operation happens before the update, so the old/previous value
is recorded in the record, but the text seems to describe them happening at
the same time, without a specified ordering between them.
(That said, IIRC, there is some text later in the document that helps
clarify the intent, but that is not a free pass for leaving things unclear
here.)

 I think you are misreading this. There is no update action or copy
operation that is being applied to a datastore node.  No operation or action
is mentioned.  Instead, as the definition says, this is merely a data item
which can be put into the stream of push update notifications.   


> Section 3.1
> 
>          +  Dampening period: In an on-change subscription, detected
>             [...]
>             is included.  The dampening period goes into effect every
>             time an update record completes assembly.
> 
> Just to double-check: this means that after a long hiatus, the first 
> change to the monitored subtree(s) triggers an immediate push with 
> just the single update, and only then does the dampening period kick 
> in and defer delivery of potential subsequent updates?
> 
>  Yes, this is correct 
> 
> Section 3.5.2
> 
> This bit about the "create" and "delete" errors from RFC 8072 Section
> 2.5 not being errors in our usage is a little interesting, process-wise.
> In one sense, we are changing the semantics of an already published 
> RFC, and would need to apply an "Updates:" relationship to indicate 
> that, but in the other sense we are building a new custom thing that 
> reuses a lot of the syntax/semantics of YANG patch but is 
> fundamentally a new
> (different) thing.  The phrasing we use to talk about it can affect 
> which case the reader perceives us to be in...
> 
> The discussion on the "change-type" enumeration seems to pretty 
> clearly place us in the latter case, which is good.
> 
>  Keeping this as is. 
> 
> Section 3.6
> 
> Thank you for the note about the power of XPath expressions and the 
> duty of the receiver to understand what it's asking for -- that sort 
> of statement would potentially even be appropriate in the Security 
> Considerations (but is fine where it is)!
> 
>  Keeping this as is.  
> 
> Section 3.7
> 
>    Of note in the above example is the 'patch-id' with a value of '0'.
>    Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG
>    Push, the publisher SHOULD put into the 'patch-id' a counter starting
>    at '0' which increments with every 'push-change-update' generated for
>    a subscription.  If used as a counter, this counter MUST be reset to
>    '0' anytime a resynchronization occurs (i.e., with the sending of a
>    'push-update').  Also if used as a counter, the counter MUST be reset
>    to '0' after passing a maximum value of '4294967295' (i.e. maximum
>    value that can be represented using uint32 data type).  Such a
>    mechanism allows easy identification of lost or out-of-sequence
>    update records.
> 
> It's not really clear to me how much value there is in this counter 
> mechanism if the client' can't rely on the server's behavior actually 
> being to use a counter (the requirement is only "SHOULD").  Can this be a
"MUST"
> (or maybe "MUST excpet when [...]") instead?
> 
>  Would prefer to not introduce no MUST requirements at this 
> point and keep this as a SHOULD.  

This is only a non-blocking comment, so go ahead.

 Thank you 

> Section 3.9
> 
>                                                           Empty "push-
>    change-update" messages (in case of an on-change subscription) MUST
>    NOT be sent.  This is required to ensure that clients cannot
>    surreptitiously monitor objects that they do not have access to via
>    carefully crafted selection filters.  By the same token, changes to
>    objects that are filtered MUST NOT affect any dampening intervals.
> 
> I appreciate this attention to security-relevant detail; thank you!
> 
>  thanks! 
> 
> Section 3.11.1
> 
> Do we want to give any guidance for the "incomplete-update" case about 
> whether a subscriber should wait and give the publisher a chance to 
> provide a full "push-update" for resynchronization (per Section 4.3.2) 
> versus perform a normal query for the datastore contents and 
> effectuating its own resynchronization?
> 
>  This should be up to the subscriber to decide, and what to do 
> may differ for different applications.  In some instances, it can 
> afford to simply wait; in other cases or when specifically interested 
> in one particular closely-monitored item it may decide not to and sync
immediately.
> 

Okay.

> Section 4
> 
>    o  For on-change subscriptions, assuming any dampening period has
>       completed, triggering occurs whenever a change in the subscribed
>       information is detected.  On-change subscriptions have more
>       complex semantics that is guided by its own set of parameters:
> 
> nit: singular/plural mismatch "semantics"/"is"
> 
>  changed to "On-change subscriptions have more complex semantics 
> that are guided by their own set of parameters" 
> 
> Section 4.3.2
> 
> 
>    A "time-of-update" which represents the time an update record
>    snapshot was generated.  A receiver MAY assume that at this point in
>    time a publisher's objects have the values that were pushed.
> 
> nit: I think "had the values" (past tense) is more appropriate.
> 
>  changed 
> 
> Section 4.4.1
> 
>    a publisher that cannot serve on-change updates but periodic updates
>    might return the following NETCONF response:
> 
> nit: "but can serve periodic updates"
> 
>  changed 
> 
> Section 4.4.2
> 
>    The specific parameters to be returned in as part of the RPC error
>    response depend on the specific transport that is used to manage the
>    subscription.  For NETCONF, those parameters are specified in
>    [I-D.draft-ietf-netconf-netconf-event-notifications].
> 
> nit: "in" and "as part of" are redundant.
> 
>  removed "in" 
> 
> Section 5
> 
> It is slightly interesting to note that (apparently) the 
> update-policy-modifiable grouping allows for a subscription to switch 
> between periodic and triggered at runtime (by virtue of wanting a 
> single grouping to cover all the cases and needing to be able to 
> modify the parameters for each case).  I would mostly expect 
> implementations to deny such modification requests due to the needed 
> complexity, but I'm also not sure that there's a need to mention this
explicitly in the document.
> 
>   I think it is implied that a modification request can always 
> be denied if not supported by a server.  At the same time, clearly in 
> general you would not change between on-change and periodic.  Keeping 
> as is. 
> 
>             leaf period {
>               type centiseconds;
>               mandatory true;
>               description
>                 "Duration of time which should occur between periodic
>                  push updates, in one hundredths of a second.";
> 
> It would probably be okay to skip "in one hundredths of a second" 
> given the usage of the centiseconds typedef.
> 
>  doesn't hurt to be explicit; keeping as is 
> 
>     rc:yang-data resync-subscription-error {
>       container resync-subscription-error {
>         description
>           "If a 'resync-subscription' RPC fails, the subscription is
>            not resynced and the RPC error response MUST indicate the
>            reason for this failure.  This yang-data MAY be inserted as
>            structured data within a subscription's RPC error response
>            to indicate the failure reason.";
> 
> It's a little weird to have the normative language here constraining 
> the RPC error response that must be returned for a specific RPC, since 
> this is not the description of that RPC.  (It's probably also 
> duplicating langauge elsewhere but I didn't double-check.)
> 
>  Keeping as is since it is clear what is happening.  Note that 
> there are limitations to the RPC semantics you can formally define in 
> YANG, hence the description. 
> 
>     rc:yang-data establish-subscription-datastore-error-info {
>       container establish-subscription-datastore-error-info {
>         description
>           "If any 'establish-subscription' RPC parameters are
>            unsupportable against the datastore, a subscription is not
>            created and the RPC error response MUST indicate the reason
>            why the subscription failed to be created.  This yang-data
>            MAY be inserted as structured data within a subscription's
>            RPC error response to indicate the failure reason.  This
>            yang-data MUST be inserted if hints are to be provided back
>            to the subscriber.";
> 
> (ditto)
> 
> Contrast to modify-subscription-datastore-error-info, which only has 
> normative language about the yang-data being described and not the 
> RPCs that
> (might) use it.
> 
>  Would keep as is.  I think the semantics are clear.  

You can certainly keep it as-is and I won't complain further; I just want to
note that my complaint was not "the semantics are unclear if I read the
whole document" but rather "the semantics are described in a different place
than a naive reader might expect".  Yes, the reader is generally going to
have to look up the description of the data types involved in the RPC as
well as the RPC description itself to actually use it, but I can imagine
some cases where that doesn't work as well as it could.

 Thanks; your comment is well taken and I understand where you are
coming from but let's keep it then. 
> nit: push-update and push-change-update use different langauge about 
> "does not constitute a general-purpose notification" and I'm not sure 
> there's a reason to diverge.
> Their "incomplete-update" leaves also have divergent descriptions, but 
> I think that latter divergence is more reasonable.
> 
>  Updated the description of push-change-update to align this 
> part of the description of the notifications.  

Thanks!

-Ben

>     augment "/sn:subscription-modified/sn:target" {
>       [...]
>       case datastore {
>         uses datastore-criteria {
>           refine "selection-filter/within-subscription" {
>             description
>               "Specifies where the selection filter, and where it came
>                from within the subscription and then populated within
>                this notification.  If the 'selection-filter-ref' is
> 
> nit: "where the selection filter" seems like an incomplete clause.
> 
>  Updating this to  "Specifies the selection filter and where it 
> originated  from.  If the 'selection-filter-ref' is ...".  This way, 
> the description also aligns better with the augment to 
> sn:subscription-started/sn:target.  
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Wed May 15 12:02:11 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CA01207E0; Wed, 15 May 2019 12:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DZm7cXs_j4H; Wed, 15 May 2019 12:02:03 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5531207B0; Wed, 15 May 2019 12:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6388; q=dns/txt; s=iport; t=1557946922; x=1559156522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lAK7PicURoknmG600LZxmUoYmkA1oimezwAjvKmelZg=; b=QVc4nzF179Iaw2DFuWf79s4ircxTxPjZmYRKdslPq1WwwLIlP6GOOTPl hPC64q9ZU2vbzcOnpxMjFPy8SZwBD8rWPSVnz9wzQYvMYlC9iF9guJGFG DfBuoheEOIHPXMWsOFAA3N79sObFvvz51thS1tZimj6r0CIXgLdgBzeG1 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAAAWYdxc/5ldJa1bCQ4OAQEBBAE?= =?us-ascii?q?BBwQBAYFRBwEBCwGBZippVDAoCoQHiByMd5hTFIFnCQEBAQwBASUKAQGEQAI?= =?us-ascii?q?XghQjNAkOAQMBAQQBAQIBBG0cDIVKAQEBAwEjEUMCBQsCAQgVBQIJFgcCAgI?= =?us-ascii?q?wFRACBAENDYJPSwGBew8PrEeBL4RGQYUlBoELKAGLTheBQD+BEYMSPoJhAgE?= =?us-ascii?q?CAYEqAQgKAYMpglgEiyGCO4xjjRoJAoIJhiGEOod7I4IUhkyNDoMgiRSBIoU?= =?us-ascii?q?2jjICERWBMB84ZlgRCHAVgyeCRohMhQQ7QTEBjhwPFwOBCIEhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,473,1549929600"; d="scan'208";a="563193909"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2019 19:01:59 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x4FJ1xas028472 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2019 19:01:59 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 May 2019 15:01:59 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 15 May 2019 15:01:58 -0400
From: "Eric Voit (evoit)" 
To: Benjamin Kaduk , The IESG 
CC: "draft-ietf-netconf-netconf-event-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
Thread-Index: AQHVC0issmRKZA7PmESHWaRaGNgVg6ZsgKHQ
Date: Wed, 15 May 2019 19:01:58 +0000
Message-ID: <17b8294694a446679f786fee28e4e206@XCH-RTP-013.cisco.com>
References: <155794345628.30726.16513916652364715189.idtracker@ietfa.amsl.com>
In-Reply-To: <155794345628.30726.16513916652364715189.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 19:02:11 -0000

VGhhbmtzIGZvciB0aGUgcmV2aWV3IEJlbmphbWluLiAgU29tZSB0aG91Z2h0cyBpbi1saW5lLiAg
SSB3aWxsIHBvc3QgdGhlIGNvcnJlc3BvbmRpbmcgdXBkYXRlIHNvb24uDQoNCj4gRnJvbTogQmVu
amFtaW4gS2FkdWssIE1heSAxNSwgMjAxOSAyOjA0IFBNDQo+IA0KPiBCZW5qYW1pbiBLYWR1ayBo
YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0
Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9ucy0yMDogTm8gT2JqZWN0aW9uDQo+
IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0
IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh
bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFn
cmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3Lmll
dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBp
bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiAN
Cj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj
YW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9ucy8NCj4gDQo+IA0KPiAN
Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBTZWN0
aW9uIDYNCj4gDQo+ICAgIE5vdGlmaWNhdGlvbiBtZXNzYWdlcyB0cmFuc3BvcnRlZCBvdmVyIHRo
ZSBORVRDT05GIHByb3RvY29sIE1VU1QgYmUNCj4gICAgZW5jb2RlZCBpbiBhIDxub3RpZmljYXRp
b24+IG1lc3NhZ2UgYXMgZGVmaW5lZCB3aXRoaW4gW1JGQzUyNzddLA0KPiAgICBTZWN0aW9uIDQu
ICBBbmQgcGVyIFtSRkM1Mjc3XSdzICJldmVudFRpbWUiIG9iamVjdCBkZWZpbml0aW9uLCB0aGUN
Cj4gICAgImV2ZW50VGltZSIgcG9wdWxhdGVkIHdpdGggdGhlIGV2ZW50IG9jY3VycmVuY2UgdGlt
ZS4NCj4gDQo+IG5pdDogSSB0aGluayB0aGUgbGFzdCBzZW50ZW5jZSBpcyBhY3R1YWxseSBhIHNl
bnRlbmNlIGZyYWdtZW50Lg0KDQpUaGlzIHJlYWRzIGZpbmUgd2l0aCBtZS4gIFNldmVyYWwgb24t
bGluZSBncmFtbWFyIGNoZWNrcyBnaXZlIGl0IGEgcGFzcywgYnV0IEkgYW0gbm90IHN1cmUgaG93
IG11Y2ggSSB0cnVzdCB0aG9zZSB0b29scy4gIFNvIEkgd2lsbCBsZWF2ZSBhcyBpcy4NCg0KPiBT
ZWN0aW9uIDcNCj4gDQo+IFRoaXMgIkVpdGhlciBpdCB3aWxsIGNvcnJlc3BvbmQgdG8gWy4uLl0g
T3IgdGhpcyAnZXJyb3ItdGFnJyB3aWxsIGNvcnJlc3BvbmQgdG8gWy4uLl0iDQo+IHNlZW1zIHRv
IHByZWNsdWRlIGZ1dHVyZSBleHRlbnNpb25zOyBkbyB3ZSB3YW50IHRvIGFkZCBzb21lIHdlYWtl
bmluZw0KPiBsYW5ndWFnZSBsaWtlICJmb3IgdGhlIG1lY2hhbmlzbXMgc3BlY2lmaWVkIGluIHRo
aXMgZG9jdW1lbnQiPw0KDQpXb3JrcyBmb3IgbWUsIG5vdyBzYXlzLi4uDQoNCkZvciB0aGUgbWVj
aGFuaXNtcyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgdGhpcyAiZXJyb3ItdGFnIiB3aWxs
IGNvbWUgZnJvbSBvbmUgb2YgdHdvIHBsYWNlcy4uLi4NCiANCj4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgc3BlY2lmaWMgaWRlbnRpdHkNCj4g
ICAgICAgdG8gdXNlIGRlcGVuZHMgb24gdGhlIFJQQyBmb3Igd2hpY2ggdGhlIGVycm9yIG9jY3Vy
cmVkLiAgRWFjaA0KPiAgICAgICBlcnJvciBpZGVudGl0eSB3aWxsIGJlIGluc2VydGVkIGFzIHRo
ZSAiZXJyb3ItYXBwLXRhZyIgZm9sbG93aW5nDQo+ICAgICAgIHRoZSBmb3JtIDxtb2R1bGVuYW1l
Pjo8aWRlbnRpdHluYW1lPi4gIEFuIGV4YW1wbGUgb2Ygc3VjaCBhcyB2YWxpZA0KPiAgICAgICBl
bmNvZGluZyB3b3VsZCBiZSAiaWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6bm8tc3VjaC0N
Cj4gICAgICAgc3Vic2NyaXB0aW9uIi4gIFZpYWJsZSBlcnJvcnMgZm9yIGRpZmZlcmVudCBSUENz
IGFyZSBhcyBmb2xsb3dzOg0KPiANCj4gICAgICAgICAgICAgUlBDICAgICAgICAgICAgICAgICAg
ICAgdXNlIGJhc2UgaWRlbnRpdHkNCj4gICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgICAgICBlc3RhYmxpc2gt
c3Vic2NyaXB0aW9uICBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uLWVycm9yDQo+ICAgICAgICAgICAg
IG1vZGlmeS1zdWJzY3JpcHRpb24gICAgIG1vZGlmeS1zdWJzY3JpcHRpb24tZXJyb3INCj4gICAg
ICAgICAgICAgZGVsZXRlLXN1YnNjcmlwdGlvbiAgICAgZGVsZXRlLXN1YnNjcmlwdGlvbi1lcnJv
cg0KPiAgICAgICAgICAgICBraWxsLXN1YnNjcmlwdGlvbiAgICAgICBkZWxldGUtc3Vic2NyaXB0
aW9uLWVycm9yDQo+ICAgICAgICAgICAgIHJlc3luYy1zdWJzY3JpcHRpb24gICAgIHJlc3luYy1z
dWJzY3JpcHRpb24tZXJyb3INCj4gDQo+IFRoaXMgaXMgcHJvYmFibHkganVzdCBteSBsYWNrIG9m
IGZhbWlsaWFyaXR5IHdpdGggdGhlIHByb3RvY29sLCBidXQgdGhlIHRleHQgZG9lc24ndA0KPiBk
byBtdWNoIHRvIGluZGljYXRlIGhvdyB0aGUgImJhc2UgaWRlbnRpdHkiIGNvbmNlcHQgaW4gdGhl
IHRhYmxlIGNvcnJlc3BvbmRzIHRvDQo+IHRoZSAiPG1vZHVsZW5hbWU+OjxpZGVudGl0eW5hbWU+
IiBzeW50YXggb3IgdGhlIHNwZWNpZmljIGV4YW1wbGUgZ2l2ZW4uICBJDQo+IHRoaW5rIHRoYXQg
dGhpcyBqdXN0IG1lYW5zIHRoYXQgdGhlIDxpZGVudGl0eW5hbWU+IG11c3QgYmUgb2YgdGhlIGJh
c2UgdHlwZSBvcg0KPiBkZXJpdmVkIGZyb20gaXQsIHNvIG1heWJlICJkZXJpdmUgZnJvbSIgb3Ig
ImhhdmUiIGluc3RlYWQgb2YgInVzZSIgaW4gdGhlIHRhYmxlDQo+IGhlYWRpbmcgd291bGQgYmUg
bW9yZSBjbGVhci4NCg0KV29ya3MgZm9yIG1lLiAgQ2hhbmdlZCAidXNlIiB0byAiaGF2ZSIuDQog
DQo+ICAgICAgIFRoZSB5YW5nLWRhdGEgaW5jbHVkZWQgd2l0aGluICJlcnJvci1pbmZvIiBTSE9V
TEQgTk9UIGluY2x1ZGUgdGhlDQo+ICAgICAgIG9wdGlvbmFsIGxlYWYgImVycm9yLXJlYXNvbiIs
IGFzIHN1Y2ggYSBsZWFmIHdvdWxkIGJlIHJlZHVuZGFudA0KPiAgICAgICB3aXRoIGluZm9ybWF0
aW9uIHRoYXQgaXMgYWxyZWFkeSBwbGFjZWQgd2l0aGluIHRoZQ0KPiAgICAgICAiZXJyb3ItYXBw
LXRhZyIuDQo+IA0KPiBJJ20gbm90IHN1cmUgd2hlcmUgdGhpcyAiZXJyb3ItcmVhc29uIiBsZWFm
IGlzIGRlZmluZWQgLS0gSSBkb24ndCAgc2VlIGl0IGluIGFueSBvZg0KPiBzdWJzY3JpYmVkLW5v
dGlmaWNhdGlvbnMsIHlhbmctcHVzaCwgb3IgUkZDIDYyNDEuDQoNCkdvb2QgY2F0Y2guICBJdCBu
b3cgcmVhZHMgInJlYXNvbiIuICAoV2UgcmVuYW1lZCB0byBvYmplY3QgImVycm9yLXJlYXNvbiIg
dG8gInJlYXNvbiIgYSBmZXcgZG9jdW1lbnQgaXRlcmF0aW9ucyBhZ28uKQ0KDQo+IFNlY3Rpb24g
OA0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgVGhlDQo+ICAgIHB1Ymxpc2hlciBNQVkgYWxzbyBzdXNwZW5k
IG9yIHRlcm1pbmF0ZSBhIHN1YnNldCBvZiB0aGUgYWN0aXZlDQo+ICAgIHN1YnNjcmlwdGlvbnMg
b24gdGhhdCBORVRDT05GIHNlc3Npb24uDQo+IA0KPiBJJ2Qgc3VnZ2VzdCBzYXlpbmcvcmVwZWF0
aW5nIHdoeSB0aGUgcHVibGlzaGVyIG1pZ2h0IGRvIHRoaXMsIGkuZS4sICJNQVkgYWxzbw0KPiBz
dXNwZW5kIG9yIHRlcm1pbmF0ZSBbLi4uXSwgaW4gb3JkZXIgdG8gcmVjbGFpbSByZXNvdXJjZXMg
YW5kIHByZXNlcnZlIG5vcm1hbA0KPiBvcGVyYXRpb24gZm9yIHRoZSBvdGhlciBzdWJzY3JpcHRp
b25zLiINCg0KU3VnZ2VzdGVkIHRleHQgYWRvcHRlZC4NCg0KPiBBcHBlbmRpeCBBLjINCj4gDQo+
IEknZCBzdWdnZXN0IGFkZGluZyBhIG5vdGUgdGhhdCB0aGUgImlkIiB2YWx1ZXMgb2YgMjIsIDIz
LCBhbmQgMzkgYXJlIGp1c3QgZXhhbXBsZXMsDQo+IGFuZCB0aGF0IGFjdHVhbCB2YWx1ZXMgbWF5
IG5vdCBiZSBzbWFsbCBpbnRlZ2VycyAoYWtpbiB0byBteSBjb21tZW50IG9uIHRoZQ0KPiBSRVNU
Q09ORiBkb2N1bWVudCkuDQoNCldvcmtzIGZvciBtZS4gICBJIGFkZGVkIHRoZSBmb2xsb3dpbmcg
YXQgdGhlIHRvcCBvZiB0aGUgZXhhbXBsZXMgc2VjdGlvbjoNCiJBZGRpdGlvbmFsbHkgdGhlIHN1
YnNjcmlwdGlvbiAiaWQiIHZhbHVlcyBvZiAyMiwgMjMsIGFuZCAzOSB1c2VkIGJlbG93IGFyZSBq
dXN0IGV4YW1wbGVzLiBJbiBwcm9kdWN0aW9uLCB0aGUgYWN0dWFsIHZhbHVlcyBvZiAiaWQiIG1h
eSBub3QgYmUgc21hbGwgaW50ZWdlcnMuIg0KDQpUaGFua3MgYWdhaW4sDQpFcmljDQo=


From nobody Wed May 15 12:24:38 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64F11207EF; Wed, 15 May 2019 12:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DccFRvLCOhl; Wed, 15 May 2019 12:24:28 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08B11207D6; Wed, 15 May 2019 12:24:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3135; q=dns/txt; s=iport; t=1557948268; x=1559157868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BA+Pm5bARE4Lw36rqVqC6x/n8/RJdHLubDG1JkX0A/c=; b=HZ5ezXa5yyeBWsTew6C1/5S1VEwU1Jk10xT0TdM+TEZuKmBPdfsyVbMN +fF1iDiQJXx5mVHF+MHuIgW3CEF5LkW3yf5u28ziOp9bLjAgJix3oyj7A UAIeEZM53dFTWmsB/DKNtyLO/mEV1w/ctqyRYL6LcwXq+DC4Kv93HkL5M Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAABLZtxc/5RdJa1kDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVMEAQEBCwGCEGlUMDKZGphTgXsJAQEBDAEBIwwBAYRAAoIrIzY?= =?us-ascii?q?HDgEDAQEEAQECAQRtHAyFSgEBAQMBOjQLBQsCAQgOByEFCzIlAgQBDQ0Tgwi?= =?us-ascii?q?Bew8PrWKERkGFJAaBMwGLTheBQD+EIz6CYQICAQGBR4V4BIsPm2VlCQKCCYY?= =?us-ascii?q?hhDqHeyOCFIZMjQ6MNIZYjjICERWBMCYCL4FXcBU7gm2CGhcUgziFFIUEO0G?= =?us-ascii?q?Pf4EhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,473,1549929600"; d="scan'208";a="273219198"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2019 19:24:26 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x4FJOQZA001492 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2019 19:24:26 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 May 2019 15:24:25 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 15 May 2019 15:24:25 -0400
From: "Eric Voit (evoit)" 
To: Alexander Clemm , "'Benjamin Kaduk'" 
CC: "'The IESG'" , "netconf@ietf.org" , "draft-ietf-netconf-yang-push@ietf.org" , "netconf-chairs@ietf.org" 
Thread-Topic: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
Thread-Index: AQJ3PF2dFB47j2Iq/ZH31Feu7eo0twH9HjRjAiM3vTWlBxuWYIAADRrQ
Date: Wed, 15 May 2019 19:24:25 +0000
Message-ID: 
References: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com> <043c01d50ac9$7099a780$51ccf680$@clemm.org> <20190515145945.GD14483@kduck.mit.edu> <052101d50b50$49cbf450$dd63dcf0$@clemm.org>
In-Reply-To: <052101d50b50$49cbf450$dd63dcf0$@clemm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 19:24:37 -0000

> From: Alexander Clemm, May 15, 2019 2:59 PM
>

> > Section 3.3 states:
> >
> >             In order for a subscriber to determine whether objects
> >    support on-change subscriptions, objects are marked accordingly on a
> >    publisher.  Accordingly, when subscribing, it is the responsibility
> >    of the subscriber to ensure it is aware of which objects support on-
> >    change and which do not.  For more on how objects are so marked, see
> >    Section 3.10.
> >
> > Chasing the reference, we see that this marking is left for future
> > work or implementation-specific usage.  I'm not very comfortable with
> > the way we are describing this situation, as it seems pretty fragile
> > in the face of different implementations trying to interoperate.
> >
> >  The working group decided to pull this item out of this draft.
> > It is being addressed in draft-ietf-netconf-notification-capabilities
> > (https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capa
> > biliti
> > es/) 
>=20
> I guess I'll see what the -24 looks like, but I'm not sure yet whether "p=
ull this
> item out of the draft" is describing a previous decision that left it in =
this state or
> a current decision starting from this state.  (The latter would seem to m=
ake
> more sense to me, but I can wait and see.)
>=20
>  To give a bit of history, in a set of earlier revisions we did de=
scribe a
> mechanism for this.  There was quite a bit of discussion around this and =
various
> options were considered, from introducing a YANG extension (see e.g. rev =
12
> section 3.10) to the mechanism that is now described in the separate draf=
t.
> There were also discussions whether such mechanism should be generalized
> further - for example, what if you wanted to express not only whether an =
item
> supports on-change subscriptions, but wants to give an indication of the =
"size"
> of the change?  The WG ultimately decided to not overburden the draft and=
 slow
> progress down further and address this item separately.  There was also a=
t some
> point discussion about keeping it simpler and take an all-or-nothing appr=
oach
> (require a server to either support on-change for all objects or none), w=
hich
> however was deemed to be too restrictive and we did want to allow for the
> possibility of a differentiated approach.
> Bottom line, I would like to ask please accept the previous decision.
> 

To summarize how this played out in the WG
- there was a section dedicated to the solution within YANG push
- several WG members asked extract this solution in order to postpone final=
ization of the solution
- we extracted the section at the WG request
- a new draft with the solution was adopted by the WG.  See draft-ietf-netc=
onf-notification-capabilities
- implementers would be wise to use this draft

To get a brief glimpse on some of the details in the discussion history, yo=
u can look at=20
https://github.com/netconf-wg/yang-push/issues/10=20
There was also quite a bit on the mailing list.

Thanks,
Eric


From nobody Wed May 15 12:33:18 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6B12017C; Wed, 15 May 2019 12:33:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-netconf-event-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw 
Message-ID: <155794878921.30587.14812046146231301278.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 12:33:09 -0700
Archived-At: 
Subject: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 19:33:09 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-netconf-event-notifications-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

An easy to fix issue.

Section 8.  I agree with the brevity of this section as the more detailed
considerations can be found in [draft-ietf-netconf-subscribed-notifications].
[draft-ietf-netconf-subscribed-notifications] has a similar statement about
buggy subscribers, but also makes a SHOULD statement about operators monitoring
for odd behavior.  This text doesn’t include this monitoring recommendation but
does explicitly discuss terminating sessions.  Could the text in these two
sections please be reconciled. Perhaps with a reference such as:

“This document does not introduce additional Security Considerations for
dynamic subscriptions beyond those discussed in
[draft-ietf-netconf-subscribed-notifications].  In particular for NETCONF
subscribers … ”





From nobody Wed May 15 12:38:41 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3301200B1; Wed, 15 May 2019 12:38:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw 
Message-ID: <155794911377.30630.11830718567923683706.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 12:38:33 -0700
Archived-At: 
Subject: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 19:38:34 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per Section 9, [draft-ietf-netconf-netconf-event-notifications] and
[draft-ietf-netconf-subscribed-notifications] mention concerns about a
“malicious or buggy subscriber sends a number of establish-subscription
requests” in their Security Considerations.  Is that not a concern here too?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 3.1.  “A subscriber can then attempt to re-establish the dynamic
subscription by using the procedure described in Section 3.”  This seems like a
circular reference.  This guidance (to go read Section 3) is being given in
Section 3.1 (which is inside Section 3).

(2) Section 3.3.  Missing word.
s/requests with publisher/requests with the publisher/

(3) Section 3.4.  “This initiates the publisher to initiate the flow …”.  I
stumbled over the double use of “initiate”.  Do you mean “This signals to the
publisher to initiate the flow …”?

(4) Section 3.4 suggests that NACM/related methods should be used to authorize
“modify-subscription, resync-subscription and delete-subscription” RPCs. 
Section 9, Security Considerations, says “Therefore, even if an attacker
succeeds in guessing the subscription URI, a RESTCONF username [RFC8040] with
the required administrative permissions must be used to be able to access or  
modify that subscription.”  Is there a reason not to say the obvious thing in
the Security Considerations that these particular RPCs should be protected
(with NACM/related methods like was stated in Section 3.4).



From nobody Wed May 15 13:04:02 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 406411207D6; Wed, 15 May 2019 13:04:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155795064021.30579.17743334960038300416@ietfa.amsl.com>
Date: Wed, 15 May 2019 13:04:00 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-yang-push-24.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 20:04:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Subscription to YANG Datastores
        Authors         : Alexander Clemm
                          Eric Voit
	Filename        : draft-ietf-netconf-yang-push-24.txt
	Pages           : 58
	Date            : 2019-05-15

Abstract:
   This document describes a mechanism that allows subscriber
   applications to request a continuous and customized stream of updates
   from a YANG datastore.  Providing such visibility into updates
   enables new capabilities based on the remote mirroring and monitoring
   of configuration and operational state.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-yang-push-24
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-24

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


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

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


From nobody Wed May 15 13:08:53 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1334B12004C; Wed, 15 May 2019 13:08:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= 
To: "The IESG" 
Cc: draft-ietf-netconf-netconf-event-notifications@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= 
Message-ID: <155795093207.30599.1210729112386367807.idtracker@ietfa.amsl.com>
Date: Wed, 15 May 2019 13:08:52 -0700
Archived-At: 
Subject: [netconf] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-netconf-netconf-event-notifications-20=3A_=28with_COMMENT?= =?utf-8?q?=29?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 20:08:52 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-netconf-netconf-event-notifications-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work everyone has put into this document. I have only a small
number of comments and some nits.

== COMMENTS ==
- section 4, "MUST be supported" but by which party ?
- section 7, MUST all components (except 'error-severity') be part of the
rpc-error ? If so, then make it clear - section 8, see the subscriber as the
ennemy, but, can also the exporter be a threat?

== NITS ==
- it would be clearer to group all authors by affiliation
- abstract providing references to subscribed notifications and YANG-push
documents would be a plus - section 3, expand RPC - section 3, probably because
I am not a native English speaker, but I cannot really parse "A solution MUST
reply" esp the word "solution"



From nobody Wed May 15 13:34:26 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DCC12010F; Wed, 15 May 2019 13:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JM4_0dBR_os; Wed, 15 May 2019 13:34:14 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7671200FE; Wed, 15 May 2019 13:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1557952454; x=1559162054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B8otPxR6Ng6tectGuKNzEn5PnjXbP9ugjOHTrIqTfLA=; b=PdQXX5SV1WjZCbgMsDdXqsTZO3eVMwTWgUfWOZ+ZLltNdo9m/ad1mCGQ KEn1u4X4tTgVmwVOmmTPGAmjuQ/CM6FlW1WxMxC3wLPhAbrODVw+S3JwQ jVeIVF9E8gy/iAfqE0mVb7AGP17hELS8Z2PrElRMBGuH8+A996ANelkJ2 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAABrdtxc/5pdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgWYqgT0wMoQHiByMd5hTgXsJAQEBDAEBLwEBhEACF4IUIzQ?= =?us-ascii?q?JDgEDAQEEAQECAQRtKIVKAQEBAwEjEUMCBQsCAQgOBwUCCR0CAgIwFRACBAE?= =?us-ascii?q?NDYJPS4F8D6wvgS+KMYELKAGJe4FTF4FAP4QjPodOglgEiyGCO5l9CQKCCZJ?= =?us-ascii?q?WI4IUhkyNDoMgiRSVCgIRFYEwHziBV3AVgyiCRY4KAUGPf4EhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,474,1549929600"; d="scan'208";a="277195446"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2019 20:34:12 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x4FKYCLj031781 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2019 20:34:12 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 May 2019 16:34:11 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 15 May 2019 16:34:11 -0400
From: "Eric Voit (evoit)" 
To: Roman Danyliw , The IESG 
CC: "draft-ietf-netconf-netconf-event-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
Thread-Index: AQHVC1UKCmTTd5q9QEOBEyxiozCk46ZsoLCg
Date: Wed, 15 May 2019 20:34:11 +0000
Message-ID: 
References: <155794878921.30587.14812046146231301278.idtracker@ietfa.amsl.com>
In-Reply-To: <155794878921.30587.14812046146231301278.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: 
Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 20:34:16 -0000

SGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gICBBIHRob3VnaHQgaW4tbGluZS4u
Lg0KDQo+IEZyb206IFJvbWFuIERhbnlsaXcsIE1heSAxNSwgMjAxOSAzOjMzIFBNDQo+DQo+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQW4gZWFzeSB0
byBmaXggaXNzdWUuDQo+IA0KPiBTZWN0aW9uIDguICBJIGFncmVlIHdpdGggdGhlIGJyZXZpdHkg
b2YgdGhpcyBzZWN0aW9uIGFzIHRoZSBtb3JlIGRldGFpbGVkDQo+IGNvbnNpZGVyYXRpb25zIGNh
biBiZSBmb3VuZCBpbiBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u
c10uDQo+IFtkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXSBoYXMg
YSBzaW1pbGFyIHN0YXRlbWVudCBhYm91dA0KPiBidWdneSBzdWJzY3JpYmVycywgYnV0IGFsc28g
bWFrZXMgYSBTSE9VTEQgc3RhdGVtZW50IGFib3V0IG9wZXJhdG9ycw0KPiBtb25pdG9yaW5nIGZv
ciBvZGQgYmVoYXZpb3IuICBUaGlzIHRleHQgZG9lc27igJl0IGluY2x1ZGUgdGhpcyBtb25pdG9y
aW5nDQo+IHJlY29tbWVuZGF0aW9uIGJ1dCBkb2VzIGV4cGxpY2l0bHkgZGlzY3VzcyB0ZXJtaW5h
dGluZyBzZXNzaW9ucy4gIENvdWxkIHRoZSB0ZXh0DQo+IGluIHRoZXNlIHR3byBzZWN0aW9ucyBw
bGVhc2UgYmUgcmVjb25jaWxlZC4gUGVyaGFwcyB3aXRoIGEgcmVmZXJlbmNlIHN1Y2ggYXM6DQo+
IA0KPiDigJxUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhZGRpdGlvbmFsIFNlY3Vy
aXR5IENvbnNpZGVyYXRpb25zIGZvcg0KPiBkeW5hbWljIHN1YnNjcmlwdGlvbnMgYmV5b25kIHRo
b3NlIGRpc2N1c3NlZCBpbiBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtDQo+IG5vdGlm
aWNhdGlvbnNdLiAgSW4gcGFydGljdWxhciBmb3IgTkVUQ09ORiBzdWJzY3JpYmVycyDigKY8dXNl
IHRoZSBjdXJyZW50IHRleHQ+IOKAnQ0KDQpJIHRoaW5rIHdoYXQgeW91IGFyZSBsb29raW5nIGZv
ciBpcyBzb21ldGhpbmcgbGlrZToNCiJUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBh
ZGRpdGlvbmFsIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGZvciBkeW5hbWljIHN1YnNjcmlwdGlv
bnMgYmV5b25kIHRob3NlIGRpc2N1c3NlZCBpbiBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli
ZWQtbm90aWZpY2F0aW9uc10uICBCdXQgdGhlcmUgaXMgb25lIGNvbnNpZGVyYXRpb24gd29ydGh5
IG9mIG1vcmUgcmVmaW5lbWVudCBiYXNlZCBvbiB0aGUgY29ubmVjdGlvbiBvcmllbnRlZCBuYXR1
cmUgb2YgdGhlIE5FVENPTkYgcHJvdG9jb2wuICBTcGVjaWZpY2FsbHksIGlmIGEgYnVnZ3kgb3Ig
Y29tcHJvbWlzZWQgTkVUQ09ORiBzdWJzY3JpYmVyIHNlbmRzIGEgbnVtYmVyIG9mICJlc3RhYmxp
c2gtc3Vic2NyaXB0aW9uIiByZXF1ZXN0cywgdGhlbiB0aGVzZSBzdWJzY3JpcHRpb25zIGFjY3Vt
dWxhdGUgYW5kIG1heSB1c2UgdXAgc3lzdGVtIHJlc291cmNlcy4gSW4gc3VjaCBhIHNpdHVhdGlv
biwgc3Vic2NyaXB0aW9ucyBNQVkgYmUgdGVybWluYXRlZCBieSB0ZXJtaW5hdGluZyB0aGUgdW5k
ZXJseWluZyBORVRDT05GIHNlc3Npb24uLi4gIg0KDQpJZiB0aGlzIHRleHQgd29ya3MgZm9yIHlv
dSwgSSB3aWxsIGFkZCBpdCBpbi4NCg0KRXJpYw0K


From nobody Wed May 15 13:36:53 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7352F120116; Wed, 15 May 2019 13:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeIeC3SC4eUo; Wed, 15 May 2019 13:36:42 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 232AC12010F; Wed, 15 May 2019 13:36:42 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4FKad9S000442; Wed, 15 May 2019 16:36:39 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x4FKad9S000442
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1557952599; bh=vBczDnBBnRhuL+vZ5+nNiPmU/NE11TkX9AJKmXPyD44=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=YGfseEy45aWeOHxSrMe2pNeonLZd189lr717bOMhvru9JQfJtopCO6rYqgv5nvdE2 VWVhxb2VMcErGnRbMvlNP+C13n/kXqTNYVkf5UeLOWkARWzWdvvdebG32K733sc2Pa WRMqzfS3opiKQ4RQkD+qntUP36lT5ZWaAMaFX6Zg=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4FKab3f026898; Wed, 15 May 2019 16:36:37 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 15 May 2019 16:36:37 -0400
From: Roman Danyliw 
To: "Eric Voit (evoit)" , The IESG 
CC: "draft-ietf-netconf-netconf-event-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
Thread-Index: AQHVC1UMIURW2jHBikWXRDs3ThzXMKZs536A//+9K0A=
Date: Wed, 15 May 2019 20:36:37 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3365E93@marathon>
References: <155794878921.30587.14812046146231301278.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 20:36:45 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRXJpYyBWb2l0IChldm9p
dCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDE1LCAy
MDE5IDQ6MzQgUE0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNH
IDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQt
bm90aWZpY2F0aW9uc0BpZXRmLm9yZzsgS2VudCBXYXRzZW4NCj4gPGtlbnQraWV0ZkB3YXRzZW4u
bmV0PjsgbmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVj
dDogUkU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRj
b25mLWV2ZW50LQ0KPiBub3RpZmljYXRpb25zLTIwOiAod2l0aCBESVNDVVNTKQ0KPiANCj4gSGkg
Um9tYW4sDQo+IA0KPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuICAgQSB0aG91Z2h0IGluLWxpbmUu
Li4NCj4gDQo+ID4gRnJvbTogUm9tYW4gRGFueWxpdywgTWF5IDE1LCAyMDE5IDM6MzMgUE0NCj4g
Pg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBESVNDVVNTOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g
Pg0KPiA+IEFuIGVhc3kgdG8gZml4IGlzc3VlLg0KPiA+DQo+ID4gU2VjdGlvbiA4LiAgSSBhZ3Jl
ZSB3aXRoIHRoZSBicmV2aXR5IG9mIHRoaXMgc2VjdGlvbiBhcyB0aGUgbW9yZQ0KPiA+IGRldGFp
bGVkIGNvbnNpZGVyYXRpb25zIGNhbiBiZSBmb3VuZCBpbiBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1
YnNjcmliZWQtDQo+IG5vdGlmaWNhdGlvbnNdLg0KPiA+IFtkcmFmdC1pZXRmLW5ldGNvbmYtc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zXSBoYXMgYSBzaW1pbGFyIHN0YXRlbWVudA0KPiA+IGFib3V0
IGJ1Z2d5IHN1YnNjcmliZXJzLCBidXQgYWxzbyBtYWtlcyBhIFNIT1VMRCBzdGF0ZW1lbnQgYWJv
dXQNCj4gPiBvcGVyYXRvcnMgbW9uaXRvcmluZyBmb3Igb2RkIGJlaGF2aW9yLiAgVGhpcyB0ZXh0
IGRvZXNu4oCZdCBpbmNsdWRlIHRoaXMNCj4gPiBtb25pdG9yaW5nIHJlY29tbWVuZGF0aW9uIGJ1
dCBkb2VzIGV4cGxpY2l0bHkgZGlzY3VzcyB0ZXJtaW5hdGluZw0KPiA+IHNlc3Npb25zLiAgQ291
bGQgdGhlIHRleHQgaW4gdGhlc2UgdHdvIHNlY3Rpb25zIHBsZWFzZSBiZSByZWNvbmNpbGVkLg0K
PiBQZXJoYXBzIHdpdGggYSByZWZlcmVuY2Ugc3VjaCBhczoNCj4gPg0KPiA+IOKAnFRoaXMgZG9j
dW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIGFkZGl0aW9uYWwgU2VjdXJpdHkgQ29uc2lkZXJhdGlv
bnMNCj4gPiBmb3IgZHluYW1pYyBzdWJzY3JpcHRpb25zIGJleW9uZCB0aG9zZSBkaXNjdXNzZWQg
aW4NCj4gPiBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtIG5vdGlmaWNhdGlvbnNdLiAg
SW4gcGFydGljdWxhciBmb3IgTkVUQ09ORg0KPiBzdWJzY3JpYmVycyDigKY8dXNlIHRoZSBjdXJy
ZW50IHRleHQ+IOKAnQ0KPiANCj4gSSB0aGluayB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IgaXMg
c29tZXRoaW5nIGxpa2U6DQo+ICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhZGRp
dGlvbmFsIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGZvcg0KPiBkeW5hbWljIHN1YnNjcmlwdGlv
bnMgYmV5b25kIHRob3NlIGRpc2N1c3NlZCBpbiBbZHJhZnQtaWV0Zi1uZXRjb25mLQ0KPiBzdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnNdLiAgQnV0IHRoZXJlIGlzIG9uZSBjb25zaWRlcmF0aW9uIHdv
cnRoeSBvZiBtb3JlDQo+IHJlZmluZW1lbnQgYmFzZWQgb24gdGhlIGNvbm5lY3Rpb24gb3JpZW50
ZWQgbmF0dXJlIG9mIHRoZSBORVRDT05GDQo+IHByb3RvY29sLiAgU3BlY2lmaWNhbGx5LCBpZiBh
IGJ1Z2d5IG9yIGNvbXByb21pc2VkIE5FVENPTkYgc3Vic2NyaWJlciBzZW5kcw0KPiBhIG51bWJl
ciBvZiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIgcmVxdWVzdHMsIHRoZW4gdGhlc2Ugc3Vic2Ny
aXB0aW9ucw0KPiBhY2N1bXVsYXRlIGFuZCBtYXkgdXNlIHVwIHN5c3RlbSByZXNvdXJjZXMuIElu
IHN1Y2ggYSBzaXR1YXRpb24sDQo+IHN1YnNjcmlwdGlvbnMgTUFZIGJlIHRlcm1pbmF0ZWQgYnkg
dGVybWluYXRpbmcgdGhlIHVuZGVybHlpbmcgTkVUQ09ORg0KPiBzZXNzaW9uLi4uICINCg0KV29y
a3MgZm9yIG1lIChhbmQgYmV0dGVyIHRoYW4gd2hhdCBJIHByb3Bvc2VkKS4gIFRoYW5rIHlvdSBm
b3IgdGhpcyBuZXcgdGV4dC4NCg0KUm9tYW4NCg==


From nobody Wed May 15 13:53:30 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6211200FB; Wed, 15 May 2019 13:53:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155795360834.30595.9733314429183370481@ietfa.amsl.com>
Date: Wed, 15 May 2019 13:53:28 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-event-notifications-21.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 20:53:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Dynamic subscription to YANG Events and Datastores over NETCONF
        Authors         : Eric Voit
                          Alexander Clemm
                          Alberto Gonzalez Prieto
                          Einar Nilsen-Nygaard
                          Ambika Prasad Tripathy
	Filename        : draft-ietf-netconf-netconf-event-notifications-21.txt
	Pages           : 20
	Date            : 2019-05-15

Abstract:
   This document provides a Network Configuration Protocol (NETCONF)
   binding to the dynamic subscription capability of both subscribed
   notifications and YANG-Push.

   RFC Editor note: please replace the references to pre-RFC normative
   drafts with the actual assigned RFC numbers.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-21
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-event-notifications-21

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


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

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


From nobody Wed May 15 13:54:46 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EDC1200FD; Wed, 15 May 2019 13:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u0VDzgZvZ1A; Wed, 15 May 2019 13:54:41 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24AE11200FB; Wed, 15 May 2019 13:54:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3520; q=dns/txt; s=iport; t=1557953681; x=1559163281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3ZCE94WFYl4wE8+toToeFNTOC1PpHkVqVgIC+3lQlCk=; b=g3hkUkjF7HfT74w59KkdOot0HZMzPm0CffyJU1z/4+SsH1ewMtYtSMSl IAEK36spF5hhuGONRIHxXGtGFUb5Fx6vG1cT0Ip+Xbsu9TLrBfG7rZNu1 StUitZYGOe07BUYCwX7UsEu8Z9hg7R6BtRrII8Zng+cDGESXAyV+rLCi9 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAAUfNxc/5pdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUgUBAQELAYFmKoE9MCgKhAeVE5hTgXsJAQEBDAEBLwEBhEACF4I?= =?us-ascii?q?UIzUIDgEDAQEEAQECAQRtKIVKAQEBAwEjEUMCBQcEAgEIDgMEAQEDAgkaAwI?= =?us-ascii?q?CAjAUAQgIAgQBDQUIgk9LgXwPrCWBL4oygQsoAYl7gVMXgUA/gRGDEj6HToJ?= =?us-ascii?q?YBIshgjuMY40aCQKCCZJWI4IUhkyNDoMgiRSVCgIRFYEwIAE2gVdwFYMngka?= =?us-ascii?q?OCgFBMY9OgSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,474,1549929600"; d="scan'208";a="558124501"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2019 20:54:39 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x4FKsdEa030333 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2019 20:54:39 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 May 2019 16:54:38 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Wed, 15 May 2019 16:54:38 -0400
From: "Eric Voit (evoit)" 
To: Roman Danyliw , The IESG 
CC: "draft-ietf-netconf-netconf-event-notifications@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
Thread-Index: AQHVC1UKCmTTd5q9QEOBEyxiozCk46ZsoLCggABHfID//8HSMA==
Date: Wed, 15 May 2019 20:54:38 +0000
Message-ID: 
References: <155794878921.30587.14812046146231301278.idtracker@ietfa.amsl.com>  <359EC4B99E040048A7131E0F4E113AFC01B3365E93@marathon>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3365E93@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: 
Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-netconf-event-notifications-20: (with DISCUSS)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 20:54:44 -0000

UG9zdGVkIGFzIHYyMS4NCg0KPiBGcm9tOiBSb21hbiBEYW55bGl3LCBNYXkgMTUsIDIwMTkgNDoz
NyBQTQ0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBF
cmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NCj4gPiBTZW50OiBXZWRu
ZXNkYXksIE1heSAxNSwgMjAxOSA0OjM0IFBNDQo+ID4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBj
ZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+IENjOiBkcmFmdC1pZXRmLW5l
dGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zQGlldGYub3JnOyBLZW50DQo+ID4gV2F0
c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IG5ldGNvbmYtY2hhaXJzQGlldGYub3JnOw0KPiA+
IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogUm9tYW4gRGFueWxpdydzIERpc2N1
c3Mgb24NCj4gPiBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC0NCj4gPiBub3RpZmlj
YXRpb25zLTIwOiAod2l0aCBESVNDVVNTKQ0KPiA+DQo+ID4gSGkgUm9tYW4sDQo+ID4NCj4gPiBU
aGFua3MgZm9yIHRoZSByZXZpZXcuICAgQSB0aG91Z2h0IGluLWxpbmUuLi4NCj4gPg0KPiA+ID4g
RnJvbTogUm9tYW4gRGFueWxpdywgTWF5IDE1LCAyMDE5IDM6MzMgUE0NCj4gPiA+DQo+ID4gPiAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPiA+IERJU0NVU1M6DQo+ID4gPiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
PiA+ID4gLS0NCj4gPiA+DQo+ID4gPiBBbiBlYXN5IHRvIGZpeCBpc3N1ZS4NCj4gPiA+DQo+ID4g
PiBTZWN0aW9uIDguICBJIGFncmVlIHdpdGggdGhlIGJyZXZpdHkgb2YgdGhpcyBzZWN0aW9uIGFz
IHRoZSBtb3JlDQo+ID4gPiBkZXRhaWxlZCBjb25zaWRlcmF0aW9ucyBjYW4gYmUgZm91bmQgaW4N
Cj4gPiA+IFtkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC0NCj4gPiBub3RpZmljYXRpb25z
XS4NCj4gPiA+IFtkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXSBo
YXMgYSBzaW1pbGFyDQo+ID4gPiBzdGF0ZW1lbnQgYWJvdXQgYnVnZ3kgc3Vic2NyaWJlcnMsIGJ1
dCBhbHNvIG1ha2VzIGEgU0hPVUxEIHN0YXRlbWVudA0KPiA+ID4gYWJvdXQgb3BlcmF0b3JzIG1v
bml0b3JpbmcgZm9yIG9kZCBiZWhhdmlvci4gIFRoaXMgdGV4dCBkb2VzbuKAmXQNCj4gPiA+IGlu
Y2x1ZGUgdGhpcyBtb25pdG9yaW5nIHJlY29tbWVuZGF0aW9uIGJ1dCBkb2VzIGV4cGxpY2l0bHkg
ZGlzY3Vzcw0KPiA+ID4gdGVybWluYXRpbmcgc2Vzc2lvbnMuICBDb3VsZCB0aGUgdGV4dCBpbiB0
aGVzZSB0d28gc2VjdGlvbnMgcGxlYXNlIGJlDQo+IHJlY29uY2lsZWQuDQo+ID4gUGVyaGFwcyB3
aXRoIGEgcmVmZXJlbmNlIHN1Y2ggYXM6DQo+ID4gPg0KPiA+ID4g4oCcVGhpcyBkb2N1bWVudCBk
b2VzIG5vdCBpbnRyb2R1Y2UgYWRkaXRpb25hbCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPiA+
ID4gZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBiZXlvbmQgdGhvc2UgZGlzY3Vzc2VkIGluDQo+
ID4gPiBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtIG5vdGlmaWNhdGlvbnNdLiAgSW4g
cGFydGljdWxhciBmb3INCj4gPiA+IE5FVENPTkYNCj4gPiBzdWJzY3JpYmVycyDigKY8dXNlIHRo
ZSBjdXJyZW50IHRleHQ+IOKAnQ0KPiA+DQo+ID4gSSB0aGluayB3aGF0IHlvdSBhcmUgbG9va2lu
ZyBmb3IgaXMgc29tZXRoaW5nIGxpa2U6DQo+ID4gIlRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50
cm9kdWNlIGFkZGl0aW9uYWwgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gPiBmb3IgZHluYW1p
YyBzdWJzY3JpcHRpb25zIGJleW9uZCB0aG9zZSBkaXNjdXNzZWQgaW4NCj4gPiBbZHJhZnQtaWV0
Zi1uZXRjb25mLSBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLiAgQnV0IHRoZXJlIGlzIG9uZQ0K
PiA+IGNvbnNpZGVyYXRpb24gd29ydGh5IG9mIG1vcmUgcmVmaW5lbWVudCBiYXNlZCBvbiB0aGUg
Y29ubmVjdGlvbg0KPiA+IG9yaWVudGVkIG5hdHVyZSBvZiB0aGUgTkVUQ09ORiBwcm90b2NvbC4g
IFNwZWNpZmljYWxseSwgaWYgYSBidWdneSBvcg0KPiA+IGNvbXByb21pc2VkIE5FVENPTkYgc3Vi
c2NyaWJlciBzZW5kcyBhIG51bWJlciBvZg0KPiA+ICJlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIiBy
ZXF1ZXN0cywgdGhlbiB0aGVzZSBzdWJzY3JpcHRpb25zIGFjY3VtdWxhdGUNCj4gPiBhbmQgbWF5
IHVzZSB1cCBzeXN0ZW0gcmVzb3VyY2VzLiBJbiBzdWNoIGEgc2l0dWF0aW9uLCBzdWJzY3JpcHRp
b25zDQo+ID4gTUFZIGJlIHRlcm1pbmF0ZWQgYnkgdGVybWluYXRpbmcgdGhlIHVuZGVybHlpbmcg
TkVUQ09ORiBzZXNzaW9uLi4uICINCj4gDQo+IFdvcmtzIGZvciBtZSAoYW5kIGJldHRlciB0aGFu
IHdoYXQgSSBwcm9wb3NlZCkuICBUaGFuayB5b3UgZm9yIHRoaXMgbmV3IHRleHQuDQo+IA0KPiBS
b21hbg0K


From nobody Wed May 15 14:33:37 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA21200D8 for ; Wed, 15 May 2019 14:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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, T_REMOTE_IMAGE=0.01] 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 wQ31jjtAwYFl for ; Wed, 15 May 2019 14:33:33 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 9A9301200A2 for ; Wed, 15 May 2019 14:33:32 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id l2so1029537wrb.9 for ; Wed, 15 May 2019 14:33:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=e3qZ/p/1HHyLE8XJgttbkkqAPPuqEUImJHu65MhgU4Q=; b=Duy4ZAXXu2jMtEiI+jdF+KDoSJ35V7cTE4QPMaRNVAtofxOpFIEkds70KLW1x/r64R p2UECJ5fkF/qUNQy7uvgJSYOaxCRILDbaoqXyD+Q73wyPLzMkspe9EYNo+z/QSK2Meuf iGvzAGFIfK2EZNX3/cji6Jfko6ZTTbMyQD94bJOfcXou8vZRAAvatSrQDMM6CMR6ffHM oqaY7Kg/SXjz7jxNEAKgr3MLk0dxjj4aOWQC9zq3R1uEw58102CG/ujKiIKw3h3iww1N BriG+Eiwuize1Q5p5OOg7nJtfsa4j5+zYmKdCYJhKwofhpizAWXZw6GzcBF6uAGKJJKH b4tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=e3qZ/p/1HHyLE8XJgttbkkqAPPuqEUImJHu65MhgU4Q=; b=soAdpp2mLuj2yeXv5WzhQx8a1fuMFMPL+l/FVc/IK02e4YTbwpiFU5zgzZeDovCxGn xOfzO9GqE10JGx5y3gKGpjZQZXynG/Q+ve53SWRfdutsK2WsI1bwDEAsDqA4SE8+UBH6 tVKwVmRJPGjfa1zNq9OdYGgJSQkjo/t7zn+YgVLFOp2mBdq/zRxg/geMIIjUfOwvF4hF gxnMrfaelOVUCrLOtNqmbsi+4Z2oxb04GLuQG7xKMgM8tHlr/y0IikMBpg3/gLn8N0Es hGFEmKggQLuSvK9JcPtNs7u6quNsK5iwlM/7n2KnOASqCw/uBR9qofyE91CMcmIyMv5h C28g==
X-Gm-Message-State: APjAAAWoYL/c5fC32AI2OTQBv/+IG9smtoSz/jnLGtH7fe8SMHKxWhk1 UrheaeEE9PBzCc2liJDlYmQ4FlP4
X-Google-Smtp-Source: APXvYqz7ZnL1bX4tejovzKaPobo91FeQ+eMRnJeewpc5DnZ7BaRUyJcQfp11bJ1QQFcZzJBpFrbGRg==
X-Received: by 2002:adf:9bd2:: with SMTP id e18mr15154842wrc.210.1557956011020;  Wed, 15 May 2019 14:33:31 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id v5sm6464669wra.83.2019.05.15.14.33.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 14:33:30 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C28EB8E6-8CCE-4EB4-919A-4CD4115CE27A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 15 May 2019 14:33:27 -0700
In-Reply-To: 
Cc: Kent Watsen , "netconf@ietf.org" 
To: Jonathan Hansford 
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 21:33:36 -0000

--Apple-Mail=_C28EB8E6-8CCE-4EB4-919A-4CD4115CE27A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On May 15, 2019, at 3:24 AM, Jonathan Hansford =
 wrote:
>=20
> Kent,
>=20
> I don't think Erratum 5397 should be deleted. Though the original =
section 7.8 makes no mention of confirmed commits, section 7.9 does, but =
does not differentiate between a vanilla confirmed commit and a =
persistent confirmed commit. Since a persistent confirmed commit is =
still a type of confirmed commit, without clarification the second =
paragraph of the description would seem to apply.=20

I would agree.

>=20
> With the diff, should that be against the original text or the =
original erratum?

The diff is building on top of the original erratum. I would think a =
diff w.r.t. to the original erratum would make sense.

>=20
> Thanks,
>=20
> Jonathan
>=20
>=20
> On 14/05/2019 19:45:12, "Kent Watsen" > wrote:
>=20
>> =20
>>> So I need to contact the RFC Editor to correct Erratum 5397, with =
the relevant text in sections 7.8 and 7.9 being changed to something =
like:
>>> =20
>>> 7.8: "If a NETCONF server receives a  request while =
processing a confirmed commit (Section 8.4) for that session, unless the =
confirmed commit is a persistent confirmed commit, it MUST restore the =
configuration to its state before the confirmed commit was issued. A =
persistent confirmed commit MUST survive session termination."
>>> =20
>>> 7.9: "If a NETCONF server receives a  request while =
processing a confirmed commit (Section 8.4) for the session to be =
killed, unless the confirmed commit is a persistent confirmed commit, it =
MUST restore the configuration to its state before the confirmed commit =
was issued. A persistent confirmed commit MUST survive session =
termination."
>> =20
>> Ideally, Errata 5397 is deleted (because I think that it's clear that =
Section 8.4 overrides the 7.8 behavior) but, if we have to patch the =
errata, I might suggests:
>> =20
>> For Section 7.8
>> OLD (in RFC 6241)
>> =20
>> The server will release any locks
>> and resources associated with the session and gracefully close any
>> associated connections.
>> =20
>> NEW:
>> =20
>> The server will release any locks
>> and resources, associated with the session and gracefully close any
>> associated connections. As an exception to the previous sentence, if
>> the session is processing a persistent confirmed commit (Section =
8.4),
>> the resources necessary for supporting confirmed commit are not =
released.
>> =20
>> For Section 7.9:
>> OLD (in RFC 6241)
>> =20
>> If a NETCONF server receives a  request while
>> processing a confirmed commit (Section 8.4), it MUST restore the
>> configuration to its state before the confirmed commit was issued.
>> =20
>> NEW:
>> What you have above seems fine, though I'd leave off the last =
sentence.
>> =20
>> =20
>>> I also need to contact the RFC Editor to correct Erratum 3821 to =
change:
>>> =20
>>> If the session issuing a sequence of one or more confirmed commits =
is
>>> terminated for any reason before the confirm timeout expires, the =
server
>>> MUST restore the configuration to its state before the sequence of
>>> confirmed commits was issued, unless the last confirmed commit also
>>> included a  element.
>>> =20
>>> If the device reboots for any reason before the confirm timeout
>>> expires, the server MUST restore the configuration to its state
>>> before the sequence of confirmed commits was issued.
>>> =20
>>> to something like:
>>> =20
>>> If the session issuing a sequence of one or more confirmed commits =
is
>>> terminated for any reason before the confirm timeout expires, the =
server
>>> MUST restore the configuration to its state before the sequence of
>>> confirmed commits was issued, unless the confirmed commit is a
>>> persistent confirmed commit.
>>> =20
>>> If the device reboots for any reason before the confirm timeout
>>> expires, unless a persistent confirmed commit is in progress, the
>>> server MUST restore the configuration to its state before the
>>> sequence of confirmed commits was issued.
>>> =20
>>> A persistent confirmed commit MUST survive session termination.
>>> =20
>> =20
>> This seems okay but, again, I'd leave out the last sentence.
>> =20
>> =20
>> Side note: huge errata are hard to read without a diff. If a lot of =
text, then the NEW (or the NOTES) should include a diff highlighting =
exactly what changed.
>> =20
>> Kent // contributor
>> =20
>> =20
>> =20
>>> Are those errata OK?
>>> =20
>> =20
>=20
>=20
>  =
	Virus-free. =
www.avast.com =
 =
________________________=
_______________________
> netconf mailing list
> netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =


Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_C28EB8E6-8CCE-4EB4-919A-4CD4115CE27A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On May 15, 2019, at 3:24 AM, Jonathan Hansford <jonathan@hansfords.net> wrote:

Kent,

I don't think Erratum 5397 should be deleted. Though =
the original section 7.8 makes no mention of confirmed commits, section =
7.9 does, but does not differentiate between a vanilla confirmed commit =
and a persistent confirmed commit. Since a persistent confirmed commit =
is still a type of confirmed commit, without clarification the second =
paragraph of the description would seem to =
apply. 

I would =
agree.


With the diff, should that be against the original =
text or the original erratum?

The diff is building on top of the original erratum. I =
would think a diff w.r.t. to the original erratum would make =
sense.


Thanks,

Jonathan


On 14/05/2019 19:45:12, "Kent Watsen" =
<kent@watsen.net> =
wrote:

 
So I need to contact the RFC Editor to =
correct Erratum 5397, with the relevant text in sections 7.8 and 7.9 =
being changed to something like:
 
7.8: "If a =
NETCONF server receives a <close-session> request while processing =
a confirmed commit (Section 8.4) for that session, unless the confirmed =
commit is a persistent confirmed commit, it MUST restore the =
configuration to its state before the confirmed commit was issued. A =
persistent confirmed commit MUST survive session termination."
 
7.9: "If a =
NETCONF server receives a <kill-session> request while processing =
a confirmed commit (Section 8.4) for the session to be killed, unless =
the confirmed commit is a persistent confirmed commit, it MUST restore =
the configuration to its state before the confirmed commit was issued. A =
persistent confirmed commit MUST survive session =
termination."
 
Ideally, Errata 5397 is deleted (because I think =
that it's clear that Section 8.4 overrides the 7.8 behavior) but, if we =
have to patch the errata, I might suggests:
 
For Section =
7.8
OLD (in RFC 6241)
 
The server =
will release any locks
and resources =
associated with the session and gracefully close any
associated connections.
 
NEW:
 
The server =
will release any locks
and resources, =
associated with the session and gracefully close any
associated connections. As an exception to the =
previous sentence, if
the session is =
processing a persistent confirmed commit (Section 8.4),
the resources necessary for supporting confirmed =
commit are not released.
 
For Section 7.9:
OLD =
(in RFC 6241)
 
If a NETCONF server receives a <kill-session> =
request while
processing a confirmed =
commit (Section 8.4), it MUST restore the
configuration to its state before the confirmed =
commit was issued.
 
NEW:
What you have =
above seems fine, though I'd leave off the last sentence.
 
 
I also need to contact the RFC Editor to =
correct Erratum 3821 to change:
 
If the =
session issuing a sequence of one or more confirmed commits is
terminated for any reason before the confirm =
timeout expires, the server
MUST restore =
the configuration to its state before the sequence of
confirmed commits was issued, unless the last =
confirmed commit also
included a =
<persist> element.
 
If the device reboots for any reason before the =
confirm timeout
expires, the server MUST =
restore the configuration to its state
before the sequence of confirmed commits was =
issued.
 
to something like:
 
If the =
session issuing a sequence of one or more confirmed commits is
terminated for any reason before the confirm =
timeout expires, the server
MUST restore =
the configuration to its state before the sequence of
confirmed commits was issued, unless the confirmed =
commit is a
persistent confirmed =
commit.
 
If the device reboots for any reason before the =
confirm timeout
expires, unless a =
persistent confirmed commit is in progress, the
server MUST restore the configuration to its state =
before the
sequence of confirmed commits =
was issued.
 
A persistent confirmed commit MUST survive session =
termination.
 
 
This seems =
okay but, again, I'd leave out the last sentence.
 
 
Side note: =
huge errata are hard to read without a diff. If a lot of text, then the =
NEW (or the NOTES) should include a diff highlighting exactly what =
changed.
 
Kent // contributor
 
 
 
Are those errata OK?
 
 

3D""Virus-free. www.avast.com
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

=


Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_C28EB8E6-8CCE-4EB4-919A-4CD4115CE27A--


From nobody Wed May 15 14:48:28 2019
Return-Path: <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E01200A2 for ; Wed, 15 May 2019 14:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci-bbABdkhx3 for ; Wed, 15 May 2019 14:48:24 -0700 (PDT)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8030B120021 for ; Wed, 15 May 2019 14:48:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557956903; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=bm9elLOBC7YTDYeU3O/EomLPbF4v8Ir0KUvkXPTrL2w=; b=nSNTDss1uJ3r2tcog4aRFa4lPZwhKX9ocGdlfflajsDjazikT44kFD9ZjKvsTQDm ig/6MwyO6NEuCcKzMUYGh44JQfpcS5hoiuRBQFs/xVpdtiRxQfxdK9Bu84Ld94rXlKo l979d5nIkY4U2nJtSdHUOp56JVPsN9svUACtiZhc=
From: Kent Watsen 
Message-ID: <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_17690598-21AE-4643-A2A9-FA6EE5FA2172"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 15 May 2019 21:48:22 +0000
In-Reply-To: <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com>
Cc: Jonathan Hansford , "netconf@ietf.org" 
To: Mahesh Jethanandani 
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>  <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.15-54.240.8.64
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 May 2019 21:48:27 -0000

--Apple-Mail=_17690598-21AE-4643-A2A9-FA6EE5FA2172
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



>> I don't think Erratum 5397 should be deleted. Though the original =
section 7.8 makes no mention of confirmed commits, section 7.9 does, but =
does not differentiate between a vanilla confirmed commit and a =
persistent confirmed commit. Since a persistent confirmed commit is =
still a type of confirmed commit, without clarification the second =
paragraph of the description would seem to apply.=20
>=20
> I would agree.

It's a minor point, but I could argue, as I wrote before, that such =
clarifications in 7.x are unnecessary because 8.4 provides overrides.   =
I prefer less text because it's easier to get right (wit this is at =
least the 3rd time Jonathan is at this now).  However "unnecessary" =
doesn't mean "wrong" and since we've already stepped in it, getting the =
7.x errata right might be easier than getting 8.4 right.


>> With the diff, should that be against the original text or the =
original erratum?
>=20
> The diff is building on top of the original erratum. I would think a =
diff w.r.t. to the original erratum would make sense.

It depends, are you correcting the earlier errata or filing a new one?   =
Regardless, I expressed a diff for what I think the text should be =
(which you didn't comment on); how that is translated is up to you.


Kent // contributor


--Apple-Mail=_17690598-21AE-4643-A2A9-FA6EE5FA2172
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



I don't think Erratum 5397 should be deleted. Though =
the original section 7.8 makes no mention of confirmed commits, section =
7.9 does, but does not differentiate between a vanilla confirmed commit =
and a persistent confirmed commit. Since a persistent confirmed commit =
is still a type of confirmed commit, without clarification the second =
paragraph of the description would seem to =
apply. 

I would agree.

It's a minor point, but I could argue, as I wrote =
before, that such clarifications in 7.x are unnecessary because 8.4 =
provides overrides.   I prefer less text because it's easier to get =
right (wit this is at least the 3rd time Jonathan is at this now). =
 However "unnecessary" doesn't mean "wrong" and since we've already =
stepped in it, getting the 7.x errata right might be easier than getting =
8.4 right.


With the diff, should that be against =
the original text or the original erratum?

The diff is building on top of the =
original erratum. I would think a diff w.r.t. to the original erratum =
would make sense.

It depends, are you correcting the earlier errata =
or filing a new one?   Regardless, I expressed a diff for what I =
think the text should be (which you didn't comment on); how that is =
translated is up to you.


Kent // contributor

=

--Apple-Mail=_17690598-21AE-4643-A2A9-FA6EE5FA2172--


From nobody Wed May 15 19:10:06 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839881200F4 for ; Wed, 15 May 2019 19:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttX9z96V5RLM for ; Wed, 15 May 2019 19:10:01 -0700 (PDT)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9D412010E for ; Wed, 15 May 2019 19:10:01 -0700 (PDT)
Received: by mail-pl1-f176.google.com with SMTP id f12so775883plt.8 for ; Wed, 15 May 2019 19:10:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ETolUwGDX9BkppTFXX+43CUMGe0zXp/eGnfbsdhc36c=; b=RnXXwDyoTqzpC2EOksnqst8HG/PyJ4BxMdb4QJ4E9Qtx+2cqjT4iwopBaWWO5K8Ih/ qdJvUQxbf07PHnv3cw975toMtTaqB7tRocgTOfay1bl9VMUShISxKomiyDbyKGe7KL/l K14ELy8mXpTQDDA4ejE8K3qUXnpnwxozd90S1068uZf+ZEcA4Imb/H69NFpzyIk0CHjJ t2f43da4Rt5LREklZlYwdpQVhgrX/m8HV1XecmmADYYV31SD0w/qjtw1Hb1P5r/Vqf7p 3wvq5I8gEvlNrNa/ddmpUZNvRWG+0sYmwZzKXfIDSRbb3xN2HtX7my1n+74fQWLaXW0M AY9A==
X-Gm-Message-State: APjAAAUdD7zmLhCR/vXinUe5cwgaMQcD6rxETNu40YuMotOQJaXL3J5/ j+N5x8YrmulNyHWdlys6afJFJw==
X-Google-Smtp-Source: APXvYqzea4f+S8WuMrhesGMx5AtFQNbQEuimo7msNdMk8YAi4A2QGQUosWvUVtK4+6099Q6i044A5Q==
X-Received: by 2002:a17:902:4a:: with SMTP id 68mr48186153pla.235.1557972600383;  Wed, 15 May 2019 19:10:00 -0700 (PDT)
Received: from [192.168.1.102] (c-69-181-241-121.hsd1.ca.comcast.net. [69.181.241.121]) by smtp.gmail.com with ESMTPSA id x16sm4127317pff.30.2019.05.15.19.09.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 19:09:59 -0700 (PDT)
To: "Eric Voit (evoit)" , Benjamin Kaduk , The IESG 
Cc: "netconf@ietf.org" , "draft-ietf-netconf-netconf-event-notifications@ietf.org" , "netconf-chairs@ietf.org" 
References: <155794345628.30726.16513916652364715189.idtracker@ietfa.amsl.com> <17b8294694a446679f786fee28e4e206@XCH-RTP-013.cisco.com>
From: Randy Presuhn 
Message-ID: <8a904fce-ff70-2e62-9fde-850cce607ffc@alumni.stanford.edu>
Date: Wed, 15 May 2019 19:09:58 -0700
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: <17b8294694a446679f786fee28e4e206@XCH-RTP-013.cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 02:10:05 -0000

Hi -

On 5/15/2019 12:01 PM, Eric Voit (evoit) wrote:
...
>> From: Benjamin Kaduk, May 15, 2019 2:04 PM
...
>> Section 6
>>
>>     Notification messages transported over the NETCONF protocol MUST be
>>     encoded in a  message as defined within [RFC5277],
>>     Section 4.  And per [RFC5277]'s "eventTime" object definition, the
>>     "eventTime" populated with the event occurrence time.
>>
>> nit: I think the last sentence is actually a sentence fragment.
> 
> This reads fine with me.  Several on-line grammar checks give it a pass, but I am not sure how much I trust those tools.  So I will leave as is.

No, it really is a fragment.  Not only does it begin with a conjunction,
but it lacks a verb. If it were joined to the previous sentence, one
might infer a "MUST be" before "populated", but as a separate sentence
it no longer supports that interpretation.  If "MUST be populated" isn't
the intended interpretation here, then it's even more important to
turn that fragment into a real sentence.

Randy


From nobody Thu May 16 04:47:12 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9568612002E; Thu, 16 May 2019 04:47:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-restconf-notif@ietf.org, Kent Watsen , netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund 
Message-ID: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com>
Date: Thu, 16 May 2019 04:47:11 -0700
Archived-At: 
Subject: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 11:47:11 -0000

Magnus Westerlund has entered the following ballot position for
draft-ietf-netconf-restconf-notif-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4:

Based on the QoS discussion for draft-ietf-netconf-subscribed-notifications
weight is not really a a priority in the terms people think of it. It only
provides a weight for bandwidth allocation.

   o  take any existing subscription "priority", as specified by the
      "weighting" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and copy it
      into the HTTP2 stream weight, [RFC7540] section 5.3, and

I would recommend that the use of "priority" is reformualted here to reflect
that aspect.

   o  take any existing subscription "dependency", as specified by the
      "dependency" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and use the
      HTTP2 stream for the parent subscription as the HTTP2 stream
      dependency, [RFC7540] section 5.3.1, of the dependent
      subscription.

What is not obivous to me is that just because that a subscription exists at
the publisher that it is going over the same HTTP/2 connection and thus there
might be nothing for the dependency to point at that is relevant for the
mechanism described in RFC 7540. I didn't even find a recommendation that the
receiver (subscriber) should actually re-use the HTTP/2 connection for all
communication with the same publisher.



From nobody Thu May 16 05:47:18 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5413E1200F3; Thu, 16 May 2019 05:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmP_B9jJ6L16; Thu, 16 May 2019 05:47:08 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDDC120090; Thu, 16 May 2019 05:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1872; q=dns/txt; s=iport; t=1558010827; x=1559220427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9gOfVc5Cz5Q4Y7jFeGb5ju9QyyY8HqJaRnAZ9NBxhzc=; b=F2c/LTTUWnQCCr6o+bMxDwza6E8rZe4crcZeNzIVAnR41CZpiJk0ah+k bUtRhOIWlERoAoEhIwSsKB28wm9M7oUR7lTxhUfE13igglH2QSG+mK7mq XzSFh/xSJV9qRfc1ZpsOMZfOSKlP3LbYuH/EtcONjG/0L1xLf5uBbo2ko I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABCW91c/5tdJa1kDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVIEAQEBAQsBgWYqgT0wMoQHlRWYU4F7CQEBAQwBAS8BAYR?= =?us-ascii?q?AAheCFyM1CA4BAwEBBAEBAgEEbSiFSgEBAQMBIxFDAgULAgEIFQMCAh8HAgI?= =?us-ascii?q?CMBUQAgQBDQ2CT0uBfA+rVoEvijGBCygBi04XgUA/gRGDEj6EW4JzglgEjVy?= =?us-ascii?q?ZfQkCggmSViOVboMgiRSVCgIRFYEwIAE2gVdwFYMogkWNUDtBj3+BIQEB?=
X-IronPort-AV: E=Sophos;i="5.60,476,1549929600"; d="scan'208";a="560467562"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 May 2019 12:47:04 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x4GCl30B011664 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2019 12:47:04 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 08:47:03 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Thu, 16 May 2019 08:47:03 -0400
From: "Eric Voit (evoit)" 
To: Randy Presuhn , Benjamin Kaduk , The IESG 
CC: "netconf@ietf.org" , "draft-ietf-netconf-netconf-event-notifications@ietf.org" , "netconf-chairs@ietf.org" 
Thread-Topic: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
Thread-Index: AQHVC0issmRKZA7PmESHWaRaGNgVg6ZsgKHQgADExwCAAG4z8A==
Date: Thu, 16 May 2019 12:47:03 +0000
Message-ID: <9f931951fb104c19b7e786bdd1871ae1@XCH-RTP-013.cisco.com>
References: <155794345628.30726.16513916652364715189.idtracker@ietfa.amsl.com> <17b8294694a446679f786fee28e4e206@XCH-RTP-013.cisco.com> <8a904fce-ff70-2e62-9fde-850cce607ffc@alumni.stanford.edu>
In-Reply-To: <8a904fce-ff70-2e62-9fde-850cce607ffc@alumni.stanford.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 12:47:09 -0000

PiBGcm9tOiBSYW5keSBQcmVzdWhuLCBNYXkgMTUsIDIwMTkgMTA6MTAgUE0NCj4gDQo+IEhpIC0N
Cj4gDQo+IE9uIDUvMTUvMjAxOSAxMjowMSBQTSwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQo+
IC4uLg0KPiA+PiBGcm9tOiBCZW5qYW1pbiBLYWR1aywgTWF5IDE1LCAyMDE5IDI6MDQgUE0NCj4g
Li4uDQo+ID4+IFNlY3Rpb24gNg0KPiA+Pg0KPiA+PiAgICAgTm90aWZpY2F0aW9uIG1lc3NhZ2Vz
IHRyYW5zcG9ydGVkIG92ZXIgdGhlIE5FVENPTkYgcHJvdG9jb2wgTVVTVCBiZQ0KPiA+PiAgICAg
ZW5jb2RlZCBpbiBhIDxub3RpZmljYXRpb24+IG1lc3NhZ2UgYXMgZGVmaW5lZCB3aXRoaW4gW1JG
QzUyNzddLA0KPiA+PiAgICAgU2VjdGlvbiA0LiAgQW5kIHBlciBbUkZDNTI3N10ncyAiZXZlbnRU
aW1lIiBvYmplY3QgZGVmaW5pdGlvbiwgdGhlDQo+ID4+ICAgICAiZXZlbnRUaW1lIiBwb3B1bGF0
ZWQgd2l0aCB0aGUgZXZlbnQgb2NjdXJyZW5jZSB0aW1lLg0KPiA+Pg0KPiA+PiBuaXQ6IEkgdGhp
bmsgdGhlIGxhc3Qgc2VudGVuY2UgaXMgYWN0dWFsbHkgYSBzZW50ZW5jZSBmcmFnbWVudC4NCj4g
Pg0KPiA+IFRoaXMgcmVhZHMgZmluZSB3aXRoIG1lLiAgU2V2ZXJhbCBvbi1saW5lIGdyYW1tYXIg
Y2hlY2tzIGdpdmUgaXQgYSBwYXNzLCBidXQgSQ0KPiBhbSBub3Qgc3VyZSBob3cgbXVjaCBJIHRy
dXN0IHRob3NlIHRvb2xzLiAgU28gSSB3aWxsIGxlYXZlIGFzIGlzLg0KPiANCj4gTm8sIGl0IHJl
YWxseSBpcyBhIGZyYWdtZW50LiAgTm90IG9ubHkgZG9lcyBpdCBiZWdpbiB3aXRoIGEgY29uanVu
Y3Rpb24sIGJ1dCBpdCBsYWNrcw0KPiBhIHZlcmIuIElmIGl0IHdlcmUgam9pbmVkIHRvIHRoZSBw
cmV2aW91cyBzZW50ZW5jZSwgb25lIG1pZ2h0IGluZmVyIGEgIk1VU1QgYmUiDQo+IGJlZm9yZSAi
cG9wdWxhdGVkIiwgYnV0IGFzIGEgc2VwYXJhdGUgc2VudGVuY2UgaXQgbm8gbG9uZ2VyIHN1cHBv
cnRzIHRoYXQNCj4gaW50ZXJwcmV0YXRpb24uICBJZiAiTVVTVCBiZSBwb3B1bGF0ZWQiIGlzbid0
IHRoZSBpbnRlbmRlZCBpbnRlcnByZXRhdGlvbiBoZXJlLA0KPiB0aGVuIGl0J3MgZXZlbiBtb3Jl
IGltcG9ydGFudCB0byB0dXJuIHRoYXQgZnJhZ21lbnQgaW50byBhIHJlYWwgc2VudGVuY2UuDQoN
Ck1hZGUgaXQ6ICAiQW5kIHBlciBbUkZDNTI3N10ncyAiZXZlbnRUaW1lIiBvYmplY3QgZGVmaW5p
dGlvbiwgdGhlICJldmVudFRpbWUiIGlzIHBvcHVsYXRlZCB3aXRoIHRoZSBldmVudCBvY2N1cnJl
bmNlIHRpbWUuIg0KDQpNVVNUIGlzIG5vdCByZXF1aXJlZCBhcyBwcmV2aW91cyByZWZlcmVuY2Vz
IGFscmVhZHkgZW5mb3JjZSB0aGF0IHJlcXVpcmVtZW50Lg0KDQpFcmljDQogDQo+IFJhbmR5DQo=


From nobody Thu May 16 09:47:45 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59F1200DB; Thu, 16 May 2019 09:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 header.b=VgepTYv7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ifud9V0k
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQmKzz_FE7vE; Thu, 16 May 2019 09:47:31 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4DE1200B3; Thu, 16 May 2019 09:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22494; q=dns/txt; s=iport; t=1558025251; x=1559234851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=12G+gFAtvPfENVGWVwdlZJFgh3atI41Nguv3dRVhTwM=; b=VgepTYv7RKwXx3sLIPn8uXDm41Xv7ve4e2SuHq2UsMuW/63ItKFQ52Ih 8oaZOzs26KWcm4dhqT/kLFR0goTTKRNY0cunygqKVa6LeFgN7a70KbRRl 0leKb0mDKY/iYrNv0kGtmTwWHWUzk6ASy9Xl5gdfrLqNPUVGKv1AYd6So g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AN8LjZhZcOHqq3bvaGR2fD0L/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwdSU6Gc1EfFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAACfk91c/4ENJK1kDhABBgcGgVI?= =?us-ascii?q?ICwGBPSknA2lVIAQLKIQRg0cDjnWCV36WKIEuFIEQA1QJAQEBDAEBIwoCAQG?= =?us-ascii?q?EQAIXghcjNQgOAQMBAQQBAQIBBG0cDIVKAQEBAQIBEhERDAEBJQQHBwEPAgE?= =?us-ascii?q?IGAICCR0CAgIwFRACBA4FIoI1SwGBagMODwEOoGQCgTWIX3GBL4J5AQEFgTI?= =?us-ascii?q?BE0GCfRiCDwMGgQsoi1AXgUA/gREnH4FOSTU+gmECAQIBgUUCLSECglAygia?= =?us-ascii?q?LIwqCQIZvhgGNKwkCggmGKYQ9hDSDUxuCG4ZSjRyLfYYGgSeORgIEAgQFAg4?= =?us-ascii?q?BAQWBUQI0KYEVEQhwFTsqAYJBgg8MFxRtAQiCQoUUhQQ6AXIBgSiPJwEB?=
X-IronPort-AV: E=Sophos;i="5.60,477,1549929600"; d="scan'208";a="276806708"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 May 2019 16:47:22 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x4GGlMDO026000 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2019 16:47:22 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 11:47:21 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 11:47:20 -0500
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 May 2019 12:47:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=12G+gFAtvPfENVGWVwdlZJFgh3atI41Nguv3dRVhTwM=; b=Ifud9V0komUKtQ8rA0pMxB99F2ytjNPI061h6zYxzjbz53ENT/Pls60vUyk2DAzKQT3RcwqJDBiPB/Wz2bHeOhmMhcgCb620D1XdBGuD9kV0O146iJYfNczYlsuKCkZVrmjXkqXPcN5z839fGY96+0f7/T56n8M1I7y56qHNI7w=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2138.namprd11.prod.outlook.com (10.174.107.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Thu, 16 May 2019 16:47:19 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1900.010; Thu, 16 May 2019 16:47:19 +0000
From: "Reshad Rahman (rrahman)" 
To: Benjamin Kaduk 
CC: The IESG , "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
Thread-Index: AQHVBRe+rV3duncRlUSQ6Gy9iRmrQ6ZkqNGAgAfPtACAAUg9AA==
Date: Thu, 16 May 2019 16:47:18 +0000
Message-ID: <3459B2F7-BACA-4E69-B952-1ED19B3F0BC4@cisco.com>
References: <155726272794.32635.6531627027808857417.idtracker@ietfa.amsl.com> <6F96C6CD-B0F1-44F2-A2BE-E2FD23B309CC@cisco.com> <20190515171219.GF14483@kduck.mit.edu>
In-Reply-To: <20190515171219.GF14483@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7e54071e-deae-4336-f84c-08d6da1e28fc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2138; 
x-ms-traffictypediagnostic: DM5PR1101MB2138:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0039C6E5C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(39860400002)(346002)(396003)(51444003)(51914003)(189003)(199004)(446003)(36756003)(30864003)(53946003)(14444005)(11346002)(46003)(2616005)(229853002)(86362001)(53936002)(2906002)(6436002)(81156014)(81166006)(25786009)(8676002)(561944003)(256004)(33656002)(6916009)(83716004)(6306002)(6116002)(476003)(68736007)(486006)(5660300002)(71200400001)(82746002)(478600001)(71190400001)(66556008)(73956011)(99286004)(6486002)(966005)(66476007)(7736002)(102836004)(14454004)(4326008)(6246003)(186003)(2171002)(58126008)(316002)(6512007)(76116006)(53546011)(54906003)(305945005)(6506007)(66946007)(91956017)(8936002)(76176011)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2138; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: awXeIXPve/eLkcymanWOKOu73kc4R2HrO1LT9BpT0+S/2dAV5sTe12JpPw/nLfcXmTtPoFWnZ2UlOU8TGVh9AXAonqXjWmD0WyyE/O+sVx1/n9cYa3v1bDWgWRKFWKe1uSDvcxkv8FTF7CmBMQtgRoODIm2vLEeCcQIAIL54ZNJsiPEcczGz2U9YoNs+hIfdY0nEHLh3yle62tOy5Pb2y97GbsDpaLN9rBlb1Km2KysRGLC34WEAg+scXZyNvpCMiKvnWjHbgQc5f+ab12B78dSS+otkdx3+uuLZajauBHzt5nrPPP5Vv38qOEBjyxnocZH98lPRKFgAaL4uNQM40Y+XNRmKKMi1+Fd3t53nmOSCo6KGpTOoxn+ihxkdOFtZbpsaC3qTe7peisQl3wZ8VDFojzUQAwx0DmtXCjdAX4U=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5F2A7CE27DE6A7419FB28C3DA97DC094@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e54071e-deae-4336-f84c-08d6da1e28fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2019 16:47:18.9504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2138
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 16:47:35 -0000

SGksDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQrvu79PbiAyMDE5LTA1LTE1LCAxOjE1IFBNLCAi
QmVuamFtaW4gS2FkdWsiIDxrYWR1a0BtaXQuZWR1PiB3cm90ZToNCg0KICAgIE9uIEZyaSwgTWF5
IDEwLCAyMDE5IGF0IDA5OjU1OjA4UE0gKzAwMDAsIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIHdy
b3RlOg0KICAgID4gSGksDQogICAgPiANCiAgICA+IFRoYW5rcyBmb3IgdGhlIHJldmlldywgcGxl
YXNlIHNlZSBpbmxpbmUuDQogICAgPiANCiAgICA+IE9uIDIwMTktMDUtMDcsIDQ6NTkgUE0sICJC
ZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToN
CiAgICA+IA0KICAgID4gICAgIEJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp
bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4gICAgIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0
Y29uZi1ub3RpZi0xMzogRGlzY3Vzcw0KICAgID4gICAgICAgICANCiAgICA+ICAgICBQbGVhc2Ug
cmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0
ZXJpYS5odG1sDQogICAgPiAgICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND
VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICA+ICAgICANCiAgICA+ICAgICANCiAgICA+
ICAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu
IGJlIGZvdW5kIGhlcmU6DQogICAgPiAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLw0KICAgID4gICAgIA0KICAgID4g
ICAgIA0KICAgID4gICAgIA0KICAgID4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+ICAgICBESVND
VVNTOg0KICAgID4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+ICAgICANCiAgICA+ICAgICBUaGFu
a3MgZm9yIHRoZSB3ZWxsLXdyaXR0ZW4gZG9jdW1lbnQhICBJICBqdXN0IGhhdmUgc29tZSBib3Jp
bmcgaG91c2VjbGVhbmluZw0KICAgID4gICAgIHBvaW50cyB0aGF0IHNob3VsZCBiZSBlYXN5IHRv
IHJlc29sdmUuDQogICAgPiAgICAgDQogICAgPiAgICAgU2VjdGlvbiAzLjIgc3RhdGVzOg0KICAg
ID4gICAgIA0KICAgID4gICAgICAgIFN1YnNjcmliZXJzIGNhbiBsZWFybiB3aGF0IGV2ZW50IHN0
cmVhbXMgYSBSRVNUQ09ORiBzZXJ2ZXIgc3VwcG9ydHMNCiAgICA+ICAgICAgICBieSBxdWVyeWlu
ZyB0aGUgInN0cmVhbXMiIGNvbnRhaW5lciBvZiBpZXRmLXN1YnNjcmliZWQtDQogICAgPiAgICAg
ICAgbm90aWZpY2F0aW9uLnlhbmcgaW4NCiAgICA+ICAgICAgICBbSS1ELmRyYWZ0LWlldGYtbmV0
Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLiAgU3VwcG9ydCBmb3IgdGhlDQogICAgPiAg
ICAgICAgInN0cmVhbXMiIGNvbnRhaW5lciBvZiBpZXRmLXJlc3Rjb25mLW1vbml0b3JpbmcueWFu
ZyBpbiBbUkZDODA0MF0gaXMNCiAgICA+ICAgICAgICBub3QgcmVxdWlyZWQuICBJZiBpdCBpcyBz
dXBwb3J0ZWQsIHRoZSBldmVudCBzdHJlYW1zIHdoaWNoIGFyZSBpbiB0aGUNCiAgICA+ICAgICAg
ICAic3RyZWFtcyIgY29udGFpbmVyIG9mIGlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLnlh
bmcgU0hPVUxEIGFsc28NCiAgICA+ICAgICAgICBiZSBpbiB0aGUgInN0cmVhbXMiIGNvbnRhaW5l
ciBvZiBpZXRmLXJlc3Rjb25mLW1vbml0b3JpbmcueWFuZy4NCiAgICA+ICAgICANCiAgICA+ICAg
ICBUaGlzICJTSE9VTEQiIHNlZW1zIHRvIGJlIGF0dGVtcHRpbmcgdG8gaW1wb3NlIGEgbm9ybWF0
aXZlIHJlcXVpcmVtZW50DQogICAgPiAgICAgb24gc3BlY2lmaWNhdGlvbnMgdGhhdCBpbXBsZW1l
bnQNCiAgICA+ICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z
IGFuZCBSRkMgODA0MCBzdHJlYW1zLA0KICAgID4gICAgIHdpdGhvdXQgcmVnYXJkIHRvIHdoZXRo
ZXIgdGhleSBpbXBsZW1lbnQgdGhpcyBzcGVjaWZpY2F0aW9uLiAgSXQgc2VlbXMNCiAgICA+ICAg
ICBiZXR0ZXItcGxhY2VkIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNh
dGlvbnMuDQogICAgPiA8UlI+IFJGQzgwNDAgaXMgdGhlIFJFU1RDT05GIFJGQyBhbmQgc3Vic2Ny
aWJlZC1ub3RpZmljYXRpb25zIGlzIG5vdA0KICAgID4gICB0cmFuc3BvcnQgc3BlY2lmaWMuIFNp
bmNlIHRoaXMgZG9jdW1lbnQgaXMgZm9yIFJFU1RDT05GLCB0aGlzIGlzIHdoeSB3ZQ0KICAgIA0K
ICAgIEFoLCBvZiBjb3Vyc2U7IEkgZmFpbGVkIHRvIGludGVybmFsaXplIHRoYXQgUkZDIDgwNDAg
aXMgUkVTVENPTkYtc3BlY2lmaWMNCiAgICBpbiBteSBxdWljayBjaGVjayBvZiB0aGUgcmVmZXJl
bmNlLg0KICAgIA0KICAgID4gICBoYXZlIGFkZGVkIHRoaXMgc3RhdGVtZW50IGluIHRoaXMgZG9j
dW1lbnQuDQogICAgDQogICAgU28gSSBhZ3JlZSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgdGhlIG9u
bHkgcmVhc29uYWJsZSBwbGFjZSB0byBjb252ZXkgdGhpcw0KICAgIGluZm9ybWF0aW9uLCBidXQg
dGhlIGN1cnJlbnQgcHJlc2VudGF0aW9uIHN0aWxsIGZlZWxzIHJhdGhlciBvZGQgdG8gbWUuDQog
ICAgSnVzdCB0byBjaGVjayBteSB1bmRlcnN0YW5kaW5nLCB0aGUgc2l0dWF0aW9uIGNvdWxkIGJl
IHN1bW1hcml6ZWQgYXMNCiAgICAiW3N1YnNjcmliZWQtbm90aWZpY2F0aW9uc10gZGVmaW5lcyBh
ICJzdHJlYW1zIiBjb250YWluZXIsIGFuZCA4MDQwDQogICAgZGVzY3JpYmVzIGEgZGlmZmVyZW50
ICJzdHJlYW1zIiBjb250YWluZXIsIGJ1dCBpZiBib3RoIGNvbnRhaW5lcnMgYXJlDQogICAgcHJl
c2VudC9zdXBwb3J0ZWQsIHRoZW4gYW55dGhpbmcgaW4gdGhlIG9uZSBmcm9tIFtzdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnNdDQogICAgc2hvdWxkIGFsc28gYmUgdmlzaWJsZSBpbiB0aGUgb25lIGZy
b20gODA0MCI/DQogICAgDQogICAgVG8gbWUsIHRoaXMgaGFzIGEgbGFyZ2UgY29tcG9uZW50IG9m
ICJkb2N1bWVudCBBIHNwZWNpZnlpbmcgdGhlIGludGVyYWN0aW9uDQogICAgb2YgZG9jdW1lbnRz
IEIgYW5kIEMiLCB3aGljaCBub3JtYWxseSB3b3VsZCByZXF1aXJlIGFuICJVcGRhdGVzIg0KICAg
IHJlbGF0aW9uc2hpcCB0byBlaXRoZXIgQiBvciBDIChvciwgaWYgQiBvciBDIGFyZSBub3QgUkZD
cyB5ZXQsIGp1c3QgbW92aW5nDQogICAgdGhlIHRleHQpLiAgSSB1bmRlcnN0YW5kIHRoYXQgaW4g
dGhpcyBjYXNlIHRoaW5ncyBhcmUgc29tZXdoYXQgZGlmZmVyZW50LA0KICAgIGFzIGRvY3VtZW50
IEEgKGkuZS4sIHRoaXMgZG9jdW1lbnQpIGlzIHNwZWNpZnlpbmcgdGhlIHRyYW5zcG9ydCBzY2hl
bWUgZm9yDQogICAgZG9jdW1lbnQgQiAoc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zKSB1c2luZyB0
aGUgcHJvdG9jb2wgZnJvbSBkb2N1bWVudCBDLg0KICAgIEFzIHN1Y2gsIGFueXRoaW5nIHRoYXQg
ZGVzY3JpYmVzIGludGVyYWN0aW9ucyBhYm91dCBkb2N1bWVudCBCIHRoYXQgYXJlDQogICAgc3Bl
Y2lmaWMgdG8gd2hlbiBpdCBpcyBjYXJyaWVkIG92ZXIgZG9jdW1lbnQgQyBtdXN0IGJlIGluIHRo
aXMgZG9jdW1lbnQsDQogICAgYnV0IHRoaXMgc3BlY2lmaWMgbWF0dGVyIGZlZWxzIGxlc3MgbGlr
ZSBzb21ldGhpbmcgYWJvdXQgaG93IHRoZSBwcm90b2NvbA0KICAgIGlzIGVuY29kZWQgKGkuZS4s
IHRoZSBtYWluIGZvY3VzIG9mIHRoaXMgZG9jdW1lbnQpIGFuZCByYXRoZXIgYW4NCiAgICBpbnRl
cmFjdGlvbiBiZXR3ZWVuIHByb3Rjb2wgZmVhdHVyZXMuDQogICAgDQogICAgSSBkb24ndCBoYXZl
IGEgZ3JlYXQgcHJvcG9zYWwgZm9yIGFueXRoaW5nIHNwZWNpZmljIHRvIGNoYW5nZSB0aGF0IHdv
dWxkDQogICAgYWxsZXZpYXRlIG15IGNvbmNlcm4sIHRob3VnaCAoYW5kIGFzIHN1Y2ggSSB3aWxs
IHN0b3AgaG9sZGluZyB0aGlzIGFzIGENCiAgICBEaXNjdXNzIHBvaW50KSwgdGhvdWdoIEkgaG9w
ZSBteSBjb2xsZWFndWVzIG9uIHRoZSBJRVNHIG1heSBoYXZlIHNvbWUNCiAgICBhZGRpdGlvbmFs
IHRob3VnaHRzLiAgVGhlIGJlc3QgdGhpbmcgSSBjYW4gY29tZSB1cCB3aXRoIHJpZ2h0IG5vdyB3
b3VsZCBiZQ0KICAgIHRvIHNheToNCiAgICANCiAgICAgIEluIHRoZSBjYXNlIHdoZW4gdGhlIFJF
U1RDT05GIGJpbmRpbmcgc3BlY2lmaWVkIGJ5IHRoaXMgZG9jdW1lbnQgaXMgdXNlZA0KICAgICAg
dG8gY29udmV5IHRoZSAic3RyZWFtcyIgY29udGFpbmVyIGZyb20gaWV0Zi1yZXN0Y29uZi1tb25p
dG9yaW5nLnlhbmcNCiAgICAgIChpLmUuLCB0aGF0IGZlYXR1cmUgaXMgc3VwcG9ydGVkKSwgYW55
IGV2ZW50IHN0cmVhbXMgY29udGFpbmVkIHRoZXJlaW4NCiAgICAgIGFyZSBhbHNvIGV4cGVjdGVk
IHRvIGJlIHByZXNlbnQgaW4gdGhlICJzdHJlYW1zIiBjb250YWluZXIgb2YNCiAgICAgIGlldGYt
cmVzdGNvbmYtbW9uaXRvcmluZy55YW5nLg0KICA8UlIyPiBJJ20gb2sgd2l0aCB0aGlzIHRleHQs
IHdpbGwgY2hlY2sgd2l0aCBjby1hdXRob3JzLiANCiAgDQogICAgRmVlZGJhY2sgaXMgd2VsY29t
ZSENCiAgICANCiAgICA+ICAgICBTaW1pbGFybHksIHdoZW4gU2VjdGlvbiA0IHdyaXRlczoNCiAg
ICA+ICAgICANCiAgICA+ICAgICAgICBUbyBtZWV0IHN1YnNjcmlwdGlvbiBxdWFsaXR5IG9mIHNl
cnZpY2UgcHJvbWlzZXMsIHRoZSBwdWJsaXNoZXIgTVVTVA0KICAgID4gICAgICAgIHRha2UgYW55
IGV4aXN0aW5nIHN1YnNjcmlwdGlvbiAiZHNjcCIgYW5kIGFwcGx5IGl0IHRvIHRoZSBEU0NQDQog
ICAgPiAgICAgICAgbWFya2luZyBpbiB0aGUgSVAgaGVhZGVyLg0KICAgID4gICAgIA0KICAgID4g
ICAgIHRoYXQgc2VlbXMgdG8gYmUgZHVwbGljYXRpbmcgYSBub3JtYXRpdmUgcmVxdWlyZW1lbnQg
ZnJvbSB0aGUgY29yZQ0KICAgID4gICAgIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBkb2N1bWVu
dC4gIChBbmQgSSdtIHN1cmUgTWFnbnVzIHdpbGwgaGF2ZQ0KICAgID4gICAgIGZ1cnRoZXIgZm9s
bG93LXVwIGFib3V0IGhvdyBEU0NQIG1hcmtpbmdzIGFyZSBwZXItY29ubmVjdGlvbiBmb3IgdGhl
DQogICAgPiAgICAgc3RyZWFtIHRyYW5zcG9ydHMgd2UgaGF2ZSBhdmFpbGFibGUsIGFzIHdlbGwu
KQ0KICAgID4gPFJSPiBZb3UgYXJlIGNvcnJlY3QsIHRoaXMgdGV4dCBjYW4gYmUgcmVtb3ZlZC4g
ICBJIGNhbiByZXBsYWNlIGl0IHdpdGggYSByZWZlcmVuY2UgdG8gdGhlIHNlY3Rpb24gaW4gc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zLCB3b3VsZCB0aGF0IHdvcmsgZm9yIHlvdT8NCiAgICANCiAg
ICBUaGF0IHdvcmtzIGZvciBtZTsgdGhhbmtzLg0KICAgIA0KICAgID4gICAgIA0KICAgID4gICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiAgICA+ICAgICBDT01NRU5UOg0KICAgID4gICAgIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCiAgICA+ICAgICANCiAgICA+ICAgICBUaGUgY29yZSBzdWJzY3JpYmVkLW5vdGlmaWNhdGlv
bnMgZG9jdW1lbnQgbm90ZXMgdGhhdCBkeW5hbWljDQogICAgPiAgICAgc3Vic2NyaXB0aW9ucyBv
bmx5IGxhc3QgYXMgbG9uZyBhcyB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQuICBJbiB0aGlzDQog
ICAgPiAgICAgZG9jdW1lbnQsIHdlIGhhdmUgdHdvIGNvbm5lY3Rpb25zIGluIEZpZ3VyZSAxLCB3
aGljaCBjb3VsZCBwb3RlbnRpYWxseQ0KICAgID4gICAgIGJlIHNlcGFyYXRlIFRDUC9UTFMgY29u
bmVjdGlvbnMgKG9yIEhUVFAvMiBzdHJlYW1zKS4gIEluIHRoZSAidHdvIFRDUA0KICAgID4gICAg
IGNvbm5lY3Rpb25zIiBjYXNlLCBkb2VzIHRlcm1pbmF0aW5nIGVpdGhlciBvbmUgY2F1c2UgdGhl
IGNlc3NhdGlvbiBvZg0KICAgID4gICAgIHRoZSBzdWJzY3JpcHRpb24sIG9yIGp1c3QgKGIpPw0K
ICAgID4gPFJSPiBUaGVyZSBhcmUgbm8gImxvbmctbGl2ZWQgUkVTVENPTkYgc2Vzc2lvbnMiLiBU
ZXJtaW5hdGluZyAoYSkgZG9lcyBub3QgdGVybWluYXRlIHRoZSBzdWJzY3JpcHRpb24uDQogICAg
DQogICAgT2theS4gIFRoaXMgd2FzIG5vdCBjbGVhciB0byBtZSwgYSBub24tZXhwZXJ0IGluIHRo
ZSBmaWVsZCwgYnV0IGlmIHlvdQ0KICAgIHRoaW5rIGl0J3MgY2xlYXIgdG8gdGhlIHRhcmdldCBh
dWRpZW5jZSBJIHdvbid0IGFzayBmb3IgYW55IHRleHQgY2hhbmdlcw0KICAgIHRvIGNsYXJpZnku
DQo8UlIyPiBJJ2xsIG11bGwgaXQgb3ZlciwgcmlnaHQgbm93IEknbSBsZWFuaW5nIHRvd2FyZHMg
bm8gYWRkaXRpb25hbCB0ZXh0IHNpbmNlIHVuZGVyc3RhbmRpbmcgUkVTVENPTkYgaXMgbmVlZGVk
Lg0KICAgIA0KICAgID4gICAgIFNlY3Rpb24gMg0KICAgID4gICAgIA0KICAgID4gICAgIFBsZWFz
ZSB1c2UgdGhlIGJvaWxlcnBsYXRlIGZyb20gUkZDIDgxNzQuDQogICAgPiA8UlI+IEFjaywgd2ls
bCBkbyBpbiBuZXh0IHJldi4NCiAgICA+ICAgICANCiAgICA+ICAgICBTZWN0aW9uIDMNCiAgICA+
ICAgICANCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFlB
TkcgZGF0YXN0b3JlIHN1YnNjcmlwdGlvbiBpcw0KICAgID4gICAgICAgIGFjY29tcGxpc2hlZCB2
aWEgYXVnbWVudGF0aW9ucyB0bw0KICAgID4gICAgICAgIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25m
LXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10gYXMgZGVzY3JpYmVkIHdpdGhpbg0KICAgID4gICAg
ICAgIFtJLUQuaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0gU2VjdGlvbiA0LjQuDQogICAgPiAgICAg
DQogICAgPiAgICAgSSBzZWUgc29tZSByZXZpZXdlcnMgY29tbWVudGVkIHRoYXQgdGhpbmdzIHdl
cmUgYSBiaXQgdGVyc2UvYXJjYW5lOyBJDQogICAgPiAgICAgbWlnaHQgc3VnZ2VzdCB0aGF0ICJ2
aWEgYXVnbWVudGF0aW9ucyB0byBbc3Vic2NyaWJlZCBub3RpZmljYXRpb25zXSIgaXMNCiAgICA+
ICAgICBub3QgcmVhbGx5IGFkZGluZyBtdWNoIGhlcmUsIGFuZCB0aGUgeWFuZy1wdXNoIFJQQ3Mg
YXJlIHRoZSBpbXBvcnRhbnQNCiAgICA+ICAgICBwYXJ0Lg0KICAgID4gPFJSPiBUaGUgYXVnbWVu
dGF0aW9uIHRvIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBpcyBtZW50aW9uZWQgYmVjYXVzZSBp
dCBpcyBuZWVkZWQgZm9yIFJFU1RDT05GLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgY2hhbmdlIHRo
aXMgdG8gIi4uLmFjY29tcGxpc2hlZCBhcyBkZXNjcmliZWQgaW4gIFtJLUQuaWV0Zi1uZXRjb25m
LXlhbmctcHVzaF0gU2VjdGlvbiA0LjQuIj8NCiAgICANCiAgICBUaGF0J3MgbXkgc3VnZ2VzdGlv
biwgeWVzIChidXQgZmVlbCBmcmVlIHRvIGlnbm9yZSBpdCkuDQo8UlIyPiBJIHNlZSB2YWx1ZSBp
biBrZWVwaW5nIHRoZSBhdWdtZW50YXRpb24gdG8gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGlu
IHRoZSB0ZXh0LCBJJ2xsIGRpc2N1c3Mgd2l0aCBjby1hdXRob3JzLg0KICAgIA0KICAgID4gICAg
IFNlY3Rpb24gMy4xDQogICAgPiAgICAgDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hlcmUgcXVpY2sNCiAgICA+ICAg
ICAgICByZWNvZ25pdGlvbiBvZiB0aGUgbG9zcyBvZiBhIHB1Ymxpc2hlciBpcyByZXF1aXJlZCwg
YSBzdWJzY3JpYmVyDQogICAgPiAgICAgICAgU0hPVUxEIHVzZSBhIFRMUyBoZWFydGJlYXQgW1JG
QzY1MjBdLCBqdXN0IGZyb20gcmVjZWl2ZXIgdG8NCiAgICA+ICAgICAgICBwdWJsaXNoZXIsIHRv
IHRyYWNrIEhUVFAgc2Vzc2lvbiBjb250aW51aXR5Lg0KICAgID4gICAgIA0KICAgID4gICAgIFRM
UyBoZWFydGJlYXRzIHJlcXVpcmUgaW5pdGlhdGlvbiBieSB0aGUgVExTIGNsaWVudCwgYnkgdmly
dHVlIG9mDQogICAgPiAgICAgaW5jbHVkaW5nIHRoZSBIZWFydGJlYXRFeHRlbnNpb24gaW4gdGhl
IENsaWVudEhlbGxvLiAgV2hvIGlzIGdvaW5nIHRvIGJlDQogICAgPiAgICAgbWFraW5nIHRoZSBk
ZXRlcm1pbmF0aW9uIHRoYXQgcXVpY2sgcmVjb2duaXRpb24gaXMgcmVxdWlyZWQsIGFuZCBpZg0K
ICAgID4gICAgIHRoYXQncyB0aGUgcHVibGlzaGVyLCBob3cgZG9lcyB0aGUgc3Vic2NyaWJlciBr
bm93IHRvIHVzZSBUTFMNCiAgICA+ICAgICBoZWFydGJlYXRzPw0KICAgID4gPFJSPiBUaGUgc3Vi
c2NyaWJlciBpcyB0aGUgb25lIG1ha2luZyB0aGF0IGRldGVybWluYXRpb24gc2luY2UgdGhpcyBp
cyB0byByZWNvZ25pemUgdGhlIGxvc3Mgb2YgdGhlIHB1Ymxpc2hlci4NCiAgICANCiAgICBPa2F5
LiAgSSB0aGluayB0aGF0IG1lYW5zIGFsbCB0aGUgdGVjaG5pY2FsIHBpZWNlcyB3b3JrIHRvZ2V0
aGVyIGFzIG5lZWRlZCwNCiAgICBidXQgdGhlcmUgY291bGQgcGVyaGFwcyBiZSBtb3JlIHByZWNp
c2lvbiBpbiB0aGUgdGV4dCBhYm91dCB0aGUgZXhwZWN0ZWQNCiAgICBiZWhhdmlvci4gIChOb3Rl
IHRoYXQgdGhpcyBpcyBhIG5vbi1ibG9ja2luZyBjb21tZW50LCBvZiBjb3Vyc2UuKQ0KPFJSPiBJ
IHdpbGwgKHRyeSB0bykgY2xhcmlmeSB0aGUgdGV4dC4NCiAgICANCiAgICA+ICAgICBuaXQ6IEl0
J3MgaW50ZXJlc3RpbmcgdGhhdCB3ZSBzZWVtIHRvIGJlIHVzaW5nIGJvdGggInN1YnNjcmliZXIi
IGFuZA0KICAgID4gICAgICJyZWNlaXZlciIgdG8gdGFsayBhYm91dCB0aGUgVExTIGNsaWVudCwg
aW4gdGhlIHNhbWUgc2VudGVuY2UuDQogICAgPiA8UlI+IFdpbGwgY2hhbmdlIHRvIHN1YnNjcmli
ZXIuDQogICAgPiAgICAgDQogICAgPiAgICAgc2lkZSBub3RlOiBwZXIgaHR0cHM6Ly9naXRodWIu
Y29tL29wZW5zc2wvb3BlbnNzbC9wdWxsLzE5MjgsIE9wZW5TU0wNCiAgICA+ICAgICB3aWxsIG5v
dCBzdXBwb3J0IFRMUyBvciBEVExTIGhlYXJ0YmVhdHMgb2YgYW55IGZvcm0gaW4gaXRzIG5leHQg
bWFqb3INCiAgICA+ICAgICByZWxlYXNlICgzLjAuMCkuDQogICAgPiAgICAgDQogICAgPiAgICAg
ICAgTG9zcyBvZiB0aGUgaGVhcnRiZWF0IE1VU1QgcmVzdWx0IGluIGFueSBzdWJzY3JpcHRpb24g
cmVsYXRlZCBUQ1ANCiAgICA+ICAgICAgICBzZXNzaW9ucyBiZXR3ZWVuIHRob3NlIGVuZHBvaW50
cyBiZWluZyB0b3JuIGRvd24uICBBIHN1YnNjcmliZXIgY2FuDQogICAgPiAgICAgICAgdGhlbiBh
dHRlbXB0IHRvIHJlLWVzdGFibGlzaCB0aGUgZHluYW1pYyBzdWJzY3JpcHRpb24gYnkgdXNpbmcg
dGhlDQogICAgPiAgICAgICAgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuDQogICAg
PiAgICAgDQogICAgPiAgICAgUkZDIDY1MjAgZG9lcyBub3Qgc3BlY2lmeSByZXRyYW5zbWl0IG51
bWJlcnMgb3IgaW50ZXJ2YWxzIHRvIGJlIHVzZWQgdG8NCiAgICA+ICAgICBkZXRlcm1pbmUgdGhh
dCBhIHBlZXIgaXMgbm9ucmVzcG9uc2l2ZSAoaS5lLiwgImxvc3QiKSwgc28gdGhpcyB0ZXh0DQog
ICAgPiAgICAgc2VlbXMgdW5kZXItc3BlY2lmaWVkLiAgSXMgdGhlIGludGVudCB0byBsZWF2ZSB0
aGVzZSBkZWNpc2lvbnMgdG8gYmUNCiAgICA+ICAgICBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYz8N
CiAgICA+IDxSUj4gWWVzIHRoaXMgaXMgdGhlIGludGVudCBzaW5jZSBpdCBhbGwgZGVwZW5kcyBv
biB3aGF0IHRoZSBzdWJzY3JpYmVyIG5lZWRzL3dpc2hlcy4NCiAgICANCiAgICBJdCBtYXkgYmUg
d29ydGggbWVudGlvbmluZyBleHBsaWNpdGx5IHRoYXQgdGhpcyBpcyB0byBiZQ0KICAgIGltcGxl
bWVudGF0aW9uLXNwZWNpZmljLCBidXQgaXQncyB5b3VyIGNhbGwuDQo8UlIyPiBJIHdpbGwgbWVu
dGlvbiBpdCBleHBsaWNpdGx5Lg0KICAgIA0KICAgID4gICAgIFNlY3Rpb24gMy4zDQogICAgPiAg
ICAgDQogICAgPiAgICAgSSBzZWUgdGhhdCBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1u
b3RpZmljYXRpb25zIChzZWN0aW9uIDIuNC42KQ0KICAgID4gICAgIGFkbW9uaXNoZXMgdXMgdG8g
Y2hlY2sgZm9yIHRyYW5zcG9ydC1sYXllciBlcnJvcnMgKGFuZCBBQ0xzISkgYmVmb3JlDQogICAg
PiAgICAgUlBDLWxldmVsIGVycm9yczsgaXMgdGhlIHRleHQgaGVyZSBhYm91dCAiZmFpbHMgdG8g
c2VydmUgdGhlIFJQQw0KICAgID4gICAgIHJlcXVlc3QiIGFuZCBvdXIgZGVzY3JpcHRpb24gb2Yg
ZXJyb3IgaGFuZGxpbmcgY29uc2lzdGVudCB3aXRoIHRoZQ0KICAgID4gICAgIHNlcGFyYXRlIHRy
YW5zcG9ydC1sYXllciBlcnJvciBoYW5kbGluZz8gIChJIHRoaW5rIGl0IGNhbiBiZSwgd2l0aCBh
DQogICAgPiAgICAgY2FyZWZ1bCByZWFkaW5nIG9mICJvbmUgb2YgdGhlIHJlYXNvbnMgaW5kaWNh
dGVkIGluIFtdIFNlY3Rpb24gMi40LjYiLA0KICAgID4gICAgIGJ1dCBwZXJoYXBzIG90aGVyIHJl
YWRpbmdzIGFyZSBwb3NzaWJsZS4pDQogICAgPiA8UlI+IFllcyB0aGlzIHNlY3Rpb24gaXMgZm9y
IFJQQy1sZXZlbCBlcnJvcnMsIGl0IHJlZmVyZW5jZXMgMi40LjYgb2Ygc3Vic2NyaWJlZC1ub3Rp
ZmljYXRpb25zIHdoaWNoIHByb3ZpZGVkIGEgbGlzdCBvZiBwb3NzaWJsZSBlcnJvcnMuDQogICAg
DQogICAgVGhhbmtzIGZvciBjaGVja2luZy4NCiAgICANCiAgICA+ICAgICAgICAgICBUaGUgeWFu
Zy1kYXRhIGluY2x1ZGVkIHdpdGhpbiAiZXJyb3ItaW5mbyIgU0hPVUxEIE5PVCBpbmNsdWRlIHRo
ZQ0KICAgID4gICAgICAgICAgIG9wdGlvbmFsIGxlYWYgImVycm9yLXJlYXNvbiIsIGFzIHN1Y2gg
YSBsZWFmIHdvdWxkIGJlIHJlZHVuZGFudA0KICAgID4gICAgICAgICAgIHdpdGggaW5mb3JtYXRp
b24gdGhhdCBpcyBhbHJlYWR5IHBsYWNlZCB3aXRoaW4gdGhlDQogICAgPiAgICAgICAgICAgImVy
cm9yLWFwcC10YWciLg0KICAgID4gICAgIA0KICAgID4gICAgIEknbSBub3Qgc3VyZSB3aGVyZSB0
aGlzICJlcnJvci1yZWFzb24iIGxlYWYgaXMgZGVmaW5lZCAtLSBJIGRvbid0IHNlZSBpdA0KICAg
ID4gICAgIGluIGFueSBvZiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMsIHlhbmctcHVzaCwgb3Ig
UkZDIDgwNDAuDQogICAgPiA8UlI+R29vZCBjYXRjaCwgIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUg
InJlYXNvbiIgZnJvbSB5YW5nLXB1c2gsIHdpbGwgY2hlY2suICAgIA0KICAgIA0KICAgIFRoYW5r
czsgaXQncyBnb29kIHRvIGtub3cgdGhlcmUncyBwcm9iYWJseSBhIHJlYXNvbiB3aHkgSSB3YXMg
Y29uZnVzZWQgOikNCiAgICANCiAgICA+ICAgICBTZWN0aW9uIDMuNA0KICAgID4gICAgIA0KICAg
ID4gICAgIEknbSBub3Qgc3VyZSB0aGF0IEkndmUgcHJldmlvdXNseSBlbmNvdW50ZXJlZCB1c2lu
ZyB0aGUgc2VjdGlvbiBoZWFkaW5nDQogICAgPiAgICAgdG8gaW50cm9kdWNlIGFuIGFjcm9ueW0g
KGFzIGlzIGRvbmUgaGVyZSBmb3IgU1NFKS4gIEkgYmV0IHRoZSBSRkMgRWRpdG9yDQogICAgPiAg
ICAgd2lsbCBkbyB0aGUgcmlnaHQgdGhpbmcsIHRob3VnaC4NCiAgICA+IDxSUj4gSSdsbCBtb3Zl
IHRoZSBhY3JvbnltIHRvIHRoZSBzZWN0aW9uIHRleHQNCiAgICA+ICAgICANCiAgICA+ICAgICAg
ICBvICBJbiBhZGRpdGlvbiB0byBhbiBSUEMgcmVzcG9uc2UgZm9yIGEgIm1vZGlmeS1zdWJzY3Jp
cHRpb24iIFJQQw0KICAgID4gICAgICAgICAgIHRyYXZlbGluZyBvdmVyIChhKSwgYSAic3Vic2Ny
aXB0aW9uLW1vZGlmaWVkIiBzdGF0ZSBjaGFuZ2UNCiAgICA+ICAgICAgICAgICBub3RpZmljYXRp
b24gTVVTVCBiZSBzZW50IHdpdGhpbiAoYikuICBUaGlzIGFsbG93cyB0aGUgcmVjZWl2ZXIgdG8N
CiAgICA+ICAgICAgICAgICBrbm93IGV4YWN0bHkgd2hlbiB0aGUgbmV3IHRlcm1zIG9mIHRoZSBz
dWJzY3JpcHRpb24gaGF2ZSBiZWVuDQogICAgPiAgICAgICAgICAgYXBwbGllZCB0byB0aGUgbm90
aWZpY2F0aW9uIG1lc3NhZ2VzLiAgU2VlIGFycm93IChjKS4NCiAgICA+ICAgICANCiAgICA+ICAg
ICBuaXQ6IEkgbWlnaHQgc3VnZ2VzdCBzb21lIGxhbmd1YWdlIGFib3V0ICJvcmRlciB3aXRoaW4g
dGhlIG5vdGlmaWNhdGlvbnMNCiAgICA+ICAgICBzdHJlYW0iIGZvciB0aGlzIHN0YXRlIGNoYW5n
ZSwgYnV0IHRoYXQncyBwdXJlbHkgZWRpdG9yaWFsLg0KICAgID4gPFJSPiBTbyB5b3Ugd291bGQg
bGlrZSB0aGlzIHRleHQgY2hhbmdlZCB0byBjbGFyaWZ5IHRoZSBvcmRlciBvZiBldmVudHM/DQog
ICAgDQogICAgSWYgSSB3YXMgd3JpdGluZyBpdCwgSSdkIHNheSAiYWxsb3dzIHRoZSByZWNlaXZl
ciB0byBrbm93IGV4YWN0bHkgd2hlbiwNCiAgICB3aXRoaW4gdGhlIHN0cmVhbSBvZiBldmVudHMs
IHRoZSBuZXcgdGVybXMgb2YgdGhlIHN1YnNjcmlwdGlvbiBoYXZlIGJlZW4NCiAgICBhcHBsaWVk
IFsuLi5dIi4gIEJ1dCB5b3UncmUgd3JpdGluZyBpdCwgbm90IG1lLCBzbyBteSBvcGluaW9uIGRv
ZXNuJ3QgY291bnQNCiAgICBmb3IgbXVjaC4NCjxSUjI+IFRoaXMgdGV4dCBkb2VzIHNlZW0gY2xl
YXJlci4NCiAgICANCiAgICA+ICAgICAgICBvICBJbiBhZGRpdGlvbiB0byBhbnkgcmVxdWlyZWQg
YWNjZXNzIHBlcm1pc3Npb25zIChlLmcuLCBOQUNNKSwgUlBDcw0KICAgID4gICAgICAgICAgIG1v
ZGlmeS1zdWJzY3JpcHRpb24sIHJlc3luYy1zdWJzY3JpcHRpb24gYW5kIGRlbGV0ZS1zdWJzY3Jp
cHRpb24NCiAgICA+ICAgICAgICAgICBTSE9VTEQgb25seSBiZSBhbGxvd2VkIGJ5IHRoZSBzYW1l
IFJFU1RDT05GIHVzZXJuYW1lIFtSRkM4MDQwXQ0KICAgID4gICAgICAgICAgIHdoaWNoIGludm9r
ZWQgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbi4NCiAgICA+ICAgICANCiAgICA+ICAgICBJJ20gY29u
ZnVzZWQgYWJvdXQgdGhpcyAiU0hPVUxEIiAodGhlIHNlY2RpciByZXZpZXdlciBub3RlZCBpdCBh
cyB3ZWxsKQ0KICAgID4gICAgIC0tIGluIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBjb3JlIHN1YnNj
cmliZWQtbm90aWZpY2F0aW9ucyByZXF1aXJlcyB0aGF0DQogICAgPiAgICAgc3VjaCBSUENzIG11
c3QgYmUgZG9uZSBvbiB0aGUgc2FtZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBhcyB0aGUgb25lIHVz
ZWQNCiAgICA+ICAgICB0byBjcmVhdGUgYSBkeW5hbWljIHN1YnNjcmlwdGlvbiAoaS5lLiwgbGlu
ZSAoYSkgaW4gRmlndXJlIDEpLCBhbmQgc2luY2UNCiAgICA+ICAgICBSRkMgODA0MCBhdXRoZW50
aWNhdGVkIGNsaWVudCBpZGVudGl0aWVzIGFyZSBhdCB0aGUgY29ubmVjdGlvbiBsZXZlbCwNCiAg
ICA+ICAgICB0aGVyZSBjb3VsZCBuZXZlciBiZSBhbnkgY2hhbmdlIG9mIHVzZXJuYW1lIGFjcm9z
cyB0aGUgY2FsbHMuDQogICAgPiA8UlI+IFdoYXQgeW91IGRlc2NyaWJlIGFib3ZlIGlzIHRydWUg
Zm9yIG5ldGNvbmYgKGFsbCBkb25lIG9uIHNhbWUgc2Vzc2lvbi4gDQogICAgPiBIb3dldmVyIHJl
c3Rjb25mIGRvZXNuJ3Qgd29yayB0aGUgc2FtZSB3YXkgKG5vIGxvbmctbGl2ZWQgc2Vzc2lvbnMp
LCBzbyBzdWJzZXF1ZW50IFJQQ3MgY291bGQgYWN0dWFsbHkgYmUgb24gYSBkaWZmZXJlbnQgdHJh
bnNwb3J0IGNvbm5lY3Rpb24uDQogICAgPiBJIGRvIHJlY2FsbCB0aGUgc2VjZGlyIGNvbW1lbnRz
IGFuZCB5b3VyIGNvbW1lbnRzIHRvIG15IHJlc3BvbnNlLCBJIHdpbGwgaW5jbHVkZSB0aGUgdGV4
dCB5b3UgaGFkIHN1Z2dlc3RlZCB0byBqdXN0aWZ5IHRoZSBTSE9VTEQuDQogICAgDQogICAgVGhh
bmtzLg0KICAgIA0KICAgID4gICAgICAgIG8gIExvc3Mgb2YgVExTIGhlYXJ0YmVhdA0KICAgID4g
ICAgIA0KICAgID4gICAgIChBcyBub3RlZCBhYm92ZSwgdGhpcyBpcyB1bmRlci1zcGVjaWZpZWQg
YXQgcHJlc2VudC4pDQogICAgPiAgICAgDQogICAgPiAgICAgU2VjdGlvbiA5DQogICAgPiAgICAg
DQogICAgPiAgICAgSSB3b3VsZCBzdWdnZXN0IGFsc28gcmVjb21tZW5kaW5nIHRoYXQgdGhlICd1
cmknIHZhbHVlcyBub3QgaGF2ZSBhDQogICAgPiAgICAgcHJlZGljdGFibGUgc3RydWN0dXJlIG9y
IGJlIGd1ZXNzYWJsZS4gIFdoaWxlIHdlIGRvIGhhdmUgc29saWQgYWNjZXNzDQogICAgPiAgICAg
Y29udHJvbCBpbiBwbGFjZSB2aWEgTkFDTS9ldGMuLCB0aGVyZSBpcyBzdGlsbCBhIHJpc2sgb2Yg
c2lkZS1jaGFubmVsDQogICAgPiAgICAgbGVha2FnZSBpZiB0aGVyZSdzIGEgZGlzdGluY3Rpb24g
YmV0d2VlbiAicmVzb3VyY2UgZG9lcyBub3QgZXhpc3QiIGFuZA0KICAgID4gICAgICJub3QgYXV0
aG9yaXplZCIuICAoRllJIHdlIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB1bmd1ZXNzYWJs
ZSBVUklzDQogICAgPiAgICAgaW4gdGhlIGNvbnRleHQgb2YgZHJhZnQtaWV0Zi1hY21lLWFjbWUs
IHdoaWNoIGhhZCBhIG11Y2ggd2Vha2VyDQogICAgPiAgICAgYWNjZXNzLWNvbnRyb2wgc3Rvcnkg
YW5kIGNvdWxkIGluIHNvbWUgc2Vuc2UgYmUgc2FpZCB0byB1c2UgImNhcGFiaWxpdHkNCiAgICA+
ICAgICBVUklzIiwgaWYgYW55b25lIHdhbnRzIHRvIGRvIHNvbWUgYmFja2dyb3VuZCByZWFkaW5n
LikNCiAgICA+ICAgICAoT25lIG1pZ2h0IHNlZSBhbHNvIGRyYWZ0LWdvbnQtbnVtZXJpYy1pZHMt
c2VjLWNvbnNpZGVyYXRpb25zLikNCiAgICA+IDxSUj4gU2VjdGlvbiA5IHNheXMgIlRoZSBzdWJz
Y3JpcHRpb24gVVJJIGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIC4uLiIuIEkgY2FuIGFkZCB0
ZXh0LCBhcyB5b3Ugc3VnZ2VzdGVkLCB0byByZWNvbW1lbmQgdGhhdCB0aGUgdXJpIHZhbHVlcyBu
b3QgYmUgcHJlZGljdGFibGUuDQogICAgDQogICAgUGxlYXNlIGRvIC0tIEkgdGhpbmsgdGhpcyBp
cyBlYXN5IHRvIGRvIGFuZCBpbXByb3ZlcyB0aGUgcm9idXN0bmVzcyBvZiB0aGUNCiAgICBzeXN0
ZW0sIHNvIHdlIHNob3VsZCByZWNvbW1lbmQgaW1wbGVtZW50YXRpb25zIHRvIGRvIGl0IGV2ZW4g
aWYgdGhlcmUncyBub3QNCiAgICBhIHN0cmljdCBmdW5jdGlvbmFsIHJlcXVpcmVtZW50IHRvIGRv
IHNvLg0KPFJSMj4gV2lsbCBkby4NCg0KUmVnYXJkcywNClJlc2hhZC4NCiAgICANCiAgICA+ICAg
ICBJIHNlZSB0aGF0IHRoZSBzdWJzY3JpcHRpb24taWQgdHlwZSBpcyBvbmx5IG9mIHR5cGUgdWlu
dDMyIGluDQogICAgPiAgICAgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0
aW9ucywgd2hpY2ggdG8gc29tZSBleHRlbnQgbGltaXRzDQogICAgPiAgICAgdGhlIHVuZ3Vlc3Nh
YmlsaXR5IHByb3BlcnR5IHRvIHRoZSBVUklzIGFuZCBub3QgYXMgbXVjaCBmb3IgdGhlIElEcw0K
ICAgID4gICAgIHRoZW1zZWx2ZXMgKHRob3VnaCByYW5kb21pemF0aW9uIHdpdGhpbiBhIDMyLWJp
dCBzcGFjZSBpcyBub3Qgd2l0aG91dA0KICAgID4gICAgIHZhbHVlKS4NCiAgICA+ICAgICANCiAg
ICA+ICAgICBBcHBlbmRpeCBBDQogICAgPiAgICAgDQogICAgPiAgICAgQ29uc2lzdGVudCB3aXRo
IG15IHN1Z2dlc3Rpb24gaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLCBJJ2QgY2hhbmdl
DQogICAgPiAgICAgdGhlIHJldHVybmVkIFVSSSBoZXJlIG9yIGF0IGxlYXN0IG5vdGUgdGhhdCB0
aGUgIjIyIiwgIjIzIiwgZXRjLiBhcmUNCiAgICA+ICAgICBwbGFjZWhvbGRlcnMgYW5kIG5vdCBp
bmRpY2F0aXZlIG9mIGV4cGVjdGVkIHVzYWdlLg0KICAgID4gPFJSPiBJIHdpbGwgYWRkIGEgbm90
ZS4NCiAgICANCiAgICBUaGFua3MhDQogICAgDQogICAgLUJlbg0KICAgIA0KICAgID4gICAgIChU
aGlzIHNuaXBwZXQgZnJvbSBBLjEuMSkNCiAgICA+ICAgICANCiAgICA+ICAgICAgICB7DQogICAg
PiAgICAgICAgICAgImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOmlucHV0Ijogew0KICAg
ID4gICAgICAgICAgICAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjogIi9leGFtcGxlLW1vZHVsZTpm
b28vIiwNCiAgICA+ICAgICAgICAgICAgICAic3RyZWFtIjogIk5FVENPTkYiLA0KICAgID4gICAg
ICAgICAgICAgICJkc2NwIjogIjEwIg0KICAgID4gICAgICAgICAgIH0NCiAgICA+ICAgICAgICB9
DQogICAgPiAgICAgDQogICAgPiAgICAgVGhlIGFtYmlndWl0eSBvZiAiMTAiIGhhcyBiZWVuIG5v
dGVkIGVsc2V3aGVyZSwgYnV0IHNpbmNlIGl0J3MgYSB1aW50OA0KICAgID4gICAgIChyYW5nZSAi
MC4uNjMiKSB3b3VsZG4ndCBpdCBiZSBhIEpTT04gbnVtYmVyLCBub3QgYSBKU09OIHN0cmluZz8N
CiAgICA+IDxSUj4gWW91IGFyZSBjb3JyZWN0LCB3aWxsIGNoYW5nZSB0byAxMA0KICAgID4gICAg
IA0KICAgID4gICAgIFNpbWlsYXJseSwgc3Vic2NyaXB0aW9uIElEcyBhcmUgdWludDMyLCB3aGlj
aCBJSVVDIGdldHMgZW5jb2RlZCBhcyBhDQogICAgPiAgICAgbnVtYmVyLg0KICAgID4gPFJSPiBD
b3JyZWN0IGFnYWluLiAgICANCiAgICA+ICAgICANCiAgICA+IFJlZ2FyZHMsDQogICAgPiBSZXNo
YWQuDQogICAgPiANCiAgICANCg0K


From nobody Thu May 16 10:03:05 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5A0120043 for ; Thu, 16 May 2019 10:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V3iefQFGv1j9 for ; Thu, 16 May 2019 10:02:56 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 27B4A120025 for ; Thu, 16 May 2019 10:02:56 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id c17so3242059lfi.2 for ; Thu, 16 May 2019 10:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mCWWoZgrOlLj5Ro3Xdbyy7SH6dQyTTr+YDbnjLQe4Cg=; b=akkcpMAOi+R94CxpK4mbZ4qbQ/5I77LITBGAtxyJlWdkQDtql+3SPxmAmQ9rUSGPIN pK94HBtM6TtCYatJwgQ+l+lgOy5Q1dgzecPUv1u7xz+C0dXnIVPdTIEmj3PhPgusXyph GA99SiwIxEClhCZAvlLIHG04HW/bLT/hGdudWsqVHFj+ArSd7W1Q3q8WZeHeMpd95iAR zrU7w28ihyYvlLOt7bN7bv3nUfF4Un6MnW0juWrWk0DA8T4jEnbcASnVthqcgx5mT9zA QfwHmT1dHvLRyHGoPGir67F8d/nAFMV8L7BSDimvPKWSPyD8zY6ahhuzrucXmum3/PKM gQAA==
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=mCWWoZgrOlLj5Ro3Xdbyy7SH6dQyTTr+YDbnjLQe4Cg=; b=JTavUm7YKSkNCg/exKQnjfwn65Fy2fic9Cwi5/FPIcEcXW00/gBEYDKtsnCZP+Uakz qMOElu37JCSQ8qqwgnEBIND/SPxYf23qnNF24/blxWy2BRUUUIaEPDZAGcUn7LcZ2Hrc dRC2kwZjUDrEpCgVxj0R1EDUNtfoa6lX20KhJpJKyIBbXc5HYKor6FnfNoVLiERYL0O9 STrm2fFdGJRG1YBjlxHkzjFtRTig74Gxw351sdetbrbFTFNraT9ZSGrwlocn1HmZSVfR hRPA6cnilAGCVsNnbhIpJ4u5hvhetiMBU4WuCJM8BLgx7oI8VSX11YPCcOSHOot5bg/L tEng==
X-Gm-Message-State: APjAAAVKudqcAPbdQyJsZg6Q0Zoh1Ob7llMGavahGUQXSxj6z5m0MuLJ 6l4/icdzYDgl3tkBhH/O4aYTU5bWQhZ+xCJlDYkQxw==
X-Google-Smtp-Source: APXvYqyXesi9lHDsgdPOveMy5QzY6oBJ4FE7cnszPG5QGz/2JAqj+nb8H/0fXvLDiW4CY67GGgCUJBAIOvhfc+zFTBA=
X-Received: by 2002:a19:ae14:: with SMTP id f20mr24093060lfc.49.1558026174323;  Thu, 16 May 2019 10:02:54 -0700 (PDT)
MIME-Version: 1.0
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>  <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com>
In-Reply-To: <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com>
From: Andy Bierman 
Date: Thu, 16 May 2019 10:02:43 -0700
Message-ID: 
To: Kent Watsen 
Cc: Mahesh Jethanandani , "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000abf63e0589043c66"
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 17:03:03 -0000

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

On Wed, May 15, 2019 at 2:48 PM Kent Watsen  wrote:

>
>
> I don't think Erratum 5397 should be deleted. Though the original section
> 7.8 makes no mention of confirmed commits, section 7.9 does, but does not
> differentiate between a vanilla confirmed commit and a persistent confirmed
> commit. Since a persistent confirmed commit is still a type of confirmed
> commit, without clarification the second paragraph of the description would
> seem to apply.
>
>
> I would agree.
>
>
>
7.8 does not say anything about the  is for the
session that started a confirmed commit or extended a confirmed commmit.
It could be interpreted to mean any kill-session for any session causes
a confirmed commit to be rolled back.  The text below is so ambiguous it
is not even clear the  has to be for an existing session,

      If a NETCONF server receives a  request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.





> It's a minor point, but I could argue, as I wrote before, that such
> clarifications in 7.x are unnecessary because 8.4 provides overrides.   I
> prefer less text because it's easier to get right (wit this is at least the
> 3rd time Jonathan is at this now).  However "unnecessary" doesn't mean
> "wrong" and since we've already stepped in it, getting the 7.x errata right
> might be easier than getting 8.4 right.
>
>

8.4 para 3 says the confirmed commit is not tied to a session if the
persist/persist0id mechanism is used.

   If the  element is not given in the confirmed commit
   operation, any follow-up commit and the confirming commit MUST be
   issued on the same session that issued the confirmed commit.  If the
    element is given in the confirmed  operation, a
   follow-up commit and the confirming commit can be given on any
   session, and they MUST include a  element with a value
   equal to the given value of the  element.


The problematic text is actually in 

8.4.4.1.  

   Description:

         Cancels an ongoing confirmed commit.  If the 
         parameter is not given, the  operation MUST be
         issued on the same session that issued the confirmed commit.


In order to cancel a confirmed commit (belonging to another client, i.e
the persist-id is not known), the client issues a  for
any random or non-existent session.  It would make more sense to issue a

(maybe require superuser) instead. The access control policy for

is the wrong way to configure access to cancelling a confirmed commit.

IMO these procedures are not well designed or documented, and an Errata
cannot
be used to fix it -- a new version of the protocol should fix it, in which
WG and IETF consensus
is reached for the selected solution.




> With the diff, should that be against the original text or the original
> erratum?
>
>
> The diff is building on top of the original erratum. I would think a diff
> w.r.t. to the original erratum would make sense.
>
>
> It depends, are you correcting the earlier errata or filing a new one?
> Regardless, I expressed a diff for what I think the text should be (which
> you didn't comment on); how that is translated is up to you.
>
>
> Kent // contributor
>
>
Andy


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

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




=

On Wed, May 15, 2019 at 2:48 PM Kent =
Watsen <kent@watsen.net> wrote=
:


=

I don't think Erratum 5397 should be de=
leted. Though the original section 7.8 makes no mention of confirmed commit=
s, section 7.9 does, but does not differentiate between a vanilla confirmed=
 commit and a persistent confirmed commit. Since a persistent confirmed com=
mit is still a type of confirmed commit, without clarification the second p=
aragraph of the description would seem to apply.=C2=A0

I would agree.


7.8 does not say anything about=
 the <kill-session> is for the
session that started a confirmed co=
mmit or extended a confirmed commmit.
It could be interpreted to mean an=
y kill-session for any session causes
a confirmed commit to be rolled ba=
ck.=C2=A0 The text below is so ambiguous it
is not even clear the <kill-session> has to be for an existing sessi=
on,

      If a =
NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.



=C2=
=A0
It's a minor point, but =
I could argue, as I wrote before, that such clarifications in 7.x are unnec=
essary because 8.4 provides overrides. =C2=A0 I prefer less text because it=
's easier to get right (wit this is at least the 3rd time Jonathan is a=
t this now).=C2=A0 However "unnecessary" doesn't mean "w=
rong" and since we've already stepped in it, getting the 7.x errat=
a right might be easier than getting 8.4 right.

<=
/div>


8.4 para 3 says the co=
nfirmed commit is not tied to a session if the persist/persist0id mechanism=
 is used.

   If the <persist> element is not given in the confirme=
d commit
   operation, any follow-up commit and the confirming commit MUST be
   issued on the same session that issued the confirmed commit.  If the
   <persist> element is given in the confirmed <commit> operati=
on, a
   follow-up commit and the confirming commit can be given on any
   session, and they MUST include a <persist-id> element with a value
   equal to the given value of the <persist> element.
=C2=A0
The problematic text is actually in <cancel_commit>=


8.4.4.1.  <cancel-commit>

   Description:

         Cancels an ongoing confirmed commit.  If the <persist-id>
         parameter is not given, the <cancel-commit> operation MUST b=
e
         issued on the same session that issued the confirmed commit.
=


In order to =
cancel a confirmed commit (belonging to another client, i.e
the persist-=
id is not known), the client issues a <kill-session> for
any rando=
m or non-existent session.=C2=A0 It would make more sense to issue a <ca=
ncel-commit>
(maybe require superuser) instead. The access con=
trol policy for <kill-session>
is the wrong way to configur=
e access to cancelling a confirmed commit.

IMO the=
se procedures are not well designed or documented, and an Errata cannot
be used to fix it -- a new version of the protocol should fix it, in=
 which WG and IETF consensus
is reached for the selected solution=
.



=


With the diff, should =
that be against the original text or the original erratum?

The diff is building on top of the original erratum.=
 I would think a diff w.r.t. to the original erratum would make sense.

It depends, are you correctin=
g the earlier errata or filing a new one? =C2=A0 Regardless, I expressed a =
diff for what I think the text should be (which you didn't comment on);=
 how that is translated is up to you.


Kent // contributor


Andy
=C2=A0
____________=
___________________________________

netconf mailing list

netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf




--000000000000abf63e0589043c66--


From nobody Thu May 16 10:48:50 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E371120143; Thu, 16 May 2019 10:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 header.b=a51MBfx0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SDZ9q2O/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBX34GKPFO9g; Thu, 16 May 2019 10:48:35 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3B6120025; Thu, 16 May 2019 10:47:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4816; q=dns/txt; s=iport; t=1558028876; x=1559238476; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=axzevODMdFUDSi0/0vd4hCO3Gl35UVGTZK37R8iobNI=; b=a51MBfx0Nqv5bQODiUt1T4OcKuDAYFiXS+OoQfYfgn5uAf1t/9Iel5eB RrwI1SOUep7ZtDWlIaikOoBNEnnhCK6Q+lCIK5KDGDLojdl+iSGJqZEjU AS8ek80jaPMxP/UhO4vsU/3AI0mMIJxsoHxUPmZfwQFBihor0ZkyYn2Gl g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AbF3wIRSBC9cATegTdkpnoqAnq9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYgFcRHXVlN9HCgOk8TE8H7NBXf?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AAAdot1c/4sNJK1kHgEGBwaBUQk?= =?us-ascii?q?LAYE9KScDaVUgBAsohBGDRwOOdZl9gS4UgRADVAkBAQEMAQEjCgIBAYRAAhe?= =?us-ascii?q?CFyM0CQ4BAwEBBAEBAgEEbRwMhUsCAQMSEREMAQE3AQ8CAQYCDgwCCR0CAgI?= =?us-ascii?q?wFRACBAENBSKCNUsBgWoDHQEOkBWQYAKBNYhfcYEvgnkBAQWBRkGCfxiCDwM?= =?us-ascii?q?GgQsoAYl8gVMXgUA/gREnH4JMPoJhAgECAYEqARIBHxchAoJQMoImiy2CQJo?= =?us-ascii?q?bCQKCCYYphD2ENINTG4IbhlKDd4kljEWGZY5GAgQCBAUCDgEBBYFPOCk9WBE?= =?us-ascii?q?IcBVlAYJBgg83gziFFIU/cgGBKIxVDxcDgikBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,477,1549929600"; d="scan'208";a="274030097"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 May 2019 17:47:36 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4GHlZbt010939 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2019 17:47:36 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 12:47:35 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 13:47:34 -0400
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 May 2019 12:47:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=axzevODMdFUDSi0/0vd4hCO3Gl35UVGTZK37R8iobNI=; b=SDZ9q2O/BtZzVa6+xZFoFa22Tcinm9kyA87zf2f6PvMT5CzHT9rkkHR5WGLfF2VTNBRsw0LC9W0C7bhACrfkscmr32a80QH+cp0qCHDt0Oa5AoHcRS4qgCJmIF9bx0dWptTsj9UjZCVNfJvOiwU25UiMYRfIbx94pEvlD909CMc=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2202.namprd11.prod.outlook.com (10.174.104.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Thu, 16 May 2019 17:47:33 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1900.010; Thu, 16 May 2019 17:47:33 +0000
From: "Reshad Rahman (rrahman)" 
To: Roman Danyliw , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
Thread-Index: AQHVC1XMPpSgw/G1oUetILMzNrmjL6ZtxSWA
Date: Thu, 16 May 2019 17:47:32 +0000
Message-ID: <21BFDD8B-ACFC-42D4-A95C-49CD92ED7420@cisco.com>
References: <155794911377.30630.11830718567923683706.idtracker@ietfa.amsl.com>
In-Reply-To: <155794911377.30630.11830718567923683706.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 89cd5804-d359-49df-413c-08d6da26930d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2202; 
x-ms-traffictypediagnostic: DM5PR1101MB2202:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0039C6E5C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(366004)(396003)(189003)(199004)(256004)(6512007)(6306002)(6246003)(446003)(2906002)(8936002)(478600001)(5660300002)(25786009)(33656002)(966005)(81156014)(14444005)(76176011)(6436002)(99286004)(6486002)(305945005)(7736002)(8676002)(102836004)(4326008)(14454004)(229853002)(6506007)(81166006)(11346002)(476003)(2616005)(486006)(83716004)(316002)(71200400001)(53936002)(64756008)(46003)(68736007)(66556008)(54906003)(86362001)(58126008)(82746002)(6116002)(36756003)(66476007)(91956017)(186003)(66946007)(73956011)(71190400001)(76116006)(66446008)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2202; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: W3VVZzfrCsxJczgO7bbF7KvkSli37aarBHf82gIPpsjzRK38fXKrvxfFy7YGf5Nk2tFX+vqC45J/QAxZN62n1ftBZ27g0xyTncfDop3jtsoTiLwl+qXkh0pzy1P+sRQJQRRBrGa8XhmyAqbDTNPmWqiZY2fZjDf64xse4Kds+oWY3Os8KZIfMY8QIxUj5sU4QZ05ZZ7EgvnVhcjiTJiPAAp6kUElvDBhb87Ex7RNc1nRG2dxNtH9z40F/nlOe89V6iSEgWUCsoHZWS+lwV8wXjgQCYzudnEtOurXDBI0RrVRZnEJzGlmgIryZ/k3vvB/8Am5vm1UazEnsjp/+oEqMZSv7BH+O0mIczR++TGt9zk2+AXUmj/w1UWhR8rDK3cOsSkmkbqNwLTM6QO9zJ19xV8a5QfjAEMXOIe+Efak4W4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3252B49B6F54F648BEC230C742C02E79@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 89cd5804-d359-49df-413c-08d6da26930d
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2019 17:47:32.8634 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2202
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: 
Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 17:48:40 -0000

SGksDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldywgcGxlYXNlIHNlZSBpbmxpbmUuDQoNCu+7
v09uIDIwMTktMDUtMTUsIDM6MzggUE0sICJSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciIg
PG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgUm9tYW4gRGFueWxpdyBoYXMgZW50ZXJl
ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLW5ldGNv
bmYtcmVzdGNvbmYtbm90aWYtMTM6IERpc2N1c3MNCiAgICANCiAgICBXaGVuIHJlc3BvbmRpbmcs
IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCiAg
ICBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg
ZnJlZSB0byBjdXQgdGhpcw0KICAgIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K
ICAgIA0KICAgIA0KICAgIFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn
L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCiAgICBmb3IgbW9yZSBpbmZvcm1hdGlv
biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KICAgIA0KICAgIA0K
ICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g
YmUgZm91bmQgaGVyZToNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYvDQogICAgDQogICAgDQogICAgDQogICAgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KICAgIERJU0NVU1M6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIFBl
ciBTZWN0aW9uIDksIFtkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRp
b25zXSBhbmQNCiAgICBbZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u
c10gbWVudGlvbiBjb25jZXJucyBhYm91dCBhDQogICAg4oCcbWFsaWNpb3VzIG9yIGJ1Z2d5IHN1
YnNjcmliZXIgc2VuZHMgYSBudW1iZXIgb2YgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbg0KICAgIHJl
cXVlc3Rz4oCdIGluIHRoZWlyIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLiAgSXMgdGhhdCBub3Qg
YSBjb25jZXJuIGhlcmUgdG9vPw0KPFJSPiBHb29kIGNhdGNoLiBJIGNhbiBhZGQgc2ltaWxhciB0
ZXh0IHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiB0aGlzIGRyYWZ0LCB3b3VsZCB0
aGUgZm9sbG93aW5nIHRleHQgYmUgc2F0aXNmYWN0b3J5Pw0KICAgIElmIGEgYnVnZ3kgb3INCiAg
ICBjb21wcm9taXNlZCBSRVNUQ09ORiBzdWJzY3JpYmVyIHNlbmRzIGEgbnVtYmVyIG9mICJlc3Rh
Ymxpc2gtDQogICAgc3Vic2NyaXB0aW9uIiByZXF1ZXN0cywgdGhlbiB0aGVzZSBzdWJzY3JpcHRp
b25zIGFjY3VtdWxhdGUgYW5kIG1heQ0KICAgIHVzZSB1cCBzeXN0ZW0gcmVzb3VyY2VzLiAgSW4g
c3VjaCBhIHNpdHVhdGlvbiwgdGhlDQogICAgcHVibGlzaGVyIE1BWSBhbHNvIHN1c3BlbmQgb3Ig
dGVybWluYXRlIGEgc3Vic2V0IG9mIHRoZSBhY3RpdmUNCiAgICBzdWJzY3JpcHRpb25zIGZyb20g
dGhhdCBSRVNUQ09ORiBzdWJzY3JpYmVyIGluIG9yZGVyIHRvIHJlY2xhaW0gcmVzb3VyY2VzDQog
ICAgYW5kIHByZXNlcnZlIG5vcm1hbCBvcGVyYXRpb24gZm9yIHRoZSBvdGhlciBzdWJzY3JpcHRp
b25zLiAgICANCiAgICANCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgQ09NTUVOVDoNCiAgICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQogICAgDQogICAgKDEpIFNlY3Rpb24gMy4xLiAg4oCcQSBzdWJzY3JpYmVyIGNh
biB0aGVuIGF0dGVtcHQgdG8gcmUtZXN0YWJsaXNoIHRoZSBkeW5hbWljDQogICAgc3Vic2NyaXB0
aW9uIGJ5IHVzaW5nIHRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy7igJ0gIFRo
aXMgc2VlbXMgbGlrZSBhDQogICAgY2lyY3VsYXIgcmVmZXJlbmNlLiAgVGhpcyBndWlkYW5jZSAo
dG8gZ28gcmVhZCBTZWN0aW9uIDMpIGlzIGJlaW5nIGdpdmVuIGluDQogICAgU2VjdGlvbiAzLjEg
KHdoaWNoIGlzIGluc2lkZSBTZWN0aW9uIDMpLg0KPFJSPiBBY2ssIHdpbGwgY2hhbmdlIHJlZmVy
ZW5jZSB0byAzLjQuDQogICAgDQogICAgKDIpIFNlY3Rpb24gMy4zLiAgTWlzc2luZyB3b3JkLg0K
ICAgIHMvcmVxdWVzdHMgd2l0aCBwdWJsaXNoZXIvcmVxdWVzdHMgd2l0aCB0aGUgcHVibGlzaGVy
Lw0KPFJSPiBPay4NCiAgICANCiAgICAoMykgU2VjdGlvbiAzLjQuICDigJxUaGlzIGluaXRpYXRl
cyB0aGUgcHVibGlzaGVyIHRvIGluaXRpYXRlIHRoZSBmbG93IOKApuKAnS4gIEkNCiAgICBzdHVt
YmxlZCBvdmVyIHRoZSBkb3VibGUgdXNlIG9mIOKAnGluaXRpYXRl4oCdLiAgRG8geW91IG1lYW4g
4oCcVGhpcyBzaWduYWxzIHRvIHRoZQ0KICAgIHB1Ymxpc2hlciB0byBpbml0aWF0ZSB0aGUgZmxv
dyDigKbigJ0/DQo8UlI+IFllcywgd2lsbCBtYWtlIHRoZSBjaGFuZ2UuICAgIA0KICAgICg0KSBT
ZWN0aW9uIDMuNCBzdWdnZXN0cyB0aGF0IE5BQ00vcmVsYXRlZCBtZXRob2RzIHNob3VsZCBiZSB1
c2VkIHRvIGF1dGhvcml6ZQ0KICAgIOKAnG1vZGlmeS1zdWJzY3JpcHRpb24sIHJlc3luYy1zdWJz
Y3JpcHRpb24gYW5kIGRlbGV0ZS1zdWJzY3JpcHRpb27igJ0gUlBDcy4gDQogICAgU2VjdGlvbiA5
LCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgc2F5cyDigJxUaGVyZWZvcmUsIGV2ZW4gaWYgYW4g
YXR0YWNrZXINCiAgICBzdWNjZWVkcyBpbiBndWVzc2luZyB0aGUgc3Vic2NyaXB0aW9uIFVSSSwg
YSBSRVNUQ09ORiB1c2VybmFtZSBbUkZDODA0MF0gd2l0aA0KICAgIHRoZSByZXF1aXJlZCBhZG1p
bmlzdHJhdGl2ZSBwZXJtaXNzaW9ucyBtdXN0IGJlIHVzZWQgdG8gYmUgYWJsZSB0byBhY2Nlc3Mg
b3IgIA0KICAgIG1vZGlmeSB0aGF0IHN1YnNjcmlwdGlvbi7igJ0gIElzIHRoZXJlIGEgcmVhc29u
IG5vdCB0byBzYXkgdGhlIG9idmlvdXMgdGhpbmcgaW4NCiAgICB0aGUgU2VjdXJpdHkgQ29uc2lk
ZXJhdGlvbnMgdGhhdCB0aGVzZSBwYXJ0aWN1bGFyIFJQQ3Mgc2hvdWxkIGJlIHByb3RlY3RlZA0K
ICAgICh3aXRoIE5BQ00vcmVsYXRlZCBtZXRob2RzIGxpa2Ugd2FzIHN0YXRlZCBpbiBTZWN0aW9u
IDMuNCkuDQo8UlI+IFdlIGdvdCBzaW1pbGFyIGNvbW1lbnRzIGZyb20gYW5vdGhlciByZXZpZXdl
ci4gV2Ugd2lsbCBiZSBhZGRpbmcgdGV4dCB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMu
DQoNClJlZ2FyZHMsDQpSZXNoYWQuICAgIA0KICAgIA0KICAgIA0KDQo=


From nobody Thu May 16 11:50:09 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80039120153 for ; Thu, 16 May 2019 11:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MFGDiiEU80q for ; Thu, 16 May 2019 11:50:04 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 A971D12014F for ; Thu, 16 May 2019 11:50:04 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id y11so2286522pfm.13 for ; Thu, 16 May 2019 11:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9jS/WlW/gIfxe1XhyYABwY3gsddYDfzcbaE5UPJdYXU=; b=e6K3znpdSjtJ/SjCMq0esvuXep2uJUolxDEyVVk0VjaFF/NCuStlks72ijk6xmnWCm K9SC0vtKxYqLWOIah+08Cef4lQcs/3xDiwFxsyqPTCFzdNqBJTkVApdqPZZJa/NPyeIJ HJm3vRtpvqqXIws34/QtfszoKecaIyhy3F+TvtffJ1tscm3gZ/jPF/Lv0heLbf9AZWlE ar8eUUJk9yKLJ7/A6MNdvwfQ80w/tOQhDSy2WUBzwYjlVmkzAqc35Q3SoG0zdIi482rS BQ7ROFhH/Rmqi2WXGk8nZG2yf48Cgf/oj8Dry/MK7YoDVI9ZZ/jqwdvXN2T6fPmZ1iCg dxWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9jS/WlW/gIfxe1XhyYABwY3gsddYDfzcbaE5UPJdYXU=; b=SuFUBHseMmqbkN/TJgw/pv1/2EJ2igIXfUdBnv166v7anK5X7XRFD8niS2y6szsBxh /1gyLWWIDBhkErJQ9l3XlMN4dAuzz/gS7iTSKty++0TqlgCtrnEfWEYscfRVe7nk7wSS bx55ufVT9ex5xFKyD/j8DhjV5BI4U6LwfTzGnq2I3gvbir1t2HMXQ2j+dW551l3zOppz nZfMPcOM/rGngG51r0OkDLa/L/bSgvRAndlJ458ilVNhFMW4/wFz9CGYGCBWzca1o+t+ gPREQIRWphfQCmy2VlIK2Zs1XcCvlPeyPJQnfnv01WTCa6zMT9AfZ0btrEsTStRVJhRV jumA==
X-Gm-Message-State: APjAAAXYzqRiuD7cFzpJZXrBTVDLCDHcH8tTo3qb7NnjeCRPaGhHnsAu 31HeV2EkIvl7lFIjlrW8G9kRyDL2
X-Google-Smtp-Source: APXvYqx5sJKkZ+991C4PfTJS5EEWMjiC9yJBmjheSxmGCKKz6vFEjtbSemp7k0IEnqN7tqtEALUNAA==
X-Received: by 2002:a63:d615:: with SMTP id q21mr52068852pgg.401.1558032604000;  Thu, 16 May 2019 11:50:04 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id r9sm11255192pfc.173.2019.05.16.11.50.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 11:50:02 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_32F927A8-1D9B-4432-A94C-C4869544C7E3"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 16 May 2019 11:50:01 -0700
In-Reply-To: 
Cc: Kent Watsen , "netconf@ietf.org" 
To: Andy Bierman 
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>  <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com> 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 18:50:08 -0000

--Apple-Mail=_32F927A8-1D9B-4432-A94C-C4869544C7E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Andy,

> On May 16, 2019, at 10:02 AM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, May 15, 2019 at 2:48 PM Kent Watsen > wrote:
>=20
>=20
>>> I don't think Erratum 5397 should be deleted. Though the original =
section 7.8 makes no mention of confirmed commits, section 7.9 does, but =
does not differentiate between a vanilla confirmed commit and a =
persistent confirmed commit. Since a persistent confirmed commit is =
still a type of confirmed commit, without clarification the second =
paragraph of the description would seem to apply.=20
>>=20
>> I would agree.
>=20
>=20
> 7.8 does not say anything about the  is for the
> session that started a confirmed commit or extended a confirmed =
commmit.
> It could be interpreted to mean any kill-session for any session =
causes
> a confirmed commit to be rolled back.  The text below is so ambiguous =
it
> is not even clear the  has to be for an existing =
session,
>=20
>       If a NETCONF server receives a  request while
>       processing a confirmed commit (Section 8.4), it MUST restore the
>       configuration to its state before the confirmed commit was =
issued.
>=20

While the original text in 7.8 was ambiguous, Erratum 5397 does seem to =
clarify that the  (not  request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a 
      element.
That is why I agree that Erratum 5397 should not be deleted, but should =
be modified to the text suggested by Jonathan.

>=20
> =20
> It's a minor point, but I could argue, as I wrote before, that such =
clarifications in 7.x are unnecessary because 8.4 provides overrides.   =
I prefer less text because it's easier to get right (wit this is at =
least the 3rd time Jonathan is at this now).  However "unnecessary" =
doesn't mean "wrong" and since we've already stepped in it, getting the =
7.x errata right might be easier than getting 8.4 right.
>=20
>=20
>=20
> 8.4 para 3 says the confirmed commit is not tied to a session if the =
persist/persist0id mechanism is used.
>=20
>    If the  element is not given in the confirmed commit
>    operation, any follow-up commit and the confirming commit MUST be
>    issued on the same session that issued the confirmed commit.  If =
the
>     element is given in the confirmed  operation, a
>    follow-up commit and the confirming commit can be given on any
>    session, and they MUST include a  element with a value
>    equal to the given value of the  element.
> =20
> The problematic text is actually in 
>=20
> 8.4.4.1.  
>=20
>    Description:
>=20
>          Cancels an ongoing confirmed commit.  If the 
>          parameter is not given, the  operation MUST be
>          issued on the same session that issued the confirmed commit.
>=20
> In order to cancel a confirmed commit (belonging to another client, =
i.e
> the persist-id is not known), the client issues a  for
> any random or non-existent session.  It would make more sense to issue =
a 
> (maybe require superuser) instead. The access control policy for =

> is the wrong way to configure access to cancelling a confirmed commit.
>=20
> IMO these procedures are not well designed or documented, and an =
Errata cannot
> be used to fix it -- a new version of the protocol should fix it, in =
which WG and IETF consensus
> is reached for the selected solution.

Do you want to open this as a netconf-next issue?

>=20
>=20
>=20
>=20
>>> With the diff, should that be against the original text or the =
original erratum?
>>=20
>> The diff is building on top of the original erratum. I would think a =
diff w.r.t. to the original erratum would make sense.
>=20
> It depends, are you correcting the earlier errata or filing a new one? =
  Regardless, I expressed a diff for what I think the text should be =
(which you didn't comment on); how that is translated is up to you.
>=20
>=20
> Kent // contributor
>=20
>=20
> Andy
> =20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =


Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_32F927A8-1D9B-4432-A94C-C4869544C7E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
Andy,

On May 16, 2019, at 10:02 AM, Andy Bierman =
<andy@yumaworks.com> wrote:



On Wed, May 15, 2019 at 2:48 PM Kent Watsen <kent@watsen.net> =
wrote:


I don't think Erratum 5397 should be deleted. Though the =
original section 7.8 makes no mention of confirmed commits, section 7.9 =
does, but does not differentiate between a vanilla confirmed commit and =
a persistent confirmed commit. Since a persistent confirmed commit is =
still a type of confirmed commit, without clarification the second =
paragraph of the description would seem to =
apply. 

I would agree.


7.8 does not say anything about the =
<kill-session> is for the
session that started a =
confirmed commit or extended a confirmed commmit.
It could =
be interpreted to mean any kill-session for any session causes
a confirmed commit to be rolled back.  The text below is =
so ambiguous it
is not even clear the =
<kill-session> has to be for an existing session,

      If a =
NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.


<=
div>
While the original text in 7.8 was ambiguous, =
Erratum 5397 does seem to clarify that the <close-session> (not =
<kill-session), is for the session in question, and not any =
session.

      If a =
NETCONF server receives a <close-session> request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a =
<persist>
      element.
That is why I agree that Erratum =
5397 should not be deleted, but should be modified to the text suggested =
by Jonathan.


 
It's a minor point, but I could argue, as I wrote before, =
that such clarifications in 7.x are unnecessary because 8.4 provides =
overrides.   I prefer less text because it's easier to get right =
(wit this is at least the 3rd time Jonathan is at this now).  =
However "unnecessary" doesn't mean "wrong" and since we've already =
stepped in it, getting the 7.x errata right might be easier than getting =
8.4 right.



8.4 =
para 3 says the confirmed commit is not tied to a session if the =
persist/persist0id mechanism is used.

   If the <persist> element is not given in the =
confirmed commit
   operation, any follow-up commit and the confirming commit MUST be
   issued on the same session that issued the confirmed commit.  If the
   <persist> element is given in the confirmed <commit> =
operation, a
   follow-up commit and the confirming commit can be given on any
   session, and they MUST include a <persist-id> element with a =
value
   equal to the given value of the <persist> =
element.
 
The =
problematic text is actually in <cancel_commit>

8.4.4.1.  <cancel-commit>

   Description:

         Cancels an ongoing confirmed commit.  If the <persist-id>
         parameter is not given, the <cancel-commit> operation =
MUST be
         issued on the same session that issued the confirmed =
commit.

In order to cancel a confirmed commit (belonging to =
another client, i.e
the persist-id is not known), the =
client issues a <kill-session> for
any random or =
non-existent session.  It would make more sense to issue a =
<cancel-commit>
(maybe require superuser) =
instead. The access control policy for <kill-session>
is the wrong way to configure access to cancelling a =
confirmed commit.

IMO these procedures are not well designed or documented, and =
an Errata cannot
be used to fix it -- a new version =
of the protocol should fix it, in which WG and IETF consensus
is reached for the selected =
solution.

Do=
 you want to open this as a netconf-next issue?





With the diff, should that be against the original text or =
the original erratum?

The diff is building on top of the original erratum. I =
would think a diff w.r.t. to the original erratum would make =
sense.

It depends, are you correcting the =
earlier errata or filing a new one?   Regardless, I expressed a =
diff for what I think the text should be (which you didn't comment on); =
how that is translated is up to you.


Kent // =
contributor


Andy
 
_______________________________________________

netconf mailing list

netconf@ietf.org

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







Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_32F927A8-1D9B-4432-A94C-C4869544C7E3--


From nobody Thu May 16 12:03:18 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50541201DD; Thu, 16 May 2019 12:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Tor2eNACkvnS; Thu, 16 May 2019 12:03:02 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 8909712021B; Thu, 16 May 2019 12:02:50 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id z16so1996173pgv.11; Thu, 16 May 2019 12:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dDehXbwovcYfEiNlzWq6xnL0iekFRh0ZK/XSocW+rak=; b=SMGiitX+nn2wOsBe+JdXMqVFW2YcdrdY2I220VYx5/tWIYSvYBT7PIRogs9aJilqzM yBi2tuRzV8BKD1K7k+xoKzvN9WGAXRc5fdVuX94I7i4DplR+Y9xm9Dz1AqW33nHpedKw FClxyTny+UKpUbZhFCNegEyuckCLqzd4ZfRNLpnFYVgAOojcFZuOCmTVXOlxERBxmY2K oOqP/y8siEidBlHJCKmtbGaNUqTvV2jdKncqX8gH8dfUaOfpUgOpFFQEQ7WNT7Qh4Am1 iuA2BKF1Yt/AEIU8takW0suSvHGyRxNwacFvsTWiRjyue16/pExoyqwxfl/ZQsg5laS9 tL9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dDehXbwovcYfEiNlzWq6xnL0iekFRh0ZK/XSocW+rak=; b=i1jQAoYnK9owqT0f+AhFwX4Tohoa3yCimmLXDSYlYy9fUVsJC3VIf6IFm++Pip8V3h 8/tAiCltX15oudw3bTcKmtop1QD2+SnQBKb4QscFZVR2/LQNmY38c2sRBRn6g2bucsl/ i3BtHbqzAT64XLoq6zkMatMi3KZEr265SMrQCs4yYob8GDQHBJGkiNv3vynRZs9TCiXY SE84uZETzvDyufAyP+u2k2/OlneEfffQyAI4y5Di/NtasuFS96jCv/uRr7cM8wfSjL// 9Oxcwv6MGRH1cKi3fD85jw6UQKadcXUuCiEIEnZQeypqCPn/98V3KDdSCOqebqog4zR4 0H5Q==
X-Gm-Message-State: APjAAAXwKzrbFijlZF2lCMIbor5NZFJcfJZ4QMpHCVe6r9/EwWumHcJR 0S0aGi5wq5apRY+PfIwFtsFxdxta
X-Google-Smtp-Source: APXvYqxjMffG89PcwEGzTizOEtuj770gnn8RcOhJNcc4h1KFBICK3dnV9Vu/pWz5EA5ZjbGaV4CVsA==
X-Received: by 2002:aa7:820c:: with SMTP id k12mr55854901pfi.177.1558033369671;  Thu, 16 May 2019 12:02:49 -0700 (PDT)
Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id o20sm7109759pgj.70.2019.05.16.12.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 12:02:48 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani 
In-Reply-To: <0A966DA9-7CF7-4288-B636-70EABC184742@gmail.com>
Date: Thu, 16 May 2019 12:02:47 -0700
Cc: tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EE979DF-F274-44E1-B33F-FE70A50590F8@gmail.com>
References: <0A966DA9-7CF7-4288-B636-70EABC184742@gmail.com>
To: Netconf 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netconf] Re-issue of adoption poll for draft-kwatsen-netconf-tcp-client-server-02
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 19:03:04 -0000

This closes this adoption poll. No comments or objections were received =
during the poll. Therefore, this draft is now adopted as a WG item. =
Author(s), please post this draft as =
draft-ietf-netconf-tcp-client-server-00 without any modifications.

Thanks.

> On May 1, 2019, at 11:54 AM, Mahesh Jethanandani =
 wrote:
>=20
> As noted in the mail yesterday to the NETCONF WG, I am issuing a new =
poll on draft-kwatsen-netconf-tcp-client-server draft that was discussed =
in 104.
>=20
> There were comments that were received on the -00 draft that was =
presented in 104, that have been addressed in the -02 version of the =
draft. Since the original poll was on the -00 version of the draft, we =
(the chairs), felt the need to re-issue the poll. Also, that poll =
included the HTTP client/server draft, which is still under discussion, =
and as such has been removed from this poll.
>=20
> The TCP client/server draft did get support in 103, so rather than =
asking for a repeat of that show of support, I am asking if there is any =
objection to the adoption of this draft. If you do have an objection, =
please state your reasons for why you feel this work should not be done.
>=20
> The poll will run for two weeks, till May 15, and if no objections are =
received by then, the draft will be adopted as a WG item.

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Thu May 16 12:11:12 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C871E12028A for ; Thu, 16 May 2019 12:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4dbu0wSgauj9 for ; Thu, 16 May 2019 12:11:03 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F4812025A for ; Thu, 16 May 2019 12:10:52 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id a10so4107525ljf.6 for ; Thu, 16 May 2019 12:10:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yhEdhtujZODDo0lHewN/0UohvCiBkZDYk4S4hm6vI5k=; b=XHt/P70xy0yBtiag2f1aC8hnwYDv3I1E0SipPGOnIYZgY3pgX/bEFTQrRQJMARSWHA UAvis53kJlAgbjubA2Noij+nGbxlIhhsVHg53kD1KiKAzT/ch/dwgZ65K2QhEr3cAF2Y B9ULJs/ejBNEukN60R0gxzce38WmcGCbW1eFl705A1xfAPurOprVf+M5+kBXzqG8mYpa GpGuIVbzbS4YpOXyU87dzE1Ib+eTGHW7gOndjk9v2J8AvCG5tDUZPmwwo5NpuV99aU3l 3Ui04iRyC3V0Yz3Km+lHIegSBsRRycjzUQyVH7aMSqsisB8wZDuE6yeN44Fh3KA0sI0N QA0g==
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=yhEdhtujZODDo0lHewN/0UohvCiBkZDYk4S4hm6vI5k=; b=gSlhG0kkSD/xRZzgsnm6Fd90TaQAwAp9nvJK0jAIccg2EchI1u1uQZW6Bu+OBxNtag rv79H3eVmpJJYfPbMMmkCCLIe8FMjB50pzL9JRf/V2NxYiJqvxYNIvrD5U10ITKahmVQ i1aDY2LBn6ZlQBWveQ1Ogvpz867US5jrBdJQfUftaPj6hnZYkBFhpWTN4PzZXeYd9nOr 3eGWfjdgpKIMTKP2NgzEZgfD02cKpV3phGTdg6qMyJFWrLzU/PERHfDDqcihMx233Z7Y xfT7cx5C/6pSQfkIfJXk3zemt89mqQbrD3sqs20v2OFABaMR/1G/OPV5kcNruDhhIxMq 6aNg==
X-Gm-Message-State: APjAAAUJ4CAgrEF5IVuT2P4sXZ6MTP6aOm4sP7W5Rtiwy8iANS9F+5Iq OoAQDnTrr7y5YBELJ6UWTCHf+a7eS59HtTeSkteLig==
X-Google-Smtp-Source: APXvYqz0aUtFzUYoWIQ+dfJTIDDjI3EgGI3X8W1CNhaMtnKWaYH/b+/tYYZM2kZw5bRbIh/EfNrWiwieRonl//jBUs0=
X-Received: by 2002:a2e:8716:: with SMTP id m22mr9793958lji.128.1558033850046;  Thu, 16 May 2019 12:10:50 -0700 (PDT)
MIME-Version: 1.0
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>  <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com>  <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com>
In-Reply-To: <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com>
From: Andy Bierman 
Date: Thu, 16 May 2019 12:10:38 -0700
Message-ID: 
To: Mahesh Jethanandani 
Cc: Kent Watsen , "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000002e36f005890606d2"
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 19:11:10 -0000

--0000000000002e36f005890606d2
Content-Type: text/plain; charset="UTF-8"

On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Hi Andy,
>
> On May 16, 2019, at 10:02 AM, Andy Bierman  wrote:
>
>
>
> On Wed, May 15, 2019 at 2:48 PM Kent Watsen  wrote:
>
>>
>>
>> I don't think Erratum 5397 should be deleted. Though the original section
>> 7.8 makes no mention of confirmed commits, section 7.9 does, but does not
>> differentiate between a vanilla confirmed commit and a persistent confirmed
>> commit. Since a persistent confirmed commit is still a type of confirmed
>> commit, without clarification the second paragraph of the description would
>> seem to apply.
>>
>>
>> I would agree.
>>
>>
>>
> 7.8 does not say anything about the  is for the
> session that started a confirmed commit or extended a confirmed commmit.
> It could be interpreted to mean any kill-session for any session causes
> a confirmed commit to be rolled back.  The text below is so ambiguous it
> is not even clear the  has to be for an existing session,
>
>       If a NETCONF server receives a  request while
>       processing a confirmed commit (Section 8.4), it MUST restore the
>       configuration to its state before the confirmed commit was issued.
>
>
>
> While the original text in 7.8 was ambiguous, Erratum 5397 does seem to
> clarify that the  (not  question, and not any session.
>
>
I do not agree that close-session overrides the text in sec 8.4 supports
this procedure.
It also makes no sense from an operational POV, since dropping the session
(without a close-session) does not have this affect :



   If the session issuing the confirmed commit is terminated *for any
   reason* before the confirm timeout expires, the server MUST restore
   the configuration to its state before the confirmed commit was
   issued,* unless the confirmed commit also included a 
   element.*


IMO this text overrides the close-session and kill-session text.




>       If a NETCONF server receives a  request while
>       processing a confirmed commit (Section 8.4) for that session, it
>       MUST restore the configuration to its state before the confirmed
>       commit was issued unless the confirmed commit included a 
>       element.
>
> That is why I agree that Erratum 5397 should not be deleted, but should be
> modified to the text suggested by Jonathan.
>
>
This makes no operational sense if the  parameter was used.


>
>
>
>> It's a minor point, but I could argue, as I wrote before, that such
>> clarifications in 7.x are unnecessary because 8.4 provides overrides.   I
>> prefer less text because it's easier to get right (wit this is at least the
>> 3rd time Jonathan is at this now).  However "unnecessary" doesn't mean
>> "wrong" and since we've already stepped in it, getting the 7.x errata right
>> might be easier than getting 8.4 right.
>>
>>
>
> 8.4 para 3 says the confirmed commit is not tied to a session if the
> persist/persist0id mechanism is used.
>
>    If the  element is not given in the confirmed commit
>    operation, any follow-up commit and the confirming commit MUST be
>    issued on the same session that issued the confirmed commit.  If the
>     element is given in the confirmed  operation, a
>    follow-up commit and the confirming commit can be given on any
>    session, and they MUST include a  element with a value
>    equal to the given value of the  element.
>
>
> The problematic text is actually in 
>
> 8.4.4.1.  
>
>    Description:
>
>          Cancels an ongoing confirmed commit.  If the 
>          parameter is not given, the  operation MUST be
>          issued on the same session that issued the confirmed commit.
>
>
> In order to cancel a confirmed commit (belonging to another client, i.e
> the persist-id is not known), the client issues a  for
> any random or non-existent session.  It would make more sense to issue a
> 
> (maybe require superuser) instead. The access control policy for
> 
> is the wrong way to configure access to cancelling a confirmed commit.
>
> IMO these procedures are not well designed or documented, and an Errata
> cannot
> be used to fix it -- a new version of the protocol should fix it, in which
> WG and IETF consensus
> is reached for the selected solution.
>
>
> Do you want to open this as a netconf-next issue?
>
>
>
not really



>
>
>
>> With the diff, should that be against the original text or the original
>> erratum?
>>
>>
>> The diff is building on top of the original erratum. I would think a diff
>> w.r.t. to the original erratum would make sense.
>>
>>
>> It depends, are you correcting the earlier errata or filing a new one?
>> Regardless, I expressed a diff for what I think the text should be (which
>> you didn't comment on); how that is translated is up to you.
>>
>>
>> Kent // contributor
>>
>>
> Andy
>
>
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>

Andy

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




=

On Thu, May 16, 2019 at 11:50 AM Mahe=
sh Jethanandani <mjethanandan=
i@gmail.com> wrote:
Hi Andy,

<=
blockquote type=3D"cite">
On May 16, 2019, at 10:02 AM, Andy Bierman &l=
t;andy@yumaworks.co=
m> wrote:



On Wed, May 15, 20=
19 at 2:48 PM Kent Watsen <kent@watsen.net> wrote:


I don=
't think Erratum 5397 should be deleted. Though the original section 7.=
8 makes no mention of confirmed commits, section 7.9 does, but does not dif=
ferentiate between a vanilla confirmed commit and a persistent confirmed co=
mmit. Since a persistent confirmed commit is still a type of confirmed comm=
it, without clarification the second paragraph of the description would see=
m to apply.=C2=A0

I would agree.

7.8 does not say anything about the <kill-session> is for the<=
br>session that started a confirmed commit or extended a confirmed commmit.=

It could be interpreted to mean any kill-session for any session causes=

a confirmed commit to be rolled back.=C2=A0 The text below is so ambigu=
ous it
is not even clear the <kill-sessi=
on> has to be for an existing session,

      If a NETCONF server receives a <kill-session> request=
 while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.



While the original text i=
n 7.8 was ambiguous, Erratum 5397 does seem to clarify that the <close-s=
ession> (not <kill-session), is for the session in question, and not =
any session.


I d=
o not agree that close-session overrides the text in sec 8.4 supports this =
procedure.
It also makes no sense from an operational POV, since =
dropping the session
(without a close-session) does not have this=
 affect :



   If the session issuing the confirmed commit is terminated for any
   reason before the confirm timeout expires, the server MUST restore
   the configuration to its state before the confirmed commit was
   issued, unless the confirmed commit also included a <persist>
   element.


IMO this tex=
t overrides the close-session and kill-session text.


=C2=A0
      If a NETCONF server receives =
a <close-session> request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a <persist&=
gt;
      element.
That is why I agree that Erratum 5397 should not b=
e deleted, but should be modified to the text suggested by Jonathan.
<=
/div>


This makes no op=
erational sense if the <persist> parameter was used.
=C2=A0=


=C2=A0
It's a min=
or point, but I could argue, as I wrote before, that such clarifications in=
 7.x are unnecessary because 8.4 provides overrides. =C2=A0 I prefer less t=
ext because it's easier to get right (wit this is at least the 3rd time=
 Jonathan is at this now).=C2=A0 However "unnecessary" doesn'=
t mean "wrong" and since we've already stepped in it, getting=
 the 7.x errata right might be easier than getting 8.4 right.


8.4 para=
 3 says the confirmed commit is not tied to a session if the persist/persis=
t0id mechanism is used.

   If the <persist> element is not given in the confirmed c=
ommit
   operation, any follow-up commit and the confirming commit MUST be
   issued on the same session that issued the confirmed commit.  If the
   <persist> element is given in the confirmed <commit> operati=
on, a
   follow-up commit and the confirming commit can be given on any
   session, and they MUST include a <persist-id> element with a value
   equal to the given value of the <persist> element.
=C2=A0
The problematic text is actually in <cancel_commit>=


8.4.4.1.  <=
;cancel-commit>

   Description:

         Cancels an ongoing confirmed commit.  If the <persist-id>
         parameter is not given, the <cancel-commit> operation MUST b=
e
         issued on the same session that issued the confirmed commit.
=


In order to cancel a confirme=
d commit (belonging to another client, i.e
the persist-id is not known),=
 the client issues a <kill-session> for
any random or non-existent=
 session.=C2=A0 It would make more sense to issue a <cancel-commit>
(maybe require superuser) instead. The access control policy for &=
lt;kill-session>
is the wrong way to configure access to cance=
lling a confirmed commit.

IMO these procedures are=
 not well designed or documented, and an Errata cannot
be used to=
 fix it -- a new version of the protocol should fix it, in which WG and IET=
F consensus
is reached for the selected solution.

Do you want to open this as a netconf-n=
ext issue?



not really

=C2=A0



With the d=
iff, should that be against the original text or the original erratum?

The diff is building on top of the origi=
nal erratum. I would think a diff w.r.t. to the original erratum would make=
 sense.

It depends, are y=
ou correcting the earlier errata or filing a new one? =C2=A0 Regardless, I =
expressed a diff for what I think the text should be (which you didn't =
comment on); how that is translated is up to you.

=

Kent // contributor

<=
br>
Andy
=C2=A0
_____________________________________=
__________

netconf mailing list

netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf







Mahesh Jethanandani




Andy

=C2=A0

--0000000000002e36f005890606d2--


From nobody Thu May 16 16:20:12 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90F412030B for ; Thu, 16 May 2019 16:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa10i8EIaQPr for ; Thu, 16 May 2019 16:20:00 -0700 (PDT)
Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EB7120345 for ; Thu, 16 May 2019 16:20:00 -0700 (PDT)
Received: by mail-pl1-f169.google.com with SMTP id c5so2345820pll.11 for ; Thu, 16 May 2019 16:20:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x3DrFkKCG8uFl6PSW1KLisTQKChHwlP+a9Dc4hGlwRE=; b=cuX5410LP+EY4+MI4oRUc3LMEjuc6uj+2X+U1O3O6JaE7RDuIv3jrHi4Y8YbAE8jYB vDENmMRuWvTxMvRoQzhoCfr0sGKfnHwYsL+Gubdurao/exzHXLu3GlmpOmKDHZfmOn3G lGhphgmAOHmakX/dur5FpzLlsmS6L490tOyMF0gmNeD4+/cRvx9Z2Gx4byBTRm+b9ZdZ tjXZgXkSeYtBo/cetzzt7zoajaA8XS65ttq7wWpxbhQavDShg/vgNtHJB6zlZq0I0ThZ ALyv2cOBFrnZJK+HMNRMF7HjK2PBLZ894WrCan8p0FtWSi/zp5H3msTp2c/Zc5C6L4fi g4fA==
X-Gm-Message-State: APjAAAXdEwI41yVdYOuOFkQGpm6++r7lEWK4erWkiwV5H8or1Z3sIKnn OirrkykH7IivFSOUrHed1gGScg==
X-Google-Smtp-Source: APXvYqyxRKOhpCFeVp349bA31RskQB8jf2OwKf0lUqM6s1PDAtx9N9vVx/X5jDoIYEgYkD0TfMcFrQ==
X-Received: by 2002:a17:902:b602:: with SMTP id b2mr53673783pls.293.1558048800046;  Thu, 16 May 2019 16:20:00 -0700 (PDT)
Received: from [192.168.1.102] (c-69-181-241-121.hsd1.ca.comcast.net. [69.181.241.121]) by smtp.gmail.com with ESMTPSA id x23sm6175094pfn.160.2019.05.16.16.19.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 16:19:59 -0700 (PDT)
To: "Eric Voit (evoit)" , Benjamin Kaduk , The IESG 
Cc: "netconf@ietf.org" , "draft-ietf-netconf-netconf-event-notifications@ietf.org" , "netconf-chairs@ietf.org" 
References: <155794345628.30726.16513916652364715189.idtracker@ietfa.amsl.com> <17b8294694a446679f786fee28e4e206@XCH-RTP-013.cisco.com> <8a904fce-ff70-2e62-9fde-850cce607ffc@alumni.stanford.edu> <9f931951fb104c19b7e786bdd1871ae1@XCH-RTP-013.cisco.com>
From: Randy Presuhn 
Message-ID: <25abe8f0-600d-649e-b33a-aad675ca8e45@alumni.stanford.edu>
Date: Thu, 16 May 2019 16:19:59 -0700
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: <9f931951fb104c19b7e786bdd1871ae1@XCH-RTP-013.cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-netconf-event-notifications-20: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 23:20:07 -0000

Hi -

On 5/16/2019 5:47 AM, Eric Voit (evoit) wrote:
>> From: Randy Presuhn, May 15, 2019 10:10 PM
>>
>> Hi -
>>
>> On 5/15/2019 12:01 PM, Eric Voit (evoit) wrote:
>> ...
>>>> From: Benjamin Kaduk, May 15, 2019 2:04 PM
>> ...
>>>> Section 6
>>>>
>>>>      Notification messages transported over the NETCONF protocol MUST be
>>>>      encoded in a  message as defined within [RFC5277],
>>>>      Section 4.  And per [RFC5277]'s "eventTime" object definition, the
>>>>      "eventTime" populated with the event occurrence time.
>>>>
>>>> nit: I think the last sentence is actually a sentence fragment.
>>>
>>> This reads fine with me.  Several on-line grammar checks give it a pass, but I
>> am not sure how much I trust those tools.  So I will leave as is.
>>
>> No, it really is a fragment.  Not only does it begin with a conjunction, but it lacks
>> a verb. If it were joined to the previous sentence, one might infer a "MUST be"
>> before "populated", but as a separate sentence it no longer supports that
>> interpretation.  If "MUST be populated" isn't the intended interpretation here,
>> then it's even more important to turn that fragment into a real sentence.
> 
> Made it:  "And per [RFC5277]'s "eventTime" object definition, the "eventTime" is populated with the event occurrence time."

Better, although I see no earthly reason for beginning this
sentence with "And".

Randy


From nobody Thu May 16 19:27:27 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D874512033D; Thu, 16 May 2019 19:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NYExRwE+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JMakpVOY
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWSU8goO0vPC; Thu, 16 May 2019 19:27:15 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056AA12014E; Thu, 16 May 2019 19:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14110; q=dns/txt; s=iport; t=1558060035; x=1559269635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hQtmKu10qh8Z41j/cDPGGODMnkPZIekJeichfS2YJTo=; b=NYExRwE+VGH0BFU/+liEuKl4IjnReyaU0G6w5znjmioDlTXn/xewmF9g EtQ/LDY8t6inPQIoE3vzSFZ2MN9WuUJJ3aZXkBzoFbh6zGOgxtwkk2jyq bD0JqNWU81qdKbHGoXFjIaMC65/6YkDRWWkrmuDOtgUzuIPJMufmTT8uT 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AQqUqyBJNU3St3wFsJ9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFfhJf7vZioSF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAADjGt5c/5xdJa1bCRwBAQEEAQE?= =?us-ascii?q?HBAEBgVEHAQELAYE9JAUnA2lVIAQLKAqECINHA4RSiiKCV5cngS4UgRADVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGDekYCF4IXIzQJDgEDAQEEAQECAQRtHAyFSwEBAQIBAQE?= =?us-ascii?q?QEREMAQEsBAcBDwIBCBoCCRYHAgICJQsVEAIEAQ0BBCKCNUsBgWoDDg8BDqA?= =?us-ascii?q?0AoE1iF9xgS+CeQEBBYFGQYJ/GIIPAwaBCygBi08XgUA/gREnH4JMPoJhAQE?= =?us-ascii?q?BAgGBKgEICgEJFgcQIQKCUDKCJosZCwoOgjOGb5JKZQkCggmGK4Q+hDSDVRu?= =?us-ascii?q?CG4ZSBY0cjEiBJYVBjkcCBAIEBQIOAQEFgU84KT1YEQhwFTsqAYJBgg83gzi?= =?us-ascii?q?FFIU/cgEOgRqMCYEiAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.60,478,1549929600"; d="scan'208";a="559049836"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 May 2019 02:27:13 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4H2RDia018821 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2019 02:27:13 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 21:27:13 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 22:27:11 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 May 2019 22:27:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hQtmKu10qh8Z41j/cDPGGODMnkPZIekJeichfS2YJTo=; b=JMakpVOYnyrEaGBxljkktZdzpHKs4Eylxtdhj75Ec4txT9R4rSDy0Uy6pvkURxKq+mlqsRO93kd7VGHsX8XUQbT/xHKG6gok06ApsPowAG8ne+f9ZGQlDepvecK4M03AZnC4qyIO1Ve5yGAxs/zC2a+ZjL/JsaW+luXIE9JG2U8=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2348.namprd11.prod.outlook.com (10.173.174.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Fri, 17 May 2019 02:27:10 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1900.010; Fri, 17 May 2019 02:27:10 +0000
From: "Reshad Rahman (rrahman)" 
To: Adam Roach , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
Thread-Index: AQHVCu60QWyOYQqwSEOksNKzIOWLIqZuVagA
Date: Fri, 17 May 2019 02:27:09 +0000
Message-ID: 
References: <155790481851.17474.3456985672733157831.idtracker@ietfa.amsl.com>
In-Reply-To: <155790481851.17474.3456985672733157831.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bf24905c-8de7-4646-56ae-08d6da6f2a1e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2348; 
x-ms-traffictypediagnostic: DM5PR1101MB2348:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0040126723
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(396003)(136003)(51914003)(189003)(199004)(8936002)(6512007)(6306002)(11346002)(2616005)(36756003)(64756008)(76116006)(26005)(5660300002)(68736007)(476003)(82746002)(91956017)(86362001)(71200400001)(71190400001)(66446008)(14454004)(486006)(66946007)(83716004)(66476007)(66556008)(73956011)(2906002)(3846002)(6116002)(4326008)(8676002)(33656002)(6246003)(66066001)(81156014)(478600001)(81166006)(14444005)(966005)(256004)(58126008)(305945005)(76176011)(99286004)(316002)(102836004)(6486002)(229853002)(6506007)(6436002)(53936002)(25786009)(54906003)(446003)(110136005)(7736002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2348; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: v/p0SwIwvx3u22v6eyzPRCi+RhutYx6rWgSzUVWA7WZZ9MJIFHt4zUNsQ42pYnL2H0DN++jSoXqsNRprLTSWtghZDfZn5yINtrAb54cRADKCxkq/0yUCnLCaqoocNt792eedXG6ly8uI/9LxgMSOu09K2dbpU4V7nvftT4/gShnfN5T+STDRaRgVGpxImTOE3ZaYAlhr9qsHJO0Mh3Poh6DeNjtd43Q6xP0o41CiviAK2YSsqecd4EnZWVs2tzbJOAeab5qkp4Lgut2OLZ1qxIzrBLsl8aGOTa4mytvG5HK+MzohMJdzVqaVAJi6W2sQmkUcVltKDBc1YqsOvF5R8yTzM+WBXdH6V6DiuqG6t322jyKP3q0Jg9u9ZQPGnpYZy3fAi4cvs5LAhD2OB3dI8AUR5knoMFhXJoanBmDcxXQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bf24905c-8de7-4646-56ae-08d6da6f2a1e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 02:27:10.0969 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2348
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: 
Subject: Re: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 02:27:18 -0000

SGksDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldywgcGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0K77u/
T24gMjAxOS0wNS0xNSwgMzoyMCBBTSwgIm5ldGNvbmYgb24gYmVoYWxmIG9mIEFkYW0gUm9hY2gg
dmlhIERhdGF0cmFja2VyIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBu
b3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIEFkYW0gUm9hY2ggaGFzIGVudGVyZWQgdGhl
IGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi1uZXRjb25mLXJl
c3Rjb25mLW5vdGlmLTEzOiBEaXNjdXNzDQogICAgDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVh
c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1h
aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg
dG8gY3V0IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICAN
CiAgICANCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0
ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv
dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBU
aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv
dW5kIGhlcmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0
Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLw0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCiAgICBESVNDVVNTOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICBUaGFua3Mg
Zm9yIGFsbCB0aGUgd29yayB0aGF0IHRoZSBhdXRob3JzIGFuZCBvdGhlciBjb250cmlidXRvcnMg
aGF2ZQ0KICAgIHB1dCBpbnRvIHRoaXMgZG9jdW1lbnQuIEkgaGF2ZSB0d28gY29tbWVudHMgdGhh
dCBuZWVkIHRvIGJlIGFkZHJlc3NlZA0KICAgIGJlZm9yZSBwdWJsaWNhdGlvbiwgYnV0IHRoZXkg
c2hvdWxkIGJvdGggYmUgdmVyeSBlYXN5IHRvIGZpeC4NCiAgICANCiAgICAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCiAgICANCiAgICANCiAgICDCpzMuMzoNCiAgICANCiAgICA+ICBJZiBhIHB1Ymxpc2hl
ciBmYWlscyB0byBzZXJ2ZSB0aGUgUlBDIHJlcXVlc3QgZm9yIG9uZSBvZiB0aGUgcmVhc29ucw0K
ICAgID4gIGluZGljYXRlZCBpbiBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v
dGlmaWNhdGlvbnNdDQogICAgPiAgU2VjdGlvbiAyLjQuNiBvciBbSS1ELmlldGYtbmV0Y29uZi15
YW5nLXB1c2hdIEFwcGVuZGl4IEEsIHRoaXMgd2lsbA0KICAgID4gIGJlIGluZGljYXRlZCBieSAi
NDA2IiBzdGF0dXMgY29kZSB0cmFuc3BvcnRlZCBpbiB0aGUgSFRUUCByZXNwb25zZS4NCiAgICAN
CiAgICBUaGlzIHJlYWxseSBpc24ndCB3aGF0IDQwNiBtZWFucy4gNDA2IG1lYW5zICJ5b3Ugc2Vu
dCBvbmUgb3IgbW9yZSBvZiB0aGUNCiAgICAnQWNjZXB0JywgJ0FjY2VwdC1DaGFyc2V0JywgJ0Fj
Y2VwdC1FbmNvZGluZycsIG9yICdBY2NlcHQtTGFuZ3VhZ2UnIGhlYWRlcg0KICAgIGZpZWxkcywg
YW5kIEkgY2FuJ3QgZ2VuZXJhdGUgYSByZXNwb25zZSB0aGF0IHNhdGlzZmllcyB3aGF0IHlvdSd2
ZSBhc2tlZCBmb3IuIg0KICAgIA0KICAgIEZvciBzb21lIG9mIHRoZSBlcnJvcnMgbGlzdGVkIGlu
IHRoZSB0d28gY2l0ZWQgc2VjdGlvbnMsIHRoZXJlIGlzIGEgcmVhc29uYWJsZQ0KICAgIHNlbWFu
dGljIG1hcHBpbmcgb250byBleGlzdGluZyBIVFRQIHJlc3BvbnNlIGNvZGVzOyBlLmcuIHRoZQ0K
ICAgICJuby1zdWNoLXN1YnNjcmlwdGlvbiIgZXJyb3JzIGNvdWxkIGFsbCByZWFzb25hYmx5IG1h
cCBvbiB0byBIVFRQIDQwNC4gIEknbGwNCiAgICBub3RlIHRoYXQgUkZDIDgwNDAgc2VjdGlvbiA3
IHBlcmZvcm1zIGV4YWN0bHkgdGhpcyBraW5kIG9mIG1hcHBpbmcsIHNvIHRoZQ0KICAgIGFwcHJv
YWNoIHNlZW1zIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgd2F5IHRoYXQgUkVTVENPTkYgaGFz
IGVsZWN0ZWQgdG8gdXNlDQogICAgSFRUUCByZXNwb25zZSBjb2Rlcy4gSW4gZmFjdCwgdGhpcyBk
b2N1bWVudCBhbHJlYWR5IG1hcHMgZnJvbSB0aGUgY2l0ZWQgZXJyb3JzDQogICAgdG8gZXJyb3Ig
dGFncyBhbHJlYWR5LCBhbmQgdGhhdCB0YWJsZSBtYXBzIGZyb20gZXJyb3ItdGFnIHRvDQogICAg
SFRUUCByZXNwb25zZSBjb2Rlcywgc28gZml4aW5nIHRoaXMgc2hvdWxkIGJlIHRoZSByZWxhdGl2
ZWx5IHN0cmFpZ2h0Zm9yd2FyZA0KICAgIGV4ZXJjaXNlIG9mIHVwZGFpbmcgdGhlIHRhYmxlcyBp
biB0aGlzIHNlY3Rpb24gdG8gYWxzbyBpbmNsdWRlIHRoZSBIVFRQIHJlc3BvbnNlDQogICAgY29k
ZSB0aGF0IFJGQyA4MDQwIG1hcHMgdG8gdGhlIGluZGljYXRlZCBlcnJvci10YWcuIEZvciBleGFt
cGxlOg0KICAgIA0KICAgICAgICAgZXJyb3IgaWRlbnRpdHkgICAgICAgICB1c2VzIGVycm9yLXRh
ZyAgICAgICAgICAgICBIVFRQIFJlc3BvbnNlDQogICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tIC0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0NCiAgICAgICAgIGRz
Y3AtdW5hdmFpbGFibGUgICAgICAgaW52YWxpZC12YWx1ZSAgICAgICAgICAgICAgNDAwDQogICAg
ICAgICBlbmNvZGluZy11bnN1cHBvcnRlZCAgIGludmFsaWQtdmFsdWUgICAgICAgICAgICAgIDQw
MA0KICAgICAgICAgZmlsdGVyLXVuc3VwcG9ydGVkICAgICBpbnZhbGlkLXZhbHVlICAgICAgICAg
ICAgICA0MDANCiAgICAgICAgIGluc3VmZmljaWVudC1yZXNvdXJjZXMgcmVzb3VyY2UtZGVuaWVk
ICAgICAgICAgICAgNDA5DQogICAgICAgICBuby1zdWNoLXN1YnNjcmlwdGlvbiAgIGludmFsaWQt
dmFsdWUgICAgICAgICAgICAgIDQwNA0KICAgICAgICAgcmVwbGF5LXVuc3VwcG9ydGVkICAgICBv
cGVyYXRpb24tbm90LXN1cHBvcnRlZCAgICA1MDENCiAgICANCiAgICAgICAgIGVycm9yIGlkZW50
aXR5ICAgICAgICAgICAgICB1c2VzIGVycm9yLXRhZyAgICAgICAgICBIVFRQIFJlc3BvbnNlDQog
ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tLS0tLS0gICAgICAg
ICAgLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgY2FudC1leGNsdWRlICAgICAgICAgICAgICAgIG9w
ZXJhdGlvbi1ub3Qtc3VwcG9ydGVkIDUwMQ0KICAgICAgICAgZGF0YXN0b3JlLW5vdC1zdWJzY3Jp
YmFibGUgIGludmFsaWQtdmFsdWUgICAgICAgICAgIDQwMA0KICAgICAgICAgbm8tc3VjaC1zdWJz
Y3JpcHRpb24tcmVzeW5jIGludmFsaWQtdmFsdWUgICAgICAgICAgIDQwNA0KICAgICAgICAgb24t
Y2hhbmdlLXVuc3VwcG9ydGVkICAgICAgIG9wZXJhdGlvbi1ub3Qtc3VwcG9ydGVkIDUwMQ0KICAg
ICAgICAgb24tY2hhbmdlLXN5bmMtdW5zdXBwb3J0ZWQgIG9wZXJhdGlvbi1ub3Qtc3VwcG9ydGVk
IDUwMQ0KICAgICAgICAgcGVyaW9kLXVuc3VwcG9ydGVkICAgICAgICAgIGludmFsaWQtdmFsdWUg
ICAgICAgICAgIDQwMA0KICAgICAgICAgdXBkYXRlLXRvby1iaWcgICAgICAgICAgICAgIHRvby1i
aWcgICAgICAgICAgICAgICAgIDQwMA0KICAgICAgICAgc3luYy10b28tYmlnICAgICAgICAgICAg
ICAgIHRvby1iaWcgICAgICAgICAgICAgICAgIDQwMA0KICAgICAgICAgdW5jaGFuZ2luZy1zZWxl
Y3Rpb24gICAgICAgIG9wZXJhdGlvbi1mYWlsZWQgICAgICAgIDUwMA0KICAgIA0KICAgIEhvd2V2
ZXIgeW91IGNob29zZSB0byBhZGRyZXNzIHRoaXMsIGlmIHRoZSBlcnJvciBpc24ndCByZWxhdGVk
IHRvIGFueSBvZiB0aGUNCiAgICBmb3VyIGhlYWRlciBmaWVsZHMgSSBtZW50aW9uIGFib3ZlLCB0
aGVuIHlvdSBjYW4ndCBzcGVjaWZ5IHRoZSB1c2Ugb2YgYSA0MDYuDQo8UlI+IFRoYW5rIHlvdSBm
b3Igc3VnZ2VzdGluZyBzdGF0dXMgY29kZXMgZm9yIHRoZSBkaWZmZXJlbnQgZXJyb3JzLCBtdWNo
IGFwcHJlY2lhdGVkLiBJIGFncmVlIHRoYXQgNDA2IGlzIG5vdCBhcHByb3ByaWF0ZS4gUmVnYXJk
aW5nIDQwMCwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGlzIGZvciBpbnZhbGlkIHN5bnRh
eCwgc28gZm9yIGVycm9ycyBzdWNoIGFzIGRzY3AtdW5hdmFpbGFibGUgb3IgZW5jb2RpbmctdW5z
dXBwb3J0ZWQsIHdvdWxkIDQwOSBiZSBtb3JlIGFwcHJvcHJpYXRlIHRoYW4gNDAwPw0KICAgIA0K
ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIMKnMy40Og0KICAgIA0KICAgIFRoaXMg
c2VjdGlvbiBpcyB1bmNsZWFyIGFib3V0IGhvdyBTZXJ2ZXItU2VudCBFdmVudHMgYXJlIHRvIGJl
IHVzZWQgKGluDQogICAgcGFydGljdWxhciwgdGhleSBkb24ndCBzYXkgYW55dGhpbmcgYWJvdXQg
ZXZlbnQgdHlwZSB0byBiZSB1c2VkKS4gQmFzZWQgb24gdGhlDQogICAgb25lIGV4YW1wbGUgaW4g
QXBwZW5kaXggQSB0aGF0IHNob3dzIFNTRSBzeW50YXgsIEknbSBhc3N1bWluZyB5b3UgcHJvYmFi
bHkgZG8NCiAgICBub3QgaW50ZW5kIHRvIHVzZSBTU0UgImV2ZW50IHR5cGUiIGZpZWxkcyB0byBk
aXN0aW5ndWlzaCBiZXR3ZWVuIGV2ZW50cyBpbiBhbnkNCiAgICB3YXkuICBUaGlzIHdvdWxkIG1l
YW4gdGhhdCB5b3UgbmVlZCB0byBzcGVjaWZ5IHRoYXQgYWxsIFNTRSBtZXNzYWdlcyBhcmUgc2Vu
dA0KICAgIHdpdGggYW4gZXZlbnQgdHlwZSBvZiAibWVzc2FnZSwiIHdoaWNoIHRoZSBzZXJ2ZXIg
bWF5IG9taXQgKGFzIGl0IGlzIHRoZQ0KICAgIGRlZmF1bHQgc3BlY2lmaWVkIGluIHRoZSBTZXJ2
ZXItU2lkZSBFdmVudHMgc3BlY2lmaWNhdGlvbikuICBUaGlzIG1lYW5zIHRoYXQNCiAgICBjbGll
bnRzIHdpbGwgbmVlZCB0byBhY2NlcHQgYm90aDoNCiAgICANCiAgICBkYXRhOiB7DQogICAgZGF0
YTogICAiaWV0Zi1yZXN0Y29uZjpub3RpZmljYXRpb24iIDogew0KICAgIGRhdGE6ICAgICAiZXZl
bnRUaW1lIjogIjIwMDctMDktMDFUMTA6MDA6MDBaIiwNCiAgICBkYXRhOiAgICAgImlldGYtc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zOnN1YnNjcmlwdGlvbi1tb2RpZmllZCI6IHsNCiAgICBkYXRh
OiAgICAgICAiaWQiOiAiMzkiLA0KICAgIGRhdGE6ICAgICAgICJ1cmkiOiAiaHR0cHM6Ly9leGFt
cGxlLmNvbS9yZXN0Y29uZi9zdWJzY3JpcHRpb25zLzIyIg0KICAgIGRhdGE6ICAgICAgICJzdHJl
YW0teHBhdGgtZmlsdGVyIjogIi9leGFtcGxlLW1vZHVsZTpmb28iLA0KICAgIGRhdGE6ICAgICAg
ICJzdHJlYW0iOiB7DQogICAgZGF0YTogICAgICAgICAgImlldGYtbmV0Y29uZi1zdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnMiIDogIk5FVENPTkYiDQogICAgZGF0YTogICAgICAgfQ0KICAgIGRhdGE6
ICAgICB9DQogICAgZGF0YTogICB9DQogICAgZGF0YTogfQ0KICAgIA0KICAgIC4uLmFuZC4uLg0K
ICAgIA0KICAgIGV2ZW50OiBtZXNzYWdlDQogICAgZGF0YTogew0KICAgIGRhdGE6ICAgImlldGYt
cmVzdGNvbmY6bm90aWZpY2F0aW9uIiA6IHsNCiAgICBkYXRhOiAgICAgImV2ZW50VGltZSI6ICIy
MDA3LTA5LTAxVDEwOjAwOjAwWiIsDQogICAgZGF0YTogICAgICJpZXRmLXN1YnNjcmliZWQtbm90
aWZpY2F0aW9uczpzdWJzY3JpcHRpb24tbW9kaWZpZWQiOiB7DQogICAgZGF0YTogICAgICAgImlk
IjogIjM5IiwNCiAgICBkYXRhOiAgICAgICAidXJpIjogImh0dHBzOi8vZXhhbXBsZS5jb20vcmVz
dGNvbmYvc3Vic2NyaXB0aW9ucy8yMiINCiAgICBkYXRhOiAgICAgICAic3RyZWFtLXhwYXRoLWZp
bHRlciI6ICIvZXhhbXBsZS1tb2R1bGU6Zm9vIiwNCiAgICBkYXRhOiAgICAgICAic3RyZWFtIjog
ew0KICAgIGRhdGE6ICAgICAgICAgICJpZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRp
b25zIiA6ICJORVRDT05GIg0KICAgIGRhdGE6ICAgICAgIH0NCiAgICBkYXRhOiAgICAgfQ0KICAg
IGRhdGE6ICAgfQ0KICAgIGRhdGE6IH0NCiAgICANCiAgICBJdCBtYXkgYmUgaGVscGZ1bCB0byBp
bmNvcnBvcmF0ZSB0aGUgU1NFIHN5bnRheCBpbnRvIGFsbCBvZiB0aGUgbm90aWZpY2F0aW9uDQog
ICAgZXhhbXBsZXMgaW4gQXBwZW5kaXggQSAodGhhdCBpcywgYWxsIG9mIHRoZSBleGFtcGxlcyBp
biBBLjIgYW5kIEEuMykuIEkgd291bGQNCiAgICByZWNvbW1lbmQgYSBtaXggb2YgZXhhbXBsZXMg
d2l0aCBhbmQgd2l0aG91dCAiZXZlbnQ6IG1lc3NhZ2UiLg0KPFJSPiBBbmR5IEJpZXJtYW4gKG9u
ZSBvZiB0aGUgY28tYXV0aG9ycykgbWVudGlvbmVkIHRoYXQgUkVTVENPTkYgZG9lcyBub3QgZGVm
aW5lIGFueSB2YWx1ZXMgZm9yICJldmVudCIgYW5kIHBvaW50ZWQgdXMgdG8gdGhpcyB0ZXh0IGZy
b20gUkZDODA0MCBQNzIgICAgDQogICBBIFJFU1RDT05GDQogICBzZXJ2ZXIgU0hPVUxEIE5PVCBz
ZW5kIHRoZSAiZXZlbnQiIG9yICJpZCIgZmllbGRzLCBhcyB0aGVyZSBhcmUgbm8NCiAgIG1lYW5p
bmdmdWwgdmFsdWVzIHRoYXQgY291bGQgYmUgdXNlZCBmb3IgdGhlbSB0aGF0IHdvdWxkIG5vdCBi
ZQ0KICAgcmVkdW5kYW50IHRvIHRoZSBjb250ZW50cyBvZiB0aGUgbm90aWZpY2F0aW9uIGl0c2Vs
Zi4gICAgDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQogICAgDQogICAgR2VuZXJhbCBjb21tZW50Og0KICAgIA0KICAgIEl0J3MgYSBiaXQgdW5j
bGVhciBhYm91dCB3aGF0IHRoZSBub3JtYXRpdmUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBTZXJ2
ZXItU2VudA0KICAgIEV2ZW50cyBjb25uZWN0aW9uIGFuZCBhIHN1YnNjcmlwdGlvbiBpcyBpbnRl
bmRlZCB0byBiZS4gRm9yIGV4YW1wbGU6IGlmIEkgc2VuZA0KICAgIGFuIFJQQyBjb21tYW5kIHRv
IGNyZWF0ZSBhIHN1YnNjcmlwdGlvbiwgYW5kIHRoZW4gbWFrZSB0d28gZGlmZmVyZW50IFNTRQ0K
ICAgIGNvbm5lY3Rpb25zIHRvIHRoZSByZXN1bHRpbmcgVVJMLCB3aWxsIHRoZXkgYm90aCByZWNl
aXZlIGV2ZW50cyBhc3NvY2lhdGVkDQogICAgd2l0aCB0aGF0IHN1YnNjcmlwdGlvbj8gSWYgc28s
IGRvZXMgYSBUTFMgaGVhcnRiZWF0IGZhaWx1cmUgb24gb25lIG9mIHRoZW0NCiAgICBjYXVzZSB0
aGUgZW50aXJlIHN1YnNjcmlwdGlvbiB0byBnbyBhd2F5PyAoSWYgbm90LCB3aGF0IGhhcHBlbnM/
KQ0KPFJSPiBUaGUgcmVzb3VyY2UgY3JlYXRlZCB2aWEgdGhlIGVzdGFibGlzaC1zdWJzY3JpcHRp
b24gaXMgZm9yIDEgc3Vic2NyaXB0aW9uLiBUaGVyZSBjYW4gb25seSBiZSAxIEdFVCBvbiB0aGUg
VVJJIGF0IHRoZSBzYW1lIHRpbWUsIHRoaXMgZG9lcyBub3Qgc2VlbSB0byBiZSBleHBsaWNpdGx5
IHN0YXRlZCBhbnl3aGVyZSwgc28gcHJvYmFibHkgYSBnb29kIGlkZWEgdG8gYWRkIHRleHQgdG8g
dGhhdCBlZmZlY3QuDQogICAgDQogICAgSWYgSSBoYXZlIG9ubHkgb25lIGNvbm5lY3Rpb24gcmVs
YXRlZCB0byBhIHN1YnNjcmlwdGlvbiwgYW5kIEkgY2xvc2UgdGhlIFRDUA0KICAgIGNvbm5lY3Rp
b24sIGRvZXMgdGhhdCBuZWNlc3NhcmlseSBtYWtlIHRoZSBzdWJzY3JpcHRpb24gZ28gYXdheT8g
V2hhdCBpZiBJDQogICAgc2V0IHVwIGEgbmV3IFRDUCBjb25uZWN0aW9uIHJpZ2h0IGF3YXkgYWZ0
ZXIgY2xvc2luZyB0aGUgZmlyc3Qgb25lPyBXaWxsDQogICAgdGhhdCB3b3JrPw0KPFJSPiBUaGUg
c3Vic2NyaXB0aW9uIHdpbGwgbm90IGdvIGF3YXkgd2hlbiB0aGUgVENQIGNvbm5lY3Rpb24gaXMg
Y2xvc2VkLiBBcyBtZW50aW9uZWQgYXQgdGhlIGVuZCBvZiAzLjQsIHRoZSBzdWJzY3JpcHRpb24g
Z29lcyBhd2F5IG9uIHJlY2VpcHQgb2YgZGVsZXRlLXN1YnNjcmlwdGlvbi9raWxsLXN1YnNjcmlw
dGlvbiBSUENzIG9yIG9uIGxvc3Mgb2YgVExTIGhlYXJ0YmVhdC4gSWYgYSBjbGllbnQgZG9lcyBh
IEdFVCBhZnRlciBjbG9zaW5nIHRoZSBmaXJzdCBHRVQsIHllcyB0aGlzIGlzIHN1cHBvc2VkIHRv
IHdvcmsuDQogICAgDQogICAgV2hhdCBpZiBJIHVzZSBSUEMgdG8gc2V0IHVwIGEgbmV3IHN1YnNj
cmlwdGlvbiwgYW5kIHRoZW4gd2FpdCBhIGZldyBtaW51dGVzDQogICAgYmVmb3JlIGNvbm5lY3Rp
bmcgdG8gdGhlIHN1YnNjcmlwdGlvbiBVUkw/DQo8UlI+IFRoYXQgaXMgYWxzbyBzdXBwb3NlZCB0
byB3b3JrIGFzIGxvbmcgYXMgdGhlIHN1YnNjcmlwdGlvbiB3YXNuJ3QgdGVybWluYXRlZCBhcyBw
ZXIgc2VjdGlvbiAzLjQuDQogICAgDQogICAgSSBkb24ndCB0aGluayB5b3UgbmVlZCB0byBhbnN3
ZXIgYWxsIG9mIHRoZXNlIGNvcm5lciBjYXNlcyBwZXIgc2UgKGFsdGhvdWdoIGl0DQogICAgd291
bGQgYmUgbmljZSksIGJ1dCBtaW5pbWFsbHkgYSBjb3VwbGUgb2Ygc3RhdGVtZW50cyB0aGF0IGNs
ZWFybHkgc3BlbGwgb3V0DQogICAgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHN1YnNjcmlwdGlv
bnMgYW5kIHRoZSBjb25uZWN0aW9ucyB1c2VkIHRvIGRlbGl2ZXINCiAgICByZWxhdGVkIGV2ZW50
cyB3b3VsZCBoZWxwIGltcGxlbWVudG9ycyBmaWd1cmUgb3V0IHRoZSBhbnN3ZXJzIHRvIHRoZXNl
DQogICAgcXVlc3Rpb25zLg0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAg
IMKnMjoNCiAgICANCiAgICA+ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF
UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAgPiAgIlNIT1VMRCIsICJTSE9VTEQg
Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgICA+
ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5
IFtSRkMyMTE5XS4NCiAgICANCiAgICBQbGVhc2UgdXNlIHRoZSBib2lsZXJwbGF0ZSBzcGVjaWZp
ZWQgYnkgUkZDIDgxNzQuDQo8UlI+IFdpbGwgZG8uICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KICAgIA0KICAgIMKnMy4xOg0KICAgIA0KICAgID4gIEFzIHN0YXRlZCBpbiBTZWN0aW9uIDIu
MSBvZiBbUkZDODA0MF0sIGEgc3Vic2NyaWJlciBNVVNUIGVzdGFibGlzaA0KICAgID4gIHRoZSBI
VFRQIHNlc3Npb24gb3ZlciBUTFMgW1JGQzUyNDZdIGluIG9yZGVyIHRvIHNlY3VyZSB0aGUgY29u
dGVudCBpbg0KICAgID4gIHRyYW5zaXQuDQogICAgDQogICAgSXMgdGhlIGludGVudGlvbiBoZXJl
IHRvIHJlc3RyaWN0IGNsaWVudHMgdG8gVExTIDEuMj8gSWYgbm90LCBwbGVhc2UgY2l0ZQ0KICAg
IFJGQyA4NDQ2IGluc3RlYWQgb2YgUkZDIDUyNDYuIElmIHNvLCBwbGVhc2UgYWRkIHRleHQgdGhh
dCBleHBsYWlucyB3aHkuDQogICAgDQogICAgKFRoaXMgY29tbWVudCBhbHNvIGFwcGxpZXMgdG8g
c2VjdGlvbiA5KQ0KPFJSPiBXaWxsIHVwZGF0ZSB0byBSRkM4NDQ2Lg0KICAgIA0KICAgIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIMKnMy4xOg0KICAgIA0KICAgID4gIExvc3Mgb2YgdGhl
IGhlYXJ0YmVhdCBNVVNUIHJlc3VsdCBpbiBhbnkgc3Vic2NyaXB0aW9uIHJlbGF0ZWQgVENQDQog
ICAgDQogICAgbml0OiAiLi4uc3ViY3JpcHRpb24tcmVsYXRlZC4uLiINCjxSUj4gV2lsbCBjaGFu
Z2UgdG8gc3Vic2NyaXB0aW9uLXJlbGF0ZWQuICAgIA0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KICAg
IA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog
ICAgbmV0Y29uZiBtYWlsaW5nIGxpc3QNCiAgICBuZXRjb25mQGlldGYub3JnDQogICAgaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAgDQoNCg==


From nobody Fri May 17 09:22:12 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD8B12013C; Fri, 17 May 2019 09:22:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155811013021.26439.5815156474038042593@ietfa.amsl.com>
Date: Fri, 17 May 2019 09:22:10 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 16:22:10 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : YANG Groupings for TCP Clients and TCP Servers
        Authors         : Kent Watsen
                          Michael Scharf
	Filename        : draft-ietf-netconf-tcp-client-server-00.txt
	Pages           : 16
	Date            : 2019-05-17

Abstract:
   This document defines three YANG modules: the first defines a
   grouping for configuring a generic TCP client, the second defines a
   grouping for configuring a generic TCP server, and the third defines
   a grouping common to the TCP clients and TCP servers.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-00
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-00


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

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


From nobody Fri May 17 13:35:55 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92845120165; Fri, 17 May 2019 13:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 V15tTLDTspdk; Fri, 17 May 2019 13:35:50 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4AD4312011C; Fri, 17 May 2019 13:35:49 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x4HKZe7X053898 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 May 2019 15:35:41 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1558125342; bh=Fq6ymQcWPJ78iFcTnpA53HreylxZKk24LhTNMQ4t3dU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=h1H8O6QP4OrShCKbpeQa5o7EtjWr7HgnqxozAqapU/QYzmlRxlHcTqya+dhTB1Hhw E4Ja2oFT1rZRbJx3XATTa2cZhive1qaxKt/tl0FcofwtEuosOxcS4EPCVB+CqkjK/c inO7ufXSXLCxJyQwCZdV4iq7K+Lo4M/W1nklpV30=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: "Reshad Rahman (rrahman)" , The IESG 
Cc: "draft-ietf-netconf-restconf-notif@ietf.org" , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
References: <155790481851.17474.3456985672733157831.idtracker@ietfa.amsl.com> 
From: Adam Roach 
Message-ID: <88ad00b4-7617-3ca1-3262-08412aa98e41@nostrum.com>
Date: Fri, 17 May 2019 15:35:35 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netconf] Adam Roach's Discuss on draft-ietf-netconf-restconf-notif-13: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 20:35:53 -0000

Thanks for your quick response. I have some answers inline below (and 
have removed the part of the conversation that requires no response).


On 5/16/19 9:27 PM, Reshad Rahman (rrahman) wrote:
> Hi,
>
> Thanks for the review, please see inline.
>
>
> On 2019-05-15, 3:20 AM, "netconf on behalf of Adam Roach via Datatracker"  wrote:
>
>      Adam Roach has entered the following ballot position for
>      draft-ietf-netconf-restconf-notif-13: Discuss
>      
>      When responding, please keep the subject line intact and reply to all
>      email addresses included in the To and CC lines. (Feel free to cut this
>      introductory paragraph, however.)
>      
>      
>      Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>      for more information about IESG DISCUSS and COMMENT positions.
>      
>      
>      The document, along with other ballot positions, can be found here:
>      https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif/
>      
>      
>      
>      ----------------------------------------------------------------------
>      DISCUSS:
>      ----------------------------------------------------------------------
>      
>      Thanks for all the work that the authors and other contributors have
>      put into this document. I have two comments that need to be addressed
>      before publication, but they should both be very easy to fix.
>      
>      ---------------------------------------------------------------------------
>      
>      
>      §3.3:
>      
>      >  If a publisher fails to serve the RPC request for one of the reasons
>      >  indicated in [I-D.draft-ietf-netconf-subscribed-notifications]
>      >  Section 2.4.6 or [I-D.ietf-netconf-yang-push] Appendix A, this will
>      >  be indicated by "406" status code transported in the HTTP response.
>      
>      This really isn't what 406 means. 406 means "you sent one or more of the
>      'Accept', 'Accept-Charset', 'Accept-Encoding', or 'Accept-Language' header
>      fields, and I can't generate a response that satisfies what you've asked for."
>      
>      For some of the errors listed in the two cited sections, there is a reasonable
>      semantic mapping onto existing HTTP response codes; e.g. the
>      "no-such-subscription" errors could all reasonably map on to HTTP 404.  I'll
>      note that RFC 8040 section 7 performs exactly this kind of mapping, so the
>      approach seems to be consistent with the way that RESTCONF has elected to use
>      HTTP response codes. In fact, this document already maps from the cited errors
>      to error tags already, and that table maps from error-tag to
>      HTTP response codes, so fixing this should be the relatively straightforward
>      exercise of updaing the tables in this section to also include the HTTP response
>      code that RFC 8040 maps to the indicated error-tag. For example:
>      
>           error identity         uses error-tag             HTTP Response
>           ---------------------- --------------             -------------
>           dscp-unavailable       invalid-value              400
>           encoding-unsupported   invalid-value              400
>           filter-unsupported     invalid-value              400
>           insufficient-resources resource-denied            409
>           no-such-subscription   invalid-value              404
>           replay-unsupported     operation-not-supported    501
>      
>           error identity              uses error-tag          HTTP Response
>           ----------------------      --------------          -------------
>           cant-exclude                operation-not-supported 501
>           datastore-not-subscribable  invalid-value           400
>           no-such-subscription-resync invalid-value           404
>           on-change-unsupported       operation-not-supported 501
>           on-change-sync-unsupported  operation-not-supported 501
>           period-unsupported          invalid-value           400
>           update-too-big              too-big                 400
>           sync-too-big                too-big                 400
>           unchanging-selection        operation-failed        500
>      
>      However you choose to address this, if the error isn't related to any of the
>      four header fields I mention above, then you can't specify the use of a 406.
>  Thank you for suggesting status codes for the different errors, much appreciated. I agree that 406 is not appropriate. Regarding 400, my understanding is that it is for invalid syntax, so for errors such as dscp-unavailable or encoding-unsupported, would 409 be more appropriate than 400?


400 is a generic "there is something wrong with your request for which 
there is no more specific error code," and it's used pretty extensively 
by the base RESTCONF specification. 409 generally means that the server 
is in a (typically temporary) state that is incompatible with the action 
indicated by the request.

Once of the things that I took pains to ensure in my suggestions is that 
the HTTP response I suggest above is one of the ones that RFC 8040 
indicates for the corresponding error-tag (even for those cases where I 
don't think RFC 8040 made a strictly accurate choice). I suspect that it 
is best if the RESTCONF notification behavior is kept in sync with the 
base RESTCONF behavior, but I'm not an expert on the whole YANG 
ecosystem, so I may be mistaken.


>      
>      ---------------------------------------------------------------------------
>      
>      §3.4:
>      
>      This section is unclear about how Server-Sent Events are to be used (in
>      particular, they don't say anything about event type to be used). Based on the
>      one example in Appendix A that shows SSE syntax, I'm assuming you probably do
>      not intend to use SSE "event type" fields to distinguish between events in any
>      way.  This would mean that you need to specify that all SSE messages are sent
>      with an event type of "message," which the server may omit (as it is the
>      default specified in the Server-Side Events specification).  This means that
>      clients will need to accept both:
>      
>      data: {
>      data:   "ietf-restconf:notification" : {
>      data:     "eventTime": "2007-09-01T10:00:00Z",
>      data:     "ietf-subscribed-notifications:subscription-modified": {
>      data:       "id": "39",
>      data:       "uri": "https://example.com/restconf/subscriptions/22"
>      data:       "stream-xpath-filter": "/example-module:foo",
>      data:       "stream": {
>      data:          "ietf-netconf-subscribed-notifications" : "NETCONF"
>      data:       }
>      data:     }
>      data:   }
>      data: }
>      
>      ...and...
>      
>      event: message
>      data: {
>      data:   "ietf-restconf:notification" : {
>      data:     "eventTime": "2007-09-01T10:00:00Z",
>      data:     "ietf-subscribed-notifications:subscription-modified": {
>      data:       "id": "39",
>      data:       "uri": "https://example.com/restconf/subscriptions/22"
>      data:       "stream-xpath-filter": "/example-module:foo",
>      data:       "stream": {
>      data:          "ietf-netconf-subscribed-notifications" : "NETCONF"
>      data:       }
>      data:     }
>      data:   }
>      data: }
>      
>      It may be helpful to incorporate the SSE syntax into all of the notification
>      examples in Appendix A (that is, all of the examples in A.2 and A.3). I would
>      recommend a mix of examples with and without "event: message".
>  Andy Bierman (one of the co-authors) mentioned that RESTCONF does not define any values for "event" and pointed us to this text from RFC8040 P72
>     A RESTCONF
>     server SHOULD NOT send the "event" or "id" fields, as there are no
>     meaningful values that could be used for them that would not be
>     redundant to the contents of the notification itself.


Ah, okay. That seems to cover the situation, although it might bear 
reiterating in this document also.


>      
>
>      ----------------------------------------------------------------------
>      COMMENT:
>      ----------------------------------------------------------------------
>      
>      General comment:
>      
>      It's a bit unclear about what the normative relationship between a Server-Sent
>      Events connection and a subscription is intended to be. For example: if I send
>      an RPC command to create a subscription, and then make two different SSE
>      connections to the resulting URL, will they both receive events associated
>      with that subscription? If so, does a TLS heartbeat failure on one of them
>      cause the entire subscription to go away? (If not, what happens?)
>  The resource created via the establish-subscription is for 1 subscription. There can only be 1 GET on the URI at the same time, this does not seem to be explicitly stated anywhere, so probably a good idea to add text to that effect.
>      
>      If I have only one connection related to a subscription, and I close the TCP
>      connection, does that necessarily make the subscription go away? What if I
>      set up a new TCP connection right away after closing the first one? Will
>      that work?
>  The subscription will not go away when the TCP connection is closed. As mentioned at the end of 3.4, the subscription goes away on receipt of delete-subscription/kill-subscription RPCs or on loss of TLS heartbeat. If a client does a GET after closing the first GET, yes this is supposed to work.
>      
>      What if I use RPC to set up a new subscription, and then wait a few minutes
>      before connecting to the subscription URL?
>  That is also supposed to work as long as the subscription wasn't terminated as per section 3.4.
>      
>      I don't think you need to answer all of these corner cases per se (although it
>      would be nice), but minimally a couple of statements that clearly spell out
>      the relationship between subscriptions and the connections used to deliver
>      related events would help implementors figure out the answers to these
>      questions.


Thanks for the explanation; that all makes sense. I suggest you add 
whatever text you feel is appropriate so that other readers understand 
it as well as I do now. :)

Thanks!

/a


From nobody Tue May 21 02:46:37 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D996E1200CC; Tue, 21 May 2019 02:46:35 -0700 (PDT)
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, 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 TOe1d90T9yJ4; Tue, 21 May 2019 02:46:32 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00091.outbound.protection.outlook.com [40.107.0.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4676A12011C; Tue, 21 May 2019 02:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F1K8irG0xXv58GFIRhbJvcwy4fIyNthJy6Nwwbzf324=; b=pHsrpje+BTsShnNm7Zk/xjy+PiM1kwV0HikoXhtWqBtGsRo0yQIsPTX0APd7lmiAktK57IkK27F8lHW6y929d+j61PrR8JySlaYRTDk2jEXgy98saY4ZiujiYarTBrWeiS0vTrGHWNJBwz675jKqyJMp0hOKfo0qRoiHnnbYT7E=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5326.eurprd07.prod.outlook.com (20.178.11.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.9; Tue, 21 May 2019 09:46:29 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d%7]) with mapi id 15.20.1922.013; Tue, 21 May 2019 09:46:29 +0000
From: tom petch 
To: "Eric Voit (evoit)" 
CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-21
Thread-Index: AQHVD7oQaflczmem80CO42kqbYL/XQ==
Date: Tue, 21 May 2019 09:46:29 +0000
Message-ID: <057401d50fb9$855e16c0$4001a8c0@gateway.2wire.net>
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>     <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net> <23a9e41d7bcb41d7a6b7a9eeb50aaa18@XCH-RTP-013.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LNXP265CA0006.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::18) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2d900107-eb9f-4562-2cc4-08d6ddd132db
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5326; 
x-ms-traffictypediagnostic: VI1PR07MB5326:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(39860400002)(136003)(51914003)(13464003)(51444003)(189003)(199004)(99286004)(316002)(26005)(52116002)(54906003)(14454004)(81686011)(81816011)(53936002)(6246003)(61296003)(76176011)(6916009)(486006)(5660300002)(386003)(6506007)(53546011)(68736007)(102836004)(2906002)(6116002)(478600001)(71200400001)(84392002)(30864003)(186003)(86362001)(446003)(476003)(14496001)(71190400001)(3846002)(1556002)(305945005)(7736002)(50226002)(44736005)(6486002)(8676002)(229853002)(6436002)(8936002)(81166006)(81156014)(86152003)(4720700003)(66066001)(62236002)(44716002)(256004)(6512007)(9686003)(73956011)(66946007)(14444005)(15650500001)(25786009)(66446008)(64756008)(66556008)(4326008)(66476007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5326; H:VI1PR07MB3118.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-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DuiN4sVi/Tt4NWQdMzqUyPgIHPTgs3grR8hJNy2D/IrCwuIV/o/Czu3bZliDdqBY+aF1oyAsD2fO6t0ZAO1ehpgD29eGym+Z6EXjgs76W6UMnmwlNHI0aDeuVHjH9TeeUNNDa0u7QBL3dR96fn/UfYIBoZMSF+tGnHwPGSD2yFCFvc+kVJq24w1Wsl+iNxVZbC9jw3dxes4mPDaaj4VNyuDPhFS3erHKmx9P2Aa/w2Sc7zX2UasKYsUxqzVfGBj/1lstDHc4k2eFMuFe5CbRI8Cv2yB/rJzMJ10NxKxlSS33mBpjwdsBdlomlHdi4kLo33gi0TJD4S1Fi8lifC1NscT6BOMuz3PSYeWfEkxEqY3qrjPyt6yxH9dpALhOHJb/xayvDSlN5e5QP+j+FrRhK6mZiY+cBS/4LsBP5yPNnx4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <063C44D8CE7D4549A6A46CD8BB45B179@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d900107-eb9f-4562-2cc4-08d6ddd132db
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 09:46:29.5768 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ietfc@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5326
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-21
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 09:46:36 -0000

RXJpYw0KDQpMb29rcyBnb29kIGJ1dCBJIGRvIGFncmVlIHdpdGggQmVuamFtaW4gYWJvdXQgdGhl
IGdyYW1tYXIgb2YNCg0KIkFuZCBwZXIgW1JGQzUyNzddJ3MgImV2ZW50VGltZSIgb2JqZWN0IGRl
ZmluaXRpb24sIHRoZQ0KICAgImV2ZW50VGltZSIgcG9wdWxhdGVkIHdpdGggdGhlIGV2ZW50IG9j
Y3VycmVuY2UgdGltZS4iDQoNCkkgY2Fubm90IG1ha2UgdGhhdCBpbnRvIGEgc2VudGVuY2UuICdw
b3B1bGF0ZWQnIHNlZW1zIHRvIGJlIGEgcGFzdA0KcGFydGljaXBsZSBtYWtpbmcgJyBwb3B1bGF0
ZWQgd2l0aCB0aGUgZXZlbnQgb2NjdXJyZW5jZSB0aW1lJyBpbnRvIGFuDQphZGplY3RpdmFsIGNs
YXVzZSBhbmQgdGhlIHdob2xlIGxhY2tpbmcgYSBtYWluIHZlcmI7IElNSE8gaXQgbmVlZHMgYQ0K
dmVyYiBiZWZvcmUgJ3BvcHVsYXRlZCcgc3VjaCBhcyAnaXMnLCAnd2lsbCBiZScsICdNQVkgYmUn
LCAgJyBNVVNUIGJlJw0KZXRjLiAgSSBhd2FpdCB3aXRoIGludGVyZXN0IHRoZSB2aWV3cyBvZiB0
aGUgUkZDIEVkaXRvciB3aG9zZSB3b3JkIG9uDQp0aGVzZSBtYXR0ZXJzIEkgdHJlYXQgYXMgZ29z
cGVsLg0KDQpUb20gUGV0Y2gNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTog
IkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPg0KU2VudDogVHVlc2RheSwgTWF5
IDE0LCAyMDE5IDM6NTkgUE0NCg0KPiBIaSBUb20sDQo+DQo+ID4gRnJvbTogdG9tIHBldGNoLCBN
YXkgMTQsIDIwMTkgNzo0OCBBTQ0KPiA+DQo+ID4gRXJpYw0KPiA+DQo+ID4gQSBxdWljayBicm93
c2UgdGVsbHMgbWUgdGhhdCBpbiB0aGUgUkZDIEkgcmVndWxhcmx5IHJlZmVyIHRvLA0KJ2JpbmRp
bmcnDQo+ID4gaXMgdXNlZCBpbiBvdmVyIDMwMCBvZiB0aGVtIGJ1dCB0aGF0IGluIGFsbCB0aG9z
ZSB0aGF0IEkgbG9va2VkIGF0LA0KaXQgaXMgYWx3YXlzDQo+ID4gYmluZGluZyBhbiBlbGVtZW50
IG9mIGEgc2V0IHRvIGFuIGVsZW1lbnQgb2YgdGhlIHNhbWUgb3IgYSBkaWZmZXJlbnQNCnNldCwg
d2hlcmUNCj4gPiB0aGUgc2V0cyBhcmUgc2ltaWxhciBpbiBuYXR1cmUuICBUaHVzIEFSUCBiaW5k
cyBhbiBJUCBhZGRyZXNzIHRvIGENCk1BQyBhZGRyZXNzIG9yDQo+ID4gYSBiaWRpcmVjdGlvbmFs
IE1QTFMgTFNQIGJpbmRzIG9uZSB1bmlkaXJlY3Rpb25hbCBMU1AgdG8gYW5vdGhlciBhbmQNCnNv
IG9uZS4NCj4gPg0KPiA+IFdoYXQgSSBkbyBub3QgbGVhcm4gaGVyZSBpcyB3aGF0IGlzIGJlaW5n
IGJvdW5kIHRvIHdoYXQuDQo+ID4NCj4gPiBQZXJoYXBzDQo+ID4gICAgVGhpcyBkb2N1bWVudCBz
cGVjaWZpZXMgdGhlIGJpbmRpbmcgb2YgYSBzdHJlYW0gb2YgZXZlbnRzIHdoaWNoDQpmb3JtIHBh
cnQgb2YgYQ0KPiA+IGR5bmFtaWMgc3Vic2NyaXB0aW9uIHRvIHRoZSBORVRDT05GDQo+ID4gICAg
cHJvdG9jb2wgW1JGQzYyNDFdLiAgRHluYW1pYyBzdWJzY3JpcHRpb25zIGFyZSBkZWZpbmVkIGlu
DQo+ID4gICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z
XS4NCj4NCj4gSSBhbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBmaXJz
dCBzZW50ZW5jZSBvZiB0aGUNCkludHJvIGhlcmUsIGFzIGRvY3VtZW50IHJlZmVyZW5jZXMgYXJl
IG5vdCBpbiBhYnN0cmFjdHMuDQo+DQo+IFRoaXMgdGV4dCB3b3JrcyBmb3IgbWUuICAgQW55IG9i
amVjdGlvbnMgYW55b25lPw0KPg0KPiA+IFRoZSBjcnV4IGlzICJiaW5kaW5nIC4uLiB0byAuLi4i
IHdoaWNoIGlzIGN1cnJlbnRseSBsYWNraW5nLg0KPiA+DQo+ID4gTW9yZSBnZW5lcmFsbHk6LSgN
Cj4gPiBJIGRvIGZpbmQgdGhpcyBJLUQgaGFyZCB0byB1bmRlcnN0YW5kLiAgSSB0aGluayB0aGF0
IHRoZSBrZXkgaXMgdGhhdA0KdGhpcyBJLUQsIG1vcmUNCj4gPiB0aGFuIGFueSBvdGhlciBJIGNh
biB0aGluayBvZiwgaXMgc28gZGVwZW5kZW50IG9uIG9uZSBvZiBpdHMNCk5vcm1hdGl2ZQ0KPiA+
IFJlZmVyZW5jZXMsIHRvIHdoaXQsIHN1YnNjcmliZWQgbm90aWZpY2F0aW9uczsgSSB0aGluayB0
aGF0IHRoYXQNCm5lZWRzIGNhbGxpbmcgb3V0DQo+ID4gc28gSSB3b3VsZCBhZGQgIlRoaXMgbWVt
byBhc3N1bWVzIHRoYXQgdGhlIHJlYWRlciBpcyBmYW1pbGlhciB3aXRoDQp0aGUNCj4gPiB0ZXJt
aW5vbG9neSBhbmQgY29uY2VwdHMgZGVmaW5lZCBpbiBbc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z
XSINCj4NCj4gQXMgdGhlIGxhc3Qgc2VudGVuY2UgaW4gdGhlIEludHJvIHNlY3Rpb24sIEkgaGF2
ZSBhZGRlZDoNCj4gIlRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IHRoZSByZWFkZXIgaXMgZmFt
aWxpYXIgd2l0aCB0aGUNCnRlcm1pbm9sb2d5IGFuZCBjb25jZXB0cyBkZWZpbmVkIGluDQpbSS1E
LmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLiINCj4NCj4gPiBZ
ZXMsIHRoYXQgaXMgd2hhdCBhIE5vcm1hdGl2ZSBSZWZlcmVuY2UgbWVhbnMgYnV0IEkgZmluZCB0
aGlzDQpleGFtcGxlIHNvDQo+ID4gZXh0cmVtZSB0aGF0IEkgdGhpbmsgaXQgbmVlZHMgY2FsbGlu
ZyBvdXQuICBFYWNoIHRpbWUgaW4gdGhlIHBhc3QNCnNpeCBtb250aHMgSSBoYXZlDQo+ID4gdHVy
bmVkIHRvIHRoaXMgSS1EIChpdCBpcyB0aGUgc21hbGxlc3Qgb2YgdGhlIHZlcnkgbGFyZ2Ugc2V0
IG9mDQpuZXRjb25mIEktRHM6LSksIEkgaGF2ZQ0KPiA+IGdpdmVuIHVwLCBldmVudHVhbGx5IHdv
cmtpbmcgb3V0IHRoYXQgZmlyc3QgSSBtdXN0IG1hc3RlciB0aGUgODANCnBhZ2VzIG9mDQo+ID4g
c3Vic2NyaWJlZCBub3RpZmljYXRpb25zLiAgVGhpcyBtYXkgbm90IGJlIHNvIG9idmlvdXMgdG8g
dGhvc2UNCmludm9sdmVkIGF0IExhc3QNCj4gPiBDYWxsIHRpbWUuDQo+DQo+IFVuZGVyc3Rvb2Qu
ICBBbmQgaXQgaXMgdHJ1ZSB0aGF0IHVuZGVyc3RhbmRpbmcNCnN1YnNjcmliZWQtbm90aWZpY2F0
aW9ucyBpcyBhIHByZXJlcXVpc2l0ZS4NCj4NCj4gRXJpYw0KPg0KPiA+IFRvbSBQZXRjaA0KPiA+
DQo+ID4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIkVyaWMg
Vm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPg0KPiA+IFNlbnQ6IEZyaWRheSwgTWF5IDEw
LCAyMDE5IDc6MzkgUE0NCj4gPg0KPiA+DQo+ID4gPiBIaSBEaHJ1diwNCj4gPiA+IEhpIEtlbnQs
DQo+ID4gPg0KPiA+ID4gPiBGcm9tOiBEaHJ1diBEaG9keSwgTWF5IDksIDIwMTkgMTE6MjggUE0N
Cj4gPiA+ID4NCj4gPiA+ID4gSGkgRXJpYywNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IEVyaWMgVm9pdCAoZXZvaXQpIFttYWls
dG86ZXZvaXRAY2lzY28uY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IDEwIE1heSAyMDE5IDAyOjE4DQo+
ID4gPiA+ID4gSGkgRGhydXYsDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEZyb206IERocnV2IERo
b2R5LCBNYXkgOSwgMjAxOSAxMjowMyBBTQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIEVy
aWMsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhhbmtzIGZvciB0aGUgdXBkYXRlLiBJIHNl
ZSBvbmUgbWlub3IgY29tbWVudCB0aGF0IGlzIG5vdA0KPiA+IGhhbmRsZWQuDQo+ID4gPiA+ID4g
PiBNYXliZSB5b3UgbWlzc2VkIGl0PyBPciB5b3UgZGlzYWdyZWUsIHRoYXQgc29tZSBtb3JlIHRl
eHQgaXMNCj4gPiByZXF1aXJlZD8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IE1pbm9yIElz
c3VlczoNCj4gPiA+ID4gPiA+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gPiAoMSkgQWJz
dHJhY3QgJiBJbnRyb2R1Y3Rpb24sIEl0IGlzIG5vdCBjbGVhciB3aGF0IGRvZXMgdGhlDQo+ID4g
J2JpbmRpbmcnDQo+ID4gPiA+ID4gPiA+IG1lYW4gYW5kIHdobyBhcmUgdGhlIHBhcnRpZXMgdG8g
dGhpcyBiaW5kaW5nPyBJZiB0aGlzIGlzDQp0aGUNCj4gPiA+ID4gPiA+ID4gZG9jdW1lbnQgdGhh
dA0KPiA+ID4gPiA+ID4gbWVudGlvbnMgJ2JpbmRpbmcnDQo+ID4gPiA+ID4gPiA+IGZpcnN0LCBz
byBwbGVhc2UgYWRkIHNvbWUgbW9yZSBjbGFyaWZ5aW5nIHRleHQuDQo+ID4gPiA+ID4NCj4gPiA+
ID4gPiBUaGlzIGlzIG5vdCB0aGUgZmlyc3QgZG9jdW1lbnQgd2hpY2ggbWVudGlvbnMgJ2JpbmRp
bmcnDQpmaXJzdC4NCj4gPiBUaGUNCj4gPiA+ID4gPiBkb2N1bWVudCB3aGljaCBkb2VzIHRoaXMg
Zmlyc3QgaXMNCmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLQ0KPiA+ID4gPiA+IG5vdGlm
aWNhdGlvbnMuDQo+ID4gPiA+IFtbRGhydXYgRGhvZHldXSBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zIHNheXMNCj4gPiB0aGlzIGluIHRoZQ0KPiA+ID4gPiBJbnRy
b2R1Y3Rpb24gLQ0KPiA+ID4gPg0KPiA+ID4gPiAgICBXaGlsZSB0aGUgZnVuY3Rpb25hbGl0eSBk
ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMNCnRyYW5zcG9ydC0NCj4gPiA+ID4gICAgYWdub3N0
aWMsIHRyYW5zcG9ydHMgbGlrZSBORVRDT05GIFtSRkM2MjQxXSBvciBSRVNUQ09ORg0KW1JGQzgw
NDBdDQo+ID4gY2FuDQo+ID4gPiA+ICAgIGJlIHVzZWQgdG8gY29uZmlndXJlIG9yIGR5bmFtaWNh
bGx5IHNpZ25hbCBzdWJzY3JpcHRpb25zLCBhbmQNCj4gPiB0aGVyZQ0KPiA+ID4gPiAgICBhcmUg
YmluZGluZ3MgZGVmaW5lZCBmb3Igc3Vic2NyaWJlZCBldmVudCByZWNvcmQgZGVsaXZlcnkgZm9y
DQo+ID4gTkVUQ09ORg0KPiA+ID4gPiAgICB3aXRoaW4gW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYt
bmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zXSwNCmFuZA0KPiA+IGZvcg0KPiA+ID4gPiAgICBS
RVNUQ09ORiB3aXRoaW4gW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWZdLg0K
PiA+ID4gPg0KPiA+ID4gPiBJIHRoaW5rIHRoaXMgaXMgb25seSB0aW1lIGJpbmRpbmcgaXMgdXNl
ZCBpbiB0aGlzIGNvbnRleHQuDQo+ID4gPiA+IEFuZCBub3cgdGhpcyBJLUQgc2F5cyAtDQo+ID4g
PiA+DQo+ID4gPiA+ICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBiaW5kaW5nIGZvciBldmVu
dHMgc3RyZWFtZWQgb3ZlciB0aGUNCj4gPiBORVRDT05GDQo+ID4gPiA+ICAgIHByb3RvY29sIFtS
RkM2MjQxXSBmb3IgZHluYW1pYyBzdWJzY3JpcHRpb25zIGFzIGRlZmluZWQgaW4NCj4gPiA+ID4g
ICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4NCj4g
PiA+ID4NCj4gPiA+ID4gQW5kIHlvdSBkb27igJl0IHVzZSB0aGlzIHRlcm0gZXZlciBhZ2Fpbi4N
Cj4gPiA+ID4NCj4gPiA+ID4gVG8gbWUgdGhpcyBpcyBiaXQgY2lyY3VsYXIgYW5kIHRoZSB0ZXJt
IGJpbmRpbmcgaXMgdXNlZCBsb29zZWx5Lg0KQW5kDQo+ID4gdGh1cyBJIGZsYWdnZWQNCj4gPiA+
ID4gaXQuIEkgd2lsbCBsZXQgeW91IGFuZCBLZW50IGRlY2lkZSB0aGUgcmlnaHQgYXBwcm9hY2gu
DQo+ID4gPg0KPiA+ID4gSSByZWFsbHkgYW0gb2sgd2l0aCBtYW55IG9wdGlvbnMgaGVyZToNCj4g
PiA+ICAoYSkgIGtlZXAgdGhlIGN1cnJlbnQgdGV4dC4NCj4gPiA+ICAoYikgIHVzZSBwcmV2aW91
cyB2ZXJzaW9ucyBvZiB0aGUgYWJzdHJhY3QuDQo+ID4gPiAgKGMpICByZXBsYWNlIHRoZSB3b3Jk
IGJpbmRpbmcgd2l0aCBzb21lIG90aGVyIHRleHQuDQo+ID4gPg0KPiA+ID4gR2V0dGluZyB0aGUg
cmlnaHQgd29yZHMgaGVyZSBuYWlsZWQgZG93biBoYXNuJ3QgYmVlbiBmcm9tIGxhY2sgb2YNCj4g
PiBlZmZvcnQuICBUbyBnaXZlIHlvdSBhbiBpZGVhLCBiZWxvdyBhcmUgZm91ciBwcmV2aW91cyBh
dHRlbXB0cyBhdA0KdGhlIGFic3RyYWN0Lg0KPiA+ID4NCj4gPiA+IEZyb20gLXY1DQo+ID4gPg0K
PiA+ID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGhvdyB0byB0cmFuc3BvcnQgbmV0d29yayBz
dWJzY3JpcHRpb25zDQphbmQNCj4gPiA+ICAgIGV2ZW50IG1lc3NhZ2VzIG9uIHRvcCBvZiB0aGUg
TmV0d29yayBDb25maWd1cmF0aW9uIHByb3RvY29sDQo+ID4gPiAgICAoTkVUQ09ORikuICBUaGlz
IGluY2x1ZGVzIHRoZSBmdWxsIHNldCBvZiBSUENzLCBzdWJzY3JpcHRpb24NCnN0YXRlDQo+ID4g
PiAgICBjaGFuZ2VzLCBhbmQgc3Vic2NyaWJlZCBjb250ZW50IG5lZWRpbmcgYXN5bmNocm9ub3Vz
IGRlbGl2ZXJ5Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBGcm9tIC12Ng0KPiA+ID4NCj4gPiA+ICAg
IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBORVRDT05GIGJpbmRpbmcgZm9yDQo+ID4gPiAgICBb
SS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLiAgSW5jbHVk
ZWQNCmFyZToNCj4gPiA+DQo+ID4gPiAgICBvICBUcmFuc3BvcnQgbWFwcGluZ3MgZm9yIHN1YnNj
cmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFuZ2UNCj4gPiA+ICAgICAgIG5vdGlmaWNhdGlvbnMsIGFu
ZCBub3RpZmljYXRpb24gbWVzc2FnZXMNCj4gPiA+DQo+ID4gPiAgICBvICBGdW5jdGlvbmFsaXR5
IHdoaWNoIG11c3QgYmUgc3VwcG9ydGVkIHdpdGggTkVUQ09ORg0KPiA+ID4NCj4gPiA+ICAgIG8g
IEV4YW1wbGVzIGluIGFwcGVuZGljZXMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gRnJvbSAtdjcNCj4g
PiA+DQo+ID4gPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5nIGZv
cg0KPiA+ID4gICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRp
b25zXSBhbmQNCj4gPiA+ICAgIFtJLUQuaWV0Zi1uZXRjb25mLXlhbmctcHVzaF0uICBJbmNsdWRl
ZCBhcmU6DQo+ID4gPg0KPiA+ID4gICAgbyAgdHJhbnNwb3J0IG1hcHBpbmdzIGZvciBzdWJzY3Jp
cHRpb24gUlBDcywgc3RhdGUgY2hhbmdlDQo+ID4gPiAgICAgICBub3RpZmljYXRpb25zLCBhbmQg
bm90aWZpY2F0aW9uIG1lc3NhZ2VzLA0KPiA+ID4gICAgbyAgZnVuY3Rpb25hbCByZXF1aXJlbWVu
dHMsIGFuZA0KPiA+ID4gICAgbyAgZXhhbXBsZXMNCj4gPiA+DQo+ID4gPg0KPiA+ID4gRnJvbSAt
djgNCj4gPiA+DQo+ID4gPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgTkVUQ09ORiBiaW5k
aW5nIHRvIHN1YnNjcmliZWQNCj4gPiBub3RpZmljYXRpb25zDQo+ID4gPiAgICBhbmQgdG8gWUFO
RyBwdXNoLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBIb25lc3RseSBJIGxpa2UgdGhlIHY1IHZlcnNp
b24uICAgQnV0IHByZXZpb3VzIHJldmlld2VycyBoYXZlDQo+ID4gaW5jcmVtZW50YWxseSBkcml2
ZW4gdGhpbmdzIHRvIHRoZSBjdXJyZW50IHRleHQuICAgIElmIEtlbnQgeW91DQpwcmVmZXINCj4g
PiBzb21ldGhpbmcgb3RoZXIgdGhhbiB0aGUgY3VycmVudCB0ZXh0LCBsZXQgbWUga25vdyB3aGF0
IGl0IGlzLiAgSSBhbQ0Kc3VyZSBJIHdpbGwNCj4gPiBsaWtlIGl0IHRvby4NCj4gPiA+DQo+ID4g
PiBFcmljDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gVGhhbmtzIQ0KPiA+ID4gPiBEaHJ1dg0KPiA+
ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IEluIHRoZSBhYnN0cmFjdCBvZiB0aGlzIGRvY3VtZW50
LCB0aGF0IGRyYWZ0IGlzIG5vdCBleHBsaWNpdGx5DQo+ID4gbGlzdGVkDQo+ID4gPiA+ID4gYnkg
cmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rvb2Qgd2UgYXJlIG5vdCBzdXBwb3NlZCB0byB1c2UNCj4g
PiByZWZlcmVuY2VzIGluDQo+ID4gPiA+ID4gYWJzdHJhY3RzKS4gIEJ1dCBpdCBpcyBsaXN0ZWQg
aW4gdGhlIEludHJvZHVjdGlvbi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRvIG1ha2UgdGhpcyBj
bGVhcmVyIGZvciB5b3UgaW4gdGhpcyBkb2N1bWVudCwgcGVyaGFwcw0KInRyYW5zcG9ydA0KPiA+
IGJpbmRpbmciDQo+ID4gPiA+ID4gaW5zdGVhZCBvZiAiYmluZGluZyI/ICAgSSByZWFsbHkgZG9u
J3QgaGF2ZSBtYW55IGFsdGVybmF0aXZlcw0KSQ0KPiA+IGNhbiB0aGluaw0KPiA+ID4gPiA+IG9m
IHdoaWNoIGFsc28ga2VlcHMgdGhlIHRleHQgYnJpZWYuICAgVGhpcyBwYXJ0aWN1bGFyIHRleHQg
aGFzDQo+ID4gYmVlbg0KPiA+ID4gPiA+IGZyZXF1ZW50bHkgdHdlYWtlZCBpbiB0aGUgcGFzdC4N
Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoYW5rcy4NCj4gPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4N
Cj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhhbmtzIQ0KPiA+ID4gPiA+ID4gRGhydXY+DQo+ID4g
PiA+ID4gPiBPbiBXZWQsIE1heSA4LCAyMDE5IGF0IDk6MTQgUE0gRXJpYyBWb2l0IChldm9pdCkN
Cj4gPiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gVXBkYXRlIHBvc3RlZCBhcyAtdjIwLiAgIFdpdGggdGhlIGNvcnJlc3BvbmRpbmcgY2hhbmdl
IHRvDQo+ID4gZHJhZnQtaWV0Zi0NCj4gPiA+ID4gPiBuZXRjb25mLQ0KPiA+ID4gPiA+ID4gc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zIHBvc3RlZCBhcyAtdjI1Lg0KPiA+ID4gPiA+ID4gPg0KPiA+
ID4gPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gRnJvbTogRGhy
dXYgRGhvZHksIE1heSA4LCAyMDE5IDI6MjEgQU0NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiA+IEhpIEtlbnQsIEVyaWMsDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBG
aW5lIHdpdGggbWUhDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBUaGFua3MhDQo+
ID4gPiA+ID4gPiA+ID4gRGhydXYNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IE9u
IFdlZCwgTWF5IDgsIDIwMTkgYXQgMzoxOSBBTSBLZW50IFdhdHNlbg0KPiA+ID4gPiA+ID4gPiA+
IDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCj4gPiA+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+ID4g
PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g
PiA+ID4gPGVyaWM+IEJhc2VkIG9uIG15IHJlYWRpbmcgb2YgeW91ciBwcm9jZXNzIHN1Z2dlc3Rp
b25zDQo+ID4gS2VudCwgSQ0KPiA+ID4gPiA+ID4gPiA+ID4gbGlrZSBiZXN0IHRoZQ0KPiA+ID4g
PiA+ID4gPiA+IOKAnG1lbnRpb27igJ0gYXBwcm9hY2ggd2hpY2ggeW91IHVzZWQgZm9yIFJGQy04
MDcxLCBTZWN0aW9uDQoxLjQuDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4g
V2hhdCBJIHRoaW5rIGNvdWxkIGJlIGRvbmUgdG8gY292ZXIgdGhpcyBpczoNCj4gPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiAoQSkgIFJlbW92ZSBTZWN0aW9uIDExOiBOb3RlcyB0
byB0aGUgUkZDIEVkaXRvcg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IChC
KSAgUGVyIEtlbnTigJlzIGRlc2lyZSB0byBhbHNvIGNvdmVyDQo+ID4gPiA+ID4gPiA+ID4gPiBk
cmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIHBsYWNlIHRoZQ0KPiA+ID4gPiA+ID4g
PiA+IGZvbGxvd2luZyBzdGF0ZW1lbnQgaW50bw0KPiA+ID4gPiA+ID4gPiA+IGRyYWZ0LWlldGYt
bmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCj4gPiA+ID4gPiA+ID4gPiBkaXJlY3Rs
eSBhZnRlciBGaWd1cmUgMTANCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBb
UkZDLTUyNzddIFNlY3Rpb24gMi4yLjEgc3RhdGVzIHRoYXQgYSBub3RpZmljYXRpb24NCj4gPiBt
ZXNzYWdlIGlzDQo+ID4gPiA+ID4gPiA+ID4gPiB0byBiZSBzZW50IHRvIGENCj4gPiA+ID4gPiA+
ID4gPiBzdWJzY3JpYmVyIHdoaWNoIGluaXRpYXRlZCBhICJjcmVhdGUtc3Vic2NyaXB0aW9uIi4N
CldpdGgNCj4gPiB0aGlzDQo+ID4gPiA+ID4gc3BlY2lmaWNhdGlvbiwNCj4gPiA+ID4gPiA+IHRo
aXMNCj4gPiA+ID4gPiA+ID4gPiBSRkMtNTI3NyBzdGF0ZW1lbnQgc2hvdWxkIGJlIG1vcmUgYnJv
YWRseSBpbnRlcnByZXRlZCB0bw0KPiA+IG1lYW4NCj4gPiA+ID4gPiA+ID4gPiB0aGF0IG5vdGlm
aWNhdGlvbiBtZXNzYWdlcyBjYW4gYWxzbyBiZSBzZW50IHRvIGENCnN1YnNjcmliZXINCj4gPiA+
ID4gPiA+ID4gPiB3aGljaCBpbml0aWF0ZWQgYW4gImVzdGFibGlzaC1zdWJzY3JpcHRpb24iLCBv
ciBhDQpjb25maWd1cmVkDQo+ID4gPiA+ID4gPiA+ID4gcmVjZWl2ZXIgd2hpY2ggaGFzIGJlZW4g
c2VudCBhIOKAnHN1YnNjcmlwdGlvbi1zdGFydGVk4oCdLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4g
PiA+ID4gPiA+ID4gPiA+IERvZXMgdGhpcyB3b3JrIGZvciBib3RoIG9mIHlvdT8NCj4gPiA+ID4g
PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gV29ya3MgZm9y
IG1lLg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gVGhlIGlzc3VlIGlzbid0IGNvbnNpc3RlbmN5IHNvIG11
Y2ggYXMgbWVldGluZw0KPiA+IGV4cGVjdGF0aW9ucywNCj4gPiA+ID4gPiA+ID4gPiA+IHBlciBg
eG1sMnJmY2AsIHRoZQ0KPiA+ID4gPiA+ID4gPiA+IGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWV0
aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgaW4gdGhlDQo+ID4gPiA+ID4gPiA+ID4gUmVmZXJlbmNl
cyBzZWN0aW9uLCB3aGljaCB0aGVuIGF1dG8tZXhwYW5kcyB0byB0aGUNCmNvcnJlY3QNCj4gPiA+
ID4gPiA+ID4gPiByZWZlcmVuY2UgdGV4dCwgYXMgd2VsbCBhcyBkZWZpbmluZyB0aGUgYW5jaG9y
DQo+ID4gPiA+ID4gPiA+ID4gIkktRC5pZXRmLW5ldGNvbmYtDQo+ID4gPiA+ID4gc3Vic2NyaWJl
ZC1ub3RpZmljYXRpb25zIjoNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiAg
ICAgICAgIDw/cmZjDQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+IGluY2x1ZGU9InJlZmVyZW5jZS5J
LUQuaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyI/DQo+ID4gPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPEVyaWM+IFRoYXQg
ZGVmaW5pdGVseSBtYWtlcyB0aGluZ3MgZWFzaWVyIHRoYW4gd2hhdCBJDQo+ID4gaGF2ZQ0KPiA+
ID4gPiA+ID4gPiA+ID4gYmVlbiBkb2luZy4gIEkgYW0NCj4gPiA+ID4gPiA+ID4gPiBoaXR0aW5n
IGFuIHhtbDJyZmMgZXJyb3IgdHJ5aW5nIHRoaXMgcmlnaHQgbm93LCBidXQgSQ0Kd2lsbA0KPiA+
IGdldCB0aGVyZS4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gPiA+ID4gWWVzLCBpdCB3YXMgYW4gZXllLW9wZW5lciB3aGVuIEkgZmlndXJlZCBpdCBv
dXQuICAgQmUNCj4gPiBhd2FyZSB0aGF0LA0KPiA+ID4gPiA+IHRob3VnaA0KPiA+ID4gPiA+ID4g
c29tZQ0KPiA+ID4gPiA+ID4gPiA+IGV4dGVybmFsIHNvdXJjZXMgKGUuZy4sIElUVSBzdGFuZGFy
ZHMpIGFyZSBzdXBwb3J0ZWQsDQptYW55DQo+ID4gYXJlDQo+ID4gPiA+ID4gPiA+ID4gbm90LCBh
bmQgc28gaGFuZC0gY29kaW5nIHRoZSA8cmVmZXJlbmNlPiBpcyBzdGlsbA0Kc29tZXRpbWVzDQo+
ID4gPiA+ID4gcmVxdWlyZWQuLi4NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
Pg0KPiA+ID4gPiA+ID4gPiA+ID4gS2VudCAvLyBzaGVwaGVyZA0KPiA+ID4gPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4NCj4NCj4NCg0K


From nobody Tue May 21 05:44:55 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0782120041; Tue, 21 May 2019 05:44:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155844268576.2599.16416814520293764766@ietfa.amsl.com>
Date: Tue, 21 May 2019 05:44:45 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-event-notifications-22.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 12:44:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Dynamic subscription to YANG Events and Datastores over NETCONF
        Authors         : Eric Voit
                          Alexander Clemm
                          Alberto Gonzalez Prieto
                          Einar Nilsen-Nygaard
                          Ambika Prasad Tripathy
	Filename        : draft-ietf-netconf-netconf-event-notifications-22.txt
	Pages           : 20
	Date            : 2019-05-21

Abstract:
   This document provides a Network Configuration Protocol (NETCONF)
   binding to the dynamic subscription capability of both subscribed
   notifications and YANG-Push.

   RFC Editor note: please replace the references to pre-RFC normative
   drafts with the actual assigned RFC numbers.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-22
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-event-notifications-22

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


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 May 21 05:45:49 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1378B120186; Tue, 21 May 2019 05:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T3KvKuZA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SkQtTUWM
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW-OAiaJJZPk; Tue, 21 May 2019 05:45:36 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2ED12022D; Tue, 21 May 2019 05:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16972; q=dns/txt; s=iport; t=1558442735; x=1559652335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kmA6lPdkzOL8I2ixq8Tf7SEIeIpeyLw1/Hm3Tclk2AU=; b=T3KvKuZAIZ+WwH2+fWtAPEd84KeSKMSiysVprClEyNpMS+6RZkDxsDLJ hrrkOvdjKq7PAC7aqzyR+ClmpcbxZXidHROPSzIODSbae856/rlAymloz 7vEC5XBrovGfdnqdVy3yH6RgFwFAE/dk3iKyYC7jjcJ1p/ckdfkLlE9kq k=;
IronPort-PHdr: =?us-ascii?q?9a23=3A2EPX4h/WKw05+v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcObDkznBPXrdCc9Ws9FUQwt8g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAABR8uNc/4oNJK1lHgEGBwaBUgg?= =?us-ascii?q?LAYE9KScDgT4gBAsoCoQJg0cDjnSCV5cngS6BJANUCQEBAQwBAS0CAQGEQAI?= =?us-ascii?q?Xgg8jNQgOAQMBAQQBAQIBBG0cDIVKAQEBAwESEREMAQE1AgEEBwQCAQgVAQI?= =?us-ascii?q?CAgkaAwICAjAUARACBA4FCBqCNUuBawMODwECm0YCgTWIX3GBL4J5AQEFhQc?= =?us-ascii?q?Ygg8JgQwoi1EXgUA/gRFGgkw+hEYFM4JQMoImizUDgkKaLQkCgg2TG4Iehls?= =?us-ascii?q?FjS6DJYpXlCICBAIEBQIOAQEFgVABNoFXcBWDJ4IPg2+KU3KBKYtyAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.60,495,1549929600"; d="scan'208";a="562524823"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 May 2019 12:45:33 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4LCjVIG022579 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2019 12:45:31 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 07:45:30 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 07:45:30 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 21 May 2019 07:45:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kmA6lPdkzOL8I2ixq8Tf7SEIeIpeyLw1/Hm3Tclk2AU=; b=SkQtTUWMXlF9TLN670Whwmuurztc3vZPiEbnV7uI83BOTB/bEFOoSFJOUv/F1QoddKmNgIW+metjT0aJhvxXqfmxK3VT1hfJ6DxXmDlr1S2wProwRDhad7qKa+pRol07izQMJXNDJFS0o5WFoWzghgRyM+gRYa7ocfGas+md1W8=
Received: from DM6PR11MB4089.namprd11.prod.outlook.com (20.176.126.30) by DM6PR11MB3370.namprd11.prod.outlook.com (20.176.122.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Tue, 21 May 2019 12:45:28 +0000
Received: from DM6PR11MB4089.namprd11.prod.outlook.com ([fe80::d014:d7a3:270:e5a9]) by DM6PR11MB4089.namprd11.prod.outlook.com ([fe80::d014:d7a3:270:e5a9%3]) with mapi id 15.20.1900.020; Tue, 21 May 2019 12:45:28 +0000
From: "Eric Voit (evoit)" 
To: tom petch 
CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-21
Thread-Index: AQHVD7ogsfQqZfW6sEmyF+sbn2y9DaZ1hTEg
Date: Tue, 21 May 2019 12:45:28 +0000
Message-ID: 
References:  <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com>     <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net> <23a9e41d7bcb41d7a6b7a9eeb50aaa18@XCH-RTP-013.cisco.com> <057401d50fb9$855e16c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <057401d50fb9$855e16c0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; 
x-originating-ip: [173.38.117.77]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e72c7c20-a569-4674-1a9d-08d6ddea344f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR11MB3370; 
x-ms-traffictypediagnostic: DM6PR11MB3370:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(396003)(366004)(346002)(199004)(189003)(51444003)(13464003)(51914003)(14454004)(68736007)(6506007)(11346002)(33656002)(476003)(446003)(6436002)(486006)(55016002)(229853002)(9686003)(25786009)(6916009)(26005)(14444005)(186003)(478600001)(4326008)(256004)(73956011)(64756008)(66446008)(30864003)(305945005)(76116006)(66946007)(66476007)(66556008)(7736002)(53546011)(296002)(316002)(76176011)(7696005)(8936002)(8676002)(54906003)(52536014)(81166006)(81156014)(99286004)(5660300002)(66066001)(15650500001)(86362001)(2906002)(71190400001)(3846002)(53936002)(6246003)(102836004)(74316002)(6116002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3370; H:DM6PR11MB4089.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: zT+ubGoSwcmls8wwQ4+FwLYiyEBKvg3VYZrz4378HDFsKc75n9K92zwZ/DbOK//BGHN85oyufSZmnFXTLtW/HOzPG6xxNgM+2EakyJeAjlK6TVFFsnqzZMUFC5Zt13jNTxPY1HWYrRgug5bXHxcdO/nukZ6i6weacDokx68f/d5j7K6NEZzfkfqrNeLvnePlUnYNyzIUZrWTAfnqpnC0J3ubamycDGl7J5sT+BL7/jO8Y9WR+FYqTL0VKHBRsAwBijerjDJ29A5GiYms8sJxaHa/Y/pYcMVOYjKMukvSQX8injHTL8p/Si3AvHA6yGi1PzlLz4qtTF1NFWKHlgHAe0RLCW/f0c/AbuoW+bvgblnkql5CSQ0u09Kp6wZOk9BoW+//NcRS0RRW2n+cmhL1L7vWz4/t2pyc3B7nVVYWuek=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e72c7c20-a569-4674-1a9d-08d6ddea344f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 12:45:28.8159 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3370
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: 
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-21
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 12:45:47 -0000

SSBtYWRlIGl0ICdpcycuICAgSSBwb3N0ZWQgdGhlIHZlcnNpb24gYXMgd2VsbC4NCg0KRXJpYw0K
DQo+IEVyaWMNCj4gDQo+IExvb2tzIGdvb2QgYnV0IEkgZG8gYWdyZWUgd2l0aCBCZW5qYW1pbiBh
Ym91dCB0aGUgZ3JhbW1hciBvZg0KPiANCj4gIkFuZCBwZXIgW1JGQzUyNzddJ3MgImV2ZW50VGlt
ZSIgb2JqZWN0IGRlZmluaXRpb24sIHRoZQ0KPiAgICAiZXZlbnRUaW1lIiBwb3B1bGF0ZWQgd2l0
aCB0aGUgZXZlbnQgb2NjdXJyZW5jZSB0aW1lLiINCj4gDQo+IEkgY2Fubm90IG1ha2UgdGhhdCBp
bnRvIGEgc2VudGVuY2UuICdwb3B1bGF0ZWQnIHNlZW1zIHRvIGJlIGEgcGFzdCBwYXJ0aWNpcGxl
DQo+IG1ha2luZyAnIHBvcHVsYXRlZCB3aXRoIHRoZSBldmVudCBvY2N1cnJlbmNlIHRpbWUnIGlu
dG8gYW4gYWRqZWN0aXZhbCBjbGF1c2UgYW5kDQo+IHRoZSB3aG9sZSBsYWNraW5nIGEgbWFpbiB2
ZXJiOyBJTUhPIGl0IG5lZWRzIGEgdmVyYiBiZWZvcmUgJ3BvcHVsYXRlZCcgc3VjaCBhcw0KPiAn
aXMnLCAnd2lsbCBiZScsICdNQVkgYmUnLCAgJyBNVVNUIGJlJw0KPiBldGMuICBJIGF3YWl0IHdp
dGggaW50ZXJlc3QgdGhlIHZpZXdzIG9mIHRoZSBSRkMgRWRpdG9yIHdob3NlIHdvcmQgb24gdGhl
c2UNCj4gbWF0dGVycyBJIHRyZWF0IGFzIGdvc3BlbC4NCj4gDQo+IFRvbSBQZXRjaA0KPiANCj4g
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiRXJpYyBWb2l0IChldm9pdCki
IDxldm9pdEBjaXNjby5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAxNCwgMjAxOSAzOjU5IFBN
DQo+IA0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+ID4gRnJvbTogdG9tIHBldGNoLCBNYXkgMTQsIDIw
MTkgNzo0OCBBTQ0KPiA+ID4NCj4gPiA+IEVyaWMNCj4gPiA+DQo+ID4gPiBBIHF1aWNrIGJyb3dz
ZSB0ZWxscyBtZSB0aGF0IGluIHRoZSBSRkMgSSByZWd1bGFybHkgcmVmZXIgdG8sDQo+ICdiaW5k
aW5nJw0KPiA+ID4gaXMgdXNlZCBpbiBvdmVyIDMwMCBvZiB0aGVtIGJ1dCB0aGF0IGluIGFsbCB0
aG9zZSB0aGF0IEkgbG9va2VkIGF0LA0KPiBpdCBpcyBhbHdheXMNCj4gPiA+IGJpbmRpbmcgYW4g
ZWxlbWVudCBvZiBhIHNldCB0byBhbiBlbGVtZW50IG9mIHRoZSBzYW1lIG9yIGEgZGlmZmVyZW50
DQo+IHNldCwgd2hlcmUNCj4gPiA+IHRoZSBzZXRzIGFyZSBzaW1pbGFyIGluIG5hdHVyZS4gIFRo
dXMgQVJQIGJpbmRzIGFuIElQIGFkZHJlc3MgdG8gYQ0KPiBNQUMgYWRkcmVzcyBvcg0KPiA+ID4g
YSBiaWRpcmVjdGlvbmFsIE1QTFMgTFNQIGJpbmRzIG9uZSB1bmlkaXJlY3Rpb25hbCBMU1AgdG8g
YW5vdGhlciBhbmQNCj4gc28gb25lLg0KPiA+ID4NCj4gPiA+IFdoYXQgSSBkbyBub3QgbGVhcm4g
aGVyZSBpcyB3aGF0IGlzIGJlaW5nIGJvdW5kIHRvIHdoYXQuDQo+ID4gPg0KPiA+ID4gUGVyaGFw
cw0KPiA+ID4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGJpbmRpbmcgb2YgYSBzdHJl
YW0gb2YgZXZlbnRzIHdoaWNoDQo+IGZvcm0gcGFydCBvZiBhDQo+ID4gPiBkeW5hbWljIHN1YnNj
cmlwdGlvbiB0byB0aGUgTkVUQ09ORg0KPiA+ID4gICAgcHJvdG9jb2wgW1JGQzYyNDFdLiAgRHlu
YW1pYyBzdWJzY3JpcHRpb25zIGFyZSBkZWZpbmVkIGluDQo+ID4gPiAgICBbSS1ELmRyYWZ0LWll
dGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLg0KPiA+DQo+ID4gSSBhbSBhc3N1
bWluZyB0aGF0IHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUN
Cj4gSW50cm8gaGVyZSwgYXMgZG9jdW1lbnQgcmVmZXJlbmNlcyBhcmUgbm90IGluIGFic3RyYWN0
cy4NCj4gPg0KPiA+IFRoaXMgdGV4dCB3b3JrcyBmb3IgbWUuICAgQW55IG9iamVjdGlvbnMgYW55
b25lPw0KPiA+DQo+ID4gPiBUaGUgY3J1eCBpcyAiYmluZGluZyAuLi4gdG8gLi4uIiB3aGljaCBp
cyBjdXJyZW50bHkgbGFja2luZy4NCj4gPiA+DQo+ID4gPiBNb3JlIGdlbmVyYWxseTotKA0KPiA+
ID4gSSBkbyBmaW5kIHRoaXMgSS1EIGhhcmQgdG8gdW5kZXJzdGFuZC4gIEkgdGhpbmsgdGhhdCB0
aGUga2V5IGlzIHRoYXQNCj4gdGhpcyBJLUQsIG1vcmUNCj4gPiA+IHRoYW4gYW55IG90aGVyIEkg
Y2FuIHRoaW5rIG9mLCBpcyBzbyBkZXBlbmRlbnQgb24gb25lIG9mIGl0cw0KPiBOb3JtYXRpdmUN
Cj4gPiA+IFJlZmVyZW5jZXMsIHRvIHdoaXQsIHN1YnNjcmliZWQgbm90aWZpY2F0aW9uczsgSSB0
aGluayB0aGF0IHRoYXQNCj4gbmVlZHMgY2FsbGluZyBvdXQNCj4gPiA+IHNvIEkgd291bGQgYWRk
ICJUaGlzIG1lbW8gYXNzdW1lcyB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aA0KPiB0
aGUNCj4gPiA+IHRlcm1pbm9sb2d5IGFuZCBjb25jZXB0cyBkZWZpbmVkIGluIFtzdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnNdIg0KPiA+DQo+ID4gQXMgdGhlIGxhc3Qgc2VudGVuY2UgaW4gdGhlIElu
dHJvIHNlY3Rpb24sIEkgaGF2ZSBhZGRlZDoNCj4gPiAiVGhpcyBkb2N1bWVudCBhc3N1bWVzIHRo
YXQgdGhlIHJlYWRlciBpcyBmYW1pbGlhciB3aXRoIHRoZQ0KPiB0ZXJtaW5vbG9neSBhbmQgY29u
Y2VwdHMgZGVmaW5lZCBpbg0KPiBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v
dGlmaWNhdGlvbnNdLiINCj4gPg0KPiA+ID4gWWVzLCB0aGF0IGlzIHdoYXQgYSBOb3JtYXRpdmUg
UmVmZXJlbmNlIG1lYW5zIGJ1dCBJIGZpbmQgdGhpcw0KPiBleGFtcGxlIHNvDQo+ID4gPiBleHRy
ZW1lIHRoYXQgSSB0aGluayBpdCBuZWVkcyBjYWxsaW5nIG91dC4gIEVhY2ggdGltZSBpbiB0aGUg
cGFzdA0KPiBzaXggbW9udGhzIEkgaGF2ZQ0KPiA+ID4gdHVybmVkIHRvIHRoaXMgSS1EIChpdCBp
cyB0aGUgc21hbGxlc3Qgb2YgdGhlIHZlcnkgbGFyZ2Ugc2V0IG9mDQo+IG5ldGNvbmYgSS1Eczot
KSwgSSBoYXZlDQo+ID4gPiBnaXZlbiB1cCwgZXZlbnR1YWxseSB3b3JraW5nIG91dCB0aGF0IGZp
cnN0IEkgbXVzdCBtYXN0ZXIgdGhlIDgwDQo+IHBhZ2VzIG9mDQo+ID4gPiBzdWJzY3JpYmVkIG5v
dGlmaWNhdGlvbnMuICBUaGlzIG1heSBub3QgYmUgc28gb2J2aW91cyB0byB0aG9zZQ0KPiBpbnZv
bHZlZCBhdCBMYXN0DQo+ID4gPiBDYWxsIHRpbWUuDQo+ID4NCj4gPiBVbmRlcnN0b29kLiAgQW5k
IGl0IGlzIHRydWUgdGhhdCB1bmRlcnN0YW5kaW5nDQo+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9u
cyBpcyBhIHByZXJlcXVpc2l0ZS4NCj4gPg0KPiA+IEVyaWMNCj4gPg0KPiA+ID4gVG9tIFBldGNo
DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+
IEZyb206ICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4NCj4gPiA+IFNlbnQ6
IEZyaWRheSwgTWF5IDEwLCAyMDE5IDc6MzkgUE0NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBIaSBE
aHJ1diwNCj4gPiA+ID4gSGkgS2VudCwNCj4gPiA+ID4NCj4gPiA+ID4gPiBGcm9tOiBEaHJ1diBE
aG9keSwgTWF5IDksIDIwMTkgMTE6MjggUE0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpIEVyaWMs
DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
PiA+ID4gPiBGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0N
Cj4gPiA+ID4gPiA+IFNlbnQ6IDEwIE1heSAyMDE5IDAyOjE4DQo+ID4gPiA+ID4gPiBIaSBEaHJ1
diwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEZyb206IERocnV2IERob2R5LCBNYXkgOSwg
MjAxOSAxMjowMyBBTQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBIaSBFcmljLA0KPiA+
ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBUaGFua3MgZm9yIHRoZSB1cGRhdGUuIEkgc2VlIG9u
ZSBtaW5vciBjb21tZW50IHRoYXQgaXMgbm90DQo+ID4gPiBoYW5kbGVkLg0KPiA+ID4gPiA+ID4g
PiBNYXliZSB5b3UgbWlzc2VkIGl0PyBPciB5b3UgZGlzYWdyZWUsIHRoYXQgc29tZSBtb3JlIHRl
eHQgaXMNCj4gPiA+IHJlcXVpcmVkPw0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IE1p
bm9yIElzc3VlczoNCj4gPiA+ID4gPiA+ID4gPiAtLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiA+
ID4gKDEpIEFic3RyYWN0ICYgSW50cm9kdWN0aW9uLCBJdCBpcyBub3QgY2xlYXIgd2hhdCBkb2Vz
IHRoZQ0KPiA+ID4gJ2JpbmRpbmcnDQo+ID4gPiA+ID4gPiA+ID4gbWVhbiBhbmQgd2hvIGFyZSB0
aGUgcGFydGllcyB0byB0aGlzIGJpbmRpbmc/IElmIHRoaXMgaXMNCj4gdGhlDQo+ID4gPiA+ID4g
PiA+ID4gZG9jdW1lbnQgdGhhdA0KPiA+ID4gPiA+ID4gPiBtZW50aW9ucyAnYmluZGluZycNCj4g
PiA+ID4gPiA+ID4gPiBmaXJzdCwgc28gcGxlYXNlIGFkZCBzb21lIG1vcmUgY2xhcmlmeWluZyB0
ZXh0Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoaXMgaXMgbm90IHRoZSBmaXJzdCBkb2N1
bWVudCB3aGljaCBtZW50aW9ucyAnYmluZGluZycNCj4gZmlyc3QuDQo+ID4gPiBUaGUNCj4gPiA+
ID4gPiA+IGRvY3VtZW50IHdoaWNoIGRvZXMgdGhpcyBmaXJzdCBpcw0KPiBkcmFmdC1pZXRmLW5l
dGNvbmYtc3Vic2NyaWJlZC0NCj4gPiA+ID4gPiA+IG5vdGlmaWNhdGlvbnMuDQo+ID4gPiA+ID4g
W1tEaHJ1diBEaG9keV1dIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlv
bnMgc2F5cw0KPiA+ID4gdGhpcyBpbiB0aGUNCj4gPiA+ID4gPiBJbnRyb2R1Y3Rpb24gLQ0KPiA+
ID4gPiA+DQo+ID4gPiA+ID4gICAgV2hpbGUgdGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZCBpbiB0
aGlzIGRvY3VtZW50IGlzDQo+IHRyYW5zcG9ydC0NCj4gPiA+ID4gPiAgICBhZ25vc3RpYywgdHJh
bnNwb3J0cyBsaWtlIE5FVENPTkYgW1JGQzYyNDFdIG9yIFJFU1RDT05GDQo+IFtSRkM4MDQwXQ0K
PiA+ID4gY2FuDQo+ID4gPiA+ID4gICAgYmUgdXNlZCB0byBjb25maWd1cmUgb3IgZHluYW1pY2Fs
bHkgc2lnbmFsIHN1YnNjcmlwdGlvbnMsIGFuZA0KPiA+ID4gdGhlcmUNCj4gPiA+ID4gPiAgICBh
cmUgYmluZGluZ3MgZGVmaW5lZCBmb3Igc3Vic2NyaWJlZCBldmVudCByZWNvcmQgZGVsaXZlcnkg
Zm9yDQo+ID4gPiBORVRDT05GDQo+ID4gPiA+ID4gICAgd2l0aGluIFtJLUQuZHJhZnQtaWV0Zi1u
ZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9uc10sDQo+IGFuZA0KPiA+ID4gZm9yDQo+
ID4gPiA+ID4gICAgUkVTVENPTkYgd2l0aGluIFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rj
b25mLW5vdGlmXS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgdGhpbmsgdGhpcyBpcyBvbmx5IHRp
bWUgYmluZGluZyBpcyB1c2VkIGluIHRoaXMgY29udGV4dC4NCj4gPiA+ID4gPiBBbmQgbm93IHRo
aXMgSS1EIHNheXMgLQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAgVGhpcyBkb2N1bWVudCBwcm92
aWRlcyBhIGJpbmRpbmcgZm9yIGV2ZW50cyBzdHJlYW1lZCBvdmVyIHRoZQ0KPiA+ID4gTkVUQ09O
Rg0KPiA+ID4gPiA+ICAgIHByb3RvY29sIFtSRkM2MjQxXSBmb3IgZHluYW1pYyBzdWJzY3JpcHRp
b25zIGFzIGRlZmluZWQgaW4NCj4gPiA+ID4gPiAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1z
dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQW5kIHlvdSBk
b27igJl0IHVzZSB0aGlzIHRlcm0gZXZlciBhZ2Fpbi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRv
IG1lIHRoaXMgaXMgYml0IGNpcmN1bGFyIGFuZCB0aGUgdGVybSBiaW5kaW5nIGlzIHVzZWQgbG9v
c2VseS4NCj4gQW5kDQo+ID4gPiB0aHVzIEkgZmxhZ2dlZA0KPiA+ID4gPiA+IGl0LiBJIHdpbGwg
bGV0IHlvdSBhbmQgS2VudCBkZWNpZGUgdGhlIHJpZ2h0IGFwcHJvYWNoLg0KPiA+ID4gPg0KPiA+
ID4gPiBJIHJlYWxseSBhbSBvayB3aXRoIG1hbnkgb3B0aW9ucyBoZXJlOg0KPiA+ID4gPiAgKGEp
ICBrZWVwIHRoZSBjdXJyZW50IHRleHQuDQo+ID4gPiA+ICAoYikgIHVzZSBwcmV2aW91cyB2ZXJz
aW9ucyBvZiB0aGUgYWJzdHJhY3QuDQo+ID4gPiA+ICAoYykgIHJlcGxhY2UgdGhlIHdvcmQgYmlu
ZGluZyB3aXRoIHNvbWUgb3RoZXIgdGV4dC4NCj4gPiA+ID4NCj4gPiA+ID4gR2V0dGluZyB0aGUg
cmlnaHQgd29yZHMgaGVyZSBuYWlsZWQgZG93biBoYXNuJ3QgYmVlbiBmcm9tIGxhY2sgb2YNCj4g
PiA+IGVmZm9ydC4gIFRvIGdpdmUgeW91IGFuIGlkZWEsIGJlbG93IGFyZSBmb3VyIHByZXZpb3Vz
IGF0dGVtcHRzIGF0DQo+IHRoZSBhYnN0cmFjdC4NCj4gPiA+ID4NCj4gPiA+ID4gRnJvbSAtdjUN
Cj4gPiA+ID4NCj4gPiA+ID4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGhvdyB0byB0cmFuc3Bv
cnQgbmV0d29yayBzdWJzY3JpcHRpb25zDQo+IGFuZA0KPiA+ID4gPiAgICBldmVudCBtZXNzYWdl
cyBvbiB0b3Agb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBwcm90b2NvbA0KPiA+ID4gPiAg
ICAoTkVUQ09ORikuICBUaGlzIGluY2x1ZGVzIHRoZSBmdWxsIHNldCBvZiBSUENzLCBzdWJzY3Jp
cHRpb24NCj4gc3RhdGUNCj4gPiA+ID4gICAgY2hhbmdlcywgYW5kIHN1YnNjcmliZWQgY29udGVu
dCBuZWVkaW5nIGFzeW5jaHJvbm91cyBkZWxpdmVyeS4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+
ID4gRnJvbSAtdjYNCj4gPiA+ID4NCj4gPiA+ID4gICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBh
IE5FVENPTkYgYmluZGluZyBmb3INCj4gPiA+ID4gICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYt
c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXS4gIEluY2x1ZGVkDQo+IGFyZToNCj4gPiA+ID4NCj4g
PiA+ID4gICAgbyAgVHJhbnNwb3J0IG1hcHBpbmdzIGZvciBzdWJzY3JpcHRpb24gUlBDcywgc3Rh
dGUgY2hhbmdlDQo+ID4gPiA+ICAgICAgIG5vdGlmaWNhdGlvbnMsIGFuZCBub3RpZmljYXRpb24g
bWVzc2FnZXMNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgRnVuY3Rpb25hbGl0eSB3aGljaCBtdXN0
IGJlIHN1cHBvcnRlZCB3aXRoIE5FVENPTkYNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgRXhhbXBs
ZXMgaW4gYXBwZW5kaWNlcw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBGcm9tIC12Nw0KPiA+
ID4gPg0KPiA+ID4gPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5n
IGZvcg0KPiA+ID4gPiAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm
aWNhdGlvbnNdIGFuZA0KPiA+ID4gPiAgICBbSS1ELmlldGYtbmV0Y29uZi15YW5nLXB1c2hdLiAg
SW5jbHVkZWQgYXJlOg0KPiA+ID4gPg0KPiA+ID4gPiAgICBvICB0cmFuc3BvcnQgbWFwcGluZ3Mg
Zm9yIHN1YnNjcmlwdGlvbiBSUENzLCBzdGF0ZSBjaGFuZ2UNCj4gPiA+ID4gICAgICAgbm90aWZp
Y2F0aW9ucywgYW5kIG5vdGlmaWNhdGlvbiBtZXNzYWdlcywNCj4gPiA+ID4gICAgbyAgZnVuY3Rp
b25hbCByZXF1aXJlbWVudHMsIGFuZA0KPiA+ID4gPiAgICBvICBleGFtcGxlcw0KPiA+ID4gPg0K
PiA+ID4gPg0KPiA+ID4gPiBGcm9tIC12OA0KPiA+ID4gPg0KPiA+ID4gPiAgICBUaGlzIGRvY3Vt
ZW50IHByb3ZpZGVzIGEgTkVUQ09ORiBiaW5kaW5nIHRvIHN1YnNjcmliZWQNCj4gPiA+IG5vdGlm
aWNhdGlvbnMNCj4gPiA+ID4gICAgYW5kIHRvIFlBTkcgcHVzaC4NCj4gPiA+ID4NCj4gPiA+ID4N
Cj4gPiA+ID4gSG9uZXN0bHkgSSBsaWtlIHRoZSB2NSB2ZXJzaW9uLiAgIEJ1dCBwcmV2aW91cyBy
ZXZpZXdlcnMgaGF2ZQ0KPiA+ID4gaW5jcmVtZW50YWxseSBkcml2ZW4gdGhpbmdzIHRvIHRoZSBj
dXJyZW50IHRleHQuICAgIElmIEtlbnQgeW91DQo+IHByZWZlcg0KPiA+ID4gc29tZXRoaW5nIG90
aGVyIHRoYW4gdGhlIGN1cnJlbnQgdGV4dCwgbGV0IG1lIGtub3cgd2hhdCBpdCBpcy4gIEkgYW0N
Cj4gc3VyZSBJIHdpbGwNCj4gPiA+IGxpa2UgaXQgdG9vLg0KPiA+ID4gPg0KPiA+ID4gPiBFcmlj
DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzIQ0KPiA+ID4gPiA+IERocnV2DQo+
ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSW4gdGhlIGFic3RyYWN0IG9mIHRoaXMg
ZG9jdW1lbnQsIHRoYXQgZHJhZnQgaXMgbm90IGV4cGxpY2l0bHkNCj4gPiA+IGxpc3RlZA0KPiA+
ID4gPiA+ID4gYnkgcmVmZXJlbmNlIChhcyBJIHVuZGVyc3Rvb2Qgd2UgYXJlIG5vdCBzdXBwb3Nl
ZCB0byB1c2UNCj4gPiA+IHJlZmVyZW5jZXMgaW4NCj4gPiA+ID4gPiA+IGFic3RyYWN0cykuICBC
dXQgaXQgaXMgbGlzdGVkIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQo+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gVG8gbWFrZSB0aGlzIGNsZWFyZXIgZm9yIHlvdSBpbiB0aGlzIGRvY3VtZW50LCBwZXJo
YXBzDQo+ICJ0cmFuc3BvcnQNCj4gPiA+IGJpbmRpbmciDQo+ID4gPiA+ID4gPiBpbnN0ZWFkIG9m
ICJiaW5kaW5nIj8gICBJIHJlYWxseSBkb24ndCBoYXZlIG1hbnkgYWx0ZXJuYXRpdmVzDQo+IEkN
Cj4gPiA+IGNhbiB0aGluaw0KPiA+ID4gPiA+ID4gb2Ygd2hpY2ggYWxzbyBrZWVwcyB0aGUgdGV4
dCBicmllZi4gICBUaGlzIHBhcnRpY3VsYXIgdGV4dCBoYXMNCj4gPiA+IGJlZW4NCj4gPiA+ID4g
PiA+IGZyZXF1ZW50bHkgdHdlYWtlZCBpbiB0aGUgcGFzdC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+
ID4gPiBUaGFua3MuDQo+ID4gPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+ID4gVGhhbmtzIQ0KPiA+ID4gPiA+ID4gPiBEaHJ1dj4NCj4gPiA+ID4gPiA+
ID4gT24gV2VkLCBNYXkgOCwgMjAxOSBhdCA5OjE0IFBNIEVyaWMgVm9pdCAoZXZvaXQpDQo+ID4g
PiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g
PiA+IFVwZGF0ZSBwb3N0ZWQgYXMgLXYyMC4gICBXaXRoIHRoZSBjb3JyZXNwb25kaW5nIGNoYW5n
ZSB0bw0KPiA+ID4gZHJhZnQtaWV0Zi0NCj4gPiA+ID4gPiA+IG5ldGNvbmYtDQo+ID4gPiA+ID4g
PiA+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBwb3N0ZWQgYXMgLXYyNS4NCj4gPiA+ID4gPiA+
ID4gPg0KPiA+ID4gPiA+ID4gPiA+IEVyaWMNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g
PiA+ID4gRnJvbTogRGhydXYgRGhvZHksIE1heSA4LCAyMDE5IDI6MjEgQU0NCj4gPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiBIaSBLZW50LCBFcmljLA0KPiA+ID4gPiA+ID4gPiA+
ID4NCj4gPiA+ID4gPiA+ID4gPiA+IEZpbmUgd2l0aCBtZSENCj4gPiA+ID4gPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiA+ID4gPiBUaGFua3MhDQo+ID4gPiA+ID4gPiA+ID4gPiBEaHJ1dg0KPiA+ID4g
PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+IE9uIFdlZCwgTWF5IDgsIDIwMTkgYXQgMzox
OSBBTSBLZW50IFdhdHNlbg0KPiA+ID4gPiA+ID4gPiA+ID4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0
Pg0KPiA+ID4gPiA+ID4gPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPGVyaWM+
IEJhc2VkIG9uIG15IHJlYWRpbmcgb2YgeW91ciBwcm9jZXNzIHN1Z2dlc3Rpb25zDQo+ID4gPiBL
ZW50LCBJDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGxpa2UgYmVzdCB0aGUNCj4gPiA+ID4gPiA+ID4g
PiA+IOKAnG1lbnRpb27igJ0gYXBwcm9hY2ggd2hpY2ggeW91IHVzZWQgZm9yIFJGQy04MDcxLCBT
ZWN0aW9uDQo+IDEuNC4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
V2hhdCBJIHRoaW5rIGNvdWxkIGJlIGRvbmUgdG8gY292ZXIgdGhpcyBpczoNCj4gPiA+ID4gPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gKEEpICBSZW1vdmUgU2VjdGlvbiAxMTogTm90
ZXMgdG8gdGhlIFJGQyBFZGl0b3INCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g
PiA+ID4gKEIpICBQZXIgS2VudOKAmXMgZGVzaXJlIHRvIGFsc28gY292ZXINCj4gPiA+ID4gPiA+
ID4gPiA+ID4gZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLCBwbGFjZSB0aGUNCj4g
PiA+ID4gPiA+ID4gPiA+IGZvbGxvd2luZyBzdGF0ZW1lbnQgaW50bw0KPiA+ID4gPiA+ID4gPiA+
ID4gZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPiA+ID4gPiA+
ID4gPiA+ID4gZGlyZWN0bHkgYWZ0ZXIgRmlndXJlIDEwDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiA+ID4gPiA+IFtSRkMtNTI3N10gU2VjdGlvbiAyLjIuMSBzdGF0ZXMgdGhhdCBh
IG5vdGlmaWNhdGlvbg0KPiA+ID4gbWVzc2FnZSBpcw0KPiA+ID4gPiA+ID4gPiA+ID4gPiB0byBi
ZSBzZW50IHRvIGENCj4gPiA+ID4gPiA+ID4gPiA+IHN1YnNjcmliZXIgd2hpY2ggaW5pdGlhdGVk
IGEgImNyZWF0ZS1zdWJzY3JpcHRpb24iLg0KPiBXaXRoDQo+ID4gPiB0aGlzDQo+ID4gPiA+ID4g
PiBzcGVjaWZpY2F0aW9uLA0KPiA+ID4gPiA+ID4gPiB0aGlzDQo+ID4gPiA+ID4gPiA+ID4gPiBS
RkMtNTI3NyBzdGF0ZW1lbnQgc2hvdWxkIGJlIG1vcmUgYnJvYWRseSBpbnRlcnByZXRlZCB0bw0K
PiA+ID4gbWVhbg0KPiA+ID4gPiA+ID4gPiA+ID4gdGhhdCBub3RpZmljYXRpb24gbWVzc2FnZXMg
Y2FuIGFsc28gYmUgc2VudCB0byBhDQo+IHN1YnNjcmliZXINCj4gPiA+ID4gPiA+ID4gPiA+IHdo
aWNoIGluaXRpYXRlZCBhbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIsIG9yIGENCj4gY29uZmln
dXJlZA0KPiA+ID4gPiA+ID4gPiA+ID4gcmVjZWl2ZXIgd2hpY2ggaGFzIGJlZW4gc2VudCBhIOKA
nHN1YnNjcmlwdGlvbi1zdGFydGVk4oCdLg0KPiA+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiA+ID4gPiBEb2VzIHRoaXMgd29yayBmb3IgYm90aCBvZiB5b3U/DQo+ID4gPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IFdvcmtzIGZv
ciBtZS4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g
PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gVGhlIGlzc3VlIGlzbid0IGNvbnNpc3Rl
bmN5IHNvIG11Y2ggYXMgbWVldGluZw0KPiA+ID4gZXhwZWN0YXRpb25zLA0KPiA+ID4gPiA+ID4g
PiA+ID4gPiBwZXIgYHhtbDJyZmNgLCB0aGUNCj4gPiA+ID4gPiA+ID4gPiA+IGRvY3VtZW50IHNo
b3VsZCBoYXZlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgaW4gdGhlDQo+ID4gPiA+ID4g
PiA+ID4gPiBSZWZlcmVuY2VzIHNlY3Rpb24sIHdoaWNoIHRoZW4gYXV0by1leHBhbmRzIHRvIHRo
ZQ0KPiBjb3JyZWN0DQo+ID4gPiA+ID4gPiA+ID4gPiByZWZlcmVuY2UgdGV4dCwgYXMgd2VsbCBh
cyBkZWZpbmluZyB0aGUgYW5jaG9yDQo+ID4gPiA+ID4gPiA+ID4gPiAiSS1ELmlldGYtbmV0Y29u
Zi0NCj4gPiA+ID4gPiA+IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyI6DQo+ID4gPiA+ID4gPiA+
ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgPD9yZmMNCj4gPiA+ID4gPiA+ID4g
PiA+ID4NCj4gPiA+IGluY2x1ZGU9InJlZmVyZW5jZS5JLUQuaWV0Zi1uZXRjb25mLXN1YnNjcmli
ZWQtbm90aWZpY2F0aW9ucyI/DQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g
PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gPEVyaWM+IFRoYXQgZGVmaW5pdGVseSBtYWtlcyB0
aGluZ3MgZWFzaWVyIHRoYW4gd2hhdCBJDQo+ID4gPiBoYXZlDQo+ID4gPiA+ID4gPiA+ID4gPiA+
IGJlZW4gZG9pbmcuICBJIGFtDQo+ID4gPiA+ID4gPiA+ID4gPiBoaXR0aW5nIGFuIHhtbDJyZmMg
ZXJyb3IgdHJ5aW5nIHRoaXMgcmlnaHQgbm93LCBidXQgSQ0KPiB3aWxsDQo+ID4gPiBnZXQgdGhl
cmUuDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g
PiA+ID4gPiA+IFllcywgaXQgd2FzIGFuIGV5ZS1vcGVuZXIgd2hlbiBJIGZpZ3VyZWQgaXQgb3V0
LiAgIEJlDQo+ID4gPiBhd2FyZSB0aGF0LA0KPiA+ID4gPiA+ID4gdGhvdWdoDQo+ID4gPiA+ID4g
PiA+IHNvbWUNCj4gPiA+ID4gPiA+ID4gPiA+IGV4dGVybmFsIHNvdXJjZXMgKGUuZy4sIElUVSBz
dGFuZGFyZHMpIGFyZSBzdXBwb3J0ZWQsDQo+IG1hbnkNCj4gPiA+IGFyZQ0KPiA+ID4gPiA+ID4g
PiA+ID4gbm90LCBhbmQgc28gaGFuZC0gY29kaW5nIHRoZSA8cmVmZXJlbmNlPiBpcyBzdGlsbA0K
PiBzb21ldGltZXMNCj4gPiA+ID4gPiA+IHJlcXVpcmVkLi4uDQo+ID4gPiA+ID4gPiA+ID4gPiA+
DQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IEtlbnQgLy8gc2hlcGhl
cmQNCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gPiA+ID4NCj4gPiA+ID4NCj4gPg0KPiA+DQoNCg==


From nobody Tue May 21 07:38:28 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F880120153; Tue, 21 May 2019 07:38:13 -0700 (PDT)
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.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ibagdona@gmail.com, draft-ietf-netconf-subscribed-notifications@ietf.org,  netconf-chairs@ietf.org, The IESG , netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen , rfc-editor@rfc-editor.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <155844949331.2360.5731244607608302167.idtracker@ietfa.amsl.com>
Date: Tue, 21 May 2019 07:38:13 -0700
Archived-At: 
Subject: [netconf] Protocol Action: 'Subscription to YANG Event Notifications' to Proposed Standard (draft-ietf-netconf-subscribed-notifications-26.txt)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 14:38:14 -0000

The IESG has approved the following document:
- 'Subscription to YANG Event Notifications'
  (draft-ietf-netconf-subscribed-notifications-26.txt) as Proposed Standard

This document is the product of the Network Configuration Working Group.

The IESG contact persons are Warren Kumari and Ignas Bagdonas.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/




Technical Summary

This document defines a mechanism for allowing interested subscribers to subscribe and receive a stream of events being sent by a publisher. A corresponding YANG data model for controlling of this functionality is also defined. Subscribe notifications form a more generic event distribution mechanism than previously defined in RFC5277.  


Working Group Summary

WG reached consensus on the document without singling out any specific topics that were significantly controversial. The industry interest appears to be in dynamic subscriptions, and therefore configured subscriptions have been more questioned whether they should be supported too. Shepherd writeup contains more details on the decisions and results. 


Document Quality

There is a general interest from vendor community to implement at least parts of the functionality specified (dynamic subscriptions appear to be more demanded by the industry). The document has gone through several directorate reviews 


Personnel

The Document Shepherd is Kent Watsen.  The Responsible Area Director is Ignas Bagdonas. 


IANA Note

This document adds new entries to existing IETF XML and YANG Module Names registries.


From nobody Tue May 21 09:04:04 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E751F120041; Tue, 21 May 2019 09:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jheUnvbO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IDPV9SlV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36BsJIOcg-F6; Tue, 21 May 2019 09:03:59 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B31912016E; Tue, 21 May 2019 09:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4056; q=dns/txt; s=iport; t=1558454628; x=1559664228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=blRjYlicwelG+Q9EYDPjPM1JfhP0g1K6wIFQbGLUTYk=; b=jheUnvbOnYtMEtUx5QkG5hV84+JWfahDb7ag5C71a8T8tL+kjRXCdfee LTpCh2vSvsCpx6voKpoV4O8hAKUqynRAzg1Htza1KKrCcWC1dYOXB3jbe nHnI1h43Wh6mvSUqOUJvG1ICtSVHDycP5OqX0k2r8wPx3F5FviMVJH/R9 M=;
IronPort-PHdr: =?us-ascii?q?9a23=3A3ZGrrRFomNAOSSQwQKhNx51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeTwZiw/FcJqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AABFIORc/5NdJa1lHgEGBwaBUQk?= =?us-ascii?q?LAYE9JAUnA2lVIAQLKAqECYNHA452gjKXTIEuFIEQA1QJAQEBDAEBIwoCAQG?= =?us-ascii?q?EQAIXgg8jNAkOAQMBAQQBAQIBBG0cDIVLAgQSEREMAQE3AQ8CAQgaAgkdAgI?= =?us-ascii?q?CMBUQAgQBDQUigwABgWoDHQEOnC8CgTWIX3GBL4J5AQEFgUdBgn0Ygg8DBoE?= =?us-ascii?q?MKAGLUBeBQD+BEScME4JMPoJhAgECAYEhCQESAR8XIQKCUDKCJos4gkKaLQk?= =?us-ascii?q?Cgg2GLoh4g1obgh6GW40zjFaGco5WAgQCBAUCDgEBBYFPOCk9WBEIcBVlAYJ?= =?us-ascii?q?Bgg83bQEHgkOFFIU/cgGBKItFgSIBgSABAQ?=
X-IronPort-AV: E=Sophos;i="5.60,495,1549929600"; d="scan'208";a="274673111"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 May 2019 16:03:46 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x4LG3kl0014564 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 May 2019 16:03:46 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 11:03:45 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 May 2019 11:03:44 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 21 May 2019 11:03:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=blRjYlicwelG+Q9EYDPjPM1JfhP0g1K6wIFQbGLUTYk=; b=IDPV9SlVwaO1/EoX3r3g9elgOiryX2P8roSbOALV9fgMtkH/tsTl/GKDQVecO7tOARX1cr0E77CkRhbRzNcCjcFEHxYAWpkWqTFyisGQfjx2ABGBJ5t51wXEFzm68Kv48jWV6ANVoIuSbnH0IYGgnxWHXbppW/mm1XBlBOewMsY=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2187.namprd11.prod.outlook.com (10.174.104.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.16; Tue, 21 May 2019 16:03:43 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1900.020; Tue, 21 May 2019 16:03:43 +0000
From: "Reshad Rahman (rrahman)" 
To: Magnus Westerlund , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
Thread-Index: AQHVC90j5N+ogNsXt0aGO/2zhavC3qZ1grgA
Date: Tue, 21 May 2019 16:03:43 +0000
Message-ID: <6CAAE1F0-336D-4E43-9544-7D83FC456409@cisco.com>
References: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com>
In-Reply-To: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [173.38.117.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 600495f3-6e73-4d85-187f-08d6de05e62a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2187; 
x-ms-traffictypediagnostic: DM5PR1101MB2187:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(366004)(136003)(189003)(199004)(6486002)(26005)(186003)(6246003)(99286004)(305945005)(83716004)(14454004)(68736007)(478600001)(966005)(53936002)(6306002)(76116006)(73956011)(6512007)(102836004)(64756008)(66446008)(66556008)(91956017)(5660300002)(66946007)(66476007)(256004)(82746002)(7736002)(76176011)(2906002)(6436002)(6116002)(25786009)(3846002)(6506007)(4326008)(229853002)(71190400001)(36756003)(71200400001)(2616005)(66066001)(476003)(86362001)(446003)(486006)(58126008)(110136005)(11346002)(81156014)(81166006)(8936002)(33656002)(54906003)(8676002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2187; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: NhN5F6+8Km2SVvEwQ++qIrzDiXT/YQ2FUVLU3rovo4nu0N6Z01htmZB2Kxt+HE4tK2mcBNeXGYM4O5GDiDo1hmKpYwA7B3p+SNOS4OTOtOziCseply3k6vzoJcfL8fw/jKkrVpAwYiZ72VJ98VtGoWbYkpUQzBwagHJqbra1muV8YvI0+hZ82MIH0Yn/SPIGLp7IDnD6VF3+DURD9L+2T64u4zMCBTU+w6otbGfiOPxxWWSgEs4cvMtKUM51CLdC8uB/BKY6xPXOSBemcKftUB/w6FS1MfB1W977l6L0uqNexqdyj58twfQHaEAxo8sDZ3T4t8yJA1B0jtOEvnFRt2QBIdJgM5JlqI65CPGRD9M1Ag+KtCerVeQPbOAQjNge69avmwScm6ZIbrnN60qfXmjKwVnjxb8PFJkoiU2UXtY=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 600495f3-6e73-4d85-187f-08d6de05e62a
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 16:03:43.5353 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2187
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 16:04:02 -0000

SGksDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUuDQoNCu+7
v09uIDIwMTktMDUtMTYsIDc6NDcgQU0sICJNYWdudXMgV2VzdGVybHVuZCB2aWEgRGF0YXRyYWNr
ZXIiIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIE1hZ251cyBXZXN0ZXJsdW5kIGhh
cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRyYWZ0LWll
dGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZi0xMzogTm8gT2JqZWN0aW9uDQogICAgDQogICAgV2hl
biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw
bHkgdG8gYWxsDQogICAgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg
bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBo
LCBob3dldmVyLikNCiAgICANCiAgICANCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1v
cmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4N
CiAgICANCiAgICANCiAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv
c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLw0KICAgIA0KICAgIA0K
ICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CiAgICANCiAgICBTZWN0aW9uIDQ6DQogICAgDQogICAgQmFzZWQgb24gdGhlIFFvUyBkaXNjdXNz
aW9uIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQogICAg
d2VpZ2h0IGlzIG5vdCByZWFsbHkgYSBhIHByaW9yaXR5IGluIHRoZSB0ZXJtcyBwZW9wbGUgdGhp
bmsgb2YgaXQuIEl0IG9ubHkNCiAgICBwcm92aWRlcyBhIHdlaWdodCBmb3IgYmFuZHdpZHRoIGFs
bG9jYXRpb24uDQogICAgDQogICAgICAgbyAgdGFrZSBhbnkgZXhpc3Rpbmcgc3Vic2NyaXB0aW9u
ICJwcmlvcml0eSIsIGFzIHNwZWNpZmllZCBieSB0aGUNCiAgICAgICAgICAid2VpZ2h0aW5nIiBs
ZWFmIG5vZGUgaW4NCiAgICAgICAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnNdLCBhbmQgY29weSBpdA0KICAgICAgICAgIGludG8gdGhlIEhUVFAyIHN0
cmVhbSB3ZWlnaHQsIFtSRkM3NTQwXSBzZWN0aW9uIDUuMywgYW5kDQogICAgDQogICAgSSB3b3Vs
ZCByZWNvbW1lbmQgdGhhdCB0aGUgdXNlIG9mICJwcmlvcml0eSIgaXMgcmVmb3JtdWFsdGVkIGhl
cmUgdG8gcmVmbGVjdA0KICAgIHRoYXQgYXNwZWN0Lg0KPFJSPiBXZSBnb3Qgc2ltaWxhciBjb21t
ZW50cyBmcm9tIGFub3RoZXIgcmV2aWV3ZXIsIHRoZSBwcm9wb3NlZCBuZXcgdGV4dCBmb3IgdGhl
IG5leHQgcmV2aXNpb24gaXM6DQp0YWtlIHRoZSAid2VpZ2h0aW5nIiBsZWFmIG5vZGUgaW4gIFtJ
LUQuZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10sIGFuZCBjb3B5
IGl0IGludG8gdGhlIEhUVFAyIHN0cmVhbSB3ZWlnaHQsIFtSRkM3NTQwXSBzZWN0aW9uIDUuMywg
YW5kIC4uLg0KV291bGQgdGhpcyBhZGRyZXNzIHlvdXIgY29tbWVudD8NCiAgICANCiAgICAgICBv
ICB0YWtlIGFueSBleGlzdGluZyBzdWJzY3JpcHRpb24gImRlcGVuZGVuY3kiLCBhcyBzcGVjaWZp
ZWQgYnkgdGhlDQogICAgICAgICAgImRlcGVuZGVuY3kiIGxlYWYgbm9kZSBpbg0KICAgICAgICAg
IFtJLUQuZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10sIGFuZCB1
c2UgdGhlDQogICAgICAgICAgSFRUUDIgc3RyZWFtIGZvciB0aGUgcGFyZW50IHN1YnNjcmlwdGlv
biBhcyB0aGUgSFRUUDIgc3RyZWFtDQogICAgICAgICAgZGVwZW5kZW5jeSwgW1JGQzc1NDBdIHNl
Y3Rpb24gNS4zLjEsIG9mIHRoZSBkZXBlbmRlbnQNCiAgICAgICAgICBzdWJzY3JpcHRpb24uDQog
ICAgDQogICAgV2hhdCBpcyBub3Qgb2Jpdm91cyB0byBtZSBpcyB0aGF0IGp1c3QgYmVjYXVzZSB0
aGF0IGEgc3Vic2NyaXB0aW9uIGV4aXN0cyBhdA0KICAgIHRoZSBwdWJsaXNoZXIgdGhhdCBpdCBp
cyBnb2luZyBvdmVyIHRoZSBzYW1lIEhUVFAvMiBjb25uZWN0aW9uIGFuZCB0aHVzIHRoZXJlDQog
ICAgbWlnaHQgYmUgbm90aGluZyBmb3IgdGhlIGRlcGVuZGVuY3kgdG8gcG9pbnQgYXQgdGhhdCBp
cyByZWxldmFudCBmb3IgdGhlDQogICAgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBSRkMgNzU0MC4g
SSBkaWRuJ3QgZXZlbiBmaW5kIGEgcmVjb21tZW5kYXRpb24gdGhhdCB0aGUNCiAgICByZWNlaXZl
ciAoc3Vic2NyaWJlcikgc2hvdWxkIGFjdHVhbGx5IHJlLXVzZSB0aGUgSFRUUC8yIGNvbm5lY3Rp
b24gZm9yIGFsbA0KICAgIGNvbW11bmljYXRpb24gd2l0aCB0aGUgc2FtZSBwdWJsaXNoZXIuDQog
PFJSPiBHb29kIHBvaW50LCB0aGlzIGlzIG5vdCBzcGVsbGVkIG91dC4gIFdlIHdpbGwgYWRkIHRl
eHQgZm9yIHRoZSBzdWJzY3JpYmVyJ3MgcmV1c2Ugb2YgdGhlIEhUVFAyIHNlc3Npb246DQpmb3Ig
ZHluYW1pYyBzdWJzY3JpcHRpb25zIHRvIGEgc3BlY2lmaWMgcHVibGlzaGVyLCBhbGwgc3Vic2Ny
aWJlciBVUkkgR0VUIHJlcXVlc3RzIE1VU1QgdXNlIGEgY29tbW9uIEhUVFAyIHNlc3Npb24gZm9y
IGEgcGFydGljdWxhciBEU0NQIHZhbHVlLg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KICAgIA0KDQo=


From nobody Tue May 21 21:57:00 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4109D1200DE; Tue, 21 May 2019 21:56:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <155850101219.2355.1472349091350700255@ietfa.amsl.com>
Date: Tue, 21 May 2019 21:56:52 -0700
Archived-At: 
Subject: [netconf] I-D Action: draft-ietf-netconf-yang-push-25.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 May 2019 04:56:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Subscription to YANG Datastores
        Authors         : Alexander Clemm
                          Eric Voit
	Filename        : draft-ietf-netconf-yang-push-25.txt
	Pages           : 58
	Date            : 2019-05-21

Abstract:
   This document describes a mechanism that allows subscriber
   applications to request a continuous and customized stream of updates
   from a YANG datastore.  Providing such visibility into updates
   enables new capabilities based on the remote mirroring and monitoring
   of configuration and operational state.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-yang-push-25
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-25

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


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

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


From nobody Wed May 22 00:44:00 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284831200B1; Wed, 22 May 2019 00:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q--VqHgL3ae4; Wed, 22 May 2019 00:43:55 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51B212004B; Wed, 22 May 2019 00:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPBzVuzra5Yrr3EuiL1+AZwD8Rn+9RHdXbLmBeMIvpU=; b=c5UhHm9dC4HJ6uvse7PgZuAxyzojpdK27btBKA+K9gyrkno4VvK7SdC8GRfwqf122AVwo/pmWeWSSgYZ9plQu7YKMqH7YTmMgoPZYD31UviKsmXQUuoBnaVym/c6CY81b4MHrtCfItweujhOGznenrOPzg19ExSyfSwyIYP8xmg=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2587.eurprd07.prod.outlook.com (10.168.190.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.13; Wed, 22 May 2019 07:43:50 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.016; Wed, 22 May 2019 07:43:50 +0000
From: Magnus Westerlund 
To: "Reshad Rahman (rrahman)" , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
Thread-Index: AQHVC90hSxzlbk31FUCEnsswKya10w==
Date: Wed, 22 May 2019 07:43:50 +0000
Message-ID: 
References: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com> <6CAAE1F0-336D-4E43-9544-7D83FC456409@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dd647e14-bcda-4bc3-5019-08d6de893b3a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2587; 
x-ms-traffictypediagnostic: HE1PR0701MB2587:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0045236D47
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(136003)(346002)(39860400002)(199004)(189003)(3846002)(6116002)(55016002)(6246003)(44832011)(5660300002)(53546011)(110136005)(8676002)(6436002)(81156014)(54906003)(9686003)(25786009)(6306002)(53936002)(68736007)(7736002)(305945005)(8936002)(2906002)(4326008)(81166006)(256004)(86362001)(446003)(229853002)(74316002)(508600001)(99286004)(316002)(486006)(476003)(66066001)(966005)(66476007)(66556008)(64756008)(102836004)(71190400001)(71200400001)(33656002)(76176011)(66446008)(7696005)(52536014)(73956011)(76116006)(14454004)(66946007)(26005)(6506007)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2587; H:HE1PR0701MB2522.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: XOjuyAoF5dRJMtKBrITffFJkZTtz6B0i0hOcyGBru3V627aCCMj+T0TySG9w1ea1YyILIfEkIum/kdtGv2WujQstULwaDKuUsCsos3llN4SKRomAlFXaZCNfk5hI9jQ8IJRl2aip8uF15+yDD4/ggsREP3nQvyvB6WM25JpcHILCiUMOU5G9ekiqQ76Rt+Pwb3ZU7Ts8YvFf0+6yLMow8w//QlpIZ8xI3ddzEfp1DZnF9Z8W4HqvqHLPsfYVq5WrKcjdMupcRTQYajEkToW8SjKECNmCMUM+WWJpjyntuEVmRRCRId0UmF0YlIiPq9QZReo9uZnsJl6e/NpQrC2ddm+uHdIZTp9kU1gNxPj9k+To27hgNvYRPo3Lrj9bl9aR74RbsD4Z9oKlCLXdiN8JCAKV5Swtpc9il+/Re6gPExE=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd647e14-bcda-4bc3-5019-08d6de893b3a
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2019 07:43:50.3805 (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-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2587
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 May 2019 07:43:58 -0000

T24gMjAxOS0wNS0yMSAxODowMywgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6Cj4gSGks
Cj4KPiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lLgo+Cj4g77u/
T24gMjAxOS0wNS0xNiwgNzo0NyBBTSwgIk1hZ251cyBXZXN0ZXJsdW5kIHZpYSBEYXRhdHJhY2tl
ciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOgo+Cj4gICAgIE1hZ251cyBXZXN0ZXJsdW5kIGhh
cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcgo+ICAgICBkcmFmdC1p
ZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYtMTM6IE5vIE9iamVjdGlvbgo+ICAgICAKPiAgICAg
V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQg
cmVwbHkgdG8gYWxsCj4gICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k
IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzCj4gICAgIGludHJvZHVjdG9yeSBwYXJh
Z3JhcGgsIGhvd2V2ZXIuKQo+ICAgICAKPiAgICAgCj4gICAgIFBsZWFzZSByZWZlciB0byBodHRw
czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwKPiAg
ICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv
c2l0aW9ucy4KPiAgICAgCj4gICAgIAo+ICAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro
ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6Cj4gICAgIGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZi8K
PiAgICAgCj4gICAgIAo+ICAgICAKPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICAgICBDT01NRU5UOgo+
ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tCj4gICAgIAo+ICAgICBTZWN0aW9uIDQ6Cj4gICAgIAo+ICAgICBC
YXNlZCBvbiB0aGUgUW9TIGRpc2N1c3Npb24gZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3Jp
YmVkLW5vdGlmaWNhdGlvbnMKPiAgICAgd2VpZ2h0IGlzIG5vdCByZWFsbHkgYSBhIHByaW9yaXR5
IGluIHRoZSB0ZXJtcyBwZW9wbGUgdGhpbmsgb2YgaXQuIEl0IG9ubHkKPiAgICAgcHJvdmlkZXMg
YSB3ZWlnaHQgZm9yIGJhbmR3aWR0aCBhbGxvY2F0aW9uLgo+ICAgICAKPiAgICAgICAgbyAgdGFr
ZSBhbnkgZXhpc3Rpbmcgc3Vic2NyaXB0aW9uICJwcmlvcml0eSIsIGFzIHNwZWNpZmllZCBieSB0
aGUKPiAgICAgICAgICAgIndlaWdodGluZyIgbGVhZiBub2RlIGluCj4gICAgICAgICAgIFtJLUQu
ZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc10sIGFuZCBjb3B5IGl0
Cj4gICAgICAgICAgIGludG8gdGhlIEhUVFAyIHN0cmVhbSB3ZWlnaHQsIFtSRkM3NTQwXSBzZWN0
aW9uIDUuMywgYW5kCj4gICAgIAo+ICAgICBJIHdvdWxkIHJlY29tbWVuZCB0aGF0IHRoZSB1c2Ug
b2YgInByaW9yaXR5IiBpcyByZWZvcm11YWx0ZWQgaGVyZSB0byByZWZsZWN0Cj4gICAgIHRoYXQg
YXNwZWN0Lgo+IDxSUj4gV2UgZ290IHNpbWlsYXIgY29tbWVudHMgZnJvbSBhbm90aGVyIHJldmll
d2VyLCB0aGUgcHJvcG9zZWQgbmV3IHRleHQgZm9yIHRoZSBuZXh0IHJldmlzaW9uIGlzOgo+IHRh
a2UgdGhlICJ3ZWlnaHRpbmciIGxlYWYgbm9kZSBpbiAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYt
c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXSwgYW5kIGNvcHkgaXQgaW50byB0aGUgSFRUUDIgc3Ry
ZWFtIHdlaWdodCwgW1JGQzc1NDBdIHNlY3Rpb24gNS4zLCBhbmQgLi4uCj4gV291bGQgdGhpcyBh
ZGRyZXNzIHlvdXIgY29tbWVudD8KClllcywgdGhhdCBpcyBhdCBsZWFzdCBhY3Rpb25hYmxlLgoK
Cj4gICAgIAo+ICAgICAgICBvICB0YWtlIGFueSBleGlzdGluZyBzdWJzY3JpcHRpb24gImRlcGVu
ZGVuY3kiLCBhcyBzcGVjaWZpZWQgYnkgdGhlCj4gICAgICAgICAgICJkZXBlbmRlbmN5IiBsZWFm
IG5vZGUgaW4KPiAgICAgICAgICAgW0ktRC5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1u
b3RpZmljYXRpb25zXSwgYW5kIHVzZSB0aGUKPiAgICAgICAgICAgSFRUUDIgc3RyZWFtIGZvciB0
aGUgcGFyZW50IHN1YnNjcmlwdGlvbiBhcyB0aGUgSFRUUDIgc3RyZWFtCj4gICAgICAgICAgIGRl
cGVuZGVuY3ksIFtSRkM3NTQwXSBzZWN0aW9uIDUuMy4xLCBvZiB0aGUgZGVwZW5kZW50Cj4gICAg
ICAgICAgIHN1YnNjcmlwdGlvbi4KPiAgICAgCj4gICAgIFdoYXQgaXMgbm90IG9iaXZvdXMgdG8g
bWUgaXMgdGhhdCBqdXN0IGJlY2F1c2UgdGhhdCBhIHN1YnNjcmlwdGlvbiBleGlzdHMgYXQKPiAg
ICAgdGhlIHB1Ymxpc2hlciB0aGF0IGl0IGlzIGdvaW5nIG92ZXIgdGhlIHNhbWUgSFRUUC8yIGNv
bm5lY3Rpb24gYW5kIHRodXMgdGhlcmUKPiAgICAgbWlnaHQgYmUgbm90aGluZyBmb3IgdGhlIGRl
cGVuZGVuY3kgdG8gcG9pbnQgYXQgdGhhdCBpcyByZWxldmFudCBmb3IgdGhlCj4gICAgIG1lY2hh
bmlzbSBkZXNjcmliZWQgaW4gUkZDIDc1NDAuIEkgZGlkbid0IGV2ZW4gZmluZCBhIHJlY29tbWVu
ZGF0aW9uIHRoYXQgdGhlCj4gICAgIHJlY2VpdmVyIChzdWJzY3JpYmVyKSBzaG91bGQgYWN0dWFs
bHkgcmUtdXNlIHRoZSBIVFRQLzIgY29ubmVjdGlvbiBmb3IgYWxsCj4gICAgIGNvbW11bmljYXRp
b24gd2l0aCB0aGUgc2FtZSBwdWJsaXNoZXIuCj4gIDxSUj4gR29vZCBwb2ludCwgdGhpcyBpcyBu
b3Qgc3BlbGxlZCBvdXQuICBXZSB3aWxsIGFkZCB0ZXh0IGZvciB0aGUgc3Vic2NyaWJlcidzIHJl
dXNlIG9mIHRoZSBIVFRQMiBzZXNzaW9uOgo+IGZvciBkeW5hbWljIHN1YnNjcmlwdGlvbnMgdG8g
YSBzcGVjaWZpYyBwdWJsaXNoZXIsIGFsbCBzdWJzY3JpYmVyIFVSSSBHRVQgcmVxdWVzdHMgTVVT
VCB1c2UgYSBjb21tb24gSFRUUDIgc2Vzc2lvbiBmb3IgYSBwYXJ0aWN1bGFyIERTQ1AgdmFsdWUu
CgpJcyB0aGF0IHJlYWxseSBhIE1VU1Q/IEkgd291bGQgdW5kZXJzdGFuZCBhIFJFQ09NTUVOREVE
IHRvIGVuYWJsZSB0aGUKZGVwZW5kZW5jeSBhbmQgd2VpZ2h0aW5nIHdpdGhpbiB0aGUgc3Vic2Ny
aXB0aW9uIHVzaW5nIHRoZSBzYW1lIERTQ1AuCkhvd2V2ZXIsIHdoYXQgYXJlIHRoZSByZWFzb25z
IHRvIG1hbmRhdGUgaXQsIGFuZCBJIGRvbid0IGJlbGlldmUgaXQgaXMKZW5mb3JjZWFibGUgYXMg
dGhlIHB1Ymxpc2hlciBjYW4ndCBkZXRlcm1pbmUgdGhhdCBhIHJlY2VpdmVyIGlzIHRoZSBzYW1l
Cmluc3RhbmNlIGFzIGFub3RoZXIgcmVjZWl2ZXIsIGF0IGxlYXN0IG5vdCBpZiBJIGFzc3VtZSB0
aGF0IHRoZQpyZWNlaXZlcnMgYXJlIGluc3RhbmNlcyBydW5uaW5nIGluIGEgdmlydHVhbGl6ZWQg
ZW52aXJvbm1lbnQuCgoKQ2hlZXJzCgpNYWdudXMgV2VzdGVybHVuZCAKCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
TmV0d29yayBBcmNoaXRlY3R1cmUgJiBQcm90b2NvbHMsIEVyaWNzc29uIFJlc2VhcmNoCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4
Mjg3ClRvcnNoYW1uc2dhdGFuIDIzICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQpT
RS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVy
aWNzc29uLmNvbQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgo=


From nobody Wed May 22 08:31:51 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DE4120074; Wed, 22 May 2019 08:31:43 -0700 (PDT)
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.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ibagdona@gmail.com, The IESG , draft-ietf-netconf-netconf-event-notifications@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, rfc-editor@rfc-editor.org, Kent Watsen , netconf-chairs@ietf.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <155853910333.11385.17111702462176846245.idtracker@ietfa.amsl.com>
Date: Wed, 22 May 2019 08:31:43 -0700
Archived-At: 
Subject: [netconf] Protocol Action: 'Dynamic subscription to YANG Events and Datastores over NETCONF' to Proposed Standard (draft-ietf-netconf-netconf-event-notifications-22.txt)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 May 2019 15:31:43 -0000

The IESG has approved the following document:
- 'Dynamic subscription to YANG Events and Datastores over NETCONF'
  (draft-ietf-netconf-netconf-event-notifications-22.txt) as Proposed Standard

This document is the product of the Network Configuration Working Group.

The IESG contact persons are Warren Kumari and Ignas Bagdonas.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications/




Technical Summary

This document defines the NETCONF-specific extensions required for support of subscribe notifications. 


Working Group Summary

The WG has reached consensus on the document without any controversial topics. 


Document Quality

There is vendor interest in developing support for subscribe notifications, and as a result it will require implementing the extensions defined in this document. The document has received several directorate reviews, as well as a review from YANG Doctors. 


Personnel

The Document Shepherd is Kent Watsen. The Responsible Area Director is Ignas Bagdonas.




From nobody Wed May 22 10:02:37 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979441200B5; Wed, 22 May 2019 10:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWbx3ZdACK8X; Wed, 22 May 2019 10:02:30 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 C0722120165; Wed, 22 May 2019 10:02:29 -0700 (PDT)
Received: from [172.16.0.44] ([73.189.160.186]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M2fop-1hUssY0a6B-00486W;  Wed, 22 May 2019 19:02:25 +0200
From: Alexander Clemm 
To: 'Benjamin Kaduk' 
Cc: 'The IESG' , netconf@ietf.org, draft-ietf-netconf-yang-push@ietf.org, netconf-chairs@ietf.org
References: <155673770403.950.6197744294924652887.idtracker@ietfa.amsl.com> <043c01d50ac9$7099a780$51ccf680$@clemm.org> <20190515145945.GD14483@kduck.mit.edu> <052101d50b50$49cbf450$dd63dcf0$@clemm.org>
Message-ID: 
Date: Wed, 22 May 2019 10:02:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <052101d50b50$49cbf450$dd63dcf0$@clemm.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Provags-ID: V03:K1:bPGCf15qxKdVzAk/AH07GWNpaOv48AUhRen2f1SsAxsGdW4nZim UzuXswP1LgjQxK3pO/osVKzn4HENAec93rrhUxW1ZdwMQun3jQpQFZ0invsh8hf7pSeNgz0 z7nBYLNFl0pULpLbYJmeUq1ArXd6NMESWNz8fD3XOmfOgiWMh86v3BgNODzIgxtpTkyk5Pt FoJUqwFHdU6KOhCXj66/Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:sUB6EsNCUDA=:ka1tk8ZLbNelR/vb0MG2QB 6GfBf33Xmz5T3Z6FpYBJeURTlL+sJkIlNa0XiBF9+ZteFzrKT9Su3uOAHg2qozkuto2HTqNLX OCcaMkZEOiktr0fVBzQrFAfob5H2D+st72R26svRVptVdb8nJ/Nvp6IlkFM8umWbGxIx7Zpbm Z5raJkP1O7N7ofDzDTKAPlSgFFrbzYE+lse2ieO0mQktdmu7q7s+tg9rtzJ/9oreXjZRxxXoQ PHkpWPhu6XQDRpP7LuCVLuiRqX8F05RLWXejfhevvRaIDC8LPNyh66Ia7gUgBuJD6mwWe7pxk OB06Ww1qLRE6psVoOl2UqI6dym4f3J9CeZ5UsNx6cTH1iwivJ+CI3obxh+Tr/5yne06+tmkLV Tb3RMlqhMjz+9800Ti7p2z++IEbujTB8Lo5VwzzCbsQXSrRWp1rhFKRND+S4gh+qMqDRU1iLe hKuPsLJFGpy2jDnaRHEd/QXYX1l9WxzuaHSG90TwpjnvNq7keqwV0ndFg9znNe4eXcRDO4etU ktmSapb0LgcTw4FZ3JtOcXeF7ULuSFmXcyGhHLbF/thpyz/b3SBtIYnfcPeSY1DMzMZmASMxi pBwxVoVM57VRM+LCLfh+UkVqiB+Ya80tzIRYgf243Nh/L3yqK4z3imElJnjHYj9UTSUmKd5Ey LeQ+eHcC0g3PCWdagTg3xRRL3lqz8ep5m2rZJBZCw3Hnl8BZ4FN0kCXt8PyUdwyzy7FTLOHHi 66piNF8taJ8RU4+uIj6w9qMWYg8L9gQepW8pL5U8LXjCXATMut516P1vDKk=
Archived-At: 
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 May 2019 17:02:35 -0000

Hi Benjamin, all,

we have posted -25 to address your final comment.  -25 adds a reference 
to draft-ietf-netconf-notification-capabilities. Also, in section 3.10 
(On-Change Notifiable), the 3rd paragraph has been updated as follows: 
"Implementations are therefore strongly advised to provide a solution to 
this problem. One solution might involve making discoverable to clients 
which objects are on-change notifiable, specified using another YANG 
data model.  Such a solution is specified in . Until this 
solution is standardized, implementations SHOULD provide their own 
solution."

Thanks
--- Alex

On 5/15/2019 11:59 AM, Alexander Clemm wrote:
> Hi,
> Responses inline, 
> Thanks
> --- Alex
>
> -----Original Message-----
> From: Benjamin Kaduk 
> Sent: Wednesday, May 15, 2019 8:00 AM
> To: Alexander Clemm 
> Cc: 'The IESG' ; netconf@ietf.org;
> draft-ietf-netconf-yang-push@ietf.org; netconf-chairs@ietf.org
> Subject: Re: [netconf] Benjamin Kaduk's Discuss on
> draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
>
> On Tue, May 14, 2019 at 07:53:52PM -0700, Alexander Clemm wrote:
>> Hi Benjamin,
>>
>> Thank you for your review!  Replies inline, .  Update will be
>> reflected in -24, to be posted shortly.
>>
>> --- Alex
>>
>> -----Original Message-----
>> From: netconf  On Behalf Of Benjamin Kaduk
>> via Datatracker
>> Sent: Wednesday, May 1, 2019 12:08 PM
>> To: The IESG 
>> Cc: netconf@ietf.org; draft-ietf-netconf-yang-push@ietf.org;
>> netconf-chairs@ietf.org
>> Subject: [netconf] Benjamin Kaduk's Discuss on
>> draft-ietf-netconf-yang-push-23: (with DISCUSS and COMMENT)
>>
>> Benjamin Kaduk has entered the following ballot position for
>> draft-ietf-netconf-yang-push-23: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut
>> this introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Note that I reviewed the -22 and the current version is -23.  Briefly
>> skimming the diff, it seems that some changes touch on points I make
>> in my review, but there is probably still discussion to have on them.
>>
>> (pro-forma) I see the GenArt reviewer noted the author count (seven)
>> already, but I couldn't find a response or note in the ballot or
>> shephert writeup acknowledging this.  So failing that, I'll put up a
>> discuss point until the responsible AD says it's fine.
>>
>> [See also discussion on draft-ietf-netconf-subscribed notifications
>> about the pre-RFC5378 boilerplate and whether or not it can be removed
>> from this document]
>>
>>  Several of the authors have graciously agreed to step down and
>> be listed as contributors. 
> Thanks to them!
>
>> Section 3.3 states:
>>
>>              In order for a subscriber to determine whether objects
>>     support on-change subscriptions, objects are marked accordingly on a
>>     publisher.  Accordingly, when subscribing, it is the responsibility
>>     of the subscriber to ensure it is aware of which objects support on-
>>     change and which do not.  For more on how objects are so marked, see
>>     Section 3.10.
>>
>> Chasing the reference, we see that this marking is left for future
>> work or implementation-specific usage.  I'm not very comfortable with
>> the way we are describing this situation, as it seems pretty fragile
>> in the face of different implementations trying to interoperate.
>>
>>  The working group decided to pull this item out of this draft.
>> It is being addressed in draft-ietf-netconf-notification-capabilities
>> (https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capa
>> biliti
>> es/) 
> I guess I'll see what the -24 looks like, but I'm not sure yet whether
> "pull
> this item out of the draft" is describing a previous decision that left it
> in this state or a current decision starting from this state.  (The latter
> would seem to make more sense to me, but I can wait and see.)
>
>  To give a bit of history, in a set of earlier revisions we did
> describe a mechanism for this.  There was quite a bit of discussion around
> this and various options were considered, from introducing a YANG
> extension
> (see e.g. rev 12 section 3.10) to the mechanism that is now described in
> the
> separate draft.  There were also discussions whether such mechanism should
> be generalized further - for example, what if you wanted to express not
> only
> whether an item supports on-change subscriptions, but wants to give an
> indication of the "size" of the change?  The WG ultimately decided to not
> overburden the draft and slow progress down further and address this item
> separately.  There was also at some point discussion about keeping it
> simpler and take an all-or-nothing approach (require a server to either
> support on-change for all objects or none), which however was deemed to be
> too restrictive and we did want to allow for the possibility of a
> differentiated approach.
> Bottom line, I would like to ask please accept the previous decision.
> 
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you for the very thoughtful document!  I've lost track of the
>> number of places where I started writing a comment only to note that
>> my concern had already been addressed in the following text.  In
>> general the writing style is great, though I did find some grammar and
> clarity nits (noted inline).
>> Abstract
>>
>>                 Providing such visibility into updates enables new
>>     capabilities based on the remote mirroring and monitoring of
>>     configuration and operational state.
>>
>> This phrasing ("new capabilities based on") is hard for me to follow,
>> particularly about whether these are protocol-level capabilities and
>> what actors are granted the new capabilities.
>>
>>  The capabilities are clearly not related to protocol-level
>> capabilities, but capabilities for applications that have uses for
>> information obtained from YANG datastores.  If it's okay, at this
>> point we would like to keep it as-is. 
> It's your prerogative to keep it as-is, though the RFC Editor may also
> take
> a crack at the wording.
>
>  Sure.  Kept as is for now. 
>
>> Section 1
>>
>>     Traditional approaches to providing visibility into managed entities
>>     from remote have been built on polling.  [...]
>>
>> nit: "remote" is an adjective and needs a noun to bind to; "from
>> remote systems", "from remote vantages", or "from afar" would all be
>> fine wordings here.
>>
>>  changed to  "from a remote system".  
>>
>>     o  Polling incurs significant latency.  This latency prohibits many
>>        application types.
>>
>> nit: I'd suggest wording as "types of application", since on my first
>> reading I thought this was referring to some sort of codepoint.
>>
>>  changed 
>>
>>     o  Polling cycles may be missed, requests may be delayed or get lost,
>>        often when the network is under stress and the need for the data
>>        is the greatest.
>>
>> nit: the grammar is a bit weird, here, as if a comma splice.  I think
>> replacing the first comma with a colon or em dash would suffice.
>>
>>  replaced first comma with "and", to read: "Polling cycles may
>> be missed and requests may be delayed or get lost, often when the
>> network is under stress and the need for the data is the greatest."
>> 
> Thanks!
>
>>     o  Datastore node update: A data item containing the current value of
>>        a datastore node at the time the datastore node update was
>>        created, as well as the path to the datastore node.
>>
>> Is this storing the "new" or the "old" value as the "current value"?
>>
>>  I don't understand the question.  I think the statement is
>> clear.
> This sounds like it's conceptually "take a copy of some data as you make
> an
> update it, to have a historical record of what changed".  I mostly assume
> that the copy operation happens before the update, so the old/previous
> value
> is recorded in the record, but the text seems to describe them happening
> at
> the same time, without a specified ordering between them.
> (That said, IIRC, there is some text later in the document that helps
> clarify the intent, but that is not a free pass for leaving things unclear
> here.)
>
>  I think you are misreading this. There is no update action or copy
> operation that is being applied to a datastore node.  No operation or
> action
> is mentioned.  Instead, as the definition says, this is merely a data item
> which can be put into the stream of push update notifications.
> 
>
>> Section 3.1
>>
>>           +  Dampening period: In an on-change subscription, detected
>>              [...]
>>              is included.  The dampening period goes into effect every
>>              time an update record completes assembly.
>>
>> Just to double-check: this means that after a long hiatus, the first
>> change to the monitored subtree(s) triggers an immediate push with
>> just the single update, and only then does the dampening period kick
>> in and defer delivery of potential subsequent updates?
>>
>>  Yes, this is correct 
>>
>> Section 3.5.2
>>
>> This bit about the "create" and "delete" errors from RFC 8072 Section
>> 2.5 not being errors in our usage is a little interesting, process-wise.
>> In one sense, we are changing the semantics of an already published
>> RFC, and would need to apply an "Updates:" relationship to indicate
>> that, but in the other sense we are building a new custom thing that
>> reuses a lot of the syntax/semantics of YANG patch but is
>> fundamentally a new
>> (different) thing.  The phrasing we use to talk about it can affect
>> which case the reader perceives us to be in...
>>
>> The discussion on the "change-type" enumeration seems to pretty
>> clearly place us in the latter case, which is good.
>>
>>  Keeping this as is. 
>>
>> Section 3.6
>>
>> Thank you for the note about the power of XPath expressions and the
>> duty of the receiver to understand what it's asking for -- that sort
>> of statement would potentially even be appropriate in the Security
>> Considerations (but is fine where it is)!
>>
>>  Keeping this as is.  
>>
>> Section 3.7
>>
>>     Of note in the above example is the 'patch-id' with a value of '0'.
>>     Per [RFC8072], the 'patch-id' is an arbitrary string.  With YANG
>>     Push, the publisher SHOULD put into the 'patch-id' a counter starting
>>     at '0' which increments with every 'push-change-update' generated for
>>     a subscription.  If used as a counter, this counter MUST be reset to
>>     '0' anytime a resynchronization occurs (i.e., with the sending of a
>>     'push-update').  Also if used as a counter, the counter MUST be reset
>>     to '0' after passing a maximum value of '4294967295' (i.e. maximum
>>     value that can be represented using uint32 data type).  Such a
>>     mechanism allows easy identification of lost or out-of-sequence
>>     update records.
>>
>> It's not really clear to me how much value there is in this counter
>> mechanism if the client' can't rely on the server's behavior actually
>> being to use a counter (the requirement is only "SHOULD").  Can this be
> a
> "MUST"
>> (or maybe "MUST excpet when [...]") instead?
>>
>>  Would prefer to not introduce no MUST requirements at this
>> point and keep this as a SHOULD.  
> This is only a non-blocking comment, so go ahead.
>
>  Thank you 
>
>> Section 3.9
>>
>>                                                            Empty "push-
>>     change-update" messages (in case of an on-change subscription) MUST
>>     NOT be sent.  This is required to ensure that clients cannot
>>     surreptitiously monitor objects that they do not have access to via
>>     carefully crafted selection filters.  By the same token, changes to
>>     objects that are filtered MUST NOT affect any dampening intervals.
>>
>> I appreciate this attention to security-relevant detail; thank you!
>>
>>  thanks! 
>>
>> Section 3.11.1
>>
>> Do we want to give any guidance for the "incomplete-update" case about
>> whether a subscriber should wait and give the publisher a chance to
>> provide a full "push-update" for resynchronization (per Section 4.3.2)
>> versus perform a normal query for the datastore contents and
>> effectuating its own resynchronization?
>>
>>  This should be up to the subscriber to decide, and what to do
>> may differ for different applications.  In some instances, it can
>> afford to simply wait; in other cases or when specifically interested
>> in one particular closely-monitored item it may decide not to and sync
> immediately.
>> 
> Okay.
>
>> Section 4
>>
>>     o  For on-change subscriptions, assuming any dampening period has
>>        completed, triggering occurs whenever a change in the subscribed
>>        information is detected.  On-change subscriptions have more
>>        complex semantics that is guided by its own set of parameters:
>>
>> nit: singular/plural mismatch "semantics"/"is"
>>
>>  changed to "On-change subscriptions have more complex semantics
>> that are guided by their own set of parameters" 
>>
>> Section 4.3.2
>>
>>
>>     A "time-of-update" which represents the time an update record
>>     snapshot was generated.  A receiver MAY assume that at this point in
>>     time a publisher's objects have the values that were pushed.
>>
>> nit: I think "had the values" (past tense) is more appropriate.
>>
>>  changed 
>>
>> Section 4.4.1
>>
>>     a publisher that cannot serve on-change updates but periodic updates
>>     might return the following NETCONF response:
>>
>> nit: "but can serve periodic updates"
>>
>>  changed 
>>
>> Section 4.4.2
>>
>>     The specific parameters to be returned in as part of the RPC error
>>     response depend on the specific transport that is used to manage the
>>     subscription.  For NETCONF, those parameters are specified in
>>     [I-D.draft-ietf-netconf-netconf-event-notifications].
>>
>> nit: "in" and "as part of" are redundant.
>>
>>  removed "in" 
>>
>> Section 5
>>
>> It is slightly interesting to note that (apparently) the
>> update-policy-modifiable grouping allows for a subscription to switch
>> between periodic and triggered at runtime (by virtue of wanting a
>> single grouping to cover all the cases and needing to be able to
>> modify the parameters for each case).  I would mostly expect
>> implementations to deny such modification requests due to the needed
>> complexity, but I'm also not sure that there's a need to mention this
> explicitly in the document.
>>   I think it is implied that a modification request can always
>> be denied if not supported by a server.  At the same time, clearly in
>> general you would not change between on-change and periodic.  Keeping
>> as is. 
>>
>>              leaf period {
>>                type centiseconds;
>>                mandatory true;
>>                description
>>                  "Duration of time which should occur between periodic
>>                   push updates, in one hundredths of a second.";
>>
>> It would probably be okay to skip "in one hundredths of a second"
>> given the usage of the centiseconds typedef.
>>
>>  doesn't hurt to be explicit; keeping as is 
>>
>>      rc:yang-data resync-subscription-error {
>>        container resync-subscription-error {
>>          description
>>            "If a 'resync-subscription' RPC fails, the subscription is
>>             not resynced and the RPC error response MUST indicate the
>>             reason for this failure.  This yang-data MAY be inserted as
>>             structured data within a subscription's RPC error response
>>             to indicate the failure reason.";
>>
>> It's a little weird to have the normative language here constraining
>> the RPC error response that must be returned for a specific RPC, since
>> this is not the description of that RPC.  (It's probably also
>> duplicating langauge elsewhere but I didn't double-check.)
>>
>>  Keeping as is since it is clear what is happening.  Note that
>> there are limitations to the RPC semantics you can formally define in
>> YANG, hence the description. 
>>
>>      rc:yang-data establish-subscription-datastore-error-info {
>>        container establish-subscription-datastore-error-info {
>>          description
>>            "If any 'establish-subscription' RPC parameters are
>>             unsupportable against the datastore, a subscription is not
>>             created and the RPC error response MUST indicate the reason
>>             why the subscription failed to be created.  This yang-data
>>             MAY be inserted as structured data within a subscription's
>>             RPC error response to indicate the failure reason.  This
>>             yang-data MUST be inserted if hints are to be provided back
>>             to the subscriber.";
>>
>> (ditto)
>>
>> Contrast to modify-subscription-datastore-error-info, which only has
>> normative language about the yang-data being described and not the
>> RPCs that
>> (might) use it.
>>
>>  Would keep as is.  I think the semantics are clear.  
> You can certainly keep it as-is and I won't complain further; I just want
> to
> note that my complaint was not "the semantics are unclear if I read the
> whole document" but rather "the semantics are described in a different
> place
> than a naive reader might expect".  Yes, the reader is generally going to
> have to look up the description of the data types involved in the RPC as
> well as the RPC description itself to actually use it, but I can imagine
> some cases where that doesn't work as well as it could.
>
>  Thanks; your comment is well taken and I understand where you are
> coming from but let's keep it then. 
>> nit: push-update and push-change-update use different langauge about
>> "does not constitute a general-purpose notification" and I'm not sure
>> there's a reason to diverge.
>> Their "incomplete-update" leaves also have divergent descriptions, but
>> I think that latter divergence is more reasonable.
>>
>>  Updated the description of push-change-update to align this
>> part of the description of the notifications.  
> Thanks!
>
> -Ben
>
>>      augment "/sn:subscription-modified/sn:target" {
>>        [...]
>>        case datastore {
>>          uses datastore-criteria {
>>            refine "selection-filter/within-subscription" {
>>              description
>>                "Specifies where the selection filter, and where it came
>>                 from within the subscription and then populated within
>>                 this notification.  If the 'selection-filter-ref' is
>>
>> nit: "where the selection filter" seems like an incomplete clause.
>>
>>  Updating this to  "Specifies the selection filter and where it
>> originated  from.  If the 'selection-filter-ref' is ...".  This way,
>> the description also aligns better with the augment to
>> sn:subscription-started/sn:target. 
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>


From nobody Wed May 22 14:41:13 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0237B1200A4; Wed, 22 May 2019 14:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 header.b=FtIKBhsR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C5m7V6Tx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui2trSuq7_dT; Wed, 22 May 2019 14:40:59 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD111200A3; Wed, 22 May 2019 14:40:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6434; q=dns/txt; s=iport; t=1558561258; x=1559770858; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LoAwxQXKZkNAx9SNy6JddOWs8f9tl11tb/8aMG2YMI4=; b=FtIKBhsR1feBUO0GWwVoMVhJBZQPa1h6niFJu9N+s/KMV/dXfb2zgzMI z29HUI+1yztN8Jt+Hgm2gBzVua8oy98x3iOLtnawP8EG2MFHv2ea78qDg Q2IKoMuBhpp/BCCCwD7rc9+rZNH23nLz5oTceBl31T/eY8XbwaoahCJDw c=;
IronPort-PHdr: =?us-ascii?q?9a23=3Afhf4nRfP4IE0tWktfftgYfHKlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAAC1weVc/4UNJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT0pJwNpVSAECygKhAmDRwOEUooigleXKYEuFIEQA1QJAQE?= =?us-ascii?q?BDAEBIwoCAQGEQAIXghojNAkOAQMBAQQBAQIBBG0cDIVKAQEBAQIBEhERDAE?= =?us-ascii?q?BNwENAgIBCBIGAgIJGgMCAgIZFxQBAg4CBAENBSKDAAGBagMODwEOnHUCgTW?= =?us-ascii?q?IX3GBL4J5AQEFgUZBgwUYgg8DBgWBBygBi1AXgUA/gREnH4JMPoJhAgECAYE?= =?us-ascii?q?hCQESAR8XIQKCUDKCJos8gkOaNgkCgg2GMIh5g10bgh6GXo02jF2Gd45eAgQ?= =?us-ascii?q?CBAUCDgEBBYFPOCk9WBEIcBVlAYJBgg83bQEHgkOFFIU/cgGBKIpngSIBgSA?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,500,1549929600"; d="scan'208";a="281137330"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 May 2019 21:40:57 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x4MLeueR014503 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 May 2019 21:40:56 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 May 2019 16:40:55 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 May 2019 16:40:54 -0500
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 May 2019 17:40:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LoAwxQXKZkNAx9SNy6JddOWs8f9tl11tb/8aMG2YMI4=; b=C5m7V6Txy55p6b24sDVeSArVRVREqdZnfewZEGvAuhffyfpBmDchzAFjb6uQ+RRZKtVAKW3XlmyD5PqNYTyqJI1t0uLBmN/Kskj0K44LbBgiBAWMyChqhflLHOfolQfzd1edYuoq67C1Tv7SM5NIjfO2VHrRe39DbrRybn0tVzY=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2331.namprd11.prod.outlook.com (10.173.171.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Wed, 22 May 2019 21:40:52 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1922.017; Wed, 22 May 2019 21:40:52 +0000
From: "Reshad Rahman (rrahman)" 
To: Magnus Westerlund , The IESG 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , Kent Watsen , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
Thread-Index: AQHVC90j5N+ogNsXt0aGO/2zhavC3qZ3c0SA
Date: Wed, 22 May 2019 21:40:52 +0000
Message-ID: <516A6855-BC04-4E17-8F98-1255F624C44C@cisco.com>
References: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com> <6CAAE1F0-336D-4E43-9544-7D83FC456409@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [161.44.212.40]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5246c55d-4621-429c-6d89-08d6defe29f9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2331; 
x-ms-traffictypediagnostic: DM5PR1101MB2331:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0045236D47
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(376002)(346002)(366004)(199004)(189003)(66066001)(86362001)(229853002)(68736007)(476003)(256004)(446003)(36756003)(7736002)(6436002)(6506007)(53546011)(6306002)(305945005)(71200400001)(71190400001)(83716004)(5660300002)(11346002)(6486002)(2616005)(6246003)(102836004)(478600001)(486006)(6512007)(966005)(33656002)(186003)(76116006)(91956017)(76176011)(81166006)(53936002)(58126008)(6116002)(81156014)(110136005)(66476007)(73956011)(66556008)(66946007)(64756008)(8936002)(66446008)(316002)(54906003)(3846002)(8676002)(4326008)(99286004)(2906002)(82746002)(26005)(25786009)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2331; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: J0FqHds2w0s5lU087V0rrtXBgyuQPjcBdKHDazU5XMcZVwOhYEIWlFV1J/SmhSH/13m87OwhA9Yy6GaZyY2gxk5KKHWVcxOZXs8hi86V6o4Xa+6cPvQeruX8NUwr5MnxkrLa2/+QZNqvWFmv6hkmGFfz+ngOwhwCshPICy2kIpLTUDfRUc8TiOC4li70ZGgWduUL4IWgbCsgd0QaSmVPhoCSyZ7QRDW2AyG1KX4lfqpVVfiGEb2azeG+X0gPsfvcrZ3mvhoqzAkdfd7vtk/vSeU4sYTl/+EHRENqEpTu/qIa/pkiLbGDW2LjBxzb/vnrW0Bt5hW//c7/aNsPgs/SDiFEwd2hSubhELylq4R5CsLIMHUees2Q9PV0yG0nIoAuQ9il2eiDLdIB5nYxoX9AgFh3ZUc0uLkvshYo/LmNFWU=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0FFC6374520D714FB60A6E9BC23F9A3A@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5246c55d-4621-429c-6d89-08d6defe29f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2019 21:40:52.5074 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2331
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 May 2019 21:41:01 -0000

SGksDQoNCu+7v09uIDIwMTktMDUtMjIsIDM6NDQgQU0sICJNYWdudXMgV2VzdGVybHVuZCIgPG1h
Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCiAgICBPbiAyMDE5LTA1LTIx
IDE4OjAzLCBSZXNoYWQgUmFobWFuIChycmFobWFuKSB3cm90ZToNCiAgICA+IEhpLA0KICAgID4N
CiAgICA+IFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUuDQogICAg
Pg0KICAgID4gT24gMjAxOS0wNS0xNiwgNzo0NyBBTSwgIk1hZ251cyBXZXN0ZXJsdW5kIHZpYSBE
YXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4NCiAgICA+ICAgICBN
YWdudXMgV2VzdGVybHVuZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv
biBmb3INCiAgICA+ICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYtMTM6IE5v
IE9iamVjdGlvbg0KICAgID4gICAgIA0KICAgID4gICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNl
IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KICAgID4gICAg
IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm
cmVlIHRvIGN1dCB0aGlzDQogICAgPiAgICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl
ci4pDQogICAgPiAgICAgDQogICAgPiAgICAgDQogICAgPiAgICAgUGxlYXNlIHJlZmVyIHRvIGh0
dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K
ICAgID4gICAgIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N
TUVOVCBwb3NpdGlvbnMuDQogICAgPiAgICAgDQogICAgPiAgICAgDQogICAgPiAgICAgVGhlIGRv
Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo
ZXJlOg0KICAgID4gICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZi8NCiAgICA+ICAgICANCiAgICA+ICAgICANCiAgICA+
ICAgICANCiAgICA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAgICAgQ09NTUVOVDoNCiAgICA+
ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAgICAgDQogICAgPiAgICAgU2VjdGlvbiA0Og0KICAg
ID4gICAgIA0KICAgID4gICAgIEJhc2VkIG9uIHRoZSBRb1MgZGlzY3Vzc2lvbiBmb3IgZHJhZnQt
aWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KICAgID4gICAgIHdlaWdodCBp
cyBub3QgcmVhbGx5IGEgYSBwcmlvcml0eSBpbiB0aGUgdGVybXMgcGVvcGxlIHRoaW5rIG9mIGl0
LiBJdCBvbmx5DQogICAgPiAgICAgcHJvdmlkZXMgYSB3ZWlnaHQgZm9yIGJhbmR3aWR0aCBhbGxv
Y2F0aW9uLg0KICAgID4gICAgIA0KICAgID4gICAgICAgIG8gIHRha2UgYW55IGV4aXN0aW5nIHN1
YnNjcmlwdGlvbiAicHJpb3JpdHkiLCBhcyBzcGVjaWZpZWQgYnkgdGhlDQogICAgPiAgICAgICAg
ICAgIndlaWdodGluZyIgbGVhZiBub2RlIGluDQogICAgPiAgICAgICAgICAgW0ktRC5kcmFmdC1p
ZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXSwgYW5kIGNvcHkgaXQNCiAgICA+
ICAgICAgICAgICBpbnRvIHRoZSBIVFRQMiBzdHJlYW0gd2VpZ2h0LCBbUkZDNzU0MF0gc2VjdGlv
biA1LjMsIGFuZA0KICAgID4gICAgIA0KICAgID4gICAgIEkgd291bGQgcmVjb21tZW5kIHRoYXQg
dGhlIHVzZSBvZiAicHJpb3JpdHkiIGlzIHJlZm9ybXVhbHRlZCBoZXJlIHRvIHJlZmxlY3QNCiAg
ICA+ICAgICB0aGF0IGFzcGVjdC4NCiAgICA+IDxSUj4gV2UgZ290IHNpbWlsYXIgY29tbWVudHMg
ZnJvbSBhbm90aGVyIHJldmlld2VyLCB0aGUgcHJvcG9zZWQgbmV3IHRleHQgZm9yIHRoZSBuZXh0
IHJldmlzaW9uIGlzOg0KICAgID4gdGFrZSB0aGUgIndlaWdodGluZyIgbGVhZiBub2RlIGluICBb
SS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLCBhbmQgY29w
eSBpdCBpbnRvIHRoZSBIVFRQMiBzdHJlYW0gd2VpZ2h0LCBbUkZDNzU0MF0gc2VjdGlvbiA1LjMs
IGFuZCAuLi4NCiAgICA+IFdvdWxkIHRoaXMgYWRkcmVzcyB5b3VyIGNvbW1lbnQ/DQogICAgDQog
ICAgWWVzLCB0aGF0IGlzIGF0IGxlYXN0IGFjdGlvbmFibGUuDQogICAgDQogICAgDQogICAgPiAg
ICAgDQogICAgPiAgICAgICAgbyAgdGFrZSBhbnkgZXhpc3Rpbmcgc3Vic2NyaXB0aW9uICJkZXBl
bmRlbmN5IiwgYXMgc3BlY2lmaWVkIGJ5IHRoZQ0KICAgID4gICAgICAgICAgICJkZXBlbmRlbmN5
IiBsZWFmIG5vZGUgaW4NCiAgICA+ICAgICAgICAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1z
dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnNdLCBhbmQgdXNlIHRoZQ0KICAgID4gICAgICAgICAgIEhU
VFAyIHN0cmVhbSBmb3IgdGhlIHBhcmVudCBzdWJzY3JpcHRpb24gYXMgdGhlIEhUVFAyIHN0cmVh
bQ0KICAgID4gICAgICAgICAgIGRlcGVuZGVuY3ksIFtSRkM3NTQwXSBzZWN0aW9uIDUuMy4xLCBv
ZiB0aGUgZGVwZW5kZW50DQogICAgPiAgICAgICAgICAgc3Vic2NyaXB0aW9uLg0KICAgID4gICAg
IA0KICAgID4gICAgIFdoYXQgaXMgbm90IG9iaXZvdXMgdG8gbWUgaXMgdGhhdCBqdXN0IGJlY2F1
c2UgdGhhdCBhIHN1YnNjcmlwdGlvbiBleGlzdHMgYXQNCiAgICA+ICAgICB0aGUgcHVibGlzaGVy
IHRoYXQgaXQgaXMgZ29pbmcgb3ZlciB0aGUgc2FtZSBIVFRQLzIgY29ubmVjdGlvbiBhbmQgdGh1
cyB0aGVyZQ0KICAgID4gICAgIG1pZ2h0IGJlIG5vdGhpbmcgZm9yIHRoZSBkZXBlbmRlbmN5IHRv
IHBvaW50IGF0IHRoYXQgaXMgcmVsZXZhbnQgZm9yIHRoZQ0KICAgID4gICAgIG1lY2hhbmlzbSBk
ZXNjcmliZWQgaW4gUkZDIDc1NDAuIEkgZGlkbid0IGV2ZW4gZmluZCBhIHJlY29tbWVuZGF0aW9u
IHRoYXQgdGhlDQogICAgPiAgICAgcmVjZWl2ZXIgKHN1YnNjcmliZXIpIHNob3VsZCBhY3R1YWxs
eSByZS11c2UgdGhlIEhUVFAvMiBjb25uZWN0aW9uIGZvciBhbGwNCiAgICA+ICAgICBjb21tdW5p
Y2F0aW9uIHdpdGggdGhlIHNhbWUgcHVibGlzaGVyLg0KICAgID4gIDxSUj4gR29vZCBwb2ludCwg
dGhpcyBpcyBub3Qgc3BlbGxlZCBvdXQuICBXZSB3aWxsIGFkZCB0ZXh0IGZvciB0aGUgc3Vic2Ny
aWJlcidzIHJldXNlIG9mIHRoZSBIVFRQMiBzZXNzaW9uOg0KICAgID4gZm9yIGR5bmFtaWMgc3Vi
c2NyaXB0aW9ucyB0byBhIHNwZWNpZmljIHB1Ymxpc2hlciwgYWxsIHN1YnNjcmliZXIgVVJJIEdF
VCByZXF1ZXN0cyBNVVNUIHVzZSBhIGNvbW1vbiBIVFRQMiBzZXNzaW9uIGZvciBhIHBhcnRpY3Vs
YXIgRFNDUCB2YWx1ZS4NCiAgICANCiAgICBJcyB0aGF0IHJlYWxseSBhIE1VU1Q/IEkgd291bGQg
dW5kZXJzdGFuZCBhIFJFQ09NTUVOREVEIHRvIGVuYWJsZSB0aGUNCiAgICBkZXBlbmRlbmN5IGFu
ZCB3ZWlnaHRpbmcgd2l0aGluIHRoZSBzdWJzY3JpcHRpb24gdXNpbmcgdGhlIHNhbWUgRFNDUC4N
CiAgICBIb3dldmVyLCB3aGF0IGFyZSB0aGUgcmVhc29ucyB0byBtYW5kYXRlIGl0LCBhbmQgSSBk
b24ndCBiZWxpZXZlIGl0IGlzDQogICAgZW5mb3JjZWFibGUgYXMgdGhlIHB1Ymxpc2hlciBjYW4n
dCBkZXRlcm1pbmUgdGhhdCBhIHJlY2VpdmVyIGlzIHRoZSBzYW1lDQogICAgaW5zdGFuY2UgYXMg
YW5vdGhlciByZWNlaXZlciwgYXQgbGVhc3Qgbm90IGlmIEkgYXNzdW1lIHRoYXQgdGhlDQogICAg
cmVjZWl2ZXJzIGFyZSBpbnN0YW5jZXMgcnVubmluZyBpbiBhIHZpcnR1YWxpemVkIGVudmlyb25t
ZW50Lg0KPFJSMj4gWW91IGFyZSBjb3JyZWN0LiBXaGF0IGFib3V0Og0KZm9yIGR5bmFtaWMgc3Vi
c2NyaXB0aW9ucyB0byBhIHNwZWNpZmljIHB1Ymxpc2hlciwgaXQgaXMgcmVjb21tZW5kZWQgdGhh
dCBhbGwgc3Vic2NyaWJlciBVUkkgR0VUIHJlcXVlc3RzIHVzZSBhIGNvbW1vbiBIVFRQMiBzZXNz
aW9uIGZvciBhIHBhcnRpY3VsYXIgRFNDUCB2YWx1ZS4NCg0KUmVnYXJkcywNClJlc2hhZC4NCiAg
ICANCiAgICBDaGVlcnMNCiAgICANCiAgICBNYWdudXMgV2VzdGVybHVuZCANCiAgICANCiAgICAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQogICAgTmV0d29yayBBcmNoaXRlY3R1cmUgJiBQcm90b2NvbHMsIEVyaWNz
c29uIFJlc2VhcmNoDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIEVyaWNzc29uIEFCICAgICAgICAg
ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KICAgIFRvcnNoYW1uc2dhdGFuIDIzICAg
ICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KICAgIFNFLTE2NCA4MCBTdG9ja2hvbG0s
IFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQogICAgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KICAgIA0KICAgIA0KDQo=


From nobody Thu May 23 01:00:08 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF51200EF; Thu, 23 May 2019 00:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsxRMP8V1U05; Thu, 23 May 2019 00:59:56 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20082.outbound.protection.outlook.com [40.107.2.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC2D12001A; Thu, 23 May 2019 00:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XqugMowHRoEeG3TEgS0Uk1pvlvAOdixjptlP8BFV8CQ=; b=JWTKnHOMGEQjb075YMoOHeucMtIr+DqFCOEE0wwF/SD4dAl0IFgBuOgCVIAWtVIyjlJOSULI6pmN+y9hfXMOLnQZCg1lIhBWFlxIH/cwfGm/7GczKQbBvMtBLU12AWp9LQOYX7lP4f+5U8x3tfOh/2v+rcT6sRG12OCI8PCitmk=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.13; Thu, 23 May 2019 07:59:52 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.016; Thu, 23 May 2019 07:59:52 +0000
From: Magnus Westerlund 
To: "rrahman@cisco.com" , "iesg@ietf.org" 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , "kent+ietf@watsen.net" , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
Thread-Index: AQHVC90hSxzlbk31FUCEnsswKya106Z3tlMAgACr9/A=
Date: Thu, 23 May 2019 07:59:52 +0000
Message-ID: 
References: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com> <6CAAE1F0-336D-4E43-9544-7D83FC456409@cisco.com>  <516A6855-BC04-4E17-8F98-1255F624C44C@cisco.com>
In-Reply-To: <516A6855-BC04-4E17-8F98-1255F624C44C@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be677e84-f61f-46c5-1596-08d6df54a2fe
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2905; 
x-ms-traffictypediagnostic: HE1PR0701MB2905:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(366004)(136003)(39860400002)(189003)(199004)(99286004)(76176011)(7696005)(256004)(2501003)(6506007)(66476007)(73956011)(66556008)(64756008)(66446008)(6116002)(68736007)(102836004)(66946007)(6246003)(66616009)(71190400001)(71200400001)(53936002)(86362001)(8936002)(8676002)(81156014)(81166006)(25786009)(4326008)(316002)(74316002)(110136005)(54906003)(44832011)(11346002)(476003)(486006)(446003)(52536014)(7736002)(305945005)(229853002)(66066001)(5660300002)(6436002)(33656002)(26005)(186003)(3846002)(14454004)(99936001)(9686003)(2906002)(55016002)(76116006)(508600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2905; H:HE1PR0701MB2522.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: vAq4JmF9r9iClcutsNURg/z99FuV72bg1x+7T4EajKlcQlg/Q+zMNkN5Q85rWs3yhDueWzq5TNW25P/RwQzw/eLJfJPagm2d9z6AWYofLtbe7mlXQ5xd47Bf20HEaJqyZOCdKI++B+s09YnJdZCjJWRZM4V32Qcu4ius/El2QkTP2DZXTyXLZHMy5DZa0o0RXSjEItD+K6Z53y+xn04sKpcUA3h4PLcuWcQ/Av4BXn/XprzgfAdGIzHmXJN1FXuE/bcaWz5tqk5W190td1Hb1vO2ThnUJ8ONmFv1CIa5efs72gc8WVJj72bC9Bel97BN8WUcRXppGt6dAO8Plr4f4DAwRkxj80y9gneQ0D5S5QI3dgTM6T6bEknFCDAeJOnb50GccFVaz2Mdt/PrPEQ4bSsrQasu65BPpjjkLokXp6s=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0035_01D5114E.43295080"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be677e84-f61f-46c5-1596-08d6df54a2fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 07:59:52.3030 (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-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2905
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 May 2019 07:59:59 -0000

------=_NextPart_000_0035_01D5114E.43295080
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi,


>
>     >
>     >        o  take any existing subscription "dependency", as specified by 
> the
>     >           "dependency" leaf node in
>     >           [I-D.draft-ietf-netconf-subscribed-notifications], and use 
> the
>     >           HTTP2 stream for the parent subscription as the HTTP2 stream
>     >           dependency, [RFC7540] section 5.3.1, of the dependent
>     >           subscription.
>     >
>     >     What is not obivous to me is that just because that a subscription 
> exists
> at
>     >     the publisher that it is going over the same HTTP/2 connection and 
> thus
> there
>     >     might be nothing for the dependency to point at that is relevant 
> for the
>     >     mechanism described in RFC 7540. I didn't even find a 
> recommendation
> that the
>     >     receiver (subscriber) should actually re-use the HTTP/2 connection 
> for
> all
>     >     communication with the same publisher.
>     >   Good point, this is not spelled out.  We will add text for the
> subscriber's reuse of the HTTP2 session:
>     > for dynamic subscriptions to a specific publisher, all subscriber URI 
> GET
> requests MUST use a common HTTP2 session for a particular DSCP value.
>
>     Is that really a MUST? I would understand a RECOMMENDED to enable the
>     dependency and weighting within the subscription using the same DSCP.
>     However, what are the reasons to mandate it, and I don't believe it is
>     enforceable as the publisher can't determine that a receiver is the same
>     instance as another receiver, at least not if I assume that the
>     receivers are instances running in a virtualized environment.
>  You are correct. What about:
> for dynamic subscriptions to a specific publisher, it is recommended that 
> all
> subscriber URI GET requests use a common HTTP2 session for a particular
> DSCP value.

If you are rewriting the old sentence that had a MUST because different DSCP 
needs different TCP connections as only a single DSCP can be applied per TCP 
connection, I think you need to have these two issues separated. One for 
stating the recommendation about reusing HTTP/2 sessions for multiple 
subscriptions using the same DSCP value. A second one stating the requirement 
that you need to use different HTTP/2 sessions for each DSCP value in use.

Cheers

Magnus Westerlund

------=_NextPart_000_0035_01D5114E.43295080
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ
C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1
MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn
bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u
LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp
R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx
BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB
WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb
8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN
eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG
N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww
gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv
bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s
aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u
LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI
KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X
nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN
NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY
Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW
BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB
4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W
5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF
6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2
cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du
JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8
8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE
qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh
U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX
DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC
CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no
rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk
UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ
YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH
MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6
kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup
5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS
3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs
xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v
Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku
dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI
MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6
Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6
aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy
bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW
BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN
BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB
D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr
0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj
dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC
fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc
dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd
Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo
mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ
zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl
rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xOTA1MjMwNzU5NTBaMCMGCSqGSIb3DQEJBDEWBBThQPWAE4remOEQiGf0l/gf6izV
vTBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF
cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl
rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5
cXntMA0GCSqGSIb3DQEBAQUABIIBADKXVyOGJkgLrYgl4/qGQtx4nYNuq1co8sM1HWeqHoA1y0Et
84wsGsBgICDNNob7VGJYmEl8DxznDOKUD9+F0oyLnjThqzsFHZm+wx4dH3NRraEygT9lsJLmrWs8
ZqW+ZnznmGrWLnI3bT9AGEkMrhcHzA8v5H6cGO3htu5qJDrc1xVIXcuuY30N04BUai/W7Qq1oRYf
jJYCFJ1ha4LYoSQxN8y1dd8W8vhmRZ4p4/l6ej4wczKjUOMAenntAnTCE+eyZRBYIpUTJIMedq3S
NPi78yvOOxlCo814XriLGgROfJRV0BbElAklm77xxLsMcejRfBsVzHlydOia25CSWOwAAAAAAAA=

------=_NextPart_000_0035_01D5114E.43295080--


From nobody Thu May 23 10:01:58 2019
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00591120184; Thu, 23 May 2019 10:01:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: draft-ietf-netconf-yang-push@ietf.org, Kent Watsen ,  netconf-chairs@ietf.org, kent+ietf@watsen.net, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <155863091699.17104.157526908887351699.idtracker@ietfa.amsl.com>
Date: Thu, 23 May 2019 10:01:56 -0700
Archived-At: 
Subject: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-yang-push-25: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 May 2019 17:01:57 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netconf-yang-push-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss points!



From nobody Thu May 23 14:45:26 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DDB120105; Thu, 23 May 2019 14:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Bf5QUbun; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aA3/rH0/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTpSgyBXEY05; Thu, 23 May 2019 14:45:22 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E835120046; Thu, 23 May 2019 14:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4024; q=dns/txt; s=iport; t=1558647922; x=1559857522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zqosq2bxNCveW36r8wF2CYzMtbe4qeqGhPa0ZUrHQ6Q=; b=Bf5QUbuniPtJ5/T8cxSkMWUTrrL5/Kl7wZcymwFevTw0abntcmkhLbxH ZHZHZaWAVFTkmCT3UKJOSwKH+xSGNtemJCaRzC+7m3oC+JSaX+hABxX05 0YMST+YdP7okGo1H/VHi4qvv1krBChRqheCnR0HoL3Dh828k4sNBu2r8c A=;
IronPort-PHdr: =?us-ascii?q?9a23=3AXVxFsR8nKTUasv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSfAE3+JfjCZC0hF8MEX1hgrDm2?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AADeE+dc/5RdJa1mHgEGBwaBUQk?= =?us-ascii?q?LAYE9TgIDaVUgBAsohBODRwOOd5oAgS4UgRADVAkBAQEMAQEtAgEBhEACF4I?= =?us-ascii?q?hIzQJDgEDAQEEAQECAQRtHAyFSwIEEhERDAEBNwEPAgEIGgIJHQICAjAVEAI?= =?us-ascii?q?EAQ0FIoMAAYFqAx0Bm1ICgTeIX3GBL4J5AQEFhQkYgg8JgQwoAYtRF4FAP4E?= =?us-ascii?q?RJx+CTD6ECDwXI4JQMoImjgeaOwkCgg2TDhuWOIxklV8CBAIEBQIOAQEFgU8?= =?us-ascii?q?4KYEucBVlAYJBgg83gzmKUgFygSmNDgEB?=
X-IronPort-AV: E=Sophos;i="5.60,504,1549929600"; d="scan'208";a="275650091"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 May 2019 21:45:21 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x4NLjLc3012323 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 May 2019 21:45:21 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 May 2019 16:45:20 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 May 2019 16:45:20 -0500
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 May 2019 16:45:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zqosq2bxNCveW36r8wF2CYzMtbe4qeqGhPa0ZUrHQ6Q=; b=aA3/rH0/SpI006xw4UcbYTQsZu4lbYYSY0VhUeq+3V98luQZGZojHuwThbZ7foNOhbpvXRmYjZQKNdkr+Sq28ZC91n1ZGODR6a2ew/iarkPZ76Zup4uHFu3yupruu5QyMGFQHqkb2zPnNrtoZyqL/IGj7B3Ln8xPzjXG8j2Eufk=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2219.namprd11.prod.outlook.com (10.174.246.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.17; Thu, 23 May 2019 21:45:16 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1922.017; Thu, 23 May 2019 21:45:16 +0000
From: "Reshad Rahman (rrahman)" 
To: Magnus Westerlund , "iesg@ietf.org" 
CC: "draft-ietf-netconf-restconf-notif@ietf.org" , "kent+ietf@watsen.net" , "netconf-chairs@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
Thread-Index: AQHVC90j5N+ogNsXt0aGO/2zhavC3qZ3c0SAgADwAgCAAKOOgA==
Date: Thu, 23 May 2019 21:45:16 +0000
Message-ID: <7009FE15-1A66-4DD6-992D-F42C08A3909D@cisco.com>
References: <155800723160.19565.3853721470955609906.idtracker@ietfa.amsl.com> <6CAAE1F0-336D-4E43-9544-7D83FC456409@cisco.com>  <516A6855-BC04-4E17-8F98-1255F624C44C@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; 
x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0b0d4820-6356-48c9-11a8-08d6dfc7f1e4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2219; 
x-ms-traffictypediagnostic: DM5PR1101MB2219:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(396003)(346002)(376002)(189003)(199004)(305945005)(446003)(7736002)(76116006)(99286004)(91956017)(11346002)(66446008)(64756008)(73956011)(66476007)(66556008)(66946007)(2616005)(478600001)(110136005)(58126008)(54906003)(14454004)(6512007)(5660300002)(476003)(486006)(81156014)(316002)(76176011)(2501003)(6506007)(33656002)(46003)(102836004)(81166006)(6246003)(71200400001)(71190400001)(83716004)(6116002)(256004)(8676002)(4326008)(36756003)(8936002)(25786009)(229853002)(6436002)(2906002)(86362001)(6486002)(82746002)(68736007)(53936002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2219; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ZUjHV9Ane5/g9KopGX+ecqKSoJdKDn2lCrGkZwsCpOTDYFskePsOYfllxaZhmkn8vMXgPYf96RyKXPmUtI8fA/jSYexKcAbmVYJbSA7lLuxrWpc+f82Ic40uw8yIQIdvc3AS55JtGeTWieC102aeWv9nYb1Ym5SN1V1PUlRLME95RAGHCOFjSAlZ4yydIHA++Iecv75430GVYhbByJmJ5aZgAciBLv8HS7I4iWvpbi+1ZgSwxF9C746Lykr8FkChIQifsiodADmYV3npcL3psg+LR0IAH1CVLTHQrXGYr303muJOYd7c9UjKw84lmlFs/SaI5mP7mIfNNMR1UZvz1IGOOXYjb10/oGgmnnzyDCFDDiLnkmYP2MwnWqKTEjKJ8ZpSBrb49p5cxhwFfcdsNIpcIzKmCn/5j/IKjA6H5xY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <45339893A0129446988472EF391FDEE2@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b0d4820-6356-48c9-11a8-08d6dfc7f1e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 21:45:16.8044 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2219
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: 
Subject: Re: [netconf] Magnus Westerlund's No Objection on draft-ietf-netconf-restconf-notif-13: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 May 2019 21:45:25 -0000

SGksDQoNCu+7v09uIDIwMTktMDUtMjMsIDQ6MDAgQU0sICJNYWdudXMgV2VzdGVybHVuZCIgPG1h
Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICANCiAg
ICANCiAgICA+DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgICAgIG8gIHRha2UgYW55IGV4
aXN0aW5nIHN1YnNjcmlwdGlvbiAiZGVwZW5kZW5jeSIsIGFzIHNwZWNpZmllZCBieSANCiAgICA+
IHRoZQ0KICAgID4gICAgID4gICAgICAgICAgICJkZXBlbmRlbmN5IiBsZWFmIG5vZGUgaW4NCiAg
ICA+ICAgICA+ICAgICAgICAgICBbSS1ELmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5v
dGlmaWNhdGlvbnNdLCBhbmQgdXNlIA0KICAgID4gdGhlDQogICAgPiAgICAgPiAgICAgICAgICAg
SFRUUDIgc3RyZWFtIGZvciB0aGUgcGFyZW50IHN1YnNjcmlwdGlvbiBhcyB0aGUgSFRUUDIgc3Ry
ZWFtDQogICAgPiAgICAgPiAgICAgICAgICAgZGVwZW5kZW5jeSwgW1JGQzc1NDBdIHNlY3Rpb24g
NS4zLjEsIG9mIHRoZSBkZXBlbmRlbnQNCiAgICA+ICAgICA+ICAgICAgICAgICBzdWJzY3JpcHRp
b24uDQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgIFdoYXQgaXMgbm90IG9iaXZvdXMgdG8g
bWUgaXMgdGhhdCBqdXN0IGJlY2F1c2UgdGhhdCBhIHN1YnNjcmlwdGlvbiANCiAgICA+IGV4aXN0
cw0KICAgID4gYXQNCiAgICA+ICAgICA+ICAgICB0aGUgcHVibGlzaGVyIHRoYXQgaXQgaXMgZ29p
bmcgb3ZlciB0aGUgc2FtZSBIVFRQLzIgY29ubmVjdGlvbiBhbmQgDQogICAgPiB0aHVzDQogICAg
PiB0aGVyZQ0KICAgID4gICAgID4gICAgIG1pZ2h0IGJlIG5vdGhpbmcgZm9yIHRoZSBkZXBlbmRl
bmN5IHRvIHBvaW50IGF0IHRoYXQgaXMgcmVsZXZhbnQgDQogICAgPiBmb3IgdGhlDQogICAgPiAg
ICAgPiAgICAgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBSRkMgNzU0MC4gSSBkaWRuJ3QgZXZlbiBm
aW5kIGEgDQogICAgPiByZWNvbW1lbmRhdGlvbg0KICAgID4gdGhhdCB0aGUNCiAgICA+ICAgICA+
ICAgICByZWNlaXZlciAoc3Vic2NyaWJlcikgc2hvdWxkIGFjdHVhbGx5IHJlLXVzZSB0aGUgSFRU
UC8yIGNvbm5lY3Rpb24gDQogICAgPiBmb3INCiAgICA+IGFsbA0KICAgID4gICAgID4gICAgIGNv
bW11bmljYXRpb24gd2l0aCB0aGUgc2FtZSBwdWJsaXNoZXIuDQogICAgPiAgICAgPiAgPFJSPiBH
b29kIHBvaW50LCB0aGlzIGlzIG5vdCBzcGVsbGVkIG91dC4gIFdlIHdpbGwgYWRkIHRleHQgZm9y
IHRoZQ0KICAgID4gc3Vic2NyaWJlcidzIHJldXNlIG9mIHRoZSBIVFRQMiBzZXNzaW9uOg0KICAg
ID4gICAgID4gZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyB0byBhIHNwZWNpZmljIHB1Ymxpc2hl
ciwgYWxsIHN1YnNjcmliZXIgVVJJIA0KICAgID4gR0VUDQogICAgPiByZXF1ZXN0cyBNVVNUIHVz
ZSBhIGNvbW1vbiBIVFRQMiBzZXNzaW9uIGZvciBhIHBhcnRpY3VsYXIgRFNDUCB2YWx1ZS4NCiAg
ICA+DQogICAgPiAgICAgSXMgdGhhdCByZWFsbHkgYSBNVVNUPyBJIHdvdWxkIHVuZGVyc3RhbmQg
YSBSRUNPTU1FTkRFRCB0byBlbmFibGUgdGhlDQogICAgPiAgICAgZGVwZW5kZW5jeSBhbmQgd2Vp
Z2h0aW5nIHdpdGhpbiB0aGUgc3Vic2NyaXB0aW9uIHVzaW5nIHRoZSBzYW1lIERTQ1AuDQogICAg
PiAgICAgSG93ZXZlciwgd2hhdCBhcmUgdGhlIHJlYXNvbnMgdG8gbWFuZGF0ZSBpdCwgYW5kIEkg
ZG9uJ3QgYmVsaWV2ZSBpdCBpcw0KICAgID4gICAgIGVuZm9yY2VhYmxlIGFzIHRoZSBwdWJsaXNo
ZXIgY2FuJ3QgZGV0ZXJtaW5lIHRoYXQgYSByZWNlaXZlciBpcyB0aGUgc2FtZQ0KICAgID4gICAg
IGluc3RhbmNlIGFzIGFub3RoZXIgcmVjZWl2ZXIsIGF0IGxlYXN0IG5vdCBpZiBJIGFzc3VtZSB0
aGF0IHRoZQ0KICAgID4gICAgIHJlY2VpdmVycyBhcmUgaW5zdGFuY2VzIHJ1bm5pbmcgaW4gYSB2
aXJ0dWFsaXplZCBlbnZpcm9ubWVudC4NCiAgICA+IDxSUjI+IFlvdSBhcmUgY29ycmVjdC4gV2hh
dCBhYm91dDoNCiAgICA+IGZvciBkeW5hbWljIHN1YnNjcmlwdGlvbnMgdG8gYSBzcGVjaWZpYyBw
dWJsaXNoZXIsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgDQogICAgPiBhbGwNCiAgICA+IHN1YnNj
cmliZXIgVVJJIEdFVCByZXF1ZXN0cyB1c2UgYSBjb21tb24gSFRUUDIgc2Vzc2lvbiBmb3IgYSBw
YXJ0aWN1bGFyDQogICAgPiBEU0NQIHZhbHVlLg0KICAgIA0KICAgIElmIHlvdSBhcmUgcmV3cml0
aW5nIHRoZSBvbGQgc2VudGVuY2UgdGhhdCBoYWQgYSBNVVNUIGJlY2F1c2UgZGlmZmVyZW50IERT
Q1AgDQogICAgbmVlZHMgZGlmZmVyZW50IFRDUCBjb25uZWN0aW9ucyBhcyBvbmx5IGEgc2luZ2xl
IERTQ1AgY2FuIGJlIGFwcGxpZWQgcGVyIFRDUCANCiAgICBjb25uZWN0aW9uLCBJIHRoaW5rIHlv
dSBuZWVkIHRvIGhhdmUgdGhlc2UgdHdvIGlzc3VlcyBzZXBhcmF0ZWQuIE9uZSBmb3IgDQogICAg
c3RhdGluZyB0aGUgcmVjb21tZW5kYXRpb24gYWJvdXQgcmV1c2luZyBIVFRQLzIgc2Vzc2lvbnMg
Zm9yIG11bHRpcGxlIA0KICAgIHN1YnNjcmlwdGlvbnMgdXNpbmcgdGhlIHNhbWUgRFNDUCB2YWx1
ZS4gQSBzZWNvbmQgb25lIHN0YXRpbmcgdGhlIHJlcXVpcmVtZW50IA0KICAgIHRoYXQgeW91IG5l
ZWQgdG8gdXNlIGRpZmZlcmVudCBIVFRQLzIgc2Vzc2lvbnMgZm9yIGVhY2ggRFNDUCB2YWx1ZSBp
biB1c2UuDQpUaGUgdGV4dCBhYm92ZSB3YXMgaW5kZWVkIGZvciByZXVzaW5nIEhUVFAyIHNlc3Np
b25zIG9uIHRoZSBjbGllbnQvc3Vic2NyaWJlci4gSSdsbCBhZGQgdGV4dCBmb3IgdGhlIGxhc3Qg
cGFydCBhYm92ZSB0b28gKGRpZmZlcmVudCBEU0NQIHZhbHVlcyBjYW4ndCBzaGFyZSBIVFRQMiBz
ZXNzaW9uKS4NCg0KUmVnYXJkcywNClJlc2hhZC4NCg0KICAgIA0KICAgIENoZWVycw0KICAgIA0K
ICAgIE1hZ251cyBXZXN0ZXJsdW5kDQogICAgDQoNCg==


From nobody Fri May 24 02:56:43 2019
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7516A120074 for ; Fri, 24 May 2019 02:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv_1WBhERSPw for ; Fri, 24 May 2019 02:56:38 -0700 (PDT)
Received: from mail.myfast.site (mail.myfast.site [81.19.215.14]) (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 1E67D120045 for ; Fri, 24 May 2019 02:56:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pCLiS4KeG4luJdrKkadE9mGvg83wD0FOiFMSw2WZ47M=; b=ahiKdUagmsvOr+PimCLbVGr+O t/2z4vwrfiZdNOx1VxCx8NKP8acnfBo138G8AAAyY9TMcBaTMG3IvevyZ6b2UAbGqunYmXJ6g9/8s etVdT1Nr4uGMr6Wumzlw3KSuDabSbhp9uuySOVTVMgYLWsQTch7ipkHURb/pXQE6XU0RUxNazwa6b 9gFDql/PMhiO6NmD7OA/0bJOWrmuiOlPsYK+QH4x2lyTVlwrY2TUxTw6mJjYtwNQFiXvHN71shrgF /+rApnUaoMl/sd5xFgyA3n1fEgQYirWwL0vL8FXIsJUStvg+IMNRtm4Jdh8mcwDVE4r6ViI6zWfuf RUpSByV6Q==;
Received: from hansfords.plus.com ([84.92.116.209]:53807 helo=Vanguard) by mail.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hU6wD-004FM0-M6; Fri, 24 May 2019 10:56:35 +0100
From: 
To: "'Andy Bierman'" , "'Mahesh Jethanandani'" 
Cc: "'Kent Watsen'" , 
References:  <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com>   <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com>  <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com>  <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com> 
In-Reply-To: 
Date: Fri, 24 May 2019 10:56:33 +0100
Message-ID: <00d101d51216$f807d120$e8177360$@hansfords.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D2_01D5121F.59D38C20"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEklGrOMV/w/jlFXeDl9P6RpktVAwMZoGKtAkTE2WoB6D+fYgJpYrUFAgVhjmgB0JVjYQJ8PT8lAReGQGcB8z3QDQIlgQtrpzFlk1A=
Content-Language: en-gb
X-Antivirus: Avast (VPS 190524-0, 24/05/2019), Outbound message
X-Antivirus-Status: Clean
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mail.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: mail.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: mail.myfast.site: jonathan@hansfords.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [netconf] RFC 6241 Ambiguity
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 May 2019 09:56:42 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00D2_01D5121F.59D38C20
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

 

Apologies for the delay in responding.

 

The reason for the errata I have raised on persistent confirmed commits is =
because RFC 6241 seems to me to be ambiguous. For example, section 8.4.1 st=
ates, =E2=80=9CIf the session issuing the confirmed commit is terminated fo=
r any reason before the confirm timeout expires, the server MUST restore th=
e configuration to its state before the confirmed commit was issued, unless=
 the confirmed commit also included a  element.=E2=80=9D To my min=
d, the reasons for terminating the session include the client issuing a , another client issuing a  on the session in que=
stion, a network failure, the client rebooting, and the server rebooting. Y=
et in the next paragraph it states, =E2=80=9CIf the device reboots for any =
reason before the confirm timeout expires, the server MUST restore the conf=
iguration to its state before the confirmed commit was issued.=E2=80=9D So =
does the second paragraph overrule the first when the session terminates du=
e to the device rebooting? If so, what is the reason why a persistent confi=
rmed commit cannot persist beyond a device reboot but it can for all other =
cases of session termination? And why does the RFC state about the persist =
parameter on page 101, =E2=80=9CThis parameter is used to make a confirmed =
commit persistent.  A persistent confirmed commit is not aborted if the NET=
CONF session terminates.  The only way to abort a persistent confirmed comm=
it is to let the timer expire, or to use the  operation=E2=
=80=9D? The RFC could really do with making it clearer under what circumsta=
nces a persistent confirmed commit is aborted, hence my errata. If I have g=
ot them wrong, I apologise.

 

Re Kent=E2=80=99s point about section 8.4 overriding section 7.8 behaviour.=
 Is that a common approach to RFCs, that subsequent sections can overrule p=
rior sections without needing to add clarity in those prior sections? If so=
, why are there so many forward references to capabilities in section 7?

 

With the diffs in the errata, I am unclear what happens when reporting an e=
rror in an existing erratum. If the resultant erratum replaces the previous=
 one, it would make sense to provide the diff against the original text. If=
 it becomes an additional erratum, it would make sense to provide the diff =
against the previous erratum.

 

Re Andy=E2=80=99s point about the text on  in section 7.9 bei=
ng ambiguous, that is why I proposed the change. However, if that change is=
 not correct, then surely we still need an erratum to clarify what the inte=
nt truly is. Clearly Andy is of the opinion an erratum is not sufficient an=
d this needs to be fixed in a new version of the protocol which is why I=E2=
=80=99m confused as to why he doesn=E2=80=99t want to open this as a netcon=
f-next issue.

 

For the work we are currently undertaking, persistent confirmed commits cou=
ld be very useful. But if the RFC is ambiguous, errata cannot fix it and it=
 isn=E2=80=99t a netconf-next issue we will have to remove support for it. =
But if that is the case then presumably we should not support any of :confi=
rmed-commit:1.1.

 

Jonathan

 

From: netconf  On Behalf Of Andy Bierman
Sent: 16 May 2019 20:11
To: Mahesh Jethanandani 
Cc: Kent Watsen ; netconf@ietf.org
Subject: Re: [netconf] RFC 6241 Ambiguity

 

 

 

On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandani  > wrote:

Hi Andy,





On May 16, 2019, at 10:02 AM, Andy Bierman  > wrote:

 

 

 

On Wed, May 15, 2019 at 2:48 PM Kent Watsen  > wrote:

 





I don't think Erratum 5397 should be deleted. Though the original section 7=
=2E8 makes no mention of confirmed commits, section 7.9 does, but does not =
differentiate between a vanilla confirmed commit and a persistent confirmed=
 commit. Since a persistent confirmed commit is still a type of confirmed c=
ommit, without clarification the second paragraph of the description would =
seem to apply. 

 

I would agree.

 

 

7.8 does not say anything about the  is for the
session that started a confirmed commit or extended a confirmed commmit.
It could be interpreted to mean any kill-session for any session causes
a confirmed commit to be rolled back.  The text below is so ambiguous it

is not even clear the  has to be for an existing session,




      If a NETCONF server receives a  request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

 

 

While the original text in 7.8 was ambiguous, Erratum 5397 does seem to cla=
rify that the  (not 
   element.

 

IMO this text overrides the close-session and kill-session text.

 

 

 

      If a NETCONF server receives a  request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a 
      element.

That is why I agree that Erratum 5397 should not be deleted, but should be =
modified to the text suggested by Jonathan.

 

 

This makes no operational sense if the  parameter was used.

 

 

 

It's a minor point, but I could argue, as I wrote before, that such clarifi=
cations in 7.x are unnecessary because 8.4 provides overrides.   I prefer l=
ess text because it's easier to get right (wit this is at least the 3rd tim=
e Jonathan is at this now).  However "unnecessary" doesn't mean "wrong" and=
 since we've already stepped in it, getting the 7.x errata right might be e=
asier than getting 8.4 right.

 

 

 

8.4 para 3 says the confirmed commit is not tied to a session if the persis=
t/persist0id mechanism is used.

 

   If the  element is not given in the confirmed commit
   operation, any follow-up commit and the confirming commit MUST be
   issued on the same session that issued the confirmed commit.  If the
    element is given in the confirmed  operation, a
   follow-up commit and the confirming commit can be given on any
   session, and they MUST include a  element with a value
   equal to the given value of the  element.

 

The problematic text is actually in 

 

8.4.4.1.  
 
   Description:
 
         Cancels an ongoing confirmed commit.  If the 
         parameter is not given, the  operation MUST be
         issued on the same session that issued the confirmed commit.
 

In order to cancel a confirmed commit (belonging to another client, i.e
the persist-id is not known), the client issues a  for
any random or non-existent session.  It would make more sense to issue a 

(maybe require superuser) instead. The access control policy for 

is the wrong way to configure access to cancelling a confirmed commit.

 

IMO these procedures are not well designed or documented, and an Errata can=
not

be used to fix it -- a new version of the protocol should fix it, in which =
WG and IETF consensus

is reached for the selected solution.

 

Do you want to open this as a netconf-next issue?





 

 

not really

 

 





 





With the diff, should that be against the original text or the original err=
atum?

 

The diff is building on top of the original erratum. I would think a diff w=
=2Er.t. to the original erratum would make sense.

 

It depends, are you correcting the earlier errata or filing a new one?   Re=
gardless, I expressed a diff for what I think the text should be (which you=
 didn't comment on); how that is translated is up to you.

 

 

Kent // contributor

 

 

Andy

 

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

 

Mahesh Jethanandani

mjethanandani@gmail.com  

 

 

 

 

Andy

 

 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

------=_NextPart_000_00D2_01D5121F.59D38C20
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi,
 
Apologies for the=
 delay in responding.
 
The reason for the errata =
I have raised on persistent confirmed commits is because RFC 6241 seems to =
me to be ambiguous. For example, section 8.4.1 states, =E2=80=9CIf the sess=
ion issuing the confirmed commit is terminated for any reason before the co=
nfirm timeout expires, the server MUST restore the configuration to its sta=
te before the confirmed commit was issued, unless the confirmed commit also=
 included a <persist> element.=E2=80=9D To my mind, the reasons for t=
erminating the session include the client issuing a <close-session>, =
another client issuing a <kill-session> on the session in question, a=
 network failure, the client rebooting, and the server rebooting. Yet in th=
e next paragraph it states, =E2=80=9CIf the device reboots for any reason b=
efore the confirm timeout expires, the server MUST restore the configuratio=
n to its state before the confirmed commit was issued.=E2=80=9D So does the=
 second paragraph overrule the first when the session terminates due to the=
 device rebooting? If so, what is the reason why a persistent confirmed com=
mit cannot persist beyond a device reboot but it can for all other cases of=
 session termination? And why does the RFC state about the persist paramete=
r on page 101, =E2=80=9CThis parameter is used to make a confirmed commit p=
ersistent.=C2=A0 A persistent confirmed commit is not aborted if the NETCON=
F session terminates.=C2=A0 The only way to abort a persistent confirmed co=
mmit is to let the timer expire, or to use the <cancel-commit> operat=
ion=E2=80=9D? The RFC could really do with making it clearer under what cir=
cumstances a persistent confirmed commit is aborted, hence my errata. If I =
have got them wrong, I apologise.
 
Re Kent=E2=80=
=99s point about section 8.4 overriding section 7.8 behaviour. Is that a co=
mmon approach to RFCs, that subsequent sections can overrule prior sections=
 without needing to add clarity in those prior sections? If so, why are the=
re so many forward references to capabilities in section 7?
=
 
With the diffs in the errata, I am unclear what happens when re=
porting an error in an existing erratum. If the resultant erratum replaces =
the previous one, it would make sense to provide the diff against the origi=
nal text. If it becomes an additional erratum, it would make sense to provi=
de the diff against the previous erratum.
 
Re And=
y=E2=80=99s point about the text on <kill-session> in section 7.9 bei=
ng ambiguous, that is why I proposed the change. However, if that change is=
 not correct, then surely we still need an erratum to clarify what the inte=
nt truly is. Clearly Andy is of the opinion an erratum is not sufficient an=
d this needs to be fixed in a new version of the protocol which is why I=E2=
=80=99m confused as to why he doesn=E2=80=99t want to open this as a netcon=
f-next issue.
 
For the work we are currently unde=
rtaking, persistent confirmed commits could be very useful. But if the RFC =
is ambiguous, errata cannot fix it and it isn=E2=80=99t a netconf-next issu=
e we will have to remove support for it. But if that is the case then presu=
mably we should not support any of :confirmed-commit:1.1.=

&n=
bsp;
Jonathan
 
From: netconf <ne=
tconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent:=
 16 May 2019 20:11
To: Mahesh Jethanandani <mjethanandani@gmai=
l.com>
Cc: Kent Watsen <kent@watsen.net>; netconf@ietf.o=
rg
Subject: Re: [netconf] RFC 6241 Ambiguity
 
<=
o:p> 
 
On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandan=
i <mjethanandani@gmail.com> wrote:
Hi Andy,


 
 
<=
/div>
 
On Wed, May 15, 2019 at 2:48 PM Kent Watsen <kent@watsen.net> wrote:
<=
/div>
 


<=
/p>
I don't think Erratum 5397 should be deleted. Though the original =
section 7.8 makes no mention of confirmed commits, section 7.9 does, but do=
es not differentiate between a vanilla confirmed commit and a persistent co=
nfirmed commit. Since a persistent confirmed commit is still a type of conf=
irmed commit, without clarification the second paragraph of the description=
 would seem to apply. 
<=
div>
 
I =
would agree.
 
 
7.8 does not s=
ay anything about the <kill-session> is for the
session that start=
ed a confirmed commit or extended a confirmed commmit.
It could be inter=
preted to mean any kill-session for any session causes
a confirmed commi=
t to be rolled back.  The text below is so ambiguous it
=

is not even clear the <kill-session> =
has to be for an existing session,


=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 If a NETCONF server receives a <kill-session> r=
equest while
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 processing=
 a confirmed commit (Section 8.4), it MUST restore the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configuration to its state before the confi=
rmed commit was issued.
 
 =

While the original text in 7.8 was amb=
iguous, Erratum 5397 does seem to clarify that the <close-session> (n=
ot <kill-session), is for the session in question, and not any session.<=
o:p>
 
 
=

I do not agree that close-session overrides the text i=
n sec 8.4 supports this procedure.
It also makes no sense from an operational POV, since dropping the se=
ssion
(without a close-sessio=
n) does not have this affect :
 


=C2=A0=C2=A0 If the session issuing the confirmed commit is te=
rminated for any
=C2=A0=C2=A0 reason before t=
he confirm timeout expires, the server MUST restore
=

=C2=A0=C2=A0 the configuration to its stat=
e before the confirmed commit was
=C2=A0=C2=A0 issued, unless the confirmed commit also i=
ncluded a <persist>
=C2=A0=C2=A0 element.<=
o:p>
 
IMO this text overrides the close-session and kill-se=
ssion text.
 =

 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a NETCONF server receives a <clos=
e-session> request while
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 processing a con=
firmed commit (Section 8.4) for that session, it
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 MUST restore the configuration to its state before the confirmed
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 commit was issued unless the confirmed commit i=
ncluded a <persist>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 element.

That is why I agree that Erratum 53= 97 should not be deleted, but should be modified to the text suggested by J= onathan.

 

 =

This makes no operational sense if the = <persist> parameter was used.

 

 

 

It's a mino= r point, but I could argue, as I wrote before, that such clarifications in = 7.x are unnecessary because 8.4 provides overrides.   I prefer less te= xt because it's easier to get right (wit this is at least the 3rd time Jona= than is at this now).  However "unnecessary" doesn't mean &q= uot;wrong" and since we've already stepped in it, getting the 7.x erra= ta right might be easier than getting 8.4 right.

<= p class=3DMsoNormal> 

 

 

8.4 para 3 says the c= onfirmed commit is not tied to a session if the persist/persist0id mechanis= m is used.

 <= /p>

=C2=A0=C2=A0 If the <p=
ersist> element is not given in the confirmed commit
=C2=A0=C2=A0 operation, any follow-up commit and the confirming commit MU= ST be
=C2=A0=C2=A0 issued on the same session that iss=
ued the confirmed commit.=C2=A0 If the
=C2=A0=C2=A0 &l=
t;persist> element is given in the confirmed <commit> operation, a=

=C2=A0=C2=A0 follow-up commit and the confirming comm=
it can be given on any
=C2=A0=C2=A0 session, and they =
MUST include a <persist-id> element with a value
=C2=A0=C2=A0 equal to the given value of the <persist> element.=

 

The problematic text is actually in <cancel_commit= >

 

8.4.4.1.=C2=A0 <cancel-commi=
t>
 
=C2=A0=C2=A0 Descrip=
tion:
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cancels an ongoing confirmed commit.=C2=A0 I=
f the <persist-id>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 parameter is not given, the <cancel-commit> ope=
ration MUST be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 issued on the same session that issued the confirmed commit.=

 

In order to cancel a confirmed commit (belonging to anothe= r client, i.e
the persist-id is not known), the client issues a <kill= -session> for
any random or non-existent session.  It would make= more sense to issue a <cancel-commit>

(maybe require superuser) instead. The access control polic= y for <kill-session>

is= the wrong way to configure access to cancelling a confirmed commit.

 

IMO these procedures are not well designed or documented,= and an Errata cannot

be used= to fix it -- a new version of the protocol should fix it, in which WG and = IETF consensus

is reached for= the selected solution.

=

 

D= o you want to open this as a netconf-next issue?

<= p class=3DMsoNormal>

&n= bsp;

 

not really

 

 



 


=

With the diff, should that be against the original t= ext or the original erratum?

=

 

T= he diff is building on top of the original erratum. I would think a diff w.= r.t. to the original erratum would make sense.

 

=

It depends, are you correcting the earlier errata or f= iling a new one?   Regardless, I expressed a diff for what I think the= text should be (which you didn't comment on); how that is translated is up= to you.

 

 

Kent // contributor

 

=  

Andy

 

__________________________= _____________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/m= ailman/listinfo/netconf

 

Mahesh Jethanandani

&nbs= p;

 

 

 

Andy

 

=

 


3D"" Virus-= free. www.avast.com
------=_NextPart_000_00D2_01D5121F.59D38C20-- From nobody Fri May 24 09:14:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B651B120301 for ; Fri, 24 May 2019 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 EjRCsvLXxvTj for ; Fri, 24 May 2019 09:14:13 -0700 (PDT) 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 7E9F5120190 for ; Fri, 24 May 2019 09:14:12 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id n134so7551233lfn.11 for ; Fri, 24 May 2019 09:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lLEylnWcW4iTB5z652RtaaiTatzDU05UdL1QqiZxbo8=; b=Fs2EcnjHxpHO6+AVbTBg+39iUDtV7MPG+95PAcJY6d5IfvjvTjjQ4/17KNfG2nPMj8 oVd8mC6vMinEf4MyvT/iC3ctShMPhjUGPJFrnoOQRO9X6jMaZqsDN6OBEbVoR84Ght19 fMdz60QGZ1xazpkNLgyTl2/3B40iWHKi2Z3j20pA9cP3VJUYx7RDyP0IIEG/tCSHT9O5 nspxeLpGckOykblIlq2YLhtU6Yp5snGufvUJN2Ff7r9vtx5FfzDHxRxrrlrarlodiMHz YMn0fiY2rhnk+HLAKc4tFcpB9HcoRrFUtTIabARncOvNu1DNXihL/Rgvtp7MwWPw4qVu eLwA== 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=lLEylnWcW4iTB5z652RtaaiTatzDU05UdL1QqiZxbo8=; b=Xd71RNuIPsDza+SuHlNj7utx4E8lItZJ+uH9ZXZBCVMJHRa65Gq8P5Af8xQeW6RABo E9ujdTpBPNZjV+EvdvEUNg4lbdNcxu9dt1PHC9ySQvstrwnz3+vquq3czP01Eky4eVWB ZMbBWcSMKh//gpqeR3Bz3HuBVq75Z9ej7uXTIgyU/F550pIFh+ycp3JSNIcWHMe227D7 kSxBaz+JfNr/bLucaFbnqLetq4oBpTVhw3XxM3ffdnhMNQv0kTNpAWg3pm4XdcFxCGk3 jj22uZ4wUrDtsQpWvzeewZZrhpVzBBGm1E2x0sIloxO1Ts8Ax7pHSlvBEaka9/fVhP7i PtOw== X-Gm-Message-State: APjAAAUNeNLNPz6iNoOOCcX+CGb55AI6NdoV/02yAH1W8IBFRpL3vCbs VAcb1HDhrfYPc0gyhFZdIfZo5Fy85lfrOtufqUEiwA== X-Google-Smtp-Source: APXvYqyqdp4vxmrHhw/cFZANKCB/gPFdWGw/L9X1jWv5/YZHKBO89pPftDm6dqYIB3PTm7ZGoq56UYb4HGi8PZSLuTg= X-Received: by 2002:ac2:46c3:: with SMTP id p3mr408257lfo.178.1558714449643; Fri, 24 May 2019 09:14:09 -0700 (PDT) MIME-Version: 1.0 References: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com> <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com> <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com> <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com> <00d101d51216$f807d120$e8177360$@hansfords.net> In-Reply-To: <00d101d51216$f807d120$e8177360$@hansfords.net> From: Andy Bierman Date: Fri, 24 May 2019 09:13:58 -0700 Message-ID: To: Jonathan Hansford Cc: Mahesh Jethanandani , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="00000000000013e4980589a47d7c" Archived-At: Subject: Re: [netconf] RFC 6241 Ambiguity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 16:14:17 -0000 --00000000000013e4980589a47d7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 24, 2019 at 2:56 AM wrote: > Hi, > > > > Apologies for the delay in responding. > > > > The reason for the errata I have raised on persistent confirmed commits i= s > because RFC 6241 seems to me to be ambiguous. For example, section 8.4.1 > states, =E2=80=9CIf the session issuing the confirmed commit is terminate= d for any > reason before the confirm timeout expires, the server MUST restore the > configuration to its state before the confirmed commit was issued, unless > the confirmed commit also included a element.=E2=80=9D To my mi= nd, the > reasons for terminating the session include the client issuing a > , another client issuing a on the session i= n > question, a network failure, the client rebooting, and the server > rebooting. Yet in the next paragraph it states, =E2=80=9CIf the device re= boots for > any reason before the confirm timeout expires, the server MUST restore th= e > configuration to its state before the confirmed commit was issued.=E2=80= =9D So does > the second paragraph overrule the first when the session terminates due t= o > the device rebooting? If so, what is the reason why a persistent confirme= d > commit cannot persist beyond a device reboot but it can for all other cas= es > of session termination? And why does the RFC state about the persist > parameter on page 101, =E2=80=9CThis parameter is used to make a confirme= d commit > persistent. A persistent confirmed commit is not aborted if the NETCONF > session terminates. The only way to abort a persistent confirmed commit = is > to let the timer expire, or to use the operation=E2=80=9D= ? The RFC > could really do with making it clearer under what circumstances a > persistent confirmed commit is aborted, hence my errata. If I have got th= em > wrong, I apologise. > > > > Re Kent=E2=80=99s point about section 8.4 overriding section 7.8 behaviou= r. Is > that a common approach to RFCs, that subsequent sections can overrule pri= or > sections without needing to add clarity in those prior sections? If so, w= hy > are there so many forward references to capabilities in section 7? > > > > With the diffs in the errata, I am unclear what happens when reporting an > error in an existing erratum. If the resultant erratum replaces the > previous one, it would make sense to provide the diff against the origina= l > text. If it becomes an additional erratum, it would make sense to provide > the diff against the previous erratum. > > > > Re Andy=E2=80=99s point about the text on in section 7.9 b= eing > ambiguous, that is why I proposed the change. However, if that change is > not correct, then surely we still need an erratum to clarify what the > intent truly is. Clearly Andy is of the opinion an erratum is not > sufficient and this needs to be fixed in a new version of the protocol > which is why I=E2=80=99m confused as to why he doesn=E2=80=99t want to op= en this as a > netconf-next issue. > > > > For the work we are currently undertaking, persistent confirmed commits > could be very useful. But if the RFC is ambiguous, errata cannot fix it a= nd > it isn=E2=80=99t a netconf-next issue we will have to remove support for = it. But if > that is the case then presumably we should not support any of > :confirmed-commit:1.1. > > > It seems that some text in RFC 4741 was not updated in RFC 6241 to support the addition of the and parameters. The intent of the authors (and WG) during development of RFC 6241 was that the parameter would decouple the confirmed commit procedure from the session that issued the confirmed commit operation. An errata is appropriate if the WG agrees (a) what text is incorrect (b) what is the intent of the incorrect text (c) what is the correct replacement text It does not seem that any of these conditions are met in this case so I guess it is a netconf-next issue. Jonathan > Andy > > > *From:* netconf *On Behalf Of *Andy Bierman > *Sent:* 16 May 2019 20:11 > *To:* Mahesh Jethanandani > *Cc:* Kent Watsen ; netconf@ietf.org > *Subject:* Re: [netconf] RFC 6241 Ambiguity > > > > > > > > On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Hi Andy, > > > > On May 16, 2019, at 10:02 AM, Andy Bierman wrote: > > > > > > > > On Wed, May 15, 2019 at 2:48 PM Kent Watsen wrote: > > > > > > I don't think Erratum 5397 should be deleted. Though the original section > 7.8 makes no mention of confirmed commits, section 7.9 does, but does not > differentiate between a vanilla confirmed commit and a persistent confirm= ed > commit. Since a persistent confirmed commit is still a type of confirmed > commit, without clarification the second paragraph of the description wou= ld > seem to apply. > > > > I would agree. > > > > > > 7.8 does not say anything about the is for the > session that started a confirmed commit or extended a confirmed commmit. > It could be interpreted to mean any kill-session for any session causes > a confirmed commit to be rolled back. The text below is so ambiguous it > > is not even clear the has to be for an existing session, > > > If a NETCONF server receives a request while > > processing a confirmed commit (Section 8.4), it MUST restore the > > configuration to its state before the confirmed commit was issued. > > > > > > While the original text in 7.8 was ambiguous, Erratum 5397 does seem to > clarify that the (not question, and not any session. > > > > > > I do not agree that close-session overrides the text in sec 8.4 supports > this procedure. > > It also makes no sense from an operational POV, since dropping the sessio= n > > (without a close-session) does not have this affect : > > > > > > If the session issuing the confirmed commit is terminated *for any* > > * reason* before the confirm timeout expires, the server MUST restore > > the configuration to its state before the confirmed commit was > > issued,* unless the confirmed commit also included a * > > * element.* > > > > IMO this text overrides the close-session and kill-session text. > > > > > > > > If a NETCONF server receives a request while > > processing a confirmed commit (Section 8.4) for that session, it > > MUST restore the configuration to its state before the confirmed > > commit was issued unless the confirmed commit included a > > element. > > That is why I agree that Erratum 5397 should not be deleted, but should b= e > modified to the text suggested by Jonathan. > > > > > > This makes no operational sense if the parameter was used. > > > > > > > > It's a minor point, but I could argue, as I wrote before, that such > clarifications in 7.x are unnecessary because 8.4 provides overrides. I > prefer less text because it's easier to get right (wit this is at least t= he > 3rd time Jonathan is at this now). However "unnecessary" doesn't mean > "wrong" and since we've already stepped in it, getting the 7.x errata rig= ht > might be easier than getting 8.4 right. > > > > > > > > 8.4 para 3 says the confirmed commit is not tied to a session if the > persist/persist0id mechanism is used. > > > > If the element is not given in the confirmed commit > > operation, any follow-up commit and the confirming commit MUST be > > issued on the same session that issued the confirmed commit. If the > > element is given in the confirmed operation, a > > follow-up commit and the confirming commit can be given on any > > session, and they MUST include a element with a value > > equal to the given value of the element. > > > > The problematic text is actually in > > > > 8.4.4.1. > > > > Description: > > > > Cancels an ongoing confirmed commit. If the > > parameter is not given, the operation MUST be > > issued on the same session that issued the confirmed commit. > > > > In order to cancel a confirmed commit (belonging to another client, i.e > the persist-id is not known), the client issues a for > any random or non-existent session. It would make more sense to issue a > > > (maybe require superuser) instead. The access control policy for > > > is the wrong way to configure access to cancelling a confirmed commit. > > > > IMO these procedures are not well designed or documented, and an Errata > cannot > > be used to fix it -- a new version of the protocol should fix it, in whic= h > WG and IETF consensus > > is reached for the selected solution. > > > > Do you want to open this as a netconf-next issue? > > > > > > > > not really > > > > > > > > > > > > With the diff, should that be against the original text or the original > erratum? > > > > The diff is building on top of the original erratum. I would think a diff > w.r.t. to the original erratum would make sense. > > > > It depends, are you correcting the earlier errata or filing a new one? > Regardless, I expressed a diff for what I think the text should be (which > you didn't comment on); how that is translated is up to you. > > > > > > Kent // contributor > > > > > > Andy > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > Andy > > > > > > > Virus-free. > www.avast.com > > <#m_-270464312496652421_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > --00000000000013e4980589a47d7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 24, 2019 at 2:56 AM <<= a href=3D"mailto:jonathan@hansfords.net">jonathan@hansfords.net> wro= te:

Hi,

<= u>=C2=A0

Apologies for th= e delay in responding.

=C2=A0

The reason for= the errata I have raised on persistent confirmed commits is because RFC 62= 41 seems to me to be ambiguous. For example, section 8.4.1 states, =E2=80= =9CIf the session issuing the confirmed commit is terminated for any reason= before the confirm timeout expires, the server MUST restore the configurat= ion to its state before the confirmed commit was issued, unless the confirm= ed commit also included a <persist> element.=E2=80=9D To my mind, the= reasons for terminating the session include the client issuing a <close= -session>, another client issuing a <kill-session> on the session = in question, a network failure, the client rebooting, and the server reboot= ing. Yet in the next paragraph it states, =E2=80=9CIf the device reboots fo= r any reason before the confirm timeout expires, the server MUST restore th= e configuration to its state before the confirmed commit was issued.=E2=80= =9D So does the second paragraph overrule the first when the session termin= ates due to the device rebooting? If so, what is the reason why a persisten= t confirmed commit cannot persist beyond a device reboot but it can for all= other cases of session termination? And why does the RFC state about the p= ersist parameter on page 101, =E2=80=9CThis parameter is used to make a con= firmed commit persistent.=C2=A0 A persistent confirmed commit is not aborte= d if the NETCONF session terminates.=C2=A0 The only way to abort a persiste= nt confirmed commit is to let the timer expire, or to use the <cancel-co= mmit> operation=E2=80=9D? The RFC could really do with making it clearer= under what circumstances a persistent confirmed commit is aborted, hence m= y errata. If I have got them wrong, I apologise.

=C2=A0

Re Kent=E2=80=99s point about section 8.4 overriding section 7.= 8 behaviour. Is that a common approach to RFCs, that subsequent sections ca= n overrule prior sections without needing to add clarity in those prior sec= tions? If so, why are there so many forward references to capabilities in s= ection 7?

=C2= =A0

With the diffs in the err= ata, I am unclear what happens when reporting an error in an existing errat= um. If the resultant erratum replaces the previous one, it would make sense= to provide the diff against the original text. If it becomes an additional= erratum, it would make sense to provide the diff against the previous erra= tum.

=C2=A0<= /u>

Re Andy=E2=80=99s point about th= e text on <kill-session> in section 7.9 being ambiguous, that is why = I proposed the change. However, if that change is not correct, then surely = we still need an erratum to clarify what the intent truly is. Clearly Andy = is of the opinion an erratum is not sufficient and this needs to be fixed i= n a new version of the protocol which is why I=E2=80=99m confused as to why= he doesn=E2=80=99t want to open this as a netconf-next issue.

=C2=A0

For the work we are currently undertaking, persis= tent confirmed commits could be very useful. But if the RFC is ambiguous, e= rrata cannot fix it and it isn=E2=80=99t a netconf-next issue we will have = to remove support for it. But if that is the case then presumably we should= not support any of :confirmed-commit:1.1.

=C2=A0

=

It seems that some text in RFC 4741 was not u= pdated in RFC 6241 to
support the addition of the <persist>= and <persist-id> parameters.

The intent of = the authors (and WG) during development of RFC 6241 was
that the = <persist> parameter would decouple the confirmed commit procedure
from the session that issued the confirmed commit operation.

An errata is appropriate if the WG agrees
=C2= =A0 =C2=A0(a) what text is incorrect
=C2=A0 =C2=A0(b) what is the= intent of the incorrect text
=C2=A0 =C2=A0(c) what is the correc= t replacement text

It does not seem that any of th= ese conditions are met in this case so I guess it
is a netconf-ne= xt issue.


Jonathan


<= /div>
Andy
=C2=A0

=C2=A0

= From: netconf <<= a href=3D"mailto:netconf-bounces@ietf.org" target=3D"_blank">netconf-bounce= s@ietf.org> On Behalf Of Andy Bierman
Sent: 16 May = 2019 20:11
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc= : Kent Watsen <= kent@watsen.net>; netconf@ietf.org
Subject: Re: [netconf] RFC 6241 Ambiguit= y

=C2=A0

=C2=A0

=C2=A0

On Thu, M= ay 16, 2019 at 11:50 AM Mahesh Jethanandani <mjethanandani@gmail.com> wrote:=

Hi = Andy,



On May 16, 2019, at 10:02 AM, Andy Bierman <andy@yumaworks.com> wrote:<= /u>

=C2=A0

=C2=A0

=C2=A0

On Wed, Ma= y 15, 2019 at 2:48 PM Kent Watsen <kent@watsen.net> wrote:

=C2=A0

=



I don't think = Erratum 5397 should be deleted. Though the original section 7.8 makes no me= ntion of confirmed commits, section 7.9 does, but does not differentiate be= tween a vanilla confirmed commit and a persistent confirmed commit. Since a= persistent confirmed commit is still a type of confirmed commit, without c= larification the second paragraph of the description would seem to apply.= =C2=A0

=C2=A0

I would agree= .

=C2=A0

=C2=A0

7.8 does no= t say anything about the <kill-session> is for the
session that st= arted a confirmed commit or extended a confirmed commmit.
It could be in= terpreted to mean any kill-session for any session causes
a confirmed co= mmit to be rolled back.=C2=A0 The text below is so ambiguous it

is not even clear the <kill-sess= ion> has to be for an existing session,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a NETCONF server receives a <kill-se= ssion> request while
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 processing a confirmed commit (Section 8.4), it MUST restore the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configuration to its state=
 before the confirmed commit was issued.

=C2=A0

=C2=A0

While = the original text in 7.8 was ambiguous, Erratum 5397 does seem to clarify t= hat the <close-session> (not <kill-session), is for the session in= question, and not any session.

=C2=A0

=C2=A0

I do no= t agree that close-session overrides the text in sec 8.4 supports this proc= edure.

It also makes no = sense from an operational POV, since dropping the session

=

(without a close-session) does not have t= his affect :

=C2= =A0



=C2=A0=C2=A0 If the session issuing the confirmed commit is terminat=
ed for any
=C2=A0=C2=A0 reason before the =
confirm timeout expires, the server MUST restore
= 
=C2=A0=C2=A0 the configuration to its stat=
e before the confirmed commit was
=C2=A0=C2=A0 issued, unless the confirmed commit also =
included a <persist>
=C2=A0=C2=A0 element.

=C2=A0

IMO this text overrides the close-sessi= on and kill-session text.

=C2=A0

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a NETCONF server receives a=
 <close-session> request while
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 processing a confirmed commit (Section 8.4) for that session, it=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST restore the configuration to its sta=
te before the confirmed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 commit was =
issued unless the confirmed commit included a <persist>=

=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 element.

That is why I agree that Erratum 5397 should not be deleted= , but should be modified to the text suggested by Jonathan.

=C2=A0

=C2=A0

<= div>

This makes no operational sense if the <persi= st> parameter was used.

=C2=A0

=C2=A0

= =C2=A0

It's a minor point, but I could argue, as I wrote befor= e, that such clarifications in 7.x are unnecessary because 8.4 provides ove= rrides. =C2=A0 I prefer less text because it's easier to get right (wit= this is at least the 3rd time Jonathan is at this now).=C2=A0 However &quo= t;unnecessary" doesn't mean "wrong" and since we've = already stepped in it, getting the 7.x errata right might be easier than ge= tting 8.4 right.

= =C2=A0

=C2=A0

=C2=A0=

8.4 para 3 says the confirmed com= mit is not tied to a session if the persist/persist0id mechanism is used.

=C2=A0

<= /div>
=C2=A0=C2=A0 If the <persi=
st> element is not given in the confirmed commit
=C2=A0=C2=A0 operation, any follow-up commit and the confirming commit MUS= T be
=C2=A0=C2=A0 issued on the same session that i=
ssued the confirmed commit.=C2=A0 If the
=C2=A0=C2=
=A0 <persist> element is given in the confirmed <commit> operat=
ion, a
=C2=A0=C2=A0 follow-up commit and the confir=
ming commit can be given on any
=C2=A0=C2=A0 sessio=
n, and they MUST include a <persist-id> element with a value
=C2=A0=C2=A0 equal to the given value of the <persist>=
; element.

=C2=A0

The problematic text is actu= ally in <cancel_commit>

=C2=A0

8.4.4.1.=C2=A0 <cancel-commit>
=C2=
=A0
=C2=A0=C2=A0 Description:
<=
/u>=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Cancels an ongoing confirmed commit.=C2=A0 If the <persist-id>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 paramet=
er is not given, the <cancel-commit> operation MUST be<=
/pre>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 issued on the sa=
me session that issued the confirmed commit.
=C2=A0
=
In order to cancel a confirmed commit (belonging to another client, i.e
=
the persist-id is not known), the client issues a <kill-session> for<=
br>any random or non-existent session.=C2=A0 It would make more sense to is=
sue a <cancel-commit>

(maybe require superuser) instead. The access control policy for <ki= ll-session>

is the wr= ong way to configure access to cancelling a confirmed commit.=

=C2=A0

IMO these procedures are not well designed or document= ed, and an Errata cannot

be used to fix it -- a new version of the protocol should fix it, in which= WG and IETF consensus

i= s reached for the selected solution.

=C2=A0

<= p class=3D"MsoNormal">Do you want to open this as a netconf-next issue?<= /u>



<= blockquote style=3D"margin-top:5pt;margin-bottom:5pt">
<= p class=3D"MsoNormal">=C2=A0

=C2=A0<= u>

not really

=C2=A0

=C2=A0



=C2=A0


<= br>

With the diff, should that be against the orig= inal text or the original erratum?

=C2=A0

The diff is building on top of the original erratum. I would= think a diff w.r.t. to the original erratum would make sense.

=C2= =A0

It depends, are you correct= ing the earlier errata or filing a new one? =C2=A0 Regardless, I expressed = a diff for what I think the text should be (which you didn't comment on= ); how that is translated is up to you.

=C2=A0

<= u>=C2=A0

Kent // contribut= or

=C2=A0

=C2=A0

<= /div>

Andy

=C2=A0

_______________________________________________
netconf = mailing list
netco= nf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

=C2=A0

<= /div>

3D"" Virus-free. www.avast.com
<= /div> --00000000000013e4980589a47d7c-- From nobody Fri May 24 09:22:19 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02D0120305 for ; Fri, 24 May 2019 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHEeD9K3LB2J for ; Fri, 24 May 2019 09:22:14 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60124.outbound.protection.outlook.com [40.107.6.124]) (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 C6288120304 for ; Fri, 24 May 2019 09:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E2LX/c2547/umb3zSo8GyW3EwKQzvg83y/ijzaz0frk=; b=MPfxDFNp6hYP31gEYwE12+Zx4YN2jD41z16V4TD99QQs1BXkREHi+NxmM+CLgStEkFLq16uPBCrR5/9Fkg2z6l+nAsLgT+FPr2cB8FssEPnq3jjfNaB4DfJmDQ870v+dOf/L7mYiHuKhU6PRUoE/eGz9IsrFbw1yavIVL3CXPq8= Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB4269.eurprd07.prod.outlook.com (20.176.6.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.8; Fri, 24 May 2019 16:22:10 +0000 Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d%7]) with mapi id 15.20.1943.007; Fri, 24 May 2019 16:22:10 +0000 From: tom petch To: "jonathan@hansfords.net" , 'Andy Bierman' , 'Mahesh Jethanandani' CC: 'Kent Watsen' , "netconf@ietf.org" Thread-Topic: [netconf] RFC 6241 Ambiguity Thread-Index: AQHVEkwxbmbSabcwjUS9zmsfFcmOnA== Date: Fri, 24 May 2019 16:22:10 +0000 Message-ID: <009401d5124c$486e4ba0$4001a8c0@gateway.2wire.net> References: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com> <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com> <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com> <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com> <00d101d51216$f807d120$e8177360$@hansfords.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0059.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::23) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a23f9c81-a59f-45ef-e3ac-08d6e063f8a0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4269; x-ms-traffictypediagnostic: VI1PR07MB4269: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0047BC5ADE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(136003)(39860400002)(346002)(199004)(189003)(13464003)(446003)(476003)(71200400001)(71190400001)(486006)(53546011)(2501003)(4720700003)(73956011)(66476007)(66556008)(64756008)(66946007)(66446008)(110136005)(7736002)(8676002)(44736005)(68736007)(6436002)(305945005)(229853002)(86362001)(81166006)(81156014)(26005)(102836004)(5660300002)(1556002)(6486002)(186003)(86152003)(2906002)(14496001)(25786009)(966005)(14444005)(478600001)(256004)(50226002)(8936002)(316002)(54906003)(386003)(6506007)(62236002)(6116002)(3846002)(4326008)(44716002)(84392002)(14454004)(52116002)(6246003)(76176011)(81686011)(61296003)(81816011)(6306002)(6512007)(99286004)(53936002)(66066001)(9686003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4269; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: o/m09V40+J5e869j4U0s05PS1Ph2aFOlG5FFMLOYJ/foo+naWjZT55kQ5MsCP8l6p0DyNrY9ZszXNgEAB3FgpsrOZQ8V8D5Cu4Oy33wKUwGkHB1kL2ypza1X5jrnzP6Krdh5AeKszdIkcolqyAhIJ/xDaf07bl+dWGX2AawChoQoy2OE278O4KkiZlJ8ea2oTJCx81zWP7371QLM+tgDRrWRUGVvVZvBgHnw+db5YddCRt2IoFqQ0M6oj86B71uV7NaZ/HP9m5Un/JxdXx9VCMoBwgYivi+1yz6Oq8pXCzTOQeNYQT4t0dn6oFvG1qa+EIpnY0HIKHLAhEluCAr2g8s2PFiGyK7fzS5wlfABC4G/zlfu5o0IZ/msRCjskt0EAQZAU9UtMb3nX0SJurXG0RxzsnOv+lRTNQfe/Hzj7zg= Content-Type: text/plain; charset="utf-8" Content-ID: <3EF8CA0817DB4841AD09452C0AACC3C7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: a23f9c81-a59f-45ef-e3ac-08d6e063f8a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2019 16:22:10.1369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ietfc@btconnect.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4269 Archived-At: Subject: Re: [netconf] RFC 6241 Ambiguity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 16:22:18 -0000 aW5saW5lDQoNClRvbSBQZXRjaA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9t OiA8am9uYXRoYW5AaGFuc2ZvcmRzLm5ldD4NClNlbnQ6IEZyaWRheSwgTWF5IDI0LCAyMDE5IDEw OjU2IEFNDQoNCkhpLA0KDQpBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiByZXNwb25kaW5nLg0K DQpUaGUgcmVhc29uIGZvciB0aGUgZXJyYXRhIEkgaGF2ZSByYWlzZWQgb24gcGVyc2lzdGVudCBj b25maXJtZWQgY29tbWl0cw0KaXMgYmVjYXVzZSBSRkMgNjI0MSBzZWVtcyB0byBtZSB0byBiZSBh bWJpZ3VvdXMuIEZvciBleGFtcGxlLCBzZWN0aW9uDQo4LjQuMSBzdGF0ZXMsIOKAnElmIHRoZSBz ZXNzaW9uIGlzc3VpbmcgdGhlIGNvbmZpcm1lZCBjb21taXQgaXMgdGVybWluYXRlZA0KZm9yIGFu eSByZWFzb24gYmVmb3JlIHRoZSBjb25maXJtIHRpbWVvdXQgZXhwaXJlcywgdGhlIHNlcnZlciBN VVNUDQpyZXN0b3JlIHRoZSBjb25maWd1cmF0aW9uIHRvIGl0cyBzdGF0ZSBiZWZvcmUgdGhlIGNv bmZpcm1lZCBjb21taXQgd2FzDQppc3N1ZWQsIHVubGVzcyB0aGUgY29uZmlybWVkIGNvbW1pdCBh bHNvIGluY2x1ZGVkIGEgPHBlcnNpc3Q+IGVsZW1lbnQu4oCdDQpUbyBteSBtaW5kLCB0aGUgcmVh c29ucyBmb3IgdGVybWluYXRpbmcgdGhlIHNlc3Npb24gaW5jbHVkZSB0aGUgY2xpZW50DQppc3N1 aW5nIGEgPGNsb3NlLXNlc3Npb24+LCBhbm90aGVyIGNsaWVudCBpc3N1aW5nIGEgPGtpbGwtc2Vz c2lvbj4gb24NCnRoZSBzZXNzaW9uIGluIHF1ZXN0aW9uLCBhIG5ldHdvcmsgZmFpbHVyZSwgdGhl IGNsaWVudCByZWJvb3RpbmcsIGFuZA0KdGhlIHNlcnZlciByZWJvb3RpbmcuIFlldCBpbiB0aGUg bmV4dCBwYXJhZ3JhcGggaXQgc3RhdGVzLCDigJxJZiB0aGUNCmRldmljZSByZWJvb3RzIGZvciBh bnkgcmVhc29uIGJlZm9yZSB0aGUgY29uZmlybSB0aW1lb3V0IGV4cGlyZXMsIHRoZQ0Kc2VydmVy IE1VU1QgcmVzdG9yZSB0aGUgY29uZmlndXJhdGlvbiB0byBpdHMgc3RhdGUgYmVmb3JlIHRoZSBj b25maXJtZWQNCmNvbW1pdCB3YXMgaXNzdWVkLuKAnSBTbyBkb2VzIHRoZSBzZWNvbmQgcGFyYWdy YXBoIG92ZXJydWxlIHRoZSBmaXJzdCB3aGVuDQp0aGUgc2Vzc2lvbiB0ZXJtaW5hdGVzIGR1ZSB0 byB0aGUgZGV2aWNlIHJlYm9vdGluZz8gSWYgc28sIHdoYXQgaXMgdGhlDQpyZWFzb24gd2h5IGEg cGVyc2lzdGVudCBjb25maXJtZWQgY29tbWl0IGNhbm5vdCBwZXJzaXN0IGJleW9uZCBhIGRldmlj ZQ0KcmVib290IGJ1dCBpdCBjYW4gZm9yIGFsbCBvdGhlciBjYXNlcyBvZiBzZXNzaW9uIHRlcm1p bmF0aW9uPyBBbmQgd2h5DQpkb2VzIHRoZSBSRkMgc3RhdGUgYWJvdXQgdGhlIHBlcnNpc3QgcGFy YW1ldGVyIG9uIHBhZ2UgMTAxLCDigJxUaGlzDQpwYXJhbWV0ZXIgaXMgdXNlZCB0byBtYWtlIGEg Y29uZmlybWVkIGNvbW1pdCBwZXJzaXN0ZW50LiAgQSBwZXJzaXN0ZW50DQpjb25maXJtZWQgY29t bWl0IGlzIG5vdCBhYm9ydGVkIGlmIHRoZSBORVRDT05GIHNlc3Npb24gdGVybWluYXRlcy4gIFRo ZQ0Kb25seSB3YXkgdG8gYWJvcnQgYSBwZXJzaXN0ZW50IGNvbmZpcm1lZCBjb21taXQgaXMgdG8g bGV0IHRoZSB0aW1lcg0KZXhwaXJlLCBvciB0byB1c2UgdGhlIDxjYW5jZWwtY29tbWl0PiBvcGVy YXRpb27igJ0/IFRoZSBSRkMgY291bGQgcmVhbGx5DQpkbyB3aXRoIG1ha2luZyBpdCBjbGVhcmVy IHVuZGVyIHdoYXQgY2lyY3Vtc3RhbmNlcyBhIHBlcnNpc3RlbnQNCmNvbmZpcm1lZCBjb21taXQg aXMgYWJvcnRlZCwgaGVuY2UgbXkgZXJyYXRhLiBJZiBJIGhhdmUgZ290IHRoZW0gd3JvbmcsDQpJ IGFwb2xvZ2lzZS4NCg0KUmUgS2VudOKAmXMgcG9pbnQgYWJvdXQgc2VjdGlvbiA4LjQgb3ZlcnJp ZGluZyBzZWN0aW9uIDcuOCBiZWhhdmlvdXIuIElzDQp0aGF0IGEgY29tbW9uIGFwcHJvYWNoIHRv IFJGQ3MsIHRoYXQgc3Vic2VxdWVudCBzZWN0aW9ucyBjYW4gb3ZlcnJ1bGUNCnByaW9yIHNlY3Rp b25zIHdpdGhvdXQgbmVlZGluZyB0byBhZGQgY2xhcml0eSBpbiB0aG9zZSBwcmlvciBzZWN0aW9u cz8NCklmIHNvLCB3aHkgYXJlIHRoZXJlIHNvIG1hbnkgZm9yd2FyZCByZWZlcmVuY2VzIHRvIGNh cGFiaWxpdGllcyBpbg0Kc2VjdGlvbiA3Pw0KDQpXaXRoIHRoZSBkaWZmcyBpbiB0aGUgZXJyYXRh LCBJIGFtIHVuY2xlYXIgd2hhdCBoYXBwZW5zIHdoZW4gcmVwb3J0aW5nDQphbiBlcnJvciBpbiBh biBleGlzdGluZyBlcnJhdHVtLiBJZiB0aGUgcmVzdWx0YW50IGVycmF0dW0gcmVwbGFjZXMgdGhl DQpwcmV2aW91cyBvbmUsIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gcHJvdmlkZSB0aGUgZGlmZiBh Z2FpbnN0IHRoZQ0Kb3JpZ2luYWwgdGV4dC4gSWYgaXQgYmVjb21lcyBhbiBhZGRpdGlvbmFsIGVy cmF0dW0sIGl0IHdvdWxkIG1ha2Ugc2Vuc2UNCnRvIHByb3ZpZGUgdGhlIGRpZmYgYWdhaW5zdCB0 aGUgcHJldmlvdXMgZXJyYXR1bS4NCg0KPHRwPg0KDQpKb25hdGhhbg0KDQpUaGUgUkZDIEVkaXRv ciB3ZWJzaXRlIHNheXMNCg0KIFtOb3RlOiBUbyByZXBvcnQgYW4gZXJyb3IgaW4gYW4gZXhpc3Rp bmcgZXJyYXR1bSwgcGxlYXNlIGNvbnRhY3QgdGhlDQpSRkMgRWRpdG9yLl0NCg0Kd2hpY2ggc3Vn Z2VzdHMgdGhhdCB3ZSBoYXZlIGFuIGFkLWhvYyBwcm9jZXNzIGFuZCBubyBmb3JtYWwgcHJvY2Vk dXJlLg0KQXMgeWV0LCBJIGRvIG5vdCBzZWUgY29uc2Vuc3VzIGFzIHRvIHdoYXQgdGhlIHRvdGFs aXR5IG9mIHRoZSBjaGFuZ2VzIHRvDQp0aGUgUkZDIHNob3VsZCBiZSwgd2hpY2ggZm9yIG1lIGlz IHRoZSBzdGFydGluZyBwb2ludCwgYmVmb3JlIGNvbnRhY3RpbmcNCnRoZSBSRkMgRWRpdG9yIHRv IGluc3RpZ2F0ZSB0aGUgcHJvY2Vzcy4NCg0KT24gdGhlIG1vcmUgZ2VuZXJhbCBwb2ludCwgaWYg SSByZWFkIGEgZG9jdW1lbnQgZnJvbSBzdGFydCB0byBlbmQgYW5kDQpmaW5kIGxhdGVyIHNlY3Rp b25zIGNvbnRyYWRpY3RpbmcgZWFybGllciBvbmVzIEkgd291bGQgcmVnYXJkIHRoZQ0KZG9jdW1l bnQgYXMgZmxhd2VkLg0KDQpUb20gUGV0Y2gNCg0KDQoNClJlIEFuZHnigJlzIHBvaW50IGFib3V0 IHRoZSB0ZXh0IG9uIDxraWxsLXNlc3Npb24+IGluIHNlY3Rpb24gNy45IGJlaW5nDQphbWJpZ3Vv dXMsIHRoYXQgaXMgd2h5IEkgcHJvcG9zZWQgdGhlIGNoYW5nZS4gSG93ZXZlciwgaWYgdGhhdCBj aGFuZ2UgaXMNCm5vdCBjb3JyZWN0LCB0aGVuIHN1cmVseSB3ZSBzdGlsbCBuZWVkIGFuIGVycmF0 dW0gdG8gY2xhcmlmeSB3aGF0IHRoZQ0KaW50ZW50IHRydWx5IGlzLiBDbGVhcmx5IEFuZHkgaXMg b2YgdGhlIG9waW5pb24gYW4gZXJyYXR1bSBpcyBub3QNCnN1ZmZpY2llbnQgYW5kIHRoaXMgbmVl ZHMgdG8gYmUgZml4ZWQgaW4gYSBuZXcgdmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wNCndoaWNoIGlz IHdoeSBJ4oCZbSBjb25mdXNlZCBhcyB0byB3aHkgaGUgZG9lc27igJl0IHdhbnQgdG8gb3BlbiB0 aGlzIGFzIGENCm5ldGNvbmYtbmV4dCBpc3N1ZS4NCg0KIEZvciB0aGUgd29yayB3ZSBhcmUgY3Vy cmVudGx5IHVuZGVydGFraW5nLCBwZXJzaXN0ZW50IGNvbmZpcm1lZCBjb21taXRzDQpjb3VsZCBi ZSB2ZXJ5IHVzZWZ1bC4gQnV0IGlmIHRoZSBSRkMgaXMgYW1iaWd1b3VzLCBlcnJhdGEgY2Fubm90 IGZpeCBpdA0KYW5kIGl0IGlzbuKAmXQgYSBuZXRjb25mLW5leHQgaXNzdWUgd2Ugd2lsbCBoYXZl IHRvIHJlbW92ZSBzdXBwb3J0IGZvciBpdC4NCkJ1dCBpZiB0aGF0IGlzIHRoZSBjYXNlIHRoZW4g cHJlc3VtYWJseSB3ZSBzaG91bGQgbm90IHN1cHBvcnQgYW55IG9mDQo6Y29uZmlybWVkLWNvbW1p dDoxLjEuDQoNCkpvbmF0aGFuDQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogMTYgTWF5IDIwMTkgMjA6MTEN ClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCkNjOiBL ZW50IFdhdHNlbiA8a2VudEB3YXRzZW4ubmV0PjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtuZXRjb25mXSBSRkMgNjI0MSBBbWJpZ3VpdHkNCg0KT24gVGh1LCBNYXkgMTYsIDIwMTkg YXQgMTE6NTAgQU0gTWFoZXNoIEpldGhhbmFuZGFuaQ0KPG1qZXRoYW5hbmRhbmlAZ21haWwuY29t IDxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+ID4gd3JvdGU6DQoNCkhpIEFuZHksDQoN Ck9uIE1heSAxNiwgMjAxOSwgYXQgMTA6MDIgQU0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29y a3MuY29tDQo8bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4gPiB3cm90ZToNCg0KT24gV2VkLCBN YXkgMTUsIDIwMTkgYXQgMjo0OCBQTSBLZW50IFdhdHNlbiA8a2VudEB3YXRzZW4ubmV0DQo8bWFp bHRvOmtlbnRAd2F0c2VuLm5ldD4gPiB3cm90ZToNCg0KSSBkb24ndCB0aGluayBFcnJhdHVtIDUz OTcgc2hvdWxkIGJlIGRlbGV0ZWQuIFRob3VnaCB0aGUgb3JpZ2luYWwNCnNlY3Rpb24gNy44IG1h a2VzIG5vIG1lbnRpb24gb2YgY29uZmlybWVkIGNvbW1pdHMsIHNlY3Rpb24gNy45IGRvZXMsIGJ1 dA0KZG9lcyBub3QgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGEgdmFuaWxsYSBjb25maXJtZWQgY29t bWl0IGFuZCBhDQpwZXJzaXN0ZW50IGNvbmZpcm1lZCBjb21taXQuIFNpbmNlIGEgcGVyc2lzdGVu dCBjb25maXJtZWQgY29tbWl0IGlzDQpzdGlsbCBhIHR5cGUgb2YgY29uZmlybWVkIGNvbW1pdCwg d2l0aG91dCBjbGFyaWZpY2F0aW9uIHRoZSBzZWNvbmQNCnBhcmFncmFwaCBvZiB0aGUgZGVzY3Jp cHRpb24gd291bGQgc2VlbSB0byBhcHBseS4NCg0KSSB3b3VsZCBhZ3JlZS4NCg0KNy44IGRvZXMg bm90IHNheSBhbnl0aGluZyBhYm91dCB0aGUgPGtpbGwtc2Vzc2lvbj4gaXMgZm9yIHRoZQ0Kc2Vz c2lvbiB0aGF0IHN0YXJ0ZWQgYSBjb25maXJtZWQgY29tbWl0IG9yIGV4dGVuZGVkIGEgY29uZmly bWVkIGNvbW1taXQuDQpJdCBjb3VsZCBiZSBpbnRlcnByZXRlZCB0byBtZWFuIGFueSBraWxsLXNl c3Npb24gZm9yIGFueSBzZXNzaW9uIGNhdXNlcw0KYSBjb25maXJtZWQgY29tbWl0IHRvIGJlIHJv bGxlZCBiYWNrLiAgVGhlIHRleHQgYmVsb3cgaXMgc28gYW1iaWd1b3VzIGl0DQoNCmlzIG5vdCBl dmVuIGNsZWFyIHRoZSA8a2lsbC1zZXNzaW9uPiBoYXMgdG8gYmUgZm9yIGFuIGV4aXN0aW5nIHNl c3Npb24sDQoNCiAgICAgIElmIGEgTkVUQ09ORiBzZXJ2ZXIgcmVjZWl2ZXMgYSA8a2lsbC1zZXNz aW9uPiByZXF1ZXN0IHdoaWxlDQogICAgICBwcm9jZXNzaW5nIGEgY29uZmlybWVkIGNvbW1pdCAo U2VjdGlvbiA4LjQpLCBpdCBNVVNUIHJlc3RvcmUgdGhlDQogICAgICBjb25maWd1cmF0aW9uIHRv IGl0cyBzdGF0ZSBiZWZvcmUgdGhlIGNvbmZpcm1lZCBjb21taXQgd2FzIGlzc3VlZC4NCg0KDQpX aGlsZSB0aGUgb3JpZ2luYWwgdGV4dCBpbiA3Ljggd2FzIGFtYmlndW91cywgRXJyYXR1bSA1Mzk3 IGRvZXMgc2VlbSB0bw0KY2xhcmlmeSB0aGF0IHRoZSA8Y2xvc2Utc2Vzc2lvbj4gKG5vdCA8a2ls bC1zZXNzaW9uKSwgaXMgZm9yIHRoZSBzZXNzaW9uDQppbiBxdWVzdGlvbiwgYW5kIG5vdCBhbnkg c2Vzc2lvbi4NCg0KSSBkbyBub3QgYWdyZWUgdGhhdCBjbG9zZS1zZXNzaW9uIG92ZXJyaWRlcyB0 aGUgdGV4dCBpbiBzZWMgOC40IHN1cHBvcnRzDQp0aGlzIHByb2NlZHVyZS4NCg0KSXQgYWxzbyBt YWtlcyBubyBzZW5zZSBmcm9tIGFuIG9wZXJhdGlvbmFsIFBPViwgc2luY2UgZHJvcHBpbmcgdGhl DQpzZXNzaW9uDQoNCih3aXRob3V0IGEgY2xvc2Utc2Vzc2lvbikgZG9lcyBub3QgaGF2ZSB0aGlz IGFmZmVjdCA6DQoNCiAgIElmIHRoZSBzZXNzaW9uIGlzc3VpbmcgdGhlIGNvbmZpcm1lZCBjb21t aXQgaXMgdGVybWluYXRlZCBmb3IgYW55DQogICByZWFzb24gYmVmb3JlIHRoZSBjb25maXJtIHRp bWVvdXQgZXhwaXJlcywgdGhlIHNlcnZlciBNVVNUIHJlc3RvcmUNCiAgIHRoZSBjb25maWd1cmF0 aW9uIHRvIGl0cyBzdGF0ZSBiZWZvcmUgdGhlIGNvbmZpcm1lZCBjb21taXQgd2FzDQogICBpc3N1 ZWQsIHVubGVzcyB0aGUgY29uZmlybWVkIGNvbW1pdCBhbHNvIGluY2x1ZGVkIGEgPHBlcnNpc3Q+ DQogICBlbGVtZW50Lg0KDQpJTU8gdGhpcyB0ZXh0IG92ZXJyaWRlcyB0aGUgY2xvc2Utc2Vzc2lv biBhbmQga2lsbC1zZXNzaW9uIHRleHQuDQoNCiAgICAgIElmIGEgTkVUQ09ORiBzZXJ2ZXIgcmVj ZWl2ZXMgYSA8Y2xvc2Utc2Vzc2lvbj4gcmVxdWVzdCB3aGlsZQ0KICAgICAgcHJvY2Vzc2luZyBh IGNvbmZpcm1lZCBjb21taXQgKFNlY3Rpb24gOC40KSBmb3IgdGhhdCBzZXNzaW9uLCBpdA0KICAg ICAgTVVTVCByZXN0b3JlIHRoZSBjb25maWd1cmF0aW9uIHRvIGl0cyBzdGF0ZSBiZWZvcmUgdGhl IGNvbmZpcm1lZA0KICAgICAgY29tbWl0IHdhcyBpc3N1ZWQgdW5sZXNzIHRoZSBjb25maXJtZWQg Y29tbWl0IGluY2x1ZGVkIGEgPHBlcnNpc3Q+DQogICAgICBlbGVtZW50Lg0KDQpUaGF0IGlzIHdo eSBJIGFncmVlIHRoYXQgRXJyYXR1bSA1Mzk3IHNob3VsZCBub3QgYmUgZGVsZXRlZCwgYnV0IHNo b3VsZA0KYmUgbW9kaWZpZWQgdG8gdGhlIHRleHQgc3VnZ2VzdGVkIGJ5IEpvbmF0aGFuLg0KDQpU aGlzIG1ha2VzIG5vIG9wZXJhdGlvbmFsIHNlbnNlIGlmIHRoZSA8cGVyc2lzdD4gcGFyYW1ldGVy IHdhcyB1c2VkLg0KDQpJdCdzIGEgbWlub3IgcG9pbnQsIGJ1dCBJIGNvdWxkIGFyZ3VlLCBhcyBJ IHdyb3RlIGJlZm9yZSwgdGhhdCBzdWNoDQpjbGFyaWZpY2F0aW9ucyBpbiA3LnggYXJlIHVubmVj ZXNzYXJ5IGJlY2F1c2UgOC40IHByb3ZpZGVzIG92ZXJyaWRlcy4NCkkgcHJlZmVyIGxlc3MgdGV4 dCBiZWNhdXNlIGl0J3MgZWFzaWVyIHRvIGdldCByaWdodCAod2l0IHRoaXMgaXMgYXQNCmxlYXN0 IHRoZSAzcmQgdGltZSBKb25hdGhhbiBpcyBhdCB0aGlzIG5vdykuICBIb3dldmVyICJ1bm5lY2Vz c2FyeSINCmRvZXNuJ3QgbWVhbiAid3JvbmciIGFuZCBzaW5jZSB3ZSd2ZSBhbHJlYWR5IHN0ZXBw ZWQgaW4gaXQsIGdldHRpbmcgdGhlDQo3LnggZXJyYXRhIHJpZ2h0IG1pZ2h0IGJlIGVhc2llciB0 aGFuIGdldHRpbmcgOC40IHJpZ2h0Lg0KDQo4LjQgcGFyYSAzIHNheXMgdGhlIGNvbmZpcm1lZCBj b21taXQgaXMgbm90IHRpZWQgdG8gYSBzZXNzaW9uIGlmIHRoZQ0KcGVyc2lzdC9wZXJzaXN0MGlk IG1lY2hhbmlzbSBpcyB1c2VkLg0KDQogICBJZiB0aGUgPHBlcnNpc3Q+IGVsZW1lbnQgaXMgbm90 IGdpdmVuIGluIHRoZSBjb25maXJtZWQgY29tbWl0DQogICBvcGVyYXRpb24sIGFueSBmb2xsb3ct dXAgY29tbWl0IGFuZCB0aGUgY29uZmlybWluZyBjb21taXQgTVVTVCBiZQ0KICAgaXNzdWVkIG9u IHRoZSBzYW1lIHNlc3Npb24gdGhhdCBpc3N1ZWQgdGhlIGNvbmZpcm1lZCBjb21taXQuICBJZiB0 aGUNCiAgIDxwZXJzaXN0PiBlbGVtZW50IGlzIGdpdmVuIGluIHRoZSBjb25maXJtZWQgPGNvbW1p dD4gb3BlcmF0aW9uLCBhDQogICBmb2xsb3ctdXAgY29tbWl0IGFuZCB0aGUgY29uZmlybWluZyBj b21taXQgY2FuIGJlIGdpdmVuIG9uIGFueQ0KICAgc2Vzc2lvbiwgYW5kIHRoZXkgTVVTVCBpbmNs dWRlIGEgPHBlcnNpc3QtaWQ+IGVsZW1lbnQgd2l0aCBhIHZhbHVlDQogICBlcXVhbCB0byB0aGUg Z2l2ZW4gdmFsdWUgb2YgdGhlIDxwZXJzaXN0PiBlbGVtZW50Lg0KDQpUaGUgcHJvYmxlbWF0aWMg dGV4dCBpcyBhY3R1YWxseSBpbiA8Y2FuY2VsX2NvbW1pdD4NCg0KOC40LjQuMS4gIDxjYW5jZWwt Y29tbWl0Pg0KDQogICBEZXNjcmlwdGlvbjoNCg0KICAgICAgICAgQ2FuY2VscyBhbiBvbmdvaW5n IGNvbmZpcm1lZCBjb21taXQuICBJZiB0aGUgPHBlcnNpc3QtaWQ+DQogICAgICAgICBwYXJhbWV0 ZXIgaXMgbm90IGdpdmVuLCB0aGUgPGNhbmNlbC1jb21taXQ+IG9wZXJhdGlvbiBNVVNUIGJlDQog ICAgICAgICBpc3N1ZWQgb24gdGhlIHNhbWUgc2Vzc2lvbiB0aGF0IGlzc3VlZCB0aGUgY29uZmly bWVkIGNvbW1pdC4NCg0KSW4gb3JkZXIgdG8gY2FuY2VsIGEgY29uZmlybWVkIGNvbW1pdCAoYmVs b25naW5nIHRvIGFub3RoZXIgY2xpZW50LCBpLmUNCnRoZSBwZXJzaXN0LWlkIGlzIG5vdCBrbm93 biksIHRoZSBjbGllbnQgaXNzdWVzIGEgPGtpbGwtc2Vzc2lvbj4gZm9yDQphbnkgcmFuZG9tIG9y IG5vbi1leGlzdGVudCBzZXNzaW9uLiAgSXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIHRvIGlzc3Vl IGENCjxjYW5jZWwtY29tbWl0Pg0KDQoobWF5YmUgcmVxdWlyZSBzdXBlcnVzZXIpIGluc3RlYWQu IFRoZSBhY2Nlc3MgY29udHJvbCBwb2xpY3kgZm9yDQo8a2lsbC1zZXNzaW9uPg0KDQppcyB0aGUg d3Jvbmcgd2F5IHRvIGNvbmZpZ3VyZSBhY2Nlc3MgdG8gY2FuY2VsbGluZyBhIGNvbmZpcm1lZCBj b21taXQuDQoNCg0KSU1PIHRoZXNlIHByb2NlZHVyZXMgYXJlIG5vdCB3ZWxsIGRlc2lnbmVkIG9y IGRvY3VtZW50ZWQsIGFuZCBhbiBFcnJhdGENCmNhbm5vdA0KDQpiZSB1c2VkIHRvIGZpeCBpdCAt LSBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBwcm90b2NvbCBzaG91bGQgZml4IGl0LCBpbg0Kd2hpY2gg V0cgYW5kIElFVEYgY29uc2Vuc3VzDQppcyByZWFjaGVkIGZvciB0aGUgc2VsZWN0ZWQgc29sdXRp b24uDQoNCkRvIHlvdSB3YW50IHRvIG9wZW4gdGhpcyBhcyBhIG5ldGNvbmYtbmV4dCBpc3N1ZT8N Cg0KDQpub3QgcmVhbGx5DQoNCldpdGggdGhlIGRpZmYsIHNob3VsZCB0aGF0IGJlIGFnYWluc3Qg dGhlIG9yaWdpbmFsIHRleHQgb3IgdGhlIG9yaWdpbmFsDQplcnJhdHVtPw0KDQoNClRoZSBkaWZm IGlzIGJ1aWxkaW5nIG9uIHRvcCBvZiB0aGUgb3JpZ2luYWwgZXJyYXR1bS4gSSB3b3VsZCB0aGlu ayBhDQpkaWZmIHcuci50LiB0byB0aGUgb3JpZ2luYWwgZXJyYXR1bSB3b3VsZCBtYWtlIHNlbnNl Lg0KDQoNCkl0IGRlcGVuZHMsIGFyZSB5b3UgY29ycmVjdGluZyB0aGUgZWFybGllciBlcnJhdGEg b3IgZmlsaW5nIGEgbmV3IG9uZT8NClJlZ2FyZGxlc3MsIEkgZXhwcmVzc2VkIGEgZGlmZiBmb3Ig d2hhdCBJIHRoaW5rIHRoZSB0ZXh0IHNob3VsZCBiZQ0KKHdoaWNoIHlvdSBkaWRuJ3QgY29tbWVu dCBvbik7IGhvdyB0aGF0IGlzIHRyYW5zbGF0ZWQgaXMgdXAgdG8geW91Lg0KDQpLZW50IC8vIGNv bnRyaWJ1dG9yDQoNCg0KQW5keQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3Jn IDxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0KDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KDQptamV0aGFuYW5k YW5pQGdtYWlsLmNvbSA8bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KDQoN Cg0KDQoNCg0KQW5keQ0KDQoNCg0KDQoNCg0KDQotLS0NClRoaXMgZW1haWwgaGFzIGJlZW4gY2hl Y2tlZCBmb3IgdmlydXNlcyBieSBBdmFzdCBhbnRpdmlydXMgc29mdHdhcmUuDQpodHRwczovL3d3 dy5hdmFzdC5jb20vYW50aXZpcnVzDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tDQoN Cg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBu ZXRjb25mIG1haWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPg0KDQo= From nobody Fri May 24 13:18:50 2019 Return-Path: <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544D12004C for ; Fri, 24 May 2019 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5bRFtqvC29J for ; Fri, 24 May 2019 13:18:44 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4399120345 for ; Fri, 24 May 2019 13:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1558729122; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=LAR+0s4mdVBc/YspGYwh5OgbQzv+5umyZ8VyZdRLR1Q=; b=DLfn1F9/Y36Nj+nSP7ODA13mARF1RVmMQt/dNqNSTetMT0VHyVlSus+f2D8EaM1p soGhaXn2RC9cr2DOY54n7hZyqqEgoT7EOcF3SDTrO/x7I4A7FnYvwlAqZHZG9FjLaeV ihSYyptjSBqU+YmulR5uiXuCpFyMclkjXCDxYv9w= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_FC1FEB00-3ED2-4835-91D2-F1552FF06B78" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 24 May 2019 20:18:42 +0000 References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> Message-ID: <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.05.24-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 20:18:48 -0000 --Apple-Mail=_FC1FEB00-3ED2-4835-91D2-F1552FF06B78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The message below was sent two weeks ago. As a matter of expediency, I = will assume there are no objections to this "crypt-hash"-like proposal. Thanks, Kent // contributor > On May 11, 2019, at 12:18 PM, Kent Watsen = wrote: >=20 >=20 > Hi Juergen, >=20 >=20 >>> I discussed this option in my "wide-screen needed" email from last = Friday. >>> There are 3 cases to consider: >>>=20 >>> 1) the manufacturer creates the (most likely "hidden") key pair and = associated certificate. >>> - these nodes MUST originate in (origin=3D"system") >>> - clients MUST replicate their (potentially encrypted or = "permanently-hidden" >>> enumerated) content into in order reference the key = and/or cert. >>=20 >> The question is what or how much needs replication. We refer to >> hardware interfaces created by the manufacturer (and identified = during >> system startup - or during hotplug procedures) by having a name >> binding of config in to operational state in . >> If you configure eth0, then this config binds to an >> interface with the same name. So if there is a key pair created by = the >> vendor, perhaps all we need is a kind of a name that can be used to >> bind the config to the key. >=20 > True, it could to a handle, but it's unclear what the handle would be. = We'd probably have to create one just to resolve this issue. >=20 >=20 >>> 2) the client wishes to generate a key (hidden or not) without ever = touching the >>> private key. >>> - presumably this occurs via a "generate-key" action (open to = ideas) >>> - this key ultimately MUST be in in order to be = referenced by config. >>=20 >> Perhaps the question is whether this is 'the key' or 'the name of the >> key'. >=20 > Same as above. >=20 >=20 >>> - ideally it shows up in as consequence of invoking = the action. >>> - less ideal, as in (1), a / sequence could = be used >>> to bring the key into . >>=20 >> Would it help if "generate-key" simply returns a name for the new = key? >=20 > Perhaps, I'd have to think through it more but, first, I want to dig a = little more on the "crypt-hash" approach (see below). >=20 >=20 >>> 3) the client wished to installed a hidden key. >>> - note that we don't discuss installing a non-hidden key here, = because >>> that is exactly what a standard operation does. >>> - presumably this occurs via a "install-key" action (open to = ideas) >>> - this is a weird case because the client is initially okay with = touching the >>> private key, but thereafter wants it to be protected by the = system. >>> - again, as with (2), ideally the key shows up in running as = consequence >>> of the action, but a round-trip could also get it there. >>=20 >> /js >=20 >=20 >=20 > Switching gears, I'd like to explore more the idea of reverting the = 3-tuple back to "mandatory true" as discussed here: = https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY = but, instead of using `action` statements, perhaps we can use something = similar to "crypt-hash". >=20 > =46rom RFC 7317: >=20 > typedef crypt-hash { > type string { > pattern > '$0$.*' > + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' > + '|$5$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' > + '|$6$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; > } > description > "The crypt-hash type is used to store passwords using > a hash function. The algorithms for applying the hash > function and encoding the result are implemented in > various UNIX systems as the function crypt(3). >=20 > A value of this type matches one of the forms: >=20 > $0$ > $$$ > $$$$ >=20 > The '$0$' prefix signals that the value is clear text. When > such a value is received by the server, a hash value is > calculated, and the string '$$$' or > $$$$ is prepended to the result. This > value is stored in the configuration data store. > >=20 >=20 > Note that the last sentence says "stored in the configuration data = store". > So how about this (note: all 3 values are "mandatory true"): >=20 >=20 > leaf algorithm { > nacm:default-deny-write; > type asymmetric-key-algorithm-ref; > mandatory true; > description > "Identifies the key's algorithm."; > } >=20 >=20 > leaf public-key { > nacm:default-deny-write; > type union { > type binary; > type string { > pattern > + '' > + '|[A-Za-z0-9+/]+[=3D]{1,3}'; > } > mandatory true; > description > " > Binary is used for a standard configuration value. >=20 > Prefix values are used to support special use-cases as follows: >=20 > >=20 > An input value that is used to request the system to=20 > generate the key-pair. >=20 > Without the optional '-and-hidden' postfix, the generated > key pair is stored in the configuration data store. This > is used to support the security best practice use case > whereby the client doesn't touch the private key. >=20 > With the optional '-and-hidden' postfix, the key pair is > generated in such a way that it will thereafter be reported > either using '' or ''. =20 >=20 > When the '' prefix is > used, it MUST be used in both the 'public-key' and = 'private- > key' values. >=20 > [A-Za-z0-9+/]+[=3D]{1,3} >=20 > An input value that is used to request the system to=20 > store the provided key-pair in such a way that it will > thereafter be reported either as '' > or '*'. >=20 > Following the prefix is the base64-encoded value of the > public key. >=20 > When the '' prefix is used, it MUST be=20= > used in both the 'public-key' and 'private-key' values. > "; > } >=20 >=20 > leaf private-key { > nacm:default-deny-all; > type union { > type binary; > type string { > pattern > '' > + '|[A-Za-z0-9+/]+[=3D]{1,3}' > + '|' > + '|[A-Za-z0-9+/]+[=3D]{1,3}'; > } > mandatory true; > description > " > Binary is used for a standard configuration value. >=20 > Prefix values are used to support special use-cases as follows: >=20 > >=20 > An output value that is used by the system to indicate > that the private key value is not available in any form. >=20 > [A-Za-z0-9+/]+[=3D]{1,3} >=20 > An output value that is used by the system to indicate > that the private key value is encrypted using the key > identified by the 'by' attribute. >=20 > Following the prefix is the base64-encoded value of the > encrypted private key.=20 >=20 > >=20 > An input value that is used to request the system to=20 > generate the key-pair. >=20 > Without the optional '-and-hidden' postfix, the generated > key pair is stored in the configuration data store. This > is used to support the security best practice use case > whereby the client doesn't touch the private key. >=20 > With the optional '-and-hidden' postfix, the key pair is > generated in such a way that it will thereafter be reported > either using '' or ''. >=20 > When the '' prefix is > used, it MUST be used in both the 'public-key' and = 'private- > key' values. >=20 > [A-Za-z0-9+/]+[=3D]{1,3} >=20 > An input value that is used to request the system to=20 > store the provided key-pair in such a way that it will > thereafter be reported either as '' > or '*'. >=20 > Following the prefix is the base64-encoded value of the > private key. >=20 > When the '' prefix is used, it MUST be=20= > used in both the 'public-key' and 'private-key' values. > "; > } >=20 >=20 >=20 > Kent // contributor >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_FC1FEB00-3ED2-4835-91D2-F1552FF06B78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The message below was = sent two weeks ago.   As a matter of expediency, I will assume = there are no objections to this "crypt-hash"-like proposal.

Thanks,
Kent  // contributor




On May 11, 2019, at 12:18 PM, Kent Watsen <kent+ietf@watsen.net> wrote:


Hi Juergen,


I discussed this option in my "wide-screen needed" email from = last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely = "hidden") key pair and associated certificate.
=     - these nodes MUST originate in = <operational> (origin=3D"system")
=     - clients MUST replicate their (potentially = encrypted or "permanently-hidden"
=       enumerated) content into = <running> in order reference the key and/or cert.

The question is what or how much = needs replication. We refer to
hardware interfaces created = by the manufacturer (and identified during
system startup = - or during hotplug procedures) by having a name
binding = of config in <running> to operational state in = <operational>.
If you configure eth0, then this = config binds to an <operational>
interface with the = same name. So if there is a key pair created by the
vendor, = perhaps all we need is a kind of a name that can be used to
bind the config to the key.

True, it could to a handle, but it's unclear what the handle = would be.  We'd probably have to create one just to resolve this = issue.


2) the = client wishes to generate a key (hidden or not) without ever touching = the
  private key.
=     - presumably this occurs via a "generate-key" = action (open to ideas)
    - this key = ultimately MUST be in <running> in order to be referenced by = config.

Perhaps the question = is whether this is 'the key' or 'the name of the
key'.

Same as above.


    - ideally it shows up = in <running> as consequence of invoking the action.
=     - less ideal, as in (1), a = <get-data>/<edit-data> sequence could be used
=       to bring the key into = <running>.

Would it help = if "generate-key" simply returns a name for the new key?

Perhaps, I'd have to think = through it more but, first, I want to dig a little more on the = "crypt-hash" approach (see below).


3) the client wished to installed a hidden key.
=     - note that we don't discuss installing a = non-hidden key here, because
=       that is exactly what a standard = <edit-config> operation does.
=     - presumably this occurs via a "install-key" = action (open to ideas)
    - this is = a weird case because the client is initially okay with touching the
      private key, but = thereafter wants it to be protected by the system.
=     - again, as with (2), ideally the key shows up = in running as consequence
=       of the action, but a round-trip = could also get it there.

/js



Switching gears, I'd like to explore more the idea of = reverting the 3-tuple back to "mandatory true" as discussed here: https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5me= OCpNQMJusY but, instead of using `action` statements, perhaps we can = use something similar to "crypt-hash".

=46rom= RFC 7317:

    typedef = crypt-hash {
      type = string {
=         pattern
=           '$0$.*'
        + = '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
=         + = '|$5$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
=         + = '|$6$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
      }
=       description
=         "The crypt-hash type is = used to store passwords using
=          a hash function. =  The algorithms for applying the hash
=          function and = encoding the result are implemented in
=          various UNIX = systems as the function crypt(3).

=          A value of this = type matches one of the forms:

=            $0$<c= lear text password>
=            $<id&= gt;$<salt>$<password hash>
=            $<id&= gt;$<parameter>$<salt>$<password hash>
         The = '$0$' prefix signals that the value is clear text.  When
         such a = value is received by the server, a hash value is
=          calculated, and = the string '$<id>$<salt>$' or
=          $<id>$<para= meter>$<salt>$ is prepended to the result.  This
         value = is stored in the configuration data store.
=     <snip/>


Note that the last sentence says "stored in the configuration = data store".
So how about this (note: all 3 values are = "mandatory true"):


=    leaf algorithm {
=      nacm:default-deny-write;
=      type asymmetric-key-algorithm-ref;
     mandatory true;
=      description
=        "Identifies the key's = algorithm.";
   }


   leaf public-key {
     nacm:default-deny-write;
     type union {
=        type binary;
=        type string {
=          pattern
         + = '<value-to-be-generated(-and-hidden)?>'
=          + = '|<value-to-be-hidden>[A-Za-z0-9+/]+[=3D]{1,3}';
=        }
=      mandatory true;
=      description
=        "
=        Binary is used for a standard = configuration value.

=        Prefix values are used to = support special use-cases as follows:

=          <value-to-be-gene= rated(-and-hidden)?>

=            An = input value that is used to request the system to
=            generate= the key-pair.

=            Without = the optional '-and-hidden' postfix, the generated
=            key = pair is stored in the configuration data store.  This
=            is = used to support the security best practice use case
=            whereby = the client doesn't touch the private key.

=            With = the optional '-and-hidden' postfix, the key pair is
=            generate= d in such a way that it will thereafter be reported
=            either = using '<permanently-hidden>' or '<encrypted by=3D'*'>'. =            

=            When = the '<value-to-be-generated(-and-hidden)?>' prefix is
=            used, = it MUST be used in both the 'public-key' and 'private-
=            key' = values.

=          <value-to-be-hidd= en>[A-Za-z0-9+/]+[=3D]{1,3}

=            An = input value that is used to request the system to
=            store = the provided key-pair in such a way that it will
=            thereaft= er be reported either as '<permanently-hidden>'
=            or = '<encrypted by=3D'*'>*'.

=            Followin= g the prefix is the base64-encoded value of the
=            public = key.

=            When = the '<value-to-be-hidden>' prefix is used, it MUST be
=            used = in both the 'public-key' and 'private-key' values.
=        ";
=    }


=    leaf private-key {
=      nacm:default-deny-all;
=      type union {
=        type binary;
=        type string {
=          pattern
=            '<per= manently-hidden>'
=          + '|<encrypted = by=3D"*">[A-Za-z0-9+/]+[=3D]{1,3}'
=          + = '|<value-to-be-generated(-and-hidden)?>'
=          + = '|<value-to-be-hidden>[A-Za-z0-9+/]+[=3D]{1,3}';
=        }
=      mandatory true;
=      description
=        "
=        Binary is used for a standard = configuration value.

=        Prefix values are used to = support special use-cases as follows:

=          <permanently-hidd= en>

=            An = output value that is used by the system to indicate
=            that = the private key value is not available in any form.

=          <encrypted = by=3D'*'>[A-Za-z0-9+/]+[=3D]{1,3}

=            An = output value that is used by the system to indicate
=            that = the private key value is encrypted using the key
=            identifi= ed by the 'by' attribute.

=            Followin= g the prefix is the base64-encoded value of the
=            encrypte= d private key.

=          <value-to-be-gene= rated(-and-hidden)?>

=            An = input value that is used to request the system to
=            generate= the key-pair.

=            Without = the optional '-and-hidden' postfix, the generated
=            key = pair is stored in the configuration data store.  This
=            is = used to support the security best practice use case
=            whereby = the client doesn't touch the private key.

=            With = the optional '-and-hidden' postfix, the key pair is
=            generate= d in such a way that it will thereafter be reported
=            either = using '<permanently-hidden>' or '<encrypted by=3D'*'>'.

=            When = the '<value-to-be-generated(-and-hidden)?>' prefix is
=            used, = it MUST be used in both the 'public-key' and 'private-
=            key' = values.

=          <value-to-be-hidd= en>[A-Za-z0-9+/]+[=3D]{1,3}

=            An = input value that is used to request the system to
=            store = the provided key-pair in such a way that it will
=            thereaft= er be reported either as '<permanently-hidden>'
=            or = '<encrypted by=3D'*'>*'.

=            Followin= g the prefix is the base64-encoded value of the
=            private = key.

=            When = the '<value-to-be-hidden>' prefix is used, it MUST be
=            used = in both the 'public-key' and 'private-key' values.
=        ";
=    }



Kent // contributor


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

= --Apple-Mail=_FC1FEB00-3ED2-4835-91D2-F1552FF06B78-- From nobody Mon May 27 07:27:25 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52313120004; Mon, 27 May 2019 07:27:18 -0700 (PDT) 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.97.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ibagdona@gmail.com, The IESG , draft-ietf-netconf-yang-push@ietf.org, netconf-chairs@ietf.org, netconf@ietf.org, kent+ietf@watsen.net, Kent Watsen , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155896723832.729.7194149626529275174.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2019 07:27:18 -0700 Archived-At: Subject: [netconf] Protocol Action: 'Subscription to YANG Datastores' to Proposed Standard (draft-ietf-netconf-yang-push-25.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 14:27:18 -0000 The IESG has approved the following document: - 'Subscription to YANG Datastores' (draft-ietf-netconf-yang-push-25.txt) as Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ Technical Summary This document defines a mechanism for interested subscribers to receive asynchronous events corresponding to changes happening to a YANG datastore. A YANG data model for controlling the operation of such subscription is also defined. Working Group Summary WG reached a consensus on the mechanisms specified in the document, without any major disagreements. Document Quality There is at least some interest from vendor community for implementing the specified functionality. The document has been reviewed by several directorates in addition to usual last calls. Personnel The Document Shepherd is Kent Watsen. The responsible Area Director is Ignas Bagdonas. IANA Note This document adds new entries to IETF XML and YANG Module Names registries. From nobody Thu May 30 02:48:48 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934BD120105 for ; Thu, 30 May 2019 02:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDU550lI7Yvc for ; Thu, 30 May 2019 02:48:41 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10041.outbound.protection.outlook.com [40.107.1.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB21A120074 for ; Thu, 30 May 2019 02:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+8z+2sy4DoCSgXQRXbNq44Xfg5VWv0jAE8HolCNK5Zk=; b=R/7MT4iQ17BQa34OYfKeFrB11aS6MlO0AbIHxcH4ylxJy6g0Tb2xor70+cf/eTP4RzjnKwDJJyoGmSJqa+5pyiligPPcazO54x6irlB+KRS8Y8l25nT+DAHcRAM2hkuwcMpEYg5jWAWhKLF6W6+m1jq9J/7evNIBZKfesxG6Ank= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB5326.eurprd07.prod.outlook.com (20.178.11.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.12; Thu, 30 May 2019 09:48:34 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::95e8:7ebf:d9f5:d887]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::95e8:7ebf:d9f5:d887%7]) with mapi id 15.20.1943.016; Thu, 30 May 2019 09:48:34 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Kov=E1cs?= To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oAAICCMAAAQfJ4AABQvugADqJOIAAAiERYAAKAZY4AABZSwAAAGYSwAABxXrgAA8jwUAAB/0SoAAJqYTgAAFKLEAAAT2BoAACbL7AAAASZ0AAL8j1gAAAX72AAASqQQAABHnTAAArPS3AAKWLDUAARaMhaA= Date: Thu, 30 May 2019 09:48:34 +0000 Message-ID: References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> In-Reply-To: <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efc5a62e-04e0-4e71-941f-08d6e4e3fb9b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB5326; x-ms-traffictypediagnostic: VI1PR07MB5326: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(376002)(396003)(136003)(199004)(189003)(11346002)(25786009)(446003)(6246003)(71200400001)(66946007)(66066001)(476003)(486006)(14454004)(790700001)(54896002)(6306002)(9686003)(186003)(6116002)(53936002)(64756008)(236005)(3846002)(5660300002)(73956011)(81166006)(2501003)(66556008)(76116006)(256004)(66476007)(66446008)(14444005)(7736002)(561944003)(86362001)(68736007)(71190400001)(81156014)(316002)(102836004)(110136005)(966005)(606006)(9326002)(26005)(74316002)(229853002)(6436002)(8676002)(55016002)(2906002)(508600001)(76176011)(6506007)(99286004)(52536014)(7696005)(45776006)(33656002)(53546011)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5326; H:VI1PR07MB4735.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: Ub6Ea3w6G1DLBoYAxEpsAzbmjkJCaEXcBd/Kb0i7ajzGFS2UthO713Xi/lNB3yL1kwUYSygf5VYjuj2qkGxh2hZCbtzckzYP3vuwmfuVhdsz7bT4U+4I5xN+rweLURzD2fj6au10cZARmDsUx9tufHtpws+FarcB/u0rYPTpNL0GcjIaHs0ig164Jbd2X0s7oIDr7KY9SmbKqJfUVoJ1gY2hVtKQ5n0EyxGaRJIBcNwOVU/C1XnBtXTW5uqKJ0/v+ZcRuyZq9SToNsb0XScRbgqCcajoFFgnBgJRISunSEOWDMTOH6GxGYUSu/AG8ZCpXc0BF/8/CHHmmcDpM5VROkq+Y4x0WSln3M0QqX9ftg4BTvGBlsBPHSm9OYpwhT8+T+SHv0rdRbd9xWcW/3Rbf8HuRnrfZ5rjjQM9d/33fWE= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4735A8741475AB48FC53FACD83180VI1PR07MB4735eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: efc5a62e-04e0-4e71-941f-08d6e4e3fb9b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2019 09:48:34.9060 (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-CrossTenant-userprincipalname: balazs.kovacs@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5326 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 09:48:45 -0000 --_000_VI1PR07MB4735A8741475AB48FC53FACD83180VI1PR07MB4735eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, In case of crypt-hash, I can accept the extension of the crypt(3) schemes w= ith a $0$ that sort of represents a hash() action, since it matches the ori= ginal crypt(3) syntax. In this case, I find it awkward to tell what to do with the data (verbs) as= prefixes of the data. I personally preferred actions better for this purpo= se. I assume that this representation also does not change the matter of "a= ctions" affecting configuration (see 'output' values). Also validation of r= equired input and output seems more complicated to me. The generate action returning the name of the key or optionally creating co= nfiguration sounded so far the closest match to me. I'm also thinking do we need the 'generate-and-not-hide' and the 'install-a= nd-hide' use cases? Br, Balazs From: netconf On Behalf Of Kent Watsen Sent: Friday, May 24, 2019 10:19 PM To: netconf@ietf.org Subject: Re: [netconf] ietf crypto types - permanently hidden The message below was sent two weeks ago. As a matter of expediency, I wi= ll assume there are no objections to this "crypt-hash"-like proposal. Thanks, Kent // contributor On May 11, 2019, at 12:18 PM, Kent Watsen > wrote: Hi Juergen, I discussed this option in my "wide-screen needed" email from last Friday. There are 3 cases to consider: 1) the manufacturer creates the (most likely "hidden") key pair and associa= ted certificate. - these nodes MUST originate in (origin=3D"system") - clients MUST replicate their (potentially encrypted or "permanently-h= idden" enumerated) content into in order reference the key and/or = cert. The question is what or how much needs replication. We refer to hardware interfaces created by the manufacturer (and identified during system startup - or during hotplug procedures) by having a name binding of config in to operational state in . If you configure eth0, then this config binds to an interface with the same name. So if there is a key pair created by the vendor, perhaps all we need is a kind of a name that can be used to bind the config to the key. True, it could to a handle, but it's unclear what the handle would be. We'= d probably have to create one just to resolve this issue. 2) the client wishes to generate a key (hidden or not) without ever touchin= g the private key. - presumably this occurs via a "generate-key" action (open to ideas) - this key ultimately MUST be in in order to be referenced by= config. Perhaps the question is whether this is 'the key' or 'the name of the key'. Same as above. - ideally it shows up in as consequence of invoking the actio= n. - less ideal, as in (1), a / sequence could be use= d to bring the key into . Would it help if "generate-key" simply returns a name for the new key? Perhaps, I'd have to think through it more but, first, I want to dig a litt= le more on the "crypt-hash" approach (see below). 3) the client wished to installed a hidden key. - note that we don't discuss installing a non-hidden key here, because that is exactly what a standard operation does. - presumably this occurs via a "install-key" action (open to ideas) - this is a weird case because the client is initially okay with touchi= ng the private key, but thereafter wants it to be protected by the system. - again, as with (2), ideally the key shows up in running as consequenc= e of the action, but a round-trip could also get it there. /js Switching gears, I'd like to explore more the idea of reverting the 3-tuple= back to "mandatory true" as discussed here: https://mailarchive.ietf.org/a= rch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY but, instead of using `action` = statements, perhaps we can use something similar to "crypt-hash". >From RFC 7317: typedef crypt-hash { type string { pattern '$0$.*' + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}' + '|$5$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}' + '|$6$(rounds=3D\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}'; } description "The crypt-hash type is used to store passwords using a hash function. The algorithms for applying the hash function and encoding the result are implemented in various UNIX systems as the function crypt(3). A value of this type matches one of the forms: $0$ $$$ $$$$ The '$0$' prefix signals that the value is clear text. When such a value is received by the server, a hash value is calculated, and the string '$$$' or $$$$ is prepended to the result. This value is stored in the configuration data store. Note that the last sentence says "stored in the configuration data store". So how about this (note: all 3 values are "mandatory true"): leaf algorithm { nacm:default-deny-write; type asymmetric-key-algorithm-ref; mandatory true; description "Identifies the key's algorithm."; } leaf public-key { nacm:default-deny-write; type union { type binary; type string { pattern + '' + '|[A-Za-z0-9+/]+[=3D]{1,3}'; } mandatory true; description " Binary is used for a standard configuration value. Prefix values are used to support special use-cases as follows: An input value that is used to request the system to generate the key-pair. Without the optional '-and-hidden' postfix, the generated key pair is stored in the configuration data store. This is used to support the security best practice use case whereby the client doesn't touch the private key. With the optional '-and-hidden' postfix, the key pair is generated in such a way that it will thereafter be reported either using '' or ''. When the '' prefix is used, it MUST be used in both the 'public-key' and 'private- key' values. [A-Za-z0-9+/]+[=3D]{1,3} An input value that is used to request the system to store the provided key-pair in such a way that it will thereafter be reported either as '' or '*'. Following the prefix is the base64-encoded value of the public key. When the '' prefix is used, it MUST be used in both the 'public-key' and 'private-key' values. "; } leaf private-key { nacm:default-deny-all; type union { type binary; type string { pattern '' + '|[A-Za-z0-9+/]+[=3D]{1,3}' + '|' + '|[A-Za-z0-9+/]+[=3D]{1,3}'; } mandatory true; description " Binary is used for a standard configuration value. Prefix values are used to support special use-cases as follows: An output value that is used by the system to indicate that the private key value is not available in any form. [A-Za-z0-9+/]+[=3D]{1,3} An output value that is used by the system to indicate that the private key value is encrypted using the key identified by the 'by' attribute. Following the prefix is the base64-encoded value of the encrypted private key. An input value that is used to request the system to generate the key-pair. Without the optional '-and-hidden' postfix, the generated key pair is stored in the configuration data store. This is used to support the security best practice use case whereby the client doesn't touch the private key. With the optional '-and-hidden' postfix, the key pair is generated in such a way that it will thereafter be reported either using '' or ''. When the '' prefix is used, it MUST be used in both the 'public-key' and 'private- key' values. [A-Za-z0-9+/]+[=3D]{1,3} An input value that is used to request the system to store the provided key-pair in such a way that it will thereafter be reported either as '' or '*'. Following the prefix is the base64-encoded value of the private key. When the '' prefix is used, it MUST be used in both the 'public-key' and 'private-key' values. "; } Kent // contributor _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_VI1PR07MB4735A8741475AB48FC53FACD83180VI1PR07MB4735eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

In case of crypt-hash, I can accept the extension of= the crypt(3) schemes with a $0$ that sort of represents a hash() action, s= ince it matches the original crypt(3) syntax.

 

In this case, I find it awkward to tell what to do w= ith the data (verbs) as prefixes of the data. I personally preferred action= s better for this purpose. I assume that this representation also does not = change the matter of “actions” affecting configuration (see ‘output’ values). Also validation of requir= ed input and output seems more complicated to me.

 

The generate action returning the name of the key or= optionally creating configuration sounded so far the closest match to me.<= o:p>

 

I’m also thinking do we need the ‘genera= te-and-not-hide’ and the ‘install-and-hide’ use cases?

 

Br,

Balazs

 

 

From: netconf <netconf-bounces@ietf.org>= ; On Behalf Of Kent Watsen
Sent: Friday, May 24, 2019 10:19 PM
To: netconf@ietf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden

 

 

The message below was sent two weeks ago.   As = a matter of expediency, I will assume there are no objections to this "= ;crypt-hash"-like proposal.

 

Thanks,

Kent  // contributor

 

 

 



On May 11, 2019, at 12:18 PM, Kent Watsen <kent+ietf@watsen.net> wrot= e:

 


Hi Juergen,



I discussed this option in my "wide-screen need= ed" email from last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely "hidden") key pair a= nd associated certificate.
    - these nodes MUST originate in <operational>= (origin=3D"system")
    - clients MUST replicate their (potentially encrypt= ed or "permanently-hidden"
      enumerated) content into <running>= ; in order reference the key and/or cert.


The question is what or how much needs replication. We refer to
hardware interfaces created by the manufacturer (and identified during
system startup - or during hotplug procedures) by having a name
binding of config in <running> to operational state in <operationa= l>.
If you configure eth0, then this config binds to an <operational>
interface with the same name. So if there is a key pair created by the
vendor, perhaps all we need is a kind of a name that can be used to
bind the config to the key.


True, it could to a handle, but it's unclear what the handle would be. &nbs= p;We'd probably have to create one just to resolve this issue.



2) the client wishes to generate a key (hidden or no= t) without ever touching the
  private key.
    - presumably this occurs via a "generate-key&q= uot; action (open to ideas)
    - this key ultimately MUST be in <running> in= order to be referenced by config.


Perhaps the question is whether this is 'the key' or 'the name of the
key'.


Same as above.



    - ideally it shows up in <= ;running> as consequence of invoking the action.
    - less ideal, as in (1), a <get-data>/<edi= t-data> sequence could be used
      to bring the key into <running>.<= o:p>


Would it help if "generate-key" simply returns a name for the new= key?


Perhaps, I'd have to think through it more but, first, I want to dig a litt= le more on the "crypt-hash" approach (see below).



3) the client wished to installed a hidden key.
    - note that we don't discuss installing a non-hidde= n key here, because
      that is exactly what a standard <edi= t-config> operation does.
    - presumably this occurs via a "install-key&qu= ot; action (open to ideas)
    - this is a weird case because the client is initia= lly okay with touching the
      private key, but thereafter wants it to= be protected by the system.
    - again, as with (2), ideally the key shows up in r= unning as consequence
      of the action, but a round-trip could a= lso get it there.


/js




Switching gears, I'd like to explore more the idea of reverting the 3-tuple= back to "mandatory true" as discussed here: https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY but, instead of using `action` statements, perhaps we can use something = similar to "crypt-hash".

>From RFC 7317:

    typedef crypt-hash {
      type string {
        pattern
          '$0$.*'
        + '|$1$[a-zA-Z0-9./]{1,= 8}$[a-zA-Z0-9./]{22}'
        + '|$5$(rounds=3D\d+= ;$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
        + '|$6$(rounds=3D\d+= ;$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
      }
      description
        "The crypt-hash type i= s used to store passwords using
         a hash function. &nbs= p;The algorithms for applying the hash
         function and encoding= the result are implemented in
         various UNIX systems = as the function crypt(3).

         A value of this type = matches one of the forms:

           $0$<cl= ear text password>
           $<id&g= t;$<salt>$<password hash>
           $<id&g= t;$<parameter>$<salt>$<password hash>

         The '$0$' prefix sign= als that the value is clear text.  When
         such a value is recei= ved by the server, a hash value is
         calculated, and the s= tring '$<id>$<salt>$' or
         $<id>$<param= eter>$<salt>$ is prepended to the result.  This
         value is stored in th= e configuration data store.
    <snip/>


Note that the last sentence says "stored in the configuration data sto= re".
So how about this (note: all 3 values are "mandatory true"):


   leaf algorithm {
     nacm:default-deny-write;
     type asymmetric-key-algorithm-ref;
     mandatory true;
     description
       "Identifies the key's algori= thm.";
   }


   leaf public-key {
     nacm:default-deny-write;
     type union {
       type binary;
       type string {
         pattern
         + '<value-to-b= e-generated(-and-hidden)?>'
         + '|<value-to-= be-hidden>[A-Za-z0-9+/]+[=3D]{1,3}';
       }
     mandatory true;
     description
       "
       Binary is used for a standard con= figuration value.

       Prefix values are used to support= special use-cases as follows:

         <value-to-be-gener= ated(-and-hidden)?>

           An input = value that is used to request the system to
           generate = the key-pair.

           Without t= he optional '-and-hidden' postfix, the generated
           key pair = is stored in the configuration data store.  This
           is used t= o support the security best practice use case
           whereby t= he client doesn't touch the private key.

           With the = optional '-and-hidden' postfix, the key pair is
           generated= in such a way that it will thereafter be reported
           either us= ing '<permanently-hidden>' or '<encrypted by=3D'*'>'.  &nb= sp;         

           When the = '<value-to-be-generated(-and-hidden)?>' prefix is
           used, it = MUST be used in both the 'public-key' and 'private-
           key' valu= es.

         <value-to-be-hidde= n>[A-Za-z0-9+/]+[=3D]{1,3}

           An input = value that is used to request the system to
           store the= provided key-pair in such a way that it will
           thereafte= r be reported either as '<permanently-hidden>'
           or '<e= ncrypted by=3D'*'>*'.

           Following= the prefix is the base64-encoded value of the
           public ke= y.

           When the = '<value-to-be-hidden>' prefix is used, it MUST be
           used in b= oth the 'public-key' and 'private-key' values.
       ";
   }


   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<perm= anently-hidden>'
         + '|<encrypted= by=3D"*">[A-Za-z0-9+/]+[=3D]{1,3}'
         + '|<value-to-= be-generated(-and-hidden)?>'
         + '|<value-to-= be-hidden>[A-Za-z0-9+/]+[=3D]{1,3}';
       }
     mandatory true;
     description
       "
       Binary is used for a standard con= figuration value.

       Prefix values are used to support= special use-cases as follows:

         <permanently-hidde= n>

           An output= value that is used by the system to indicate
           that the = private key value is not available in any form.

         <encrypted by=3D'*= '>[A-Za-z0-9+/]+[=3D]{1,3}

           An output= value that is used by the system to indicate
           that the = private key value is encrypted using the key
           identifie= d by the 'by' attribute.

           Following= the prefix is the base64-encoded value of the
           encrypted= private key.

         <value-to-be-gener= ated(-and-hidden)?>

           An input = value that is used to request the system to
           generate = the key-pair.

           Without t= he optional '-and-hidden' postfix, the generated
           key pair = is stored in the configuration data store.  This
           is used t= o support the security best practice use case
           whereby t= he client doesn't touch the private key.

           With the = optional '-and-hidden' postfix, the key pair is
           generated= in such a way that it will thereafter be reported
           either us= ing '<permanently-hidden>' or '<encrypted by=3D'*'>'.

           When the = '<value-to-be-generated(-and-hidden)?>' prefix is
           used, it = MUST be used in both the 'public-key' and 'private-
           key' valu= es.

         <value-to-be-hidde= n>[A-Za-z0-9+/]+[=3D]{1,3}

           An input = value that is used to request the system to
           store the= provided key-pair in such a way that it will
           thereafte= r be reported either as '<permanently-hidden>'
           or '<e= ncrypted by=3D'*'>*'.

           Following= the prefix is the base64-encoded value of the
           private k= ey.

           When the = '<value-to-be-hidden>' prefix is used, it MUST be
           used in b= oth the 'public-key' and 'private-key' values.
       ";
   }



Kent // contributor


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

 

--_000_VI1PR07MB4735A8741475AB48FC53FACD83180VI1PR07MB4735eurp_-- From nobody Thu May 30 07:14:28 2019 Return-Path: <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786B8120074 for ; Thu, 30 May 2019 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_NONE=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 iDhqRjSacriu for ; Thu, 30 May 2019 07:14:24 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFAF0120111 for ; Thu, 30 May 2019 07:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1559225662; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CUPio/ZLJqc0/AGPUaja+v8zeA1R86LUqUKDnFZHf3g=; b=DLJIdt4ZtVBdqQXVoefvK7gqKCGxZl4ozUNYFZJxJ57NQYjAUSpRCxcQXxKfedNv TZ5S8PtqhyvmMsUQUCfp1kYiWrerbPYmllcXdY16ljR4rL8z7CdzsmAC4nSyoPEnzl+ eFY7i0TQYhcS+OoLYjz1Z59+xAs5YxJ7bHBPAnRA= From: Kent Watsen Message-ID: <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1952B2D4-F890-4F71-ADBC-941261A80663" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 30 May 2019 14:14:22 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.05.30-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 14:14:26 -0000 --Apple-Mail=_1952B2D4-F890-4F71-ADBC-941261A80663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, > In case of crypt-hash, I can accept the extension of the crypt(3) = schemes with a $0$ that sort of represents a hash() action, since it = matches the original crypt(3) syntax. > =20 > In this case, I find it awkward to tell what to do with the data = (verbs) as prefixes of the data. Agreed, but we seem to be at an impasse and I thought this approach = could get us over the line. > I personally preferred actions better for this purpose. It is my preference to use actions as well, but there's pushback there. = Maybe we could claim that the pushback is "in the rough" and press ahead = regardless, but I'd rather avoid that if possible.=20 > I assume that this representation also does not change the matter of = =E2=80=9Cactions=E2=80=9D affecting configuration (see =E2=80=98output=E2=80= =99 values). You mean, exploring this solution leaves the "is it possible for actions = to affect configuration" as unresolved? - correct, that discussion = would remain open. > Also validation of required input and output seems more complicated to = me. How so? > The generate action returning the name of the key or optionally = creating configuration sounded so far the closest match to me. Understood. > I=E2=80=99m also thinking do we need the =E2=80=98generate-and-not-hide= =E2=80=99 and the =E2=80=98install-and-hide=E2=80=99 use cases? Actually, I view =E2=80=98generate-and-not-hide=E2=80=99 as a very = common case. That is, ask the system to generate the key (because = clients are lazy and security best practice), and let standard NACM = rules protect the key. I think that systems supporting user-generated = "hidden" keys will be somewhat rare, to the extent that there should = feature statements enabling servers to indicate if they support the = ability or not. --- I'm growing weary of this discussion. Perhaps we should do even less = for the first release of the crypto-types module. That is, instead of: leaf private-key { nacm:default-deny-all; type union { type binary; type string { pattern '' + '|[A-Za-z0-9+/]+[=3D]{1,3}' + '|' + '|[A-Za-z0-9+/]+[=3D]{1,3}'; } we have: leaf private-key { nacm:default-deny-all; type union { type binary; type string { pattern '' + '|[A-Za-z0-9+/]+[=3D]{1,3}' } This removes the "verbs" (as you call them) and thus leaves open = possibility for either "verbs" or action statements to be added in some = future revision. This subset still supports the critical use-case of a = manufacturer-generated private key for a secure device identifier (i.e., = IDevID). Unfortunately, it does not support the security best = practice use-case of having the device generate the private key. The = IESG (Security Directorate) may or may not be okay with this (obviously = the shepherd would have to bring it to their attention), but perhaps = it's worth testing their resolve and see what happens? Kent // contributor --Apple-Mail=_1952B2D4-F890-4F71-ADBC-941261A80663 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Balazs,

In case of crypt-hash, I = can accept the extension of the crypt(3) schemes with a $0$ that sort of = represents a hash() action, since it matches the original crypt(3) = syntax.
 
In this case, I find it awkward to tell what to do with the = data (verbs) as prefixes of the = data.

Agreed,= but we seem to be at an impasse and I thought this approach could get = us over the line.


I = personally preferred actions better for this purpose. =

It is my = preference to use actions as well, but there's pushback there. =  Maybe we could claim that the pushback is "in the rough" and press = ahead regardless, but I'd rather avoid that if = possible. 


I assume that this = representation also does not change the matter of =E2=80=9Cactions=E2=80=9D= affecting configuration (see =E2=80=98output=E2=80=99 values). =

You mean, = exploring this solution leaves the "is it possible for actions to affect = configuration" as unresolved?  - correct, that discussion would = remain open.


Also validation of = required input and output seems more complicated to = me.

How = so?


The generate action returning the = name of the key or optionally creating configuration sounded so far the = closest match to me.

Understood.


 I=E2=80= =99m also thinking do we need the =E2=80=98generate-and-not-hide=E2=80=99 = and the =E2=80=98install-and-hide=E2=80=99 use = cases?

Actually, = I view  =E2=80=98generate-and-not-hide=E2=80=99 as a very = common case.  That is, ask the system to generate the key (because = clients are lazy and security best practice), and let standard NACM = rules protect the key.   I think that systems supporting = user-generated "hidden" keys will be somewhat rare, to the extent that = there should feature statements enabling servers to indicate if they = support the ability or not.


---

I'm = growing weary of this discussion.  Perhaps we should do even less = for the first release of the crypto-types module.  That is, instead = of:

   leaf private-key = {
     nacm:default-deny-all;
     type union {
    =    type binary;
       type = string {
         pattern
          =  '<permanently-hidden>'
      =    + '|<encrypted by=3D"*">[A-Za-z0-9+/]+[=3D]{1,3}'
         + = '|<value-to-be-generated(-and-hidden)?>'
  =        + = '|<value-to-be-hidden>[A-Za-z0-9+/]+[=3D]{1,3}';
       }

we have:

  =  leaf private-key {
    =  nacm:default-deny-all;
     type = union {
       type binary;
       type string {
  =        pattern
      =      '<permanently-hidden>'
  =        + '|<encrypted = by=3D"*">[A-Za-z0-9+/]+[=3D]{1,3}'
      =  }


This= removes the "verbs" (as you call them) and thus leaves open possibility = for either "verbs" or action statements to be added in some future = revision.   This subset still supports the critical use-case of a = manufacturer-generated private key for a secure device identifier (i.e., = IDevID).    Unfortunately, it does not support the security = best practice use-case of having the device generate the private key. =  The IESG (Security Directorate) may or may not be okay with this = (obviously the shepherd would have to bring it to their attention), but = perhaps it's worth testing their resolve and see what = happens?


Kent // contributor



= --Apple-Mail=_1952B2D4-F890-4F71-ADBC-941261A80663-- From nobody Thu May 30 07:47:24 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266EF12004E for ; Thu, 30 May 2019 07:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 h6qnTJr6MDBQ for ; Thu, 30 May 2019 07:47:19 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052C8120046 for ; Thu, 30 May 2019 07:47:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CEF5B81A; Thu, 30 May 2019 16:47:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id M6dG2HZoq2J7; Thu, 30 May 2019 16:47:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 30 May 2019 16:47:16 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6B6D20128; Thu, 30 May 2019 16:47:16 +0200 (CEST) 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 9RDJgy00h3Tl; Thu, 30 May 2019 16:47:16 +0200 (CEST) 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 62A6B20126; Thu, 30 May 2019 16:47:16 +0200 (CEST) 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.1713.5; Thu, 30 May 2019 16:47:15 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 85F25300990D77; Thu, 30 May 2019 16:47:15 +0200 (CEST) Date: Thu, 30 May 2019 16:47:15 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" Message-ID: <20190530144715.ypon36hh62mhbk3f@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= , "netconf@ietf.org" References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.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: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 14:47:22 -0000 On Thu, May 30, 2019 at 02:14:22PM +0000, Kent Watsen wrote: > I'm growing weary of this discussion. Perhaps we should do even less for the first release of the crypto-types module. That is, instead of: > > leaf private-key { > nacm:default-deny-all; > type union { > type binary; > type string { > pattern > '' > + '|[A-Za-z0-9+/]+[=]{1,3}' > + '|' > + '|[A-Za-z0-9+/]+[=]{1,3}'; > } > > we have: > > leaf private-key { > nacm:default-deny-all; > type union { > type binary; > type string { > pattern > '' > + '|[A-Za-z0-9+/]+[=]{1,3}' > } > > > This removes the "verbs" (as you call them) and thus leaves open possibility for either "verbs" or action statements to be added in some future revision. This subset still supports the critical use-case of a manufacturer-generated private key for a secure device identifier (i.e., IDevID). Unfortunately, it does not support the security best practice use-case of having the device generate the private key. The IESG (Security Directorate) may or may not be okay with this (obviously the shepherd would have to bring it to their attention), but perhaps it's worth testing their resolve and see what happens? > Some comments: - Not sure what security best practice is and where it is defined. Creating the key on the device has the benefit that the key may never have to leave the device but it also requires that I can trust the device to create good keys. (People recall the glitch that led to weak openssh keys on many Linux systems? And given todays world, which devices should I trust to generate strong keys?) I might decide that creating keys with known software I am willing to trust is far better than trusting a key generator shipped by a random device manufacturer. - Side effects are bad and should be avoided. If something requires an rpc/action, make it an rpc/action. - If you create something, give it a name; once things are named (or have other unique properties), config can then refer to these named objects. A create key operation might simply return a fingerprint for the key as the key's name. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri May 31 00:40:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094DF12001B for ; Fri, 31 May 2019 00:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBGWUs85h9QJ for ; Fri, 31 May 2019 00:40:18 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on062a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A95A12007A for ; Fri, 31 May 2019 00:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jOeinxqijIsai2XewEDoJB3HOZfsA3iFnGiJ+05Etyg=; b=riXuKtw2DNi5K+x+ewujvN/h3A37HXD4fD/LQuHePLjRcHCZla00uR+8USNaYQl9LxCAsHz/NhPO4D+2DivCTuaAUo2GFHBBZsYQ9UWCRuWHOd8F0GyLGmw2kT3MkhI0wfTjKaP8N0EFu6dChAw9Uq9a7N7FvhuR3AV6+3LMcew= Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB4944.eurprd07.prod.outlook.com (20.177.201.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.4; Fri, 31 May 2019 07:40:15 +0000 Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::95e8:7ebf:d9f5:d887]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::95e8:7ebf:d9f5:d887%7]) with mapi id 15.20.1943.016; Fri, 31 May 2019 07:40:15 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] ietf crypto types - permanently hidden Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpALufsOAAAVM5oADthG5oAAICCMAAAQfJ4AABQvugADqJOIAAAiERYAAKAZY4AABZSwAAAGYSwAABxXrgAA8jwUAAB/0SoAAJqYTgAAFKLEAAAT2BoAACbL7AAAASZ0AAL8j1gAAAX72AAASqQQAABHnTAAArPS3AAKWLDUAARaMhaAACnm1AAAjjAdg Date: Fri, 31 May 2019 07:40:15 +0000 Message-ID: References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <20190507.141926.1879619200930898148.mbj@tail-f.com> <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com> <20190508054622.rz64qmxdhbx53x4g@anna.jacobs.jacobs-university.de> <0100016aa7b06b97-15f7703f-58b7-40a9-8afe-a54dd2b809e2-000000@email.amazonses.com> <0100016aeb7ee1aa-93dbb2f2-f4ff-432f-9a26-a10abb96b03b-000000@email.amazonses.com> <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.com> In-Reply-To: <0100016b09177be4-ad12ed9f-ddc5-4c13-9470-39b2768513cb-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52a84743-f0f0-455a-1e24-08d6e59b3903 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB4944; x-ms-traffictypediagnostic: VI1PR07MB4944: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00540983E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(366004)(189003)(199004)(51444003)(99286004)(790700001)(316002)(6306002)(71200400001)(6116002)(71190400001)(76116006)(3846002)(52536014)(7696005)(14444005)(33656002)(256004)(66556008)(66476007)(8676002)(7736002)(74316002)(66946007)(53546011)(476003)(6916009)(81156014)(81166006)(8936002)(66446008)(64756008)(9686003)(5660300002)(54896002)(85182001)(76176011)(6506007)(73956011)(102836004)(6436002)(68736007)(486006)(186003)(6246003)(85202003)(66066001)(25786009)(2906002)(14454004)(508600001)(66574012)(11346002)(446003)(53936002)(229853002)(55016002)(4326008)(86362001)(26005)(9326002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4944; H:VI1PR07MB4735.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: ViplALUyPRFrBmKuef/JUGbVIFUKG5Kexz4/v9eytJDozghEa7CJP4zkYuRZj1w2K6bpWHB+vbJgiNllXaeX2FBMHWQ8FLolIG86lgycCaSAdOtHa4JC19Q1G1NgQO795/EzTzWUPftzR5Q31tlgt5PmaI/udihMDVEY00eywkrPWDbd60fSq7vzM760wM4H8XBSbZsmIxULiTm/nbKOP3WQgLS3GLQ+0dAuIVSuLSJiXOgQ7Fn3k3nyhdMGnW3DhyMwlG5RRnXiMR1EQ7iXA5MKdVgTb7bBX6iqSCCAcsWm7UBrLo98A4sICJxBG8XCDU4a7HBW4DnOHB3YtYFxU6c/ODbnNBVTKdj+SOYorgdNvtW+pKYspYCjNlf5AzkRcBlN66JA1br+sl+47SOb92w0EdqGnQ7SnT2ocTF4JGY= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47351DBAC8B0C8EB8A6309D283190VI1PR07MB4735eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52a84743-f0f0-455a-1e24-08d6e59b3903 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2019 07:40:15.8451 (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-CrossTenant-userprincipalname: balazs.kovacs@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4944 Archived-At: Subject: Re: [netconf] ietf crypto types - permanently hidden X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 07:40:22 -0000 --_000_VI1PR07MB47351DBAC8B0C8EB8A6309D283190VI1PR07MB4735eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KQWxzbyB2YWxpZGF0aW9uIG9mIHJlcXVpcmVkIGlucHV0IGFuZCBvdXRwdXQg c2VlbXMgbW9yZSBjb21wbGljYXRlZCB0byBtZS4NCg0KSG93IHNvPw0KDQpUaGUg4oCYdmFsdWUt dG8tYmUtZ2VuZXJhdGVk4oCZIOKAnGFjdGlvbuKAnSB3b3VsZCByZXF1aXJlIGJvdGggdGhlIHBy aXZhdGUta2V5IGFuZCBwdWJsaWMta2V5IHNldCB0byB0aGUgc2FtZSwgcGx1cyB0aGUgYWxnb3Jp dGhtIGJlIGNvbmZpZ3VyZWQuIEJlc2lkZXMsIGlmIHRoZXJlIGlzIGEgbXVzdCBzdGF0ZW1lbnQg b24gYW55IG9mIHRoZXNlLCBkb2VzIHRoZSBtdXN0IHN0YXRlbWVudCBjb25zaWRlciB0aGUg4oCY aW5wdXTigJkgb3IgdGhlIOKAmG91dHB1dOKAmSB2YWx1ZXM/IEkgZ290IGEgYml0IGNvbmZ1c2Vk IHdoaWxlIHRoaW5raW5nIG9uIHRoZXNlLg0KDQogSeKAmW0gYWxzbyB0aGlua2luZyBkbyB3ZSBu ZWVkIHRoZSDigJhnZW5lcmF0ZS1hbmQtbm90LWhpZGXigJkgYW5kIHRoZSDigJhpbnN0YWxsLWFu ZC1oaWRl4oCZIHVzZSBjYXNlcz8NCg0KQWN0dWFsbHksIEkgdmlldyAg4oCYZ2VuZXJhdGUtYW5k LW5vdC1oaWRl4oCZIGFzIGEgdmVyeSBjb21tb24gY2FzZS4gIFRoYXQgaXMsIGFzayB0aGUgc3lz dGVtIHRvIGdlbmVyYXRlIHRoZSBrZXkgKGJlY2F1c2UgY2xpZW50cyBhcmUgbGF6eSBhbmQgc2Vj dXJpdHkgYmVzdCBwcmFjdGljZSksIGFuZCBsZXQgc3RhbmRhcmQgTkFDTSBydWxlcyBwcm90ZWN0 IHRoZSBrZXkuICAgSSB0aGluayB0aGF0IHN5c3RlbXMgc3VwcG9ydGluZyB1c2VyLWdlbmVyYXRl ZCAiaGlkZGVuIiBrZXlzIHdpbGwgYmUgc29tZXdoYXQgcmFyZSwgdG8gdGhlIGV4dGVudCB0aGF0 IHRoZXJlIHNob3VsZCBmZWF0dXJlIHN0YXRlbWVudHMgZW5hYmxpbmcgc2VydmVycyB0byBpbmRp Y2F0ZSBpZiB0aGV5IHN1cHBvcnQgdGhlIGFiaWxpdHkgb3Igbm90Lg0KDQpNYXliZSBnZW5lcmF0 ZS1hbmQtbm90LWhpZGUgd291bGQgYmUgd2lkZXNwcmVhZCwgYnV0IGl0IGlzIG5vdCBteSBwcmVm ZXJyZWQgY2hvaWNlIG9mIGtleSBoYW5kbGluZyBkdWUgdG8gdGhhdCBpdCBvcGVucyB1cCB0byB0 aGUgY2xpZW50IHRvIG1hbmFnZSB0aGUga2V5IGJsb2IgYWZ0ZXIgZmlyc3QgZ2VuZXJhdGlvbi4g U28gbWF5YmUgYWxsIG9mIHRoZXNlIHNob3VsZCBiZSBvcHRpb25hbCB3aXRoIGZlYXR1cmVzPw0K DQoNCndlIGhhdmU6DQoNCiAgIGxlYWYgcHJpdmF0ZS1rZXkgew0KICAgICBuYWNtOmRlZmF1bHQt ZGVueS1hbGw7DQogICAgIHR5cGUgdW5pb24gew0KICAgICAgIHR5cGUgYmluYXJ5Ow0KICAgICAg IHR5cGUgc3RyaW5nIHsNCiAgICAgICAgIHBhdHRlcm4NCiAgICAgICAgICAgJzxwZXJtYW5lbnRs eS1oaWRkZW4+Jw0KICAgICAgICAgKyAnfDxlbmNyeXB0ZWQgYnk9IioiPltBLVphLXowLTkrL10r Wz1dezEsM30nDQogICAgICAgfQ0KDQoNClRoaXMgcmVtb3ZlcyB0aGUgInZlcmJzIiAoYXMgeW91 IGNhbGwgdGhlbSkgYW5kIHRodXMgbGVhdmVzIG9wZW4gcG9zc2liaWxpdHkgZm9yIGVpdGhlciAi dmVyYnMiIG9yIGFjdGlvbiBzdGF0ZW1lbnRzIHRvIGJlIGFkZGVkIGluIHNvbWUgZnV0dXJlIHJl dmlzaW9uLiAgIFRoaXMgc3Vic2V0IHN0aWxsIHN1cHBvcnRzIHRoZSBjcml0aWNhbCB1c2UtY2Fz ZSBvZiBhIG1hbnVmYWN0dXJlci1nZW5lcmF0ZWQgcHJpdmF0ZSBrZXkgZm9yIGEgc2VjdXJlIGRl dmljZSBpZGVudGlmaWVyIChpLmUuLCBJRGV2SUQpLiAgICBVbmZvcnR1bmF0ZWx5LCBpdCBkb2Vz IG5vdCBzdXBwb3J0IHRoZSBzZWN1cml0eSBiZXN0IHByYWN0aWNlIHVzZS1jYXNlIG9mIGhhdmlu ZyB0aGUgZGV2aWNlIGdlbmVyYXRlIHRoZSBwcml2YXRlIGtleS4gIFRoZSBJRVNHIChTZWN1cml0 eSBEaXJlY3RvcmF0ZSkgbWF5IG9yIG1heSBub3QgYmUgb2theSB3aXRoIHRoaXMgKG9idmlvdXNs eSB0aGUgc2hlcGhlcmQgd291bGQgaGF2ZSB0byBicmluZyBpdCB0byB0aGVpciBhdHRlbnRpb24p LCBidXQgcGVyaGFwcyBpdCdzIHdvcnRoIHRlc3RpbmcgdGhlaXIgcmVzb2x2ZSBhbmQgc2VlIHdo YXQgaGFwcGVucz8NCg0KSWYgc28sIGNhbiB5b3UgY2xhcmlmeSB0aGUgY29uZmlndXJhdGlvbiB1 c2UgY2FzZSBvZiBjbGllbnQgY29uZmlndXJpbmcgPHBlcm1hbmVudGx5LWhpZGRlbj4sIGRvZXMg dGhhdCBwcm9kdWNlIGEgdmFsaWQgZW5kLXJlc3VsdD8gT3Igd291bGQgdGhhdCBiZSBvbmx5IGFu IG91dHB1dCBwYXR0ZXJuIGNyZWF0ZWQgYXMgdGhlIHJlc3VsdCBvZiBhIOKAmGdlbmVyYXRlLWhp ZGRlbi1rZXnigJkgYWN0aW9uIHRoYXQgbWF5IGJlIGFkZGVkIGJ5IGFuIGltcGxlbWVudGF0aW9u IGF1Z21lbnRpbmcgdGhlIG1vZGVsPw0KUmVnYXJkaW5nIOKAmGVuY3J5cHRlZCBieeKAmSwgd291 bGQgdGhhdCBiZSBvbmx5IHVzZWQgd2hlbiB0aGUgZGV2aWNlIGFsbG93cyB0byBiYWNrIHVwIGVu Y3J5cHRlZCBrZXlzIHRvIGxhdGVyIHJlc3RvcmUgaXQgdG8gc2FtZSBkZXZpY2UgKG9yIGFueSBv dGhlciB0aGF0IG1heSBnZXQgaG9sZCBvZiB0aGUgc2FtZSBlbmNyeXB0aW9uIGtleSBpbiBzb21l IHdheSk/DQoNCkJyLA0KQmFsYXpzDQoNCg0KRnJvbTogS2VudCBXYXRzZW4gPGtlbnRAd2F0c2Vu Lm5ldD4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMzAsIDIwMTkgNDoxNCBQTQ0KVG86IEJhbMOhenMg S292w6FjcyA8YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20+DQpDYzogbmV0Y29uZkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBpZXRmIGNyeXB0byB0eXBlcyAtIHBlcm1hbmVudGx5 IGhpZGRlbg0KDQoNCkhpIEJhbGF6cywNCg0KSW4gY2FzZSBvZiBjcnlwdC1oYXNoLCBJIGNhbiBh Y2NlcHQgdGhlIGV4dGVuc2lvbiBvZiB0aGUgY3J5cHQoMykgc2NoZW1lcyB3aXRoIGEgJDAkIHRo YXQgc29ydCBvZiByZXByZXNlbnRzIGEgaGFzaCgpIGFjdGlvbiwgc2luY2UgaXQgbWF0Y2hlcyB0 aGUgb3JpZ2luYWwgY3J5cHQoMykgc3ludGF4Lg0KDQpJbiB0aGlzIGNhc2UsIEkgZmluZCBpdCBh d2t3YXJkIHRvIHRlbGwgd2hhdCB0byBkbyB3aXRoIHRoZSBkYXRhICh2ZXJicykgYXMgcHJlZml4 ZXMgb2YgdGhlIGRhdGEuDQoNCkFncmVlZCwgYnV0IHdlIHNlZW0gdG8gYmUgYXQgYW4gaW1wYXNz ZSBhbmQgSSB0aG91Z2h0IHRoaXMgYXBwcm9hY2ggY291bGQgZ2V0IHVzIG92ZXIgdGhlIGxpbmUu DQoNCg0KDQpJIHBlcnNvbmFsbHkgcHJlZmVycmVkIGFjdGlvbnMgYmV0dGVyIGZvciB0aGlzIHB1 cnBvc2UuDQoNCkl0IGlzIG15IHByZWZlcmVuY2UgdG8gdXNlIGFjdGlvbnMgYXMgd2VsbCwgYnV0 IHRoZXJlJ3MgcHVzaGJhY2sgdGhlcmUuICBNYXliZSB3ZSBjb3VsZCBjbGFpbSB0aGF0IHRoZSBw dXNoYmFjayBpcyAiaW4gdGhlIHJvdWdoIiBhbmQgcHJlc3MgYWhlYWQgcmVnYXJkbGVzcywgYnV0 IEknZCByYXRoZXIgYXZvaWQgdGhhdCBpZiBwb3NzaWJsZS4NCg0KDQoNCkkgYXNzdW1lIHRoYXQg dGhpcyByZXByZXNlbnRhdGlvbiBhbHNvIGRvZXMgbm90IGNoYW5nZSB0aGUgbWF0dGVyIG9mIOKA nGFjdGlvbnPigJ0gYWZmZWN0aW5nIGNvbmZpZ3VyYXRpb24gKHNlZSDigJhvdXRwdXTigJkgdmFs dWVzKS4NCg0KWW91IG1lYW4sIGV4cGxvcmluZyB0aGlzIHNvbHV0aW9uIGxlYXZlcyB0aGUgImlz IGl0IHBvc3NpYmxlIGZvciBhY3Rpb25zIHRvIGFmZmVjdCBjb25maWd1cmF0aW9uIiBhcyB1bnJl c29sdmVkPyAgLSBjb3JyZWN0LCB0aGF0IGRpc2N1c3Npb24gd291bGQgcmVtYWluIG9wZW4uDQoN Cg0KDQpBbHNvIHZhbGlkYXRpb24gb2YgcmVxdWlyZWQgaW5wdXQgYW5kIG91dHB1dCBzZWVtcyBt b3JlIGNvbXBsaWNhdGVkIHRvIG1lLg0KDQpIb3cgc28/DQoNCg0KVGhlIGdlbmVyYXRlIGFjdGlv biByZXR1cm5pbmcgdGhlIG5hbWUgb2YgdGhlIGtleSBvciBvcHRpb25hbGx5IGNyZWF0aW5nIGNv bmZpZ3VyYXRpb24gc291bmRlZCBzbyBmYXIgdGhlIGNsb3Nlc3QgbWF0Y2ggdG8gbWUuDQoNClVu ZGVyc3Rvb2QuDQoNCg0KDQogSeKAmW0gYWxzbyB0aGlua2luZyBkbyB3ZSBuZWVkIHRoZSDigJhn ZW5lcmF0ZS1hbmQtbm90LWhpZGXigJkgYW5kIHRoZSDigJhpbnN0YWxsLWFuZC1oaWRl4oCZIHVz ZSBjYXNlcz8NCg0KQWN0dWFsbHksIEkgdmlldyAg4oCYZ2VuZXJhdGUtYW5kLW5vdC1oaWRl4oCZ IGFzIGEgdmVyeSBjb21tb24gY2FzZS4gIFRoYXQgaXMsIGFzayB0aGUgc3lzdGVtIHRvIGdlbmVy YXRlIHRoZSBrZXkgKGJlY2F1c2UgY2xpZW50cyBhcmUgbGF6eSBhbmQgc2VjdXJpdHkgYmVzdCBw cmFjdGljZSksIGFuZCBsZXQgc3RhbmRhcmQgTkFDTSBydWxlcyBwcm90ZWN0IHRoZSBrZXkuICAg SSB0aGluayB0aGF0IHN5c3RlbXMgc3VwcG9ydGluZyB1c2VyLWdlbmVyYXRlZCAiaGlkZGVuIiBr ZXlzIHdpbGwgYmUgc29tZXdoYXQgcmFyZSwgdG8gdGhlIGV4dGVudCB0aGF0IHRoZXJlIHNob3Vs ZCBmZWF0dXJlIHN0YXRlbWVudHMgZW5hYmxpbmcgc2VydmVycyB0byBpbmRpY2F0ZSBpZiB0aGV5 IHN1cHBvcnQgdGhlIGFiaWxpdHkgb3Igbm90Lg0KDQoNCi0tLQ0KDQpJJ20gZ3Jvd2luZyB3ZWFy eSBvZiB0aGlzIGRpc2N1c3Npb24uICBQZXJoYXBzIHdlIHNob3VsZCBkbyBldmVuIGxlc3MgZm9y IHRoZSBmaXJzdCByZWxlYXNlIG9mIHRoZSBjcnlwdG8tdHlwZXMgbW9kdWxlLiAgVGhhdCBpcywg aW5zdGVhZCBvZjoNCg0KICAgbGVhZiBwcml2YXRlLWtleSB7DQogICAgIG5hY206ZGVmYXVsdC1k ZW55LWFsbDsNCiAgICAgdHlwZSB1bmlvbiB7DQogICAgICAgdHlwZSBiaW5hcnk7DQogICAgICAg dHlwZSBzdHJpbmcgew0KICAgICAgICAgcGF0dGVybg0KICAgICAgICAgICAnPHBlcm1hbmVudGx5 LWhpZGRlbj4nDQogICAgICAgICArICd8PGVuY3J5cHRlZCBieT0iKiI+W0EtWmEtejAtOSsvXStb PV17MSwzfScNCiAgICAgICAgICsgJ3w8dmFsdWUtdG8tYmUtZ2VuZXJhdGVkKC1hbmQtaGlkZGVu KT8+Jw0KICAgICAgICAgKyAnfDx2YWx1ZS10by1iZS1oaWRkZW4+W0EtWmEtejAtOSsvXStbPV17 MSwzfSc7DQogICAgICAgfQ0KDQp3ZSBoYXZlOg0KDQogICBsZWFmIHByaXZhdGUta2V5IHsNCiAg ICAgbmFjbTpkZWZhdWx0LWRlbnktYWxsOw0KICAgICB0eXBlIHVuaW9uIHsNCiAgICAgICB0eXBl IGJpbmFyeTsNCiAgICAgICB0eXBlIHN0cmluZyB7DQogICAgICAgICBwYXR0ZXJuDQogICAgICAg ICAgICc8cGVybWFuZW50bHktaGlkZGVuPicNCiAgICAgICAgICsgJ3w8ZW5jcnlwdGVkIGJ5PSIq Ij5bQS1aYS16MC05Ky9dK1s9XXsxLDN9Jw0KICAgICAgIH0NCg0KDQpUaGlzIHJlbW92ZXMgdGhl ICJ2ZXJicyIgKGFzIHlvdSBjYWxsIHRoZW0pIGFuZCB0aHVzIGxlYXZlcyBvcGVuIHBvc3NpYmls aXR5IGZvciBlaXRoZXIgInZlcmJzIiBvciBhY3Rpb24gc3RhdGVtZW50cyB0byBiZSBhZGRlZCBp biBzb21lIGZ1dHVyZSByZXZpc2lvbi4gICBUaGlzIHN1YnNldCBzdGlsbCBzdXBwb3J0cyB0aGUg Y3JpdGljYWwgdXNlLWNhc2Ugb2YgYSBtYW51ZmFjdHVyZXItZ2VuZXJhdGVkIHByaXZhdGUga2V5 IGZvciBhIHNlY3VyZSBkZXZpY2UgaWRlbnRpZmllciAoaS5lLiwgSURldklEKS4gICAgVW5mb3J0 dW5hdGVseSwgaXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgc2VjdXJpdHkgYmVzdCBwcmFjdGljZSB1 c2UtY2FzZSBvZiBoYXZpbmcgdGhlIGRldmljZSBnZW5lcmF0ZSB0aGUgcHJpdmF0ZSBrZXkuICBU aGUgSUVTRyAoU2VjdXJpdHkgRGlyZWN0b3JhdGUpIG1heSBvciBtYXkgbm90IGJlIG9rYXkgd2l0 aCB0aGlzIChvYnZpb3VzbHkgdGhlIHNoZXBoZXJkIHdvdWxkIGhhdmUgdG8gYnJpbmcgaXQgdG8g dGhlaXIgYXR0ZW50aW9uKSwgYnV0IHBlcmhhcHMgaXQncyB3b3J0aCB0ZXN0aW5nIHRoZWlyIHJl c29sdmUgYW5kIHNlZSB3aGF0IGhhcHBlbnM/DQoNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoN Cg0K --_000_VI1PR07MB47351DBAC8B0C8EB8A6309D283190VI1PR07MB4735eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEtlbnQsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi41aW4i PkFsc28gdmFsaWRhdGlvbiBvZiByZXF1aXJlZCBpbnB1dCBhbmQgb3V0cHV0IHNlZW1zIG1vcmUg Y29tcGxpY2F0ZWQgdG8gbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SG93IHNvPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUg4oCYdmFsdWUtdG8tYmUtZ2VuZXJhdGVk4oCZIOKAnGFjdGlvbuKAnSB3 b3VsZCByZXF1aXJlIGJvdGggdGhlIHByaXZhdGUta2V5IGFuZCBwdWJsaWMta2V5IHNldCB0byB0 aGUgc2FtZSwgcGx1cyB0aGUgYWxnb3JpdGhtIGJlIGNvbmZpZ3VyZWQuIEJlc2lkZXMsIGlmIHRo ZXJlIGlzIGEgbXVzdCBzdGF0ZW1lbnQgb24gYW55IG9mIHRoZXNlLCBkb2VzIHRoZSBtdXN0IHN0 YXRlbWVudCBjb25zaWRlciB0aGUg4oCYaW5wdXTigJkNCiBvciB0aGUg4oCYb3V0cHV04oCZIHZh bHVlcz8gSSBnb3QgYSBiaXQgY29uZnVzZWQgd2hpbGUgdGhpbmtpbmcgb24gdGhlc2UuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7SeKAmW0g YWxzbyB0aGlua2luZyBkbyB3ZSBuZWVkIHRoZSDigJhnZW5lcmF0ZS1hbmQtbm90LWhpZGXigJkg YW5kIHRoZSDigJhpbnN0YWxsLWFuZC1oaWRl4oCZIHVzZSBjYXNlcz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5BY3R1YWxseSwgSSB2aWV3Jm5ic3A7Jm5ic3A74oCYZ2VuZXJhdGUtYW5kLW5vdC1oaWRl4oCZ Jm5ic3A7YXMgYSB2ZXJ5IGNvbW1vbiBjYXNlLiAmbmJzcDtUaGF0IGlzLCBhc2sgdGhlIHN5c3Rl bSB0byBnZW5lcmF0ZSB0aGUga2V5IChiZWNhdXNlIGNsaWVudHMgYXJlIGxhenkgYW5kIHNlY3Vy aXR5IGJlc3QgcHJhY3RpY2UpLCBhbmQgbGV0IHN0YW5kYXJkIE5BQ00gcnVsZXMgcHJvdGVjdCB0 aGUga2V5LiAmbmJzcDsNCiBJIHRoaW5rIHRoYXQgc3lzdGVtcyBzdXBwb3J0aW5nIHVzZXItZ2Vu ZXJhdGVkICZxdW90O2hpZGRlbiZxdW90OyBrZXlzIHdpbGwgYmUgc29tZXdoYXQgcmFyZSwgdG8g dGhlIGV4dGVudCB0aGF0IHRoZXJlIHNob3VsZCBmZWF0dXJlIHN0YXRlbWVudHMgZW5hYmxpbmcg c2VydmVycyB0byBpbmRpY2F0ZSBpZiB0aGV5IHN1cHBvcnQgdGhlIGFiaWxpdHkgb3Igbm90Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBnZW5lcmF0ZS1hbmQtbm90LWhpZGUgd291bGQg YmUgd2lkZXNwcmVhZCwgYnV0IGl0IGlzIG5vdCBteSBwcmVmZXJyZWQgY2hvaWNlIG9mIGtleSBo YW5kbGluZyBkdWUgdG8gdGhhdCBpdCBvcGVucyB1cCB0byB0aGUgY2xpZW50IHRvIG1hbmFnZSB0 aGUga2V5IGJsb2IgYWZ0ZXIgZmlyc3QgZ2VuZXJhdGlvbi4gU28gbWF5YmUgYWxsIG9mIHRoZXNl IHNob3VsZCBiZSBvcHRpb25hbCB3aXRoIGZlYXR1cmVzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj53ZSBoYXZlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAmbmJzcDtsZWFm IHByaXZhdGUta2V5IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO25hY206ZGVmYXVsdC1kZW55 LWFsbDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdW5pb24gezxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgYmluYXJ5Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3R5cGUgc3RyaW5nIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cGF0dGVybjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JyZsdDtwZXJtYW5lbnRseS1oaWRkZW4mZ3Q7Jzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmIzQzOyAnfCZsdDtlbmNyeXB0ZWQgYnk9JnF1b3Q7KiZxdW90OyZndDtbQS1a YS16MC05JiM0MzsvXSYjNDM7Wz1dezEsM30nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoaXMgcmVtb3ZlcyB0aGUgJnF1b3Q7 dmVyYnMmcXVvdDsgKGFzIHlvdSBjYWxsIHRoZW0pIGFuZCB0aHVzIGxlYXZlcyBvcGVuIHBvc3Np YmlsaXR5IGZvciBlaXRoZXIgJnF1b3Q7dmVyYnMmcXVvdDsgb3IgYWN0aW9uIHN0YXRlbWVudHMg dG8gYmUgYWRkZWQgaW4gc29tZSBmdXR1cmUgcmV2aXNpb24uICZuYnNwOyBUaGlzIHN1YnNldCBz dGlsbCBzdXBwb3J0cyB0aGUgY3JpdGljYWwgdXNlLWNhc2Ugb2YgYSBtYW51ZmFjdHVyZXItZ2Vu ZXJhdGVkDQogcHJpdmF0ZSBrZXkgZm9yIGEgc2VjdXJlIGRldmljZSBpZGVudGlmaWVyIChpLmUu LCBJRGV2SUQpLiAmbmJzcDsgJm5ic3A7VW5mb3J0dW5hdGVseSwgaXQgZG9lcyBub3Qgc3VwcG9y dCB0aGUgc2VjdXJpdHkgYmVzdCBwcmFjdGljZSB1c2UtY2FzZSBvZiBoYXZpbmcgdGhlIGRldmlj ZSBnZW5lcmF0ZSB0aGUgcHJpdmF0ZSBrZXkuICZuYnNwO1RoZSBJRVNHIChTZWN1cml0eSBEaXJl Y3RvcmF0ZSkgbWF5IG9yIG1heSBub3QgYmUgb2theSB3aXRoIHRoaXMgKG9idmlvdXNseQ0KIHRo ZSBzaGVwaGVyZCB3b3VsZCBoYXZlIHRvIGJyaW5nIGl0IHRvIHRoZWlyIGF0dGVudGlvbiksIGJ1 dCBwZXJoYXBzIGl0J3Mgd29ydGggdGVzdGluZyB0aGVpciByZXNvbHZlIGFuZCBzZWUgd2hhdCBo YXBwZW5zPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBzbywgY2FuIHlvdSBjbGFyaWZ5IHRo ZSBjb25maWd1cmF0aW9uIHVzZSBjYXNlIG9mIGNsaWVudCBjb25maWd1cmluZyAmbHQ7cGVybWFu ZW50bHktaGlkZGVuJmd0OywgZG9lcyB0aGF0IHByb2R1Y2UgYSB2YWxpZCBlbmQtcmVzdWx0PyBP ciB3b3VsZCB0aGF0IGJlIG9ubHkgYW4gb3V0cHV0IHBhdHRlcm4gY3JlYXRlZCBhcyB0aGUgcmVz dWx0IG9mIGEg4oCYZ2VuZXJhdGUtaGlkZGVuLWtleeKAmSBhY3Rpb24gdGhhdCBtYXkNCiBiZSBh ZGRlZCBieSBhbiBpbXBsZW1lbnRhdGlvbiBhdWdtZW50aW5nIHRoZSBtb2RlbD88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyDigJhlbmNyeXB0ZWQgYnnigJks IHdvdWxkIHRoYXQgYmUgb25seSB1c2VkIHdoZW4gdGhlIGRldmljZSBhbGxvd3MgdG8gYmFjayB1 cCBlbmNyeXB0ZWQga2V5cyB0byBsYXRlciByZXN0b3JlIGl0IHRvIHNhbWUgZGV2aWNlIChvciBh bnkgb3RoZXIgdGhhdCBtYXkgZ2V0IGhvbGQgb2YgdGhlIHNhbWUgZW5jcnlwdGlvbiBrZXkgaW4g c29tZSB3YXkpPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cciw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJhbGF6czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEtlbnQg V2F0c2VuICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTWF5IDMwLCAyMDE5IDQ6MTQgUE08YnI+DQo8Yj5Ubzo8L2I+IEJhbMOhenMgS292w6FjcyAm bHQ7YmFsYXpzLmtvdmFjc0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRjb25m QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gaWV0ZiBjcnlwdG8g dHlwZXMgLSBwZXJtYW5lbnRseSBoaWRkZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpIEJhbGF6cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNhc2Ugb2YgY3J5cHQtaGFzaCwgSSBjYW4g YWNjZXB0IHRoZSBleHRlbnNpb24gb2YgdGhlIGNyeXB0KDMpIHNjaGVtZXMgd2l0aCBhICQwJCB0 aGF0IHNvcnQgb2YgcmVwcmVzZW50cyBhIGhhc2goKSBhY3Rpb24sIHNpbmNlIGl0IG1hdGNoZXMg dGhlIG9yaWdpbmFsIGNyeXB0KDMpIHN5bnRheC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBjYXNlLCBJIGZpbmQgaXQgYXdrd2Fy ZCB0byB0ZWxsIHdoYXQgdG8gZG8gd2l0aCB0aGUgZGF0YSAodmVyYnMpIGFzIHByZWZpeGVzIG9m IHRoZSBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZCwgYnV0IHdlIHNlZW0gdG8gYmUg YXQgYW4gaW1wYXNzZSBhbmQgSSB0aG91Z2h0IHRoaXMgYXBwcm9hY2ggY291bGQgZ2V0IHVzIG92 ZXIgdGhlIGxpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBwZXJzb25hbGx5IHByZWZlcnJlZCBhY3Rpb25zIGJldHRlciBmb3IgdGhp cyBwdXJwb3NlLiA8bzpwPg0KPC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIG15IHByZWZlcmVuY2UgdG8g dXNlIGFjdGlvbnMgYXMgd2VsbCwgYnV0IHRoZXJlJ3MgcHVzaGJhY2sgdGhlcmUuICZuYnNwO01h eWJlIHdlIGNvdWxkIGNsYWltIHRoYXQgdGhlIHB1c2hiYWNrIGlzICZxdW90O2luIHRoZSByb3Vn aCZxdW90OyBhbmQgcHJlc3MgYWhlYWQgcmVnYXJkbGVzcywgYnV0IEknZCByYXRoZXIgYXZvaWQg dGhhdCBpZiBwb3NzaWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFzc3VtZSB0aGF0IHRoaXMgcmVwcmVzZW50YXRpb24g YWxzbyBkb2VzIG5vdCBjaGFuZ2UgdGhlIG1hdHRlciBvZiDigJxhY3Rpb25z4oCdIGFmZmVjdGlu ZyBjb25maWd1cmF0aW9uIChzZWUg4oCYb3V0cHV04oCZIHZhbHVlcykuDQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Zb3UgbWVhbiwgZXhwbG9yaW5nIHRoaXMgc29sdXRpb24gbGVhdmVzIHRoZSAmcXVv dDtpcyBpdCBwb3NzaWJsZSBmb3IgYWN0aW9ucyB0byBhZmZlY3QgY29uZmlndXJhdGlvbiZxdW90 OyBhcyB1bnJlc29sdmVkPyAmbmJzcDstIGNvcnJlY3QsIHRoYXQgZGlzY3Vzc2lvbiB3b3VsZCBy ZW1haW4gb3Blbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbHNvIHZhbGlkYXRpb24gb2YgcmVxdWlyZWQgaW5wdXQgYW5kIG91dHB1dCBz ZWVtcyBtb3JlIGNvbXBsaWNhdGVkIHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBzbz88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBnZW5lcmF0ZSBhY3Rpb24gcmV0dXJuaW5nIHRoZSBuYW1lIG9mIHRoZSBrZXkgb3Igb3B0 aW9uYWxseSBjcmVhdGluZyBjb25maWd1cmF0aW9uIHNvdW5kZWQgc28gZmFyIHRoZSBjbG9zZXN0 IG1hdGNoIHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlVuZGVyc3Rvb2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7SeKAmW0gYWxzbyB0aGlua2luZyBk byB3ZSBuZWVkIHRoZSDigJhnZW5lcmF0ZS1hbmQtbm90LWhpZGXigJkgYW5kIHRoZSDigJhpbnN0 YWxsLWFuZC1oaWRl4oCZIHVzZSBjYXNlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY3R1YWxseSwgSSB2aWV3Jm5ic3A7Jm5i c3A74oCYZ2VuZXJhdGUtYW5kLW5vdC1oaWRl4oCZJm5ic3A7YXMgYSB2ZXJ5IGNvbW1vbiBjYXNl LiAmbmJzcDtUaGF0IGlzLCBhc2sgdGhlIHN5c3RlbSB0byBnZW5lcmF0ZSB0aGUga2V5IChiZWNh dXNlIGNsaWVudHMgYXJlIGxhenkgYW5kIHNlY3VyaXR5IGJlc3QgcHJhY3RpY2UpLCBhbmQgbGV0 IHN0YW5kYXJkIE5BQ00gcnVsZXMgcHJvdGVjdCB0aGUga2V5LiAmbmJzcDsgSSB0aGluayB0aGF0 IHN5c3RlbXMgc3VwcG9ydGluZw0KIHVzZXItZ2VuZXJhdGVkICZxdW90O2hpZGRlbiZxdW90OyBr ZXlzIHdpbGwgYmUgc29tZXdoYXQgcmFyZSwgdG8gdGhlIGV4dGVudCB0aGF0IHRoZXJlIHNob3Vs ZCBmZWF0dXJlIHN0YXRlbWVudHMgZW5hYmxpbmcgc2VydmVycyB0byBpbmRpY2F0ZSBpZiB0aGV5 IHN1cHBvcnQgdGhlIGFiaWxpdHkgb3Igbm90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gZ3Jvd2luZyB3ZWFyeSBvZiB0aGlzIGRp c2N1c3Npb24uICZuYnNwO1BlcmhhcHMgd2Ugc2hvdWxkIGRvIGV2ZW4gbGVzcyBmb3IgdGhlIGZp cnN0IHJlbGVhc2Ugb2YgdGhlIGNyeXB0by10eXBlcyBtb2R1bGUuICZuYnNwO1RoYXQgaXMsIGlu c3RlYWQgb2Y6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtsZWFmIHByaXZhdGUta2V5IHs8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwO25hY206ZGVmYXVsdC1kZW55LWFsbDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3R5 cGUgdW5pb24gezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgYmluYXJ5Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgc3RyaW5nIHs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF0dGVybjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JyZsdDtwZXJtYW5lbnRseS1oaWRkZW4mZ3Q7Jzxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOyAnfCZsdDtlbmNyeXB0ZWQg Ynk9JnF1b3Q7KiZxdW90OyZndDtbQS1aYS16MC05JiM0MzsvXSYjNDM7Wz1dezEsM30nPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7ICd8Jmx0O3ZhbHVlLXRvLWJl LWdlbmVyYXRlZCgtYW5kLWhpZGRlbik/Jmd0Oyc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzsgJ3wmbHQ7dmFsdWUtdG8tYmUtaGlkZGVuJmd0O1tBLVphLXowLTkm IzQzOy9dJiM0MztbPV17MSwzfSc7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZSBo YXZlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7bGVhZiBwcml2YXRlLWtleSB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDtuYWNtOmRlZmF1bHQtZGVueS1hbGw7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIHVu aW9uIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGJpbmFyeTs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIHN0cmluZyB7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BhdHRlcm48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOycmbHQ7cGVybWFuZW50bHktaGlkZGVuJmd0Oyc8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzsgJ3wmbHQ7ZW5jcnlwdGVkIGJ5PSZx dW90OyomcXVvdDsmZ3Q7W0EtWmEtejAtOSYjNDM7L10mIzQzO1s9XXsxLDN9Jzxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHJlbW92ZXMgdGhlICZxdW90O3ZlcmJzJnF1b3Q7 IChhcyB5b3UgY2FsbCB0aGVtKSBhbmQgdGh1cyBsZWF2ZXMgb3BlbiBwb3NzaWJpbGl0eSBmb3Ig ZWl0aGVyICZxdW90O3ZlcmJzJnF1b3Q7IG9yIGFjdGlvbiBzdGF0ZW1lbnRzIHRvIGJlIGFkZGVk IGluIHNvbWUgZnV0dXJlIHJldmlzaW9uLiAmbmJzcDsgVGhpcyBzdWJzZXQgc3RpbGwgc3VwcG9y dHMgdGhlIGNyaXRpY2FsIHVzZS1jYXNlIG9mIGEgbWFudWZhY3R1cmVyLWdlbmVyYXRlZCBwcml2 YXRlDQoga2V5IGZvciBhIHNlY3VyZSBkZXZpY2UgaWRlbnRpZmllciAoaS5lLiwgSURldklEKS4g Jm5ic3A7ICZuYnNwO1VuZm9ydHVuYXRlbHksIGl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIHNlY3Vy aXR5IGJlc3QgcHJhY3RpY2UgdXNlLWNhc2Ugb2YgaGF2aW5nIHRoZSBkZXZpY2UgZ2VuZXJhdGUg dGhlIHByaXZhdGUga2V5LiAmbmJzcDtUaGUgSUVTRyAoU2VjdXJpdHkgRGlyZWN0b3JhdGUpIG1h eSBvciBtYXkgbm90IGJlIG9rYXkgd2l0aCB0aGlzIChvYnZpb3VzbHkgdGhlIHNoZXBoZXJkDQog d291bGQgaGF2ZSB0byBicmluZyBpdCB0byB0aGVpciBhdHRlbnRpb24pLCBidXQgcGVyaGFwcyBp dCdzIHdvcnRoIHRlc3RpbmcgdGhlaXIgcmVzb2x2ZSBhbmQgc2VlIHdoYXQgaGFwcGVucz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50 IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR07MB47351DBAC8B0C8EB8A6309D283190VI1PR07MB4735eurp_-- From nobody Fri May 31 15:19:48 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902991200FF for ; Fri, 31 May 2019 15:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4O26GigeGtoP for ; Fri, 31 May 2019 15:19:43 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 E368E120020 for ; Fri, 31 May 2019 15:19:42 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id t1so1250182pgc.2 for ; Fri, 31 May 2019 15:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=j2kYDGRr4DcQHsVb+cmxBXykh6W99M91bctq0hrdSBU=; b=cDNXIBRbzHYNa0FOFEZnde+7DLwS5FJ9W5VQRyZBZhDN9gBWj+yNcQO2vixgBBeHXf v8sOpBpPgDU6dGZLnLgcgzA/FsWC1GKz9j2VHXkao0JvuTJqRVl8UqfrlRyFbeg+1gqz HaeJ4HzQPI/c9iLUtQf2shcICQ4DWN4fxCipS+nlUKS+bDeliUhWpEM4XUDyddKIqXs+ xHorJ+DDoARxmUhVcqlozJZDeU/IsDoW7FzWoVnlfPMD05+GaLXVLEG+PI0YXydgBa6l jeuvMNyyoPNoQ6/MGpaaXYL4mIJ4lCohRJ07wlAnNHVn/+ATuu7KFub7sLfHREH+j6DC 0gew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=j2kYDGRr4DcQHsVb+cmxBXykh6W99M91bctq0hrdSBU=; b=kYrUpJb8XapAUbrJTX9dUy9q5CwQbeUgho6Nvj/Vw1VsTX+y4Btp5lKwAkv4ZLGILm zJyXW3Af4GJ/R2OdNy7nYmo4YzASS3XXcj0j3hhY1v/3nZb+CYawdWhZ3LxJc8xkSBFz vKWhnBSnI1gQhQFHw8XgqYpTzTVpx00QCRB7Q+JtNii0XdBm0fIwlenHL2mUbdx3mszd xcbktXzKKaqqlJzEm/5Ft7uED0ccGi5hsutS0vmPeXS/1X5C2xY2ntgKo1ZLjaMSxfDu DeCKVR/Fy1dH40vNWlAvTQXzExZd789PP4z4JJ0Dlvk9TIdCm31zqf9S4YeGbMz/oyvq NR+g== X-Gm-Message-State: APjAAAVmlNoAVqsCG7YuYY/TwX/Vz85Jw+g/rWO878SniB/gjmp8fzKl yY4e/yIH+pn9GPF9NzZGKPrDtAdD X-Google-Smtp-Source: APXvYqxil9EaDbNcOoKSH6VjyKqJj2HqtOSJfvsIDwUrgOKXEPsW49gNBSPUNogUKhAZkwvhSC47CQ== X-Received: by 2002:aa7:8b17:: with SMTP id f23mr7734583pfd.194.1559341182024; Fri, 31 May 2019 15:19:42 -0700 (PDT) Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id v9sm6778762pfm.34.2019.05.31.15.19.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 May 2019 15:19:41 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_4D40E664-11C6-47F5-A0C7-5643ADCD4BE6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 31 May 2019 15:19:40 -0700 References: <0100016aa75956af-70018fb1-15f8-4394-8ffd-4f4d5b2d7b3f-000000@email.amazonses.com> <0100016ab7a9af7e-cd7f776e-79e1-42a4-9c5d-d04aed0d8fa1-000000@email.amazonses.com> <76ED75C8-AA1A-4A03-A382-0DE834C914A1@gmail.com> <0100016abd77bfe3-88ae515a-d7f9-41c7-b627-9c51bdf16213-000000@email.amazonses.com> <884391D0-3F53-4F3D-BFB0-DD333D09507C@gmail.com> <00d101d51216$f807d120$e8177360$@hansfords.net> To: Netconf In-Reply-To: <00d101d51216$f807d120$e8177360$@hansfords.net> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] RFC 6241 Ambiguity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 22:19:46 -0000 --Apple-Mail=_4D40E664-11C6-47F5-A0C7-5643ADCD4BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Several attempts have been made to clarify the role of confirmed commit = in RFC 6241 vis-a-vis Section 7.8 and Section 7.9 = , and the text in Section 8.4 Confirmed Commit Capability. We, (the chairs) believe that the best way to resolve issues with the = current set of erratum that already exist or are being proposed is to = minimize re-explaining the role of confirmed commit in both Section 7.8 = and 7.9 and defer the explanation to Section 8.4 of the RFC. With that = in mind, we are proposing that Section 7.8 and 7.9 should ultimately = look as follows. Note, the highlights in all the sections are to enable = identifying the changes. =20 OLD (as in original RFC 6241) 7.8 . Description: Request graceful termination of a NETCONF session. When a NETCONF server receives a request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a request will be ignored. Positive Response: If the device was able to satisfy the request, an is sent that includes an element. Negative Response: An element is included in the if the request cannot be completed for any reason. Example: NEW 7.8 . Description: Request graceful termination of a NETCONF session. When a NETCONF server receives a request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a request will be ignored. For details on what happens if a NETCONF server receives a=20 request while processing a confirmed commit, please refer to Section 8.4 = . Positive Response: If the device was able to satisfy the request, an is sent that includes an element. Negative Response: An element is included in the if the request cannot be completed for any reason. Example: OLD (as in original RFC 6241). 7.9 . Description: Force the termination of a NETCONF session. When a NETCONF entity receives a request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. If a NETCONF server receives a request while processing a confirmed commit (Section 8.4 = ), it MUST restore the configuration to its state before the confirmed commit was issued. Otherwise, the operation does not roll back configuration or other device state modifications made by the entity holding the lock. Parameters: session-id: Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an "invalid-value" error is returned. Positive Response: If the device was able to satisfy the request, an is sent that includes an element. Negative Response: An element is included in the if the request cannot be completed for any reason. Example: 4 NEW 7.9 . Description: Force the termination of a NETCONF session. When a NETCONF entity receives a request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. For details on what happens if a NETCONF server receives a=20 request while processing a confirmed commit, please refer to Section 8.4 = . Otherwise, the operation does not roll back configuration or other device state modifications made by the entity holding the lock. Parameters: session-id: Session identifier of the NETCONF session to be terminated. If this value is equal to the current session ID, an "invalid-value" error is returned. Positive Response: If the device was able to satisfy the request, an is sent that includes an element. Negative Response: An element is included in the if the request cannot be completed for any reason. Example: 4 In addition, the following paragraph in Section 8.4.1 would be modified. OLD: If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued. NEW: If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit=20= also included a element. Current Erratums for RFC 6241 will be adjusted to accommodate these = changes. Mahesh & Kent (co-chairs) --Apple-Mail=_4D40E664-11C6-47F5-A0C7-5643ADCD4BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Several attempts have been made to clarify the role of = confirmed commit in RFC 6241 vis-a-vis Section 7.8 <close-session> = and Section 7.9 <kill-session>, and the text in Section 8.4 = Confirmed Commit Capability.

We, (the chairs) believe that the best way to resolve issues = with the current set of erratum that already exist or are being proposed = is to minimize re-explaining the role of confirmed commit in both = Section 7.8 and 7.9 and defer the explanation to Section 8.4 of the RFC. = With that in mind, we are proposing that Section 7.8 and 7.9 should = ultimately look as follows. Note, the highlights in all the sections are = to enable identifying the changes.

 

OLD (as in original RFC 6241)

7.8.  = <close-session>

   Description:  = Request graceful termination of a NETCONF session.

    =   When a NETCONF server receives a <close-session> request, = it will
    =   gracefully close the session.  The server will release any = locks
    =   and resources associated with the session and gracefully close = any
    =   associated connections.  Any NETCONF requests received after = a
    =   <close-session> request will be ignored.

   = Positive Response:  If the device was able to satisfy the request, = an
    =   <rpc-reply> is sent that includes an <ok> = element.

   Negative Response:  An <rpc-error> = element is included in the
      <rpc-reply> if the request cannot = be completed for any reason.

   = Example:

     <rpc message-id=3D"101"
        =   = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <close-session/>
     </rpc>

   =   <rpc-reply message-id=3D"101"
          = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <ok/>
   =   </rpc-reply>

NEW

7.8.  = <close-session>

   Description:  = Request graceful termination of a NETCONF session.

    =   When a NETCONF server receives a <close-session> request, = it will
    =   gracefully close the session.  The server will release any = locks
    =   and resources associated with the session and gracefully close = any
    =   associated connections.  Any NETCONF requests received after = a
    =   <close-session> request will be ignored.

      For details on what happens if a = NETCONF server receives a 
      = <close-session> request while processing a confirmed = commit,
      please refer to Section 8.4.

   Positive = Response:  If the device was able to satisfy the request, = an
    =   <rpc-reply> is sent that includes an <ok> = element.

   Negative Response:  An <rpc-error> = element is included in the
      <rpc-reply> if the request cannot = be completed for any reason.

   = Example:

     <rpc message-id=3D"101"
        =   = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <close-session/>
     </rpc>

   =   <rpc-reply message-id=3D"101"
          = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <ok/>
   =   </rpc-reply>

OLD (as in original RFC = 6241).

7.9.  = <kill-session>

   Description:  = Force the termination of a NETCONF session.

    =   When a NETCONF entity receives a <kill-session> request for = an
    =   open session, it will abort any operations currently in = process,
    =   release any locks and resources associated with the session, = and
    =   close any associated connections.

      If a = NETCONF server receives a <kill-session> request = while
    =   processing a confirmed commit (Section 8.4), it MUST restore the
      = configuration to its state before the confirmed commit was = issued.

      Otherwise, the <kill-session> = operation does not roll back
      configuration or other device state = modifications made by the
      entity holding the = lock.

   Parameters:

      = session-id:  Session identifier of the NETCONF session to = be
   =       terminated.  If this value is equal to the = current session ID,
   =       an "invalid-value" error is = returned.

   Positive Response:  If the device was able = to satisfy the request, an
      <rpc-reply> is sent that includes = an <ok> element.

   Negative = Response:  An <rpc-error> element is included in = the
    =   <rpc-reply> if the request cannot be completed for any = reason.


   = Example:

     <rpc message-id=3D"101"
        =   = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <kill-session>
         = <session-id>4</session-id>
       = </kill-session>
     </rpc>

   =   <rpc-reply message-id=3D"101"
          = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <ok/>
   =   </rpc-reply>

NEW

7.9.  = <kill-session>

   Description:  = Force the termination of a NETCONF session.

    =   When a NETCONF entity receives a <kill-session> request for = an
    =   open session, it will abort any operations currently in = process,
    =   release any locks and resources associated with the session, = and
    =   close any associated connections.

      For details on what happens if a NETCONF server = receives a 
      <kill-session> request while = processing a confirmed commit,
      please = refer to Section 8.4.

    =   Otherwise, the <kill-session> operation does not roll = back
    =   configuration or other device state modifications made by = the
    =   entity holding the lock.

   = Parameters:

      session-id:  Session identifier of = the NETCONF session to be
         terminated.  If this = value is equal to the current session ID,
       =   an "invalid-value" error is returned.

   = Positive Response:  If the device was able to satisfy the request, = an
    =   <rpc-reply> is sent that includes an <ok> = element.

   Negative Response:  An <rpc-error> = element is included in the
      <rpc-reply> if the request cannot = be completed for any reason.


   = Example:

     <rpc message-id=3D"101"
        =   = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <kill-session>
         = <session-id>4</session-id>
       = </kill-session>
     </rpc>

   =   <rpc-reply message-id=3D"101"
          = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       = <ok/>
   =   </rpc-reply>


In= addition, the following paragraph in Section 8.4.1 would be = modified.

OLD:

   If = the device reboots for any reason before the confirm = timeout
   = expires, the server MUST restore the configuration to its = state
   = before the confirmed commit was issued.


NEW:

   If = the device reboots for any reason before the confirm = timeout
   = expires, the server MUST restore the configuration to its = state
   = before the confirmed commit was issued, unless the = confirmed commit 
   also included a = <persist> element.

Current Erratums for RFC 6241 will be = adjusted to accommodate these changes.

Mahesh & = Kent (co-chairs)


= --Apple-Mail=_4D40E664-11C6-47F5-A0C7-5643ADCD4BE6--