From nobody Sat Feb 1 00:09:28 2020 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 89415120112 for ; Sat, 1 Feb 2020 00:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.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 yJybCasAEXKW for ; Sat, 1 Feb 2020 00:09:21 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10062.outbound.protection.outlook.com [40.107.1.62]) (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 2DA0712004C for ; Sat, 1 Feb 2020 00:09:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QttnkCS9ukDCwe30rgkEtWqK4TGtvi6Xml7QF67kUdUshMeJs1qB3XaCC/xtu7d9np+WSezOPj6mscNEK309cDmnxMkmAwd8B37gGpv7H7zIDX8JX5yQJZRV+iFqREylHh5CtXBApW+RjMnmQde/qa7AcMEVTGpoGCHLk8qbkXjIoDz0TQ36CYqOcG9o2hwIvF9cRmRUUAQ8vdakOj0v2EMf1kV+47Tfeeo/28uuBefptHkH0LjjhlBXWdUv62VBZtXi5tFEHME9Y8Dej/A+9q8IwmRqniQQ+EV3ReNxeaSAaYChP8C1nynKfUSTtdUIpCqEc3x7TwlR1gGJYOImog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0hFJUFD7NntkEbyRSrMcnYYtgil9o3UTD6LK8DJ57f4=; b=R3qLu4pDChFH/7RQGl8DDePf47k1om/18PcD9vhfzCm4TJKtrrJ3cxlEUtSpZ+XZOuXK9Ti+SJCr6ZABbcUT6HWbfE8a3fi95S54gvWnZLC89QEOzGHHFK7i1gc46hB0t4LfuikImXjNwqIc1QiE+Wpja3RKW2KEcq8KMBpvFzNi87ek/mxs3RT3XldQLVvSuRm6NUrJZHtq8t+z5rWbeGvFdXNKgdX5v8oABxk8z45P0c8coztwPnbsPa/1soQ4tJkBNoo6NNkyCidV2mo8hbrwUNkC79+IjbcsJ9O5OhI0Ak49OtTnHXLaPGHqoUXWwTdWc5RZp5CreqgMLiDpeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0hFJUFD7NntkEbyRSrMcnYYtgil9o3UTD6LK8DJ57f4=; b=YUeAqZBuUmtJRo6Biuha//dMehGVKbUsxIiUX5FN9/sBKUlDIWY1DSldLb3uRmPN0MCiBHq/Jy/7ZDaN9cOow/ie3tQXOEbSjNZ//TwxVuDBd3lTnWUEo0AxuDxYUrotKev/PCPiiGKBZKFc04Xu0VAIM5rLjJQQX1XBLtaeN4s= Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0517.EURP190.PROD.OUTLOOK.COM (10.165.140.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Sat, 1 Feb 2020 08:09:17 +0000 Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946%6]) with mapi id 15.20.2665.027; Sat, 1 Feb 2020 08:09:17 +0000 Received: from localhost (2001:638:709:5::7) by FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.28 via Frontend Transport; Sat, 1 Feb 2020 08:09:17 +0000 From: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= To: Kent Watsen CC: Martin Bjorklund , Russ Housley , "netconf@ietf.org" Thread-Topic: [netconf] Truststore: bags, sets, or other? Thread-Index: AQHV2IKuy7SZ9bYHJ0yrmq5smVlPU6gF/MUA Date: Sat, 1 Feb 2020 08:09:17 +0000 Message-ID: <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> In-Reply-To: <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> Reply-To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33e65517-3a9d-432b-f350-08d7a6ee08a8 x-ms-traffictypediagnostic: DB6P190MB0517: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39840400004)(136003)(346002)(199004)(189003)(66476007)(66556008)(66446008)(64756008)(85202003)(66946007)(1076003)(5660300002)(85182001)(4326008)(54906003)(6496006)(52116002)(316002)(786003)(186003)(16526019)(6486002)(8936002)(81166006)(86362001)(81156014)(478600001)(966005)(3716004)(71200400001)(3450700001)(2906002)(8676002)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0517; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rtUcirO1X34y06YZPz3UB7BWSEePUYhJD9HEHJn2L1C8ftwl2Auw4V/ZOND5BtRteEulN0F0Hnh3HmLCzMX9eb07m0IE8/S6w5hPyNgKs50lriCX6wVMeqthV1FvG9x3wXJWKotRFvR3yd+dPqrYEmU0fe2z9UBhCezvON8SFGy5nxQ3m7dBfyC+QLQNWhxs88PEBWNbTK451j/+PQMqk3W6bcdmfkR5G6ncYLX4DROaIdyKdIn16YFDgcsGmu6iBeNVwKPxVHmQ/ruzm/xx1czR0YvmCjF6cg6MmPVwO6gmlBgW4hFcFWf3KLaBrPwqcd1qGPGkiNrmDuYPHuePIvkInzx4ejIRG/zN24PgKRk1xQUjkqQ5F+39mmm49u5v6QzUMaC/zb3ohdugamg79aZOW6Eja2UQ8i/9pXqJ+uV4DDfE2vO3aye7h+CE6Yw4yURtxF6svef3FbgTKXp2x5usnTrMZswKpDfIXzVbFhighBK5mW031KYqKkbgNYfAWyvZcWzCvflMRtxaI0dH8ZBBkTg7IJTOwOCnQmZanUxMinE+nphJzyr/nuIwGduS x-ms-exchange-antispam-messagedata: FEyLjnsw2XNQC5eAKtUcue1v4tzvnwIuCCDG4gQ9lxFYkafRkrvBRrTW9FEu5yxGRE4IaqRwaUjzscM7K5jPJSTaIUXPgSQprhk1lmaS0vGgvIkPLwJk+P964cis58U/PfYn4/pOUfCh5XFe/a7jmNa2WhmMJbqGCi6+3smy4vU= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 33e65517-3a9d-432b-f350-08d7a6ee08a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2020 08:09:17.6210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m9RTE6BWhlOiKf4zY0M00FSwDBGXtVbgpW3ZuEDoV61yI6EzRM4DxKHPnyCOlGxmlETOsSMp6/Fei/Rg3OZ1b/48whXYRSNTvJ4BtbyUA3w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0517 Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 01 Feb 2020 08:09:25 -0000 QSBjb21tb24gaW50ZXJwcmV0YXRpb24gaW4gdmFyaW91cyBkYXRhIHN0cnVjdHVyZSBsaWJyYXJp ZXMgaXMgdGhpczoNCg0Kc2V0OiB1bm9yZGVyZWQgY29sbGVjdGlvbiBvZiBzb21ldGhpbmcsIGR1 cGxpY2F0ZXMgbm90IGFsbG93ZWQNCmJhZzogdW5vcmRlcmVkIGNvbGxlY3Rpb24gb2Ygc29tZXRo aW5nLCBkdXBsaWNhdGVzIGFsbG93ZWQNCg0KL2pzDQoNCk9uIEZyaSwgSmFuIDMxLCAyMDIwIGF0 IDEwOjA2OjEwUE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+IA0K PiA+PiBORVc6DQo+ID4+ICAgICAgICAgICAgKy0tcncgPHRoaW5nPi1iYWdzIHs8dGhpbmctZmVh dHVyZT59Pw0KPiA+PiAgICAgICAgICAgICAgICstLXJ3IDx0aGluZz4tYmFnKiBbbmFtZV0NCj4g Pj4gICAgICAgICAgICAgICAgICArLS1ydyBuYW1lIHN0cmluZw0KPiA+PiAgICAgICAgICAgICAg ICAgICAgICstLXJ3IDx0aGluZz4qIFtuYW1lXQ0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAg ICstLXJ3IG5hbWUgc3RyaW5nDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgIOKApg0KPiA+ PiANCj4gPj4gQmV0dGVyLCByaWdodD8gICBBbnkgb3RoZXIgaWRlYXM/DQo+ID4gDQo+ID4gV2Ug aGF2ZSBjdXJyZW50IHB1Ymxpc2hlZCBtb2R1bGVzIHdpdGggYm90aCAiLWxpc3QiIGFuZCAiLXNl dCIuICBObw0KPiA+ICItYmFnIiBzbyBmYXIuDQo+ID4gDQo+ID4gRm9yIGV4YW1wbGU6DQo+ID4g DQo+ID4gICJsaXN0IHJ1bGUtbGlzdCIgaW4gaWV0Zi1uZXRjb25mLWFjbQ0KPiA+IA0KPiA+ICAi bGlzdCBtb2R1bGUtc2V0IiBpbiBpZXRmLXlhbmctbGlicmFyeQ0KPiANCj4gVHJ1ZS4NCj4gDQo+ IA0KPiA+IFRoZXJlIGFyZSBzb21lIGV4YW1wbGVzIG9mICJzIiBhcyB3ZWxsLCBidXQgdGhlc2Ug YXJlIHBsdXJhbCAicyIgZm9yIGENCj4gPiBub3JtYWwgbGlzdCBvZiBzaW5nbGV0b25zLCBhbmQg c2hvdWxkIGhhdmUgYmVlbiBuYW1lZCB3L28gdGhlIHBsdXJhbA0KPiA+ICJzIiAoaWYgd2Ugd2Vy ZSB0byBiZSBjb25zaXN0ZW50KS4NCj4gPiANCj4gPiBJIHdvdWxkIHRyeSB0byBhdm9pZCAicyIg Zm9yIGEgImxpc3Qtb2YtbGlzdHMiLCBidXQgdGhlbiBwaWNrIHRoZQ0KPiA+IHN1ZmZpeCB0aGF0 IGZlZWxzIG1vc3QgbmF0dXJhbCBpbiB0aGUgZG9tYWluLiAgKEZvciBleGFtcGxlLCByYXRoZXIN Cj4gPiAibGlzdCBhY2Nlc3MtY29udHJvbC1saXN0IiB0aGFuICJsaXN0IGFjY2Vzcy1jb250cm9s LXNldOKAnSkuDQo+IA0KPiBBZ3JlZWQuDQo+IA0KPiA+IFBlcmhhcHMgeW91IGNhbiBhcmd1ZSB0 aGF0ICItbGlzdCIgd29ya3MgYmV0dGVyIGZvciBvcmRlcmVkIHNlcXVlbmNlcywNCj4gPiBhbmQg Ii1zZXQiIGFuZCAiLWJhZyIgZm9yIHVub3JkZXJlZC4gIEJ1dCB0aGVuIHRoZXJlIGFyZSAib3Jk ZWRlZA0KPiA+IHNldHMiIGFuZCAidW5vcmRlcmVkIGxpc3RzIiAoYW5kIGV2ZW4gYXBwYXJlbnRs eSAib3JkZXJlZCBiYWciLCBpbg0KPiA+IFVNTCkuDQo+IA0KPiBQZXJoYXBzLg0KPiANCj4gPiBU aGUgcGx1cmFsICJzIiBpcyBiZXR0ZXIgZm9yIGEgc3Vycm91bmRpbmcgY29udGFpbmVyIChpZiBv bmUgZXhpc3RzKS4NCj4gDQo+IEFncmVlZC4NCj4gDQo+IA0KPiBJIGFsc28gcmVjZWl2ZWQgYSBw cml2YXRlIHJlc3BvbnNlIGZyb20gUnVzcywgd2hvIHJhdGhlciBub3Qgam9pbiB0aGUgbmV0Y29u ZiBsaXN0LCBidXQgc2FpZDoNCj4gDQo+IDEpIOKAnGJhZ+KAnSB3YXMgb3JpZ2luYWxseSBjcmVh dGVkIHRvIGRlYWwgd2l0aCBpc3N1ZXMgd2l0aCBBU04uMSB0aGUgU0VUIGFuZCBTRVFVRU5DRSB0 eXBlcywgYW5kIHNpbmNlIGhhdmUgZW50ZXJlZCBnZW5lcmFsIGNyeXB0byBwYXJsYW5jZSBvdXRz aWRlIHRoZSBQS0NTIzEyIGNvbnRleHQuDQo+IA0KPiAyKSDigJxiYWfigJ0gaXMgdGhlIGlkZWFs IHRlcm0gZm9yIHdoZW4gY29udmV5aW5nIGEgdW5vcmRlcmVkIGNvbGxlY3Rpb24gb2YgWC41MDkg Y2VydGlmaWNhdGVzLg0KPiANCj4gMykg4oCcYmFn4oCdIGlzIG5vdCBrbm93biB0byBiZSB1c2Vk IGluIHRoZSBjb250ZXh0IG9mIFNTSCBob3N0IGtleXMgb3IgUlBLcywgYnV0IHRoZXJlIGlzbuKA mXQgYW55dGhpbmcgd3Jvbmcgb3IgYmFkIHdpdGggZG9pbmcgc28gZWl0aGVyLg0KPiANCj4gQWxs IHNhaWQsIEkgYmVsaWV2ZSB0aGUgYmVzdCBjb3Vyc2UgaXMgdG8gdXNlIOKAnGJhZ+KAnSBhbmQs IG1vcmUgc3BlY2lmaWNhbGx5LCB0byB1c2UgdGhlICIveC1iYWdzL3gtYmFnL+KApuKAnSBzdHJ1 Y3R1cmUgdGhhdCBpcyBwcmVzZW50IGF0IHRoZSB0b3Agb2YgdGhpcyBtZXNzYWdlLiAgIEFzc3Vt aW5nIHRoZXJlIGFyZSBubyBvYmplY3Rpb25zLCB0aGlzIGNoYW5nZSB3aWxsIGJlIGluIHRoZSBu ZXh0IHVwZGF0ZS4NCj4gDQo+IA0KPiBLZW50DQo+IA0KDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IG5l dGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mDQoNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBD YW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAw IDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Mon Feb 3 06:51:38 2020 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 BAA22120044 for ; Mon, 3 Feb 2020 06:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=Klwl/xKp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0TjLOW+W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzNDLmhhRnCP for ; Mon, 3 Feb 2020 06:51:32 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E481200B9 for ; Mon, 3 Feb 2020 06:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4636; q=dns/txt; s=iport; t=1580741492; x=1581951092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HaOcZc/hMokJtoDqCk2d9MdWVe0r0S6FBBvmXyvv3Hg=; b=Klwl/xKpw8RaE+En2YNIUsnUlZnrV5psyqIJbJLgxCPBdKwzJW+jV+yI uswMAvbBVV7RqbiSzTJUEM3rVdhMyF9XfkdCH+iYkLYb2DNludoWBZ4nq BbEg8ekgBh+iVK8n7lw6raDAnvchqNV/WfedIPq7Adhny7AuAWU727eK6 A=; IronPort-PHdr: =?us-ascii?q?9a23=3AOiUf5xOp/FS2du1OQ5Ml6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAArMjhe/51dJa1iAxoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBagIBAQEBCwGBU1AFbFggBAsqCoQKg0YDina?= =?us-ascii?q?CX5gPglIDVAkBAQEMAQEYCwoCAQGDe0UCF4IdJDcGDgIDDQEBBAEBAQIBBQR?= =?us-ascii?q?thTcMhWYBAQEBAwEBEBERDAEBLAsBBAcCAgIBBgIQAQQBAQECAiYCAgIZDAs?= =?us-ascii?q?VCAgCBAENBQgagwWCSgMuAQIMj3aQZgKBOYhidYEygn8BAQWFCBiCDAMGBYE?= =?us-ascii?q?JKgGKXIFDGoFBP4ERR4FOfj6CZAEBgWcVCiaCSTKCLI0+gxmGBJgVdgqCO5Z?= =?us-ascii?q?bgkiYQI5hgUuZTwIEAgQFAg4BAQWBaCOBWHAVO4JsUBgNgRqNAwwXg1AzhGG?= =?us-ascii?q?FP3SBKYxQAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,398,1574121600"; d="scan'208";a="420909173" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Feb 2020 14:51:31 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 013EpVtB018158 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2020 14:51:31 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Feb 2020 08:51:31 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Feb 2020 09:51:30 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 3 Feb 2020 08:51:30 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+4kOcyfXmWRD4YiSgCYixx0WnVqBVNnar/syM4LcJSoU4HYBvWEsGU0z0ZZzhep9MeWmvyx4eAqPuyf4tEzwSs5gqRwDwHPKtDtvkREwoSStrNYTnxsRKkzBJ6OlJlE3/SwtiOvEzm9ocKpWkCO41uTCTnQXW+bwKeX50AGxWC4UzBLqHiNTuU1EyMk2Nnjgw30iET5Gbp1Qfu5MkZ4UJV5/cQ4K0X7MSF8pNZbFzVd4KCDX+XeXrD2sVseOQ0pwdc/Z7nlM4ljHpK9AMJuw9shFJh1urrzpti5PeHP7sKgCeDondtnMOQ/Dx0CupAOD4bWRQMhD5R8evEJf6EiyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HaOcZc/hMokJtoDqCk2d9MdWVe0r0S6FBBvmXyvv3Hg=; b=EFkk7gvh+Tfv/T9/7EFddPT78W8toPck/auF9pCMH+oaCxgPsn0vly9WXhf/FkbFLQ3aY0lRHQIwhQ5SrcBXJ5qDoPZJ5zXPhGp6N+3ccAQGOFotHFx+pN+0S2XSlK6uWrUd3blwRDjkiS1r6mE7wtuwhDijjUtTLBthXUOK722PTH5bTGtUpsyhjFw0LR2aV9u4DPFuEK8lOlClLeeLIjYTKoSvxXMFx7KjOu5nEY7Wr846Ly+TP11S72yLKYo4hE9xdR6zwe0M/jTvB5GQs9825NaorUnZevFrMO4zzvR89dwUpdTlWj1bTG8cex10X84ez6PRi7Tqpn6RujcSRg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none 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=HaOcZc/hMokJtoDqCk2d9MdWVe0r0S6FBBvmXyvv3Hg=; b=0TjLOW+WnekD/cAylCZPQJTzpm9tPb1gZmhFoA3yCNnKO/3LtZqGFyn7IYwlFAP4CEreFLFCZfGgrnSfb0plEP/ahJK/KXATlT3OzQlL+hcqfNyjq0qF34ZfBjk4kVnU3WLDKKOqp1R8eYiBhBWq+OKfyI2nhe7A81ispZoHWJE= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4448.namprd11.prod.outlook.com (52.135.39.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Mon, 3 Feb 2020 14:51:29 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 14:51:29 +0000 From: "Rob Wilton (rwilton)" To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= , Kent Watsen CC: Russ Housley , "netconf@ietf.org" Thread-Topic: [netconf] Truststore: bags, sets, or other? Thread-Index: AQHV19IVu2XZbPG0hUqJ53Cuw+3kZagEja2AgADH+ACAAKiCgIADkbFg Date: Mon, 3 Feb 2020 14:51:29 +0000 Message-ID: References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> In-Reply-To: <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> 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=rwilton@cisco.com; x-originating-ip: [173.38.220.53] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fd0c225c-fb47-4164-1797-08d7a8b88d6e x-ms-traffictypediagnostic: MN2PR11MB4448: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(39860400002)(366004)(346002)(199004)(189003)(966005)(478600001)(71200400001)(26005)(186003)(5660300002)(8936002)(81166006)(81156014)(54906003)(110136005)(33656002)(7696005)(52536014)(76116006)(2906002)(66446008)(316002)(64756008)(66556008)(66476007)(66946007)(8676002)(53546011)(4326008)(6506007)(66574012)(55016002)(9686003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4448; H:MN2PR11MB4366.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: BCL:0; x-microsoft-antispam-message-info: A/AbYdxEletb5OW3y8yb3mB20HB7PKha7WQDxQj+elLEG5orAt2wseqfNQsMpawNEqf5N3ThSKnk7z5VzTfX/wfP+vrXIaE8ZiLsW+eIVG6lkRqiymDgQy3h0IWNaPMt/ihuvE3DDVlrVxofNPXEZnaaLfYfkXOzzrcV9XQcbVnUTFfz3APBJ97K8JoAcr6tgeGLSmPEN6jfQgZxwqRnO4m2p8hDUvQnUnNMvdOVoHcQCoZtNHYiM6enUXsuS8YlxwqDiuOfSC3oHNvtOSQjOXgRkx0HbcSbHxApGx24e5TzetaUIldSYF12aWZ4UOynvpUf5RatF8Nub4T+Uqg50fcVs2TC3P+bZvSHAqN6jeqMLQUihoRkvIthhVYI95QqaUvzcfwdm+5tS7SD0XaoWh2ZfSw8dILaeV1oCUDhXgk78Oj4dvI9aro/rVrmpPlTem7eCo7C27YQQhjykuXJPDEX1E2buToZiKkOHNpaS9FSycM4SDemZ5APqaMZKstB+9YMfu1MRuqdTMEsgeTefQ== x-ms-exchange-antispam-messagedata: vS6BLbfka9LVL0dQnPr0ADC1tWXz2hWpdlr4lP+MO7mXiNPtJ0+EjoPHFnA4rUiS46dgaQh6chiqM772vLUMqfKlFgGSxefLZt2wn42CSCEL9BwFm6YssLmfQDiTlEtU5tx+zLmW5upwT0I4w2s7dg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd0c225c-fb47-4164-1797-08d7a8b88d6e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 14:51:29.4626 (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-CrossTenant-userprincipalname: 29J2IQqgAB8IdDy0aZvmVCUeREfyiMVHLms4MYLLACa2nJqFxnURUmfdgmjFzXrXXjx5RhWImvUO75oGiVr3kw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4448 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 03 Feb 2020 14:51:36 -0000 KzENCg0KVGhpcyB3b3VsZCBhbHNvIGJlIG15IG5vcm1hbCBpbnRlcnByZXRhdGlvbiBvZiBhIHN0 cnVjdHVyZSBkZXNjcmliZWQgYXMgYSAiYmFnIiwgYWx0aG91Z2ggdGhleSBkb24ndCBzZWVtIHRv IGJlIHRoYXQgY29tbW9ubHkgdXNlZC4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIFNjaMO2bnfDpGxkZXIsIErDvHJnZW4NClNlbnQ6IDAxIEZlYnJ1YXJ5IDIw MjAgMDg6MDkNClRvOiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQpDYzogUnVz cyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbmV0Y29uZl0gVHJ1c3RzdG9yZTogYmFncywgc2V0cywgb3Igb3RoZXI/DQoNCkEg Y29tbW9uIGludGVycHJldGF0aW9uIGluIHZhcmlvdXMgZGF0YSBzdHJ1Y3R1cmUgbGlicmFyaWVz IGlzIHRoaXM6DQoNCnNldDogdW5vcmRlcmVkIGNvbGxlY3Rpb24gb2Ygc29tZXRoaW5nLCBkdXBs aWNhdGVzIG5vdCBhbGxvd2VkDQpiYWc6IHVub3JkZXJlZCBjb2xsZWN0aW9uIG9mIHNvbWV0aGlu ZywgZHVwbGljYXRlcyBhbGxvd2VkDQoNCi9qcw0KDQpPbiBGcmksIEphbiAzMSwgMjAyMCBhdCAx MDowNjoxMFBNICswMDAwLCBLZW50IFdhdHNlbiB3cm90ZToNCj4gSGkgTWFydGluLA0KPiANCj4g Pj4gTkVXOg0KPiA+PiAgICAgICAgICAgICstLXJ3IDx0aGluZz4tYmFncyB7PHRoaW5nLWZlYXR1 cmU+fT8NCj4gPj4gICAgICAgICAgICAgICArLS1ydyA8dGhpbmc+LWJhZyogW25hbWVdDQo+ID4+ ICAgICAgICAgICAgICAgICAgKy0tcncgbmFtZSBzdHJpbmcNCj4gPj4gICAgICAgICAgICAgICAg ICAgICArLS1ydyA8dGhpbmc+KiBbbmFtZV0NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAr LS1ydyBuYW1lIHN0cmluZw0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICDigKYNCj4gPj4g DQo+ID4+IEJldHRlciwgcmlnaHQ/ICAgQW55IG90aGVyIGlkZWFzPw0KPiA+IA0KPiA+IFdlIGhh dmUgY3VycmVudCBwdWJsaXNoZWQgbW9kdWxlcyB3aXRoIGJvdGggIi1saXN0IiBhbmQgIi1zZXQi LiAgTm8gDQo+ID4gIi1iYWciIHNvIGZhci4NCj4gPiANCj4gPiBGb3IgZXhhbXBsZToNCj4gPiAN Cj4gPiAgImxpc3QgcnVsZS1saXN0IiBpbiBpZXRmLW5ldGNvbmYtYWNtDQo+ID4gDQo+ID4gICJs aXN0IG1vZHVsZS1zZXQiIGluIGlldGYteWFuZy1saWJyYXJ5DQo+IA0KPiBUcnVlLg0KPiANCj4g DQo+ID4gVGhlcmUgYXJlIHNvbWUgZXhhbXBsZXMgb2YgInMiIGFzIHdlbGwsIGJ1dCB0aGVzZSBh cmUgcGx1cmFsICJzIiBmb3IgDQo+ID4gYSBub3JtYWwgbGlzdCBvZiBzaW5nbGV0b25zLCBhbmQg c2hvdWxkIGhhdmUgYmVlbiBuYW1lZCB3L28gdGhlIA0KPiA+IHBsdXJhbCAicyIgKGlmIHdlIHdl cmUgdG8gYmUgY29uc2lzdGVudCkuDQo+ID4gDQo+ID4gSSB3b3VsZCB0cnkgdG8gYXZvaWQgInMi IGZvciBhICJsaXN0LW9mLWxpc3RzIiwgYnV0IHRoZW4gcGljayB0aGUgDQo+ID4gc3VmZml4IHRo YXQgZmVlbHMgbW9zdCBuYXR1cmFsIGluIHRoZSBkb21haW4uICAoRm9yIGV4YW1wbGUsIHJhdGhl ciANCj4gPiAibGlzdCBhY2Nlc3MtY29udHJvbC1saXN0IiB0aGFuICJsaXN0IGFjY2Vzcy1jb250 cm9sLXNldOKAnSkuDQo+IA0KPiBBZ3JlZWQuDQo+IA0KPiA+IFBlcmhhcHMgeW91IGNhbiBhcmd1 ZSB0aGF0ICItbGlzdCIgd29ya3MgYmV0dGVyIGZvciBvcmRlcmVkIA0KPiA+IHNlcXVlbmNlcywg YW5kICItc2V0IiBhbmQgIi1iYWciIGZvciB1bm9yZGVyZWQuICBCdXQgdGhlbiB0aGVyZSBhcmUg DQo+ID4gIm9yZGVkZWQgc2V0cyIgYW5kICJ1bm9yZGVyZWQgbGlzdHMiIChhbmQgZXZlbiBhcHBh cmVudGx5ICJvcmRlcmVkIA0KPiA+IGJhZyIsIGluIFVNTCkuDQo+IA0KPiBQZXJoYXBzLg0KPiAN Cj4gPiBUaGUgcGx1cmFsICJzIiBpcyBiZXR0ZXIgZm9yIGEgc3Vycm91bmRpbmcgY29udGFpbmVy IChpZiBvbmUgZXhpc3RzKS4NCj4gDQo+IEFncmVlZC4NCj4gDQo+IA0KPiBJIGFsc28gcmVjZWl2 ZWQgYSBwcml2YXRlIHJlc3BvbnNlIGZyb20gUnVzcywgd2hvIHJhdGhlciBub3Qgam9pbiB0aGUg bmV0Y29uZiBsaXN0LCBidXQgc2FpZDoNCj4gDQo+IDEpIOKAnGJhZ+KAnSB3YXMgb3JpZ2luYWxs eSBjcmVhdGVkIHRvIGRlYWwgd2l0aCBpc3N1ZXMgd2l0aCBBU04uMSB0aGUgU0VUIGFuZCBTRVFV RU5DRSB0eXBlcywgYW5kIHNpbmNlIGhhdmUgZW50ZXJlZCBnZW5lcmFsIGNyeXB0byBwYXJsYW5j ZSBvdXRzaWRlIHRoZSBQS0NTIzEyIGNvbnRleHQuDQo+IA0KPiAyKSDigJxiYWfigJ0gaXMgdGhl IGlkZWFsIHRlcm0gZm9yIHdoZW4gY29udmV5aW5nIGEgdW5vcmRlcmVkIGNvbGxlY3Rpb24gb2Yg WC41MDkgY2VydGlmaWNhdGVzLg0KPiANCj4gMykg4oCcYmFn4oCdIGlzIG5vdCBrbm93biB0byBi ZSB1c2VkIGluIHRoZSBjb250ZXh0IG9mIFNTSCBob3N0IGtleXMgb3IgUlBLcywgYnV0IHRoZXJl IGlzbuKAmXQgYW55dGhpbmcgd3Jvbmcgb3IgYmFkIHdpdGggZG9pbmcgc28gZWl0aGVyLg0KPiAN Cj4gQWxsIHNhaWQsIEkgYmVsaWV2ZSB0aGUgYmVzdCBjb3Vyc2UgaXMgdG8gdXNlIOKAnGJhZ+KA nSBhbmQsIG1vcmUgc3BlY2lmaWNhbGx5LCB0byB1c2UgdGhlICIveC1iYWdzL3gtYmFnL+KApuKA nSBzdHJ1Y3R1cmUgdGhhdCBpcyBwcmVzZW50IGF0IHRoZSB0b3Agb2YgdGhpcyBtZXNzYWdlLiAg IEFzc3VtaW5nIHRoZXJlIGFyZSBubyBvYmplY3Rpb25zLCB0aGlzIGNoYW5nZSB3aWxsIGJlIGlu IHRoZSBuZXh0IHVwZGF0ZS4NCj4gDQo+IA0KPiBLZW50DQo+IA0KDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGNvbmYgbWFpbGluZyBsaXN0 DQo+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mDQoNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0 MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNvbmYg bWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Mon Feb 3 12:21:39 2020 Return-Path: <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-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 A09FF120C9B for ; Mon, 3 Feb 2020 12:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 2etbiA18eDPt for ; Mon, 3 Feb 2020 12:21:35 -0800 (PST) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22BA120C9A for ; Mon, 3 Feb 2020 12:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1580761294; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=yrqZNtAvtncHBXqyfsin9OFT10P3huEJszlEASuh3aQ=; b=EPgDcNW3cOtBJjTvdc1r2Bd3dIK/7dQPZphJjfFLJ7t98abZyORS3nZzcuPrgfgA OHs6vtR3vNiDjB25gq9GfDjTorRT7FFvKoBBiEnWXgZ2zKtrIcMu36lpWuxxAeTGj88 TSZybZc2y6rMVBGU1j+ZUi5kU5ymtqps6dgWVM4k= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: Date: Mon, 3 Feb 2020 20:21:34 +0000 Cc: Juergen Schoenwaelder , Russ Housley , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-000000@email.amazonses.com> References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.03-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 03 Feb 2020 20:21:38 -0000 Searching online for =E2=80=9Cbag=E2=80=9D, I found definitions vary = (even amongst university CS sites) regarding if duplicates are allowed. = FWIW, this variation also exists in IETF RFCs, as CMS uses the ASN.1=E2=80= =99s "SET OF=E2=80=9D syntax (duplicates not allowed) whereas PKCS#12 = uses ASN.1=E2=80=99s =E2=80=9CSEQUENCE=E2=80=9D syntax (duplicates = allowed). In any case, if duplicates are present, they have no impact = on processing behavior (e.g., a certificate isn=E2=80=99t somehow more = trusted if it appears more than once). Of course, YANG only has =E2=80=98list=E2=80=99 and =E2=80=98leaf-list=E2=80= =99 statements for collections. So perfect mappings aren=E2=80=99t = always possible. As Martin noted in his message, the substring "set=E2=80= =9D is used in published modules (e.g., module-set). Interestingly, = lists generally allow for duplicates, but YANG lists don=E2=80=99t, due = to being keyed, unless the scope is reduce to the non-key fields, e.g., = assuming certificate =E2=80=98C=E2=80=99, both {key1, C} and {key2, C} = could be in the Truststore at the same time. I still feel that =E2=80=9Cbag=E2=80=9D is the best term to use here due = to it being a distinctive crypto-domain term used for set-like = collections. I=E2=80=99m assuming that this (using =E2=80=9Cbag=E2=80=9D)= is okay since no real objection has been voiced yet, but please let me = know if that is a misunderstanding on my part. Kent // contributor > On Feb 3, 2020, at 9:51 AM, Rob Wilton (rwilton) = wrote: >=20 > +1 >=20 > This would also be my normal interpretation of a structure described = as a "bag", although they don't seem to be that commonly used. >=20 > Thanks, > Rob >=20 >=20 > -----Original Message----- > From: netconf On Behalf Of Sch=C3=B6nw=C3=A4l= der, J=C3=BCrgen > Sent: 01 February 2020 08:09 > To: Kent Watsen > Cc: Russ Housley ; netconf@ietf.org > Subject: Re: [netconf] Truststore: bags, sets, or other? >=20 > A common interpretation in various data structure libraries is this: >=20 > set: unordered collection of something, duplicates not allowed > bag: unordered collection of something, duplicates allowed >=20 > /js >=20 > On Fri, Jan 31, 2020 at 10:06:10PM +0000, Kent Watsen wrote: >> Hi Martin, >>=20 >>>> NEW: >>>> +--rw -bags {}? >>>> +--rw -bag* [name] >>>> +--rw name string >>>> +--rw * [name] >>>> +--rw name string >>>> =E2=80=A6 >>>>=20 >>>> Better, right? Any other ideas? >>>=20 >>> We have current published modules with both "-list" and "-set". No=20= >>> "-bag" so far. >>>=20 >>> For example: >>>=20 >>> "list rule-list" in ietf-netconf-acm >>>=20 >>> "list module-set" in ietf-yang-library >>=20 >> True. >>=20 >>=20 >>> There are some examples of "s" as well, but these are plural "s" for=20= >>> a normal list of singletons, and should have been named w/o the=20 >>> plural "s" (if we were to be consistent). >>>=20 >>> I would try to avoid "s" for a "list-of-lists", but then pick the=20 >>> suffix that feels most natural in the domain. (For example, rather=20= >>> "list access-control-list" than "list access-control-set=E2=80=9D). >>=20 >> Agreed. >>=20 >>> Perhaps you can argue that "-list" works better for ordered=20 >>> sequences, and "-set" and "-bag" for unordered. But then there are=20= >>> "ordeded sets" and "unordered lists" (and even apparently "ordered=20= >>> bag", in UML). >>=20 >> Perhaps. >>=20 >>> The plural "s" is better for a surrounding container (if one = exists). >>=20 >> Agreed. >>=20 >>=20 >> I also received a private response from Russ, who rather not join the = netconf list, but said: >>=20 >> 1) =E2=80=9Cbag=E2=80=9D was originally created to deal with issues = with ASN.1 the SET and SEQUENCE types, and since have entered general = crypto parlance outside the PKCS#12 context. >>=20 >> 2) =E2=80=9Cbag=E2=80=9D is the ideal term for when conveying a = unordered collection of X.509 certificates. >>=20 >> 3) =E2=80=9Cbag=E2=80=9D is not known to be used in the context of = SSH host keys or RPKs, but there isn=E2=80=99t anything wrong or bad = with doing so either. >>=20 >> All said, I believe the best course is to use =E2=80=9Cbag=E2=80=9D = and, more specifically, to use the "/x-bags/x-bag/=E2=80=A6=E2=80=9D = structure that is present at the top of this message. Assuming there = are no objections, this change will be in the next update. >>=20 >>=20 >> Kent >>=20 >=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 3 13:06:58 2020 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 3FF0E120CB3 for ; Mon, 3 Feb 2020 13:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 HdMhlPHBGRgJ for ; Mon, 3 Feb 2020 13:06:55 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEF6120CB1 for ; Mon, 3 Feb 2020 13:06:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6A4FD300B56 for ; Mon, 3 Feb 2020 15:40:13 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r2op5DsVzbcg for ; Mon, 3 Feb 2020 15:40:10 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id A0BD7300A0D; Mon, 3 Feb 2020 15:40:10 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-000000@email.amazonses.com> Date: Mon, 3 Feb 2020 16:06:51 -0500 Cc: "Rob Wilton (rwilton)" , Juergen Schoenwaelder , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 03 Feb 2020 21:06:57 -0000 > On Feb 3, 2020, at 3:21 PM, Kent Watsen wrote: >=20 > Searching online for =E2=80=9Cbag=E2=80=9D, I found definitions vary = (even amongst university CS sites) regarding if duplicates are allowed. = FWIW, this variation also exists in IETF RFCs, as CMS uses the ASN.1=E2=80= =99s "SET OF=E2=80=9D syntax (duplicates not allowed) whereas PKCS#12 = uses ASN.1=E2=80=99s =E2=80=9CSEQUENCE=E2=80=9D syntax (duplicates = allowed). In any case, if duplicates are present, they have no impact = on processing behavior (e.g., a certificate isn=E2=80=99t somehow more = trusted if it appears more than once). >=20 > Of course, YANG only has =E2=80=98list=E2=80=99 and =E2=80=98leaf-list=E2= =80=99 statements for collections. So perfect mappings aren=E2=80=99t = always possible. As Martin noted in his message, the substring "set=E2=80= =9D is used in published modules (e.g., module-set). Interestingly, = lists generally allow for duplicates, but YANG lists don=E2=80=99t, due = to being keyed, unless the scope is reduce to the non-key fields, e.g., = assuming certificate =E2=80=98C=E2=80=99, both {key1, C} and {key2, C} = could be in the Truststore at the same time. >=20 > I still feel that =E2=80=9Cbag=E2=80=9D is the best term to use here = due to it being a distinctive crypto-domain term used for set-like = collections. I=E2=80=99m assuming that this (using =E2=80=9Cbag=E2=80=9D)= is okay since no real objection has been voiced yet, but please let me = know if that is a misunderstanding on my part. >=20 > Kent // contributor >=20 >=20 >> On Feb 3, 2020, at 9:51 AM, Rob Wilton (rwilton) = wrote: >>=20 >> +1 >>=20 >> This would also be my normal interpretation of a structure described = as a "bag", although they don't seem to be that commonly used. >>=20 >> Thanks, >> Rob >>=20 >>=20 >> -----Original Message----- >> From: netconf On Behalf Of Sch=C3=B6nw=C3=A4= lder, J=C3=BCrgen >> Sent: 01 February 2020 08:09 >> To: Kent Watsen >> Cc: Russ Housley ; netconf@ietf.org >> Subject: Re: [netconf] Truststore: bags, sets, or other? >>=20 >> A common interpretation in various data structure libraries is this: >>=20 >> set: unordered collection of something, duplicates not allowed >> bag: unordered collection of something, duplicates allowed >>=20 >> /js >>=20 >> On Fri, Jan 31, 2020 at 10:06:10PM +0000, Kent Watsen wrote: >>> Hi Martin, >>>=20 >>>>> NEW: >>>>> +--rw -bags {}? >>>>> +--rw -bag* [name] >>>>> +--rw name string >>>>> +--rw * [name] >>>>> +--rw name string >>>>> =E2=80=A6 >>>>>=20 >>>>> Better, right? Any other ideas? >>>>=20 >>>> We have current published modules with both "-list" and "-set". No=20= >>>> "-bag" so far. >>>>=20 >>>> For example: >>>>=20 >>>> "list rule-list" in ietf-netconf-acm >>>>=20 >>>> "list module-set" in ietf-yang-library >>>=20 >>> True. >>>=20 >>>=20 >>>> There are some examples of "s" as well, but these are plural "s" = for=20 >>>> a normal list of singletons, and should have been named w/o the=20 >>>> plural "s" (if we were to be consistent). >>>>=20 >>>> I would try to avoid "s" for a "list-of-lists", but then pick the=20= >>>> suffix that feels most natural in the domain. (For example, rather=20= >>>> "list access-control-list" than "list access-control-set=E2=80=9D). >>>=20 >>> Agreed. >>>=20 >>>> Perhaps you can argue that "-list" works better for ordered=20 >>>> sequences, and "-set" and "-bag" for unordered. But then there are=20= >>>> "ordeded sets" and "unordered lists" (and even apparently "ordered=20= >>>> bag", in UML). >>>=20 >>> Perhaps. >>>=20 >>>> The plural "s" is better for a surrounding container (if one = exists). >>>=20 >>> Agreed. >>>=20 >>>=20 >>> I also received a private response from Russ, who rather not join = the netconf list, but said: >>>=20 >>> 1) =E2=80=9Cbag=E2=80=9D was originally created to deal with issues = with ASN.1 the SET and SEQUENCE types, and since have entered general = crypto parlance outside the PKCS#12 context. >>>=20 >>> 2) =E2=80=9Cbag=E2=80=9D is the ideal term for when conveying a = unordered collection of X.509 certificates. >>>=20 >>> 3) =E2=80=9Cbag=E2=80=9D is not known to be used in the context of = SSH host keys or RPKs, but there isn=E2=80=99t anything wrong or bad = with doing so either. >>>=20 >>> All said, I believe the best course is to use =E2=80=9Cbag=E2=80=9D = and, more specifically, to use the "/x-bags/x-bag/=E2=80=A6=E2=80=9D = structure that is present at the top of this message. Assuming there = are no objections, this change will be in the next update. >>>=20 >>>=20 >>> Kent >>>=20 >>=20 >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 From nobody Mon Feb 3 13:38:24 2020 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 3151512001E for ; Mon, 3 Feb 2020 13:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzADd-QGdwdr for ; Mon, 3 Feb 2020 13:38:20 -0800 (PST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DD912013C for ; Mon, 3 Feb 2020 13:38:19 -0800 (PST) Received: by mail-pj1-f54.google.com with SMTP id fa20so347816pjb.1 for ; Mon, 03 Feb 2020 13:38:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XflyXrYvPTfFRWfXUfImPMIu3qujpR+mB/S++69uCFs=; b=eoMz8dptPP97EPxgQxHQRY7ssF5apwOvdtUQKbxRYbWHoYdlqysaE7KqIvpB2CGUFg FzICntMzW4NpkxpdVzLPw88KZBAkN+At10PZh1Tx6hk99VK1ywAL2Pd1PLENffkYy0i7 affcYYO8LisTikjpa39mbH12lJ5We45QBYezcAkFjh9gYeWTczwe+0yoDal9OV7iZzPv H9W9QLvhZ2epxCxpucg4KMMH/QoZruoaIKyyw51wDoUBuo9l80NwcJCKb2jj7lYqkFMa 7StE1atrdZrOeHoD20aFKfL6994A76SUA6tROsWwOx/8SFKfw65VwLlYlRbzx5XoIV6o toxA== X-Gm-Message-State: APjAAAVx1QSzONG54PrtwhC8ayP9rcoVTJjzxKH/bUKVO4hKhiRUANDc okYwAc3fKGYGN+525LtBCVouGHKSnjU= X-Google-Smtp-Source: APXvYqy2ZFsiNJnct4Hrk6iEud4FDqxfb/06Tqt6/z/KotQhUMxS3/Xo76pkqw9d/ZAPyUB25EthtQ== X-Received: by 2002:a17:90a:d804:: with SMTP id a4mr1342089pjv.11.1580765899114; Mon, 03 Feb 2020 13:38:19 -0800 (PST) Received: from [192.168.1.104] (c-73-231-235-186.hsd1.ca.comcast.net. [73.231.235.186]) by smtp.gmail.com with ESMTPSA id j8sm445591pjb.4.2020.02.03.13.38.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Feb 2020 13:38:18 -0800 (PST) To: netconf@ietf.org References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-000000@email.amazonses.com> From: Randy Presuhn Message-ID: <4eac0f7d-cf0a-71d5-d9f6-4e5c1fbd7b07@alumni.stanford.edu> Date: Mon, 3 Feb 2020 13:38:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 03 Feb 2020 21:38:22 -0000 Hi - There is no reason to use two terms for one thing. Use the term "bag" only if what you're describing is indeed not a set, i.e., if it is unordered and allows duplicates. Randy On 2/3/2020 12:21 PM, Kent Watsen wrote: > Searching online for “bag”, I found definitions vary (even amongst university CS sites) regarding if duplicates are allowed. FWIW, this variation also exists in IETF RFCs, as CMS uses the ASN.1’s "SET OF” syntax (duplicates not allowed) whereas PKCS#12 uses ASN.1’s “SEQUENCE” syntax (duplicates allowed). In any case, if duplicates are present, they have no impact on processing behavior (e.g., a certificate isn’t somehow more trusted if it appears more than once). > > Of course, YANG only has ‘list’ and ‘leaf-list’ statements for collections. So perfect mappings aren’t always possible. As Martin noted in his message, the substring "set” is used in published modules (e.g., module-set). Interestingly, lists generally allow for duplicates, but YANG lists don’t, due to being keyed, unless the scope is reduce to the non-key fields, e.g., assuming certificate ‘C’, both {key1, C} and {key2, C} could be in the Truststore at the same time. > > I still feel that “bag” is the best term to use here due to it being a distinctive crypto-domain term used for set-like collections. I’m assuming that this (using “bag”) is okay since no real objection has been voiced yet, but please let me know if that is a misunderstanding on my part. > > Kent // contributor > > >> On Feb 3, 2020, at 9:51 AM, Rob Wilton (rwilton) wrote: >> >> +1 >> >> This would also be my normal interpretation of a structure described as a "bag", although they don't seem to be that commonly used. >> >> Thanks, >> Rob >> >> >> -----Original Message----- >> From: netconf On Behalf Of Schönwälder, Jürgen >> Sent: 01 February 2020 08:09 >> To: Kent Watsen >> Cc: Russ Housley ; netconf@ietf.org >> Subject: Re: [netconf] Truststore: bags, sets, or other? >> >> A common interpretation in various data structure libraries is this: >> >> set: unordered collection of something, duplicates not allowed >> bag: unordered collection of something, duplicates allowed >> >> /js >> >> On Fri, Jan 31, 2020 at 10:06:10PM +0000, Kent Watsen wrote: >>> Hi Martin, >>> >>>>> NEW: >>>>> +--rw -bags {}? >>>>> +--rw -bag* [name] >>>>> +--rw name string >>>>> +--rw * [name] >>>>> +--rw name string >>>>> … >>>>> >>>>> Better, right? Any other ideas? >>>> >>>> We have current published modules with both "-list" and "-set". No >>>> "-bag" so far. >>>> >>>> For example: >>>> >>>> "list rule-list" in ietf-netconf-acm >>>> >>>> "list module-set" in ietf-yang-library >>> >>> True. >>> >>> >>>> There are some examples of "s" as well, but these are plural "s" for >>>> a normal list of singletons, and should have been named w/o the >>>> plural "s" (if we were to be consistent). >>>> >>>> I would try to avoid "s" for a "list-of-lists", but then pick the >>>> suffix that feels most natural in the domain. (For example, rather >>>> "list access-control-list" than "list access-control-set”). >>> >>> Agreed. >>> >>>> Perhaps you can argue that "-list" works better for ordered >>>> sequences, and "-set" and "-bag" for unordered. But then there are >>>> "ordeded sets" and "unordered lists" (and even apparently "ordered >>>> bag", in UML). >>> >>> Perhaps. >>> >>>> The plural "s" is better for a surrounding container (if one exists). >>> >>> Agreed. >>> >>> >>> I also received a private response from Russ, who rather not join the netconf list, but said: >>> >>> 1) “bag” was originally created to deal with issues with ASN.1 the SET and SEQUENCE types, and since have entered general crypto parlance outside the PKCS#12 context. >>> >>> 2) “bag” is the ideal term for when conveying a unordered collection of X.509 certificates. >>> >>> 3) “bag” is not known to be used in the context of SSH host keys or RPKs, but there isn’t anything wrong or bad with doing so either. >>> >>> All said, I believe the best course is to use “bag” and, more specifically, to use the "/x-bags/x-bag/…” structure that is present at the top of this message. Assuming there are no objections, this change will be in the next update. >>> >>> >>> Kent >>> >> >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> -- >> 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 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Feb 3 19:27:08 2020 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 787EA12003E for ; Mon, 3 Feb 2020 19:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVSPclpw_OJH for ; Mon, 3 Feb 2020 19:27:02 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF36912004A for ; Mon, 3 Feb 2020 19:27:01 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1A05259A5F20D9FE58F1; Tue, 4 Feb 2020 03:26:59 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 4 Feb 2020 03:26:58 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Tue, 4 Feb 2020 11:26:55 +0800 From: Tianran Zhou To: Mahesh Jethanandani , "Eric Voit (evoit)" CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AQHV1XCeubZMdY/BlUWFkKvfsxOTcqgKaf+w Date: Tue, 4 Feb 2020 03:26:54 +0000 Message-ID: References: <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> In-Reply-To: <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.232.185] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF1F227ANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] =?gb2312?b?tPC4tDogIFdHTEMgb24gZHJhZnQtaWV0Zi1uZXRj?= =?gb2312?b?b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcz8gKFdhcyBSZTogQ29uZmlndXJl?= =?gb2312?b?ZCByZWNlaXZlciBjYXBhYmlsaXR5IGV4Y2hhbmdlKQ==?= 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, 04 Feb 2020 03:27:04 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BF1F227ANKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KSSBzZWUgobBwcmV2aW91cy1tZXNzYWdlLWlkobEgaXMgbWVudGlvbmVkIGlu IHRoZSBkZXNjcmlwdGlvbiBvZiChsG1lc3NhZ2UtZ2VuZXJhdG9yLWlkobEgaW4gc2VjdGlvbiAz Lg0KQnV0IHRoZXJlIGlzIG5vIGRlZmluaXRpb24gb24gobBwcmV2aW91cy1tZXNzYWdlLWlkobEg aW4gc2VjdGlvbiA0LjINCkRpZCB5b3UgZHJvcCB0aGlzIGZlYXR1cmU/IE1heWJlIHlvdSBuZWVk IHRvIGNsZWFuIHVwIHRoZSB0ZXh0IG9uIHRoaXMuDQoNCkNoZWVycywNClRpYW5yYW4NCg0Kt6K8 /sjLOiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1haGVz aCBKZXRoYW5hbmRhbmkNCreiy83KsbzkOiAyMDIwxOox1MIyOMjVIDg6MTkNCsrVvP7IyzogRXJp YyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT4NCrOty806IG5ldGNvbmZAaWV0Zi5vcmcN Ctb3zOI6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t bWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5n ZSkNCg0KSGkgRXJpYywNCg0KVGhpcyBlLW1haWwgdHJpZ2dlcnMgdHdvIHJlc3BvbnNlcy4gTGV0 IHVzIGRlYWwgd2l0aCBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzIGhl cmUsIGFuZCBJIHdpbGwgYnJpbmcgdXAgY29tbWVudHMvcXVlc3Rpb25zIHJlbGF0ZWQgdG8gZHJh ZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmIGluIHRoZSBvdGhlciB0aHJlYWQuDQoNCllvdSBo YXZlIGluZGljYXRlZCBhIGRlc2lyZSB0aGF0IHJlY2VpdmVyIGNhcGFiaWxpdGllcyBzaG91bGQg YmUgZG9jdW1lbnRlZCBieSB0aGUgdHJhbnNwb3J0IHNwZWNpZmljIGRyYWZ0LCBlLmcuIGRyYWZ0 LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiwgYW5kIG5vdCB0aGlzIGRyYWZ0LiBBcyBzdWNoIHlv dSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5Lg0KDQpUbyB0aGUgV0csIHRoZSBhdXRo b3JzIGhhdmUgaW5kaWNhdGVkIGEgZGVzaXJlIHRvIHdyYXAgdXAgdGhpcyBkcmFmdCwgYW5kIHdv dWxkIGxpa2UgdXMsIHRoZSBjaGFpcnMsIHRvIGlzc3VlIGEgV0dMQyBvbiBpdC4gQmVmb3JlIHdl IGRvIHRoYXQsIHdlIHdhbnRlZCB0byBhc2sgaWYgdGhlIFdHIGJlbGlldmVzIHRoYXQgdGhlIGRv Y3VtZW50IGlzIHJlYWR5LCBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gbW9yZSBpc3N1ZXMgdGhhdCBu ZWVkIHRvIGRpc2N1c3NlZC9hZGRyZXNzZWQgYnkgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNh dGlvbi1tZXNzYWdlcyBkb2N1bWVudCBhdCB0aGlzIHRpbWUuDQoNCkNoZWVycy4NCg0KTWFoZXNo IGFuZCBLZW50IChhcyBjby1jaGFpcnMpLg0KDQoNCk9uIEphbiAxNSwgMjAyMCwgYXQgMTI6MjMg UE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2Nv LmNvbT4+IHdyb3RlOg0KDQpIaSBNYWhlc2gsDQoNCkR1cmluZyB0aGUgSUVURiAxMDYgc2Vzc2lv biwgdGhlcmUgd2FzIGRpc2N1c3Npb24gb24gaG93IGJvdGggYSBwdWJsaXNoZXIgbWlnaHQga25v dyBpZiB0aGVyZSBpcyByZWNlaXZlciBzdXBwb3J0IGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtbm90 aWZpY2F0aW9uLW1lc3NhZ2VzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2luY2x1ZGVfdGV4dD0xPi4gIFNl Y3Rpb24gNiBoaWdobGlnaHRzIHNldmVyYWwgb2YgdGhlIGNvbnNpZGVyYXRpb25zLiAgIFJlbGV2 YW50IGFyZSB0aGUgZm9sbG93aW5nOg0KDQooYSkgUmVtb3RlIGRldmljZSBjYXBhYmlsaXR5IGRp c2NvdmVyeSBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBQdWJsaXNoZXIgbmVlZHMgdG8g YmUgZW5oYW5jZWQgdG8ga25vdyBpZiB0aGUgZmFyIGVuZCBjYW4gaW50ZXJwcmV0IG5vdGlmaWNh dGlvbiBtZXNzYWdlcyB0eXBlIGJleW9uZCBSRkMtNTI3NywgU2VjdGlvbiA0Lg0KDQooYikgVGhp cyBjYXBhYmlsaXR5IGRpc2NvdmVyeSBxdWVzdGlvbiBpcyByZWxldmFudCBmb3IgYm90aCBjb25m aWd1cmVkIHN1YnNjcmlwdGlvbiByZWNlaXZlcnMgYW5kIGR5bmFtaWMgc3Vic2NyaWJlcnMuDQoN CihjKSBUaGUgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgcXVlc3Rpb24gY2FuIGJlIGdlbmVyYWxpemVk IGJleW9uZCBzdWJzY3JpcHRpb25zLCBhcyB0aGVyZSBhcmUgbWFueSByZWFzb25zIHRvIGtub3cg dGhlIGF2YWlsYWJsZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGZhciBlbmQuDQoNCihkKSBDYXBhYmls aXR5IGRpc2NvdmVyeSBhZHZlcnRpc2VtZW50IGhhcyB0cmFkaXRpb25hbGx5IGJlZW4gZGlzY3Vz c2VkIHdpdGhpbiB0cmFuc3BvcnQgZG9jdW1lbnRzIChlLmcuIFJGQy02MjQxIFNlY3Rpb24gOC4x KS4NCg0KDQpCYXNlZCBvbiAoYSktKGQpLCBjb21pbmcgdXAgd2l0aCBhIHRyYW5zcG9ydCBpbmRl cGVuZGVudCBwb2ludC1zb2x1dGlvbiB3aXRoaW4gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNh dGlvbi1tZXNzYWdlczxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLz9pbmNsdWRlX3RleHQ9MT4gKmp1c3QqIHRv IGRpc2NvdmVyIHRoaXMgc2luZ2xlIGVsZW1lbnQgb2YgY2xpZW50IGZ1bmN0aW9uYWxpdHkgc2Vl bXMgb3ZlcmtpbGwvaGVhdnl3ZWlnaHQuDQoNCkkgd2FzIGZpbmUgd2l0aCBsZXR0aW5nIHRoaXMg cmVtb3RlIGNhcGFiaWxpdGllcyBkaXNjb3ZlcnkgcXVlc3Rpb24gc2l0IGZvciBhIHdoaWxlLiAg IEhvd2V2ZXIgZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmPGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDE+IHNob3dzIHRoYXQg d2Ugbm93IG11c3QgYWRkcmVzcyB0aGlzIHF1ZXN0aW9uLiAgU3BlY2lmaWNhbGx5IHNob3VsZCB0 aGUgZGlhZ3JhbSBzZWN0aW9uIDEuNC4xIHNob3cgdGhpcyBjYXBhYmlsaXR5IGV4Y2hhbmdlPw0K DQpJdCB0dXJucyBvdXQgdGhhdCBpbmRlcGVuZGVudCBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90 aWZpY2F0aW9uLW1lc3NhZ2VzLCB0aGVyZSBzZXZlcmFsIHF1ZXN0aW9ucyBpbiBkcmFmdC1pZXRm LW5ldGNvbmYtaHR0cHMtbm90aWYgd2hpY2ggbmVlZCB0byBiZSBhbnN3ZXJlZCBwcmlvciB0byB0 aGUgc2VjdGlvbiAxLjQuMSBhcnJvdzogIlNlbmQgSFRUUFMgUE9TVCBtZXNzYWdlIHdpdGggWUFO RyBkZWZpbmVkIG5vdGlmaWNhdGlvbiAjMSIgYW55d2F5LiAgVGhlc2UgcXVlc3Rpb25zIGFyZToN CiAgKDEpIERvZXMgdGhlIHRhcmdldGVkIEhUVFBTIHJlY2VpdmVyIHN1cHBvcnQgY29uZmlndXJl ZCBzdWJzY3JpcHRpb25zPw0KICAoMikgQ2FuIHRoZSB0YXJnZXRlZCBIVFRQQCByZWNlaXZlciBh Y2NlcHQgYSBuZXcgc3Vic2NyaXB0aW9uIGFzIGRlc2NyaWJlZCBpbiBhIDxzdWJzY3JpcHRpb24t c3RhcnRlZD4/DQpPbmx5IGlmIHRoZXNlIHF1ZXN0aW9ucyBhcmUgInllcyIsIHNob3VsZCB0aGUg PHN1YnNjcmlwdGlvbi1zdGFydGVkPiBiZSByZXNwb25kZWQgdG8gd2l0aCBhbiAiT0siLg0KDQpB ZGQgdG8gdGhpcyBhIHRoaXJkIHF1ZXN0aW9uIGRyaXZlbiBmcm9tIChhKS0oZCk6DQogICgzKSBE b2VzIHRoZSByZWNlaXZlciBzdXBwb3J0IHRoZSBtZXNzYWdlIHR5cGUgd2l0aGluICJkcmFmdC1p ZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzIj8NCg0KQSBzdHJhd21hbiB3YXkgdG8g aGFuZGxlIHRoZSBhbGwgdGhyZWUgcXVlc3Rpb25zIHdpdGhpbiBkcmFmdC1pZXRmLW5ldGNvbmYt aHR0cHMtbm90aWYgd291bGQgYmUgdG8gcmVzcG9uZCB0byBhIDxzdWJzY3JpcHRpb24tc3RhcnRl ZD4gbm90aWZpY2F0aW9uIHdpdGggYW4gSFRUUCBTdGF0dXMgMjAyIChBY2NlcHRlZCkiIGFja25v d2xlZGdlbWVudC4gIFRoaXMgMjAyIHdvdWxkIGluY2x1ZGUgYm9keSBlbGVtZW50cyBsaXN0aW5n IHN1cHBvcnRlZCByZWNlaXZlciByZXNvdXJjZXMuICBNYXliZSBzb21ldGhpbmcgWUFORyBlbmNv ZGVkIHZpYSBpZXRmLXlhbmctc3RydWN0dXJlLWV4dCBjb250YWluaW5nOg0KDQogICAgICA8Zm9v IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KICAgICAg ICA8Y2FwYWJpbGl0aWVzPg0KICAgICAgICAgIDxjYXBhYmlsaXR5Pg0KICAgICAgICAgICAgdXJu OmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzOjEuMA0K ICAgICAgICAgIDwvY2FwYWJpbGl0eT4NCiAgICAgICAgPC9jYXBhYmlsaXRpZXM+DQogICAgICA8 L2Zvbz4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhpcyBhcHByb2FjaD8NCg0KRXJpYw0KDQpN YWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhh bmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQo= --_000_BBA82579FD347748BEADC4C445EA0F21BF1F227ANKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

I see =A1=B0previous-m= essage-id=A1=B1 is mentioned in the description of =A1=B0message-generator-= id=A1=B1 in section 3.

But there is no defini= tion on =A1=B0previous-message-id=A1=B1 in section 4.2

Did you drop this feat= ure? Maybe you need to clean up the text on this.

 

Cheers,

Tianran

 

=B7=A2=BC=FE=C8=CB: netconf [mailt= o:netconf-bounces@ietf.org] =B4=FA=B1=ED Mahesh Jethanandani
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2020=C4=EA1=D4=C228=C8=D5 8:19
=CA=D5=BC=FE=C8=CB: Eric Voit (evoit) <evoit@cisco.com>
=B3=AD=CB=CD: netconf@ietf.org
=D6=F7=CC=E2: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Conf= igured receiver capability exchange)

 

Hi Eric,

 

This e-mail triggers two respon= ses. Let us deal with draft-ietf-netconf-notification-messages here, and I = will bring up comments/questions related to draft-ietf-netconf-https-notif = in the other thread.

 

You have indicated a desire tha= t receiver capabilities should be documented by the transport specific draf= t, e.g. draft-ietf-netconf-https-notif, and not this draft. As such you bel= ieve that the draft is ready.

 

To the WG, the authors have ind= icated a desire to wrap up this draft, and would like us, the chairs, to is= sue a WGLC on it. Before we do that, we wanted to ask if the WG believes th= at the document is ready, and that there are no more issues that need to discussed/addressed by draft-ietf-netconf-= notification-messages document at this time.

 

Cheers.

 

Mahesh and Kent (as co-chairs).=



On Jan 15, 2020, at 12:23 PM, E= ric Voit (evoit) <evoit@cisco.com= > wrote:

 

Hi Mahesh,

 

During the IETF 106 session, there w= as discussion on how both a publisher might know if there is receiver suppo= rt for draft-ietf-netconf-notification-me= ssages.  Section 6 highlights several of the considerations.   Relevant are the following:

 

(a) Remote device capability discove= ry from the point of view of the Publisher needs to be enhanced to know if = the far end can interpret notification messages type beyond RFC-5277, Section 4.

 

(b) This capability discovery questi= on is relevant for both configured subscription receivers and dynamic subsc= ribers.  =

 

(c) The capability discovery questio= n can be generalized beyond subscriptions, as there are many reasons to kno= w the available capabilities of the far end.   

 

(d) Capability discovery advertiseme= nt has traditionally been discussed within transport documents (e.g. RFC-62= 41 Section 8.1).   

 

 

Based on (a)-(d), coming up with a t= ransport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems overkill/hea= vyweight.

 

I was fine with letting this remote = capabilities discovery question sit for a while.   However dr= aft-ietf-netconf-https-notif shows that we now must address this question.  Specifically should the diag= ram section 1.4.1 show this capability exchange?  

 

It turns out that independent of dra= ft-ietf-netconf-notification-messages, there several questions in draft-iet= f-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG = defined notification #1" anyway.  These questions are:=

  (1) Does the targeted HTTPS r= eceiver support configured subscriptions?

  (2) Can the targeted HTTP@ re= ceiver accept a new subscription as described in a <subscription-started= >?

Only if these questions are "ye= s", should the <subscription-started> be responded to with an &q= uot;OK".

 

Add to this a third question driven = from (a)-(d):

  (3) Does the receiver support= the message type within "draft-ietf-netconf-notification-messages&quo= t;?

 

A strawman way to handle the all thr= ee questions within draft-ietf-netconf-https-notif would be to respond to a= <subscription-started> notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 would include = body elements listing supported receiver resources.  Maybe something Y= ANG encoded via ietf-yang-structure-ext containing:

 

      <f= oo xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

      =   <capabilities>

      =     <capability>

      =       urn:ietf:params:xml:ns:yang:ietf-notificatio= n-messages:1.0

      =     </capability>

       = ; </capabilities>

      </= foo>

 

What do you think of this approach?<= o:p>

 

Eric

 

Mahesh Jethanandani<= /span>

 

 

 

--_000_BBA82579FD347748BEADC4C445EA0F21BF1F227ANKGEML515MBXchi_-- From nobody Tue Feb 4 11:45:40 2020 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 CAFB21207FF for ; Tue, 4 Feb 2020 11:45:38 -0800 (PST) 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, 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 lJbaBwbdhLFW for ; Tue, 4 Feb 2020 11:45:35 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE18120807 for ; Tue, 4 Feb 2020 11:45:34 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id E18C486084A; Tue, 4 Feb 2020 20:47:39 +0100 (CET) Received: from localhost (unknown [172.29.2.111]) by trail.lhotka.name (Postfix) with ESMTPSA id D97DC860138; Tue, 4 Feb 2020 20:47:37 +0100 (CET) From: Ladislav Lhotka To: "Rob Wilton \(rwilton\)" , =?utf-8?Q?Sch=C3=B6nw?= =?utf-8?Q?=C3=A4lder=2C_J=C3=BCrgen?= , Kent Watsen Cc: Russ Housley , "netconf\@ietf.org" In-Reply-To: References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> Date: Tue, 04 Feb 2020 20:45:30 +0100 Message-ID: <87r1zarvad.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 04 Feb 2020 19:45:39 -0000 "Rob Wilton (rwilton)" writes: > +1 > > This would also be my normal interpretation of a structure described as a= "bag", although they don't seem to be that commonly used. I think the term was coined in Smalltalk-80, where Bag is a subclass of Col= lection such that - its elements are not ordered - are not accessible by a key - duplicates are allowed Lada > > Thanks, > Rob > > > -----Original Message----- > From: netconf On Behalf Of Sch=C3=B6nw=C3=A4ld= er, J=C3=BCrgen > Sent: 01 February 2020 08:09 > To: Kent Watsen > Cc: Russ Housley ; netconf@ietf.org > Subject: Re: [netconf] Truststore: bags, sets, or other? > > A common interpretation in various data structure libraries is this: > > set: unordered collection of something, duplicates not allowed > bag: unordered collection of something, duplicates allowed > > /js > > On Fri, Jan 31, 2020 at 10:06:10PM +0000, Kent Watsen wrote: >> Hi Martin, >>=20 >> >> NEW: >> >> +--rw -bags {}? >> >> +--rw -bag* [name] >> >> +--rw name string >> >> +--rw * [name] >> >> +--rw name string >> >> =E2=80=A6 >> >>=20 >> >> Better, right? Any other ideas? >> >=20 >> > We have current published modules with both "-list" and "-set". No=20 >> > "-bag" so far. >> >=20 >> > For example: >> >=20 >> > "list rule-list" in ietf-netconf-acm >> >=20 >> > "list module-set" in ietf-yang-library >>=20 >> True. >>=20 >>=20 >> > There are some examples of "s" as well, but these are plural "s" for=20 >> > a normal list of singletons, and should have been named w/o the=20 >> > plural "s" (if we were to be consistent). >> >=20 >> > I would try to avoid "s" for a "list-of-lists", but then pick the=20 >> > suffix that feels most natural in the domain. (For example, rather=20 >> > "list access-control-list" than "list access-control-set=E2=80=9D). >>=20 >> Agreed. >>=20 >> > Perhaps you can argue that "-list" works better for ordered=20 >> > sequences, and "-set" and "-bag" for unordered. But then there are=20 >> > "ordeded sets" and "unordered lists" (and even apparently "ordered=20 >> > bag", in UML). >>=20 >> Perhaps. >>=20 >> > The plural "s" is better for a surrounding container (if one exists). >>=20 >> Agreed. >>=20 >>=20 >> I also received a private response from Russ, who rather not join the ne= tconf list, but said: >>=20 >> 1) =E2=80=9Cbag=E2=80=9D was originally created to deal with issues with= ASN.1 the SET and SEQUENCE types, and since have entered general crypto pa= rlance outside the PKCS#12 context. >>=20 >> 2) =E2=80=9Cbag=E2=80=9D is the ideal term for when conveying a unordere= d collection of X.509 certificates. >>=20 >> 3) =E2=80=9Cbag=E2=80=9D is not known to be used in the context of SSH h= ost keys or RPKs, but there isn=E2=80=99t anything wrong or bad with doing = so either. >>=20 >> All said, I believe the best course is to use =E2=80=9Cbag=E2=80=9D and,= more specifically, to use the "/x-bags/x-bag/=E2=80=A6=E2=80=9D structure = that is present at the top of this message. Assuming there are no objecti= ons, this change will be in the next update. >>=20 >>=20 >> Kent >>=20 > >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > > --=20 > 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 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka=20 Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 5 12:42:20 2020 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 768B7120820; Wed, 5 Feb 2020 12:42:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, kent+ietf@watsen.net, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158093533847.12738.17199343831270840649.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 12:42:18 -0800 Archived-At: Subject: [netconf] netconf - Update to a Meeting Session Request for IETF 107 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, 05 Feb 2020 20:42:19 -0000 An update to a meeting session request has just been submitted by Kent Watsen, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: netmod httpbis tcpm idr Technology Overlap: opsarea opsawg Key Participant Conflict: bfd People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Robert Wilton Resources Requested: Special Requests: Please place the session in the first half of the week (i.e., M-W). --------------------------------------------------------- From nobody Fri Feb 7 00:39:39 2020 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 E9BBA120127 for ; Fri, 7 Feb 2020 00:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KEP0bPKH1I1R for ; Fri, 7 Feb 2020 00:39:35 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767FB12003E for ; Fri, 7 Feb 2020 00:39:35 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 26B14293DB093076BF61; Fri, 7 Feb 2020 08:39:34 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 7 Feb 2020 08:39:32 +0000 Received: from DGGEMM507-MBS.china.huawei.com ([169.254.3.81]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Fri, 7 Feb 2020 16:39:26 +0800 From: wangzitao To: Mahesh Jethanandani , "Eric Voit (evoit)" CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXdkf8/mCPF7MdBRxG9gZDvXDuo9Q== Date: Fri, 7 Feb 2020 08:39:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.54.171] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2DD15D3Adggemm507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 07 Feb 2020 08:39:38 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DD15D3Adggemm507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpIaSBFcmljIGFuZCBjaGFpcnMsDQoNCkkgaGF2ZSByZWFkIHRoaXMgdmVyc2lvbiBhbmQgaGF2 ZSBvbmUgcXVlc3Rpb24uDQpPbiB3aGF0IGJhc2lzIGRvZXMgdGhlIHB1Ymxpc2hlciBwYWNrYWdl IG5vdGlmaWNhdGlvbnMgZm9yIGRpZmZlcmVudCBzdWJzY3JpcHRpb25zIHRvZ2V0aGVyPw0KSXMg dGhlIGNsaWVudCBzZW5kaW5nIGluc3RydWN0aW9ucyB0byBwYWNrYWdlIGRpZmZlcmVudCBub3Rp ZmljYXRpb25zIHRvZ2V0aGVyPw0KT3IgaXMgdGhlIHB1Ymxpc2hlciByYW5kb21seSBwYWNraW5n IGRpZmZlcmVudCBub3RpZmljYXRpb25zIHRvZ2V0aGVyPw0KDQpCZXN0IFJlZ2FyZHMhDQotTWlj aGFlbA0KDQq3orz+yMs6IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gTWFoZXNoIEpldGhhbmFuZGFuaQ0Kt6LLzcqxvOQ6IDIwMjDE6jHUwjI4yNUgODoxOQ0K ytW8/sjLOiBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPg0Ks63LzTogbmV0Y29u ZkBpZXRmLm9yZw0K1vfM4jogW25ldGNvbmZdIFdHTEMgb24gZHJhZnQtaWV0Zi1uZXRjb25mLW5v dGlmaWNhdGlvbi1tZXNzYWdlcz8gKFdhcyBSZTogQ29uZmlndXJlZCByZWNlaXZlciBjYXBhYmls aXR5IGV4Y2hhbmdlKQ0KDQpIaSBFcmljLA0KDQpUaGlzIGUtbWFpbCB0cmlnZ2VycyB0d28gcmVz cG9uc2VzLiBMZXQgdXMgZGVhbCB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t bWVzc2FnZXMgaGVyZSwgYW5kIEkgd2lsbCBicmluZyB1cCBjb21tZW50cy9xdWVzdGlvbnMgcmVs YXRlZCB0byBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgaW4gdGhlIG90aGVyIHRocmVh ZC4NCg0KWW91IGhhdmUgaW5kaWNhdGVkIGEgZGVzaXJlIHRoYXQgcmVjZWl2ZXIgY2FwYWJpbGl0 aWVzIHNob3VsZCBiZSBkb2N1bWVudGVkIGJ5IHRoZSB0cmFuc3BvcnQgc3BlY2lmaWMgZHJhZnQs IGUuZy4gZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLCBhbmQgbm90IHRoaXMgZHJhZnQu IEFzIHN1Y2ggeW91IGJlbGlldmUgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkuDQoNClRvIHRoZSBX RywgdGhlIGF1dGhvcnMgaGF2ZSBpbmRpY2F0ZWQgYSBkZXNpcmUgdG8gd3JhcCB1cCB0aGlzIGRy YWZ0LCBhbmQgd291bGQgbGlrZSB1cywgdGhlIGNoYWlycywgdG8gaXNzdWUgYSBXR0xDIG9uIGl0 LiBCZWZvcmUgd2UgZG8gdGhhdCwgd2Ugd2FudGVkIHRvIGFzayBpZiB0aGUgV0cgYmVsaWV2ZXMg dGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHksIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBtb3JlIGlz c3VlcyB0aGF0IG5lZWQgdG8gZGlzY3Vzc2VkL2FkZHJlc3NlZCBieSBkcmFmdC1pZXRmLW5ldGNv bmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzIGRvY3VtZW50IGF0IHRoaXMgdGltZS4NCg0KQ2hlZXJz Lg0KDQpNYWhlc2ggYW5kIEtlbnQgKGFzIGNvLWNoYWlycykuDQoNCg0KT24gSmFuIDE1LCAyMDIw LCBhdCAxMjoyMyBQTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86 ZXZvaXRAY2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIE1haGVzaCwNCg0KRHVyaW5nIHRoZSBJRVRG IDEwNiBzZXNzaW9uLCB0aGVyZSB3YXMgZGlzY3Vzc2lvbiBvbiBob3cgYm90aCBhIHB1Ymxpc2hl ciBtaWdodCBrbm93IGlmIHRoZXJlIGlzIHJlY2VpdmVyIHN1cHBvcnQgZm9yIGRyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy8/aW5jbHVkZV90 ZXh0PTE+LiAgU2VjdGlvbiA2IGhpZ2hsaWdodHMgc2V2ZXJhbCBvZiB0aGUgY29uc2lkZXJhdGlv bnMuICAgUmVsZXZhbnQgYXJlIHRoZSBmb2xsb3dpbmc6DQoNCihhKSBSZW1vdGUgZGV2aWNlIGNh cGFiaWxpdHkgZGlzY292ZXJ5IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIFB1Ymxpc2hl ciBuZWVkcyB0byBiZSBlbmhhbmNlZCB0byBrbm93IGlmIHRoZSBmYXIgZW5kIGNhbiBpbnRlcnBy ZXQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIHR5cGUgYmV5b25kIFJGQy01Mjc3LCBTZWN0aW9uIDQu DQoNCihiKSBUaGlzIGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1ZXN0aW9uIGlzIHJlbGV2YW50IGZv ciBib3RoIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHJlY2VpdmVycyBhbmQgZHluYW1pYyBzdWJz Y3JpYmVycy4NCg0KKGMpIFRoZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBxdWVzdGlvbiBjYW4gYmUg Z2VuZXJhbGl6ZWQgYmV5b25kIHN1YnNjcmlwdGlvbnMsIGFzIHRoZXJlIGFyZSBtYW55IHJlYXNv bnMgdG8ga25vdyB0aGUgYXZhaWxhYmxlIGNhcGFiaWxpdGllcyBvZiB0aGUgZmFyIGVuZC4NCg0K KGQpIENhcGFiaWxpdHkgZGlzY292ZXJ5IGFkdmVydGlzZW1lbnQgaGFzIHRyYWRpdGlvbmFsbHkg YmVlbiBkaXNjdXNzZWQgd2l0aGluIHRyYW5zcG9ydCBkb2N1bWVudHMgKGUuZy4gUkZDLTYyNDEg U2VjdGlvbiA4LjEpLg0KDQoNCkJhc2VkIG9uIChhKS0oZCksIGNvbWluZyB1cCB3aXRoIGEgdHJh bnNwb3J0IGluZGVwZW5kZW50IHBvaW50LXNvbHV0aW9uIHdpdGhpbiBkcmFmdC1pZXRmLW5ldGNv bmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2luY2x1ZGVfdGV4dD0x PiAqanVzdCogdG8gZGlzY292ZXIgdGhpcyBzaW5nbGUgZWxlbWVudCBvZiBjbGllbnQgZnVuY3Rp b25hbGl0eSBzZWVtcyBvdmVya2lsbC9oZWF2eXdlaWdodC4NCg0KSSB3YXMgZmluZSB3aXRoIGxl dHRpbmcgdGhpcyByZW1vdGUgY2FwYWJpbGl0aWVzIGRpc2NvdmVyeSBxdWVzdGlvbiBzaXQgZm9y IGEgd2hpbGUuICAgSG93ZXZlciBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWY8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wMT4g c2hvd3MgdGhhdCB3ZSBub3cgbXVzdCBhZGRyZXNzIHRoaXMgcXVlc3Rpb24uICBTcGVjaWZpY2Fs bHkgc2hvdWxkIHRoZSBkaWFncmFtIHNlY3Rpb24gMS40LjEgc2hvdyB0aGlzIGNhcGFiaWxpdHkg ZXhjaGFuZ2U/DQoNCkl0IHR1cm5zIG91dCB0aGF0IGluZGVwZW5kZW50IG9mIGRyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIHRoZXJlIHNldmVyYWwgcXVlc3Rpb25zIGlu IGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3aGljaCBuZWVkIHRvIGJlIGFuc3dlcmVk IHByaW9yIHRvIHRoZSBzZWN0aW9uIDEuNC4xIGFycm93OiAiU2VuZCBIVFRQUyBQT1NUIG1lc3Nh Z2Ugd2l0aCBZQU5HIGRlZmluZWQgbm90aWZpY2F0aW9uICMxIiBhbnl3YXkuICBUaGVzZSBxdWVz dGlvbnMgYXJlOg0KICAoMSkgRG9lcyB0aGUgdGFyZ2V0ZWQgSFRUUFMgcmVjZWl2ZXIgc3VwcG9y dCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnM/DQogICgyKSBDYW4gdGhlIHRhcmdldGVkIEhUVFBA IHJlY2VpdmVyIGFjY2VwdCBhIG5ldyBzdWJzY3JpcHRpb24gYXMgZGVzY3JpYmVkIGluIGEgPHN1 YnNjcmlwdGlvbi1zdGFydGVkPj8NCk9ubHkgaWYgdGhlc2UgcXVlc3Rpb25zIGFyZSAieWVzIiwg c2hvdWxkIHRoZSA8c3Vic2NyaXB0aW9uLXN0YXJ0ZWQ+IGJlIHJlc3BvbmRlZCB0byB3aXRoIGFu ICJPSyIuDQoNCkFkZCB0byB0aGlzIGEgdGhpcmQgcXVlc3Rpb24gZHJpdmVuIGZyb20gKGEpLShk KToNCiAgKDMpIERvZXMgdGhlIHJlY2VpdmVyIHN1cHBvcnQgdGhlIG1lc3NhZ2UgdHlwZSB3aXRo aW4gImRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMiPw0KDQpBIHN0cmF3 bWFuIHdheSB0byBoYW5kbGUgdGhlIGFsbCB0aHJlZSBxdWVzdGlvbnMgd2l0aGluIGRyYWZ0LWll dGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3b3VsZCBiZSB0byByZXNwb25kIHRvIGEgPHN1YnNjcmlw dGlvbi1zdGFydGVkPiBub3RpZmljYXRpb24gd2l0aCBhbiBIVFRQIFN0YXR1cyAyMDIgKEFjY2Vw dGVkKSIgYWNrbm93bGVkZ2VtZW50LiAgVGhpcyAyMDIgd291bGQgaW5jbHVkZSBib2R5IGVsZW1l bnRzIGxpc3Rpbmcgc3VwcG9ydGVkIHJlY2VpdmVyIHJlc291cmNlcy4gIE1heWJlIHNvbWV0aGlu ZyBZQU5HIGVuY29kZWQgdmlhIGlldGYteWFuZy1zdHJ1Y3R1cmUtZXh0IGNvbnRhaW5pbmc6DQoN CiAgICAgIDxmb28geG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEu MCI+DQogICAgICAgIDxjYXBhYmlsaXRpZXM+DQogICAgICAgICAgPGNhcGFiaWxpdHk+DQogICAg ICAgICAgICB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1ub3RpZmljYXRpb24tbWVz c2FnZXM6MS4wDQogICAgICAgICAgPC9jYXBhYmlsaXR5Pg0KICAgICAgICA8L2NhcGFiaWxpdGll cz4NCiAgICAgIDwvZm9vPg0KDQpXaGF0IGRvIHlvdSB0aGluayBvZiB0aGlzIGFwcHJvYWNoPw0K DQpFcmljDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DD15D3Adggemm507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

Hi Eric and chairs,

 

I have read this versi= on and have one question.

On what basis does the= publisher package notifications for different subscriptions together?

Is the client sending = instructions to package different notifications together?

Or is the publisher ra= ndomly packing different notifications together?

 

Best Regards!

-Michael

 

=B7=A2=BC=FE=C8=CB: netconf [mailt= o:netconf-bounces@ietf.org] =B4=FA=B1=ED Mahesh Jethanandani
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2020=C4=EA1=D4=C228=C8=D5 8:19
=CA=D5=BC=FE=C8=CB: Eric Voit (evoit) <evoit@cisco.com>
=B3=AD=CB=CD: netconf@ietf.org
=D6=F7=CC=E2: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Conf= igured receiver capability exchange)

 

Hi Eric,

 

This e-mail triggers two respon= ses. Let us deal with draft-ietf-netconf-notification-messages here, and I = will bring up comments/questions related to draft-ietf-netconf-https-notif = in the other thread.

 

You have indicated a desire tha= t receiver capabilities should be documented by the transport specific draf= t, e.g. draft-ietf-netconf-https-notif, and not this draft. As such you bel= ieve that the draft is ready.

 

To the WG, the authors have ind= icated a desire to wrap up this draft, and would like us, the chairs, to is= sue a WGLC on it. Before we do that, we wanted to ask if the WG believes th= at the document is ready, and that there are no more issues that need to discussed/addressed by draft-ietf-netconf-= notification-messages document at this time.

 

Cheers.

 

Mahesh and Kent (as co-chairs).=



On Jan 15, 2020, at 12:23 PM, E= ric Voit (evoit) <evoit@cisco.com= > wrote:

 

Hi Mahesh,

 

During the IETF 106 session, there w= as discussion on how both a publisher might know if there is receiver suppo= rt for draft-ietf-netconf-notification-me= ssages.  Section 6 highlights several of the considerations.   Relevant are the following:

 

(a) Remote device capability discove= ry from the point of view of the Publisher needs to be enhanced to know if = the far end can interpret notification messages type beyond RFC-5277, Section 4.

 

(b) This capability discovery questi= on is relevant for both configured subscription receivers and dynamic subsc= ribers.  =

 

(c) The capability discovery questio= n can be generalized beyond subscriptions, as there are many reasons to kno= w the available capabilities of the far end.   

 

(d) Capability discovery advertiseme= nt has traditionally been discussed within transport documents (e.g. RFC-62= 41 Section 8.1).   

 

 

Based on (a)-(d), coming up with a t= ransport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems overkill/hea= vyweight.

 

I was fine with letting this remote = capabilities discovery question sit for a while.   However dr= aft-ietf-netconf-https-notif shows that we now must address this question.  Specifically should the diag= ram section 1.4.1 show this capability exchange?  

 

It turns out that independent of dra= ft-ietf-netconf-notification-messages, there several questions in draft-iet= f-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG = defined notification #1" anyway.  These questions are:=

  (1) Does the targeted HTTPS r= eceiver support configured subscriptions?

  (2) Can the targeted HTTP@ re= ceiver accept a new subscription as described in a <subscription-started= >?

Only if these questions are "ye= s", should the <subscription-started> be responded to with an &q= uot;OK".

 

Add to this a third question driven = from (a)-(d):

  (3) Does the receiver support= the message type within "draft-ietf-netconf-notification-messages&quo= t;?

 

A strawman way to handle the all thr= ee questions within draft-ietf-netconf-https-notif would be to respond to a= <subscription-started> notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 would include = body elements listing supported receiver resources.  Maybe something Y= ANG encoded via ietf-yang-structure-ext containing:

 

      <f= oo xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

      =   <capabilities>

      =     <capability>

      =       urn:ietf:params:xml:ns:yang:ietf-notificatio= n-messages:1.0

      =     </capability>

       = ; </capabilities>

      </= foo>

 

What do you think of this approach?<= o:p>

 

Eric

 

Mahesh Jethanandani<= /span>

 

 

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2DD15D3Adggemm507mbschi_-- From nobody Fri Feb 7 08:13:34 2020 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 BBA3E120936 for ; Fri, 7 Feb 2020 08:13:31 -0800 (PST) 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 4Y1_fA5aB001 for ; Fri, 7 Feb 2020 08:13:29 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140080.outbound.protection.outlook.com [40.107.14.80]) (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 9C9BE120914 for ; Fri, 7 Feb 2020 08:13:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FwXliknSJYVRz4B4/mb1rmZplr/BVHMuqGa3qrUJQoJbIMhNomeo/9qAfrykzke8ikR0+O8S3pzgU6/L8LsBOiidpSX+c0WjObCK+jm8WSLItRZLSq6D6NsFgdNYg5VWxsSlQssduMbjp6BTGs630gFiemnovmLueCmX9xssIL2PmzxcEgjEi18J6aQs6k7nF9ePxfAWVE8A0l4xO0IPmeMEquHjkKSsWiYWavhv1WcgJQtO4nMhfw7jGwtxNJCQrW+VhmfXd9QOl+5EA4f0yrCy5/t16UjPqvnhd6EwSLInHKWEZ7xx+e4MVw8PuSrC0lpFLxt1S/+Qxe/y+TEkxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iwjCKD1pDX/c3g+QIwo2n/Ltjp4OjtLd85HiqCCr060=; b=nTyJ0LVQ16rGv+1FE00xOzWSmc2CD3eUcarnoGEg+U8gMb6ZgkIxjyvbH55S6KqROyjKG9GKWusqPluIMmi/0qtf1/S39T7D9zoySNNcsz0XQ8Ww7vmeKgDaAL0utcDVjajyBInqRGWKs3wGBzc8GAG2HICFcorkGJLZwKgxpc6N4nWzV2tQ9wxl2WU38Kry3ERAGr3ndWa9H2jyTDz6XYW+PnPNjYIUCh1JKnj+oZfpdW1MisWE0Wv0j+1ECVpXL5xjHy+Vr88wAvkMHUEyn0bge2X/sW4KFvWzC7XToqtwoa/4fFHcJMT80qffUV6vNVJ7YkfnBhA383OifNXafg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=iwjCKD1pDX/c3g+QIwo2n/Ltjp4OjtLd85HiqCCr060=; b=uHYfIeHX+sKnqF9a6QnGAJvWSIOkj61q4BF9JxWjSmvaQO1OYpzkAi6L+UPFYBF6cVUR7WrrWQ4JN92PHq1uwtUvjazNJjltNWd4EgPgSh6v3zTYE3RL8HuKDoe8qcFIiDe5CUEOOEfFP8zgrYyXY0keNGgd+ln8gU0aBp4H4gs= Received: from AM0PR07MB5187.eurprd07.prod.outlook.com (20.178.20.74) by AM0PR07MB5811.eurprd07.prod.outlook.com (20.178.116.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.14; Fri, 7 Feb 2020 16:13:25 +0000 Received: from AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::8484:2bbf:1c00:59bf]) by AM0PR07MB5187.eurprd07.prod.outlook.com ([fe80::8484:2bbf:1c00:59bf%7]) with mapi id 15.20.2707.024; Fri, 7 Feb 2020 16:13:25 +0000 From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= To: Kent Watsen , "Rob Wilton (rwilton)" CC: Russ Housley , "netconf@ietf.org" Thread-Topic: [netconf] Truststore: bags, sets, or other? Thread-Index: AQHV19IFrT35I9oBREWFMndAWafGq6gEja2AgADH+ACAAKiCgIADlQqAgABcOQCABgOQYA== Date: Fri, 7 Feb 2020 16:13:24 +0000 Message-ID: References: <0100016ff91dfd1b-9e8e6622-7e36-45dc-a661-f4702b494040-000000@email.amazonses.com> <20200131.111027.840757629039452002.mbj@tail-f.com> <0100016ffda3d528-f411ef14-2813-4372-99c4-8269e5ea435e-000000@email.amazonses.com> <20200201080916.yrlurqzzlconhxlr@anna.jacobs.jacobs-university.de> <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-000000@email.amazonses.com> In-Reply-To: <010001700cb72510-63109303-e8df-4b7a-9910-1110131432b9-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: [176.63.13.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a3f90e7e-7ec3-440f-3137-08d7abe8a918 x-ms-traffictypediagnostic: AM0PR07MB5811: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(366004)(136003)(346002)(189003)(199004)(4326008)(8936002)(66574012)(85182001)(55016002)(33656002)(9686003)(54906003)(110136005)(53546011)(6506007)(26005)(7696005)(316002)(186003)(76116006)(52536014)(86362001)(64756008)(66556008)(66476007)(66946007)(66446008)(71200400001)(5660300002)(85202003)(478600001)(8676002)(81156014)(81166006)(2906002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5811; H:AM0PR07MB5187.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: BCL:0; x-microsoft-antispam-message-info: AcKAE0ABQu6ZayVNOlb9jHMZ5gSq/fuuZlpd1fhm8WtGfchtM3hppV08B/BWlcix9Etj77plAKX3t9paI/Jl02tNJu4YlvuE1Qrw5QLMS2dCyjo+CVRo1zsLMzZ0qPut4pC/EvbkzOLpRY0kigX7O9ePK/KPqmCRTq7uwqOdHNK8dqZSmPSTO+T/Hi+N1U15WSHAzlzBM/Uo+og4eMQ/AcGvRk376Xo9l7x984sH2+5ZYVxGQpFi9wIsyos0zcxdPyFbEepkTxzkUe2ld9VQ7bloeaa3GWDTcXggcg5dsSFpqFprJ62PWxSuvn/SX3U+CGZ5npc/SSCBo+rzd2zZc7m4A9vQpbOQJQdfl8EHWXJgefboxrI0O+dz24sve4bzSupyu4m0IgSUlYp5cFtNUh3UlUnSW0LZx457ViX4b1RG7is9He/kjUN38NCHPUHbAW1kFKNkg0SyxcROGQHeLlMNULVQS9kDWs0yAIjrcwOF9vnPO81o99O0NBy/Pl73/wnHGXK5QdRlwNHo5NjT0g== x-ms-exchange-antispam-messagedata: +pCVa4m/03F3J7ZPnuos6CLJtMyRm8xLVmK4iC4ulEqxJZP6VaG796YVrY5p78xOrQ/wyPRtWiy75R0dBuwYYCCCB3yBINjWDC5FUtzzC6EjKNIrEBqD8S1OYHanjG7M8krxiYTCbm0efoWopI9HiQ== x-ms-exchange-transport-forked: True 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: a3f90e7e-7ec3-440f-3137-08d7abe8a918 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 16:13:25.3092 (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: eVdpsZpVzQXXaYiU/sNDWr0iCzREpz8QcVH5wmzxrlmfIQMRan/86dxeDywEdlKHAVgPn50+h9JzSPwMF3tW1ASGsJCTRHVUdIrUkYZMdns= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5811 Archived-At: Subject: Re: [netconf] Truststore: bags, sets, or other? 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, 07 Feb 2020 16:13:32 -0000 SGksDQoNCkkgYWdyZWUgdGhhdCBiYWcgaXMgYW4gYXBwcm9wcmlhdGUgdGVybSBpbiB0aGUgY2Vy dGlmaWNhdGUgbWFuYWdlbWVudCBvciBjcnlwdG8tZG9tYWluLiBTbyAgKzEgZm9yIHRoYXQuDQoN CkJyLA0KQmFsYXpzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRjb25m IDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAzLCAyMDIwIDk6MjIgUE0NClRvOiBSb2IgV2lsdG9uIChyd2ls dG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQpDYzogUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2ls c2VjLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gVHJ1c3Rz dG9yZTogYmFncywgc2V0cywgb3Igb3RoZXI/DQoNClNlYXJjaGluZyBvbmxpbmUgZm9yIOKAnGJh Z+KAnSwgSSBmb3VuZCBkZWZpbml0aW9ucyB2YXJ5IChldmVuIGFtb25nc3QgdW5pdmVyc2l0eSBD UyBzaXRlcykgcmVnYXJkaW5nIGlmIGR1cGxpY2F0ZXMgYXJlIGFsbG93ZWQuICBGV0lXLCB0aGlz IHZhcmlhdGlvbiBhbHNvIGV4aXN0cyBpbiBJRVRGIFJGQ3MsIGFzIENNUyB1c2VzIHRoZSBBU04u MeKAmXMgIlNFVCBPRuKAnSBzeW50YXggKGR1cGxpY2F0ZXMgbm90IGFsbG93ZWQpIHdoZXJlYXMg UEtDUyMxMiB1c2VzIEFTTi4x4oCZcyDigJxTRVFVRU5DReKAnSBzeW50YXggKGR1cGxpY2F0ZXMg YWxsb3dlZCkuICBJbiBhbnkgY2FzZSwgaWYgZHVwbGljYXRlcyBhcmUgcHJlc2VudCwgdGhleSBo YXZlIG5vIGltcGFjdCBvbiBwcm9jZXNzaW5nIGJlaGF2aW9yIChlLmcuLCBhIGNlcnRpZmljYXRl IGlzbuKAmXQgc29tZWhvdyBtb3JlIHRydXN0ZWQgaWYgaXQgYXBwZWFycyBtb3JlIHRoYW4gb25j ZSkuDQoNCk9mIGNvdXJzZSwgWUFORyBvbmx5IGhhcyDigJhsaXN04oCZIGFuZCDigJhsZWFmLWxp c3TigJkgc3RhdGVtZW50cyBmb3IgY29sbGVjdGlvbnMuICBTbyBwZXJmZWN0IG1hcHBpbmdzIGFy ZW7igJl0IGFsd2F5cyBwb3NzaWJsZS4gIEFzIE1hcnRpbiBub3RlZCBpbiBoaXMgbWVzc2FnZSwg dGhlIHN1YnN0cmluZyAic2V04oCdIGlzIHVzZWQgaW4gcHVibGlzaGVkIG1vZHVsZXMgKGUuZy4s IG1vZHVsZS1zZXQpLiAgSW50ZXJlc3RpbmdseSwgbGlzdHMgZ2VuZXJhbGx5IGFsbG93IGZvciBk dXBsaWNhdGVzLCBidXQgWUFORyBsaXN0cyBkb27igJl0LCBkdWUgdG8gYmVpbmcga2V5ZWQsIHVu bGVzcyB0aGUgc2NvcGUgaXMgcmVkdWNlIHRvIHRoZSBub24ta2V5IGZpZWxkcywgZS5nLiwgYXNz dW1pbmcgY2VydGlmaWNhdGUg4oCYQ+KAmSwgYm90aCB7a2V5MSwgQ30gYW5kIHtrZXkyLCBDfSBj b3VsZCBiZSBpbiB0aGUgVHJ1c3RzdG9yZSBhdCB0aGUgc2FtZSB0aW1lLg0KDQpJIHN0aWxsIGZl ZWwgdGhhdCDigJxiYWfigJ0gaXMgdGhlIGJlc3QgdGVybSB0byB1c2UgaGVyZSBkdWUgdG8gaXQg YmVpbmcgYSBkaXN0aW5jdGl2ZSBjcnlwdG8tZG9tYWluIHRlcm0gdXNlZCBmb3Igc2V0LWxpa2Ug Y29sbGVjdGlvbnMuICBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoaXMgKHVzaW5nIOKAnGJhZ+KAnSkg aXMgb2theSBzaW5jZSBubyByZWFsIG9iamVjdGlvbiBoYXMgYmVlbiB2b2ljZWQgeWV0LCBidXQg cGxlYXNlIGxldCBtZSBrbm93IGlmIHRoYXQgaXMgYSBtaXN1bmRlcnN0YW5kaW5nIG9uIG15IHBh cnQuDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQo+IE9uIEZlYiAzLCAyMDIwLCBhdCA5OjUx IEFNLCBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiAN Cj4gKzENCj4gDQo+IFRoaXMgd291bGQgYWxzbyBiZSBteSBub3JtYWwgaW50ZXJwcmV0YXRpb24g b2YgYSBzdHJ1Y3R1cmUgZGVzY3JpYmVkIGFzIGEgImJhZyIsIGFsdGhvdWdoIHRoZXkgZG9uJ3Qg c2VlbSB0byBiZSB0aGF0IGNvbW1vbmx5IHVzZWQuDQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiAN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5ldGNvbmYgPG5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFNjaMO2bnfDpGxkZXIsIA0KPiBKw7xy Z2VuDQo+IFNlbnQ6IDAxIEZlYnJ1YXJ5IDIwMjAgMDg6MDkNCj4gVG86IEtlbnQgV2F0c2VuIDxr ZW50K2lldGZAd2F0c2VuLm5ldD4NCj4gQ2M6IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNl Yy5jb20+OyBuZXRjb25mQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gVHJ1c3Rz dG9yZTogYmFncywgc2V0cywgb3Igb3RoZXI/DQo+IA0KPiBBIGNvbW1vbiBpbnRlcnByZXRhdGlv biBpbiB2YXJpb3VzIGRhdGEgc3RydWN0dXJlIGxpYnJhcmllcyBpcyB0aGlzOg0KPiANCj4gc2V0 OiB1bm9yZGVyZWQgY29sbGVjdGlvbiBvZiBzb21ldGhpbmcsIGR1cGxpY2F0ZXMgbm90IGFsbG93 ZWQNCj4gYmFnOiB1bm9yZGVyZWQgY29sbGVjdGlvbiBvZiBzb21ldGhpbmcsIGR1cGxpY2F0ZXMg YWxsb3dlZA0KPiANCj4gL2pzDQo+IA0KPiBPbiBGcmksIEphbiAzMSwgMjAyMCBhdCAxMDowNjox MFBNICswMDAwLCBLZW50IFdhdHNlbiB3cm90ZToNCj4+IEhpIE1hcnRpbiwNCj4+IA0KPj4+PiBO RVc6DQo+Pj4+ICAgICAgICAgICArLS1ydyA8dGhpbmc+LWJhZ3Mgezx0aGluZy1mZWF0dXJlPn0/ DQo+Pj4+ICAgICAgICAgICAgICArLS1ydyA8dGhpbmc+LWJhZyogW25hbWVdDQo+Pj4+ICAgICAg ICAgICAgICAgICArLS1ydyBuYW1lIHN0cmluZw0KPj4+PiAgICAgICAgICAgICAgICAgICAgKy0t cncgPHRoaW5nPiogW25hbWVdDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICArLS1ydyBuYW1l IHN0cmluZw0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgIOKApg0KPj4+PiANCj4+Pj4gQmV0 dGVyLCByaWdodD8gICBBbnkgb3RoZXIgaWRlYXM/DQo+Pj4gDQo+Pj4gV2UgaGF2ZSBjdXJyZW50 IHB1Ymxpc2hlZCBtb2R1bGVzIHdpdGggYm90aCAiLWxpc3QiIGFuZCAiLXNldCIuICBObyANCj4+ PiAiLWJhZyIgc28gZmFyLg0KPj4+IA0KPj4+IEZvciBleGFtcGxlOg0KPj4+IA0KPj4+ICJsaXN0 IHJ1bGUtbGlzdCIgaW4gaWV0Zi1uZXRjb25mLWFjbQ0KPj4+IA0KPj4+ICJsaXN0IG1vZHVsZS1z ZXQiIGluIGlldGYteWFuZy1saWJyYXJ5DQo+PiANCj4+IFRydWUuDQo+PiANCj4+IA0KPj4+IFRo ZXJlIGFyZSBzb21lIGV4YW1wbGVzIG9mICJzIiBhcyB3ZWxsLCBidXQgdGhlc2UgYXJlIHBsdXJh bCAicyIgZm9yIA0KPj4+IGEgbm9ybWFsIGxpc3Qgb2Ygc2luZ2xldG9ucywgYW5kIHNob3VsZCBo YXZlIGJlZW4gbmFtZWQgdy9vIHRoZSANCj4+PiBwbHVyYWwgInMiIChpZiB3ZSB3ZXJlIHRvIGJl IGNvbnNpc3RlbnQpLg0KPj4+IA0KPj4+IEkgd291bGQgdHJ5IHRvIGF2b2lkICJzIiBmb3IgYSAi bGlzdC1vZi1saXN0cyIsIGJ1dCB0aGVuIHBpY2sgdGhlIA0KPj4+IHN1ZmZpeCB0aGF0IGZlZWxz IG1vc3QgbmF0dXJhbCBpbiB0aGUgZG9tYWluLiAgKEZvciBleGFtcGxlLCByYXRoZXIgDQo+Pj4g Imxpc3QgYWNjZXNzLWNvbnRyb2wtbGlzdCIgdGhhbiAibGlzdCBhY2Nlc3MtY29udHJvbC1zZXTi gJ0pLg0KPj4gDQo+PiBBZ3JlZWQuDQo+PiANCj4+PiBQZXJoYXBzIHlvdSBjYW4gYXJndWUgdGhh dCAiLWxpc3QiIHdvcmtzIGJldHRlciBmb3Igb3JkZXJlZCANCj4+PiBzZXF1ZW5jZXMsIGFuZCAi LXNldCIgYW5kICItYmFnIiBmb3IgdW5vcmRlcmVkLiAgQnV0IHRoZW4gdGhlcmUgYXJlIA0KPj4+ ICJvcmRlZGVkIHNldHMiIGFuZCAidW5vcmRlcmVkIGxpc3RzIiAoYW5kIGV2ZW4gYXBwYXJlbnRs eSAib3JkZXJlZCANCj4+PiBiYWciLCBpbiBVTUwpLg0KPj4gDQo+PiBQZXJoYXBzLg0KPj4gDQo+ Pj4gVGhlIHBsdXJhbCAicyIgaXMgYmV0dGVyIGZvciBhIHN1cnJvdW5kaW5nIGNvbnRhaW5lciAo aWYgb25lIGV4aXN0cykuDQo+PiANCj4+IEFncmVlZC4NCj4+IA0KPj4gDQo+PiBJIGFsc28gcmVj ZWl2ZWQgYSBwcml2YXRlIHJlc3BvbnNlIGZyb20gUnVzcywgd2hvIHJhdGhlciBub3Qgam9pbiB0 aGUgbmV0Y29uZiBsaXN0LCBidXQgc2FpZDoNCj4+IA0KPj4gMSkg4oCcYmFn4oCdIHdhcyBvcmln aW5hbGx5IGNyZWF0ZWQgdG8gZGVhbCB3aXRoIGlzc3VlcyB3aXRoIEFTTi4xIHRoZSBTRVQgYW5k IFNFUVVFTkNFIHR5cGVzLCBhbmQgc2luY2UgaGF2ZSBlbnRlcmVkIGdlbmVyYWwgY3J5cHRvIHBh cmxhbmNlIG91dHNpZGUgdGhlIFBLQ1MjMTIgY29udGV4dC4NCj4+IA0KPj4gMikg4oCcYmFn4oCd IGlzIHRoZSBpZGVhbCB0ZXJtIGZvciB3aGVuIGNvbnZleWluZyBhIHVub3JkZXJlZCBjb2xsZWN0 aW9uIG9mIFguNTA5IGNlcnRpZmljYXRlcy4NCj4+IA0KPj4gMykg4oCcYmFn4oCdIGlzIG5vdCBr bm93biB0byBiZSB1c2VkIGluIHRoZSBjb250ZXh0IG9mIFNTSCBob3N0IGtleXMgb3IgUlBLcywg YnV0IHRoZXJlIGlzbuKAmXQgYW55dGhpbmcgd3Jvbmcgb3IgYmFkIHdpdGggZG9pbmcgc28gZWl0 aGVyLg0KPj4gDQo+PiBBbGwgc2FpZCwgSSBiZWxpZXZlIHRoZSBiZXN0IGNvdXJzZSBpcyB0byB1 c2Ug4oCcYmFn4oCdIGFuZCwgbW9yZSBzcGVjaWZpY2FsbHksIHRvIHVzZSB0aGUgIi94LWJhZ3Mv eC1iYWcv4oCm4oCdIHN0cnVjdHVyZSB0aGF0IGlzIHByZXNlbnQgYXQgdGhlIHRvcCBvZiB0aGlz IG1lc3NhZ2UuICAgQXNzdW1pbmcgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMsIHRoaXMgY2hhbmdl IHdpbGwgYmUgaW4gdGhlIG5leHQgdXBkYXRlLg0KPj4gDQo+PiANCj4+IEtlbnQNCj4+IA0KPiAN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBu ZXRjb25mIG1haWxpbmcgbGlzdA0KPj4gbmV0Y29uZkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+IA0KPiANCj4gLS0gDQo+IEp1ZXJn ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI DQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5 IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiBuZXRj b25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Fri Feb 7 13:55:46 2020 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 1649A1200F1 for ; Fri, 7 Feb 2020 13:55:44 -0800 (PST) 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, 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QoOOP4n1; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=lwzFCBLE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTIjgIsVU2oz for ; Fri, 7 Feb 2020 13:55:42 -0800 (PST) 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 C06A01200F3 for ; Fri, 7 Feb 2020 13:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32699; q=dns/txt; s=iport; t=1581112541; x=1582322141; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=damRv7NuJ4vfVUdXx9joZcZuH66Fl76C5jmNBaldxkw=; b=QoOOP4n1CkPD3j58try/28/gK/VcA+5/4/N9zyf5CnSttFGMpeXMhiZ7 o3l6tJIaRKY3UFM5n8bDvw3TU9oViTloC5MmTkPsYbN+cwufxRzP04F5g LJkJPByDzj2dnLoBAPnbeH3w2yXYhaKqhfKOqlSYlxk0xzfxgIH6RLsD1 0=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AJH2/4h0mBCKFrjKYsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGPt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFP8LeLCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAgDL2z1e/4kNJK1cChsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgXuBJS9QBWwrLSAECyoKhAuDRgOKfoJfiWKOMIJSA1Q?= =?us-ascii?q?CBwEBAQkDAQElCAIBAYRAAoJDJDgTAgMNAQEEAQEBAgEFBG2FNwyFZgEBAQQ?= =?us-ascii?q?SEQoTAQE1AgEPAgEGAhUQEwMEAwICAh8RFBEBAQQBDQUIBg0HgwWBfU0DHw8?= =?us-ascii?q?BAgyTRJBnAoE5iGJ1gTKCfwEBBYEzAg5BgxgNC4IFBwMGgTiBU4pQGoFBP4E?= =?us-ascii?q?RR4JMPoIbSQEBAgEBGIEcLysJgloygiyNYpJcjnRECoI6g2yCO4ElilSER4J?= =?us-ascii?q?IjFmLbo5kiGyCKJARAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDY4dOIM7hRSFP3S?= =?us-ascii?q?BKYwvAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,414,1574121600"; d="p7s'?scan'208,217";a="477735828" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Feb 2020 21:55:39 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 017Ltcs6002064 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Feb 2020 21:55:38 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 7 Feb 2020 15:55:38 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 7 Feb 2020 16:55:37 -0500 Received: from NAM11-CO1-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, 7 Feb 2020 15:55:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IN2LHcYAvSDVE1c5uOs1vlDLiAhIoRWg696VB5ig6SEFEuObMKG/nn3gbYUz6w870jwZHWkCtYN6g0SmXgVeodLcRa+AKtcsy3HGgXFe9KOpmq6VDPg9klrEltoUaMKOK0kfcw1svCqswGWB98ap44RGJQlB3oPTyey8yzLHJO7gezKf3qexyqYyRU7YKSS7F9nHIU97h+3Gi+TjliaVPF+uDk5+wePQeXm5yW/wicDyY1JvRREhgimgf9WtOskY5lM5WOw8Pfb2S6HjSdVTNM0xeEJDxrNkoh+bcXnCEJuH7/6QmebnsunZq2hu3T/Ze/nPvbl1+Q6OZPYlSGjvQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hei/3Q1QXaH9UAGGNbd0Ifs2N3IhuvnEH6eIGzJp5L8=; b=gggx5rO7U4mFGxFWoS322byNmR+g2rR3YjzRrf+OUemKDUP9SRe9+wwxFMGTqS8LiejOtv4UcuQjQE/qywH4xzacMQmcLSFxwqdaEmgKt7ECAUfGJdwBmNcSusjtRWQBmAzxft4RJAZMpMvBUz5Pjmdy8dOUIDv/n/YE4vPLBn6FmnAqxPvY80zgAEsFJllQMXOAAzJBBbt/StjiLluc33288IKOtdpSL9jiHTFPz09qkBcazxZ2F6ElFVwnPTiaOPKo114HPuVLVkZOvQIJ3/vlnY+pjZaK+ow0YtfJV59er0Sql6v68Ql7JfQ4VZF2pdJqK+4dliiLGvyYqRExwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none 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=Hei/3Q1QXaH9UAGGNbd0Ifs2N3IhuvnEH6eIGzJp5L8=; b=lwzFCBLEH+C2HE+rveuqiEgqPVZtOqModj42NMeMbRIfDAEdGdyavjs6Zip4I3B/weYg0rQ0d6VScOumOJSL9/0iz7tT1+k0TLBbXKFI0l4LT8N+dRCDqC5v2uiDpoz3lPWqrTWTpzPaDTkCS1/zD/qN9BqLcy5gKUur5t8X6f0= Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB2773.namprd11.prod.outlook.com (52.135.227.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Fri, 7 Feb 2020 21:55:35 +0000 Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2686.036; Fri, 7 Feb 2020 21:55:35 +0000 From: "Eric Voit (evoit)" To: wangzitao , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXdkf8/mCPF7MdBRxG9gZDvXDuo9QAbmQzw Date: Fri, 7 Feb 2020 21:55:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [108.31.49.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a418136d-fc07-4509-6db1-08d7ac187600 x-ms-traffictypediagnostic: BYAPR11MB2773: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(366004)(346002)(39860400002)(199004)(189003)(4326008)(186003)(316002)(9686003)(55016002)(6506007)(71200400001)(33656002)(53546011)(110136005)(2906002)(66446008)(5660300002)(8676002)(81166006)(81156014)(66946007)(52536014)(66616009)(8936002)(86362001)(26005)(7696005)(15650500001)(64756008)(66556008)(478600001)(9326002)(76116006)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2773; H:BYAPR11MB2536.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: BCL:0; x-microsoft-antispam-message-info: IYKRL+sGuYPj+o40xvFudgNy5Nw1GMt/kAlJCTBber35Qh2SwekR4tKMiDiY9qZq2ckCMRi46korecWAndrUkYlGBVjtBAcazFkCRpT6cQYAI2K3isUMBA885T6KgpvxzusTZx+J/cf2LafMMG/g5vr+0CA4rYD3Rd37L4tYHwcbePMGFYiwPaUPguiU8Ft8vVQVoP2PaEAM5HGhVL1K2UORPMPx3D6oBpIZBYc+8KkXI3Mhj4cjvrH3kCaMlrAErVsmEdjontV2Ux3WT0nkg80suMpoHXkxM8hrdav99mt5lzYZ6k5KIzlegdvyfp0tngA86sX9Kp0tNaQo9ANobdytXbAildqhpKQY+YhTKc8RyYbdLa3RnB6HLXXzXfGXZb8c0n5yC6yzjq+tUnl3VG1gJ25sQEBRbQrBcnZfTnv0aF6kFcf5cpnvciHsAIY2WMBah28aXHIvGHf/T/DRfW8AU5gjMkNFx9UpTr+Nixn4VWKvwKLBi4MBma9oGWOeOunc0K5JeJ0O2tQIBaN2PQ== x-ms-exchange-antispam-messagedata: oH+n/95iEq3ntK5Z/NuFZ73+nTDsze/92sWr3B0bnYO2g7AR7pJRqpxi/FmUWBS9vei/Vc80/8P1yLNcmNyJf2/V66G37twpTq7yUeZICtL+UW5c+Wd3MMWMX/JI8G3NXlap2vEwH30d/Hr+LBMZtA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05AA_01D5DDD7.41B9A410" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a418136d-fc07-4509-6db1-08d7ac187600 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 21:55:35.3007 (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-CrossTenant-userprincipalname: L60VDTXz2bP7XyEl3ce2sJZNLRa2CPQUdoCVYGAV02zmLWtRXXTnd8gt4Z905iZi X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2773 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 07 Feb 2020 21:55:44 -0000 ------=_NextPart_000_05AA_01D5DDD7.41B9A410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05AB_01D5DDD7.41B9A410" ------=_NextPart_001_05AB_01D5DDD7.41B9A410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, =20 From: wangzitao, February 7, 2020 3:39 AM =20 Hi Eric and chairs, =20 I have read this version and have one question.=20 On what basis does the publisher package notifications for different = subscriptions together?=20 Is the client sending instructions to package different notifications = together?=20 Or is the publisher randomly packing different notifications together?=20 right now there are no guidelines on how to package different = YANG notifications together. Specifying this could be done in ways = independent of this draft: * A specification/draft could identify the maximum latency before a = specific YANG Notifications generated must egress a publisher. * A specification/draft could indicate what specific notifications must = be bundled together. =20 Thanks, Eric =20 Best Regards! -Michael =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 = 8:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Eric, =20 This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread. =20 You have indicated a desire that receiver capabilities should be = documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready. =20 To the WG, the authors have indicated a desire to wrap up this draft, = and would like us, the chairs, to issue a WGLC on it. Before we do that, = we wanted to ask if the WG believes that the document is ready, and that = there are no more issues that need to discussed/addressed by = draft-ietf-netconf-notification-messages document at this time. =20 Cheers. =20 Mahesh and Kent (as co-chairs). On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > wrote: =20 Hi Mahesh, =20 During the IETF 106 session, there was discussion on how both a = publisher might know if there is receiver support for = draft-ietf-netconf-notification-messages. Section = 6 highlights several of the considerations. Relevant are the = following: =20 (a) Remote device capability discovery from the point of view of the = Publisher needs to be enhanced to know if the far end can interpret = notification messages type beyond RFC-5277, Section 4. =20 (b) This capability discovery question is relevant for both configured = subscription receivers and dynamic subscribers. =20 =20 (c) The capability discovery question can be generalized beyond = subscriptions, as there are many reasons to know the available = capabilities of the far end. =20 =20 (d) Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1). =20 =20 =20 Based on (a)-(d), coming up with a transport independent point-solution = within = draft-ietf-netconf-notification-messages *just* to = discover this single element of client functionality seems = overkill/heavyweight. =20 I was fine with letting this remote capabilities discovery question sit = for a while. However = = draft-ietf-netconf-https-notif shows that we now must address this = question. Specifically should the diagram section 1.4.1 show this = capability exchange? =20 =20 It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as = described in a ? Only if these questions are "yes", should the be = responded to with an "OK". =20 Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within = "draft-ietf-netconf-notification-messages"? =20 A strawman way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = notification with an HTTP Status 202 (Accepted)" = acknowledgement. This 202 would include body elements listing supported = receiver resources. Maybe something YANG encoded via = ietf-yang-structure-ext containing: =20 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 =20 What do you think of this approach? =20 Eric =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 =20 ------=_NextPart_001_05AB_01D5DDD7.41B9A410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

From:<= /b> = wangzitao, February 7, 2020 3:39 AM

 

Hi Eric and chairs,

 

I have read this version and have one question. =

On what basis does the publisher package notifications for different = subscriptions together?

Is the client sending instructions to package different notifications = together?

Or is the publisher randomly packing different notifications together? =

<eric> = right now there are no guidelines on how to package different YANG = notifications together.=C2=A0=C2=A0 Specifying this could be done in = ways independent of this draft:

  • A = specification/draft could identify the maximum latency before a specific = YANG Notifications generated must egress a = publisher.
  • A = specification/draft could indicate what specific notifications must be = bundled together.

 

Thanks,
Er= ic

 

Best Regards!

-Michael

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: = netconf [mailto:netconf-bounces@ietf.org<= /a>] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 8:19
=E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) = <evoit@cisco.com>
=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi = Eric,

 

This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread.

 

You have indicated a desire that receiver capabilities = should be documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready.

 

To the WG, the authors have indicated a desire to wrap = up this draft, and would like us, the chairs, to issue a WGLC on it. = Before we do that, we wanted to ask if the WG believes that the document = is ready, and that there are no more issues that need to = discussed/addressed by draft-ietf-netconf-notification-messages document = at this time.

 

Cheers.

 

Mahesh and Kent (as co-chairs).




On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

 =

I was fine = with letting this remote capabilities discovery question sit for a = while.   However draft-ietf-netconf-https-notif shows that we now must = address this question.  Specifically should the diagram section = 1.4.1 show this capability exchange?  

 =

It turns out = that independent of draft-ietf-netconf-notification-messages, there = several questions in draft-ietf-netconf-https-notif which need to be = answered prior to the section 1.4.1 arrow: "Send HTTPS POST message = with YANG defined notification #1" anyway.  These questions = are:

  (1) = Does the targeted HTTPS receiver support configured = subscriptions?

  (2) = Can the targeted HTTP@ receiver accept a new subscription as described = in a <subscription-started>?

Only if = these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 =

Add to this = a third question driven from (a)-(d):

  (3) = Does the receiver support the message type within = "draft-ietf-netconf-notification-messages"?

 =

A strawman = way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext = containing:

 =

  &= nbsp;   <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

  &= nbsp;     = <capabilities>

  &= nbsp;       = <capability>

  &= nbsp;         = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

  &= nbsp;       = </capability>

  &= nbsp; =     </capabilities>

=

  &= nbsp;   </foo>

 =

What do you = think of this approach?

 =

Eric

 

Mahesh Jethanandani

 

 

 

------=_NextPart_001_05AB_01D5DDD7.41B9A410-- ------=_NextPart_000_05AA_01D5DDD7.41B9A410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMjA3MjE1NDI2WjAjBgkqhkiG 9w0BCQQxFgQUXwxtNHX+h6BSCgIW6qGU7C4OYkYwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBeJMTIsIlRgfPWXWreA9qIDeVWdDwYl+N/mF0HY+zy5dEQeBVxwO1FxMdL1dmTDpsi WV5PaQI6WeUx2B1Gl7pAFdnAQ/Cjq4ugWq7lL/1xvQuR4clbU+vCbxz3BqTe3gt4xMWiJFsmfcpo Mjnd3SWTq0b9HG31XMFN4CfRN2Y/FOpr5u5FfODOHm6HoTk5zC8ar3bV3Lf/HsvL22Sy9coWzfb0 2FI7805hDR1t+leW9r+Ww/tHWUL+Aj7xaz32NBl/0WOVNZjfuB2j7c4pADUIhAeOwVO6vFHR831O 8Jwtn7c905/YS0WmU+w2Rg1AjbzvKeo3Bq6L2YF3Ak9T+EO1AAAAAAAA ------=_NextPart_000_05AA_01D5DDD7.41B9A410-- From nobody Mon Feb 10 09:28:06 2020 Return-Path: <010001703024aae0-0d6fac1e-970c-45e0-8497-fcbce5008cff-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 C8F68120837 for ; Mon, 10 Feb 2020 09:27:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 U_QhVBq78Whv for ; Mon, 10 Feb 2020 09:27:55 -0800 (PST) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E5712086B for ; Mon, 10 Feb 2020 09:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581355674; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=BbFtxtKAfeqPdieTp3ZC4qD8TAO1Ezx4fzwCYKfF7cw=; b=FPB3c0HyXt4KFnwasCtZAMZ+m094DkPPeszp2VzEujUPSQE+2bdysMjZFqEIvDWn fewiSMP5/2LRUZUMxrrH5UkSR2doqGgofnJnLuWfo77fkd8Lm7SBqG9Q+tZy3zz6nSo GqFPgigRgf57CKjEHgWkG2uCoiFlLlVCycrd4a6U= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_1D122B10-95B5-4553-8E9A-7B9BF2F46B3D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <010001703024aae0-0d6fac1e-970c-45e0-8497-fcbce5008cff-000000@email.amazonses.com> Date: Mon, 10 Feb 2020 17:27:54 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.10-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Move generate key actions? (pulling on a string unravels all) 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, 10 Feb 2020 17:28:04 -0000 --Apple-Mail=_1D122B10-95B5-4553-8E9A-7B9BF2F46B3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, This is worse than it seems, so please dig in! 1) currently the "generate-symmetric-key" and = =E2=80=9Cgenerate-asymmetric-key=E2=80=9D actions are defined in = ietf-keystore, primarily so another keystore-key can be leafref-ed so = that the output (i.e., the generated key) can be encrypted. 2) however, it seems wrong that only servers implementing ietf-keystore = should be able to generate keys. Thus I was thinking to move the = generate-* actions to ietf-crypto-types as RPCs (not actions). =20 i) Them not being actions is not an issue as the only reason they were = actions originally is because we were thinking that they would be like = object-oriented methods, adding the generated key to the parent node=E2=80= =99s list of keys. But now that the generated keys are returned in the = output, it no longer matters if it is an action or RPC. ii) In order to retain the ability to encrypt the generated key, the = ietf-keystore module can augment the ietf-crypto-types RPCs with the = "encrypt-with=E2=80=9D inout parameter. 3) I started to make this change in my local copy to see how it would = play out, and immediately ran into the seemingly unrelated issue that = the =E2=80=9Calgorithm=E2=80=9D input parameter is of type = "iasa:asymmetric-algorithm-type=E2=80=9D or = "isa:symmetric-algorithm-type=E2=80=9D, depending on the kind of key = that is being generated. Mind you, the =E2=80=9Ciasa=E2=80=9D and = =E2=80=9Cisa=E2=80=9D prefixed lists of supported keys are exactly that = which we said we=E2=80=99d split/move to the ssh-client-server and = tls-client-server drafts (PS: still waiting for someone to send a Pull = Request for this change). That is, the 3 lists of supported algorithms = becomes 6 lists (i.e., 3 for SSH and 3 for TLS). 4) But we can=E2=80=99t really move these algorithms to the SSH and TLS = modules because the "public-key-grouping=E2=80=9D and = "symmetric-key-grouping=E2=80=9D groupings have an =E2=80=9Calgorithm=E2=80= =9D leaf that leafref's these lists=E2=80=A6so the move would cause an = unresolved referenced and fail YANG validation. FWIW, this issue = exists regardless if we move the actions from keystore to = crypto-types=E2=80=A6it is only in my trying to do it that this issue = was revealed... 5) this issue suggests using =E2=80=9Cidentities=E2=80=9D rather than = =E2=80=9Cenumerations=E2=80=9D for the lists of supported algorithms. = That is, base identities in ietf-crypt-types enable identityrefs=E2=80=A6.= But if we use identities (instead of opstate-lists of supported = algorithm enumerations), we could instead either have a =E2=80=9Cmodule=E2= =80=9D or =E2=80=9Cfeature=E2=80=9D per identity, which would still = produce an opstate list (i.e., ietf-yang-library), but there would be = many of either modules or features, which may be off-putting=E2=80=A6 Options: module per identity (many modules, use YL to determine which algs server = supports) module per alg-type (e.g., SSH/TLS * symmetric/assymetric/hash) with a = feature per identity (many features!) module per alg-type + a separate runtime opstate list of supported = algorithms (unnecessary lists?) Suggestions? Kent // contributor --Apple-Mail=_1D122B10-95B5-4553-8E9A-7B9BF2F46B3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

This = is worse than it seems, so please dig in!

1) currently the = "generate-symmetric-key" and =E2=80=9Cgenerate-asymmetric-key=E2=80=9D = actions are defined in ietf-keystore, primarily so another keystore-key = can be leafref-ed so that the output (i.e., the generated key) can be = encrypted.

2) = however, it seems wrong that only servers implementing ietf-keystore = should be able to generate keys.  Thus I was thinking to move the = generate-* actions to ietf-crypto-types as RPCs (not actions). =   

i) Them not being actions is not an issue as the only reason = they were actions originally is because we were thinking that they would = be like object-oriented methods, adding the generated key to the parent = node=E2=80=99s list of keys.  But now that the generated keys are = returned in the output, it no longer matters if it is an action or = RPC.

ii) In = order to retain the ability to encrypt the generated key, the = ietf-keystore module can augment the ietf-crypto-types RPCs with the = "encrypt-with=E2=80=9D inout parameter.

3) I started to make = this change in my local copy to see how it would play out, and = immediately ran into the seemingly unrelated issue that the = =E2=80=9Calgorithm=E2=80=9D input parameter is of type = "iasa:asymmetric-algorithm-type=E2=80=9D or =  "isa:symmetric-algorithm-type=E2=80=9D, depending on the kind of = key that is being generated.  Mind you, the =E2=80=9Ciasa=E2=80=9D = and =E2=80=9Cisa=E2=80=9D prefixed lists of supported keys are exactly = that which we said we=E2=80=99d split/move to the ssh-client-server and = tls-client-server drafts (PS: still waiting for someone to send a Pull = Request for this change).  That is, the 3 lists of supported = algorithms becomes 6 lists (i.e., 3 for SSH and 3 for TLS).

4) But we can=E2=80=99t = really move these algorithms to the SSH and TLS modules because the = "public-key-grouping=E2=80=9D and "symmetric-key-grouping=E2=80=9D = groupings have an =E2=80=9Calgorithm=E2=80=9D leaf that leafref's these = lists=E2=80=A6so the move would cause an unresolved referenced and fail = YANG validation.   FWIW, this issue exists regardless if we move = the actions from keystore to crypto-types=E2=80=A6it is only in my = trying to do it that this issue was revealed...

5) this issue suggests using = =E2=80=9Cidentities=E2=80=9D rather than =E2=80=9Cenumerations=E2=80=9D = for the lists of supported algorithms.  That is, base identities in = ietf-crypt-types enable identityrefs=E2=80=A6. But if we use identities = (instead of opstate-lists of supported algorithm enumerations), we could = instead either have a =E2=80=9Cmodule=E2=80=9D or =E2=80=9Cfeature=E2=80=9D= per identity, which would still produce an opstate list (i.e., = ietf-yang-library), but there would be many of either modules or = features, which may be off-putting=E2=80=A6

Options:
  1. module per identity (many modules, use YL to = determine which algs server supports)
  2. module per = alg-type (e.g., SSH/TLS * symmetric/assymetric/hash) with a feature per = identity (many features!)
  3. module per alg-type + = a separate runtime opstate list of supported algorithms (unnecessary = lists?)
Suggestions?

Kent // = contributor

= --Apple-Mail=_1D122B10-95B5-4553-8E9A-7B9BF2F46B3D-- From nobody Mon Feb 10 12:17:01 2020 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 9B79E120827 for ; Mon, 10 Feb 2020 12:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 KOaUjZhEPzkg for ; Mon, 10 Feb 2020 12:16:57 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 9FB43120018 for ; Mon, 10 Feb 2020 12:16:57 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id c26so1878643eds.8 for ; Mon, 10 Feb 2020 12:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=W1ycfpVUhR1D+CTSAfBQKYIfpJgWTwTWpJ7au4SfktE=; b=d0R/8JjtuK6VTNYwFq6Ep/U9dCGWs7zwJQLTKVy/KajgLnCF3zYgMR80u//Qkt+MBZ Wy+H+O/USSpxK2G3G0EWNOO938V1rmKY4W5WY7OTCOBpQ1ARxUr9KNXmw624qZH9Cw6E EHBorTPwdDMfaVdJ+aqZ99jmwmhfkKg9VAq5R7ovOQV8ulJ6K2W9N+HFVRZS7cRswHcm Uoqk2XVXhWmrYhHM80iZgDuYP2ERAbXj7kmI9E1RFEmpmIkRKZrNczI/ZE81k0v2qUfe j7BRdmheZ85TivRwtvclPf1KS87ueAfv47vkkTizKGg4hn/z10J6yt/w22uHtgnAiPh5 SGhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=W1ycfpVUhR1D+CTSAfBQKYIfpJgWTwTWpJ7au4SfktE=; b=eww6qko8mRCeNEhhi5tOJvpC6rc6CEaIqmxoNPKU33QyIRJ1OO1hyAkIrjaFk0w0DZ HazxJfUl1Y3/MKH2m/zOnXG4g7rbdJpdPduSVgPkGjitmoWY+EwJWW0j+jXKxQ+Tt13U bdpw0b5jBqtgzx6bAXbclrCuIRo5xfUS6p3NH0XGsfFF4dVxI2AS2JLrXMpUkMAYHS0x evSQhBf5N5mf/Ovp2FNj+RYCgAAYNaTUcqYoaCionDJb12MqgSyDcb9yLJDPsJAmnOM0 xQYtLCTviQcvMqx4hNnLXXRZWN+7iUIK8jJqnu50R1liqqdiLAgzlXTgZ9ULsmPZpOd1 bv/A== X-Gm-Message-State: APjAAAXul5URZ4k2UG69P24yqR+z9jHbm/qlD/oje14gSFDEdKFFEL+0 Vz8Ssa67qMat+XBzCEu1B/Xk+r/E7qIasQeHpvj2KmlL X-Google-Smtp-Source: APXvYqygkr6e4Adcet9eh3UxwGCQvQGWzyX0eXlOCVCRtfXK73Ji2v9qSkU973muhttvcxLhgTF+Fo65uzcqsqddSjQ= X-Received: by 2002:a05:6402:1c87:: with SMTP id cy7mr2851772edb.348.1581365815835; Mon, 10 Feb 2020 12:16:55 -0800 (PST) MIME-Version: 1.0 From: aruna potti Date: Mon, 10 Feb 2020 12:19:38 -0800 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary="000000000000b67ddf059e3e6b2b" Archived-At: Subject: [netconf] Bulk 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, 10 Feb 2020 20:16:59 -0000 --000000000000b67ddf059e3e6b2b Content-Type: text/plain; charset="UTF-8" Hi, Is there any conclusion on the proposals mentioned below? https://tools.ietf.org/id/draft-liu-netconf-multiple-replies-01.html I am especially interested in how clients can deal with bulk as they can not wait forever for a response and usually require to have time out for a response from the device. I see an issue to increase the time out as it can interfere with the network communication issue detection while waiting for the response. What is your suggestion on how a client should handle the bulk ? Thanks, Aruna. --000000000000b67ddf059e3e6b2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Is there any conclusion = on the proposals mentioned below?

I am especially interested in how clients can deal with bulk <rpc-repl= y> as they can not wait forever for a response and usually require to ha= ve time out for a response from the device. I see an issue to increase the = time out as it can interfere with the network communication issue detection= while waiting for the response.
What is your suggestion on = how a client should handle the bulk <rpc-reply>?

=
Thanks,
Aruna.

--000000000000b67ddf059e3e6b2b-- From nobody Mon Feb 10 12:36:13 2020 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 26E70120847 for ; Mon, 10 Feb 2020 12:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 uPjJq1LyPS08 for ; Mon, 10 Feb 2020 12:36:10 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B2438120018 for ; Mon, 10 Feb 2020 12:36:10 -0800 (PST) Received: from [192.168.1.206] (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 337A560B8A; Mon, 10 Feb 2020 20:36:10 +0000 (UTC) From: Christian Hopps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: <6131477C-9EE3-499E-966A-A9ADB6FF8CD9@chopps.org> Date: Mon, 10 Feb 2020 15:36:09 -0500 To: netconf@ietf.org X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [netconf] subtree filter any namespace 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, 10 Feb 2020 20:36:12 -0000 I've been adding subtree to xpath conversion to my netconf python = client/server code (with some help from others), and in trying to get = the "any" namespace stuff working I ran into an issue. The client code was setting the default namespace to = 'xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"' on the top XML rpc = message element. This had an unwanted side-effect of placing everything = in a sub-tree filter then into the netconf namespace (if none were = given). As a work-around I created the filter element with a blank = default namespace; however, I'm not sure this is correct, i.e., ... users specified filter ... The correct thing is probably to not set the default namespace in the = client code; however, I'm not sure I can do this now for backward = compatible reasons. I could do it perhaps if the user specified a = filter, but I'm curious if it's valid to just set it to blank. Googling = produced conflicting answers for me. Thanks, Chris.= From nobody Mon Feb 10 13:46:54 2020 Return-Path: <010001703111b0fc-84113b40-5c94-4ddc-97f8-c9ffc11e72ad-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 2B4AB12086C for ; Mon, 10 Feb 2020 13:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 TkLiTvNHr5wo for ; Mon, 10 Feb 2020 13:46:49 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669A912086B for ; Mon, 10 Feb 2020 13:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581371208; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=wdE5cLqebiQWbsKPUnMG3mtmIfP4f2oow9OKrcsecNQ=; b=c/GHpBdG35kPlON3CXRVX7ZIJPoFye9ZNARjMWE5M6Nn2Km1BCuoFcbbEkmxjRCk q3gTr3Wr8lEgWuXQGb4CORULmi65gB8692+iduiP51GH3mGsvmjjZcKG8nXklZoGOmV zpBEWvkkthNAxlL7hso/FB32wrQqQi8I9IfZdjnE= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_940BD73E-410C-4B61-9211-F45E66459248" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 10 Feb 2020 21:46:48 +0000 References: <010001703024aae0-0d6fac1e-970c-45e0-8497-fcbce5008cff-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <010001703024aae0-0d6fac1e-970c-45e0-8497-fcbce5008cff-000000@email.amazonses.com> Message-ID: <010001703111b0fc-84113b40-5c94-4ddc-97f8-c9ffc11e72ad-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.10-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Move generate key actions? (pulling on a string unravels all) 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, 10 Feb 2020 21:46:52 -0000 --Apple-Mail=_940BD73E-410C-4B61-9211-F45E66459248 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I completed moving the key-generating actions from keystone (KS) to = crypto-types (CT). The diffs can be seen here: For CT: = https://github.com/netconf-wg/crypto-types/commit/5116a8bd59c7253f404fb2ec= 00f21bcec9e27771 = For KS: = https://github.com/netconf-wg/keystore/commit/20ce25acba43ce5c28e53aca7f76= a3083aa125ad = More importantly, the issue raised below disappeared, as I realized that = we were only planning to move the =E2=80=9Cconfig false=E2=80=9D = supported algorithm lists (not the alg enums) to the SSH and TLS drafts, = thus there was/is no need to introduce any base identities. Kent // contributor > On Feb 10, 2020, at 12:27 PM, Kent Watsen = wrote: >=20 > All, >=20 > This is worse than it seems, so please dig in! >=20 > 1) currently the "generate-symmetric-key" and = =E2=80=9Cgenerate-asymmetric-key=E2=80=9D actions are defined in = ietf-keystore, primarily so another keystore-key can be leafref-ed so = that the output (i.e., the generated key) can be encrypted. >=20 > 2) however, it seems wrong that only servers implementing = ietf-keystore should be able to generate keys. Thus I was thinking to = move the generate-* actions to ietf-crypto-types as RPCs (not actions). = =20 >=20 > i) Them not being actions is not an issue as the only reason they were = actions originally is because we were thinking that they would be like = object-oriented methods, adding the generated key to the parent node=E2=80= =99s list of keys. But now that the generated keys are returned in the = output, it no longer matters if it is an action or RPC. >=20 > ii) In order to retain the ability to encrypt the generated key, the = ietf-keystore module can augment the ietf-crypto-types RPCs with the = "encrypt-with=E2=80=9D inout parameter. >=20 > 3) I started to make this change in my local copy to see how it would = play out, and immediately ran into the seemingly unrelated issue that = the =E2=80=9Calgorithm=E2=80=9D input parameter is of type = "iasa:asymmetric-algorithm-type=E2=80=9D or = "isa:symmetric-algorithm-type=E2=80=9D, depending on the kind of key = that is being generated. Mind you, the =E2=80=9Ciasa=E2=80=9D and = =E2=80=9Cisa=E2=80=9D prefixed lists of supported keys are exactly that = which we said we=E2=80=99d split/move to the ssh-client-server and = tls-client-server drafts (PS: still waiting for someone to send a Pull = Request for this change). That is, the 3 lists of supported algorithms = becomes 6 lists (i.e., 3 for SSH and 3 for TLS). >=20 > 4) But we can=E2=80=99t really move these algorithms to the SSH and = TLS modules because the "public-key-grouping=E2=80=9D and = "symmetric-key-grouping=E2=80=9D groupings have an =E2=80=9Calgorithm=E2=80= =9D leaf that leafref's these lists=E2=80=A6so the move would cause an = unresolved referenced and fail YANG validation. FWIW, this issue = exists regardless if we move the actions from keystore to = crypto-types=E2=80=A6it is only in my trying to do it that this issue = was revealed... >=20 > 5) this issue suggests using =E2=80=9Cidentities=E2=80=9D rather than = =E2=80=9Cenumerations=E2=80=9D for the lists of supported algorithms. = That is, base identities in ietf-crypt-types enable identityrefs=E2=80=A6.= But if we use identities (instead of opstate-lists of supported = algorithm enumerations), we could instead either have a =E2=80=9Cmodule=E2= =80=9D or =E2=80=9Cfeature=E2=80=9D per identity, which would still = produce an opstate list (i.e., ietf-yang-library), but there would be = many of either modules or features, which may be off-putting=E2=80=A6 >=20 > Options: > module per identity (many modules, use YL to determine which algs = server supports) > module per alg-type (e.g., SSH/TLS * symmetric/assymetric/hash) with a = feature per identity (many features!) > module per alg-type + a separate runtime opstate list of supported = algorithms (unnecessary lists?) > Suggestions? >=20 > Kent // contributor >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_940BD73E-410C-4B61-9211-F45E66459248 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I completed moving the key-generating actions from keystone = (KS) to crypto-types (CT).  The diffs can be seen here:

For CT: https://github.com/netconf-wg/crypto-types/commit/5116a8bd59c72= 53f404fb2ec00f21bcec9e27771
For KS: https://github.com/netconf-wg/keystore/commit/20ce25acba43ce5c2= 8e53aca7f76a3083aa125ad

More importantly, the issue raised below disappeared, as I = realized that we were only planning to move the =E2=80=9Cconfig false=E2=80= =9D supported algorithm lists (not the alg enums) to the SSH and TLS = drafts, thus there was/is no need to introduce any base = identities.

Kent= // contributor



On Feb 10, 2020, at 12:27 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

All,

This is worse than it seems, so please = dig in!

1) = currently the "generate-symmetric-key" and =E2=80=9Cgenerate-asymmetric-ke= y=E2=80=9D actions are defined in ietf-keystore, primarily so another = keystore-key can be leafref-ed so that the output (i.e., the generated = key) can be encrypted.

2) however, it seems wrong that only servers implementing = ietf-keystore should be able to generate keys.  Thus I was thinking = to move the generate-* actions to ietf-crypto-types as RPCs (not = actions).   

i) Them not being actions is = not an issue as the only reason they were actions originally is because = we were thinking that they would be like object-oriented methods, adding = the generated key to the parent node=E2=80=99s list of keys.  But = now that the generated keys are returned in the output, it no longer = matters if it is an action or RPC.

ii) In order to retain the ability to = encrypt the generated key, the ietf-keystore module can augment the = ietf-crypto-types RPCs with the "encrypt-with=E2=80=9D inout = parameter.

3) I started to make this change in my local copy to see how = it would play out, and immediately ran into the seemingly unrelated = issue that the =E2=80=9Calgorithm=E2=80=9D input parameter is of type = "iasa:asymmetric-algorithm-type=E2=80=9D or =  "isa:symmetric-algorithm-type=E2=80=9D, depending on the kind of = key that is being generated.  Mind you, the =E2=80=9Ciasa=E2=80=9D = and =E2=80=9Cisa=E2=80=9D prefixed lists of supported keys are exactly = that which we said we=E2=80=99d split/move to the ssh-client-server and = tls-client-server drafts (PS: still waiting for someone to send a Pull = Request for this change).  That is, the 3 lists of supported = algorithms becomes 6 lists (i.e., 3 for SSH and 3 for TLS).

4) But we can=E2=80=99t = really move these algorithms to the SSH and TLS modules because the = "public-key-grouping=E2=80=9D and "symmetric-key-grouping=E2=80=9D = groupings have an =E2=80=9Calgorithm=E2=80=9D leaf that leafref's these = lists=E2=80=A6so the move would cause an unresolved referenced and fail = YANG validation.   FWIW, this issue exists regardless if we move = the actions from keystore to crypto-types=E2=80=A6it is only in my = trying to do it that this issue was revealed...

5) this issue suggests using = =E2=80=9Cidentities=E2=80=9D rather than =E2=80=9Cenumerations=E2=80=9D = for the lists of supported algorithms.  That is, base identities in = ietf-crypt-types enable identityrefs=E2=80=A6. But if we use identities = (instead of opstate-lists of supported algorithm enumerations), we could = instead either have a =E2=80=9Cmodule=E2=80=9D or =E2=80=9Cfeature=E2=80=9D= per identity, which would still produce an opstate list (i.e., = ietf-yang-library), but there would be many of either modules or = features, which may be off-putting=E2=80=A6

Options:
  1. module per identity (many modules, use YL to = determine which algs server supports)
  2. module per = alg-type (e.g., SSH/TLS * symmetric/assymetric/hash) with a feature per = identity (many features!)
  3. module per alg-type + = a separate runtime opstate list of supported algorithms (unnecessary = lists?)
Suggestions?

Kent // = contributor

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

= --Apple-Mail=_940BD73E-410C-4B61-9211-F45E66459248-- From nobody Tue Feb 11 00:00:03 2020 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 C718012008F for ; Tue, 11 Feb 2020 00:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1l93prVd8NZ for ; Mon, 10 Feb 2020 23:59:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E5D88120044 for ; Mon, 10 Feb 2020 23:59:58 -0800 (PST) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id B5C021AE018B; Tue, 11 Feb 2020 08:59:55 +0100 (CET) Date: Tue, 11 Feb 2020 08:59:17 +0100 (CET) Message-Id: <20200211.085917.2142620937359879949.mbj@tail-f.com> To: chopps@chopps.org Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <6131477C-9EE3-499E-966A-A9ADB6FF8CD9@chopps.org> References: <6131477C-9EE3-499E-966A-A9ADB6FF8CD9@chopps.org> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] subtree filter any namespace 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, 11 Feb 2020 08:00:01 -0000 Hi, Christian Hopps wrote: > I've been adding subtree to xpath conversion to my netconf python > client/server code (with some help from others), and in trying to get > the "any" namespace stuff working I ran into an issue. > > The client code was setting the default namespace to > 'xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"' on the top XML rpc > message element. This had an unwanted side-effect of placing > everything in a sub-tree filter then into the netconf namespace (if > none were given). As a work-around I created the filter element with a > blank default namespace; however, I'm not sure this is correct, i.e., > > > > ... users specified filter ... > > This is not correct since it says that "filter" is in the "" namespace. > The correct thing is probably to not set the default namespace in the > client code; however, I'm not sure I can do this now for backward > compatible reasons. I could do it perhaps if the user specified a > filter, but I'm curious if it's valid to just set it to > blank. Googling produced conflicting answers for me. I don't know how your code works but you need to end up with somthing like: ... ... OR ... ... /martin > > Thanks, > Chris. > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Feb 11 03:47:23 2020 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 2EA271200EC for ; Tue, 11 Feb 2020 03:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ZqGmkMm_3_Ay for ; Tue, 11 Feb 2020 03:47:20 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7A31200DF for ; Tue, 11 Feb 2020 03:47:20 -0800 (PST) Received: from [192.168.1.206] (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id B393160CE3; Tue, 11 Feb 2020 11:47:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Christian Hopps In-Reply-To: <20200211.085917.2142620937359879949.mbj@tail-f.com> Date: Tue, 11 Feb 2020 06:47:18 -0500 Cc: Christian Hopps , netconf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6131477C-9EE3-499E-966A-A9ADB6FF8CD9@chopps.org> <20200211.085917.2142620937359879949.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [netconf] subtree filter any namespace 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, 11 Feb 2020 11:47:22 -0000 > On Feb 11, 2020, at 2:59 AM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Christian Hopps wrote: >> I've been adding subtree to xpath conversion to my netconf python >> client/server code (with some help from others), and in trying to get >> the "any" namespace stuff working I ran into an issue. >>=20 >> The client code was setting the default namespace to >> 'xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"' on the top XML = rpc >> message element. This had an unwanted side-effect of placing >> everything in a sub-tree filter then into the netconf namespace (if >> none were given). As a work-around I created the filter element with = a >> blank default namespace; however, I'm not sure this is correct, i.e., >>=20 >> >> >> ... users specified filter ... >> >> >=20 > This is not correct since it says that "filter" is in the "" > namespace. >=20 >> The correct thing is probably to not set the default namespace in the >> client code; however, I'm not sure I can do this now for backward >> compatible reasons. I could do it perhaps if the user specified a >> filter, but I'm curious if it's valid to just set it to >> blank. Googling produced conflicting answers for me. >=20 > I don't know how your code works but you need to end up with somthing > like: >=20 > > > > > ... > > > ... > > > > Ok so my main question was is it valid to have ``xmlns=3D""'', which = your saying works. I missed the fact that I was not putting "filter" in = the netconf namespace, but I could do that with this: ... ... and leave the current API (where users may have assumed netconf = namespace was the default) unchanged. I'm not sure how many users may have relied on the netconf namespace = being the default, and it seems odd the more I think about it; part of = me wants to ditch it. :) Thanks, Chris. >=20 > OR >=20 > > > > > ... > > > ... > > > > >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Thanks, >> Chris. >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Feb 11 05:25:45 2020 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 B9C881200E7 for ; Tue, 11 Feb 2020 05:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RKvKb1Cx9xM for ; Tue, 11 Feb 2020 05:25:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05A83120043 for ; Tue, 11 Feb 2020 05:25:42 -0800 (PST) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id EA36D1AE018B; Tue, 11 Feb 2020 14:25:35 +0100 (CET) Date: Tue, 11 Feb 2020 14:24:56 +0100 (CET) Message-Id: <20200211.142456.1627117725994673253.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-000000@email.amazonses.com> References: <20191119.161851.678459934233941550.mbj@tail-f.com> <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] [netconf-wg/https-notif] Should the receivers container be moved under the augment statement and the leafref renamed? (#2) 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, 11 Feb 2020 13:25:45 -0000 Kent Watsen wrote: > Hi Martin, > > > > On Nov 19, 2019, at 10:18 AM, Martin Bjorklund wrote: > > > >> The reason to not move the receiver container under the augment is so > >> as to allow the leafref to point to multiple receivers. > > > > I don't understand this reason. > > Each "receiver" (in https-notif) maps to an HTTPS connection from the > publisher to the receiver. > > There is likely to be more than one configured subscription, yet all > notifications should go to the same receiver. > > We'd like to use the same HTTPS "connection" for all, as opposed to > having an HTTPS connection for each. > > The "receiver-ref" leaf provides an indirection enabling this > many-to-one relationship. I can't find the original thread about this issue, so I'll rephrase what I (think I) wrote from the start: I understand the reason for the many-to-one, and I wish we had that in the base model itself (i.e., RFC 8639), so that protocol-documents didn't have to invent this, and so that we could have receiver-specific config in one place. > > Since this is not a stand-alone model, I think it should augment > > /sn:subscriptions. In some way it doesn't matter what nodes are > > called and where they are located, but having descriptive names and > > keep related nodes under common subtrees helps the understanding of > > models. > > Is s/receiver-ref/https-receiver-ref/ what you had in mind? Yes, as a minimum. I would also change the top-level container "receivers" to augment /sn:subscriptions: augemnt /sn:subscriptions { container https-receivers { ... } } /martin From nobody Tue Feb 11 07:26:03 2020 Return-Path: <0100017034db6704-09a8b95c-654c-4a99-9a08-31f94e265b9e-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 CF771120170 for ; Tue, 11 Feb 2020 07:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 D7pRtlJMObNG for ; Tue, 11 Feb 2020 07:26:00 -0800 (PST) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F64E120164 for ; Tue, 11 Feb 2020 07:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581434759; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=PnwOYWrpDLWsYVGK8UXZOt1KD9BD1xE8IduN8jAswJI=; b=Zvy5404eki1UPvDldGzblyPYp+q/xxHiKmbzp9qvYRQ4AHHULif4N0bP0o3GkGcw JGhGU9JhIG1lHzZYROC7i44IMJ57tZuANjMxSGrvZt0eQXimygzDOe5nwt7vo/8yRaD 18Z2jtHix64I8nlu+Jb6x873hahOU/eEtYYU1Le0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <20200211.142456.1627117725994673253.mbj@tail-f.com> Date: Tue, 11 Feb 2020 15:25:59 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017034db6704-09a8b95c-654c-4a99-9a08-31f94e265b9e-000000@email.amazonses.com> References: <20191119.161851.678459934233941550.mbj@tail-f.com> <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-000000@email.amazonses.com> <20200211.142456.1627117725994673253.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.11-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [netconf-wg/https-notif] Should the receivers container be moved under the augment statement and the leafref renamed? (#2) 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, 11 Feb 2020 15:26:02 -0000 Hi Martin, >>>> The reason to not move the receiver container under the augment is = so >>>> as to allow the leafref to point to multiple receivers. >>>=20 >>> I don't understand this reason. >>=20 >> Each "receiver" (in https-notif) maps to an HTTPS connection from the >> publisher to the receiver. >>=20 >> There is likely to be more than one configured subscription, yet all >> notifications should go to the same receiver. >>=20 >> We'd like to use the same HTTPS "connection" for all, as opposed to >> having an HTTPS connection for each. >>=20 >> The "receiver-ref" leaf provides an indirection enabling this >> many-to-one relationship. >=20 > I can't find the original thread about this issue, so I'll rephrase > what I (think I) wrote from the start: >=20 > I understand the reason for the many-to-one, and I wish we had that in > the base model itself (i.e., RFC 8639), so that protocol-documents > didn't have to invent this, and so that we could have > receiver-specific config in one place. I agree, it would=E2=80=99ve been better in RFC 8639. I recall Juergen = writing once that he expected it to be a common pattern. But that is = behind us now, or are you suggesting a -bis? Is there is an action = coming out of this fork in the thread? >>> Since this is not a stand-alone model, I think it should augment >>> /sn:subscriptions. In some way it doesn't matter what nodes are >>> called and where they are located, but having descriptive names and >>> keep related nodes under common subtrees helps the understanding of >>> models. >>=20 >> Is s/receiver-ref/https-receiver-ref/ what you had in mind? >=20 > Yes, as a minimum. >=20 > I would also change the top-level container "receivers" to augment > /sn:subscriptions: >=20 > augemnt /sn:subscriptions { > container https-receivers { > ... > } > } Ah, I see now, thank you for providing the snippet. Kent // contributor From nobody Tue Feb 11 07:32:41 2020 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 0AB0C1208B6 for ; Tue, 11 Feb 2020 07:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtFBEBl9VqNU for ; Tue, 11 Feb 2020 07:32:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62266120880 for ; Tue, 11 Feb 2020 07:32:38 -0800 (PST) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 460651AE018B; Tue, 11 Feb 2020 16:32:34 +0100 (CET) Date: Tue, 11 Feb 2020 16:31:55 +0100 (CET) Message-Id: <20200211.163155.825868185729184607.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100017034db6704-09a8b95c-654c-4a99-9a08-31f94e265b9e-000000@email.amazonses.com> References: <0100016fa69f59c6-212e569d-fb2b-47cb-a1ff-e897829ba111-000000@email.amazonses.com> <20200211.142456.1627117725994673253.mbj@tail-f.com> <0100017034db6704-09a8b95c-654c-4a99-9a08-31f94e265b9e-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] [netconf-wg/https-notif] Should the receivers container be moved under the augment statement and the leafref renamed? (#2) 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, 11 Feb 2020 15:32:40 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gSGkgTWFydGluLA0K PiANCj4gPj4+PiBUaGUgcmVhc29uIHRvIG5vdCBtb3ZlIHRoZSByZWNlaXZlciBjb250YWluZXIg dW5kZXIgdGhlIGF1Z21lbnQgaXMgc28NCj4gPj4+PiBhcyB0byBhbGxvdyB0aGUgbGVhZnJlZiB0 byBwb2ludCB0byBtdWx0aXBsZSByZWNlaXZlcnMuDQo+ID4+PiANCj4gPj4+IEkgZG9uJ3QgdW5k ZXJzdGFuZCB0aGlzIHJlYXNvbi4NCj4gPj4gDQo+ID4+IEVhY2ggInJlY2VpdmVyIiAoaW4gaHR0 cHMtbm90aWYpIG1hcHMgdG8gYW4gSFRUUFMgY29ubmVjdGlvbiBmcm9tIHRoZQ0KPiA+PiBwdWJs aXNoZXIgdG8gdGhlIHJlY2VpdmVyLg0KPiA+PiANCj4gPj4gVGhlcmUgaXMgbGlrZWx5IHRvIGJl IG1vcmUgdGhhbiBvbmUgY29uZmlndXJlZCBzdWJzY3JpcHRpb24sIHlldCBhbGwNCj4gPj4gbm90 aWZpY2F0aW9ucyBzaG91bGQgZ28gdG8gdGhlIHNhbWUgcmVjZWl2ZXIuDQo+ID4+IA0KPiA+PiBX ZSdkIGxpa2UgdG8gdXNlIHRoZSBzYW1lIEhUVFBTICJjb25uZWN0aW9uIiBmb3IgYWxsLCBhcyBv cHBvc2VkIHRvDQo+ID4+IGhhdmluZyBhbiBIVFRQUyBjb25uZWN0aW9uIGZvciBlYWNoLg0KPiA+ PiANCj4gPj4gVGhlICJyZWNlaXZlci1yZWYiIGxlYWYgcHJvdmlkZXMgYW4gaW5kaXJlY3Rpb24g ZW5hYmxpbmcgdGhpcw0KPiA+PiBtYW55LXRvLW9uZSByZWxhdGlvbnNoaXAuDQo+ID4gDQo+ID4g SSBjYW4ndCBmaW5kIHRoZSBvcmlnaW5hbCB0aHJlYWQgYWJvdXQgdGhpcyBpc3N1ZSwgc28gSSds bCByZXBocmFzZQ0KPiA+IHdoYXQgSSAodGhpbmsgSSkgd3JvdGUgZnJvbSB0aGUgc3RhcnQ6DQo+ ID4gDQo+ID4gSSB1bmRlcnN0YW5kIHRoZSByZWFzb24gZm9yIHRoZSBtYW55LXRvLW9uZSwgYW5k IEkgd2lzaCB3ZSBoYWQgdGhhdCBpbg0KPiA+IHRoZSBiYXNlIG1vZGVsIGl0c2VsZiAoaS5lLiwg UkZDIDg2MzkpLCBzbyB0aGF0IHByb3RvY29sLWRvY3VtZW50cw0KPiA+IGRpZG4ndCBoYXZlIHRv IGludmVudCB0aGlzLCBhbmQgc28gdGhhdCB3ZSBjb3VsZCBoYXZlDQo+ID4gcmVjZWl2ZXItc3Bl Y2lmaWMgY29uZmlnIGluIG9uZSBwbGFjZS4NCj4gDQo+IEkgYWdyZWUsIGl0IHdvdWxk4oCZdmUg YmVlbiBiZXR0ZXIgaW4gUkZDIDg2MzkuICBJIHJlY2FsbCBKdWVyZ2VuDQo+IHdyaXRpbmcgb25j ZSB0aGF0IGhlIGV4cGVjdGVkIGl0IHRvIGJlIGEgY29tbW9uIHBhdHRlcm4uICBCdXQgdGhhdCBp cw0KPiBiZWhpbmQgdXMgbm93LCBvciBhcmUgeW91IHN1Z2dlc3RpbmcgYSAtYmlzPyAgSXMgdGhl cmUgaXMgYW4gYWN0aW9uDQo+IGNvbWluZyBvdXQgb2YgdGhpcyBmb3JrIGluIHRoZSB0aHJlYWQ/ DQoNCk5vIEkgZG9uJ3QgZXhwZWN0IGEgLWJpcyBmb3IgdGhpcy4gIFdoZW4vaWYgd2UgZG8gYSAt YmlzLCB3ZSBzaG91bGQNCmhhdmUgYSBsb29rIGF0IHRoaXMuDQoNCg0KL21hcnRpbg0KDQoNCj4g DQo+IA0KPiA+Pj4gU2luY2UgdGhpcyBpcyBub3QgYSBzdGFuZC1hbG9uZSBtb2RlbCwgSSB0aGlu ayBpdCBzaG91bGQgYXVnbWVudA0KPiA+Pj4gL3NuOnN1YnNjcmlwdGlvbnMuICBJbiBzb21lIHdh eSBpdCBkb2Vzbid0IG1hdHRlciB3aGF0IG5vZGVzIGFyZQ0KPiA+Pj4gY2FsbGVkIGFuZCB3aGVy ZSB0aGV5IGFyZSBsb2NhdGVkLCBidXQgaGF2aW5nIGRlc2NyaXB0aXZlIG5hbWVzIGFuZA0KPiA+ Pj4ga2VlcCByZWxhdGVkIG5vZGVzIHVuZGVyIGNvbW1vbiBzdWJ0cmVlcyBoZWxwcyB0aGUgdW5k ZXJzdGFuZGluZyBvZg0KPiA+Pj4gbW9kZWxzLg0KPiA+PiANCj4gPj4gSXMgcy9yZWNlaXZlci1y ZWYvaHR0cHMtcmVjZWl2ZXItcmVmLyB3aGF0IHlvdSBoYWQgaW4gbWluZD8NCj4gPiANCj4gPiBZ ZXMsIGFzIGEgbWluaW11bS4NCj4gPiANCj4gPiBJIHdvdWxkIGFsc28gY2hhbmdlIHRoZSB0b3At bGV2ZWwgY29udGFpbmVyICJyZWNlaXZlcnMiIHRvIGF1Z21lbnQNCj4gPiAvc246c3Vic2NyaXB0 aW9uczoNCj4gPiANCj4gPiAgYXVnZW1udCAvc246c3Vic2NyaXB0aW9ucyB7DQo+ID4gICAgY29u dGFpbmVyIGh0dHBzLXJlY2VpdmVycyB7DQo+ID4gICAgICAuLi4NCj4gPiAgICB9DQo+ID4gIH0N Cj4gDQo+IEFoLCBJIHNlZSBub3csIHRoYW5rIHlvdSBmb3IgcHJvdmlkaW5nIHRoZSBzbmlwcGV0 Lg0KPiANCj4gDQo+IEtlbnQgLy8gY29udHJpYnV0b3INCj4gDQo+IA0KPiANCj4gDQo= From nobody Wed Feb 12 04:06:58 2020 Return-Path: <01000170394b7ff7-efa3321d-b84c-4945-92d1-c567cf02c7f6-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 8C4641208A6 for ; Wed, 12 Feb 2020 04:06:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 PMM950g1vUVN for ; Wed, 12 Feb 2020 04:06:56 -0800 (PST) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED77712008F for ; Wed, 12 Feb 2020 04:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581509214; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=DF9l3ZGLRNawbnfiwikAEopejrOV+/mCWZSNzYUb4oA=; b=j8/Ds3/zRE6yZfyQr9mjodF6NFT9ANBFhDxNpzCUKddhhGuzc62jHoNw6cqAzVT8 41GNrqpOs1CGwh2EkTbtSjgycEyg8xFweUrLDyZ7s1qH/tqlLVLVlPEr4CP8JCcxeJE nHtGas0L/xs89T7tM5yFULX0AmFhuzCHgMc47zqE= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_C332F41D-1E21-4AAA-95BA-26747E04BD09" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <01000170394b7ff7-efa3321d-b84c-4945-92d1-c567cf02c7f6-000000@email.amazonses.com> Date: Wed, 12 Feb 2020 12:06:54 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.12-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] SSH private key format? 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, 12 Feb 2020 12:06:57 -0000 --Apple-Mail=_C332F41D-1E21-4AAA-95BA-26747E04BD09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Related to the crypto-types, keystore, and truststore drafts... Everyone seems to agree that the *public* key format can be specified = as: leaf public-key { type binary; description "The binary public key data for an SSH key, as specified by RFC 4253, Section 6.6, i.e.: string certificate or public key format identifier byte[n] key/certificate data."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol=E2=80=9D; } BTW, being =E2=80=9Cbinary=E2=80=9D, this produces a block a = base64, a la https://tools.ietf.org/html/rfc4716#section-3.6 = , but without the headers and footers, or EOL characters. Also note that =E2=80=9Ckey data=E2=80=9D is underspecified. = =E2=80=9Ccertificate data=E2=80=9D is better, as PGP/X.509 certs are well-specified, though we have to *assume* the encoding is =E2=80=9CDER". But what is the *private* key format? (i.e., ~/.ssh/id_dsa, = ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 or ~/.ssh/id_rsa). =20 SSH-KEYGEN(1) says this: -m key_format Specify a key format for the -i (import) or -e (export) = conversion options. The supported key formats are: ``RFC4716'' (RFC 4716/SSH2 public or private key), = ``PKCS8'' (PEM PKCS8 public key) or ``PEM=E2=80=99' (PEM public key). The default conversion format is = ``RFC4716''. FWIW, RFC 4716 does NOT define a private key format. PKCS8 does define = a private key format. PKCS8 was obsoleted by RFC 5958, which defines = the =E2=80=9COneAsymmetricKey" format, which is one of the formats used = for TLS private keys. That said, without actually trying to parse these private keys files,I = suspect that they are actually raw private keys (e.g., RSAPrivateKey, = ECPrivateKey, etc.) and not PKCS8/OneAsymmetricKey because, if they were = a OneAsymmetricKey, there would be no need for different filenames... Can anyone dig into this and confirm what these file formats are? Kent // contributor --Apple-Mail=_C332F41D-1E21-4AAA-95BA-26747E04BD09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Related to the crypto-types, keystore, and truststore = drafts...

Everyone seems to agree that the *public* key format can be = specified as:

= leaf public-key {
  =  type binary;
  =  description
      "The = binary public key data for an SSH key, as
  =      specified by RFC 4253, Section 6.6, i.e.:

        =  string    certificate or public key = format identifier
        =  byte[n]   key/certificate data.";
  =  reference
      "RFC = 4253: The Secure Shell (SSH) Transport
  =      Layer Protocol=E2=80=9D;
= }

BTW, = being =E2=80=9Cbinary=E2=80=9D, this produces a block a = base64,
a la https://tools.ietf.org/html/rfc4716#section-3.6, = but
without the headers and footers, = or EOL characters.

= Also note that =E2=80=9Ckey data=E2=80=9D is underspecified. =  =E2=80=9Ccertificate
data=E2=80=9D= is better, as PGP/X.509 certs are well-specified,
= though we have to *assume* the encoding is =E2=80=9CDER".


But what is the *private* key format?  (i.e., = ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 or ~= /.ssh/id_rsa).  

SSH-KEYGEN(1) says this:

    =  -m key_format
        =      Specify a key format for the -i (import) = or -e (export) conversion options.  The = supported key formats are:
        =      ``RFC4716'' (RFC 4716/SSH2 public or private key), = ``PKCS8'' (PEM PKCS8 public key) or ``PEM=E2=80=99'
             (PEM public = key). The default conversion format is ``RFC4716''.

FWIW, RFC 4716 does NOT = define a private key format.  PKCS8 does define a private key = format.  PKCS8 was obsoleted by RFC 5958, which defines the = =E2=80=9COneAsymmetricKey" format, which is one of the formats used for = TLS private keys.

That said, without actually trying to parse these private = keys files,I suspect that they are actually raw private keys = (e.g., RSAPrivateKey, ECPrivateKey, etc.) and not = PKCS8/OneAsymmetricKey because, if they were a OneAsymmetricKey, there = would be no need for different filenames...

Can anyone dig into this and confirm = what these file formats are?


Kent= // contributor

= --Apple-Mail=_C332F41D-1E21-4AAA-95BA-26747E04BD09-- From nobody Thu Feb 13 02:08:58 2020 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 1AF2E1200C7 for ; Thu, 13 Feb 2020 02:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ke1oRRxZYQ-T for ; Thu, 13 Feb 2020 02:08:54 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B95E12007A for ; Thu, 13 Feb 2020 02:08:54 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9D7285CAF387840873E4; Thu, 13 Feb 2020 10:08:50 +0000 (GMT) Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Feb 2020 10:08:50 +0000 Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 13 Feb 2020 10:08:49 +0000 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 13 Feb 2020 10:08:49 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.52]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Thu, 13 Feb 2020 18:08:46 +0800 From: Qin Wu To: Mahesh Jethanandani , "Eric Voit (evoit)" CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXiVDU7eC3gH6aESdCiWUYBGtpr6A== Date: Thu, 13 Feb 2020 10:08:46 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.123] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA966BA0Bdggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 13 Feb 2020 10:08:57 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA966BA0Bdggeml511mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RXJpYzoNCldoeSBzdHJ1Y3R1cmUgbWVzc2FnZSBzaG91bGQgdGllIHRvIGEgc2luZ2xlIFlBTkcg ZGF0YSBtb2R1bGUgd2l0aCChsHlhbmctbW9kdWxlobEgcGFyYW1ldGVyLCBpcyB0aGlzIHRvbyBy ZXN0cmljdGl2ZT8NCg0KLVFpbg0Kt6K8/sjLOiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIE1haGVzaCBKZXRoYW5hbmRhbmkNCreiy83KsbzkOiAyMDIwxOox 1MIyOMjVIDg6MTkNCsrVvP7IyzogRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT4N CrOty806IG5ldGNvbmZAaWV0Zi5vcmcNCtb3zOI6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVj ZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSkNCg0KSGkgRXJpYywNCg0KVGhpcyBlLW1haWwgdHJp Z2dlcnMgdHdvIHJlc3BvbnNlcy4gTGV0IHVzIGRlYWwgd2l0aCBkcmFmdC1pZXRmLW5ldGNvbmYt bm90aWZpY2F0aW9uLW1lc3NhZ2VzIGhlcmUsIGFuZCBJIHdpbGwgYnJpbmcgdXAgY29tbWVudHMv cXVlc3Rpb25zIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmIGluIHRo ZSBvdGhlciB0aHJlYWQuDQoNCllvdSBoYXZlIGluZGljYXRlZCBhIGRlc2lyZSB0aGF0IHJlY2Vp dmVyIGNhcGFiaWxpdGllcyBzaG91bGQgYmUgZG9jdW1lbnRlZCBieSB0aGUgdHJhbnNwb3J0IHNw ZWNpZmljIGRyYWZ0LCBlLmcuIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiwgYW5kIG5v dCB0aGlzIGRyYWZ0LiBBcyBzdWNoIHlvdSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5 Lg0KDQpUbyB0aGUgV0csIHRoZSBhdXRob3JzIGhhdmUgaW5kaWNhdGVkIGEgZGVzaXJlIHRvIHdy YXAgdXAgdGhpcyBkcmFmdCwgYW5kIHdvdWxkIGxpa2UgdXMsIHRoZSBjaGFpcnMsIHRvIGlzc3Vl IGEgV0dMQyBvbiBpdC4gQmVmb3JlIHdlIGRvIHRoYXQsIHdlIHdhbnRlZCB0byBhc2sgaWYgdGhl IFdHIGJlbGlldmVzIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5LCBhbmQgdGhhdCB0aGVyZSBh cmUgbm8gbW9yZSBpc3N1ZXMgdGhhdCBuZWVkIHRvIGRpc2N1c3NlZC9hZGRyZXNzZWQgYnkgZHJh ZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyBkb2N1bWVudCBhdCB0aGlzIHRp bWUuDQoNCkNoZWVycy4NCg0KTWFoZXNoIGFuZCBLZW50IChhcyBjby1jaGFpcnMpLg0KDQoNCk9u IEphbiAxNSwgMjAyMCwgYXQgMTI6MjMgUE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNj by5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBNYWhlc2gsDQoNCkR1 cmluZyB0aGUgSUVURiAxMDYgc2Vzc2lvbiwgdGhlcmUgd2FzIGRpc2N1c3Npb24gb24gaG93IGJv dGggYSBwdWJsaXNoZXIgbWlnaHQga25vdyBpZiB0aGVyZSBpcyByZWNlaXZlciBzdXBwb3J0IGZv ciBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2Fn ZXMvP2luY2x1ZGVfdGV4dD0xPi4gIFNlY3Rpb24gNiBoaWdobGlnaHRzIHNldmVyYWwgb2YgdGhl IGNvbnNpZGVyYXRpb25zLiAgIFJlbGV2YW50IGFyZSB0aGUgZm9sbG93aW5nOg0KDQooYSkgUmVt b3RlIGRldmljZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9m IHRoZSBQdWJsaXNoZXIgbmVlZHMgdG8gYmUgZW5oYW5jZWQgdG8ga25vdyBpZiB0aGUgZmFyIGVu ZCBjYW4gaW50ZXJwcmV0IG5vdGlmaWNhdGlvbiBtZXNzYWdlcyB0eXBlIGJleW9uZCBSRkMtNTI3 NywgU2VjdGlvbiA0Lg0KDQooYikgVGhpcyBjYXBhYmlsaXR5IGRpc2NvdmVyeSBxdWVzdGlvbiBp cyByZWxldmFudCBmb3IgYm90aCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiByZWNlaXZlcnMgYW5k IGR5bmFtaWMgc3Vic2NyaWJlcnMuDQoNCihjKSBUaGUgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgcXVl c3Rpb24gY2FuIGJlIGdlbmVyYWxpemVkIGJleW9uZCBzdWJzY3JpcHRpb25zLCBhcyB0aGVyZSBh cmUgbWFueSByZWFzb25zIHRvIGtub3cgdGhlIGF2YWlsYWJsZSBjYXBhYmlsaXRpZXMgb2YgdGhl IGZhciBlbmQuDQoNCihkKSBDYXBhYmlsaXR5IGRpc2NvdmVyeSBhZHZlcnRpc2VtZW50IGhhcyB0 cmFkaXRpb25hbGx5IGJlZW4gZGlzY3Vzc2VkIHdpdGhpbiB0cmFuc3BvcnQgZG9jdW1lbnRzIChl LmcuIFJGQy02MjQxIFNlY3Rpb24gOC4xKS4NCg0KDQpCYXNlZCBvbiAoYSktKGQpLCBjb21pbmcg dXAgd2l0aCBhIHRyYW5zcG9ydCBpbmRlcGVuZGVudCBwb2ludC1zb2x1dGlvbiB3aXRoaW4gZHJh ZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlczxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLz9p bmNsdWRlX3RleHQ9MT4gKmp1c3QqIHRvIGRpc2NvdmVyIHRoaXMgc2luZ2xlIGVsZW1lbnQgb2Yg Y2xpZW50IGZ1bmN0aW9uYWxpdHkgc2VlbXMgb3ZlcmtpbGwvaGVhdnl3ZWlnaHQuDQoNCkkgd2Fz IGZpbmUgd2l0aCBsZXR0aW5nIHRoaXMgcmVtb3RlIGNhcGFiaWxpdGllcyBkaXNjb3ZlcnkgcXVl c3Rpb24gc2l0IGZvciBhIHdoaWxlLiAgIEhvd2V2ZXIgZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBz LW5vdGlmPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0 cHMtbm90aWYtMDE+IHNob3dzIHRoYXQgd2Ugbm93IG11c3QgYWRkcmVzcyB0aGlzIHF1ZXN0aW9u LiAgU3BlY2lmaWNhbGx5IHNob3VsZCB0aGUgZGlhZ3JhbSBzZWN0aW9uIDEuNC4xIHNob3cgdGhp cyBjYXBhYmlsaXR5IGV4Y2hhbmdlPw0KDQpJdCB0dXJucyBvdXQgdGhhdCBpbmRlcGVuZGVudCBv ZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLCB0aGVyZSBzZXZlcmFs IHF1ZXN0aW9ucyBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgd2hpY2ggbmVlZCB0 byBiZSBhbnN3ZXJlZCBwcmlvciB0byB0aGUgc2VjdGlvbiAxLjQuMSBhcnJvdzogIlNlbmQgSFRU UFMgUE9TVCBtZXNzYWdlIHdpdGggWUFORyBkZWZpbmVkIG5vdGlmaWNhdGlvbiAjMSIgYW55d2F5 LiAgVGhlc2UgcXVlc3Rpb25zIGFyZToNCiAgKDEpIERvZXMgdGhlIHRhcmdldGVkIEhUVFBTIHJl Y2VpdmVyIHN1cHBvcnQgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zPw0KICAoMikgQ2FuIHRoZSB0 YXJnZXRlZCBIVFRQQCByZWNlaXZlciBhY2NlcHQgYSBuZXcgc3Vic2NyaXB0aW9uIGFzIGRlc2Ny aWJlZCBpbiBhIDxzdWJzY3JpcHRpb24tc3RhcnRlZD4/DQpPbmx5IGlmIHRoZXNlIHF1ZXN0aW9u cyBhcmUgInllcyIsIHNob3VsZCB0aGUgPHN1YnNjcmlwdGlvbi1zdGFydGVkPiBiZSByZXNwb25k ZWQgdG8gd2l0aCBhbiAiT0siLg0KDQpBZGQgdG8gdGhpcyBhIHRoaXJkIHF1ZXN0aW9uIGRyaXZl biBmcm9tIChhKS0oZCk6DQogICgzKSBEb2VzIHRoZSByZWNlaXZlciBzdXBwb3J0IHRoZSBtZXNz YWdlIHR5cGUgd2l0aGluICJkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2Vz Ij8NCg0KQSBzdHJhd21hbiB3YXkgdG8gaGFuZGxlIHRoZSBhbGwgdGhyZWUgcXVlc3Rpb25zIHdp dGhpbiBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgd291bGQgYmUgdG8gcmVzcG9uZCB0 byBhIDxzdWJzY3JpcHRpb24tc3RhcnRlZD4gbm90aWZpY2F0aW9uIHdpdGggYW4gSFRUUCBTdGF0 dXMgMjAyIChBY2NlcHRlZCkiIGFja25vd2xlZGdlbWVudC4gIFRoaXMgMjAyIHdvdWxkIGluY2x1 ZGUgYm9keSBlbGVtZW50cyBsaXN0aW5nIHN1cHBvcnRlZCByZWNlaXZlciByZXNvdXJjZXMuICBN YXliZSBzb21ldGhpbmcgWUFORyBlbmNvZGVkIHZpYSBpZXRmLXlhbmctc3RydWN0dXJlLWV4dCBj b250YWluaW5nOg0KDQogICAgICA8Zm9vIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5l dGNvbmY6YmFzZToxLjAiPg0KICAgICAgICA8Y2FwYWJpbGl0aWVzPg0KICAgICAgICAgIDxjYXBh YmlsaXR5Pg0KICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtbm90 aWZpY2F0aW9uLW1lc3NhZ2VzOjEuMA0KICAgICAgICAgIDwvY2FwYWJpbGl0eT4NCiAgICAgICAg PC9jYXBhYmlsaXRpZXM+DQogICAgICA8L2Zvbz4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhp cyBhcHByb2FjaD8NCg0KRXJpYw0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5p QGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABAA966BA0Bdggeml511mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Eric: 

Why structure message should tie t= o a single YANG data module with =A1=B0yang-module=A1=B1 parameter, is this= too restrictive?

 

-Qin

=B7=A2=BC=FE=C8=CB: netconf [mailt= o:netconf-bounces@ietf.org] =B4=FA=B1=ED Mahesh Jethanandani
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2020=C4=EA1=D4=C228=C8=D5 8:19
=CA=D5=BC=FE=C8=CB: Eric Voit (evoit) <evoit@cisco.com>
=B3=AD=CB=CD: netconf@ietf.org
=D6=F7=CC=E2: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Conf= igured receiver capability exchange)

 

Hi Eric,

 

This e-mail triggers two respon= ses. Let us deal with draft-ietf-netconf-notification-messages here, and I = will bring up comments/questions related to draft-ietf-netconf-https-notif = in the other thread.

 

You have indicated a desire tha= t receiver capabilities should be documented by the transport specific draf= t, e.g. draft-ietf-netconf-https-notif, and not this draft. As such you bel= ieve that the draft is ready.

 

To the WG, the authors have ind= icated a desire to wrap up this draft, and would like us, the chairs, to is= sue a WGLC on it. Before we do that, we wanted to ask if the WG believes th= at the document is ready, and that there are no more issues that need to discussed/addressed by draft-ietf-netconf-= notification-messages document at this time.

 

Cheers.

 

Mahesh and Kent (as co-chairs).=



On Jan 15, 2020, at 12:23 PM, E= ric Voit (evoit) <evoit@cisco.com= > wrote:

 

Hi Mahesh,

 

During the IETF 106 session, there w= as discussion on how both a publisher might know if there is receiver suppo= rt for draft-ietf-netconf-notification-me= ssages.  Section 6 highlights several of the considerations.   Relevant are the following:

 

(a) Remote device capability discove= ry from the point of view of the Publisher needs to be enhanced to know if = the far end can interpret notification messages type beyond RFC-5277, Section 4.

 

(b) This capability discovery questi= on is relevant for both configured subscription receivers and dynamic subsc= ribers.  =

 

(c) The capability discovery questio= n can be generalized beyond subscriptions, as there are many reasons to kno= w the available capabilities of the far end.   

 

(d) Capability discovery advertiseme= nt has traditionally been discussed within transport documents (e.g. RFC-62= 41 Section 8.1).   

 

 

Based on (a)-(d), coming up with a t= ransport independent point-solution within draft-ietf-netconf-notification-messages *just* to discover this single element of client functionality seems overkill/hea= vyweight.

 

I was fine with letting this remote = capabilities discovery question sit for a while.   However dr= aft-ietf-netconf-https-notif shows that we now must address this question.  Specifically should the diag= ram section 1.4.1 show this capability exchange?  

 

It turns out that independent of dra= ft-ietf-netconf-notification-messages, there several questions in draft-iet= f-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG = defined notification #1" anyway.  These questions are:=

  (1) Does the targeted HTTPS r= eceiver support configured subscriptions?

  (2) Can the targeted HTTP@ re= ceiver accept a new subscription as described in a <subscription-started= >?

Only if these questions are "ye= s", should the <subscription-started> be responded to with an &q= uot;OK".

 

Add to this a third question driven = from (a)-(d):

  (3) Does the receiver support= the message type within "draft-ietf-netconf-notification-messages&quo= t;?

 

A strawman way to handle the all thr= ee questions within draft-ietf-netconf-https-notif would be to respond to a= <subscription-started> notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 would include = body elements listing supported receiver resources.  Maybe something Y= ANG encoded via ietf-yang-structure-ext containing:

 

      <f= oo xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

      =   <capabilities>

      =     <capability>

      =       urn:ietf:params:xml:ns:yang:ietf-notificatio= n-messages:1.0

      =     </capability>

       = ; </capabilities>

      </= foo>

 

What do you think of this approach?<= o:p>

 

Eric

 

Mahesh Jethanandani<= /span>

 

 

 

--_000_B8F9A780D330094D99AF023C5877DABAA966BA0Bdggeml511mbxchi_-- From nobody Thu Feb 13 08:44:35 2020 Return-Path: <010001703f6ffed7-04873ab1-5ff6-4032-8fcc-12978816a9eb-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 816BA120168 for ; Thu, 13 Feb 2020 08:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 1Zs9TNCikHKR for ; Thu, 13 Feb 2020 08:44:30 -0800 (PST) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9952712016E for ; Thu, 13 Feb 2020 08:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581612269; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=eh9u/S88ILkK/s1L2j4/VW3RzBIcg0Yfyw5GSxPfQfI=; b=Nv0wXDvZG43uoN3bZUd8q95UEpDBgdITKizcwWAz7/Y3k+Hf2wtkXMMjOv1cB7J8 2pOTA8d2wDAf0qAXJATUNdZ3VzsTeC0jrfa7j6fnVkHE27G0bV2dVaMU+SaI3HGxsWs UcIe1ZzTZU2uYYYZXrkRCnRC7bbwvkflPSgyuX/0= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_66A20427-249C-446B-82E7-50286F5668CA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 13 Feb 2020 16:44:29 +0000 References: <01000170394b7ff7-efa3321d-b84c-4945-92d1-c567cf02c7f6-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000170394b7ff7-efa3321d-b84c-4945-92d1-c567cf02c7f6-000000@email.amazonses.com> Message-ID: <010001703f6ffed7-04873ab1-5ff6-4032-8fcc-12978816a9eb-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.13-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] SSH private key format? 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, 13 Feb 2020 16:44:33 -0000 --Apple-Mail=_66A20427-249C-446B-82E7-50286F5668CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 After a little digging=E2=80=A6 1) `ssh-keygen` default private key format is a proprietary format: = https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.key?ann= otate=3DHEAD = 2) `ssh-keygen` can told to save a generated private key to the standard=20= PKCS/CMS format using the =E2=80=9C-m PEM=E2=80=9D parameter 3) `ssh-keygen` can also convert its proprietary private key format to = the=20 PKCS/CMS format (e.g., ssh-keygen -p -N "" -m PEM -f ) 4) OpenSSH can read (but not write) PKCS#8/OneAsymmetricKey formats. See the 9th paragraph of the accepted answer here: = https://superuser.com/questions/1477472/openssh-public-key-file-format = 5) strangely, for =E2=80=9Cecdsa=E2=80=9D keys only, creating the = =E2=80=9CPEM=E2=80=9D format via (3) or (4) produces different EC keys (different number of fields), though = both are still parsable via `openssl ec =E2=80=A6` More info here: = https://www.thedigitalcatonline.com/blog/2018/04/25/rsa-keys = Conclusion: - It seems that both SSH and TLS private keys use the same PKCS/CMS = and OneAsymmetricKey formats. Kent // contributor > On Feb 12, 2020, at 7:06 AM, Kent Watsen wrote: >=20 > Related to the crypto-types, keystore, and truststore drafts... >=20 > Everyone seems to agree that the *public* key format can be specified = as: >=20 > leaf public-key { > type binary; > description > "The binary public key data for an SSH key, as > specified by RFC 4253, Section 6.6, i.e.: >=20 > string certificate or public key format identifier > byte[n] key/certificate data."; > reference > "RFC 4253: The Secure Shell (SSH) Transport > Layer Protocol=E2=80=9D; > } >=20 > BTW, being =E2=80=9Cbinary=E2=80=9D, this produces a block a = base64, > a la https://tools.ietf.org/html/rfc4716#section-3.6 = , but > without the headers and footers, or EOL characters. >=20 > Also note that =E2=80=9Ckey data=E2=80=9D is underspecified. = =E2=80=9Ccertificate > data=E2=80=9D is better, as PGP/X.509 certs are well-specified, > though we have to *assume* the encoding is =E2=80=9CDER". >=20 >=20 > But what is the *private* key format? (i.e., ~/.ssh/id_dsa, = ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 or ~/.ssh/id_rsa). =20 >=20 > SSH-KEYGEN(1) says this: >=20 > -m key_format > Specify a key format for the -i (import) or -e (export) = conversion options. The supported key formats are: > ``RFC4716'' (RFC 4716/SSH2 public or private key), = ``PKCS8'' (PEM PKCS8 public key) or ``PEM=E2=80=99' > (PEM public key). The default conversion format is = ``RFC4716''. >=20 > FWIW, RFC 4716 does NOT define a private key format. PKCS8 does = define a private key format. PKCS8 was obsoleted by RFC 5958, which = defines the =E2=80=9COneAsymmetricKey" format, which is one of the = formats used for TLS private keys. >=20 > That said, without actually trying to parse these private keys files,I = suspect that they are actually raw private keys (e.g., RSAPrivateKey, = ECPrivateKey, etc.) and not PKCS8/OneAsymmetricKey because, if they were = a OneAsymmetricKey, there would be no need for different filenames... >=20 > Can anyone dig into this and confirm what these file formats are? >=20 >=20 > Kent // contributor >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_66A20427-249C-446B-82E7-50286F5668CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

After a little digging=E2=80=A6

1) `ssh-keygen` default private key = format is a proprietary format:
  =   https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTO= COL.key?annotate=3DHEAD

2) `ssh-keygen` can told to save a generated private key to = the standard 
     PKCS/CMS = format using the =E2=80=9C-m PEM=E2=80=9D parameter

3) `ssh-keygen` can also = convert its proprietary private key format to the 
     PKCS/CMS format (e.g., = ssh-keygen -p -N "" -m PEM -f <filen= ame>)

4) OpenSSH can read = (but not write) PKCS#8/OneAsymmetricKey
    =  formats. See the 9th paragraph of the accepted answer = here:
     https://superuser.com/questions/1477472/openssh-public-key-file= -format

 5) = strangely, for =E2=80=9Cecdsa=E2=80=9D keys only, creating the =E2=80=9CPE= M=E2=80=9D format via (3) or (4)
    =  produces different EC keys (different number of fields), though = both are
     still parsable via = `openssl ec =E2=80=A6`

More info here: https://www.thedigitalcatonline.com/blog/2018/04/25/rsa-keys

Conclusion:

  - It seems that both SSH and TLS private keys use the = same PKCS/CMS and
    OneAsymmetricKey = formats.

Kent = // contributor



On Feb 12, 2020, at 7:06 AM, = Kent Watsen <kent+ietf@watsen.net> wrote:

Related = to the crypto-types, keystore, and truststore drafts...

Everyone seems to agree = that the *public* key format can be specified as:
leaf public-key {
=    type binary;
  =  description
      "The = binary public key data for an SSH key, as
  =      specified by RFC 4253, Section 6.6, i.e.:

        =  string    certificate or public key = format identifier
        =  byte[n]   key/certificate data.";
  =  reference
      "RFC = 4253: The Secure Shell (SSH) Transport
  =      Layer Protocol=E2=80=9D;
= }

BTW, = being =E2=80=9Cbinary=E2=80=9D, this produces a block a = base64,
a la https://tools.ietf.org/html/rfc4716#section-3.6, = but
without the headers and footers, = or EOL characters.

= Also note that =E2=80=9Ckey data=E2=80=9D is underspecified. =  =E2=80=9Ccertificate
data=E2=80=9D= is better, as PGP/X.509 certs are well-specified,
= though we have to *assume* the encoding is =E2=80=9CDER".


But what is the *private* key format?  (i.e., = ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 or ~= /.ssh/id_rsa).  

SSH-KEYGEN(1) says this:

    =  -m key_format
        =      Specify a key format for the -i (import) = or -e (export) conversion options.  The = supported key formats are:
        =      ``RFC4716'' (RFC 4716/SSH2 public or private key), = ``PKCS8'' (PEM PKCS8 public key) or ``PEM=E2=80=99'
             (PEM public = key). The default conversion format is ``RFC4716''.

FWIW, RFC 4716 does NOT = define a private key format.  PKCS8 does define a private key = format.  PKCS8 was obsoleted by RFC 5958, which defines the = =E2=80=9COneAsymmetricKey" format, which is one of the formats used for = TLS private keys.

That said, without actually trying to parse these private = keys files,I suspect that they are actually raw private keys = (e.g., RSAPrivateKey, ECPrivateKey, etc.) and not = PKCS8/OneAsymmetricKey because, if they were a OneAsymmetricKey, there = would be no need for different filenames...

Can anyone dig into this and confirm = what these file formats are?


Kent= // contributor

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

= --Apple-Mail=_66A20427-249C-446B-82E7-50286F5668CA-- From nobody Thu Feb 13 09:23:26 2020 Return-Path: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-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 B4E1E1200C4 for ; Thu, 13 Feb 2020 09:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 mAszmi0zlYdf for ; Thu, 13 Feb 2020 09:23:24 -0800 (PST) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D92120058 for ; Thu, 13 Feb 2020 09:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581614602; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=NB1l0lvu4QEdtP0maDWXk1geDCG950a4gEwxVYLLcFs=; b=BBBM7HG3FmIXvqmWVld0qmQgf/4Oq+FHHGJorbVUXgyfr6Rnxt3uoLgMrplgisnY g+OL0aJ0wZ5gZe5J4KTleWA7VMBCVWyv9ANXsi1Sf5pk4xtUHM624rzENZt9D7HDaWj q53GT5NXFjnFgEanituyn5DGxNkGq9ctn803cN8Y= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com> Date: Thu, 13 Feb 2020 17:23:22 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.13-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Supported algorithms lists 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, 13 Feb 2020 17:23:26 -0000 All, We had a discussion awhile back about split/move-ing the 3 =E2=80=9Csuppor= ted algorithm=E2=80=9D lists into the SSH- and TLS- client-server drafts = (a total of 6 lists when done). The thinking was SSH and TLS might = (perhaps likely?) support different algorithms, which would be good to = capture. That said, we noted that this was a compromise as there may be more than = one SSH or TLS library used by an application, and thus having = protocol-specific lists may be too course (compared to library-specific = lists). I=E2=80=99m wondering if we can do better and maybe even simpler=E2=80=A6 One idea is to stick with having a single list per algorithm type (i.e., = symmetric, asymmetric, hash, etc.), but then to allow each list item to = contain a list of *where* that algorithm can be used. In the simplest = case, the =E2=80=9Cwhere it can be used=E2=80=9D could be enumerated = values (=E2=80=9CSSH=E2=80=9D, =E2=80=9CTLS=E2=80=9D) but perhaps better = could be a list of XPaths? However this seems a bit upside-down, as what would likely be preferred = is to have a list of XPaths and then, for each, as list of supported = algorithms. Better, but messy, but it suggests a 3rd idea, which is = to have an RPC that takes an XPath (to a key) and returns the list of = supported algorithms for that key. rpc get-support-algorithms { input { leaf schema-path { type string; description =E2=80=9CSchema path to a =E2=80=98key=E2=80=99 = node.=E2=80=9D; } } output { choice key-type { case symmetric-key { leaf-list symmetric-algorithm { type symmetric-algorithm-type; } } case asymmetric-key { leaf-list asymmetric-algorithm { type symmetric-algorithm-type; } } } } } This seems elegant as the implementation complexity scales with the = complexity of the application. An application that uses only a single = crypto library could have a fairly static response, whereas complex = applications could vary the response by the path (knowing which crypto = library would be used). Thoughts? Kent // contributor From nobody Thu Feb 13 10:48:45 2020 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 AD79112081F for ; Thu, 13 Feb 2020 10:48:37 -0800 (PST) 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, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yZNCSpfQkg0 for ; Thu, 13 Feb 2020 10:48:36 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FED012081C for ; Thu, 13 Feb 2020 10:48:36 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01DIlQuw001235; Thu, 13 Feb 2020 18:48:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MYQ1Nc6uzIiUpIlCzsDp1H47UXdv/yEu+mh5g+oFh2U=; b=aJriYsGGEAkW+qXG1I1zT1OM6Qoyfo5SjvlxZRstYEZKPezegch3Nc7MpqjAl1vdhFAU KlfSK0hWJUOQlwYI6a9zktJg+lsfD9rwisrVrIO6GSU0pHr2Dq03UvfMfURpp4qWRufu kUIqkSceyQHIeBCbI2d10zo/MIQAYJgn1252S7Uup94z1CurpfXLgPj+Dog5XC+HmQGH bYuluNOi680uuic8cy0/cQjenziqpM07LFbfqQk3CmxY1BUja6UORb2hkNMBSwXq/m/4 ei8JO0laZqGiTRJ73Bv0jUOawxlyRQqfvBN/Ma7PijlRE0hJqIrqPgmhsOmkLr6aBU7u Fw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2y457y89xd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 18:48:35 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01DIlpRD014477; Thu, 13 Feb 2020 10:48:34 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2y5bd680v5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 13 Feb 2020 10:48:34 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Feb 2020 13:48:33 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Feb 2020 13:48:33 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 13 Feb 2020 13:48:33 -0500 From: "Salz, Rich" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Supported algorithms lists Thread-Index: AQHV4pJRGz8wjkufPEeULUGrOkBPq6gZdz2A Date: Thu, 13 Feb 2020 18:48:33 +0000 Message-ID: <3F865F3D-EEA6-4DAB-A1B3-7062C8496E4B@akamai.com> References: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com> In-Reply-To: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.35] Content-Type: text/plain; charset="utf-8" Content-ID: <414E1823B0B9F34EBB517B43EB24DCE3@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=861 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002130132 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-13_07:2020-02-12, 2020-02-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 spamscore=0 mlxlogscore=843 malwarescore=0 mlxscore=0 priorityscore=1501 suspectscore=0 impostorscore=0 phishscore=0 clxscore=1011 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002130131 Archived-At: Subject: Re: [netconf] Supported algorithms lists 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, 13 Feb 2020 18:48:44 -0000 PiBpdCBzdWdnZXN0cyBhIDNyZCBpZGVhLCB3aGljaCBpcyB0byBoYXZlIGFuIFJQQyB0aGF0IHRh a2VzIGFuIFhQYXRoICh0byBhIGtleSkgYW5kIHJldHVybnMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVk IGFsZ29yaXRobXMgZm9yIHRoYXQga2V5Lg0KICAgDQpJIGNvdWxkIGJlIGNvbmZ1c2VkLCBidXQg SSBkb24ndCBrbm93IGlmIHRoaXMgaXMgYSBnb29kIGlkZWEuICBTdXBwb3NlIEkgaGF2ZSBhbiBS U0Ega2V5cGFpcjsgd291bGQgSSBleHBlY3QgdG8gZ2V0IGJhY2sgZXZlcnkgVExTIDEuMiBjaXBo ZXJzdWl0ZSBuYW1lIHRoYXQgaGFzIFJTQSBpbiBpdD8gIFRoZXJlIGFyZSBhcm91bmQgMzAuICBB bmQgZm9yIFRMUyAxLjMsIHdoZXJlIHRoZSBpZGVudGl0eSBpcyBicm9rZW4gb3V0IHNlcGFyYXRl bHkgZnJvbSB0aGUgYnVsayBlbmNyeXB0aW9uIC0tIHRoZSBzby1jYWxsZWQgImEgbGEgY2FydGUi IGFwcHJvYWNoIC0tIGl0IGJlY29tZXMgcmF0aGVyIGRpZmZpY3VsdC4NCg0K From nobody Thu Feb 13 17:06:20 2020 Return-Path: <01000170413b5d79-04146888-12f6-4fbd-9890-5869d242f453-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 5BA2C12003F for ; Thu, 13 Feb 2020 17:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 PKwszYwPzMeM for ; Thu, 13 Feb 2020 17:06:16 -0800 (PST) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A7F120020 for ; Thu, 13 Feb 2020 17:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581642374; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=mfJ1dUm5L3Hv+1IBm5zHn0v6ae1t21MtOIihQ2bRxgE=; b=Jbq5bBxa8DLzLVsbmomdxJIqE+9ntl0IxBtFpMnGECygzFgwwRyMMUz+/X0mA8nF QsEIHrsTY9jR27tXgW0KL8/M+Qtg+a/GS3pEewddHRCjv5S4RDw0kQDfz0P3ZIS2pD7 wi3dRobyPnUVIAODkJRFACqF2ar82HtfOgOaScbQ= From: Kent Watsen Message-ID: <01000170413b5d79-04146888-12f6-4fbd-9890-5869d242f453-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA6944BC-59A8-4098-B49A-F778519D958F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 14 Feb 2020 01:06:14 +0000 In-Reply-To: <3F865F3D-EEA6-4DAB-A1B3-7062C8496E4B@akamai.com> Cc: "netconf@ietf.org" To: "Salz, Rich" References: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com> <3F865F3D-EEA6-4DAB-A1B3-7062C8496E4B@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.14-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Supported algorithms lists 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, 14 Feb 2020 01:06:18 -0000 --Apple-Mail=_EA6944BC-59A8-4098-B49A-F778519D958F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rich, good to see you=E2=80=99re keeping us honest here ;) >> it suggests a 3rd idea, which is to have an RPC that takes an XPath = (to a key) and returns the list of supported algorithms for that key. >=20 > I could be confused, but I don't know if this is a good idea. Suppose = I have an RSA keypair; would I expect to get back every TLS 1.2 = ciphersuite name that has RSA in it? There are around 30. And for TLS = 1.3, where the identity is broken out separately from the bulk = encryption -- the so-called "a la carte" approach -- it becomes rather = difficult. That=E2=80=99s not quite what I had envisioned, but you may be onto = something nonetheless. Regarding the proposed idea, first note that the intent is that the = desire to know what algorithms are supported is mostly to either 1) ask = the device to generate and key or 2) know what kind of key could be = generated offline and subsequently loaded onto the device. In either = case, it=E2=80=99s not so much that you *have* an RSA keypair, but that = you wish to generate a one. To give a concrete example, assume the data model illustrated by tree = diagram here: = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-17#a= ppendix-A.2 = . The RPC might be: = /restconf-server/listen/endpoint/transport/https/tls-server-parameters/ser= ver-identty/... So it=E2=80=99s clear that the intent that the key is intended for TLS = (not SSH). That said, and to your point, it doesn=E2=80=99t indicate if = for TLS 1.2 or 1.3 and, worse, if the path instead references a keystore = path (e.g., /keystore/asymmetric-keys/asymmetic-key/=E2=80=A6), it=E2=80=99= s not even clear that the key is intended for TLS or SSH=E2=80=A6 In contrast, the current/planned/old approach described in my previous = message, whereby there would be a list per protocol (TLS vs SSH), also = did not take into account protocol versions (1.2 vs 1.3). So, if this = is an issue, we have no proposal addressing it yet... How does OpenSSL CLI support this? Looking at `openssl ciphers`, I see = that it=E2=80=99s possible to specific protocol versions (i.e., 1.2, = 1.3, etc.). But, in the end, these are cipher suites (e.g., = ECDHE-RSA-AES128-GCM-SHA256), not just the algorithm (RSA) and = definitely not indicating supported key lengths (presumable all RSA key = lengths are supported?)... It would help if we could identify the CLI-equivalent for all this=E2=80=A6= PS: both the SSH and TLS client-server draft create mapping tables = between the protocol-specific cipher-suite names and to the algorithm = names in crypto-types. For instance, here are the mapping tables for = TLS: = https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#sectio= n-5. PPS: I=E2=80=99m beginning to think that we might be better giving up on = having any RPC to ask the server to generate keys or indicate which = algorithms are supported, punting all this complexity to some future = revision. That said, it would be best is we could get something = passable working now, if possible... Thanks, Kent. // contributor --Apple-Mail=_EA6944BC-59A8-4098-B49A-F778519D958F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Rich,  good to = see you=E2=80=99re keeping us honest here ;)

it suggests a 3rd idea, = which is to have an RPC that takes an XPath (to a key) and returns the = list of supported algorithms for that key.

I could be confused, but I don't know if this is a good idea. =  Suppose I have an RSA keypair; would I expect to get back every = TLS 1.2 ciphersuite name that has RSA in it?  There are around 30. =  And for TLS 1.3, where the identity is broken out separately from = the bulk encryption -- the so-called "a la carte" approach -- it becomes = rather difficult.

That=E2=80=99s not quite what I had envisioned, = but you may be onto something nonetheless.

Regarding the proposed idea, first note that the = intent is that the desire to know what algorithms are supported is = mostly to either 1) ask the device to generate and key or 2) know what = kind of key could be generated offline and subsequently loaded onto the = device.  In either case, it=E2=80=99s not so much that you *have* = an RSA keypair, but that you wish to generate a one.

To give a concrete example, assume the data model = illustrated by tree diagram here: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-= server-17#appendix-A.2.  The RPC might be:

 <rpc = message-id=3D"101"
    =  xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
     <get-supported-algorithms = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-crypto-types>
       <schema-path>
          = /restconf-server/listen/endpoint/transport/https/tls-server-parameters/ser= ver-identty/...
      =  </schema-path>
  =    </get-supported-algorithms>
   </rpc>

So it=E2=80=99s clear that the intent = that the key is intended for TLS (not SSH).  That said, and to your = point, it doesn=E2=80=99t indicate if for TLS 1.2 or 1.3 and, worse, if = the path instead references a keystore path (e.g., = /keystore/asymmetric-keys/asymmetic-key/=E2=80=A6), it=E2=80=99s not = even clear that the key is intended for TLS or SSH=E2=80=A6

In contrast, the = current/planned/old approach described in my previous message, whereby = there would be a list per protocol (TLS vs SSH), also did not take into = account protocol versions (1.2 vs 1.3).  So, if this is an issue, = we have no proposal addressing it yet...

How does OpenSSL CLI support this? =  Looking at `openssl ciphers`, I see that it=E2=80=99s possible to = specific protocol versions (i.e., 1.2, 1.3, etc.).   But, in the = end, these are cipher suites (e.g., ECDHE-RSA-AES128-GCM-SHA256), not = just the algorithm (RSA) and definitely not indicating supported key = lengths (presumable all RSA key lengths are supported?)...

It would help if we = could identify the CLI-equivalent for all this=E2=80=A6

PS: both the SSH and TLS = client-server draft create mapping tables between the protocol-specific = cipher-suite names and to the algorithm names in crypto-types.  For = instance, here are the mapping tables for TLS: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-serve= r-17#section-5.

PPS: I=E2=80=99m beginning to think that we might be better = giving up on having any RPC to ask the server to generate keys or = indicate which algorithms are supported, punting all this complexity to = some future revision.  That said, it would be best is we could get = something passable working now, if possible...

Thanks,
Kent. // = contributor





= --Apple-Mail=_EA6944BC-59A8-4098-B49A-F778519D958F-- From nobody Fri Feb 14 02:03:29 2020 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 96572120131 for ; Fri, 14 Feb 2020 02:03:27 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XnpQ_0gNy_ds for ; Fri, 14 Feb 2020 02:03:24 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10073.outbound.protection.outlook.com [40.107.1.73]) (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 4EE0D1200BA for ; Fri, 14 Feb 2020 02:03:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c/CS/QmWtrnsBJdFFg8za6uDuCjfXlsWqAxWrKMqQa1Ykb6Q7F1WrGVXREgBrc0cJ1ADACBMY5SQYURgu3P0r8+cBpnAzAEJdZCfcAw81aT9Btai9kOCT7+zdUPFW0x6wJX+dXyf+kft8tWQ6TiMLVV/aFdYX8iZVJN6parVYB/VD+4e+2p0ZDM6YU5sojs66ufOL4BoOH2ycSsXugKYbwcdBOXikGJBjOXbk+mEmnFyvnLyNdd7qXFQjyXXB8HxIzznlf1+GVC1gQA1r1g9ahAF1vhXOcfawB56iD2X8dim8+jOde2rtTrkr0QfadHIsTvdc9oc82hLIbBeilno6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lcyK6dcSzogceCfmGuPSQKIARP+NBjLR8ZR42AmCXn0=; b=EiA4g/llkaH4BViIyfEKfarfXhCrMHB2iQqoo8uAnPnbNXJxy2bXoeykFhNXpXKy6B/GgVWKAsdtVtcW59fxGDydMePPAtM3DKjyPp6QbTJCr/Gr3xQHfL0/6Gs/+j2e/TlHMQoHcZbgw4n/9ehshlYfH16wg1xgN5ebbaq9+Ply+3Be2Eibzxo/qQzw26eEVsh3yK3CS5DWe4ETWS57UpGDj15KLKNWh+8ZqK4h954TcUHGbvcCWkyXKUxZSXXpPFkAm8QcoVmP3oySuhYrhaJqnKaoFVT4RxiFK5UumYjVo7EObmKFhynBlKjpYvSO5E9B99OMh/8tjtlnDofoxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=lcyK6dcSzogceCfmGuPSQKIARP+NBjLR8ZR42AmCXn0=; b=i1acMibLCfC4ZOdSE0UizF0UPA4/c1LIhPnB4ZWYglgbkJXlQHWX3XtZfWTKXC8kCBaO6zAq+uvLqFUXPsbpjD2gSPE0HBRLymjsHWGbWBb78Oi0WkGJszMEZlNhv8zoKpIJt+h6954IvnRLYWLaDXr8Yx1L32l/qAJYaaXqxyI= Received: from DB7PR07MB4011.eurprd07.prod.outlook.com (52.134.97.155) by DB7PR07MB5963.eurprd07.prod.outlook.com (20.178.84.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.21; Fri, 14 Feb 2020 10:03:21 +0000 Received: from DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::b19e:4830:538a:d973]) by DB7PR07MB4011.eurprd07.prod.outlook.com ([fe80::b19e:4830:538a:d973%5]) with mapi id 15.20.2750.007; Fri, 14 Feb 2020 10:03:21 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "Reshad Rahman (rrahman)" , "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.txt Thread-Index: AQHVzIjtnDHg7Kv35kqaQ6ta9dr6oaf7nmAAgB7tp5A= Date: Fri, 14 Feb 2020 10:03:21 +0000 Message-ID: References: <157918802007.26211.15290734681239936924@ietfa.amsl.com> <4E44FB5B-799A-49CD-95DA-C81D8B5EEE31@cisco.com> In-Reply-To: <4E44FB5B-799A-49CD-95DA-C81D8B5EEE31@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bfd3e12a-f1e6-41eb-a044-08d7b1351f79 x-ms-traffictypediagnostic: DB7PR07MB5963: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(346002)(136003)(376002)(396003)(199004)(189003)(5660300002)(6506007)(53546011)(52536014)(9686003)(26005)(186003)(85202003)(85182001)(316002)(2906002)(33656002)(86362001)(55016002)(81166006)(66946007)(7696005)(76116006)(8936002)(66446008)(478600001)(64756008)(966005)(8676002)(71200400001)(81156014)(66574012)(66556008)(66476007)(15650500001)(110136005)(66616009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5963; H:DB7PR07MB4011.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: BCL:0; x-microsoft-antispam-message-info: mZevS6jXoa+ZGrDz95jAMBDbmw2dmF+Kswd2EhAty1YpUbNgfQu7Lm9Z02Ro95CGfWCtpt5G8fb1yxUdWfVeKHi9rp+GKk42Xu2R+gXSZwQFJ5GkOAUJHK6TZ0ssoxYzoGqCAby8qXx9VBecBDPxA4GuGGwfi8x3LAjT/c9Y9RXeacnOm18eWhWLM0DZCb8G3PwA16epiSLRWCgq0Jh8J/M2mlCrZrwKVIzaPZaNtDiAJRphkdhgGurUYlPqOItcLpHKcnEp8U7XJ9jb7+/6A4meHC5Akiszms8SbqaBucl5Fl0302yj/5gxxor8Y6XQQQOmFjvG/OuzXcLNzumBITiLhvRL6b2s4Fg7KOUj9ueMN+cjYiSzwdKM5wxr3rettnsAlR47GJpKX1jdhlOoO07T8awiiL+3BadjiO9jQGZcZCqwBtEdJsiw+I0Lbs8NeEDfIcLBGBrCIR1cRWqS0nKv0Q+Wd/RVN6RUnLsW3h2Ocoh7yVyX09ipQ5me/lP3ddeBmubbbECZe/r3Uxv18g== x-ms-exchange-antispam-messagedata: qzbxsShuOqGq3gEAHxP9ZfD2Mk3MFEnsBEfsbphSWaBV0n/WMTJOzlLckxJQdUo053bD6lnUeneauDx+RjEtXlj7s4ukKYBy2Ydi7wQtzSoq0tuf9+8i2xeh3+PcC6Y6R7lOg9+bTpc6ZBCgLEwUlQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_07BE_01D5E326.5D6CC710" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bfd3e12a-f1e6-41eb-a044-08d7b1351f79 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2020 10:03:21.5082 (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: 2Z99BYyjMatnGn54uu6DofEDi2x1eG4P6e7StfBNVcF+U9JqdW5hDulUWdcJrKAv83RTv7NEykMc3Vv78ni8dASq/gLyeKSVtuDRAm4pDtc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5963 Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-10.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, 14 Feb 2020 10:03:28 -0000 ------=_NextPart_000_07BE_01D5E326.5D6CC710 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See below. BALAZS -----Original Message----- From: Reshad Rahman (rrahman) =20 Sent: 2020. janu=C3=A1r 25., szombat 17:23 To: netconf@ietf.org; Bal=C3=A1zs Lengyel Subject: Re: [netconf] I-D Action: = draft-ietf-netconf-notification-capabilities-10.txt Hi Balazs, Questions/comments on the examples: - My main comment is that the example section needs to be extended to = address more use-cases. One of the reasons we didn't go with YANG model = annotation is the need to express capabilities per-instance, we should = have an example to illustrate that. (e.g. where 1 interface has = different on-change capabilities than the default/others). BALAZS: OK. will add it into the acme router example. The loopback = interface does not support any notifications. - Page 19-20 both examples have running datastore on-change-supported = set to "config-changes state-changes". I don't think state-changes makes = sense for running since state-changes is for config false nodes? BALAZS: It might not make sense, but is OK. Anyway I will remove state. I will add to the typedef's description: If the bit config-changes or state-changes is set=20 for a datastore or a set of nodes that does not contain=20 nodes with the indicated config value,=20 this has no effect, as if no support was declared.=20 E.g. indicating support for state-changes for=20 a candidate datastore has no effect.=20 - In the 2nd example, why "config-changes" for in-octets and out-octets, = should be state-changes only? BALAZS: Doesn't matter whether config-changes is declared in this case, = as these specific leaves are config=3Dfalse. I will remove = config-changes for simplicity. - Page 21 the 2nd example has this: = /if:interfaces/if:interface/if:statistics, typo?=20 BALAZS: OK, updated - Second example, do we need a node-selector entry to indicate that = datastore subscription capabilities are not reported on-change? And an = entry for / to indicate that operational is on-change capable (as in = example 1)? BALAZS:=20 datastore subscription capabilities: Not really needed, as they never = change as stated above the example operational is on-change capable: no update needed. This is declared = on system level. Regards, Reshad. =EF=BB=BFOn 2020-01-16, 10:21 AM, "netconf on behalf of = internet-drafts@ietf.org" wrote: =20 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. =20 Title : Generic YANG-related System Capabilities = and YANG-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : = draft-ietf-netconf-notification-capabilities-10.txt Pages : 23 Date : 2020-01-15 =20 Abstract: This document proposes two YANG modules. The module ietf-system- capabilities provides a structure that can be used to specify any YANG related system capability. =20 The module ietf-notification-capabilities allows a publisher to specify capabilities related to "Subscription to YANG Datastores" (YANG-Push). It proposes to use YANG Instance Data to document = this information and make it already available at implementation-time, = but also allow it to be reported at run-time. =20 =20 The IETF datatracker status page for this draft is: = https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabili= ties/ =20 There are also htmlized versions available at: = https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-= 10 = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-cap= abilities-10 =20 A diff from the previous version is available at: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-notification-capab= ilities-10 =20 =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf =20 ------=_NextPart_000_07BE_01D5E326.5D6CC710 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw 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+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIwMDIxNDEwMDMxOVowIwYJKoZIhvcNAQkEMRYEFHPod6MivJuDh1A+RqZKvJ+CrPNDMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQAShfQN8LUNIXRCCZ68PYxIc7PRZ99o36tfpttLOfeSWMJUACR1cbmP Vdl60CeIqmyUU3G8BCnqOGZFVSQdyKeahpmxyhW0boGzjw7XUa0Jrws7AAmzbeRdmrBoycAWhH4D FKmXfoGbuUbrFxYUwRLftFOmxLP33COaKGeYdGvJQ1Up4hUOojyOI+3+v7rZ2AGmsbdxS41pvwgn I/PRvDZdYwXjFfnkukJTfcnM8VyzT3kK/+uhoZuRGGWOKLrcvw40pdMcId1WX5zOPcUSttBnLwSF gHHv5XBtsKYPSerHP8sUoMLRCjSYugPIlBrgIpSif1cJCD404y0TgLBzeE8wAAAAAAAA ------=_NextPart_000_07BE_01D5E326.5D6CC710-- From nobody Fri Feb 14 08:00:56 2020 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 3E5EE1200FA; Fri, 14 Feb 2020 08:00:49 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <158169604917.16119.5942214382002308662@ietfa.amsl.com> Date: Fri, 14 Feb 2020 08:00:49 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-11.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, 14 Feb 2020 16:00:50 -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 : Generic YANG-related System Capabilities and YANG-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-11.txt Pages : 24 Date : 2020-02-14 Abstract: This document proposes two YANG modules. The module ietf-system- capabilities provides a structure that can be used to specify any YANG related system capability. The module ietf-notification-capabilities allows a publisher to specify capabilities related to "Subscription to YANG Datastores" (YANG-Push). It proposes to use YANG Instance Data to document this information and make it already available at implementation-time, but also allow it to be reported at run-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-11 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 17 18:36:39 2020 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 2D51012084C for ; Mon, 17 Feb 2020 06:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHIeDCWWHH4w for ; Mon, 17 Feb 2020 06:57:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D723312004C for ; Mon, 17 Feb 2020 06:57:55 -0800 (PST) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 0BD971AE018B; Mon, 17 Feb 2020 15:57:53 +0100 (CET) Date: Mon, 17 Feb 2020 15:57:14 +0100 (CET) Message-Id: <20200217.155714.1030215278913591724.mbj@tail-f.com> To: mgangaia@cisco.com Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Netconf Query 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, 17 Feb 2020 14:57:59 -0000 Hi, "Mahendra Gangaiah (mgangaia)" wrote: > Hi all, > > Can you please help me out with the below query. > > The below netcon payload is intended to create a layer 2 trunk port > and add allowed vlans 10 to 20 on that interface > > > > > > > > > eth1/10 > > > > TRUNK > 10..20 > > > > > > > > > > Based on the yang model definition, trunk-vlans is defined as below. > > > leaf-list trunk-vlans { > when "../interface-mode = 'TRUNK'" { > description > "Allowed VLANs may be specified for trunk mode > interfaces."; > } > > Question: > ========== > When the above payload is pushed using netconf, > Does the expression in the when statement defined in the model for an > object refers to data in the datastore context, or data in the request > context or can be either. > Can the netconf request include both the change to the configuration > that satisfies the when expression and changes to elements that are > enabled by that same when expression ? > Should the above payload work ? Yes it should work; the request sets the interface-mode to "TRUNK" which makes 'trunk-vlans' valid. /martin From nobody Mon Feb 17 18:38:22 2020 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 3F258120044 for ; Mon, 17 Feb 2020 07:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=hsfm2aXL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aCGJlGJj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtEh4e47Aq90 for ; Mon, 17 Feb 2020 07:41:45 -0800 (PST) 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 E086C12001E for ; Mon, 17 Feb 2020 07:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1998; q=dns/txt; s=iport; t=1581954105; x=1583163705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jfOjaBsM4dwgTmaUHodDvOR0l9XrnGtoO31nJuP0wa0=; b=hsfm2aXLQsCoWzkDQvvOMEWM4yG4DiP/IrdsyQEHzybUKRpDcZpHGHjN b/19wbC9Bry+2pFqfXnif6764vtERCna8Eg9DypTuNC3DXLgFJ0AJu8tg YEuTM92vJk8uHBtgiuXG6bW+YQf6eZIkn/ZWdKy90rORpUHVO40YV/5sw E=; IronPort-PHdr: =?us-ascii?q?9a23=3ArcFjkhJpfKFzsV2x59mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEj0JfjlZi0zNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAAA0s0pe/4YNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagMBAQELAYFTUAWBRCAECyqHWgOKeYJfmBGCUgNUCQE?= =?us-ascii?q?BAQwBAS0CBAEBhEACggQkNwYOAgMNAQEFAQEBAgEFBG2FNwyFZgEBAQEDEig?= =?us-ascii?q?GAQE3AQsEAgEIDgMEAQEBHhAyHQgBAQQOBQgahU8DLgECoRQCgTmIYoIngn8?= =?us-ascii?q?BAQWFEhiCDAmBOAGMIxqBQT+BWIIXNT6ETYNAgiyWapkYCoI6lm+CSYgWkDu?= =?us-ascii?q?qGgIEAgQFAg4BAQWBaCMqgS5wFTuCbFAYDY4dg3OKU3SBKY13AQE?= X-IronPort-AV: E=Sophos;i="5.70,453,1574121600"; d="scan'208";a="430832536" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Feb 2020 15:41:41 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 01HFfeaP016325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2020 15:41:41 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 09:41:40 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 09:41:40 -0600 Received: from NAM10-BN7-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; Mon, 17 Feb 2020 09:41:39 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2Bxssjz2TJvKRHQv8IDutUkmTHYinVQVyvQwjeu+Hph6z8Fmye/MjsqY1SHLVLqwRLteoMh2QzDTULGFun1YMB9nWA/GgTSjcRyWgE4xHechm6nZO9sl7K0435PBhu5JwPkcpnb02JixdXo88tFFfwyNKHYPdFq4XATc4K43CrEz/Zfi+nLV+gsbW8BBn/DcL0kalfOTlUxZbJogRe1KUo1WIJ496Rqddx0Y3kB1UTHrjgoaxV2/s/gvErYHk7wvLEgAS+MFWIOB7S9pXDU1DyL5/nVfKkgIBXLWbL2PJdbWMdaISQHQTWfnrMA8sQyoVsJFTGzqA4T2ZrmxrcW4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xdqo/tuM+H93a5Vrfq3R7Ym67avtHVKPOG8B6QVsYa8=; b=oV42qJwlNi+MDkFn6fuJ106FDnjAe3z2OXp+hFyVWSk/RDLkSMxkzcKNrf4ZRU3+c4XQ6be6FbJjv3ag9/Pn6ZYZQCeJVx4qHSdyolV2iHOnJQVeeYmnHsjzi1UL3suUaBcnj8zXY+goI3mtLatkCVi0y3NdEtmMfAbruir11vWAhQvg72QU+5TM7widiBy4oWiu1GOI2FyYRv3TUDFntqt3AdQtOINtZx0AOyF3ub+0AXs8877KYPxuMDEFRlDB49iP1aUyiiyYK/8Z1bEgbPkP3IjubfFePpPmkhQmyrnr78cV4u8rHpZ1TMSAdb2HYUeZuZHMOOiRWcynq4Ihiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none 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=xdqo/tuM+H93a5Vrfq3R7Ym67avtHVKPOG8B6QVsYa8=; b=aCGJlGJjuEOu5cvq2zutO/mj2FLIt8yjA656a5qQsQSHS/DtzVPI1Xw5OjICGlwQrKpjlAtGiSIAeb8UGBVmCt9eLzOggbLBqHMVlpnysYYRermSGZTyH/SCaVT6QBorUbTVyYqaLW4v/Q4tsCKD90zJPXpXRvDwg4smHL7hyec= Received: from BYAPR11MB3703.namprd11.prod.outlook.com (20.178.206.21) by BYAPR11MB3480.namprd11.prod.outlook.com (20.177.127.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Mon, 17 Feb 2020 15:41:38 +0000 Received: from BYAPR11MB3703.namprd11.prod.outlook.com ([fe80::d8ca:a906:971d:91a9]) by BYAPR11MB3703.namprd11.prod.outlook.com ([fe80::d8ca:a906:971d:91a9%3]) with mapi id 15.20.2729.031; Mon, 17 Feb 2020 15:41:38 +0000 From: "Mahendra Gangaiah (mgangaia)" To: Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: Netconf Query Thread-Index: AdXh3s0tqiJEkMH4RV6lcAAXotuPJwDw7zQAAAB/xpA= Date: Mon, 17 Feb 2020 15:41:38 +0000 Message-ID: References: <20200217.155714.1030215278913591724.mbj@tail-f.com> In-Reply-To: <20200217.155714.1030215278913591724.mbj@tail-f.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=mgangaia@cisco.com; x-originating-ip: [2001:420:c0cc:1008::1b2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9a37682d-ebc4-4874-82bc-08d7b3bfe0e1 x-ms-traffictypediagnostic: BYAPR11MB3480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(346002)(39860400002)(396003)(189003)(199004)(88996005)(2906002)(9686003)(66446008)(66556008)(64756008)(86362001)(66476007)(66946007)(71200400001)(5660300002)(4326008)(7116003)(55016002)(81166006)(81156014)(478600001)(33656002)(186003)(52536014)(6916009)(3480700007)(8936002)(53546011)(316002)(7696005)(8676002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3480; H:BYAPR11MB3703.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: BCL:0; x-microsoft-antispam-message-info: DiT67MFtBicmsYR6jBRDWRRCARfQ6yKBDEMRweq5dW+G5eGt1vElwni+ieyfTQ1gV2CBzhmOm7JOAkHki662HP2xCTWcBlmNB8kp/EV9P7LLy+Zj/kDJHj2UjujdV7Uil6uGPe/GwzrJQtLExV8Cbnumr35qknbWhb5TD3MxF71SyGE6nqgahL7M586cWulfngShxUBOvr1WPmlNyuM6jan3adq53cT9GclxOU/Cl3JKBFpLm1XU5NlQUOSUjq9CUuvFAbPbllkmiwGM84bxcwdFykF+0NILgv7lO/nOnQ9KA6pvGCmlXZNcL9tbDKQUOhSJ89IrDwf7d87QGQx+wekGaT3RLdl7vdgML04/a/bMBY2gYkjTw9fZVpC9ifENI/4AbTzmghJmpfjiAveKQ6sbD0HabBipCad4qokhWP5ezPSZPZ/ETK6rteqHawWA x-ms-exchange-antispam-messagedata: oiruA0USUDVchh6G6X3V2b4rhXfRZTPS0/TXJnJRXbcD7Mc4Ra0BrUg4MH7FtPB6d0K1nZCSDiCkYOkIC+mS5TinaUlUXyIeuN9LLZBR+1ios4g7Q5kLsnW4PGfbwuHTT6VJdlvoZC0Ra0eSmKggS5b2u8MLjR0NDHq1QKBv/Jk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9a37682d-ebc4-4874-82bc-08d7b3bfe0e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 15:41:38.7986 (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-CrossTenant-userprincipalname: YBYJ+BjVlyLCUhXYYs9bQshuU/lQbPWeiM+/PBX5rZ6UYwRrQmNnWA4TonlCd/Q7irmxI4dFsMtFqSPUGmYIbQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3480 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netconf] Netconf Query 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, 17 Feb 2020 15:41:48 -0000 Thanks a lot, Martin. Thanks, Mahendra -----Original Message----- From: Martin Bjorklund =20 Sent: Monday, February 17, 2020 6:57 AM To: Mahendra Gangaiah (mgangaia) Cc: netconf@ietf.org Subject: Re: Netconf Query Hi, "Mahendra Gangaiah (mgangaia)" wrote: > Hi all, >=20 > Can you please help me out with the below query. >=20 > The below netcon payload is intended to create a layer 2 trunk port=20 > and add allowed vlans 10 to 20 on that interface >=20 > > > > > > > > eth1/10 > > > > TRUNK > 10..20 > > > > > > > >=20 >=20 > Based on the yang model definition, trunk-vlans is defined as below. >=20 >=20 > leaf-list trunk-vlans { > when "../interface-mode =3D 'TRUNK'" { > description > "Allowed VLANs may be specified for trunk mode > interfaces."; > } >=20 > Question: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > When the above payload is pushed using netconf, Does the expression in=20 > the when statement defined in the model for an object refers to data=20 > in the datastore context, or data in the request context or can be=20 > either. > Can the netconf request include both the change to the configuration=20 > that satisfies the when expression and changes to elements that are=20 > enabled by that same when expression ? > Should the above payload work ? Yes it should work; the request sets the interface-mode to "TRUNK" which makes 'trunk-vlans' valid. /martin From nobody Mon Feb 17 18:51:57 2020 Return-Path: <01000170556f2468-74e59d0f-1ce8-4ddb-8781-c1f4cb56074c-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 C2905120048 for ; Mon, 17 Feb 2020 15:15:16 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rq0rARl9vadl for ; Mon, 17 Feb 2020 15:15:13 -0800 (PST) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D889120041 for ; Mon, 17 Feb 2020 15:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581981312; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=7bRDAFoqXFbvwUod0M6BXy15BNtA2Q8bsNFOAo8fTSY=; b=agyzXwRbc1Be9JHaJwt/jVFys38OPczK77V3qkNoIKZ1lygnaP0nmrIcrjxhmHyk 4PAc/CLST0OHs8mvUHR1NsB84ZERPWlUaqwCrpOWwGn7M6RK5rAApcKQYb3FqNZcZ1F CLLtqUk+u3nFg4syedueqAg8KYmnVFeSSeVyWhN4= From: Kent Watsen Message-ID: <01000170556f2468-74e59d0f-1ce8-4ddb-8781-c1f4cb56074c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_979A536D-B036-4302-92F0-CC02C5B98B7C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 17 Feb 2020 23:15:12 +0000 In-Reply-To: <01000170413b5d79-04146888-12f6-4fbd-9890-5869d242f453-000000@email.amazonses.com> Cc: "netconf@ietf.org" To: "Salz, Rich" References: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com> <3F865F3D-EEA6-4DAB-A1B3-7062C8496E4B@akamai.com> <01000170413b5d79-04146888-12f6-4fbd-9890-5869d242f453-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.17-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Supported algorithms lists 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, 17 Feb 2020 23:15:17 -0000 --Apple-Mail=_979A536D-B036-4302-92F0-CC02C5B98B7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, TL;RD;, I=E2=80=99m back to thinking that the RPCs are best. See below for an addendum. Kent // contributor > On Feb 13, 2020, at 8:06 PM, Kent Watsen wrote: >=20 >=20 > Hi Rich, good to see you=E2=80=99re keeping us honest here ;) >=20 >>> it suggests a 3rd idea, which is to have an RPC that takes an XPath = (to a key) and returns the list of supported algorithms for that key. >>=20 >> I could be confused, but I don't know if this is a good idea. = Suppose I have an RSA keypair; would I expect to get back every TLS 1.2 = ciphersuite name that has RSA in it? There are around 30. And for TLS = 1.3, where the identity is broken out separately from the bulk = encryption -- the so-called "a la carte" approach -- it becomes rather = difficult. >=20 > That=E2=80=99s not quite what I had envisioned, but you may be onto = something nonetheless. >=20 > Regarding the proposed idea, first note that the intent is that the = desire to know what algorithms are supported is mostly to either 1) ask = the device to generate and key or 2) know what kind of key could be = generated offline and subsequently loaded onto the device. In either = case, it=E2=80=99s not so much that you *have* an RSA keypair, but that = you wish to generate a one. >=20 > To give a concrete example, assume the data model illustrated by tree = diagram here: = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-17#a= ppendix-A.2 = . The RPC might be: >=20 > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > = /restconf-server/listen/endpoint/transport/https/tls-server-parameters/ser= ver-identty/... > > > >=20 > So it=E2=80=99s clear that the intent that the key is intended for TLS = (not SSH). That said, and to your point, it doesn=E2=80=99t indicate if = for TLS 1.2 or 1.3 and, worse, if the path instead references a keystore = path (e.g., /keystore/asymmetric-keys/asymmetic-key/=E2=80=A6), it=E2=80=99= s not even clear that the key is intended for TLS or SSH=E2=80=A6 Regarding the algorithms being protocol sensitive (e.g., 1.2 vs 1.3), in = lieu of not finding a way to do this in CLI, this appears to be a = non-issue. Regarding XPaths pointing to keys in Keystore, we need only declare them = as unsupported (i.e., an error should be returned). While the key MAY = be configured to Keystore, the important part is to know where it is = *used* (i.e., the XPath would be to a leafref pointing to the Keystore = elsewhere in the configuration, per the original response above). Note that misconfigurations are still possible. For instance, someone = could point a leafref to an already created yet incompatible key in the = keystore. It is expected that errors arising from such = incompatibilities would be detected when the configuration is = applied/committed. PS: I=E2=80=99m preparing a multi-draft update that will include this = idea (and every other discussed since IETF 106). This update will most = likely be used for the first WGLC on the three foundational = client-server suite of drafts (i.e., crypto-types, keystore, and = truststore). So, if any objections, please shout out now. Kent // contributor >=20 > In contrast, the current/planned/old approach described in my previous = message, whereby there would be a list per protocol (TLS vs SSH), also = did not take into account protocol versions (1.2 vs 1.3). So, if this = is an issue, we have no proposal addressing it yet... >=20 > How does OpenSSL CLI support this? Looking at `openssl ciphers`, I = see that it=E2=80=99s possible to specific protocol versions (i.e., 1.2, = 1.3, etc.). But, in the end, these are cipher suites (e.g., = ECDHE-RSA-AES128-GCM-SHA256), not just the algorithm (RSA) and = definitely not indicating supported key lengths (presumable all RSA key = lengths are supported?)... >=20 > It would help if we could identify the CLI-equivalent for all this=E2=80= =A6 >=20 > PS: both the SSH and TLS client-server draft create mapping tables = between the protocol-specific cipher-suite names and to the algorithm = names in crypto-types. For instance, here are the mapping tables for = TLS: = https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#sectio= n-5 = . >=20 > PPS: I=E2=80=99m beginning to think that we might be better giving up = on having any RPC to ask the server to generate keys or indicate which = algorithms are supported, punting all this complexity to some future = revision. That said, it would be best is we could get something = passable working now, if possible... >=20 > Thanks, > Kent. // contributor >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_979A536D-B036-4302-92F0-CC02C5B98B7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
All,

TL;RD;, I=E2=80=99= m back to thinking that the RPCs are best.

See below for an addendum.

Kent  // contributor


On Feb 13, 2020, at 8:06 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:


Hi Rich,  good to see you=E2=80=99re= keeping us honest here ;)

it suggests a 3rd idea, which is to have an RPC = that takes an XPath (to a key) and returns the list of supported = algorithms for that key.

I = could be confused, but I don't know if this is a good idea. =  Suppose I have an RSA keypair; would I expect to get back every = TLS 1.2 ciphersuite name that has RSA in it?  There are around 30. =  And for TLS 1.3, where the identity is broken out separately from = the bulk encryption -- the so-called "a la carte" approach -- it becomes = rather difficult.

That=E2=80=99s not quite what I had = envisioned, but you may be onto something nonetheless.

Regarding the proposed = idea, first note that the intent is that the desire to know what = algorithms are supported is mostly to either 1) ask the device to = generate and key or 2) know what kind of key could be generated offline = and subsequently loaded onto the device.  In either case, it=E2=80=99= s not so much that you *have* an RSA keypair, but that you wish to = generate a one.

To give a concrete example, assume the data model illustrated = by tree diagram here: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-= server-17#appendix-A.2.  The RPC might be:

 <rpc message-id=3D"101"
  =   =  xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
     <get-supported-algorithms = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-crypto-types>
       <schema-path>
          = /restconf-server/listen/endpoint/transport/https/tls-server-parameters/ser= ver-identty/...
      =  </schema-path>
  =    </get-supported-algorithms>
   </rpc>

So it=E2=80=99s clear that the intent = that the key is intended for TLS (not SSH).  That said, and to your = point, it doesn=E2=80=99t indicate if for TLS 1.2 or 1.3 and, worse, if = the path instead references a keystore path (e.g., = /keystore/asymmetric-keys/asymmetic-key/=E2=80=A6), it=E2=80=99s not = even clear that the key is intended for TLS or = SSH=E2=80=A6


Regarding the algorithms = being protocol sensitive (e.g., 1.2 vs 1.3), in lieu of not finding a = way to do this in CLI, this appears to be a non-issue.

Regarding XPaths pointing to keys in Keystore, we = need only declare them as unsupported (i.e., an error should be = returned).  While the key MAY be configured to Keystore, the = important part is to know where it is *used* (i.e., the XPath would be = to a leafref pointing to the Keystore elsewhere in the configuration, = per the original response above).

Note= that misconfigurations are still possible.  For instance, someone = could point a leafref to an already created yet incompatible key in the = keystore.  It is expected that errors arising from such = incompatibilities would be detected when the configuration is = applied/committed.

PS: I=E2=80=99m = preparing a multi-draft update that will include this idea (and every = other discussed since IETF 106).  This update will most likely be = used for the first WGLC on the three foundational client-server suite of = drafts (i.e., crypto-types, keystore, and truststore).  So, if any = objections, please shout out now.

Kent= // contributor



In contrast, the current/planned/old approach described in my = previous message, whereby there would be a list per protocol (TLS vs = SSH), also did not take into account protocol versions (1.2 vs 1.3). =  So, if this is an issue, we have no proposal addressing it = yet...

How = does OpenSSL CLI support this?  Looking at `openssl ciphers`, I see = that it=E2=80=99s possible to specific protocol versions (i.e., 1.2, = 1.3, etc.).   But, in the end, these are cipher suites (e.g., = ECDHE-RSA-AES128-GCM-SHA256), not just the algorithm (RSA) and = definitely not indicating supported key lengths (presumable all RSA key = lengths are supported?)...

It would help if we could identify the CLI-equivalent for all = this=E2=80=A6

PS: both the SSH and TLS client-server draft create mapping = tables between the protocol-specific cipher-suite names and to the = algorithm names in crypto-types.  For instance, here are the = mapping tables for TLS: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-serve= r-17#section-5.

PPS: I=E2=80=99m beginning to think that we might be better = giving up on having any RPC to ask the server to generate keys or = indicate which algorithms are supported, punting all this complexity to = some future revision.  That said, it would be best is we could get = something passable working now, if possible...

Thanks,
Kent. // = contributor





_____________________________________________= __
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_979A536D-B036-4302-92F0-CC02C5B98B7C-- From nobody Mon Feb 17 18:52:17 2020 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 2B889120048 for ; Mon, 17 Feb 2020 15:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwV8L6J29vZz for ; Mon, 17 Feb 2020 15:24:17 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84153120041 for ; Mon, 17 Feb 2020 15:24:17 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 01HNFF5x031932; Mon, 17 Feb 2020 23:24:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=U0wSebWDiv07LtB85M3CdHDrmLkPx29e0J17PFpq4qI=; b=W6mS0j5T9PAo+x+sxWx600GaSQi4/hbgv3d+7slLjcT+UjiR2d2nxoGqxSh8n2z9B4ZQ 4nVvxBZ1FAkJ4KbaqXAUbAT41ujbOe43U0lIvWYaxmIiUqBE1uAoXkpP4GNQPQoWdo62 6Z6VFbYWAncNwBgSULchjVjV62rCUVEf0rAP1aH8mq2ncKCq2XYXsWVdXb3vHiiW5Y4y YCgX+kPxgd3cUUxEV1dd3eOjJ8XumHM8bIblMUXH4Yfz+s0SfuuH8wcrwBrhAo6hbfRU sfjPBZuF4wIcKUfmB+zSbOHhYHEdk44QFQBrWe1zXl2Lqxt3Fjq/FnB4nqEHUA+7s/yY qQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2y6yeg6quf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 23:24:17 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01HNHVCZ022901; Mon, 17 Feb 2020 18:24:15 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2y6cv072rh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 18:24:15 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Feb 2020 18:24:14 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Mon, 17 Feb 2020 18:24:14 -0500 From: "Salz, Rich" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Supported algorithms lists Thread-Index: AQHV4pJRGz8wjkufPEeULUGrOkBPq6gZdz2AgAC9VwCABipOAP//rrOA Date: Mon, 17 Feb 2020 23:24:13 +0000 Message-ID: References: <010001703f93981f-3ee1e05a-fa24-41c4-a168-f66af7d4176f-000000@email.amazonses.com> <3F865F3D-EEA6-4DAB-A1B3-7062C8496E4B@akamai.com> <01000170413b5d79-04146888-12f6-4fbd-9890-5869d242f453-000000@email.amazonses.com> <01000170556f2468-74e59d0f-1ce8-4ddb-8781-c1f4cb56074c-000000@email.amazonses.com> In-Reply-To: <01000170556f2468-74e59d0f-1ce8-4ddb-8781-c1f4cb56074c-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.80] Content-Type: multipart/alternative; boundary="_000_A6BFFEFD57D843EDBA3F1D9B872C2FEEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-17_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002170191 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-17_14:2020-02-17, 2020-02-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002170191 Archived-At: Subject: Re: [netconf] Supported algorithms lists 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, 17 Feb 2020 23:24:20 -0000 --_000_A6BFFEFD57D843EDBA3F1D9B872C2FEEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va2luZyBmb3J3YXJkcyB0byByZWFkaW5nIHRoZSBuZXcgZG9jcy4NCg0KRnJvbTogS2VudCBX YXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSAxNywg MjAyMCBhdCA2OjE3IFBNDQpUbzogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPg0KQ2M6ICJu ZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0Y29u Zl0gU3VwcG9ydGVkIGFsZ29yaXRobXMgbGlzdHMNCg0KQWxsLA0KDQpUTDtSRDssIEnigJltIGJh Y2sgdG8gdGhpbmtpbmcgdGhhdCB0aGUgUlBDcyBhcmUgYmVzdC4NCg0KU2VlIGJlbG93IGZvciBh biBhZGRlbmR1bS4NCg0KS2VudCAgLy8gY29udHJpYnV0b3INCg0KDQoNCk9uIEZlYiAxMywgMjAy MCwgYXQgODowNiBQTSwgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzpr ZW50K2lldGZAd2F0c2VuLm5ldD4+IHdyb3RlOg0KDQoNCkhpIFJpY2gsICBnb29kIHRvIHNlZSB5 b3XigJlyZSBrZWVwaW5nIHVzIGhvbmVzdCBoZXJlIDspDQoNCml0IHN1Z2dlc3RzIGEgM3JkIGlk ZWEsIHdoaWNoIGlzIHRvIGhhdmUgYW4gUlBDIHRoYXQgdGFrZXMgYW4gWFBhdGggKHRvIGEga2V5 KSBhbmQgcmV0dXJucyB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgYWxnb3JpdGhtcyBmb3IgdGhhdCBr ZXkuDQoNCkkgY291bGQgYmUgY29uZnVzZWQsIGJ1dCBJIGRvbid0IGtub3cgaWYgdGhpcyBpcyBh IGdvb2QgaWRlYS4gIFN1cHBvc2UgSSBoYXZlIGFuIFJTQSBrZXlwYWlyOyB3b3VsZCBJIGV4cGVj dCB0byBnZXQgYmFjayBldmVyeSBUTFMgMS4yIGNpcGhlcnN1aXRlIG5hbWUgdGhhdCBoYXMgUlNB IGluIGl0PyAgVGhlcmUgYXJlIGFyb3VuZCAzMC4gIEFuZCBmb3IgVExTIDEuMywgd2hlcmUgdGhl IGlkZW50aXR5IGlzIGJyb2tlbiBvdXQgc2VwYXJhdGVseSBmcm9tIHRoZSBidWxrIGVuY3J5cHRp b24gLS0gdGhlIHNvLWNhbGxlZCAiYSBsYSBjYXJ0ZSIgYXBwcm9hY2ggLS0gaXQgYmVjb21lcyBy YXRoZXIgZGlmZmljdWx0Lg0KDQpUaGF04oCZcyBub3QgcXVpdGUgd2hhdCBJIGhhZCBlbnZpc2lv bmVkLCBidXQgeW91IG1heSBiZSBvbnRvIHNvbWV0aGluZyBub25ldGhlbGVzcy4NCg0KUmVnYXJk aW5nIHRoZSBwcm9wb3NlZCBpZGVhLCBmaXJzdCBub3RlIHRoYXQgdGhlIGludGVudCBpcyB0aGF0 IHRoZSBkZXNpcmUgdG8ga25vdyB3aGF0IGFsZ29yaXRobXMgYXJlIHN1cHBvcnRlZCBpcyBtb3N0 bHkgdG8gZWl0aGVyIDEpIGFzayB0aGUgZGV2aWNlIHRvIGdlbmVyYXRlIGFuZCBrZXkgb3IgMikg a25vdyB3aGF0IGtpbmQgb2Yga2V5IGNvdWxkIGJlIGdlbmVyYXRlZCBvZmZsaW5lIGFuZCBzdWJz ZXF1ZW50bHkgbG9hZGVkIG9udG8gdGhlIGRldmljZS4gIEluIGVpdGhlciBjYXNlLCBpdOKAmXMg bm90IHNvIG11Y2ggdGhhdCB5b3UgKmhhdmUqIGFuIFJTQSBrZXlwYWlyLCBidXQgdGhhdCB5b3Ug d2lzaCB0byBnZW5lcmF0ZSBhIG9uZS4NCg0KVG8gZ2l2ZSBhIGNvbmNyZXRlIGV4YW1wbGUsIGFz c3VtZSB0aGUgZGF0YSBtb2RlbCBpbGx1c3RyYXRlZCBieSB0cmVlIGRpYWdyYW0gaGVyZTogaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1jbGll bnQtc2VydmVyLTE3I2FwcGVuZGl4LUEuMjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJE bmV0Y29uZi0yRHJlc3Rjb25mLTJEY2xpZW50LTJEc2VydmVyLTJEMTctMjNhcHBlbmRpeC0yREEu MiZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNL SS13Jm09R0JkUndYTF9qdEtia1F2bG52MzR5a2kxUEZVS3QwYjVOSmRDRFFGZHVTMCZzPXVQOE1S OFVrd29ybFFjMWhVd2VzbHBQd0NoNnoxTHd5SEN3d0V4U0dSbE0mZT0+LiAgVGhlIFJQQyBtaWdo dCBiZToNCg0KIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgICAgPGdldC1zdXBwb3J0ZWQtYWxnb3Jp dGhtcyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtY3J5cHRvLXR5cGVz Pg0KICAgICAgIDxzY2hlbWEtcGF0aD4NCiAgICAgICAgICAvcmVzdGNvbmYtc2VydmVyL2xpc3Rl bi9lbmRwb2ludC90cmFuc3BvcnQvaHR0cHMvdGxzLXNlcnZlci1wYXJhbWV0ZXJzL3NlcnZlci1p ZGVudHR5Ly4uLg0KICAgICAgIDwvc2NoZW1hLXBhdGg+DQogICAgIDwvZ2V0LXN1cHBvcnRlZC1h bGdvcml0aG1zPg0KICAgPC9ycGM+DQoNClNvIGl04oCZcyBjbGVhciB0aGF0IHRoZSBpbnRlbnQg dGhhdCB0aGUga2V5IGlzIGludGVuZGVkIGZvciBUTFMgKG5vdCBTU0gpLiAgVGhhdCBzYWlkLCBh bmQgdG8geW91ciBwb2ludCwgaXQgZG9lc27igJl0IGluZGljYXRlIGlmIGZvciBUTFMgMS4yIG9y IDEuMyBhbmQsIHdvcnNlLCBpZiB0aGUgcGF0aCBpbnN0ZWFkIHJlZmVyZW5jZXMgYSBrZXlzdG9y ZSBwYXRoIChlLmcuLCAva2V5c3RvcmUvYXN5bW1ldHJpYy1rZXlzL2FzeW1tZXRpYy1rZXkv4oCm KSwgaXTigJlzIG5vdCBldmVuIGNsZWFyIHRoYXQgdGhlIGtleSBpcyBpbnRlbmRlZCBmb3IgVExT IG9yIFNTSOKApg0KDQoNClJlZ2FyZGluZyB0aGUgYWxnb3JpdGhtcyBiZWluZyBwcm90b2NvbCBz ZW5zaXRpdmUgKGUuZy4sIDEuMiB2cyAxLjMpLCBpbiBsaWV1IG9mIG5vdCBmaW5kaW5nIGEgd2F5 IHRvIGRvIHRoaXMgaW4gQ0xJLCB0aGlzIGFwcGVhcnMgdG8gYmUgYSBub24taXNzdWUuDQoNClJl Z2FyZGluZyBYUGF0aHMgcG9pbnRpbmcgdG8ga2V5cyBpbiBLZXlzdG9yZSwgd2UgbmVlZCBvbmx5 IGRlY2xhcmUgdGhlbSBhcyB1bnN1cHBvcnRlZCAoaS5lLiwgYW4gZXJyb3Igc2hvdWxkIGJlIHJl dHVybmVkKS4gIFdoaWxlIHRoZSBrZXkgTUFZIGJlIGNvbmZpZ3VyZWQgdG8gS2V5c3RvcmUsIHRo ZSBpbXBvcnRhbnQgcGFydCBpcyB0byBrbm93IHdoZXJlIGl0IGlzICp1c2VkKiAoaS5lLiwgdGhl IFhQYXRoIHdvdWxkIGJlIHRvIGEgbGVhZnJlZiBwb2ludGluZyB0byB0aGUgS2V5c3RvcmUgZWxz ZXdoZXJlIGluIHRoZSBjb25maWd1cmF0aW9uLCBwZXIgdGhlIG9yaWdpbmFsIHJlc3BvbnNlIGFi b3ZlKS4NCg0KTm90ZSB0aGF0IG1pc2NvbmZpZ3VyYXRpb25zIGFyZSBzdGlsbCBwb3NzaWJsZS4g IEZvciBpbnN0YW5jZSwgc29tZW9uZSBjb3VsZCBwb2ludCBhIGxlYWZyZWYgdG8gYW4gYWxyZWFk eSBjcmVhdGVkIHlldCBpbmNvbXBhdGlibGUga2V5IGluIHRoZSBrZXlzdG9yZS4gIEl0IGlzIGV4 cGVjdGVkIHRoYXQgZXJyb3JzIGFyaXNpbmcgZnJvbSBzdWNoIGluY29tcGF0aWJpbGl0aWVzIHdv dWxkIGJlIGRldGVjdGVkIHdoZW4gdGhlIGNvbmZpZ3VyYXRpb24gaXMgYXBwbGllZC9jb21taXR0 ZWQuDQoNClBTOiBJ4oCZbSBwcmVwYXJpbmcgYSBtdWx0aS1kcmFmdCB1cGRhdGUgdGhhdCB3aWxs IGluY2x1ZGUgdGhpcyBpZGVhIChhbmQgZXZlcnkgb3RoZXIgZGlzY3Vzc2VkIHNpbmNlIElFVEYg MTA2KS4gIFRoaXMgdXBkYXRlIHdpbGwgbW9zdCBsaWtlbHkgYmUgdXNlZCBmb3IgdGhlIGZpcnN0 IFdHTEMgb24gdGhlIHRocmVlIGZvdW5kYXRpb25hbCBjbGllbnQtc2VydmVyIHN1aXRlIG9mIGRy YWZ0cyAoaS5lLiwgY3J5cHRvLXR5cGVzLCBrZXlzdG9yZSwgYW5kIHRydXN0c3RvcmUpLiAgU28s IGlmIGFueSBvYmplY3Rpb25zLCBwbGVhc2Ugc2hvdXQgb3V0IG5vdy4NCg0KS2VudCAvLyBjb250 cmlidXRvcg0KDQoNCg0KDQpJbiBjb250cmFzdCwgdGhlIGN1cnJlbnQvcGxhbm5lZC9vbGQgYXBw cm9hY2ggZGVzY3JpYmVkIGluIG15IHByZXZpb3VzIG1lc3NhZ2UsIHdoZXJlYnkgdGhlcmUgd291 bGQgYmUgYSBsaXN0IHBlciBwcm90b2NvbCAoVExTIHZzIFNTSCksIGFsc28gZGlkIG5vdCB0YWtl IGludG8gYWNjb3VudCBwcm90b2NvbCB2ZXJzaW9ucyAoMS4yIHZzIDEuMykuICBTbywgaWYgdGhp cyBpcyBhbiBpc3N1ZSwgd2UgaGF2ZSBubyBwcm9wb3NhbCBhZGRyZXNzaW5nIGl0IHlldC4uLg0K DQpIb3cgZG9lcyBPcGVuU1NMIENMSSBzdXBwb3J0IHRoaXM/ICBMb29raW5nIGF0IGBvcGVuc3Ns IGNpcGhlcnNgLCBJIHNlZSB0aGF0IGl04oCZcyBwb3NzaWJsZSB0byBzcGVjaWZpYyBwcm90b2Nv bCB2ZXJzaW9ucyAoaS5lLiwgMS4yLCAxLjMsIGV0Yy4pLiAgIEJ1dCwgaW4gdGhlIGVuZCwgdGhl c2UgYXJlIGNpcGhlciBzdWl0ZXMgKGUuZy4sIEVDREhFLVJTQS1BRVMxMjgtR0NNLVNIQTI1Niks IG5vdCBqdXN0IHRoZSBhbGdvcml0aG0gKFJTQSkgYW5kIGRlZmluaXRlbHkgbm90IGluZGljYXRp bmcgc3VwcG9ydGVkIGtleSBsZW5ndGhzIChwcmVzdW1hYmxlIGFsbCBSU0Ega2V5IGxlbmd0aHMg YXJlIHN1cHBvcnRlZD8pLi4uDQoNCkl0IHdvdWxkIGhlbHAgaWYgd2UgY291bGQgaWRlbnRpZnkg dGhlIENMSS1lcXVpdmFsZW50IGZvciBhbGwgdGhpc+KApg0KDQpQUzogYm90aCB0aGUgU1NIIGFu ZCBUTFMgY2xpZW50LXNlcnZlciBkcmFmdCBjcmVhdGUgbWFwcGluZyB0YWJsZXMgYmV0d2VlbiB0 aGUgcHJvdG9jb2wtc3BlY2lmaWMgY2lwaGVyLXN1aXRlIG5hbWVzIGFuZCB0byB0aGUgYWxnb3Jp dGhtIG5hbWVzIGluIGNyeXB0by10eXBlcy4gIEZvciBpbnN0YW5jZSwgaGVyZSBhcmUgdGhlIG1h cHBpbmcgdGFibGVzIGZvciBUTFM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGNvbmYtdGxzLWNsaWVudC1zZXJ2ZXItMTcjc2VjdGlvbi01PGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9kcmFmdC0yRGlldGYtMkRuZXRjb25mLTJEdGxzLTJEY2xpZW50LTJEc2VydmVyLTJEMTctMjNz ZWN0aW9uLTJENSZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5 RnZ4ODZGdHNLSS13Jm09R0JkUndYTF9qdEtia1F2bG52MzR5a2kxUEZVS3QwYjVOSmRDRFFGZHVT MCZzPW5nRUhULW5kRWxKalVCNzZ6dXQzY3RjX1dUTzV3WWVja1hGX0FVRHBhOXMmZT0+Lg0KDQpQ UFM6IEnigJltIGJlZ2lubmluZyB0byB0aGluayB0aGF0IHdlIG1pZ2h0IGJlIGJldHRlciBnaXZp bmcgdXAgb24gaGF2aW5nIGFueSBSUEMgdG8gYXNrIHRoZSBzZXJ2ZXIgdG8gZ2VuZXJhdGUga2V5 cyBvciBpbmRpY2F0ZSB3aGljaCBhbGdvcml0aG1zIGFyZSBzdXBwb3J0ZWQsIHB1bnRpbmcgYWxs IHRoaXMgY29tcGxleGl0eSB0byBzb21lIGZ1dHVyZSByZXZpc2lvbi4gIFRoYXQgc2FpZCwgaXQg d291bGQgYmUgYmVzdCBpcyB3ZSBjb3VsZCBnZXQgc29tZXRoaW5nIHBhc3NhYmxlIHdvcmtpbmcg bm93LCBpZiBwb3NzaWJsZS4uLg0KDQpUaGFua3MsDQpLZW50LiAvLyBjb250cmlidXRvcg0KDQoN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpu ZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQoN Cg== --_000_A6BFFEFD57D843EDBA3F1D9B872C2FEEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2536FEB8255140458C279BBDB773B638@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TG9va2luZyBmb3J3YXJkcyB0byByZWFkaW5nIHRoZSBuZXcgZG9jcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPktlbnQgV2F0c2VuICZs dDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwg RmVicnVhcnkgMTcsIDIwMjAgYXQgNjoxNyBQTTxicj4NCjxiPlRvOiA8L2I+UmljaCBTYWx6ICZs dDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7bmV0Y29uZkBpZXRm Lm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtuZXRjb25mXSBTdXBwb3J0ZWQgYWxnb3JpdGhtcyBsaXN0czxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UTDtSRDssIEni gJltIGJhY2sgdG8gdGhpbmtpbmcgdGhhdCB0aGUgUlBDcyBhcmUgYmVzdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlIGJlbG93IGZvciBh biBhZGRlbmR1bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+S2VudCAmbmJzcDsvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAxMywgMjAyMCwgYXQgODow NiBQTSwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JiM0MztpZXRmQHdhdHNl bi5uZXQiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmljaCwgJm5i c3A7Z29vZCB0byBzZWUgeW914oCZcmUga2VlcGluZyB1cyBob25lc3QgaGVyZSA7KTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCBzdWdn ZXN0cyBhIDNyZCBpZGVhLCB3aGljaCBpcyB0byBoYXZlIGFuIFJQQyB0aGF0IHRha2VzIGFuIFhQ YXRoICh0byBhIGtleSkgYW5kIHJldHVybnMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIGFsZ29yaXRo bXMgZm9yIHRoYXQga2V5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KSSBjb3VsZCBiZSBjb25mdXNlZCwgYnV0IEkgZG9uJ3Qga25vdyBp ZiB0aGlzIGlzIGEgZ29vZCBpZGVhLiAmbmJzcDtTdXBwb3NlIEkgaGF2ZSBhbiBSU0Ega2V5cGFp cjsgd291bGQgSSBleHBlY3QgdG8gZ2V0IGJhY2sgZXZlcnkgVExTIDEuMiBjaXBoZXJzdWl0ZSBu YW1lIHRoYXQgaGFzIFJTQSBpbiBpdD8gJm5ic3A7VGhlcmUgYXJlIGFyb3VuZCAzMC4gJm5ic3A7 QW5kIGZvciBUTFMgMS4zLCB3aGVyZSB0aGUgaWRlbnRpdHkgaXMgYnJva2VuIG91dCBzZXBhcmF0 ZWx5IGZyb20NCiB0aGUgYnVsayBlbmNyeXB0aW9uIC0tIHRoZSBzby1jYWxsZWQgJnF1b3Q7YSBs YSBjYXJ0ZSZxdW90OyBhcHByb2FjaCAtLSBpdCBiZWNvbWVzIHJhdGhlciBkaWZmaWN1bHQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGF04oCZcyBub3QgcXVpdGUgd2hhdCBJIGhhZCBlbnZpc2lvbmVkLCBidXQg eW91IG1heSBiZSBvbnRvIHNvbWV0aGluZyBub25ldGhlbGVzcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBwcm9wb3Nl ZCBpZGVhLCBmaXJzdCBub3RlIHRoYXQgdGhlIGludGVudCBpcyB0aGF0IHRoZSBkZXNpcmUgdG8g a25vdyB3aGF0IGFsZ29yaXRobXMgYXJlIHN1cHBvcnRlZCBpcyBtb3N0bHkgdG8gZWl0aGVyIDEp IGFzayB0aGUgZGV2aWNlIHRvIGdlbmVyYXRlIGFuZCBrZXkgb3IgMikga25vdyB3aGF0IGtpbmQg b2Yga2V5IGNvdWxkIGJlIGdlbmVyYXRlZCBvZmZsaW5lIGFuZCBzdWJzZXF1ZW50bHkNCiBsb2Fk ZWQgb250byB0aGUgZGV2aWNlLiAmbmJzcDtJbiBlaXRoZXIgY2FzZSwgaXTigJlzIG5vdCBzbyBt dWNoIHRoYXQgeW91ICpoYXZlKiBhbiBSU0Ega2V5cGFpciwgYnV0IHRoYXQgeW91IHdpc2ggdG8g Z2VuZXJhdGUgYSBvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvIGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlLCBhc3N1bWUgdGhlIGRhdGEg bW9kZWwgaWxsdXN0cmF0ZWQgYnkgdHJlZSBkaWFncmFtIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRyZXN0Y29uZi0yRGNsaWVudC0y RHNlcnZlci0yRDE3LTIzYXBwZW5kaXgtMkRBLjImYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNh TUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1HQmRSd1hM X2p0S2JrUXZsbnYzNHlraTFQRlVLdDBiNU5KZENEUUZkdVMwJmFtcDtzPXVQOE1SOFVrd29ybFFj MWhVd2VzbHBQd0NoNnoxTHd5SEN3d0V4U0dSbE0mYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLWNsaWVudC1zZXJ2ZXItMTcjYXBw ZW5kaXgtQS4yPC9hPi4NCiAmbmJzcDtUaGUgUlBDIG1pZ2h0IGJlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jmx0O3Jw YyBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxucz0mcXVvdDt1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDtnZXQtc3VwcG9ydGVkLWFsZ29yaXRobXMgeG1sbnM9JnF1b3Q7dXJuOmlldGY6 cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtY3J5cHRvLXR5cGVzJmd0OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmx0O3NjaGVtYS1wYXRoJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAv cmVzdGNvbmYtc2VydmVyL2xpc3Rlbi9lbmRwb2ludC90cmFuc3BvcnQvaHR0cHMvdGxzLXNlcnZl ci1wYXJhbWV0ZXJzL3NlcnZlci1pZGVudHR5Ly4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 Oy9zY2hlbWEtcGF0aCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZ2V0LXN1cHBvcnRl ZC1hbGdvcml0aG1zJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jmx0Oy9ycGMmZ3Q7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGl04oCZcyBjbGVh ciB0aGF0IHRoZSBpbnRlbnQgdGhhdCB0aGUga2V5IGlzIGludGVuZGVkIGZvciBUTFMgKG5vdCBT U0gpLiAmbmJzcDtUaGF0IHNhaWQsIGFuZCB0byB5b3VyIHBvaW50LCBpdCBkb2VzbuKAmXQgaW5k aWNhdGUgaWYgZm9yIFRMUyAxLjIgb3IgMS4zIGFuZCwgd29yc2UsIGlmIHRoZSBwYXRoIGluc3Rl YWQgcmVmZXJlbmNlcyBhIGtleXN0b3JlIHBhdGggKGUuZy4sIC9rZXlzdG9yZS9hc3ltbWV0cmlj LWtleXMvYXN5bW1ldGljLWtleS/igKYpLA0KIGl04oCZcyBub3QgZXZlbiBjbGVhciB0aGF0IHRo ZSBrZXkgaXMgaW50ZW5kZWQgZm9yIFRMUyBvciBTU0jigKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgdGhlIGFsZ29yaXRobXMgYmVpbmcgcHJvdG9jb2wg c2Vuc2l0aXZlIChlLmcuLCAxLjIgdnMgMS4zKSwgaW4gbGlldSBvZiBub3QgZmluZGluZyBhIHdh eSB0byBkbyB0aGlzIGluIENMSSwgdGhpcyBhcHBlYXJzIHRvIGJlIGEgbm9uLWlzc3VlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRp bmcgWFBhdGhzIHBvaW50aW5nIHRvIGtleXMgaW4gS2V5c3RvcmUsIHdlIG5lZWQgb25seSBkZWNs YXJlIHRoZW0gYXMgdW5zdXBwb3J0ZWQgKGkuZS4sIGFuIGVycm9yIHNob3VsZCBiZSByZXR1cm5l ZCkuICZuYnNwO1doaWxlIHRoZSBrZXkgTUFZIGJlIGNvbmZpZ3VyZWQgdG8gS2V5c3RvcmUsIHRo ZSBpbXBvcnRhbnQgcGFydCBpcyB0byBrbm93IHdoZXJlIGl0IGlzICp1c2VkKiAoaS5lLiwgdGhl IFhQYXRoDQogd291bGQgYmUgdG8gYSBsZWFmcmVmIHBvaW50aW5nIHRvIHRoZSBLZXlzdG9yZSBl bHNld2hlcmUgaW4gdGhlIGNvbmZpZ3VyYXRpb24sIHBlciB0aGUgb3JpZ2luYWwgcmVzcG9uc2Ug YWJvdmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ob3RlIHRoYXQgbWlzY29uZmlndXJhdGlvbnMgYXJlIHN0aWxsIHBvc3NpYmxlLiAmbmJz cDtGb3IgaW5zdGFuY2UsIHNvbWVvbmUgY291bGQgcG9pbnQgYSBsZWFmcmVmIHRvIGFuIGFscmVh ZHkgY3JlYXRlZCB5ZXQgaW5jb21wYXRpYmxlIGtleSBpbiB0aGUga2V5c3RvcmUuICZuYnNwO0l0 IGlzIGV4cGVjdGVkIHRoYXQgZXJyb3JzIGFyaXNpbmcgZnJvbSBzdWNoIGluY29tcGF0aWJpbGl0 aWVzIHdvdWxkIGJlIGRldGVjdGVkIHdoZW4NCiB0aGUgY29uZmlndXJhdGlvbiBpcyBhcHBsaWVk L2NvbW1pdHRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UFM6IEnigJltIHByZXBhcmluZyBhIG11bHRpLWRyYWZ0IHVwZGF0ZSB0aGF0IHdp bGwgaW5jbHVkZSB0aGlzIGlkZWEgKGFuZCBldmVyeSBvdGhlciBkaXNjdXNzZWQgc2luY2UgSUVU RiAxMDYpLiAmbmJzcDtUaGlzIHVwZGF0ZSB3aWxsIG1vc3QgbGlrZWx5IGJlIHVzZWQgZm9yIHRo ZSBmaXJzdCBXR0xDIG9uIHRoZSB0aHJlZSBmb3VuZGF0aW9uYWwgY2xpZW50LXNlcnZlciBzdWl0 ZSBvZiBkcmFmdHMgKGkuZS4sIGNyeXB0by10eXBlcywNCiBrZXlzdG9yZSwgYW5kIHRydXN0c3Rv cmUpLiAmbmJzcDtTbywgaWYgYW55IG9iamVjdGlvbnMsIHBsZWFzZSBzaG91dCBvdXQgbm93Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50 IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNvbnRyYXN0LCB0aGUgY3VycmVudC9w bGFubmVkL29sZCBhcHByb2FjaCBkZXNjcmliZWQgaW4gbXkgcHJldmlvdXMgbWVzc2FnZSwgd2hl cmVieSB0aGVyZSB3b3VsZCBiZSBhIGxpc3QgcGVyIHByb3RvY29sIChUTFMgdnMgU1NIKSwgYWxz byBkaWQgbm90IHRha2UgaW50byBhY2NvdW50IHByb3RvY29sIHZlcnNpb25zICgxLjIgdnMgMS4z KS4gJm5ic3A7U28sIGlmIHRoaXMgaXMgYW4gaXNzdWUsIHdlIGhhdmUgbm8NCiBwcm9wb3NhbCBh ZGRyZXNzaW5nIGl0IHlldC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ib3cgZG9lcyBPcGVuU1NMIENMSSBzdXBwb3J0IHRoaXM/ICZuYnNw O0xvb2tpbmcgYXQgYG9wZW5zc2wgY2lwaGVyc2AsIEkgc2VlIHRoYXQgaXTigJlzIHBvc3NpYmxl IHRvIHNwZWNpZmljIHByb3RvY29sIHZlcnNpb25zIChpLmUuLCAxLjIsIDEuMywgZXRjLikuICZu YnNwOyBCdXQsIGluIHRoZSBlbmQsIHRoZXNlIGFyZSBjaXBoZXIgc3VpdGVzIChlLmcuLCBFQ0RI RS1SU0EtQUVTMTI4LUdDTS1TSEEyNTYpLCBub3QganVzdCB0aGUNCiBhbGdvcml0aG0gKFJTQSkg YW5kIGRlZmluaXRlbHkgbm90IGluZGljYXRpbmcgc3VwcG9ydGVkIGtleSBsZW5ndGhzIChwcmVz dW1hYmxlIGFsbCBSU0Ega2V5IGxlbmd0aHMgYXJlIHN1cHBvcnRlZD8pLi4uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGhlbHAg aWYgd2UgY291bGQgaWRlbnRpZnkgdGhlIENMSS1lcXVpdmFsZW50IGZvciBhbGwgdGhpc+KApjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QUzog Ym90aCB0aGUgU1NIIGFuZCBUTFMgY2xpZW50LXNlcnZlciBkcmFmdCBjcmVhdGUgbWFwcGluZyB0 YWJsZXMgYmV0d2VlbiB0aGUgcHJvdG9jb2wtc3BlY2lmaWMgY2lwaGVyLXN1aXRlIG5hbWVzIGFu ZCB0byB0aGUgYWxnb3JpdGhtIG5hbWVzIGluIGNyeXB0by10eXBlcy4gJm5ic3A7Rm9yIGluc3Rh bmNlLCBoZXJlIGFyZSB0aGUgbWFwcGluZyB0YWJsZXMgZm9yIFRMUzombmJzcDs8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xz LmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0Y29uZi0yRHRscy0yRGNsaWVudC0yRHNl cnZlci0yRDE3LTIzc2VjdGlvbi0yRDUmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1HQmRSd1hMX2p0S2Jr UXZsbnYzNHlraTFQRlVLdDBiNU5KZENEUUZkdVMwJmFtcDtzPW5nRUhULW5kRWxKalVCNzZ6dXQz Y3RjX1dUTzV3WWVja1hGX0FVRHBhOXMmYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXRscy1jbGllbnQtc2VydmVyLTE3I3NlY3Rpb24tNTwvYT4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBQ UzogSeKAmW0gYmVnaW5uaW5nIHRvIHRoaW5rIHRoYXQgd2UgbWlnaHQgYmUgYmV0dGVyIGdpdmlu ZyB1cCBvbiBoYXZpbmcgYW55IFJQQyB0byBhc2sgdGhlIHNlcnZlciB0byBnZW5lcmF0ZSBrZXlz IG9yIGluZGljYXRlIHdoaWNoIGFsZ29yaXRobXMgYXJlIHN1cHBvcnRlZCwgcHVudGluZyBhbGwg dGhpcyBjb21wbGV4aXR5IHRvIHNvbWUgZnV0dXJlIHJldmlzaW9uLiAmbmJzcDtUaGF0IHNhaWQs IGl0IHdvdWxkIGJlDQogYmVzdCBpcyB3ZSBjb3VsZCBnZXQgc29tZXRoaW5nIHBhc3NhYmxlIHdv cmtpbmcgbm93LCBpZiBwb3NzaWJsZS4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50LiAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K bmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9y ZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A6BFFEFD57D843EDBA3F1D9B872C2FEEakamaicom_-- From nobody Mon Feb 17 18:54:50 2020 Return-Path: <0100017055c347e5-13b624a9-04c0-4ba5-8a53-26a80f079607-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 42E04120889 for ; Mon, 17 Feb 2020 16:47:09 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 xmT0L-nTqhte for ; Mon, 17 Feb 2020 16:47:07 -0800 (PST) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA010120874 for ; Mon, 17 Feb 2020 16:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581986826; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=YfVrZEiX66j1l7mBBTWpXqssdlmyF47zwd+88ZmH3w0=; b=U5hxc0b1X3cI4d1wtGOE+clzuOO9jdeHrrsE5WV2MiG/2qLI6g46miysdziERu96 9iBZACcfIcDz8Ygo3CxranY5sydZ5NiW/GD4B33hulHNTi5c7ILafc3VqwDVh3m/vWm iD+yMDmxD/il9Gy+IOZhdTWigeuhirPbLZI26lOg= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100017055c347e5-13b624a9-04c0-4ba5-8a53-26a80f079607-000000@email.amazonses.com> Date: Tue, 18 Feb 2020 00:47:06 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.18-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11 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, 18 Feb 2020 00:47:09 -0000 This message begins a two-week WGLC for = draft-ietf-netconf-notification-capabilities-11 ending on March 2nd (a = week before the IETF 107 submission cutoff deadline). Here is a direct = link to the HTML version of the draft: = https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-1= 1 Positive comments, e.g., "I've reviewed this document and believe it is = ready for publication", are welcome! This is useful and important, even = from authors. Objections, concerns, and suggestions are also welcomed = at this time. Thank you, NETCONF Chairs= From nobody Mon Feb 17 18:55:34 2020 Return-Path: <0100017055e833dd-1a2ecac4-53e4-4bb7-aab9-f75516c5fd38-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 DA0FB12088D for ; Mon, 17 Feb 2020 17:27:28 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ufiPa-B_f2oR for ; Mon, 17 Feb 2020 17:27:27 -0800 (PST) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795A7120882 for ; Mon, 17 Feb 2020 17:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1581989246; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=1VXSW0b5S2ZL5t1VWzuh7qnhtSYMMSGilbRF7B8XKB8=; b=YP7ZQjKTNW4Cngnyz6f6/HvEA3OQNQckaIzoDnM1NQSaj0UuliT2wzHl9W46KYk0 baJZT+7NUMNiNj/JfyaOl/RX2iA3sVqMeHBkg3+0qeoa3WdsaEcKhxxULWSERUiDvgU mzJ4Bw4qJBdQJCa6o/0JVHglsV23MfAOIDXDvpxs= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 18 Feb 2020 01:27:26 +0000 References: <0100017055c347e5-13b624a9-04c0-4ba5-8a53-26a80f079607-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100017055c347e5-13b624a9-04c0-4ba5-8a53-26a80f079607-000000@email.amazonses.com> Message-ID: <0100017055e833dd-1a2ecac4-53e4-4bb7-aab9-f75516c5fd38-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.18-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-notification-capabilities-11 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, 18 Feb 2020 01:27:29 -0000 FWIW, this is WGLC #2, after the major updates resulting from WGLC #1 = (in October). K. > On Feb 17, 2020, at 7:47 PM, Kent Watsen wrote: >=20 > This message begins a two-week WGLC for = draft-ietf-netconf-notification-capabilities-11 ending on March 2nd (a = week before the IETF 107 submission cutoff deadline). Here is a direct = link to the HTML version of the draft: >=20 > = https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-1= 1 >=20 > Positive comments, e.g., "I've reviewed this document and believe it = is ready for publication", are welcome! This is useful and important, = even from authors. Objections, concerns, and suggestions are also = welcomed at this time. >=20 > Thank you, > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Feb 18 16:21:16 2020 Return-Path: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-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 B5976120058 for ; Tue, 18 Feb 2020 16:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gsn2knegW2vU for ; Tue, 18 Feb 2020 16:21:12 -0800 (PST) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85650120041 for ; Tue, 18 Feb 2020 16:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582071671; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=AVIrcuR4nZFzpVNvA6WrffB2gDvxRuYt2ffT8IEw81I=; b=bOz4voXF6HuudG8gGD7IxqSWN/86JyqD1v4Sc0Xlrgur2OoSgS2vYRzgHYhd0DXY Z2XTjuHL+OoR2DOOtty/SEnMf1U/uGldG3Ah5VQSPe3B0fIpOFx7DMz5rCBdJLcSoPC nnLPcbg4VMmagtao2p+6P2gbnTJ5nKtR9ISLpa4Y= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> Date: Wed, 19 Feb 2020 00:21:11 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.19-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] IANA templates for algorithms 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, 19 Feb 2020 00:21:15 -0000 =46rom our session at IETF 106, there was a suggestion to follow the = =E2=80=9Ctemplate=E2=80=9D pattern forged by = draft-ietf-dnsop-iana-class-type-yang, which provides an XSLT script = that generates a YANG module by processing as input the XML for the = separately maintained "DNS Parameters=E2=80=9D registry, specifically = https://www.iana.org/assignments/dns-parameters/dns-parameters.xml. The = IANA workflow is: 1) whenever updating the DNS Parameters registry... - for whatever RFC may be requesting it 2) also update the YANG module... - by re-running the XSLT script again over the updated XML = file The prerequisite for this process is that there exists separate = registries to pull data from, i.e., the input to the XSLT script. The = closest comparable registries that we could pull from seem to be: - for TLS: = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml - for SSH: = https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml Neither of these registries help us, at least not directly. Yes, they = provide enumerations for on-the-wire protocol values, but they fail to = provide an enumeration for, e.g., a 2048-bit RSA key. Keying off Rob=E2=80=99s comment from the 106 meeting for the IANA = process to engage expert reviewers, it seems that a process akin to the = following is needed: 1) whenever some number of existing target registries are updated - for now, just the SSH/TLS registries listed above 2) engage an "expert reviewer" to see if any of the new entries regard an undefined algorithm and, if so, a TBD process is used to add the new algorithms to the appropriate YANG module (e.g., iana-symmetric-algorithms), which would be automatically published by IANA. Drilling into step (2) some, the process might actually be: 2a) update some new TBD registry (e.g., =E2=80=9Cbase algorithms=E2=80=9D= ). This would need to be done by a crypto expert (not the NETCONF WG or YANG Doctors. Good candidates might the Security ADs or, perhaps better, the WG that published the source RFC. 2b) run a script over the updated new TBD =E2=80=9Cbase algorithms=E2=80= =9D=20 registry to produce the desired updated YANG module(s). =20 Presumably IANA could do this in the same way as will Be done for the DNS Parameters registry. Obviously (2a) relies heavily on buy-in from the Security Area experts. = The buy-in needs to be both that this is an important registry to define = and support the publication of an RFC that creates and defines rules for = maintaining said registry. Our =E2=80=9Ccrypto-types=E2=80=9D draft = could be this RFC, if they=E2=80=99re okay with that. Rich, as someone more connected to the Security Area, what do you think = about this plan and any ideas on how to proceed to get the needed = buy-in? Kent // contributor From nobody Tue Feb 18 17:06:29 2020 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 6A3131208A3 for ; Tue, 18 Feb 2020 17:06:23 -0800 (PST) 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, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CU1pmlztlk2 for ; Tue, 18 Feb 2020 17:06:21 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C81120898 for ; Tue, 18 Feb 2020 17:06:21 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01J128j1014548; Wed, 19 Feb 2020 01:06:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NLj487tdcL3ZD04GbWaQNleZuDrEQBA5nQmc8BjiZ7g=; b=Hp+UxsHjtzzMWsODvM2ravJd/NKe9RXIIZf981rSPzFchLuexrBoH1hT9sTKW7dfDzRL qvjoydvnBGvsh/TU9OFMWmy58D8MnZDlSDwfBOMjHwYp9r4tpWd2StFL51iZ86tsZ7EF bFrHx7r1gC2Vjt5yPy9fNTHhsOZGi20VSgpgy1vjXr4VRccvQcnUGcagecCZyZtpOKnE 19ZWZx2Epr2lgD5QfEq2JZSnyobG7KKqzxmsnot8X4DPLhHnHFZ+c1TCPVhfmUONoLxA /hJbloM42zxYDX8t4l0Cll9gGE4GXq+9o8s+pv6nhuwQbZ1vQgnEDo1O9s3kX6JqNjjB iQ== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2y68sf6sgk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Feb 2020 01:06:21 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01J1367m015015; Tue, 18 Feb 2020 20:06:20 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint8.akamai.com with ESMTP id 2y6cv2tc51-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Feb 2020 20:06:20 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 18 Feb 2020 20:06:18 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 18 Feb 2020 20:06:18 -0500 From: "Salz, Rich" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: IANA templates for algorithms Thread-Index: AQHV5rp+7/ibLSq920GDrcD49mcMyKghtB8A Date: Wed, 19 Feb 2020 01:06:18 +0000 Message-ID: <8713517D-96E9-45CF-8ABF-8691581A8F89@akamai.com> References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> In-Reply-To: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.104] Content-Type: text/plain; charset="utf-8" Content-ID: <4C6C046D76918846963E04FD3ADA6EE2@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=834 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002190003 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-18_08:2020-02-18, 2020-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 impostorscore=0 spamscore=0 clxscore=1011 phishscore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 mlxlogscore=806 malwarescore=0 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002190002 Archived-At: Subject: Re: [netconf] IANA templates for algorithms 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, 19 Feb 2020 01:06:28 -0000 PiAgICBOZWl0aGVyIG9mIHRoZXNlIHJlZ2lzdHJpZXMgaGVscCB1cywgYXQgbGVhc3Qgbm90IGRp cmVjdGx5LiAgWWVzLCB0aGV5IHByb3ZpZGUgZW51bWVyYXRpb25zIGZvciBvbi10aGUtd2lyZSBw cm90b2NvbCB2YWx1ZXMsIGJ1dCB0aGV5IGZhaWwgdG8gcHJvdmlkZSBhbiBlbnVtZXJhdGlvbiBm b3IsIGUuZy4sIGEgMjA0OC1iaXQgUlNBIGtleS4NCiAgDQpZZXMsIFJTQSBzaXplIGlzIG5vdCBy ZWxldmFudCB0byB0aGUgcHJvdG9jb2xzLg0KDQo+ICAgICAgICAyKSBlbmdhZ2UgYW4gImV4cGVy dCByZXZpZXdlciIgdG8gc2VlIGlmIGFueSBvZiB0aGUgbmV3IGVudHJpZXMNCiAgICAgICAgICAg IHJlZ2FyZCBhbiB1bmRlZmluZWQgYWxnb3JpdGhtIGFuZCwgaWYgc28sIGEgVEJEIHByb2Nlc3Mg aXMNCiAgICAgICAgICAgIHVzZWQgdG8gYWRkIHRoZSBuZXcgYWxnb3JpdGhtcyB0byB0aGUgYXBw cm9wcmlhdGUgWUFORw0KICAgICAgICAgICAgbW9kdWxlIChlLmcuLCBpYW5hLXN5bW1ldHJpYy1h bGdvcml0aG1zKSwgd2hpY2ggd291bGQgYmUNCiAgICAgICAgICAgIGF1dG9tYXRpY2FsbHkgcHVi bGlzaGVkIGJ5IElBTkEuDQogICAgDQpCeSB1bmRlZmluZWQsIHlvdSBtZWFuICJ1bmtub3duIHRv IFlBTkciIEkgYXNzdW1lLCBhbmQgbm90ICJhIG5ldyBjcnlwdG8gYWxnIG5vdCBwcmV2aW91c2x5 IHVzZWQgaW4gVGxTIChmb3IgZXhhbXBsZSkuIg0KDQo+ICAgICAgMmEpIHVwZGF0ZSBzb21lIG5l dyBUQkQgcmVnaXN0cnkgKGUuZy4sIOKAnGJhc2UgYWxnb3JpdGhtc+KAnSkuDQogICAgICAgICAg ICBUaGlzIHdvdWxkIG5lZWQgdG8gYmUgZG9uZSBieSBhIGNyeXB0byBleHBlcnQgKG5vdCB0aGUN CiAgICAgICAgICAgIE5FVENPTkYgV0cgb3IgWUFORyBEb2N0b3JzLiAgR29vZCBjYW5kaWRhdGVz IG1pZ2h0DQogICAgICAgICAgICB0aGUgU2VjdXJpdHkgQURzIG9yLCBwZXJoYXBzIGJldHRlciwg dGhlIFdHIHRoYXQgcHVibGlzaGVkDQogICAgICAgICAgICB0aGUgc291cmNlIFJGQy4NCkkgZG9u J3Qga25vdyBpZiB0aGUgc2VjIGZvbGtzIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gdGhpcyBidXQg SSBjb3VsZCBiZSB3cm9uZy4gIEl0IG1pZ2h0IGJlIGdvb2QgdG8gaGF2ZSBhIGJyaWVmIGNoYXQg RjJGIGluIFZhbmNvdXZlciwgd2hpY2ggSSBjYW4gaGVscCBzZXQgdXAuDQogICAgDQogDQoNCg== From nobody Tue Feb 18 19:37:48 2020 Return-Path: <010001705b85d22d-4cb8597c-6703-4d13-98aa-284cd569c163-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 CD05C120033 for ; Tue, 18 Feb 2020 19:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 cw14jPy6uIl9 for ; Tue, 18 Feb 2020 19:37:45 -0800 (PST) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22253120836 for ; Tue, 18 Feb 2020 19:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582083461; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=M1FDvk8QieqFcvxwXZtZIUpF1sruCiqbd4WLUl8QicQ=; b=mrqXAyt/1U8N/6H35TAkcqx59IlVuB1k5WuLupmAPXrNnBdBcpxOkOYPY00BKhxR PpLshuzrI1Zwk6HQPN1s0EKMs5gCppYNS2UYS9KRaoRay/fpvh8tGvEcB65bOrVkpTy rK3m8PJVJvS7GbbLmGF0D7AUSoQXYXagR7i9Qgi4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <8713517D-96E9-45CF-8ABF-8691581A8F89@akamai.com> Date: Wed, 19 Feb 2020 03:37:41 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001705b85d22d-4cb8597c-6703-4d13-98aa-284cd569c163-000000@email.amazonses.com> References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> <8713517D-96E9-45CF-8ABF-8691581A8F89@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.19-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IANA templates for algorithms 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, 19 Feb 2020 03:37:47 -0000 Hi Rich, >> Neither of these registries help us, at least not directly. Yes, = they provide enumerations for on-the-wire protocol values, but they fail = to provide an enumeration for, e.g., a 2048-bit RSA key. >=20 > Yes, RSA size is not relevant to the protocols. Not to TLS, but I think that size may be relevant to SSH. For instance, = RFC 4432 defines both "rsa1024-sha=E2=80=9D and "rsa2048-sha256=E2=80=9D. = But these enumerations are for ciphers (i.e., more than we need/want = to generate a key). FWIW, `ssh-keygen` has the =E2=80=9C-b bits=E2=80=9D parameter and = `openssl genrsa` has the =E2=80=9C[numbits]=E2=80=9D parameter. The = SSH/TLS protocols don=E2=80=99t define how the keys are created (it's = out-of-scope to those drafts), hence why their registries don=E2=80=99t = need to define enumerations for the base algorithms. Of course, it is our goal to enable the configuration/generation of the = keys themselves; effectively mimicking the CLI commands >> 2) engage an "expert reviewer" to see if any of the new entries > regard an undefined algorithm and, if so, a TBD process is > used to add the new algorithms to the appropriate YANG > module (e.g., iana-symmetric-algorithms), which would be > automatically published by IANA. >=20 > By undefined, you mean "unknown to YANG" I assume, and not "a new = crypto alg not previously used in TLS (for example).=E2=80=9D Yes, unknown to the YANG modules that we=E2=80=99re trying to define, = but also unknown to the TBD =E2=80=9Cbase algorithms=E2=80=9D registry = mentioned in (2a) below. >> 2a) update some new TBD registry (e.g., =E2=80=9Cbase = algorithms=E2=80=9D). > This would need to be done by a crypto expert (not the > NETCONF WG or YANG Doctors). Good candidates might > be the Security ADs or, perhaps better, the WG that = published > the source RFC. >=20 > I don't know if the sec folks would be interested in this but I could = be wrong. It might be good to have a brief chat F2F in Vancouver, which = I can help set up. That would be great! FWIW, I=E2=80=99m on good terms with Ben Kaduk, = Sean Turner, and Russ Housley, but maybe you were thinking SecDir? = Would it be good prepare something (e.g., slides) to help explain it? = IDK, it seems easy enough to just talk to, but that=E2=80=99s just my = POV. Regading =E2=80=9Cinterest", do you mean in terms of a) acknowledging = it=E2=80=99s a problem, b) supporting the creation of a registry, c) = participating in the creation of the registry, or d) maintaining the = registry (the expert reviews)? The minimal would be (a+b), so our = attempt to do (c) isn=E2=80=99t torpedoed by SecDir/IESG. For (d), it = would be best if they could assign an expert reviewer (perhaps SecDir), = as the prospect of (presumably) just me doing it doesn=E2=80=99t seem = right... Kent // contributor From nobody Tue Feb 18 19:51:54 2020 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 91CA212089B for ; Tue, 18 Feb 2020 19:51:53 -0800 (PST) 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, 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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDgBWrXOVki2 for ; Tue, 18 Feb 2020 19:51:52 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55249120836 for ; Tue, 18 Feb 2020 19:51:52 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01J3krTk010445; Wed, 19 Feb 2020 03:51:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=UIugo/zIF+wVAD4GXVPKrOLmxAvbcvHNqxtnnrhR5VQ=; b=Me1Hu/lw+gvUHgDglyxUYiowcDBqKEXOzKREOcAMFDr25+nrZOyNkzvFPa3v3Ngr5FNB 3FBHvhSzh/b2/QfmEWML4Jjia7V1udwfEUFUjZ5DbpbjXVZJoC6cU55k+gwu7yLQ4s2h 1I+cHQuTcjrqsKhWwO1FbOfzXaqDZfSt0IZ8xJqIaeX69atgfr8eozgj10QchLW1hT0p BgStKef0zaJIwqRif8hc3x+uvb8ng9vPMnaNTpYYbQ0rz1Okr6kV59Cw2nbvcFqGjPib zI1P45bMdztLZwqsi+fZDCtvGMI8zzsyg2JN4jwTrUi59hfqc97Du2YVFJ9kVnUP8XiH 5g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2y69jqy5g5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Feb 2020 03:51:51 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01J3lKZC007809; Tue, 18 Feb 2020 22:51:50 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2y6cv0ke1p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Feb 2020 22:51:50 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 18 Feb 2020 22:51:49 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 18 Feb 2020 22:51:49 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 18 Feb 2020 22:51:49 -0500 From: "Salz, Rich" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: IANA templates for algorithms Thread-Index: AQHV5rp+7/ibLSq920GDrcD49mcMyKghtB8AgAB+HoD//7AhgA== Date: Wed, 19 Feb 2020 03:51:48 +0000 Message-ID: <6C427748-02AB-4216-B986-907E8B4309CC@akamai.com> References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> <8713517D-96E9-45CF-8ABF-8691581A8F89@akamai.com> <010001705b85d22d-4cb8597c-6703-4d13-98aa-284cd569c163-000000@email.amazonses.com> In-Reply-To: <010001705b85d22d-4cb8597c-6703-4d13-98aa-284cd569c163-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.104] Content-Type: text/plain; charset="utf-8" Content-ID: <668E86904621FC4894F8A399BB7BF477@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=711 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2002190027 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-18_08:2020-02-18, 2020-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=693 priorityscore=1501 suspectscore=0 impostorscore=0 bulkscore=0 clxscore=1015 phishscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002190026 Archived-At: Subject: Re: [netconf] IANA templates for algorithms 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, 19 Feb 2020 03:51:53 -0000 SSBzcG9rZSBhYm91dCB0aGlzIGF0IHNlY2RpciBhd2hpbGUgYWdvIGFuZCBmb2xrcyB3ZXJlIG5v dCBlbnRodXNpYXN0aWMgYWJvdXQgdGhlIGVmZm9ydHMgaGVyZS4NCg0KSSB3b3VsZCByZWFjaCBv dXQgdG8gQmVuIGFuZCBhc2sgZm9yIHRpbWUgYXQgdGhlIG9wZW4gYXJlYSwgU0FBRy4NCiANCg0K From nobody Wed Feb 19 00:55:43 2020 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 028B51200B5 for ; Wed, 19 Feb 2020 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 npjiz9YwW77b for ; Wed, 19 Feb 2020 00:55:37 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AE1241200E9 for ; Wed, 19 Feb 2020 00:55:35 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 3662F860731; Wed, 19 Feb 2020 09:56:09 +0100 (CET) Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id 6E3A786012F; Wed, 19 Feb 2020 09:56:07 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , "netconf\@ietf.org" In-Reply-To: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> Date: Wed, 19 Feb 2020 09:55:31 +0100 Message-ID: <87h7znvtvg.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] IANA templates for algorithms 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, 19 Feb 2020 08:55:41 -0000 Kent Watsen writes: > From our session at IETF 106, there was a suggestion to follow the =E2=80= =9Ctemplate=E2=80=9D pattern forged by draft-ietf-dnsop-iana-class-type-yan= g, which provides an XSLT script that generates a YANG module by processing= as input the XML for the separately maintained "DNS Parameters=E2=80=9D re= gistry, specifically https://www.iana.org/assignments/dns-parameters/dns-pa= rameters.xml. The IANA workflow is: > > 1) whenever updating the DNS Parameters registry... > - for whatever RFC may be requesting it > > 2) also update the YANG module... > - by re-running the XSLT script again over the updated XML fi= le Strictly speaking, the XSLT stylesheet is still intended only for producing= the initial revision of the module. Re-running the stylesheet on a later revision of the registry would essenti= ally work, only the revision history would be lost. I don't see any easy wo= rkaround to this. It is up to IANA (we can help them) to decide whether the YANG module will = be updated as before, e.g. by manually adding new enums, identities etc., o= r whether they use the stylesheet and then manually edit the revision histo= ry. Maybe it would be useful to write an informational RFC suggesting a workflo= w for these cases. Lada > > The prerequisite for this process is that there exists separate registrie= s to pull data from, i.e., the input to the XSLT script. The closest compa= rable registries that we could pull from seem to be: > > - for TLS: https://www.iana.org/assignments/tls-parameters/tls-parameter= s.xhtml > - for SSH: https://www.iana.org/assignments/ssh-parameters/ssh-parameter= s.xhtml > > Neither of these registries help us, at least not directly. Yes, they pr= ovide enumerations for on-the-wire protocol values, but they fail to provid= e an enumeration for, e.g., a 2048-bit RSA key. > > Keying off Rob=E2=80=99s comment from the 106 meeting for the IANA proces= s to engage expert reviewers, it seems that a process akin to the following= is needed: > > 1) whenever some number of existing target registries are updated > - for now, just the SSH/TLS registries listed above > > 2) engage an "expert reviewer" to see if any of the new entries > regard an undefined algorithm and, if so, a TBD process is > used to add the new algorithms to the appropriate YANG > module (e.g., iana-symmetric-algorithms), which would be > automatically published by IANA. > > Drilling into step (2) some, the process might actually be: > > 2a) update some new TBD registry (e.g., =E2=80=9Cbase algorithms=E2=80= =9D). > This would need to be done by a crypto expert (not the > NETCONF WG or YANG Doctors. Good candidates might > the Security ADs or, perhaps better, the WG that published > the source RFC. > > 2b) run a script over the updated new TBD =E2=80=9Cbase algorithms=E2= =80=9D=20 > registry to produce the desired updated YANG module(s).=20=20 > Presumably IANA could do this in the same way as will > Be done for the DNS Parameters registry. > > Obviously (2a) relies heavily on buy-in from the Security Area experts. = The buy-in needs to be both that this is an important registry to define an= d support the publication of an RFC that creates and defines rules for main= taining said registry. Our =E2=80=9Ccrypto-types=E2=80=9D draft could be = this RFC, if they=E2=80=99re okay with that. > > Rich, as someone more connected to the Security Area, what do you think a= bout this plan and any ideas on how to proceed to get the needed buy-in? > > > Kent // contributor > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka=20 Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 19 03:59:21 2020 Return-Path: <010001705d5105d1-87b474be-6b84-4a22-8a7f-2629923661c3-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 2CD0A12011F for ; Wed, 19 Feb 2020 03:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 ueMsdD2fx1OB for ; Wed, 19 Feb 2020 03:59:17 -0800 (PST) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9693E12011C for ; Wed, 19 Feb 2020 03:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582113556; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=m93gbKe0ceLHTD+uYt64bAO9SHEuT6qYY0tpXHex2BE=; b=S0V9ZJFONUQxLROT3R7Q9hj/umpadwp018bG33V+Nbv3rnpLF1rQclgFOCCB13IQ PHVVHE5i87EDbP8OTcR/7KoPpA/xCe6/8Bkl1jbUa1AEnFffykK5at4imrldYHZYdTx c4R+qAQpaFLeaCnwdRkQAsFC1vlFmXHUWUA/zjZc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <87h7znvtvg.fsf@nic.cz> Date: Wed, 19 Feb 2020 11:59:16 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001705d5105d1-87b474be-6b84-4a22-8a7f-2629923661c3-000000@email.amazonses.com> References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> <87h7znvtvg.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.19-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IANA templates for algorithms 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, 19 Feb 2020 11:59:19 -0000 Hi Lada, > Strictly speaking, the XSLT stylesheet is still intended only for = producing the initial revision of the module. Apparently my expectations got ahead of me. > Re-running the stylesheet on a later revision of the registry would = essentially work, only the revision history would be lost. I don't see = any easy workaround to this. Perhaps pass the YIN of the =E2=80=9Ccurrent=E2=80=9D YANG module into = the XSLT script too? > It is up to IANA (we can help them) to decide whether the YANG module = will be updated as before, e.g. by manually adding new enums, identities = etc., or whether they use the stylesheet and then manually edit the = revision history. But it=E2=80=99s still a manual YANG-editor level effort, which is new = (I assume) to IANA. > Maybe it would be useful to write an informational RFC suggesting a = workflow for these cases. Don=E2=80=99t think that there is a patten just yet. Your draft=E2=80=99s= use XSLT to create the initial revision makes sense only in that the = registry already exists and new registrations may occur while your draft = is being published. =20 In crypto-type's case, the intention is to create a brand new = registry/YANG-module, so we could just as easily put the initial YANG = module into the draft, negating the need for IANA to run `xsltproc` at = all. If IANA doesn=E2=80=99t run XSLT for subsequent updates, I think that we = (NETCONF) need to question if a registry is even needed. The motives = behind defining a registry are 1) to accommodate IANA and 2) to make it = seem more official/interesting to the Sec folks (since =E2=80=9CYANG=E2=80= =9D appears to be uncool/taboo?). But if IANA is okay editing the YANG, = and the Sec folks are still uninterested, then we could skip creating = the registry altogether. That said, I feel that creating a, e.g., =E2=80=9Cbase algorithms=E2=80=9D= registry is best, as it allows for potential future/other use cases, = and I=E2=80=99m hopeful/optimistic that we can get the Sec folks = onboard. Kent // contributor From nobody Wed Feb 19 04:57:26 2020 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 BE82212003F for ; Wed, 19 Feb 2020 04:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BekMdQZtHMMQ for ; Wed, 19 Feb 2020 04:57:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4EE120019 for ; Wed, 19 Feb 2020 04:57:19 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id C3053140B42; Wed, 19 Feb 2020 13:57:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1582117036; bh=BT00lymVDZo665X6XFKSxhTE1br101bh6zW49gePNC8=; h=From:To:Date; b=wyXbVEoq/UTqLc+LJpUbRJcdIRbGJ8hzh5utAvEQ3xr2uXO8tf588WvI/B5MP8YPX C+gaNlsOb1jlUoq8OTPgAx056MnPetwIWnwxj6fOfc8zrxWfQsG6MV81YjkmJYMKhr DUDuYsrBaLJl1YpfLzSvtGaeFy9BBU/+a3JJ5M7c= Message-ID: <93d0d5faf613b8b5c72b74d59ed2e0a55e9ac509.camel@nic.cz> From: Ladislav Lhotka To: Kent Watsen Cc: "netconf@ietf.org" Date: Wed, 19 Feb 2020 13:57:16 +0100 In-Reply-To: <010001705d5105d1-87b474be-6b84-4a22-8a7f-2629923661c3-000000@email.amazonses.com> References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> <87h7znvtvg.fsf@nic.cz> <010001705d5105d1-87b474be-6b84-4a22-8a7f-2629923661c3-000000@email.amazonses.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.4 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] IANA templates for algorithms 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, 19 Feb 2020 12:57:25 -0000 On Wed, 2020-02-19 at 11:59 +0000, Kent Watsen wrote: > Hi Lada, > > > Strictly speaking, the XSLT stylesheet is still intended only for producing > > the initial revision of the module. > > Apparently my expectations got ahead of me. This solved the objections raised in the DNSOP WG, and I don't want to harass them with any more complications. :^) > > > > Re-running the stylesheet on a later revision of the registry would > > essentially work, only the revision history would be lost. I don't see any > > easy workaround to this. > > Perhaps pass the YIN of the “current” YANG module into the XSLT script too? > Yeah, but this is already not exactly straightforward. > > > It is up to IANA (we can help them) to decide whether the YANG module will > > be updated as before, e.g. by manually adding new enums, identities etc., or > > whether they use the stylesheet and then manually edit the revision history. > > But it’s still a manual YANG-editor level effort, which is new (I assume) to > IANA. I assume they do manual editing of modules like "iana-if-type" when rolling out a new revision. > > > > Maybe it would be useful to write an informational RFC suggesting a workflow > > for these cases. > > Don’t think that there is a patten just yet. Your draft’s use XSLT to create > the initial revision makes sense only in that the registry already exists and Yes, this is intended for mapping existing registries to YANG in a 1-1 fashion. > new registrations may occur while your draft is being published. The main concern of some DNSOP people was that the RFC itself is not updated, so somebody can use the obsolete module contained therein any time later. If they do it with the XSLT stylesheet, they should get basically the current data. > > > In crypto-type's case, the intention is to create a brand new registry/YANG- > module, so we could just as easily put the initial YANG module into the draft, > negating the need for IANA to run `xsltproc` at all. Then the YANG module effectively becomes the registry. It is a different problem though. > > If IANA doesn’t run XSLT for subsequent updates, I think that we (NETCONF) > need to question if a registry is even needed. The motives behind defining a This is of course a rather NETCONF/YANG-centric view. There are people who don't give a damn to YANG and NETCONF, but still need a registry. > registry are 1) to accommodate IANA and 2) to make it seem more > official/interesting to the Sec folks (since “YANG” appears to be > uncool/taboo?). But if IANA is okay editing the YANG, and the Sec folks are > still uninterested, then we could skip creating the registry altogether. Yes, but then somebody will have to take care about maintaining the module. I think that NETCONF isn't the right place for it, and sec folks may not be interested. Lada > > That said, I feel that creating a, e.g., “base algorithms” registry is best, > as it allows for potential future/other use cases, and I’m hopeful/optimistic > that we can get the Sec folks onboard. > > > Kent // contributor > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 19 07:32:27 2020 Return-Path: <010001705e140aa6-b386aaf0-12df-4cd2-87c9-c34641c5346d-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 A268212081E for ; Wed, 19 Feb 2020 07:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 1R9Gihsgn7_5 for ; Wed, 19 Feb 2020 07:32:18 -0800 (PST) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E46120880 for ; Wed, 19 Feb 2020 07:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582126336; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=w5NQ7lXkKNEYY4kqlvhr2vbUDF3rHeJELBtNRnO7Axk=; b=cP692YjvLLGMTjZh1hihMC+2hQdWAjS9zGzWA7GZsYrQSc8blS+dfZhbqQavo0yh bYA59NJmqNiKGMzP005V9Y8GLa/ci2p3tRyH4vedqiFml/34uJgu0Gk/DbMHxkMhvaC +xUyM8UtP/slfBzRTG8WHlTElzkre4h35AElNoTI= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <010001705e140aa6-b386aaf0-12df-4cd2-87c9-c34641c5346d-000000@email.amazonses.com> Date: Wed, 19 Feb 2020 15:32:16 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.19-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] =?utf-8?q?truststore=3A_merging_the_=E2=80=9Cssh-publi?= =?utf-8?b?Yy1rZXnigJ0gYW5kIOKAnHJhdy1wdWJsaWMta2V54oCdIGxpc3Rz?= 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, 19 Feb 2020 15:32:25 -0000 Slide 12 in my 106 presentation contained this snippet: module: ietf-truststore +--rw truststore +--rw certificates* [name] {x509-certificates}? | +-- =E2=80=A6 +--rw ssh-host-keys* [name] {ssh-host-keys}? | +-- =E2=80=A6 +--rw raw-public-keys* [name] {raw-public-keys}? +-- ...=20 The slide asked if the =E2=80=9Cssh-public-key=E2=80=9D and = =E2=80=9Craw-public-key=E2=80=9D lists should be merged. No comments = were received during the meeting, so I said that it might require trying = out, and folks can look forward to that discussion later=E2=80=A6.and = here were are! Looking at truststore's YANG, it turns out that the =E2=80=9Cssh-public-ke= y=E2=80=9D and =E2=80=9Craw-public-key=E2=80=9D lists are *identical* = with one exception, which is that each refines a common crypto-types = grouping with a slightly different =E2=80=9Cmust" expression regarding = the =E2=80=9Ckey-format". Specifically, the ssh-public-key format must = be =E2=80=9Cct:ssh-public-key-format" and raw-public-key format must be = =E2=80=9Cct:subject-public-key-info-format=E2=80=9D. However, these "must=E2=80=9D statements are low-value as already (at = least in my local copy), the SSH and TLS client/server modules have the = equivalent =E2=80=9Cmust=E2=80=9D expressions. This being the case, it = appears that these two lists should be merged, with the resulting = trees-diagram being: module: ietf-truststore +--rw truststore +--rw certificates* [name] {x509-certificates}? | +-- =E2=80=A6 +--rw public-keys* [name] {public-keys}? +-- =E2=80=A6=20 In my view, the optics on this are better, as having protocol-specific = entries in the truststore (e.g., ssh-host-keys) always seemed wrong to = me... Any objection to this change being made? PS: this is the last post-106 item I needed to address, in case you=E2=80=99= re wondering how many more might be coming... Kent // contributor From nobody Wed Feb 19 08:07:32 2020 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 BC0671201EF for ; Wed, 19 Feb 2020 08:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dyr5Cv2A; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=ukpYftOR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX9R2bnLNNSs for ; Wed, 19 Feb 2020 08:07:27 -0800 (PST) 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 8C5D7120154 for ; Wed, 19 Feb 2020 08:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30370; q=dns/txt; s=iport; t=1582128445; x=1583338045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3lpuW4lVtqeZX2kjdg52DxO52QGTrJbYCukOKj6tvgs=; b=dyr5Cv2AZ/V6Lw9ruvjLsfAFrvMmTkwSpdksowUfRU+jZfdWMGpNXyoo WGwA1qiRemKzSITM9LVVwiSUMSomORi68l9bat4siqpv1t8K8L9rEw4G3 G4XCpMj/CgLh89Oo0t6EkWFrwfS1JhNXqDBYaJXmUxp8iGTXNgMPUC9g7 0=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AfpeCbRLgbDbeDisGItmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCtad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEDlK//2Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AgCCXE1e/4cNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElL1AFbCstIAQLKgqECoNGA4pwgl+JYo4vglIDVAI?= =?us-ascii?q?HAQEBCQMBASUIAgQBAYRAAoIEJDgTAgMNAQEFAQEBAgEFBG2FNwyFZgEBAQE?= =?us-ascii?q?DEhEKEwEBNQIBDwIBBgIOAwQBAQ4TAwQDAgICHxEUCQgBAQQBDQUIBg0HgwW?= =?us-ascii?q?BfU0DHw8BAgySDZBnAoE5iGJ1gTKCfwEBBYEzAg5BgzoNC4IFBwMGgTiBU4p?= =?us-ascii?q?RGoFBP4ERR4JMPoIbSQEBAgEBGIFLKwmCWjKCLI1qkm6OeUQKgjuDb4I7gSW?= =?us-ascii?q?KW4RSmyuOb4h5gi6QHgIEAgQFAg4BAQWBaSKBWHAVO4JsUBgNjh0MFxWDO4U?= =?us-ascii?q?UhT90gSmMWgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,461,1574121600"; d="p7s'?scan'208,217";a="432631596" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Feb 2020 16:07:24 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 01JG7OPX003111 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Feb 2020 16:07:24 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Feb 2020 10:07:23 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Feb 2020 10:07:22 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Feb 2020 11:07:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jOqEY1vaY55JbG9lJg3X7G4gi4t83yfBqnMh9C0b8snYSMY43rx/ti51hshjH+kQXvvFBsGZL4IJo9O8KF2i1opjQVbjVVzMkbPzoS8iCjf3FfTvxp8VoBzA2h0INfWIt23i6muuIeN9hMPiA6mpSKqaFoDJXXTeDEx3kDc92pVcgw01OT7Ak1BXtL54FGBwQoHGN0K+klLNCfIIdTx1CAYooFoxI5gMkmbiu6zI+1dohpw5q8cv2OxOp0P4LmPNTFoNwlVEhHkifsGY++3AIz5KPzusuwE0oTlx/2bHrXwPcxjNvmLJ+mrydQgyQnNmGb+v7D7inFCAsyyKCbr/NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PLH+3bsECqgHwk0TIOtKbXHpwT28TUzVRSHxLl2moSE=; b=Lrum1LoSJNMfG9KHXs4hp4GJj7vkB7az/aal/ySROYR0FYSJ7/TAdVYNKP6op96Vd51y/LWnkZIpTyKKZSU9SaG953QF6uRJBl0oRs39ep7NLJmmbroAMX1iLZMObzSJ3mqdaat/4n6v3yV9gfaCta+8sOU3r0xCrRIrHoplNe/XksKGMelmVOn9nk9iZUl/7bsvH9+DeSBweMooYwNad/GfFT08ehkQVtUgszDhPwwiPm/HImg1PTClC3X4V6EFB20OMLcGppP9T8Vdk/FWpWYktmUp/nYEM27+M+3NTE4amKoPlzVkiW3YldUaIHr3ZHrWLz3VQbU0Lx76c2ScuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none 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=PLH+3bsECqgHwk0TIOtKbXHpwT28TUzVRSHxLl2moSE=; b=ukpYftORzx7PN/riP88mfnzK4D88fJLzLXUfXITIqTDctx/u6rOdStOEajjQw6/Ud7kJsX6ci/er+nhHfnEyOuFHj43pe563oDWXaX3BPC4+M0Sq85lhjHGVYmESz3EKqs4cxeH6dhTYBFRqlL6ZonYgAn1EfSorOoOFLiCc7fQ= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (20.177.147.96) by BL0PR11MB3058.namprd11.prod.outlook.com (20.177.204.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.23; Wed, 19 Feb 2020 16:07:13 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::ec9a:6707:d1ba:ce30]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::ec9a:6707:d1ba:ce30%7]) with mapi id 15.20.2729.033; Wed, 19 Feb 2020 16:07:13 +0000 From: "Eric Voit (evoit)" To: Qin Wu , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXiVDU7eC3gH6aESdCiWUYBGtpr6AE5dowA Date: Wed, 19 Feb 2020 16:07:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5522461c-09a9-4212-7532-08d7b555c84d x-ms-traffictypediagnostic: BL0PR11MB3058: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-forefront-prvs: 0318501FAE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(39860400002)(396003)(346002)(136003)(199004)(189003)(76116006)(81166006)(81156014)(53546011)(33656002)(110136005)(6506007)(26005)(4326008)(7696005)(52536014)(8936002)(8676002)(71200400001)(5660300002)(186003)(66946007)(478600001)(9326002)(66556008)(64756008)(66476007)(66616009)(9686003)(86362001)(66446008)(55016002)(2906002)(15650500001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3058; H:BL0PR11MB3122.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: BCL:0; x-microsoft-antispam-message-info: 4ssJKLGZjQE+dOsxSJhh/gKm2HzPPosFG6AdajpQDZ4Du/Xhp8gOvojpoNVweVU0QWMVkjPydIWFFlb7GQoUgbDEPESuPh28aacFcn+O6BmLoLt8G4oyL8qPQiWKCQ/uofXNTweSsxSF9ZriAgM1e86ODLQczBWQesrnqQXzRd2w84ObhgZ4dyjF683wUwAdkBqueHye1/SsGZGn700jk3AhPT1XUFTfEiTp+UdIRwoOmO1RsM/vutlk6AqDXagWOjWbL6TiczZ94xZhdPSxrYW5EXMH4Z+uFbur5/NefDuOXkfnls3enx+9lJwi3mfUkvzx65wMkYvejI35gfNZPAiBda3SQ0InR5BTms+1elSxM9VxzbVOFrQbyAb+ueX3xhVB8d0Urz1cX+tCR/PnvWKUuwrUv4FVR8GureoiMoY5SoJKZdgBJQLs7FBegRgFljX6KmRZalUuIPbVPIo0UrOKoOs6zbz4480duZiZTvwRMtGd7emPmXniwu8FKNnj5qCIdBAvJfgo1TGqr2MFWA== x-ms-exchange-antispam-messagedata: zjRe7VTqr/HjdAClaVbnhJb0kguEpG3QmZhLlwQYyNaLYJ6fJ/A+vmz457MB0wPsQV0nO8x9hd4IojZaJI+NZFr3SVWCUCSHIfzcXMtPNJbzHio/enIm8ty5kxWVqG9k9HhiSZz7kfTAcZeKrpypWA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0091_01D5E714.2FD5F190" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5522461c-09a9-4212-7532-08d7b555c84d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 16:07:13.2472 (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-CrossTenant-userprincipalname: wdWITcUNssHqxt/QffofjSCGquSFPPT+gPkJeEhw+7WByD25qaOpxjAVkoJzCP6/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3058 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 19 Feb 2020 16:07:30 -0000 ------=_NextPart_000_0091_01D5E714.2FD5F190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0092_01D5E714.2FD5F190" ------=_NextPart_001_0092_01D5E714.2FD5F190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Qin, =20 The parameter "yang-module" is just identifying the YANG module which = contains the definition of the encapsulated notification. I.e., some = reference to the transported objects is needed. =20 That said, the current solution doesn't provide a good solution when new = objects are augmented into an existing notification. So what you bring = up is a valid concern. Do you have suggestions on methods to handle = more complex augmented notifications? One possibility is to have a = leaf-list of augmenting models. Looking at the definitions of these = models would allow extraction of the prefixes used. There are more = complex possibilities here, however each adds to the payload. (It is = not an accident that IPFIX has template records.) =20 Eric=20 =20 From: Qin Wu =20 Sent: Thursday, February 13, 2020 5:09 AM To: Mahesh Jethanandani ; Eric Voit (evoit) = Cc: netconf@ietf.org Subject: RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? = (Was Re: Configured receiver capability exchange) =20 Eric:=20 Why structure message should tie to a single YANG data module with = =E2=80=9Cyang-module=E2=80=9D parameter, is this too restrictive? =20 -Qin =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 = 8:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Eric, =20 This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread. =20 You have indicated a desire that receiver capabilities should be = documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready. =20 To the WG, the authors have indicated a desire to wrap up this draft, = and would like us, the chairs, to issue a WGLC on it. Before we do that, = we wanted to ask if the WG believes that the document is ready, and that = there are no more issues that need to discussed/addressed by = draft-ietf-netconf-notification-messages document at this time. =20 Cheers. =20 Mahesh and Kent (as co-chairs). =20 On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > wrote: =20 Hi Mahesh, =20 During the IETF 106 session, there was discussion on how both a = publisher might know if there is receiver support for = draft-ietf-netconf-notification-messages. Section = 6 highlights several of the considerations. Relevant are the = following: =20 (a) Remote device capability discovery from the point of view of the = Publisher needs to be enhanced to know if the far end can interpret = notification messages type beyond RFC-5277, Section 4. =20 (b) This capability discovery question is relevant for both configured = subscription receivers and dynamic subscribers. =20 =20 (c) The capability discovery question can be generalized beyond = subscriptions, as there are many reasons to know the available = capabilities of the far end. =20 =20 (d) Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1). =20 =20 =20 Based on (a)-(d), coming up with a transport independent point-solution = within = draft-ietf-netconf-notification-messages *just* to = discover this single element of client functionality seems = overkill/heavyweight. =20 I was fine with letting this remote capabilities discovery question sit = for a while. However = = draft-ietf-netconf-https-notif shows that we now must address this = question. Specifically should the diagram section 1.4.1 show this = capability exchange? =20 =20 It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as = described in a ? Only if these questions are "yes", should the be = responded to with an "OK". =20 Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within = "draft-ietf-netconf-notification-messages"? =20 A strawman way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = notification with an HTTP Status 202 (Accepted)" = acknowledgement. This 202 would include body elements listing supported = receiver resources. Maybe something YANG encoded via = ietf-yang-structure-ext containing: =20 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 =20 What do you think of this approach? =20 Eric =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 =20 ------=_NextPart_001_0092_01D5E714.2FD5F190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Qin,

 

The parameter "yang-module" is just identifying = the YANG module which contains the definition of the encapsulated = notification.=C2=A0 I.e., some reference to the transported objects is = needed.

 

That said, the current solution doesn't provide a good = solution when new objects are augmented into an existing = notification.=C2=A0 So what you bring up is a valid concern.=C2=A0=C2=A0 = Do you have suggestions on methods to handle more complex augmented = notifications?=C2=A0 One possibility is to have a leaf-list of = augmenting models.=C2=A0 Looking at the definitions of these models = would allow extraction of the prefixes used.=C2=A0 There are more = complex possibilities here, however each adds to the payload.=C2=A0 = =C2=A0(It is not an accident that IPFIX has template = records.)

 

Eric

 

From:<= /b> = Qin Wu <bill.wu@huawei.com>
Sent: Thursday, February = 13, 2020 5:09 AM
To: Mahesh Jethanandani = <mjethanandani@gmail.com>; Eric Voit (evoit) = <evoit@cisco.com>
Cc: = netconf@ietf.org
Subject: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Eric: 

Why structure message should tie to a single YANG data module = with =E2=80=9Cyang-module=E2=80=9D parameter, is this too = restrictive?

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA: = netconf [mailto:netconf-bounces@ietf.org<= /a>] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 8:19
=E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) = <evoit@cisco.com>
=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi = Eric,

 

This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread.

 

You have indicated a desire that receiver capabilities = should be documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready.

 

To the WG, the authors have indicated a desire to wrap = up this draft, and would like us, the chairs, to issue a WGLC on it. = Before we do that, we wanted to ask if the WG believes that the document = is ready, and that there are no more issues that need to = discussed/addressed by draft-ietf-netconf-notification-messages document = at this time.

 

Cheers.

 

Mahesh and Kent (as co-chairs).

 

On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

 

I was fine = with letting this remote capabilities discovery question sit for a = while.   However draft-ietf-netconf-https-notif shows that we now must = address this question.  Specifically should the diagram section = 1.4.1 show this capability exchange?  

 

It turns out = that independent of draft-ietf-netconf-notification-messages, there = several questions in draft-ietf-netconf-https-notif which need to be = answered prior to the section 1.4.1 arrow: "Send HTTPS POST message = with YANG defined notification #1" anyway.  These questions = are:

  (1) = Does the targeted HTTPS receiver support configured = subscriptions?

  (2) = Can the targeted HTTP@ receiver accept a new subscription as described = in a <subscription-started>?

Only if = these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 

Add to this = a third question driven from (a)-(d):

  (3) = Does the receiver support the message type within = "draft-ietf-netconf-notification-messages"?

 

A strawman = way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext = containing:

 

  &= nbsp;   <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

  &= nbsp;     = <capabilities>

  &= nbsp;       = <capability>

  &= nbsp;         = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

  &= nbsp;       = </capability>

  &= nbsp; =     </capabilities>

=

  &= nbsp;   </foo>

 

What do you = think of this approach?

 

Eric

 

Mahesh Jethanandani

 

 

 

------=_NextPart_001_0092_01D5E714.2FD5F190-- ------=_NextPart_000_0091_01D5E714.2FD5F190 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMjE5MTYwMzE2WjAjBgkqhkiG 9w0BCQQxFgQUq51t8nppFuU57gKRJb0aGyR8Tp4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAiNIOmY8J6/A1VL72/frVx4tCfLLlIEh/D3pboqisUf+CGg/xy0KJxx+O9EJmpkPkT 2rBv+g9A/IAMmKnZKRJSpjgQepLtNUzXNBDw4IE+owImL+6f+EIXbfOutV9lfEBVe83NoSqnDuK7 9rFDPpurBhqvayJA4Ub5lcRzmeKVvT/FDl8t+rqVVXodpPpSBoAOPjW/KvQBEMiow4CiW4XILxDM GaFwcZfjv4uXmJsVc3e0Hbr8Vsh4dYS9TvuNB6onZhwLFR1TjMndCqtChgQGMKprRR+eQnOt75dM vME9ztmT70CUiH4asVW5tBtu8rdX2Y6aQmc1ZVpAT8mJbBypAAAAAAAA ------=_NextPart_000_0091_01D5E714.2FD5F190-- From nobody Thu Feb 20 17:29:50 2020 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 75FE2120288 for ; Thu, 20 Feb 2020 17:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_NSh9bKAL4Y for ; Thu, 20 Feb 2020 17:29:44 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F42120145 for ; Thu, 20 Feb 2020 17:29:44 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 270C88B99DAD47C27982; Fri, 21 Feb 2020 01:29:42 +0000 (GMT) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Feb 2020 01:29:41 +0000 Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 21 Feb 2020 01:29:40 +0000 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 21 Feb 2020 01:29:40 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.170]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0439.000; Fri, 21 Feb 2020 09:29:34 +0800 From: Qin Wu To: "Eric Voit (evoit)" , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXoVeMKpiDQpgh9TJW3asL2vtPa2g== Date: Fri, 21 Feb 2020 01:29:33 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.123] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD4A2C42dggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 21 Feb 2020 01:29:49 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD4A2C42dggeml511mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB3aGF0IEkgbGlrZSB0byBzZWUgaXMgdG8gaGF2ZSBhIGxlYWYtbGlzdCBvZiBhdWdtZW50 aW5nIG1vZGVscy4NCklmIGEgc2V0IG9mIHNwZWNpZmljIHRyYW5zcG9ydCBvYmplY3RzIHdpdGhp biB0aGUgbW9kZWwgY2FuIGJlIHRhcmdldGVkLCB0aGF0IHdpbGwgYWxzbyBiZSBuaWNlIHRvIGhh dmUuDQoNCi1RaW4NCuWPkeS7tuS6ujogRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBj aXNjby5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQy5pyIMjDml6UgMDowNw0K5pS25Lu25Lq6 OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRo YW5hbmRhbmlAZ21haWwuY29tPg0K5oqE6YCBOiBuZXRjb25mQGlldGYub3JnDQrkuLvpopg6IFJF OiBbbmV0Y29uZl0gV0dMQyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3Nh Z2VzPyAoV2FzIFJlOiBDb25maWd1cmVkIHJlY2VpdmVyIGNhcGFiaWxpdHkgZXhjaGFuZ2UpDQoN CkhpIFFpbiwNCg0KVGhlIHBhcmFtZXRlciAieWFuZy1tb2R1bGUiIGlzIGp1c3QgaWRlbnRpZnlp bmcgdGhlIFlBTkcgbW9kdWxlIHdoaWNoIGNvbnRhaW5zIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBl bmNhcHN1bGF0ZWQgbm90aWZpY2F0aW9uLiAgSS5lLiwgc29tZSByZWZlcmVuY2UgdG8gdGhlIHRy YW5zcG9ydGVkIG9iamVjdHMgaXMgbmVlZGVkLg0KDQpUaGF0IHNhaWQsIHRoZSBjdXJyZW50IHNv bHV0aW9uIGRvZXNuJ3QgcHJvdmlkZSBhIGdvb2Qgc29sdXRpb24gd2hlbiBuZXcgb2JqZWN0cyBh cmUgYXVnbWVudGVkIGludG8gYW4gZXhpc3Rpbmcgbm90aWZpY2F0aW9uLiAgU28gd2hhdCB5b3Ug YnJpbmcgdXAgaXMgYSB2YWxpZCBjb25jZXJuLiAgIERvIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIG9u IG1ldGhvZHMgdG8gaGFuZGxlIG1vcmUgY29tcGxleCBhdWdtZW50ZWQgbm90aWZpY2F0aW9ucz8g IE9uZSBwb3NzaWJpbGl0eSBpcyB0byBoYXZlIGEgbGVhZi1saXN0IG9mIGF1Z21lbnRpbmcgbW9k ZWxzLiAgTG9va2luZyBhdCB0aGUgZGVmaW5pdGlvbnMgb2YgdGhlc2UgbW9kZWxzIHdvdWxkIGFs bG93IGV4dHJhY3Rpb24gb2YgdGhlIHByZWZpeGVzIHVzZWQuICBUaGVyZSBhcmUgbW9yZSBjb21w bGV4IHBvc3NpYmlsaXRpZXMgaGVyZSwgaG93ZXZlciBlYWNoIGFkZHMgdG8gdGhlIHBheWxvYWQu ICAgKEl0IGlzIG5vdCBhbiBhY2NpZGVudCB0aGF0IElQRklYIGhhcyB0ZW1wbGF0ZSByZWNvcmRz LikNCg0KRXJpYw0KDQpGcm9tOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbTxtYWlsdG86Ymls bC53dUBodWF3ZWkuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAyMCA1OjA5 IEFNDQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFp bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj47IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBj aXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+DQpDYzogbmV0Y29uZkBpZXRmLm9yZzxt YWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbbmV0Y29uZl0gV0dMQyBvbiBk cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPyAoV2FzIFJlOiBDb25maWd1 cmVkIHJlY2VpdmVyIGNhcGFiaWxpdHkgZXhjaGFuZ2UpDQoNCkVyaWM6DQpXaHkgc3RydWN0dXJl IG1lc3NhZ2Ugc2hvdWxkIHRpZSB0byBhIHNpbmdsZSBZQU5HIGRhdGEgbW9kdWxlIHdpdGgg4oCc eWFuZy1tb2R1bGXigJ0gcGFyYW1ldGVyLCBpcyB0aGlzIHRvbyByZXN0cmljdGl2ZT8NCg0KLVFp bg0K5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDk u6PooaggTWFoZXNoIEpldGhhbmFuZGFuaQ0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0MeaciDI45pel IDg6MTkNCuaUtuS7tuS6ujogRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWls dG86ZXZvaXRAY2lzY28uY29tPj4NCuaKhOmAgTogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZz4NCuS4u+mimDogW25ldGNvbmZdIFdHTEMgb24gZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcz8gKFdhcyBSZTogQ29uZmlndXJlZCByZWNlaXZlciBj YXBhYmlsaXR5IGV4Y2hhbmdlKQ0KDQpIaSBFcmljLA0KDQpUaGlzIGUtbWFpbCB0cmlnZ2VycyB0 d28gcmVzcG9uc2VzLiBMZXQgdXMgZGVhbCB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmlj YXRpb24tbWVzc2FnZXMgaGVyZSwgYW5kIEkgd2lsbCBicmluZyB1cCBjb21tZW50cy9xdWVzdGlv bnMgcmVsYXRlZCB0byBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgaW4gdGhlIG90aGVy IHRocmVhZC4NCg0KWW91IGhhdmUgaW5kaWNhdGVkIGEgZGVzaXJlIHRoYXQgcmVjZWl2ZXIgY2Fw YWJpbGl0aWVzIHNob3VsZCBiZSBkb2N1bWVudGVkIGJ5IHRoZSB0cmFuc3BvcnQgc3BlY2lmaWMg ZHJhZnQsIGUuZy4gZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLCBhbmQgbm90IHRoaXMg ZHJhZnQuIEFzIHN1Y2ggeW91IGJlbGlldmUgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkuDQoNClRv IHRoZSBXRywgdGhlIGF1dGhvcnMgaGF2ZSBpbmRpY2F0ZWQgYSBkZXNpcmUgdG8gd3JhcCB1cCB0 aGlzIGRyYWZ0LCBhbmQgd291bGQgbGlrZSB1cywgdGhlIGNoYWlycywgdG8gaXNzdWUgYSBXR0xD IG9uIGl0LiBCZWZvcmUgd2UgZG8gdGhhdCwgd2Ugd2FudGVkIHRvIGFzayBpZiB0aGUgV0cgYmVs aWV2ZXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHksIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBt b3JlIGlzc3VlcyB0aGF0IG5lZWQgdG8gZGlzY3Vzc2VkL2FkZHJlc3NlZCBieSBkcmFmdC1pZXRm LW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzIGRvY3VtZW50IGF0IHRoaXMgdGltZS4NCg0K Q2hlZXJzLg0KDQpNYWhlc2ggYW5kIEtlbnQgKGFzIGNvLWNoYWlycykuDQoNCk9uIEphbiAxNSwg MjAyMCwgYXQgMTI6MjMgUE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb208bWFp bHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBNYWhlc2gsDQoNCkR1cmluZyB0aGUg SUVURiAxMDYgc2Vzc2lvbiwgdGhlcmUgd2FzIGRpc2N1c3Npb24gb24gaG93IGJvdGggYSBwdWJs aXNoZXIgbWlnaHQga25vdyBpZiB0aGVyZSBpcyByZWNlaXZlciBzdXBwb3J0IGZvciBkcmFmdC1p ZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2luY2x1 ZGVfdGV4dD0xPi4gIFNlY3Rpb24gNiBoaWdobGlnaHRzIHNldmVyYWwgb2YgdGhlIGNvbnNpZGVy YXRpb25zLiAgIFJlbGV2YW50IGFyZSB0aGUgZm9sbG93aW5nOg0KDQooYSkgUmVtb3RlIGRldmlj ZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBQdWJs aXNoZXIgbmVlZHMgdG8gYmUgZW5oYW5jZWQgdG8ga25vdyBpZiB0aGUgZmFyIGVuZCBjYW4gaW50 ZXJwcmV0IG5vdGlmaWNhdGlvbiBtZXNzYWdlcyB0eXBlIGJleW9uZCBSRkMtNTI3NywgU2VjdGlv biA0Lg0KDQooYikgVGhpcyBjYXBhYmlsaXR5IGRpc2NvdmVyeSBxdWVzdGlvbiBpcyByZWxldmFu dCBmb3IgYm90aCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiByZWNlaXZlcnMgYW5kIGR5bmFtaWMg c3Vic2NyaWJlcnMuDQoNCihjKSBUaGUgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgcXVlc3Rpb24gY2Fu IGJlIGdlbmVyYWxpemVkIGJleW9uZCBzdWJzY3JpcHRpb25zLCBhcyB0aGVyZSBhcmUgbWFueSBy ZWFzb25zIHRvIGtub3cgdGhlIGF2YWlsYWJsZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGZhciBlbmQu DQoNCihkKSBDYXBhYmlsaXR5IGRpc2NvdmVyeSBhZHZlcnRpc2VtZW50IGhhcyB0cmFkaXRpb25h bGx5IGJlZW4gZGlzY3Vzc2VkIHdpdGhpbiB0cmFuc3BvcnQgZG9jdW1lbnRzIChlLmcuIFJGQy02 MjQxIFNlY3Rpb24gOC4xKS4NCg0KDQpCYXNlZCBvbiAoYSktKGQpLCBjb21pbmcgdXAgd2l0aCBh IHRyYW5zcG9ydCBpbmRlcGVuZGVudCBwb2ludC1zb2x1dGlvbiB3aXRoaW4gZHJhZnQtaWV0Zi1u ZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlczxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLz9pbmNsdWRlX3Rl eHQ9MT4gKmp1c3QqIHRvIGRpc2NvdmVyIHRoaXMgc2luZ2xlIGVsZW1lbnQgb2YgY2xpZW50IGZ1 bmN0aW9uYWxpdHkgc2VlbXMgb3ZlcmtpbGwvaGVhdnl3ZWlnaHQuDQoNCkkgd2FzIGZpbmUgd2l0 aCBsZXR0aW5nIHRoaXMgcmVtb3RlIGNhcGFiaWxpdGllcyBkaXNjb3ZlcnkgcXVlc3Rpb24gc2l0 IGZvciBhIHdoaWxlLiAgIEhvd2V2ZXIgZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYt MDE+IHNob3dzIHRoYXQgd2Ugbm93IG11c3QgYWRkcmVzcyB0aGlzIHF1ZXN0aW9uLiAgU3BlY2lm aWNhbGx5IHNob3VsZCB0aGUgZGlhZ3JhbSBzZWN0aW9uIDEuNC4xIHNob3cgdGhpcyBjYXBhYmls aXR5IGV4Y2hhbmdlPw0KDQpJdCB0dXJucyBvdXQgdGhhdCBpbmRlcGVuZGVudCBvZiBkcmFmdC1p ZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLCB0aGVyZSBzZXZlcmFsIHF1ZXN0aW9u cyBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgd2hpY2ggbmVlZCB0byBiZSBhbnN3 ZXJlZCBwcmlvciB0byB0aGUgc2VjdGlvbiAxLjQuMSBhcnJvdzogIlNlbmQgSFRUUFMgUE9TVCBt ZXNzYWdlIHdpdGggWUFORyBkZWZpbmVkIG5vdGlmaWNhdGlvbiAjMSIgYW55d2F5LiAgVGhlc2Ug cXVlc3Rpb25zIGFyZToNCiAgKDEpIERvZXMgdGhlIHRhcmdldGVkIEhUVFBTIHJlY2VpdmVyIHN1 cHBvcnQgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zPw0KICAoMikgQ2FuIHRoZSB0YXJnZXRlZCBI VFRQQCByZWNlaXZlciBhY2NlcHQgYSBuZXcgc3Vic2NyaXB0aW9uIGFzIGRlc2NyaWJlZCBpbiBh IDxzdWJzY3JpcHRpb24tc3RhcnRlZD4/DQpPbmx5IGlmIHRoZXNlIHF1ZXN0aW9ucyBhcmUgInll cyIsIHNob3VsZCB0aGUgPHN1YnNjcmlwdGlvbi1zdGFydGVkPiBiZSByZXNwb25kZWQgdG8gd2l0 aCBhbiAiT0siLg0KDQpBZGQgdG8gdGhpcyBhIHRoaXJkIHF1ZXN0aW9uIGRyaXZlbiBmcm9tIChh KS0oZCk6DQogICgzKSBEb2VzIHRoZSByZWNlaXZlciBzdXBwb3J0IHRoZSBtZXNzYWdlIHR5cGUg d2l0aGluICJkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzIj8NCg0KQSBz dHJhd21hbiB3YXkgdG8gaGFuZGxlIHRoZSBhbGwgdGhyZWUgcXVlc3Rpb25zIHdpdGhpbiBkcmFm dC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgd291bGQgYmUgdG8gcmVzcG9uZCB0byBhIDxzdWJz Y3JpcHRpb24tc3RhcnRlZD4gbm90aWZpY2F0aW9uIHdpdGggYW4gSFRUUCBTdGF0dXMgMjAyIChB Y2NlcHRlZCkiIGFja25vd2xlZGdlbWVudC4gIFRoaXMgMjAyIHdvdWxkIGluY2x1ZGUgYm9keSBl bGVtZW50cyBsaXN0aW5nIHN1cHBvcnRlZCByZWNlaXZlciByZXNvdXJjZXMuICBNYXliZSBzb21l dGhpbmcgWUFORyBlbmNvZGVkIHZpYSBpZXRmLXlhbmctc3RydWN0dXJlLWV4dCBjb250YWluaW5n Og0KDQogICAgICA8Zm9vIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFz ZToxLjAiPg0KICAgICAgICA8Y2FwYWJpbGl0aWVzPg0KICAgICAgICAgIDxjYXBhYmlsaXR5Pg0K ICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtbm90aWZpY2F0aW9u LW1lc3NhZ2VzOjEuMA0KICAgICAgICAgIDwvY2FwYWJpbGl0eT4NCiAgICAgICAgPC9jYXBhYmls aXRpZXM+DQogICAgICA8L2Zvbz4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhpcyBhcHByb2Fj aD8NCg0KRXJpYw0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNv bTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABAAD4A2C42dggeml511mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgd2hhdCBJIGxpa2UgdG8gc2VlIGlzIHRvIGhhdmUgYSBs ZWFmLWxpc3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5JZiBhIHNldCBvZiBzcGVjaWZpYyB0cmFuc3BvcnQgb2JqZWN0cyB3aXRoaW4gdGhlIG1v ZGVsIGNhbiBiZSB0YXJnZXRlZCwgdGhhdCB3aWxsIGFsc28gYmUgbmljZSB0byBoYXZlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4tUWluDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpl dm9pdEBjaXNjby5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWP kemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAyMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjI8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIw PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAwOjA3PGJyPg0KPC9zcGFuPjxiPuaUtuS7 tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFFp biBXdSAmbHQ7YmlsbC53dUBodWF3ZWkuY29tJmd0OzsgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldGNvbmZAaWV0Zi5v cmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj4gUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29u Zi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2Fw YWJpbGl0eSBleGNoYW5nZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBRaW4sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHBhcmFtZXRlciAmcXVvdDt5YW5nLW1v ZHVsZSZxdW90OyBpcyBqdXN0IGlkZW50aWZ5aW5nIHRoZSBZQU5HIG1vZHVsZSB3aGljaCBjb250 YWlucyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZW5jYXBzdWxhdGVkIG5vdGlmaWNhdGlvbi4mbmJz cDsgSS5lLiwNCiBzb21lIHJlZmVyZW5jZSB0byB0aGUgdHJhbnNwb3J0ZWQgb2JqZWN0cyBpcyBu ZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhdCBzYWlkLCB0 aGUgY3VycmVudCBzb2x1dGlvbiBkb2Vzbid0IHByb3ZpZGUgYSBnb29kIHNvbHV0aW9uIHdoZW4g bmV3IG9iamVjdHMgYXJlIGF1Z21lbnRlZCBpbnRvIGFuIGV4aXN0aW5nIG5vdGlmaWNhdGlvbi4m bmJzcDsgU28gd2hhdA0KIHlvdSBicmluZyB1cCBpcyBhIHZhbGlkIGNvbmNlcm4uJm5ic3A7Jm5i c3A7IERvIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIG9uIG1ldGhvZHMgdG8gaGFuZGxlIG1vcmUgY29t cGxleCBhdWdtZW50ZWQgbm90aWZpY2F0aW9ucz8mbmJzcDsgT25lIHBvc3NpYmlsaXR5IGlzIHRv IGhhdmUgYSBsZWFmLWxpc3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuJm5ic3A7IExvb2tpbmcgYXQg dGhlIGRlZmluaXRpb25zIG9mIHRoZXNlIG1vZGVscyB3b3VsZCBhbGxvdyBleHRyYWN0aW9uIG9m IHRoZSBwcmVmaXhlcw0KIHVzZWQuJm5ic3A7IFRoZXJlIGFyZSBtb3JlIGNvbXBsZXggcG9zc2li aWxpdGllcyBoZXJlLCBob3dldmVyIGVhY2ggYWRkcyB0byB0aGUgcGF5bG9hZC4mbmJzcDsgJm5i c3A7KEl0IGlzIG5vdCBhbiBhY2NpZGVudCB0aGF0IElQRklYIGhhcyB0ZW1wbGF0ZSByZWNvcmRz Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FcmljDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUWlu IFd1ICZsdDs8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdl aS5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMywg MjAyMCA1OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBo cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPC9hPiZndDs7IEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRA Y2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbbmV0Y29uZl0gV0dMQyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90 aWZpY2F0aW9uLW1lc3NhZ2VzPyAoV2FzIFJlOiBDb25maWd1cmVkIHJlY2VpdmVyIGNhcGFiaWxp dHkgZXhjaGFuZ2UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+RXJpYzombmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF TiI+V2h5IHN0cnVjdHVyZSBtZXNzYWdlIHNob3VsZCB0aWUgdG8gYSBzaW5nbGUgWUFORyBkYXRh IG1vZHVsZSB3aXRoIOKAnHlhbmctbW9kdWxl4oCdIHBhcmFtZXRlciwgaXMgdGhpcyB0b28gcmVz dHJpY3RpdmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOIj4tUWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IG5ldGNvbmYgWzxhIGhy ZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7ku6Pooagg PC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+TWFoZXNoIEpl dGhhbmFuZGFuaTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe2 6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDIwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8 c3BhbiBsYW5nPSJFTi1VUyI+MTwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+Mjg8L3NwYW4+ 5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDg6MTk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRXJpYyBWb2l0 IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPmV2b2l0QGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYu b3JnIj4NCm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFtuZXRjb25mXSBXR0xD IG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENv bmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGlzIGUtbWFpbCB0cmlnZ2VycyB0d28gcmVzcG9uc2VzLiBMZXQg dXMgZGVhbCB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgaGVy ZSwgYW5kIEkgd2lsbCBicmluZyB1cCBjb21tZW50cy9xdWVzdGlvbnMgcmVsYXRlZCB0byBkcmFm dC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgaW4gdGhlIG90aGVyIHRocmVhZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBoYXZlIGluZGljYXRl ZCBhIGRlc2lyZSB0aGF0IHJlY2VpdmVyIGNhcGFiaWxpdGllcyBzaG91bGQgYmUgZG9jdW1lbnRl ZCBieSB0aGUgdHJhbnNwb3J0IHNwZWNpZmljIGRyYWZ0LCBlLmcuIGRyYWZ0LWlldGYtbmV0Y29u Zi1odHRwcy1ub3RpZiwgYW5kIG5vdCB0aGlzIGRyYWZ0LiBBcyBzdWNoIHlvdSBiZWxpZXZlIHRo YXQgdGhlIGRyYWZ0IGlzIHJlYWR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VG8gdGhlIFdHLCB0aGUgYXV0aG9ycyBoYXZlIGluZGljYXRlZCBhIGRl c2lyZSB0byB3cmFwIHVwIHRoaXMgZHJhZnQsIGFuZCB3b3VsZCBsaWtlIHVzLCB0aGUgY2hhaXJz LCB0byBpc3N1ZSBhIFdHTEMgb24gaXQuIEJlZm9yZSB3ZSBkbyB0aGF0LCB3ZSB3YW50ZWQgdG8g YXNrIGlmIHRoZSBXRyBiZWxpZXZlcyB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwgYW5kIHRo YXQgdGhlcmUNCiBhcmUgbm8gbW9yZSBpc3N1ZXMgdGhhdCBuZWVkIHRvIGRpc2N1c3NlZC9hZGRy ZXNzZWQgYnkgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyBkb2N1bWVu dCBhdCB0aGlzIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5DaGVlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5NYWhlc2ggYW5kIEtlbnQgKGFzIGNvLWNoYWlycykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBKYW4gMTUs IDIwMjAsIGF0IDEyOjIzIFBNLCBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBNYWhlc2gsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RHVyaW5nIHRoZSBJRVRGIDEwNiBzZXNzaW9uLCB0aGVyZSB3YXMgZGlzY3Vz c2lvbiBvbiBob3cgYm90aCBhIHB1Ymxpc2hlciBtaWdodCBrbm93IGlmIHRoZXJlIGlzIHJlY2Vp dmVyIHN1cHBvcnQgZm9yPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2luY2x1ZGVfdGV4dD0xIj48c3BhbiBz dHlsZT0iY29sb3I6Izk1NEY3MiI+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNz YWdlczwvc3Bhbj48L2E+Lg0KICZuYnNwO1NlY3Rpb24gNiBoaWdobGlnaHRzIHNldmVyYWwgb2Yg dGhlIGNvbnNpZGVyYXRpb25zLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOyZuYnNwOzwvc3Bhbj5SZWxldmFudCBhcmUgdGhlIGZvbGxvd2luZzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4oYSkgUmVtb3RlIGRldmljZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBmcm9tIHRoZSBw b2ludCBvZiB2aWV3IG9mIHRoZSBQdWJsaXNoZXIgbmVlZHMgdG8gYmUgZW5oYW5jZWQgdG8ga25v dyBpZiB0aGUgZmFyIGVuZCBjYW4gaW50ZXJwcmV0IG5vdGlmaWNhdGlvbiBtZXNzYWdlcw0KIHR5 cGUgYmV5b25kIFJGQy01Mjc3LCBTZWN0aW9uIDQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KGIpIFRoaXMgY2Fw YWJpbGl0eSBkaXNjb3ZlcnkgcXVlc3Rpb24gaXMgcmVsZXZhbnQgZm9yIGJvdGggY29uZmlndXJl ZCBzdWJzY3JpcHRpb24gcmVjZWl2ZXJzIGFuZCBkeW5hbWljIHN1YnNjcmliZXJzLiZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4oYykgVGhlIGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1ZXN0aW9uIGNhbiBiZSBnZW5lcmFs aXplZCBiZXlvbmQgc3Vic2NyaXB0aW9ucywgYXMgdGhlcmUgYXJlIG1hbnkgcmVhc29ucyB0byBr bm93IHRoZSBhdmFpbGFibGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBmYXIgZW5kLiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4oZCkgQ2FwYWJpbGl0eSBkaXNjb3ZlcnkgYWR2ZXJ0aXNlbWVudCBoYXMgdHJhZGl0 aW9uYWxseSBiZWVuIGRpc2N1c3NlZCB3aXRoaW4gdHJhbnNwb3J0IGRvY3VtZW50cyAoZS5nLiBS RkMtNjI0MSBTZWN0aW9uIDguMSkuJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJhc2VkIG9uIChhKS0oZCksIGNvbWluZyB1 cCB3aXRoIGEgdHJhbnNwb3J0IGluZGVwZW5kZW50IHBvaW50LXNvbHV0aW9uIHdpdGhpbjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLW1lc3NhZ2VzLz9pbmNsdWRlX3RleHQ9MSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIi PmRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM8L3NwYW4+PC9hPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4qanVzdCoNCiB0byBk aXNjb3ZlciB0aGlzIHNpbmdsZSBlbGVtZW50IG9mIGNsaWVudCBmdW5jdGlvbmFsaXR5IHNlZW1z IG92ZXJraWxsL2hlYXZ5d2VpZ2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FzIGZpbmUgd2l0aCBsZXR0 aW5nIHRoaXMgcmVtb3RlIGNhcGFiaWxpdGllcyBkaXNjb3ZlcnkgcXVlc3Rpb24gc2l0IGZvciBh IHdoaWxlLiZuYnNwOyZuYnNwOyBIb3dldmVyPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDEiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0 RjcyIj5kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWY8L3NwYW4+PC9hPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zaG93cw0KIHRoYXQgd2Ugbm93 IG11c3QgYWRkcmVzcyB0aGlzIHF1ZXN0aW9uLiZuYnNwOyBTcGVjaWZpY2FsbHkgc2hvdWxkIHRo ZSBkaWFncmFtIHNlY3Rpb24gMS40LjEgc2hvdyB0aGlzIGNhcGFiaWxpdHkgZXhjaGFuZ2U/Jm5i c3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkl0IHR1cm5zIG91dCB0aGF0IGluZGVwZW5kZW50IG9mIGRyYWZ0LWlldGYtbmV0 Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIHRoZXJlIHNldmVyYWwgcXVlc3Rpb25zIGluIGRy YWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3aGljaCBuZWVkIHRvIGJlIGFuc3dlcmVkDQog cHJpb3IgdG8gdGhlIHNlY3Rpb24gMS40LjEgYXJyb3c6ICZxdW90O1NlbmQgSFRUUFMgUE9TVCBt ZXNzYWdlIHdpdGggWUFORyBkZWZpbmVkIG5vdGlmaWNhdGlvbiAjMSZxdW90OyBhbnl3YXkuICZu YnNwO1RoZXNlIHF1ZXN0aW9ucyBhcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7ICgxKSBEb2VzIHRoZSB0YXJnZXRlZCBIVFRQUyByZWNlaXZlciBzdXBwb3J0IGNvbmZp Z3VyZWQgc3Vic2NyaXB0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsgKDIpIENhbiB0aGUgdGFyZ2V0ZWQgSFRUUEAgcmVjZWl2ZXIgYWNjZXB0IGEgbmV3IHN1YnNj cmlwdGlvbiBhcyBkZXNjcmliZWQgaW4gYSAmbHQ7c3Vic2NyaXB0aW9uLXN0YXJ0ZWQmZ3Q7Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9ubHkgaWYgdGhlc2UgcXVlc3Rpb25zIGFy ZSAmcXVvdDt5ZXMmcXVvdDssIHNob3VsZCB0aGUgJmx0O3N1YnNjcmlwdGlvbi1zdGFydGVkJmd0 OyBiZSByZXNwb25kZWQgdG8gd2l0aCBhbiAmcXVvdDtPSyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5B ZGQgdG8gdGhpcyBhIHRoaXJkIHF1ZXN0aW9uIGRyaXZlbiBmcm9tIChhKS0oZCk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICgzKSBEb2VzIHRoZSByZWNlaXZlciBzdXBw b3J0IHRoZSBtZXNzYWdlIHR5cGUgd2l0aGluICZxdW90O2RyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tbWVzc2FnZXMmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBzdHJhd21hbiB3YXkgdG8g aGFuZGxlIHRoZSBhbGwgdGhyZWUgcXVlc3Rpb25zIHdpdGhpbiBkcmFmdC1pZXRmLW5ldGNvbmYt aHR0cHMtbm90aWYgd291bGQgYmUgdG8gcmVzcG9uZCB0byBhICZsdDtzdWJzY3JpcHRpb24tc3Rh cnRlZCZndDsgbm90aWZpY2F0aW9uIHdpdGggYW4gSFRUUA0KIFN0YXR1cyAyMDIgKEFjY2VwdGVk KSZxdW90OyBhY2tub3dsZWRnZW1lbnQuJm5ic3A7IFRoaXMgMjAyIHdvdWxkIGluY2x1ZGUgYm9k eSBlbGVtZW50cyBsaXN0aW5nIHN1cHBvcnRlZCByZWNlaXZlciByZXNvdXJjZXMuJm5ic3A7IE1h eWJlIHNvbWV0aGluZyBZQU5HIGVuY29kZWQgdmlhIGlldGYteWFuZy1zdHJ1Y3R1cmUtZXh0IGNv bnRhaW5pbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDtmb28geG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4w JnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2FwYWJpbGl0aWVzJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2FwYWJpbGl0eSZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmll dGYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzOjEuMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7L2NhcGFiaWxpdHkmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvY2FwYWJpbGl0aWVz Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7L2ZvbyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaGF0IGRvIHlvdSB0aGluayBv ZiB0aGlzIGFwcHJvYWNoPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFoZXNo IEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86bWpldGhh bmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABAAD4A2C42dggeml511mbxchi_-- From nobody Fri Feb 21 05:50:55 2020 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 08743120114 for ; Fri, 21 Feb 2020 05:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Afksgitn; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Rll/+rbx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53YzI8EJFUgW for ; Fri, 21 Feb 2020 05:50:48 -0800 (PST) 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 9CA9E1200C5 for ; Fri, 21 Feb 2020 05:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38727; q=dns/txt; s=iport; t=1582293048; x=1583502648; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aJySOAEB5xcrBniExTHKwYWJB/unFskMiSSGKmxU1TQ=; b=AfksgitniBW1R3yoJouQmB/ahOtvimHHorX+Jq4cp9b/8AbQwQ+eKef0 pymJ3U+vU1qeL8/TnpEC3uFnQuoalxi+jINneZPYBkIHFhSwXs8jNxkEO xneHSmbV7fxNu4+yEufsTtfUudKurkz9RPLx/gnxIyqizwAM1scG6oPS+ 4=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AGaVOphNXhxq3lrEHO/Ul6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKU/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2MvnrcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZCgDn309e/4QNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWwrLSAECyoKhAqDRgOKcoJfiWOOMYJSA1QCBwEBAQk?= =?us-ascii?q?DAQElCAIEAQGEQAKCCiQ4EwIDDQEBBQEBAQIBBQRthTcMhWYBAQEBAxIRChM?= =?us-ascii?q?BATUCAQ8CAQYCDgMEAQEOEwECBAMCAgIfERQJCAEBBAENBQgGDQeDBYF9TQM?= =?us-ascii?q?fDwEOkTqQZwKBOYhidYEygn8BAQWBMwIOQYMeDQuCBQcDBoE4gVOKURqBQT+?= =?us-ascii?q?BEUeCTD6CG0kBAQIBARiBSysJglsygiyNbJJxjnlECoI8g2+CO4Emil6EUps?= =?us-ascii?q?ujnCIfIIukB0CBAIEBQIOAQEFgWkigVhwFTuCbFAYDY4dDBcVgzuFFIVBdIE?= =?us-ascii?q?pjQQBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,468,1574121600"; d="p7s'?scan'208,217";a="728940025" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Feb 2020 13:50:40 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 01LDodVo007910 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Feb 2020 13:50:40 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 07:50:39 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Feb 2020 08:50:38 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Feb 2020 08:50:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hMeNTAdPE6Oqb26lxLGOh5C3apZpQytBiiUbePQYdKtkBoMFvoMRWzECRrWiBobuYlXeR+PQ17dSICTW5CLffCnr2THa5KxjSjvGs5PCQxLR2RRevmFXqlksK9iweOQIsXkQYsc9xwBh7YTCH0QxoE2b7+GHMCrGeUsGrjR25Zx6cVGTHLrOVT5sg+f8X4Dc3sKeNw61UU+I4wuyxejak3MKNSSl9aXmmElMWps9CqH0arlneU4PdpntcdVnUli5ixTsKlPZ2tPXxg+1IypHCWShfl6/ErvvsCTjz9Gofdzy15ww2G7jFWw+c+IJTAOV/3tzleLNmkjb9R8fqWrgoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5G7dc6qafp2K6YtHBpHj0DhblSr9ybLkhscgx3iuBsk=; b=H+qzozIeWQYrd6N+o+cIqqiTdVEXkfwXOj2Fz4oE7YWlJC6iJ2ysTl32ZJo+OBBWCasItreQKV+Z6ki/rbrLgBDyvF/FvQUjkpUVoQDc+UjthPVvkGTU6n+Srm7TSd+bx57foaOZ9DqcEjE2z8qGoT4akUsjVBSlFZbObyeAZr3/PfemUpSuOKcIZUJ/TrW0LQyAaYf0NRfvVQ58if7pvJoyigRvsljla/jWweWlQILoDqzNuh5TfrV7ofNXa3deyQZUkmPmpz97w+yIkFmj1depdQv0E3xFqCHWqiUVaBLcy0du76dSFaRCPvxLGqhnC4eLhOx/ldte83FcvcgtZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none 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=5G7dc6qafp2K6YtHBpHj0DhblSr9ybLkhscgx3iuBsk=; b=Rll/+rbxQL4C2Z+Ks+3z9EgsZValYkjIDF7gSR7GvJ2OqZYTzYk/P1ElA1Dmtnn9D1z+RQMlrHaB2I3VU/4lPr1/ZR9jO1KAJiGGEb0svyg7DmFx/3fWS5VgCyrZpdF0t7oy0JR5x2tHetM9rMf1WLpzoG/sifJmaxonbp7IG7E= Received: from BYAPR11MB3125.namprd11.prod.outlook.com (2603:10b6:a03:8e::32) by BYAPR11MB3461.namprd11.prod.outlook.com (2603:10b6:a03:7b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Fri, 21 Feb 2020 13:50:37 +0000 Received: from BYAPR11MB3125.namprd11.prod.outlook.com ([fe80::d4d8:ffa2:1ad0:df81]) by BYAPR11MB3125.namprd11.prod.outlook.com ([fe80::d4d8:ffa2:1ad0:df81%5]) with mapi id 15.20.2729.033; Fri, 21 Feb 2020 13:50:37 +0000 From: "Eric Voit (evoit)" To: Qin Wu , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXoVeMKpiDQpgh9TJW3asL2vtPa2gAZf+Sg Date: Fri, 21 Feb 2020 13:50:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d093efa-dc8e-4c5b-1422-08d7b6d507d2 x-ms-traffictypediagnostic: BYAPR11MB3461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-forefront-prvs: 0320B28BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(39860400002)(136003)(366004)(376002)(189003)(199004)(64756008)(316002)(5660300002)(66946007)(4326008)(86362001)(6506007)(76116006)(66616009)(53546011)(478600001)(66446008)(66556008)(2906002)(66476007)(110136005)(33656002)(8676002)(186003)(81156014)(81166006)(52536014)(7696005)(15650500001)(71200400001)(8936002)(55016002)(9686003)(9326002)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3461; H:BYAPR11MB3125.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: BCL:0; x-microsoft-antispam-message-info: zKRyOi+YAj0kH9BQ4lDJR7XJvyy16I3BneXZH0WYQkA45SmIQQIVjNgJkBjqmTAt4NHir51aNGAeSEzVVqfRACoRYAVD18mAWLbgr/pwvt1x6a7gMjhd5NDcfTXQUYSC21KhUD0HgEE9qbK2mUpYUjBrdImI8dCz5s1dsVdiQ6EBDIxQlM8iJ7k/Ual94bRf3UhnCbmJyt72pxgyBTn+p/sOgztW1wIZrSImHXTpA0cLeF2+j9Ra9xF4TarosDiGmAwCozeTjrxG+Ob2j5NKJUPN2tbBCjNRk3TMnh3Pi13UxLf1+ukD4tqw3pvToPQvIUofjFyORrKjPIJtW1l38cOXu1ksQmpdI9bc15H+m2NBogf1RLJu79AcAjTgyryF7Z4cbCcgKmApijylhP+5uMzys49cCYFy3cfftyvOUrBAqXVbL8nuXFkxDTSPdM4aivawQ7BGrnpuxCMJevZzHtoZAWkUZ3LlSXIEODtqeYYAI5janm39HFadRWPVITeAZlsUw0UvLiMFVfEbTNpK1g== x-ms-exchange-antispam-messagedata: t+gt3LV0Lva3tsr1YhHCbDUoTeu3dfQebHB2FmFtI9b37eOasJPh5TJa+C7C9ICjjqbpGIp9Exb3czlnXqjdyfwgOQECBqPaEvuL9WA7ffJ7JHIhBqkSf7o98FMfQjDT4J/IGtsxrPbfLRsmRK1Wbw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_047B_01D5E893.F9E88760" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4d093efa-dc8e-4c5b-1422-08d7b6d507d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 13:50:37.0852 (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-CrossTenant-userprincipalname: PoEGitibpcn5cwOcbSZTCuR3O1MlVP8TgYAXlWOmDif+gEZPLk4OO3gU1gjagsZ7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3461 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 21 Feb 2020 13:50:52 -0000 ------=_NextPart_000_047B_01D5E893.F9E88760 Content-Type: multipart/alternative; boundary="----=_NextPart_001_047C_01D5E893.F9E88760" ------=_NextPart_001_047C_01D5E893.F9E88760 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Qin, =20 If the WG wants it, I have no problem adding this leaf-list. Good = catch. =20 Beyond that, do you have examples of such transport specific objects? = Transported objects would be named within the notification itself. And = the prefix associated with the object should be mappable. =20 =20 I believe it should be up to the receiver to correlate the prefix to the = right model. And putting more into each notification would make for = overhead. =20 Eric =20 From: Qin Wu, February 20, 2020 8:30 PM Yes, what I like to see is to have a leaf-list of augmenting models. If a set of specific transport objects within the model can be targeted, = that will also be nice to have. =20 -Qin=20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B42=E6=9C=8820=E6=97=A5 = 0:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu >; Mahesh Jethanandani = > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Qin, =20 The parameter "yang-module" is just identifying the YANG module which = contains the definition of the encapsulated notification. I.e., some = reference to the transported objects is needed. =20 That said, the current solution doesn't provide a good solution when new = objects are augmented into an existing notification. So what you bring = up is a valid concern. Do you have suggestions on methods to handle = more complex augmented notifications? One possibility is to have a = leaf-list of augmenting models. Looking at the definitions of these = models would allow extraction of the prefixes used. There are more = complex possibilities here, however each adds to the payload. (It is = not an accident that IPFIX has template records.) =20 Eric=20 =20 From: Qin Wu >=20 Sent: Thursday, February 13, 2020 5:09 AM To: Mahesh Jethanandani >; Eric Voit (evoit) > Cc: netconf@ietf.org =20 Subject: RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? = (Was Re: Configured receiver capability exchange) =20 Eric:=20 Why structure message should tie to a single YANG data module with = =E2=80=9Cyang-module=E2=80=9D parameter, is this too restrictive? =20 -Qin =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 = 8:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Eric, =20 This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread. =20 You have indicated a desire that receiver capabilities should be = documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready. =20 To the WG, the authors have indicated a desire to wrap up this draft, = and would like us, the chairs, to issue a WGLC on it. Before we do that, = we wanted to ask if the WG believes that the document is ready, and that = there are no more issues that need to discussed/addressed by = draft-ietf-netconf-notification-messages document at this time. =20 Cheers. =20 Mahesh and Kent (as co-chairs). =20 On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > wrote: =20 Hi Mahesh, =20 During the IETF 106 session, there was discussion on how both a = publisher might know if there is receiver support for = draft-ietf-netconf-notification-messages. Section = 6 highlights several of the considerations. Relevant are the = following: =20 (a) Remote device capability discovery from the point of view of the = Publisher needs to be enhanced to know if the far end can interpret = notification messages type beyond RFC-5277, Section 4. =20 (b) This capability discovery question is relevant for both configured = subscription receivers and dynamic subscribers. =20 =20 (c) The capability discovery question can be generalized beyond = subscriptions, as there are many reasons to know the available = capabilities of the far end. =20 =20 (d) Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1). =20 =20 =20 Based on (a)-(d), coming up with a transport independent point-solution = within = draft-ietf-netconf-notification-messages *just* to = discover this single element of client functionality seems = overkill/heavyweight. =20 I was fine with letting this remote capabilities discovery question sit = for a while. However = = draft-ietf-netconf-https-notif shows that we now must address this = question. Specifically should the diagram section 1.4.1 show this = capability exchange? =20 =20 It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as = described in a ? Only if these questions are "yes", should the be = responded to with an "OK". =20 Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within = "draft-ietf-netconf-notification-messages"? =20 A strawman way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = notification with an HTTP Status 202 (Accepted)" = acknowledgement. This 202 would include body elements listing supported = receiver resources. Maybe something YANG encoded via = ietf-yang-structure-ext containing: =20 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 =20 What do you think of this approach? =20 Eric =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 =20 ------=_NextPart_001_047C_01D5E893.F9E88760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Qin,

 

If the WG = wants it, I have no problem adding this leaf-list.=C2=A0 Good = catch.

 

Beyond that, = do you have examples of such transport specific objects?=C2=A0=C2=A0 = Transported objects would be named within the notification itself.=C2=A0 = And the prefix associated with the object should be mappable.=C2=A0 =

 

I believe it = should be up to the receiver to correlate the prefix to the right model. = And putting more into each notification would make for = overhead.

 

Eric

 

From:<= /b> = Qin Wu, February 20, 2020 8:30 PM

Yes, what I like to see is to have a = leaf-list of augmenting models.

If a set of specific transport objects = within the model can be targeted, that will also be nice to = have.

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA= : Eric Voit (evoit) [mailto:evoit@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B42=E6=9C=8820=E6=97=A5 0:07
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>; Mahesh = Jethanandani <mjethanandani@gmail.com>=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi = Qin,

 

The = parameter "yang-module" is just identifying the YANG module = which contains the definition of the encapsulated notification.  = I.e., some reference to the transported objects is = needed.

 

That said, = the current solution doesn't provide a good solution when new objects = are augmented into an existing notification.  So what you bring up = is a valid concern.   Do you have suggestions on methods to = handle more complex augmented notifications?  One possibility is to = have a leaf-list of augmenting models.  Looking at the definitions = of these models would allow extraction of the prefixes used.  There = are more complex possibilities here, however each adds to the = payload.   (It is not an accident that IPFIX has template = records.)

 

Eric =

 

From: Qin Wu <bill.wu@huawei.com> =
Sent: Thursday, February 13, 2020 5:09 AM
To: = Mahesh Jethanandani <mjethanandani@gmail.com>; = Eric Voit (evoit) <evoit@cisco.com>
Cc: netconf@ietf.org
Subject: = RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: = Configured receiver capability = exchange)

 

Eric: 

Why structure message should tie to = a single YANG data module with =E2=80=9Cyang-module=E2=80=9D parameter, = is this too restrictive?

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA= : netconf [mailto:netconf-bounces@ietf.org<= /a>] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 8:19
=E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) = <evoit@cisco.com>
=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi = Eric,

 

This = e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread.

 

You = have indicated a desire that receiver capabilities should be documented = by the transport specific draft, e.g. draft-ietf-netconf-https-notif, = and not this draft. As such you believe that the draft is = ready.

 

To = the WG, the authors have indicated a desire to wrap up this draft, and = would like us, the chairs, to issue a WGLC on it. Before we do that, we = wanted to ask if the WG believes that the document is ready, and that = there are no more issues that need to discussed/addressed by = draft-ietf-netconf-notification-messages document at this = time.

 

Cheers.

<= div>

 

Mahesh and Kent (as = co-chairs).

 

(d) Capability discovery advertisement has traditionally = been discussed within transport documents (e.g. RFC-6241 Section = 8.1).   

 

 

I was fine with letting this remote capabilities discovery = question sit for a while.   However draft-ietf-netconf-https-notif shows that we now must = address this question.  Specifically should the diagram section = 1.4.1 show this capability exchange?  

 

It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway.  These questions = are:

  (1) Does the targeted HTTPS receiver support = configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a new = subscription as described in a = <subscription-started>?

Only if these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 

Add to this a third question driven from = (a)-(d):

  (3) Does the receiver support the message type = within = "draft-ietf-netconf-notification-messages"?

 

A strawman way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext = containing:

 

      <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

        = <capabilities>

          = <capability>

          = ;  = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

          = </capability>

    =     </capabilities>

=

      = </foo>

 

What do you think of this = approach?

 

Eric

 

Mahesh = Jethanandani

 

 

 

------=_NextPart_001_047C_01D5E893.F9E88760-- ------=_NextPart_000_047B_01D5E893.F9E88760 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMjIxMTM1MDMyWjAjBgkqhkiG 9w0BCQQxFgQUDxJksYeYLwx+MkBF7SJ4MNeFXIMwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQA4RQSBLmXQHhyeMJ8mVDR28XJKlHpCRRgXTTCzhNeb7qTSDrokxGzH9vhvgM47gv1L IueimbhCDrrwqpVVfQ2Vfj8bP1BaOk037MmGijl3XZTgROO3kT3DXVSgkcIwUrV+3ykQO4DML3nA grs3uI63cbWIXrOJPaJrgk+DICviKomu+wHvHCMl669Z1chx+JhkgLjOzVQQlzZQcLmFMWBQ2YLs ScVNb/URosKbrlzrMiMOR1CJquTetXyTiCJ9SJE31io037R8P6UO1RxfxfAXJlTeFS6fmSrlyNxP V9dsXZFBEHNkZh94FJBeTbCVQYieH0qTizTcyMnkwWppZ2glAAAAAAAA ------=_NextPart_000_047B_01D5E893.F9E88760-- From nobody Sun Feb 23 03:13:09 2020 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 120953A0CA8 for ; Sun, 23 Feb 2020 03:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 UpUGnh5MFdIQ for ; Sun, 23 Feb 2020 03:13:05 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D253A0CA7 for ; Sun, 23 Feb 2020 03:13:04 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 57DBF2E76737 for ; Sun, 23 Feb 2020 12:12:59 +0100 (CET) Received: from s630.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 39A952E27812 for ; Sun, 23 Feb 2020 12:12:59 +0100 (CET) Received: from s472.loopia.se (unknown [172.22.191.6]) by s630.loopia.se (Postfix) with ESMTP id 30B8013ABEB2 for ; Sun, 23 Feb 2020 12:12:59 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s645.loopia.se ([172.22.191.6]) by s472.loopia.se (s472.loopia.se [172.22.190.12]) (amavisd-new, port 10024) with LMTP id 9qxxHTIPtYg9 for ; Sun, 23 Feb 2020 12:12:58 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: olof@hagsand.se X-Loopia-Originating-IP: 85.227.89.255 Received: from [10.0.0.14] (ua-85-227-89-255.bbcust.telenor.se [85.227.89.255]) (Authenticated sender: olof@hagsand.se) by s645.loopia.se (Postfix) with ESMTPSA id 7C502156E555 for ; Sun, 23 Feb 2020 12:12:58 +0100 (CET) To: netconf@ietf.org From: Olof Hagsand Message-ID: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> Date: Sun, 23 Feb 2020 12:12:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [netconf] Question on restconf empty list reply 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: Sun, 23 Feb 2020 11:13:08 -0000 Hello, In a restconf GET request of an empty YANG list using JSON encoding, what is the expected reply? I.e. using a yang list "x" in module "m" (pseudo http): GET /restconf/data/m:x Accept: application/yang-data+json Is the reply (1): HTTP/1.1 200 OK { "m:x": [] } or should it be (2) "404 Not Found" status-line and error-tag value "invalid-value"? Apologizes that this is a basic question, and I am sure this is resolved properly, but we have some discussions with users on how to properly interpret the description of GET in RFC 8040 Section 4.3 and RFC 7951. Regards, Olof Hagsand, Clixon maintainer From nobody Sun Feb 23 03:28:37 2020 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 B94EA3A0CE5 for ; Sun, 23 Feb 2020 03:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=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=jacobsuniversity.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 GuMtxdoHNte3 for ; Sun, 23 Feb 2020 03:28:34 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50062.outbound.protection.outlook.com [40.107.5.62]) (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 D4BF23A0CE4 for ; Sun, 23 Feb 2020 03:28:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=je+t/K3E2cIMvsvob1zAouGe6Hoarac3kHFq3NK39VHosTB3zOaiH9ucyV4uZISkH9CuX8lLWdu543RGlraPY9tbAtyTpQVH/VJgp0l3B6lTJ2woPz6l41q+TidZrobyvkceqfdcqCqEiJ5+yJJH1Jxlsg5U/j9TKvR4Cpe5mG6ahl+98gVRwURM2mHwtcpknvlbbg2MlgjoTmyP7NdKbDCEn62qFqV2XL5EgjrXbcSN1iOFWb5izpRC1FYu/Kbs9vY2azd4kpdvvByErOtwrAv+XUXRn+Ed26Bh6NWHUm8i6+Magj9M5YQv6B+Lk0Ns+SbJCO41e1WDbye3OVNoFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLMKMl809of1WZoCcud2wHN5Boe8qdGaRHVptc91B4w=; b=ZqZQwuIavAtfeHEt3ciSPRJ4OS15W3i3+9txpKAqhu+Vs17RGdgs46tDsWoebTSd1eo2nr26ewz5KcAsK5/6uH4UZPyt3XeVJf//FAxflIt2eccEsQ8swUNOxRSCY0S73GXXfKKiAcektNtn1SR6/VYE76gH2ZpR9cC1x8XZImsTvUbChkZpFixxZMlOpk/JSvrRzW5ieM8qPWfB29mStfgo5kpRb1i+eJjzBDRL5gL/O1sWwioy+JfReJpg31aOj35I6FiyApLiQo1Br6FzSrs4s7nHqgJORXYWkbpYT6Ps1oq2W5/Jdo7jXLY158Jdxs8+5QySVP/5+Ca8KjT9yA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLMKMl809of1WZoCcud2wHN5Boe8qdGaRHVptc91B4w=; b=jmt/WoVWRJOPMab24yHEV7ZGnAsKnJlXzzsmEsU+bKQQJYFlsaEJP7aYcmt4BJdhvOluVZEMTPwN7CpHrE+lbuGJq8uLcd+cH3lpEcoPfIhiQyts37oQTHRuPLmb5iYBC14HBtp9sOo0VfR0BFGppwe2qMZxyevGuRmQpOvkLlo= Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0567.EURP190.PROD.OUTLOOK.COM (10.175.241.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Sun, 23 Feb 2020 11:28:30 +0000 Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::2cda:e754:4835:c579]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::2cda:e754:4835:c579%3]) with mapi id 15.20.2750.021; Sun, 23 Feb 2020 11:28:30 +0000 Received: from localhost (212.201.44.247) by AM0PR04CA0003.eurprd04.prod.outlook.com (2603:10a6:208:122::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Sun, 23 Feb 2020 11:28:29 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Olof Hagsand CC: "netconf@ietf.org" Thread-Topic: [netconf] Question on restconf empty list reply Thread-Index: AQHV6jpF6bW55g7FYkmq2k0c8YfQS6gopEmA Date: Sun, 23 Feb 2020 11:28:30 +0000 Message-ID: <20200223112829.rjd3zf53rybmmzvc@anna.jacobs.jacobs-university.de> References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> In-Reply-To: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR04CA0003.eurprd04.prod.outlook.com (2603:10a6:208:122::16) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.201.44.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80fd57a4-7a79-42b1-429a-08d7b8538216 x-ms-traffictypediagnostic: DB6P190MB0567: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(136003)(346002)(396003)(376002)(366004)(199004)(189003)(26005)(186003)(81166006)(8936002)(966005)(16526019)(81156014)(52116002)(8676002)(86362001)(6916009)(4326008)(6486002)(956004)(66476007)(66556008)(66946007)(2906002)(3450700001)(6666004)(6496006)(71200400001)(478600001)(1076003)(5660300002)(66446008)(64756008)(786003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0567; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +2YjLxvOQTi+M5iNdZJdnuniOBK2mAuvsXAV2edugkik0WquLvoe4GkCkZGqgB/R0ycLPtPFOdhg16p3Qt9XES9JzY6XocfXY95dzeuWF5/QHtrFtEKpeeXb9lWi3cyJ/1qNZy6FpUdsvUFRCYay4eQTpNuK5zpHdRPc2cVQ+ZPDcQpElel+BhLErIf0+fl6nVbZTN1dSoFa2Qwdb4o4JbuoUC0UteKXmRP88gPRF7WTRvtjuv1UysbKz+Dzli/N/NSpjDomWEBLm4rg1PoD5B9EvgXqDZKnyVa6h+A3Fv4o3wTsHx4VSq5fLWATELq/fQd36QKkUcDEbSMgECUH4Skg3tArUVWwL/Jwr58lxN3YVF1HuwBKS8YKcPsXAc+cbwc2CegpyotPFNqQA2b86QuPHGqyBpx4hvupXtP4ei8U25WfbSO3ZlwwqN3L9YsoZjZ+D1uCGn/ViJU2kelX6oz0zSzPkoe4PBvopsIMmFFTJSUuWDn3dA/RIpkoFR3L0jba3MZpwKvEUPutS4DwNA== x-ms-exchange-antispam-messagedata: hmhsYCEHbOZUnTEyqyqolg/YSG9dfgJwaJ6DbXULLai2WrO+h+VaJuIEFgjgdCwjOi9GQLiRW5xPyAH65TF0R+z0RWWeTbd0+ZSIbCToPkW6l2Z5wsSdbTN8huPagBCPr3VQMqmkiXcGooKqe97mow== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <215CD27108A069439795416AF11E8D96@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 80fd57a4-7a79-42b1-429a-08d7b8538216 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2020 11:28:30.2616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P/SIyuWOO0quOx7k+ox5c4leQNch9E1QOmCQbXGtOCuyHXjz/xjDPkx3V5g6bmRZuSeKWAwaVdp2FWhmWsZHDz7M0pRCEkO9FTaE8mYfFkw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0567 Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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: Sun, 23 Feb 2020 11:28:36 -0000 My reading of RFC 7951 section 5.4 is that an empty list results in an empty JSON array. A related question is likely whether the empty list exists or not. RFC 8040 says a 404 response indicates that the resource does not exist (or is not accessible). So both responses may be reasonable, depending on the existence/accessibility of the resource. /js On Sun, Feb 23, 2020 at 12:12:58PM +0100, Olof Hagsand wrote: > Hello, > In a restconf GET request of an empty YANG list using JSON encoding, > what is the expected reply? I.e. using a yang list "x" in module "m" > (pseudo http): > GET /restconf/data/m:x > Accept: application/yang-data+json >=20 > Is the reply (1): > HTTP/1.1 200 OK > { > "m:x": [] > } >=20 > or should it be (2) > "404 Not Found" status-line and error-tag value "invalid-value"? >=20 > Apologizes that this is a basic question, and I am sure this is resolved > properly, but we have some discussions with users on how to properly > interpret the description of GET in RFC 8040 Section 4.3 and RFC 7951. >=20 > Regards, > Olof Hagsand, > Clixon maintainer >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Feb 23 12:01:46 2020 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 AE22D3A0DD9 for ; Sun, 23 Feb 2020 12:01:44 -0800 (PST) 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, 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 kw_AWbNI5o6k for ; Sun, 23 Feb 2020 12:01:42 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC333A0DD5 for ; Sun, 23 Feb 2020 12:01:41 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 219B52E608B1 for ; Sun, 23 Feb 2020 21:01:37 +0100 (CET) Received: from s630.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 0305D2E27DC9; Sun, 23 Feb 2020 21:01:37 +0100 (CET) Received: from s475.loopia.se (unknown [172.22.191.5]) by s630.loopia.se (Postfix) with ESMTP id EB9C613ABDB1; Sun, 23 Feb 2020 21:01:36 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s498.loopia.se ([172.22.191.5]) by s475.loopia.se (s475.loopia.se [172.22.190.15]) (amavisd-new, port 10024) with LMTP id BV-LrmXr6V-K; Sun, 23 Feb 2020 21:01:36 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: olof@hagsand.se X-Loopia-Originating-IP: 85.227.89.255 Received: from [10.0.0.14] (ua-85-227-89-255.bbcust.telenor.se [85.227.89.255]) (Authenticated sender: olof@hagsand.se) by s498.loopia.se (Postfix) with ESMTPSA id 60CFB470823; Sun, 23 Feb 2020 21:01:36 +0100 (CET) To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Cc: "netconf@ietf.org" References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200223112829.rjd3zf53rybmmzvc@anna.jacobs.jacobs-university.de> From: Olof Hagsand Message-ID: <6ed11152-ab3d-d42b-f983-908de32bbef8@hagsand.se> Date: Sun, 23 Feb 2020 21:01:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200223112829.rjd3zf53rybmmzvc@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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: Sun, 23 Feb 2020 20:01:45 -0000 Thank you for the answer! What does "the empty lists exists or not" mean, how is an existing empty list different from a non-existent list wrt YANG? I would think that a YANG list have instances (= it exists), or it does not have instances (= is empty = does not exist). Another related question is how the same request but for XML encoding should be treated, ie a YANG list x with no elements (empty list/non-existent)? GET /restconf/data/m:x Accept: application/yang-data+xml Is the reply "404 Not Found" status-line and error-tag value "invalid-value" (following the list resource doe snot exist) or, following the JSON [] (existing empty list) reasoning, a "204 No Content"? Again apologizes for these basic questions, Regards, Olof Hagsand On 2020-02-23 12:28, Schönwälder, Jürgen wrote: > My reading of RFC 7951 section 5.4 is that an empty list results in an > empty JSON array. A related question is likely whether the empty list > exists or not. RFC 8040 says a 404 response indicates that the > resource does not exist (or is not accessible). So both responses may > be reasonable, depending on the existence/accessibility of the resource. > > /js > > On Sun, Feb 23, 2020 at 12:12:58PM +0100, Olof Hagsand wrote: >> Hello, >> In a restconf GET request of an empty YANG list using JSON encoding, >> what is the expected reply? I.e. using a yang list "x" in module "m" >> (pseudo http): >> GET /restconf/data/m:x >> Accept: application/yang-data+json >> >> Is the reply (1): >> HTTP/1.1 200 OK >> { >> "m:x": [] >> } >> >> or should it be (2) >> "404 Not Found" status-line and error-tag value "invalid-value"? >> >> Apologizes that this is a basic question, and I am sure this is resolved >> properly, but we have some discussions with users on how to properly >> interpret the description of GET in RFC 8040 Section 4.3 and RFC 7951. >> >> Regards, >> Olof Hagsand, >> Clixon maintainer >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Feb 24 03:33:13 2020 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 E7D543A0835 for ; Mon, 24 Feb 2020 03:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 58ZZJqq_4pM0 for ; Mon, 24 Feb 2020 03:33:09 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0B03A0834 for ; Mon, 24 Feb 2020 03:33:09 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C710AF80725410F8E201; Mon, 24 Feb 2020 11:33:05 +0000 (GMT) Received: from lhreml725-chm.china.huawei.com (10.201.108.76) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Feb 2020 11:33:05 +0000 Received: from lhreml725-chm.china.huawei.com (10.201.108.76) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 24 Feb 2020 11:33:04 +0000 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Mon, 24 Feb 2020 11:33:04 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.89]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Mon, 24 Feb 2020 19:33:01 +0800 From: Qin Wu To: "Eric Voit (evoit)" , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXrBac3eal5GwGBScmdBP+kDouhpw== Date: Mon, 24 Feb 2020 11:33:01 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.123] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD4D630Cdggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 24 Feb 2020 11:33:12 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD4D630Cdggeml511mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYzoNCkkgYW0gd29uZGVyaW5nIGlmIGEgc2V0IG9mIG5vdGlmaWNhdGlvbiBwZXIgbWVzc2Fn ZSBjYW4gYmUgY29tcHJlc3NlZCBiZWZvcmUgYmVpbmcgYnVuZGxlZCwgaWYgdGhlIGFuc3dlciBp cyB5ZXMsIEkgdGhpbmsgZGF0YSBjb21wcmVzc2lvbiBhbGdvcml0aG0gc2hvdWxkIGJlIHNwZWNp ZmllZC4NCkluIGFkZGl0aW9uLCBzdWJzY3JpcHRpb24gbW9kZSBvciB0eXBlIChwZXJpb2RpY2Fs LCBvbiBjaGFuZ2UpIGNhbiBiZSBpbmNsdWRlZCBhcyB3ZWxsLg0KDQotUWluDQrlj5Hku7bkuro6 IEVyaWMgVm9pdCAoZXZvaXQpIFttYWlsdG86ZXZvaXRAY2lzY28uY29tXQ0K5Y+R6YCB5pe26Ze0 OiAyMDIw5bm0MuaciDIx5pelIDIxOjUxDQrmlLbku7bkuro6IFFpbiBXdSA8YmlsbC53dUBodWF3 ZWkuY29tPjsgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQrm ioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRy YWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3Vy ZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSkNCg0KSGkgUWluLA0KDQpJZiB0aGUgV0cg d2FudHMgaXQsIEkgaGF2ZSBubyBwcm9ibGVtIGFkZGluZyB0aGlzIGxlYWYtbGlzdC4gIEdvb2Qg Y2F0Y2guDQoNCkJleW9uZCB0aGF0LCBkbyB5b3UgaGF2ZSBleGFtcGxlcyBvZiBzdWNoIHRyYW5z cG9ydCBzcGVjaWZpYyBvYmplY3RzPyAgIFRyYW5zcG9ydGVkIG9iamVjdHMgd291bGQgYmUgbmFt ZWQgd2l0aGluIHRoZSBub3RpZmljYXRpb24gaXRzZWxmLiAgQW5kIHRoZSBwcmVmaXggYXNzb2Np YXRlZCB3aXRoIHRoZSBvYmplY3Qgc2hvdWxkIGJlIG1hcHBhYmxlLg0KDQpJIGJlbGlldmUgaXQg c2hvdWxkIGJlIHVwIHRvIHRoZSByZWNlaXZlciB0byBjb3JyZWxhdGUgdGhlIHByZWZpeCB0byB0 aGUgcmlnaHQgbW9kZWwuIEFuZCBwdXR0aW5nIG1vcmUgaW50byBlYWNoIG5vdGlmaWNhdGlvbiB3 b3VsZCBtYWtlIGZvciBvdmVyaGVhZC4NCg0KRXJpYw0KDQpGcm9tOiBRaW4gV3UsIEZlYnJ1YXJ5 IDIwLCAyMDIwIDg6MzAgUE0NClllcywgd2hhdCBJIGxpa2UgdG8gc2VlIGlzIHRvIGhhdmUgYSBs ZWFmLWxpc3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuDQpJZiBhIHNldCBvZiBzcGVjaWZpYyB0cmFu c3BvcnQgb2JqZWN0cyB3aXRoaW4gdGhlIG1vZGVsIGNhbiBiZSB0YXJnZXRlZCwgdGhhdCB3aWxs IGFsc28gYmUgbmljZSB0byBoYXZlLg0KDQotUWluDQrlj5Hku7bkuro6IEVyaWMgVm9pdCAoZXZv aXQpIFttYWlsdG86ZXZvaXRAY2lzY28uY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0MuaciDIw 5pelIDA6MDcNCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJp bGwud3VAaHVhd2VpLmNvbT4+OyBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdt YWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Pg0K5oqE6YCBOiBuZXRjb25m QGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K5Li76aKYOiBSRTogW25ldGNvbmZd IFdHTEMgb24gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcz8gKFdhcyBS ZTogQ29uZmlndXJlZCByZWNlaXZlciBjYXBhYmlsaXR5IGV4Y2hhbmdlKQ0KDQpIaSBRaW4sDQoN ClRoZSBwYXJhbWV0ZXIgInlhbmctbW9kdWxlIiBpcyBqdXN0IGlkZW50aWZ5aW5nIHRoZSBZQU5H IG1vZHVsZSB3aGljaCBjb250YWlucyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZW5jYXBzdWxhdGVk IG5vdGlmaWNhdGlvbi4gIEkuZS4sIHNvbWUgcmVmZXJlbmNlIHRvIHRoZSB0cmFuc3BvcnRlZCBv YmplY3RzIGlzIG5lZWRlZC4NCg0KVGhhdCBzYWlkLCB0aGUgY3VycmVudCBzb2x1dGlvbiBkb2Vz bid0IHByb3ZpZGUgYSBnb29kIHNvbHV0aW9uIHdoZW4gbmV3IG9iamVjdHMgYXJlIGF1Z21lbnRl ZCBpbnRvIGFuIGV4aXN0aW5nIG5vdGlmaWNhdGlvbi4gIFNvIHdoYXQgeW91IGJyaW5nIHVwIGlz IGEgdmFsaWQgY29uY2Vybi4gICBEbyB5b3UgaGF2ZSBzdWdnZXN0aW9ucyBvbiBtZXRob2RzIHRv IGhhbmRsZSBtb3JlIGNvbXBsZXggYXVnbWVudGVkIG5vdGlmaWNhdGlvbnM/ICBPbmUgcG9zc2li aWxpdHkgaXMgdG8gaGF2ZSBhIGxlYWYtbGlzdCBvZiBhdWdtZW50aW5nIG1vZGVscy4gIExvb2tp bmcgYXQgdGhlIGRlZmluaXRpb25zIG9mIHRoZXNlIG1vZGVscyB3b3VsZCBhbGxvdyBleHRyYWN0 aW9uIG9mIHRoZSBwcmVmaXhlcyB1c2VkLiAgVGhlcmUgYXJlIG1vcmUgY29tcGxleCBwb3NzaWJp bGl0aWVzIGhlcmUsIGhvd2V2ZXIgZWFjaCBhZGRzIHRvIHRoZSBwYXlsb2FkLiAgIChJdCBpcyBu b3QgYW4gYWNjaWRlbnQgdGhhdCBJUEZJWCBoYXMgdGVtcGxhdGUgcmVjb3Jkcy4pDQoNCkVyaWMN Cg0KRnJvbTogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2Vp LmNvbT4+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMjAgNTowOSBBTQ0KVG86IE1h aGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFu YW5kYW5pQGdtYWlsLmNvbT4+OyBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1h aWx0bzpldm9pdEBjaXNjby5jb20+Pg0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNv bmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW25ldGNvbmZdIFdHTEMgb24gZHJhZnQtaWV0Zi1u ZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcz8gKFdhcyBSZTogQ29uZmlndXJlZCByZWNlaXZl ciBjYXBhYmlsaXR5IGV4Y2hhbmdlKQ0KDQpFcmljOg0KV2h5IHN0cnVjdHVyZSBtZXNzYWdlIHNo b3VsZCB0aWUgdG8gYSBzaW5nbGUgWUFORyBkYXRhIG1vZHVsZSB3aXRoIOKAnHlhbmctbW9kdWxl 4oCdIHBhcmFtZXRlciwgaXMgdGhpcyB0b28gcmVzdHJpY3RpdmU/DQoNCi1RaW4NCuWPkeS7tuS6 ujogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1haGVz aCBKZXRoYW5hbmRhbmkNCuWPkemAgeaXtumXtDogMjAyMOW5tDHmnIgyOOaXpSA4OjE5DQrmlLbk u7bkuro6IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNp c2NvLmNvbT4+DQrmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5v cmc+DQrkuLvpopg6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmlj YXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBl eGNoYW5nZSkNCg0KSGkgRXJpYywNCg0KVGhpcyBlLW1haWwgdHJpZ2dlcnMgdHdvIHJlc3BvbnNl cy4gTGV0IHVzIGRlYWwgd2l0aCBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3Nh Z2VzIGhlcmUsIGFuZCBJIHdpbGwgYnJpbmcgdXAgY29tbWVudHMvcXVlc3Rpb25zIHJlbGF0ZWQg dG8gZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmIGluIHRoZSBvdGhlciB0aHJlYWQuDQoN CllvdSBoYXZlIGluZGljYXRlZCBhIGRlc2lyZSB0aGF0IHJlY2VpdmVyIGNhcGFiaWxpdGllcyBz aG91bGQgYmUgZG9jdW1lbnRlZCBieSB0aGUgdHJhbnNwb3J0IHNwZWNpZmljIGRyYWZ0LCBlLmcu IGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiwgYW5kIG5vdCB0aGlzIGRyYWZ0LiBBcyBz dWNoIHlvdSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5Lg0KDQpUbyB0aGUgV0csIHRo ZSBhdXRob3JzIGhhdmUgaW5kaWNhdGVkIGEgZGVzaXJlIHRvIHdyYXAgdXAgdGhpcyBkcmFmdCwg YW5kIHdvdWxkIGxpa2UgdXMsIHRoZSBjaGFpcnMsIHRvIGlzc3VlIGEgV0dMQyBvbiBpdC4gQmVm b3JlIHdlIGRvIHRoYXQsIHdlIHdhbnRlZCB0byBhc2sgaWYgdGhlIFdHIGJlbGlldmVzIHRoYXQg dGhlIGRvY3VtZW50IGlzIHJlYWR5LCBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gbW9yZSBpc3N1ZXMg dGhhdCBuZWVkIHRvIGRpc2N1c3NlZC9hZGRyZXNzZWQgYnkgZHJhZnQtaWV0Zi1uZXRjb25mLW5v dGlmaWNhdGlvbi1tZXNzYWdlcyBkb2N1bWVudCBhdCB0aGlzIHRpbWUuDQoNCkNoZWVycy4NCg0K TWFoZXNoIGFuZCBLZW50IChhcyBjby1jaGFpcnMpLg0KDQpPbiBKYW4gMTUsIDIwMjAsIGF0IDEy OjIzIFBNLCBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBj aXNjby5jb20+PiB3cm90ZToNCg0KSGkgTWFoZXNoLA0KDQpEdXJpbmcgdGhlIElFVEYgMTA2IHNl c3Npb24sIHRoZXJlIHdhcyBkaXNjdXNzaW9uIG9uIGhvdyBib3RoIGEgcHVibGlzaGVyIG1pZ2h0 IGtub3cgaWYgdGhlcmUgaXMgcmVjZWl2ZXIgc3VwcG9ydCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1tZXNzYWdlczxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLz9pbmNsdWRlX3RleHQ9MT4u ICBTZWN0aW9uIDYgaGlnaGxpZ2h0cyBzZXZlcmFsIG9mIHRoZSBjb25zaWRlcmF0aW9ucy4gICBS ZWxldmFudCBhcmUgdGhlIGZvbGxvd2luZzoNCg0KKGEpIFJlbW90ZSBkZXZpY2UgY2FwYWJpbGl0 eSBkaXNjb3ZlcnkgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgUHVibGlzaGVyIG5lZWRz IHRvIGJlIGVuaGFuY2VkIHRvIGtub3cgaWYgdGhlIGZhciBlbmQgY2FuIGludGVycHJldCBub3Rp ZmljYXRpb24gbWVzc2FnZXMgdHlwZSBiZXlvbmQgUkZDLTUyNzcsIFNlY3Rpb24gNC4NCg0KKGIp IFRoaXMgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgcXVlc3Rpb24gaXMgcmVsZXZhbnQgZm9yIGJvdGgg Y29uZmlndXJlZCBzdWJzY3JpcHRpb24gcmVjZWl2ZXJzIGFuZCBkeW5hbWljIHN1YnNjcmliZXJz Lg0KDQooYykgVGhlIGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1ZXN0aW9uIGNhbiBiZSBnZW5lcmFs aXplZCBiZXlvbmQgc3Vic2NyaXB0aW9ucywgYXMgdGhlcmUgYXJlIG1hbnkgcmVhc29ucyB0byBr bm93IHRoZSBhdmFpbGFibGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBmYXIgZW5kLg0KDQooZCkgQ2Fw YWJpbGl0eSBkaXNjb3ZlcnkgYWR2ZXJ0aXNlbWVudCBoYXMgdHJhZGl0aW9uYWxseSBiZWVuIGRp c2N1c3NlZCB3aXRoaW4gdHJhbnNwb3J0IGRvY3VtZW50cyAoZS5nLiBSRkMtNjI0MSBTZWN0aW9u IDguMSkuDQoNCg0KQmFzZWQgb24gKGEpLShkKSwgY29taW5nIHVwIHdpdGggYSB0cmFuc3BvcnQg aW5kZXBlbmRlbnQgcG9pbnQtc29sdXRpb24gd2l0aGluIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tbWVzc2FnZXM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy8/aW5jbHVkZV90ZXh0PTE+ICpqdXN0 KiB0byBkaXNjb3ZlciB0aGlzIHNpbmdsZSBlbGVtZW50IG9mIGNsaWVudCBmdW5jdGlvbmFsaXR5 IHNlZW1zIG92ZXJraWxsL2hlYXZ5d2VpZ2h0Lg0KDQpJIHdhcyBmaW5lIHdpdGggbGV0dGluZyB0 aGlzIHJlbW90ZSBjYXBhYmlsaXRpZXMgZGlzY292ZXJ5IHF1ZXN0aW9uIHNpdCBmb3IgYSB3aGls ZS4gICBIb3dldmVyIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZjxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLTAxPiBzaG93cyB0 aGF0IHdlIG5vdyBtdXN0IGFkZHJlc3MgdGhpcyBxdWVzdGlvbi4gIFNwZWNpZmljYWxseSBzaG91 bGQgdGhlIGRpYWdyYW0gc2VjdGlvbiAxLjQuMSBzaG93IHRoaXMgY2FwYWJpbGl0eSBleGNoYW5n ZT8NCg0KSXQgdHVybnMgb3V0IHRoYXQgaW5kZXBlbmRlbnQgb2YgZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1tZXNzYWdlcywgdGhlcmUgc2V2ZXJhbCBxdWVzdGlvbnMgaW4gZHJhZnQt aWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmIHdoaWNoIG5lZWQgdG8gYmUgYW5zd2VyZWQgcHJpb3Ig dG8gdGhlIHNlY3Rpb24gMS40LjEgYXJyb3c6ICJTZW5kIEhUVFBTIFBPU1QgbWVzc2FnZSB3aXRo IFlBTkcgZGVmaW5lZCBub3RpZmljYXRpb24gIzEiIGFueXdheS4gIFRoZXNlIHF1ZXN0aW9ucyBh cmU6DQogICgxKSBEb2VzIHRoZSB0YXJnZXRlZCBIVFRQUyByZWNlaXZlciBzdXBwb3J0IGNvbmZp Z3VyZWQgc3Vic2NyaXB0aW9ucz8NCiAgKDIpIENhbiB0aGUgdGFyZ2V0ZWQgSFRUUEAgcmVjZWl2 ZXIgYWNjZXB0IGEgbmV3IHN1YnNjcmlwdGlvbiBhcyBkZXNjcmliZWQgaW4gYSA8c3Vic2NyaXB0 aW9uLXN0YXJ0ZWQ+Pw0KT25seSBpZiB0aGVzZSBxdWVzdGlvbnMgYXJlICJ5ZXMiLCBzaG91bGQg dGhlIDxzdWJzY3JpcHRpb24tc3RhcnRlZD4gYmUgcmVzcG9uZGVkIHRvIHdpdGggYW4gIk9LIi4N Cg0KQWRkIHRvIHRoaXMgYSB0aGlyZCBxdWVzdGlvbiBkcml2ZW4gZnJvbSAoYSktKGQpOg0KICAo MykgRG9lcyB0aGUgcmVjZWl2ZXIgc3VwcG9ydCB0aGUgbWVzc2FnZSB0eXBlIHdpdGhpbiAiZHJh ZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyI/DQoNCkEgc3RyYXdtYW4gd2F5 IHRvIGhhbmRsZSB0aGUgYWxsIHRocmVlIHF1ZXN0aW9ucyB3aXRoaW4gZHJhZnQtaWV0Zi1uZXRj b25mLWh0dHBzLW5vdGlmIHdvdWxkIGJlIHRvIHJlc3BvbmQgdG8gYSA8c3Vic2NyaXB0aW9uLXN0 YXJ0ZWQ+IG5vdGlmaWNhdGlvbiB3aXRoIGFuIEhUVFAgU3RhdHVzIDIwMiAoQWNjZXB0ZWQpIiBh Y2tub3dsZWRnZW1lbnQuICBUaGlzIDIwMiB3b3VsZCBpbmNsdWRlIGJvZHkgZWxlbWVudHMgbGlz dGluZyBzdXBwb3J0ZWQgcmVjZWl2ZXIgcmVzb3VyY2VzLiAgTWF5YmUgc29tZXRoaW5nIFlBTkcg ZW5jb2RlZCB2aWEgaWV0Zi15YW5nLXN0cnVjdHVyZS1leHQgY29udGFpbmluZzoNCg0KICAgICAg PGZvbyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAg ICAgICAgPGNhcGFiaWxpdGllcz4NCiAgICAgICAgICA8Y2FwYWJpbGl0eT4NCiAgICAgICAgICAg IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLW5vdGlmaWNhdGlvbi1tZXNzYWdlczox LjANCiAgICAgICAgICA8L2NhcGFiaWxpdHk+DQogICAgICAgIDwvY2FwYWJpbGl0aWVzPg0KICAg ICAgPC9mb28+DQoNCldoYXQgZG8geW91IHRoaW5rIG9mIHRoaXMgYXBwcm9hY2g/DQoNCkVyaWMN Cg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABAAD4D630Cdggeml511mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Fcmlj OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSB3b25kZXJpbmcgaWYgYSBzZXQg b2Ygbm90aWZpY2F0aW9uIHBlciBtZXNzYWdlIGNhbiBiZSBjb21wcmVzc2VkIGJlZm9yZSBiZWlu ZyBidW5kbGVkLCBpZiB0aGUgYW5zd2VyIGlzIHllcywgSSB0aGluayBkYXRhIGNvbXByZXNzaW9u IGFsZ29yaXRobQ0KIHNob3VsZCBiZSBzcGVjaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JbiBhZGRpdGlvbiwgc3Vic2NyaXB0aW9uIG1vZGUgb3IgdHlwZSAocGVyaW9kaWNh bCwgb24gY2hhbmdlKSBjYW4gYmUgaW5jbHVkZWQgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVFpbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWYiPiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0N Cjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWYiPiAyMDIwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5n PSJFTi1VUyI+Mjwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjE8L3NwYW4+5pelPHNwYW4g bGFuZz0iRU4tVVMiPg0KIDIxOjUxPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFFpbiBXdSAmbHQ7YmlsbC53 dUBodWF3ZWkuY29tJmd0OzsgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7bWpldGhhbmFuZGFuaUBn bWFpbC5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+ PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t bWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5n ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5I aSBRaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgdGhlIFdH IHdhbnRzIGl0LCBJIGhhdmUgbm8gcHJvYmxlbSBhZGRpbmcgdGhpcyBsZWFmLWxpc3QuJm5ic3A7 IEdvb2QgY2F0Y2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmV5 b25kIHRoYXQsIGRvIHlvdSBoYXZlIGV4YW1wbGVzIG9mIHN1Y2ggdHJhbnNwb3J0IHNwZWNpZmlj IG9iamVjdHM/Jm5ic3A7Jm5ic3A7IFRyYW5zcG9ydGVkIG9iamVjdHMgd291bGQgYmUgbmFtZWQg d2l0aGluIHRoZSBub3RpZmljYXRpb24gaXRzZWxmLiZuYnNwOyBBbmQgdGhlIHByZWZpeCBhc3Nv Y2lhdGVkDQogd2l0aCB0aGUgb2JqZWN0IHNob3VsZCBiZSBtYXBwYWJsZS4mbmJzcDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBiZWxpZXZlIGl0IHNob3VsZCBi ZSB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gY29ycmVsYXRlIHRoZSBwcmVmaXggdG8gdGhlIHJpZ2h0 IG1vZGVsLiBBbmQgcHV0dGluZyBtb3JlIGludG8gZWFjaCBub3RpZmljYXRpb24gd291bGQgbWFr ZSBmb3Igb3ZlcmhlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUWluIFd1LCBGZWJydWFyeSAyMCwg MjAyMCA4OjMwIFBNPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlllcywgd2hhdCBJIGxpa2UgdG8gc2VlIGlzIHRvIGhhdmUgYSBsZWFmLWxp c3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J ZiBhIHNldCBvZiBzcGVjaWZpYyB0cmFuc3BvcnQgb2JqZWN0cyB3aXRoaW4gdGhlIG1vZGVsIGNh biBiZSB0YXJnZXRlZCwgdGhhdCB3aWxsIGFsc28gYmUgbmljZSB0byBoYXZlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4tUWluDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWP keS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBWb2l0IChldm9pdCkgWzxhIGhyZWY9Im1haWx0 bzpldm9pdEBjaXNjby5jb20iPm1haWx0bzpldm9pdEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ IDIwMjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4y PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1V UyI+DQogMDowNzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBRaW4gV3UgJmx0OzxhIGhyZWY9Im1haWx0bzpi aWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNvbTwvYT4mZ3Q7OyBNYWhlc2ggSmV0 aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGEgaHJlZj0ibWFp bHRvOm5ldGNvbmZAaWV0Zi5vcmciPg0KbmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+ PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t bWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5n ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5I aSBRaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHBhcmFt ZXRlciAmcXVvdDt5YW5nLW1vZHVsZSZxdW90OyBpcyBqdXN0IGlkZW50aWZ5aW5nIHRoZSBZQU5H IG1vZHVsZSB3aGljaCBjb250YWlucyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZW5jYXBzdWxhdGVk IG5vdGlmaWNhdGlvbi4mbmJzcDsgSS5lLiwgc29tZSByZWZlcmVuY2UgdG8gdGhlIHRyYW5zcG9y dGVkDQogb2JqZWN0cyBpcyBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VGhhdCBzYWlkLCB0aGUgY3VycmVudCBzb2x1dGlvbiBkb2Vzbid0IHByb3ZpZGUg YSBnb29kIHNvbHV0aW9uIHdoZW4gbmV3IG9iamVjdHMgYXJlIGF1Z21lbnRlZCBpbnRvIGFuIGV4 aXN0aW5nIG5vdGlmaWNhdGlvbi4mbmJzcDsgU28gd2hhdCB5b3UgYnJpbmcgdXAgaXMgYSB2YWxp ZA0KIGNvbmNlcm4uJm5ic3A7Jm5ic3A7IERvIHlvdSBoYXZlIHN1Z2dlc3Rpb25zIG9uIG1ldGhv ZHMgdG8gaGFuZGxlIG1vcmUgY29tcGxleCBhdWdtZW50ZWQgbm90aWZpY2F0aW9ucz8mbmJzcDsg T25lIHBvc3NpYmlsaXR5IGlzIHRvIGhhdmUgYSBsZWFmLWxpc3Qgb2YgYXVnbWVudGluZyBtb2Rl bHMuJm5ic3A7IExvb2tpbmcgYXQgdGhlIGRlZmluaXRpb25zIG9mIHRoZXNlIG1vZGVscyB3b3Vs ZCBhbGxvdyBleHRyYWN0aW9uIG9mIHRoZSBwcmVmaXhlcyB1c2VkLiZuYnNwOyBUaGVyZSBhcmUN CiBtb3JlIGNvbXBsZXggcG9zc2liaWxpdGllcyBoZXJlLCBob3dldmVyIGVhY2ggYWRkcyB0byB0 aGUgcGF5bG9hZC4mbmJzcDsgJm5ic3A7KEl0IGlzIG5vdCBhbiBhY2NpZGVudCB0aGF0IElQRklY IGhhcyB0ZW1wbGF0ZSByZWNvcmRzLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5FcmljDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUWluIFd1 ICZsdDs8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5j b208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAy MCA1OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVm PSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29t PC9hPiZndDs7IEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lz Y28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbbmV0Y29uZl0gV0dMQyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZp Y2F0aW9uLW1lc3NhZ2VzPyAoV2FzIFJlOiBDb25maWd1cmVkIHJlY2VpdmVyIGNhcGFiaWxpdHkg ZXhjaGFuZ2UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+RXJpYzombmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+ V2h5IHN0cnVjdHVyZSBtZXNzYWdlIHNob3VsZCB0aWUgdG8gYSBzaW5nbGUgWUFORyBkYXRhIG1v ZHVsZSB3aXRoIOKAnHlhbmctbW9kdWxl4oCdIHBhcmFtZXRlciwgaXMgdGhpcyB0b28gcmVzdHJp Y3RpdmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOIj4tUWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IG5ldGNvbmYgWzxhIGhyZWY9 Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7ku6PooaggPC9z cGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+TWFoZXNoIEpldGhh bmFuZGFuaTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0 PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LHNhbnMtc2VyaWYiPiAyMDIwPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3Bh biBsYW5nPSJFTi1VUyI+MTwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+Mjg8L3NwYW4+5pel PHNwYW4gbGFuZz0iRU4tVVMiPg0KIDg6MTk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRXJpYyBWb2l0IChl dm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPmV2b2l0QGNpc2NvLmNv bTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3Jn Ij4NCm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFtuZXRjb25mXSBXR0xDIG9u IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZp Z3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGlzIGUtbWFpbCB0cmlnZ2VycyB0d28gcmVzcG9uc2VzLiBMZXQgdXMg ZGVhbCB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMgaGVyZSwg YW5kIEkgd2lsbCBicmluZyB1cCBjb21tZW50cy9xdWVzdGlvbnMgcmVsYXRlZCB0byBkcmFmdC1p ZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgaW4gdGhlIG90aGVyIHRocmVhZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBoYXZlIGluZGljYXRlZCBh IGRlc2lyZSB0aGF0IHJlY2VpdmVyIGNhcGFiaWxpdGllcyBzaG91bGQgYmUgZG9jdW1lbnRlZCBi eSB0aGUgdHJhbnNwb3J0IHNwZWNpZmljIGRyYWZ0LCBlLmcuIGRyYWZ0LWlldGYtbmV0Y29uZi1o dHRwcy1ub3RpZiwgYW5kIG5vdCB0aGlzIGRyYWZ0LiBBcyBzdWNoIHlvdSBiZWxpZXZlIHRoYXQg dGhlIGRyYWZ0IGlzIHJlYWR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VG8gdGhlIFdHLCB0aGUgYXV0aG9ycyBoYXZlIGluZGljYXRlZCBhIGRlc2ly ZSB0byB3cmFwIHVwIHRoaXMgZHJhZnQsIGFuZCB3b3VsZCBsaWtlIHVzLCB0aGUgY2hhaXJzLCB0 byBpc3N1ZSBhIFdHTEMgb24gaXQuIEJlZm9yZSB3ZSBkbyB0aGF0LCB3ZSB3YW50ZWQgdG8gYXNr IGlmIHRoZSBXRyBiZWxpZXZlcyB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwgYW5kIHRoYXQg dGhlcmUNCiBhcmUgbm8gbW9yZSBpc3N1ZXMgdGhhdCBuZWVkIHRvIGRpc2N1c3NlZC9hZGRyZXNz ZWQgYnkgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyBkb2N1bWVudCBh dCB0aGlzIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5DaGVlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5NYWhlc2ggYW5kIEtlbnQgKGFzIGNvLWNoYWlycykuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBKYW4gMTUsIDIw MjAsIGF0IDEyOjIzIFBNLCBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2 b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBNYWhlc2gsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RHVyaW5nIHRoZSBJRVRGIDEwNiBzZXNzaW9uLCB0aGVyZSB3YXMgZGlzY3Vzc2lv biBvbiBob3cgYm90aCBhIHB1Ymxpc2hlciBtaWdodCBrbm93IGlmIHRoZXJlIGlzIHJlY2VpdmVy IHN1cHBvcnQgZm9yPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2luY2x1ZGVfdGV4dD0xIj48c3BhbiBzdHls ZT0iY29sb3I6Izk1NEY3MiI+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdl czwvc3Bhbj48L2E+Lg0KICZuYnNwO1NlY3Rpb24gNiBoaWdobGlnaHRzIHNldmVyYWwgb2YgdGhl IGNvbnNpZGVyYXRpb25zLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOyZuYnNwOzwvc3Bhbj5SZWxldmFudCBhcmUgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4oYSkgUmVtb3RlIGRldmljZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBmcm9tIHRoZSBwb2lu dCBvZiB2aWV3IG9mIHRoZSBQdWJsaXNoZXIgbmVlZHMgdG8gYmUgZW5oYW5jZWQgdG8ga25vdyBp ZiB0aGUgZmFyIGVuZCBjYW4gaW50ZXJwcmV0IG5vdGlmaWNhdGlvbiBtZXNzYWdlcw0KIHR5cGUg YmV5b25kIFJGQy01Mjc3LCBTZWN0aW9uIDQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KGIpIFRoaXMgY2FwYWJp bGl0eSBkaXNjb3ZlcnkgcXVlc3Rpb24gaXMgcmVsZXZhbnQgZm9yIGJvdGggY29uZmlndXJlZCBz dWJzY3JpcHRpb24gcmVjZWl2ZXJzIGFuZCBkeW5hbWljIHN1YnNjcmliZXJzLiZuYnNwOzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4oYykgVGhlIGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1ZXN0aW9uIGNhbiBiZSBnZW5lcmFsaXpl ZCBiZXlvbmQgc3Vic2NyaXB0aW9ucywgYXMgdGhlcmUgYXJlIG1hbnkgcmVhc29ucyB0byBrbm93 IHRoZSBhdmFpbGFibGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBmYXIgZW5kLiZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4oZCkgQ2FwYWJpbGl0eSBkaXNjb3ZlcnkgYWR2ZXJ0aXNlbWVudCBoYXMgdHJhZGl0aW9u YWxseSBiZWVuIGRpc2N1c3NlZCB3aXRoaW4gdHJhbnNwb3J0IGRvY3VtZW50cyAoZS5nLiBSRkMt NjI0MSBTZWN0aW9uIDguMSkuJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJhc2VkIG9uIChhKS0oZCksIGNvbWluZyB1cCB3 aXRoIGEgdHJhbnNwb3J0IGluZGVwZW5kZW50IHBvaW50LXNvbHV0aW9uIHdpdGhpbjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LW1lc3NhZ2VzLz9pbmNsdWRlX3RleHQ9MSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmRy YWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM8L3NwYW4+PC9hPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4qanVzdCoNCiB0byBkaXNj b3ZlciB0aGlzIHNpbmdsZSBlbGVtZW50IG9mIGNsaWVudCBmdW5jdGlvbmFsaXR5IHNlZW1zIG92 ZXJraWxsL2hlYXZ5d2VpZ2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FzIGZpbmUgd2l0aCBsZXR0aW5n IHRoaXMgcmVtb3RlIGNhcGFiaWxpdGllcyBkaXNjb3ZlcnkgcXVlc3Rpb24gc2l0IGZvciBhIHdo aWxlLiZuYnNwOyZuYnNwOyBIb3dldmVyPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDEiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0Rjcy Ij5kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWY8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zaG93cw0KIHRoYXQgd2Ugbm93IG11 c3QgYWRkcmVzcyB0aGlzIHF1ZXN0aW9uLiZuYnNwOyBTcGVjaWZpY2FsbHkgc2hvdWxkIHRoZSBk aWFncmFtIHNlY3Rpb24gMS40LjEgc2hvdyB0aGlzIGNhcGFiaWxpdHkgZXhjaGFuZ2U/Jm5ic3A7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkl0IHR1cm5zIG91dCB0aGF0IGluZGVwZW5kZW50IG9mIGRyYWZ0LWlldGYtbmV0Y29u Zi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIHRoZXJlIHNldmVyYWwgcXVlc3Rpb25zIGluIGRyYWZ0 LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3aGljaCBuZWVkIHRvIGJlIGFuc3dlcmVkDQogcHJp b3IgdG8gdGhlIHNlY3Rpb24gMS40LjEgYXJyb3c6ICZxdW90O1NlbmQgSFRUUFMgUE9TVCBtZXNz YWdlIHdpdGggWUFORyBkZWZpbmVkIG5vdGlmaWNhdGlvbiAjMSZxdW90OyBhbnl3YXkuICZuYnNw O1RoZXNlIHF1ZXN0aW9ucyBhcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7ICgxKSBEb2VzIHRoZSB0YXJnZXRlZCBIVFRQUyByZWNlaXZlciBzdXBwb3J0IGNvbmZpZ3Vy ZWQgc3Vic2NyaXB0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsg KDIpIENhbiB0aGUgdGFyZ2V0ZWQgSFRUUEAgcmVjZWl2ZXIgYWNjZXB0IGEgbmV3IHN1YnNjcmlw dGlvbiBhcyBkZXNjcmliZWQgaW4gYSAmbHQ7c3Vic2NyaXB0aW9uLXN0YXJ0ZWQmZ3Q7PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9ubHkgaWYgdGhlc2UgcXVlc3Rpb25zIGFyZSAm cXVvdDt5ZXMmcXVvdDssIHNob3VsZCB0aGUgJmx0O3N1YnNjcmlwdGlvbi1zdGFydGVkJmd0OyBi ZSByZXNwb25kZWQgdG8gd2l0aCBhbiAmcXVvdDtPSyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BZGQg dG8gdGhpcyBhIHRoaXJkIHF1ZXN0aW9uIGRyaXZlbiBmcm9tIChhKS0oZCk6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICgzKSBEb2VzIHRoZSByZWNlaXZlciBzdXBwb3J0 IHRoZSBtZXNzYWdlIHR5cGUgd2l0aGluICZxdW90O2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmlj YXRpb24tbWVzc2FnZXMmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBzdHJhd21hbiB3YXkgdG8gaGFu ZGxlIHRoZSBhbGwgdGhyZWUgcXVlc3Rpb25zIHdpdGhpbiBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0 cHMtbm90aWYgd291bGQgYmUgdG8gcmVzcG9uZCB0byBhICZsdDtzdWJzY3JpcHRpb24tc3RhcnRl ZCZndDsgbm90aWZpY2F0aW9uIHdpdGggYW4gSFRUUA0KIFN0YXR1cyAyMDIgKEFjY2VwdGVkKSZx dW90OyBhY2tub3dsZWRnZW1lbnQuJm5ic3A7IFRoaXMgMjAyIHdvdWxkIGluY2x1ZGUgYm9keSBl bGVtZW50cyBsaXN0aW5nIHN1cHBvcnRlZCByZWNlaXZlciByZXNvdXJjZXMuJm5ic3A7IE1heWJl IHNvbWV0aGluZyBZQU5HIGVuY29kZWQgdmlhIGlldGYteWFuZy1zdHJ1Y3R1cmUtZXh0IGNvbnRh aW5pbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtm b28geG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1 b3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2FwYWJpbGl0aWVzJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2FwYWJpbGl0eSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYt bm90aWZpY2F0aW9uLW1lc3NhZ2VzOjEuMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bHQ7L2NhcGFiaWxpdHkmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvY2FwYWJpbGl0aWVzJmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7L2ZvbyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaGF0IGRvIHlvdSB0aGluayBvZiB0 aGlzIGFwcHJvYWNoPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFoZXNoIEpl dGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABAAD4D630Cdggeml511mbxchi_-- From nobody Mon Feb 24 09:35:15 2020 Return-Path: <01000170784458b8-bfa1e136-fff9-4eb3-a815-61e976fef629-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 AF1023A0F4A for ; Mon, 24 Feb 2020 09:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ETgkxqAy027h for ; Mon, 24 Feb 2020 09:35:11 -0800 (PST) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5B73A0F4C for ; Mon, 24 Feb 2020 09:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582565710; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=ARqw7zIoM7e0Yzf3FSRHNL1Q0pB9Z/oEd3+BBrVqTXo=; b=HjL3358VqVoE7rtkmufY75uJkq2TwWcBr/nigpKLCxB34rjAXggsm0hEkwHpC6bv kZN6RMEE7ZB6xvM1o/d+84Bd59lMOzBbvCW0zvktGFESHi8nf4KiKjlLsZzlUN1PlbM AQaHbnOR/f8hNXrE5I/dyyScX2cP/+PKjn92wmu4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <6ed11152-ab3d-d42b-f983-908de32bbef8@hagsand.se> Date: Mon, 24 Feb 2020 17:35:10 +0000 Cc: Juergen Schoenwaelder , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000170784458b8-bfa1e136-fff9-4eb3-a815-61e976fef629-000000@email.amazonses.com> References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200223112829.rjd3zf53rybmmzvc@anna.jacobs.jacobs-university.de> <6ed11152-ab3d-d42b-f983-908de32bbef8@hagsand.se> To: Olof Hagsand X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.24-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 24 Feb 2020 17:35:13 -0000 Hi Olof, > What does "the empty lists exists or not" mean, how is an existing = empty > list different from a non-existent list wrt YANG? I would think that a > YANG list have instances (=3D it exists), or it does not have = instances (=3D > is empty =3D does not exist). Empty =E2=80=9Clist=E2=80=9D (and =E2=80=9Cleaf-list=E2=80=9D) handling = seems to be related to the non-presence containers issue that has been = tracked here: https://github.com/netmod-wg/yang-next/issues/88 (ps: just = updated to reflect this thread). Personally, I=E2=80=99m in the =E2=80=9Cexplicit" camp. That is, lists = (and NP-containers) do not exist unless explicitly configured and they = do not implicitly-disappear when empty. My server distinguishes between = missing (e.g., 404) and empty (204 for XML or 200 for JSON) lists. = Personally, I think it=E2=80=99s best to also return 204 (i.e., for JSON = also) as its more RESTful and encoding-independent. FWIW, RFC 8040 = doesn=E2=80=99t mention the ability for GET to return 204, but it = doesn=E2=80=99t disallow it either... > Another related question is how the same request but for XML encoding > should be treated, ie a YANG list x with no elements (empty > list/non-existent)? This issue is not encoding-specific, AFIACT. The only list-related encoding issue I=E2=80=99m aware of is when the = query targets the list node directly, not a parent container, and the = list contains more than one element. In this case, it=E2=80=99s not = possible to return a valid XML document, whereas there=E2=80=99s no = issue with JSON. =20 Off-topic, but a couple fixes have been proposed. One creates an = implicit wrapper node: =3D=3D=3D=3D start =3D=3D=3D=3D =E2=80=A6 =E2=80=A6 =E2=80=A6 =3D=3D=3D=3D stop =3D=3D=3D=3D Whereas another documents that, only in this case, is it possible to = return an invalid XML document: =3D=3D=3D=3D start =3D=3D=3D=3D =E2=80=A6 =E2=80=A6 =E2=80=A6 =3D=3D=3D=3D stop =3D=3D=3D=3D > GET /restconf/data/m:x > Accept: application/yang-data+xml >=20 > Is the reply "404 Not Found" status-line and error-tag value > "invalid-value" (following the list resource does not exist) > or, following the JSON [] (existing empty list) reasoning, a "204 No > Content=E2=80=9D? Answered above, I think. > Again apologizes for these basic questions, No worries, sometimes it takes fresh eyes to see things :) Kent // contributor From nobody Mon Feb 24 11:17:33 2020 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 A278C3A1177 for ; Mon, 24 Feb 2020 11:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=MNAZftDF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TmVbVZdQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tEmAsTHIoM8 for ; Mon, 24 Feb 2020 11:17:31 -0800 (PST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504793A1175 for ; Mon, 24 Feb 2020 11:17:31 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 8FC525CBD; Mon, 24 Feb 2020 14:17:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 24 Feb 2020 14:17:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= u1StXWaPUBArtOWq6xLXABKtj8DQgKXrEvZQTDGtxKw=; b=MNAZftDF+UgOikZv pxwvyaBWubUO/QdsndPBNfekuUQ/JzrKwx8P9JG6yb5M06aWhYltGTYdPiuL58WH UfWs3ws2wJzOK6OfU+EDmMYhPyoxBAc578asyVZsxN13tCHFEG9o9ISciL9si5aZ XjZlsXQnBP+Pz2S/99rLGeemIKUF1PPNaTQtnvPL4f0bzHvFCVq7ZN97AFv9DYSu Govnvet+wYSgg4WaHaF0s50Sx2n1rDkP58MzaoU9iHp4nPAVrgCj8RNVGrN4KDPK xC9vVKC8D8Zh2gyjRC4c4hOnFXmS++1AwJTO1U3WU92zgRazR7w+sXBndYP1UmZj Kafiqg== 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=u1StXWaPUBArtOWq6xLXABKtj8DQgKXrEvZQTDGtx Kw=; b=TmVbVZdQymQdaVWxYwReOrjt4FL7DGen7XaSV4NoCjooPs5OgNDJnQ5YT MmN61jY2pPoCn5HmZ2CzmJrQAodLGd0aCSwcMFmkiaK6dpT22YFT6k4Z4NBlBx6s mKnFqG4Sp3xpd2n9xDpzOqP0x4ue4tSOPKA1prbR3B0IUZ5W4Qandj0dQ80YEvF4 oiw9uDqXT9W2V80tcIRszOkJaoGHlCtRPpnIUaY1lYwnMDM3oFZESi6gPPHwT5Kz 7NolaV6geSAsT1hAUjy0I6AU4ZpfjYj5bRCKpa1QpYMVgSFfDe1OW86/Rq4orBWw iTIeRBSFMp6GYpVXB4UrKSYYjXkiw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepud ehkedrudejgedrgedrgeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id A0E173060FCB; Mon, 24 Feb 2020 14:17:28 -0500 (EST) Date: Mon, 24 Feb 2020 20:17:27 +0100 (CET) Message-Id: <20200224.201727.524298611078512416.id@4668.se> To: olof@hagsand.se Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 24 Feb 2020 19:17:33 -0000 Hi, Olof Hagsand wrote: > Hello, > In a restconf GET request of an empty YANG list using JSON encoding, > what is the expected reply? I.e. using a yang list "x" in module "m" > (pseudo http): > GET /restconf/data/m:x > Accept: application/yang-data+json > > Is the reply (1): > HTTP/1.1 200 OK > { > "m:x": [] > } > > or should it be (2) > "404 Not Found" status-line and error-tag value "invalid-value"? It should be 404, even if the list contains some entries. The reason for this is that there is no resource for the list itself, only for list entries. See section 3.5 of RFC 8040. We used to have "collections" for this use case, but it was never finished. /martin > > Apologizes that this is a basic question, and I am sure this is resolved > properly, but we have some discussions with users on how to properly > interpret the description of GET in RFC 8040 Section 4.3 and RFC 7951. > > Regards, > Olof Hagsand, > Clixon maintainer > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Feb 24 12:09:52 2020 Return-Path: <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-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 AE0B73A122F for ; Mon, 24 Feb 2020 12:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 F1Wxaps9yYg9 for ; Mon, 24 Feb 2020 12:09:50 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA72E3A1225 for ; Mon, 24 Feb 2020 12:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582574989; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=vQ8rhVh+qPZKXtrzA/sEpBRXviSh/FK9C+GX1p7qxFA=; b=UvemNvTofXHz+8NE81t5GNcE8qdKNiMJLC15EWsLkf+3hmU6JtO9UvcAMnL3u4qj it27py5u8iEHbkSQ20Gb8QmIZApyhX7d2CS292fDawUfOywyt+20COcvncJBhQTqFkE ej+O9WgpZlYHtYL1IzDq+eSysQ6omxylM+YbypmM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <20200224.201727.524298611078512416.id@4668.se> Date: Mon, 24 Feb 2020 20:09:49 +0000 Cc: Olof Hagsand , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200224.201727.524298611078512416.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.24-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 24 Feb 2020 20:09:52 -0000 > It should be 404, even if the list contains some entries. The reason > for this is that there is no resource for the list itself, only for > list entries. See section 3.5 of RFC 8040. Assuming you mean the first paragraph not explicitly listing =E2=80=9Clist= =E2=80=9D and =E2=80=9Cleaf-list=E2=80=9D, that conflicts with Section = 4.3, Paragraph 5. > We used to have "collections" for this use case, but it was never = finished. :sigh: ;) Kent // contributor From nobody Mon Feb 24 12:36:44 2020 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 C1B813A12B3 for ; Mon, 24 Feb 2020 12:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiSEbVsX3whf for ; Mon, 24 Feb 2020 12:36:41 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2097.outbound.protection.outlook.com [40.107.94.97]) (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 56FF73A12B2 for ; Mon, 24 Feb 2020 12:36:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k4kF4eK72ynRSDmEh9m9zg7984UdliPdY0uBrv7NBpx/RWfmfrOVczRfJPDRzhlWYuIKpWFkW4eKhRwlJL+0+wH9ej0UH0gZz6YLdRVxQ2mGakIVGg3z1SvzR4xeQmTs8e0jVGfJ1aFlC+RURpek7Z0QtLslD1WL8Dc1jeXJGsEEJ7HM4VEPEaCccEhY3DAGROcY0vqtk1sfOcHSgUwL/ngmdH4KgBoZcZ/3i15Cc3ywxq+GP+ZZHLSqr40iTrWVMIAqw3q60aIhMpJj/sMq7a9cxa/X0r1Aa2gRBOMGO7H6mzdtZbCeqF2itlytSWH5v0IfIPEizBwPJzApR4lfWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wTuFWHlD/KcqySYxeMkr0tSPP2V+ONBHEqD8efZxlgI=; b=BmX4j6KrOX1qVVZcySS/XSM7liYRBLSCd5dElt0NfNlNgEICXFnsV2npEMGR+XoqP05BFt/DaaSSpijQYk+y8tlSgihYIX8gl6cjHYrKktn6bX6uFLsaIWYID18f46r//UEarF7zN0IPZ1CyatG0YmKAeY0l1rXPMj1e+tYZW3kmcZ1osQi2ADXLTeXYvM80GOOeIfX/+QxODaKQgunTiQhdLeaa5+iW0VGMaIGu2lZZM5eX+27gOqJdgXhKdEggr83eoVFffCLQwtx1Obh1/cLl2GvT1SdNH/uVCqDy19CMOHzMNxcVu4tFcbTRlwM7dKexmCazaDVAWbk4T0Tpdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wTuFWHlD/KcqySYxeMkr0tSPP2V+ONBHEqD8efZxlgI=; b=m/tME0+uB07u9YnMXI/W2PJd7IMPoXcuNwX9kkF8amgDavHg67BhkrC/RBqmDDdgaqsINDrkCb5i/qfGCr6uutkoJAVlpfvh4KpxnyaQQfGWefw1FdOl4T4qQkhQMbzkeP6KPS0knDtAS8wSME82IT8K6HlGagU4DXg87jsm68c= Received: from DM5PR08MB2633.namprd08.prod.outlook.com (2603:10b6:3:ca::21) by DM5PR08MB3483.namprd08.prod.outlook.com (2603:10b6:4:6b::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Mon, 24 Feb 2020 20:36:38 +0000 Received: from DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::455:66cb:efa2:fabb]) by DM5PR08MB2633.namprd08.prod.outlook.com ([fe80::455:66cb:efa2:fabb%9]) with mapi id 15.20.2750.021; Mon, 24 Feb 2020 20:36:38 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Kent Watsen , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= CC: "netconf@ietf.org" Thread-Topic: [netconf] Question on restconf empty list reply Thread-Index: AQHV605lCORAmIjLkka6fPXzgh4EJagqzTcw Date: Mon, 24 Feb 2020 20:36:38 +0000 Message-ID: References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200224.201727.524298611078512416.id@4668.se> <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> In-Reply-To: <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; x-originating-ip: [65.110.215.75] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f64209d9-4814-43fe-8aba-08d7b9693fa6 x-ms-traffictypediagnostic: DM5PR08MB3483: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(199004)(189003)(186003)(110136005)(8676002)(966005)(2906002)(81166006)(66446008)(4326008)(66574012)(9686003)(64756008)(81156014)(55016002)(498600001)(66556008)(71200400001)(66476007)(66946007)(76116006)(52536014)(5660300002)(7696005)(8936002)(26005)(33656002)(6506007)(53546011)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB3483; H:DM5PR08MB2633.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qRHZE3ynVhz3QMIPsGKFkXkOAA8awqLJiJz/LqXUG9NserB3wD/5nz5FSPsBSDDw/07RQmAJPMHcsaBeAgpUl6B4NmCQh7p1522u2xWvbWD5km6Q+nmMw9YahQbNStU373kiJ2EV8tuYMdWk4sE1gQTI/7C3M9hZQcKVFxRNE5Js4b28VyekkG07RjSEQp5tkhwOL0LANQHa7yeSNM6QzVJqrL8TrZNj9fOygj7+peZ1HfmJt2yOjfT0JCpXwNFhK0EgzO+fjCQb+0ZjnkZHURZZc+RtGSq0j9/TnqbMsWq7FHQYmYmq58Mu6f5tyDXCpQPDr18sV0GEHD84zbLh3Z184h6F3P5Xh+xjaV11OJwNmr9O02c9hTcSjWAm7C7Co1m4XaW3UodrgSaUxv5GoxWbcK2j1aV6nB4DSU6eBxTTUImPBVB3c85s8ctyEp4+X6mz9AXKXalxYLrtZwStddsbsxf8/yNV1rHy2X2RIytd7V3PmYxx2y+OG8n4cDWvSuH7CtuETF74wa1ZERUAXw== x-ms-exchange-antispam-messagedata: Sg/dSEvg4N5Ujxmrt8ZnDIhpbyeP7JWnuwah3vDw61NKPTSJiZ/dLpgvxGY1K4K9KMPXe1WKdImkK9+aVuRJ/RRtr6wCzLsWdOjuBRLTuLmNS0fd8kNFHwdv27XL9YUuyhwwsUOUzrjk0VRpvPmm9g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f64209d9-4814-43fe-8aba-08d7b9693fa6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 20:36:38.5828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dG56/GNoGbsey8DeFl88ASPASnfOKJhV5/pcpORL2x1cqBrt3/cy+Z3IJ6bJWkYPoEcmo7MiO/QYzxgyKT8JpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3483 Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 24 Feb 2020 20:36:43 -0000 SGkgZ3V5cywNCg0KRm9yIE5FVENPTkYgdGhpcyBzaG91bGQgKm5vdCogcmV0dXJuIGFuIGVycm9y IHRob3VnaCByaWdodD8gSXQgc2hvdWxkIGp1c3QgcmV0dXJuIGFuIGVtcHR5IGRhdGEgc2V0Lg0K DQpJIGRvbid0IGtub3cgZW5vdWdoIGFib3V0IFJFU1RDT05GIGJ1dCBJJ20gc3VycHJpc2VkIGl0 IHdvdWxkIHJldHVybiBhbiBlcnJvciBpbiB0aGlzIGNhc2UgKHRvbyBiYWQgaXQgd291bGQgYmUg aW5jb25zaXN0ZW50IHdpdGggTkVUQ09ORikuDQoNCkphc29uDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgS2VudCBXYXRzZW4NCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNCwgMjAy MCAzOjEwIFBNDQo+IFRvOiBNYXJ0aW4gQmrDtnJrbHVuZCA8bWJqK2lldGZANDY2OC5zZT4NCj4g Q2M6IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRjb25mXSBRdWVzdGlvbiBv biByZXN0Y29uZiBlbXB0eSBsaXN0IHJlcGx5DQo+IA0KPiA+IEl0IHNob3VsZCBiZSA0MDQsIGV2 ZW4gaWYgdGhlIGxpc3QgY29udGFpbnMgc29tZSBlbnRyaWVzLiAgVGhlIHJlYXNvbg0KPiA+IGZv ciB0aGlzIGlzIHRoYXQgdGhlcmUgaXMgbm8gcmVzb3VyY2UgZm9yIHRoZSBsaXN0IGl0c2VsZiwg b25seSBmb3INCj4gPiBsaXN0IGVudHJpZXMuICBTZWUgc2VjdGlvbiAzLjUgb2YgUkZDIDgwNDAu DQo+IA0KPiBBc3N1bWluZyB5b3UgbWVhbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG5vdCBleHBsaWNp dGx5IGxpc3Rpbmcg4oCcbGlzdOKAnSBhbmQg4oCcbGVhZi0NCj4gbGlzdOKAnSwgdGhhdCBjb25m bGljdHMgd2l0aCBTZWN0aW9uIDQuMywgUGFyYWdyYXBoIDUuDQo+IA0KPiANCj4gPiBXZSB1c2Vk IHRvIGhhdmUgImNvbGxlY3Rpb25zIiBmb3IgdGhpcyB1c2UgY2FzZSwgYnV0IGl0IHdhcyBuZXZl ciBmaW5pc2hlZC4NCj4gDQo+IDpzaWdoOiAgIDspDQo+IA0KPiANCj4gS2VudCAvLyBjb250cmli dXRvcg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Tue Feb 25 09:38:30 2020 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 ECEC83A11DF for ; Tue, 25 Feb 2020 09:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=xLblj9RZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xccFPttK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rYb0phJhjbF for ; Tue, 25 Feb 2020 09:38:28 -0800 (PST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F6E3A11DE for ; Tue, 25 Feb 2020 09:38:27 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id EF44D6730; Tue, 25 Feb 2020 12:38:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 25 Feb 2020 12:38:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= wRV34KW1kjoQ/ihYIlmLsldHY6VWAstMNBfKxrnB89M=; b=xLblj9RZABgK0Oac EQBLgCe+XBmOkJkei7DPh/0OMeL/GIimQtLXZEFyDdzktehpSJJD1+6IlteAZV3M G2xo64TEWWH12CzwXxNtkul9WP6zGCmIUi3cXfjW8qpCSv+6GrKmWtJ3BOCn12wx JhPrG6XRc/L6EJiubxG0tGXWMZrj9057pACwFLgpSEdVrSH1dQkrgZeJByt3GyQj +vfwT91jOkDbmtPLxoNbqPqAuuA9wnsm4wJ1jmSFphtJx33d5MwBfJF3Kdzmrjvt LUkGD5x28u/MW4lFRtSQHxMXO7VCy3cZJP6/x+XmJW35FdLgPmJAVZoGki5lKcqO d6yJHw== 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=wRV34KW1kjoQ/ihYIlmLsldHY6VWAstMNBfKxrnB8 9M=; b=xccFPttKyOCCNPgABU6LAUAydC9RdgaVvlBXlJY87B66qxUpxvnBdItnO ZfxZHfsBiOTSwDfQt2nj7phzFR260E8C7EUmszdqfKEnoz4VLmEZX3eneCXOqqwj LWZYUkxICy/8hZjQs2TDfPqiFLxO9ol0Y3jcEbjXgOeAvKkjqGblm9J2Ui2TA9Ja qiBukQ1O73Wo+dZAnXgUSse5Qua5NYXzviRU+CLMxFu1u87QcegXFgWewiynZs6O UAOhkfMVXGAKlgq1u7jNn7kYV/kXLeL7+der7ud85dqbOd1WUmURAmFVbuJ/c0VA 8BVkExFsyVRYlU34CYp9N0+FjmVhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledvgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecukfhppeduheekrddujeegrdegrdeggeenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhes geeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C7433060FCB; Tue, 25 Feb 2020 12:38:25 -0500 (EST) Date: Tue, 25 Feb 2020 18:38:23 +0100 (CET) Message-Id: <20200225.183823.647044925138390997.id@4668.se> To: kent+ietf@watsen.net Cc: olof@hagsand.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200224.201727.524298611078512416.id@4668.se> <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 25 Feb 2020 17:38:29 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gPiBJdCBzaG91bGQg YmUgNDA0LCBldmVuIGlmIHRoZSBsaXN0IGNvbnRhaW5zIHNvbWUgZW50cmllcy4gIFRoZSByZWFz b24NCj4gPiBmb3IgdGhpcyBpcyB0aGF0IHRoZXJlIGlzIG5vIHJlc291cmNlIGZvciB0aGUgbGlz dCBpdHNlbGYsIG9ubHkgZm9yDQo+ID4gbGlzdCBlbnRyaWVzLiAgU2VlIHNlY3Rpb24gMy41IG9m IFJGQyA4MDQwLg0KPiANCj4gQXNzdW1pbmcgeW91IG1lYW4gdGhlIGZpcnN0IHBhcmFncmFwaCBu b3QgZXhwbGljaXRseSBsaXN0aW5nIOKAnGxpc3TigJ0NCj4gYW5kIOKAnGxlYWYtbGlzdOKAnSwg dGhhdCBjb25mbGljdHMgd2l0aCBTZWN0aW9uIDQuMywgUGFyYWdyYXBoIDUuDQoNCkRvZXMgaXQ/ ICBBY3R1YWxseSwgdGhhdCBwYXJhZ3JhcGggaXMgbm90IHF1aXRlIGNsZWFyLiAgV2hhdCBpcyBh DQoicmVzb3VyY2UgcmVwcmVzZW50aW5nIGEgWUFORyBsaXN0IG9iamVjdCI/DQoNCg0KL21hcnRp bg0KDQoNCj4gDQo+IA0KPiA+IFdlIHVzZWQgdG8gaGF2ZSAiY29sbGVjdGlvbnMiIGZvciB0aGlz IHVzZSBjYXNlLCBidXQgaXQgd2FzIG5ldmVyDQo+ID4gZmluaXNoZWQuDQo+IA0KPiA6c2lnaDog ICA7KQ0KPiANCj4gDQo+IEtlbnQgLy8gY29udHJpYnV0b3INCj4gDQo= From nobody Tue Feb 25 09:52:57 2020 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 3DCC73A1206 for ; Tue, 25 Feb 2020 09:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=x8duAmR5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HNWKqD4d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hozYQCaYys0 for ; Tue, 25 Feb 2020 09:52:54 -0800 (PST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F993A11FD for ; Tue, 25 Feb 2020 09:52:54 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id C573E6F6D; Tue, 25 Feb 2020 12:52:53 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 25 Feb 2020 12:52:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= 2n/IBM9xtypWNmg5P9SYHO7kq41cfU4stWctSIZEg0o=; b=x8duAmR5FsO7J4nI Jpaokndr7ryZiqvkHQm8fb7t7sUjdSf6kBmCgf4iDxww1calrIKNkMYN9BRavO2t ppVoVXfuhMxn+v9mMALB36ubIraAgkauZZ6j30I+UOaGx0KPvFqluIq5f+pPdV4d qHtvurShLexjKAOsM6GeeTeEhtcekOoUgJDvr3WfDP+qA9wHyaKSWZydVRwtB6bi pVAhQE36oPD7gU05Qz78pIQZDzocpKP+mYOI7D/ihiWfYBb/bGrRrlud5U8oDkLn 79SW/BA6jIX6+HPaIq1mAii/i0lMoeUnMRuqz5yzwnuMGxEOqx8jZvkBsM2OIS/y XuU05Q== 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=2n/IBM9xtypWNmg5P9SYHO7kq41cfU4stWctSIZEg 0o=; b=HNWKqD4dazIydBaqeVeBRsWSv+GBAHIpwXul3uPjXaBrI2InAkCzY7Haj 1AGJ1iwM+Xe8SFeiBAuNGuzPgd4OvEnS4kGLgo4SszDo9EF1ZNXyn4uPfylCBpzu fm1PdQ1AeuuoDjzje5Kp5iut7CnyKl0k6HtplMSlEZhSpPRfk5UZ16TPBhe2rLVf UT3RtRIax3tq73VIWYmjD9fJNxiKgnbPPqg1TVQdDeyxbHGjWqVBIqth0aszNnr9 RRPojTQRc/Pim4oP0zmO47JknPkI6sAzE39QABHV00KEvUvmyBdK0X+fTuM3fbl9 fYKqbrb5acK4IuWbyiBEoTOQ6Ziww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledvgddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepud ehkedrudejgedrgedrgeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 5EBCD3060BD1; Tue, 25 Feb 2020 12:52:52 -0500 (EST) Date: Tue, 25 Feb 2020 18:52:51 +0100 (CET) Message-Id: <20200225.185251.2026161013381820378.id@4668.se> To: jason.sterne@nokia.com Cc: kent+ietf@watsen.net, mbj+ietf@4668.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: <20200224.201727.524298611078512416.id@4668.se> <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 25.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 25 Feb 2020 17:52:56 -0000 SGksDQoNCiJTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkiIDxqYXNvbi5zdGVybmVA bm9raWEuY29tPiB3cm90ZToNCj4gSGkgZ3V5cywNCj4gDQo+IEZvciBORVRDT05GIHRoaXMgc2hv dWxkICpub3QqIHJldHVybiBhbiBlcnJvciB0aG91Z2ggcmlnaHQ/IEl0IHNob3VsZCBqdXN0IHJl dHVybiBhbiBlbXB0eSBkYXRhIHNldC4NCj4gDQo+IEkgZG9uJ3Qga25vdyBlbm91Z2ggYWJvdXQg UkVTVENPTkYgYnV0IEknbSBzdXJwcmlzZWQgaXQgd291bGQgcmV0dXJuDQo+IGFuIGVycm9yIGlu IHRoaXMgY2FzZSAodG9vIGJhZCBpdCB3b3VsZCBiZSBpbmNvbnNpc3RlbnQgd2l0aA0KPiBORVRD T05GKS4NCg0KVGhlIHByb3RvY29sIG9wZXJhdGlvbiBpcyBkaWZmZXJlbnQgaW4gTkVUQ09ORiBj b21wYXJlZCB0byBSRVNUQ09ORi4NCkluIE5FVENPTkYsIHlvdSB3b3VsZCBkbyBhIGdldC1jb25m aWcgb3IgZ2V0LWRhdGEgd2l0aCBhIF9maWx0ZXJfLiAgSW4NClJFU1RDT05GLCB5b3UgYXNrIGZv ciBhIHNwZWNpZmljIF9yZXNvb3VyY2VfLCBhbmQgdGhlcmUgaXMgbm8gcmVzb3VyY2UNCmZvciBh IGNvbXBsZXRlIGxpc3QuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IEphc29uDQo+IA0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NCj4gPiBTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDI0LCAyMDIwIDM6MTAgUE0NCj4gPiBUbzogTWFydGluIEJqw7Zya2x1bmQgPG1i aitpZXRmQDQ2Njguc2U+DQo+ID4gQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW25ldGNvbmZdIFF1ZXN0aW9uIG9uIHJlc3Rjb25mIGVtcHR5IGxpc3QgcmVwbHkNCj4gPiAN Cj4gPiA+IEl0IHNob3VsZCBiZSA0MDQsIGV2ZW4gaWYgdGhlIGxpc3QgY29udGFpbnMgc29tZSBl bnRyaWVzLiAgVGhlIHJlYXNvbg0KPiA+ID4gZm9yIHRoaXMgaXMgdGhhdCB0aGVyZSBpcyBubyBy ZXNvdXJjZSBmb3IgdGhlIGxpc3QgaXRzZWxmLCBvbmx5IGZvcg0KPiA+ID4gbGlzdCBlbnRyaWVz LiAgU2VlIHNlY3Rpb24gMy41IG9mIFJGQyA4MDQwLg0KPiA+IA0KPiA+IEFzc3VtaW5nIHlvdSBt ZWFuIHRoZSBmaXJzdCBwYXJhZ3JhcGggbm90IGV4cGxpY2l0bHkgbGlzdGluZyDigJxsaXN04oCd IGFuZCDigJxsZWFmLQ0KPiA+IGxpc3TigJ0sIHRoYXQgY29uZmxpY3RzIHdpdGggU2VjdGlvbiA0 LjMsIFBhcmFncmFwaCA1Lg0KPiA+IA0KPiA+IA0KPiA+ID4gV2UgdXNlZCB0byBoYXZlICJjb2xs ZWN0aW9ucyIgZm9yIHRoaXMgdXNlIGNhc2UsIGJ1dCBpdCB3YXMgbmV2ZXIgZmluaXNoZWQuDQo+ ID4gDQo+ID4gOnNpZ2g6ICAgOykNCj4gPiANCj4gPiANCj4gPiBLZW50IC8vIGNvbnRyaWJ1dG9y DQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Tue Feb 25 12:02:38 2020 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 7272A3A1419 for ; Tue, 25 Feb 2020 12:02:37 -0800 (PST) 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, 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 PxcrZEUXY-Sm for ; Tue, 25 Feb 2020 12:02:34 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4313A131D for ; Tue, 25 Feb 2020 12:02:33 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id DDAA12E778B7 for ; Tue, 25 Feb 2020 21:02:28 +0100 (CET) Received: from s630.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id BEC3A2E27FAF; Tue, 25 Feb 2020 21:02:28 +0100 (CET) Received: from s474.loopia.se (unknown [172.22.191.6]) by s630.loopia.se (Postfix) with ESMTP id B30A913ABEC7; Tue, 25 Feb 2020 21:02:28 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s498.loopia.se ([172.22.191.6]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id p8NpDzpWxVFr; Tue, 25 Feb 2020 21:02:28 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: olof@hagsand.se X-Loopia-Originating-IP: 85.227.89.255 Received: from [10.0.0.14] (ua-85-227-89-255.bbcust.telenor.se [85.227.89.255]) (Authenticated sender: olof@hagsand.se) by s498.loopia.se (Postfix) with ESMTPSA id 17611470830; Tue, 25 Feb 2020 21:02:28 +0100 (CET) To: =?UTF-8?Q?Martin_Bj=c3=b6rklund?= Cc: netconf@ietf.org References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200224.201727.524298611078512416.id@4668.se> From: Olof Hagsand Message-ID: <70fdf9ba-9b48-8cba-a3c2-1366b5a37a8f@hagsand.se> Date: Tue, 25 Feb 2020 21:02:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200224.201727.524298611078512416.id@4668.se> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 25 Feb 2020 20:02:38 -0000 On 2020-02-24 20:17, Martin Björklund wrote: > Hi, > > Olof Hagsand wrote: >> Hello, >> In a restconf GET request of an empty YANG list using JSON encoding, >> what is the expected reply? I.e. using a yang list "x" in module "m" >> (pseudo http): >> GET /restconf/data/m:x >> Accept: application/yang-data+json >> >> Is the reply (1): >> HTTP/1.1 200 OK >> { >> "m:x": [] >> } >> >> or should it be (2) >> "404 Not Found" status-line and error-tag value "invalid-value"? > > It should be 404, even if the list contains some entries. The reason > for this is that there is no resource for the list itself, only for > list entries. See section 3.5 of RFC 8040. > > We used to have "collections" for this use case, but it was never finished. OK, I find that explanation semantically sound, although somewhat disappointing from a usability perspective. But it makes sense and avoids the pitfalls of differences between non-existent and empty lists, for example. But as mentioned elsewhere, I then find paragraph 5 of section 3.5 of RFC 8040 confusing at best, or even irrelevant, if this is the correct interpretation. Thanks. --Olof > > > /martin > > >> >> Apologizes that this is a basic question, and I am sure this is resolved >> properly, but we have some discussions with users on how to properly >> interpret the description of GET in RFC 8040 Section 4.3 and RFC 7951. >> >> Regards, >> Olof Hagsand, >> Clixon maintainer >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Feb 25 14:07:09 2020 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 0EA333A16C5 for ; Tue, 25 Feb 2020 14:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=MF6xwxtj; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=SAMJsWG8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyi0Q-EIAF80 for ; Tue, 25 Feb 2020 14:07:05 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0863A16BF for ; Tue, 25 Feb 2020 14:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45024; q=dns/txt; s=iport; t=1582668425; x=1583878025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pUZ7hf+6ZlY49UVbIChd18KEREYj+z9EPtSryCX6W1g=; b=MF6xwxtjpFzg6vdGJHzhaBFkgYlaVB+ZxrPYtCRvAB5W95fblKPjjUjS hZg7sYI/W5G5R5nv65vVJxS1O5Aw48lTYcFeKigRUtQsQn0aZz0ftZbxC LGo4ffBzDMMwB93j1JGfUinh2k9BV9YUA2a8AQO3l+PzfcOylL12fXDIr M=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3ACp6qBxKOBSiqNEIrPdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCtad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEDlK//2Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAgCjmVVe/4sNJK1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElL1AFbCstIAQLKgqECoNGA4pzgl+JY44xglIDVAI?= =?us-ascii?q?HAQEBCQMBASUIAgQBAYRAAoF+JDgTAgMNAQEFAQEBAgEFBG2FNwyFYwEBAQE?= =?us-ascii?q?DEhEKEwEBNQIBDwIBBgIOAwQBAQ4TAQIEAwICAh8RFAkIAQEEAQ0FCAYNB4M?= =?us-ascii?q?FgX1NAx8PAQ6TAZBnAoE5iGJ1gTKCfwEBBYEzAg5BgwoNC4IFBwMGgTiBU4p?= =?us-ascii?q?RGoFBP4ERR4JMPoIbSQEBAgEBGIFLKwmCWzKCLI1sgnmPeI55RAqCPINwgju?= =?us-ascii?q?BJopehFKCSZhljnCBTYcvgi6QHQIEAgQFAg4BAQWBaSKBWHAVO4JsUBgNjh0?= =?us-ascii?q?MFxWDO4UUhUF0gSmPJgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,485,1574121600"; d="p7s'?scan'208,217";a="436865882" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Feb 2020 22:07:03 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 01PM730E002790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2020 22:07:03 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Feb 2020 16:07:02 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Feb 2020 16:07:01 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Feb 2020 17:07:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ar21z3sYCS+s9Oj5Atb2N6QsfL6QsZsO4eACMfkCN8dJLyRdhSvNJlsmn00vd5iCN8XW5NXtK44y6/EQOca2EWmF9RLQSEjj+h66vYvt3f6vH4F4ORKCtX5nSVMZDxLnacwUn+IUsTOvYCfGGFLcTMkPRb9WhCzGLiVN0/bqhjQ4w8mT7pCUOvPHg3h3YX6zZ3HBB3WRxNxzHn6tFVfSrGZrM8fAF37HWlp0WemaWPpMpC19rXDWS+d0POL+Xee/VfdThUj84nBxeLV2LdO9pUQzcSnWephCE06xFL61ofbei9Ytft0P74oQ6r+HX05j8nnKF08wZf6haF1s1kgWog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GGMTQoxENiEezL/KDJ0WHtzYIC1RPj3ij+0Wm51JwLM=; b=UHWGKXtlsplOMVvSxiaJ4o6f8AGDtwZ1JlqEBz28OSQprBwo2GiOjpUHhNgVGwGF+cGYoGeuciFKyJybE8mtgxQVb71N0hb03aDPjuT3RB1MThxPCww/yRQOqNSgcaahQky2frq7Psl+hkYQuOsl3/Cd+erEUOSEAy9Ov00H0aCTJMIwHJ5dsbdBbHKUm2DjVzCHUv5FiisXrkM9G5o8woIwoMrYXCzyI/mBESApR5s8/gWX3MFd93GXHXKc1CkzT3HeX4T+OElaI7TVRbOZrM3ZmEmocbqq1Mz28+PpV5qXZPzSeo5rpQSAAWZg49CdQoPExsJIiSK6QUID7rOs3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none 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=GGMTQoxENiEezL/KDJ0WHtzYIC1RPj3ij+0Wm51JwLM=; b=SAMJsWG8M2p7naH6p9AOFdx/L27klHfshQJzFXsPWTDh+xvlrgBuzXgTHyJvKoKOfTC0B6J9LAO2r3wy3LCYWnb5+ZH7zrAo/LojBRD38eMA7Ri3xJkyvyjLUiITbwniNCOAM3MtDkXxzkoycpV0GRFJPTcHMU0ire+/0IDDwGg= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3044.namprd11.prod.outlook.com (2603:10b6:208:7a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22; Tue, 25 Feb 2020 22:07:00 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::ec9a:6707:d1ba:ce30]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::ec9a:6707:d1ba:ce30%7]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 22:07:00 +0000 From: "Eric Voit (evoit)" To: Qin Wu , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXrBac3eal5GwGBScmdBP+kDouhpwBIUAJQ Date: Tue, 25 Feb 2020 22:07:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.73] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 980f7425-52c3-4c68-1018-08d7ba3f09d9 x-ms-traffictypediagnostic: BL0PR11MB3044: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(199004)(8936002)(66476007)(110136005)(86362001)(66556008)(26005)(55016002)(66616009)(52536014)(15650500001)(316002)(66446008)(64756008)(66946007)(2906002)(186003)(76116006)(9326002)(71200400001)(9686003)(33656002)(7696005)(81166006)(53546011)(478600001)(4326008)(5660300002)(6506007)(8676002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3044; H:BL0PR11MB3122.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: BCL:0; x-microsoft-antispam-message-info: 8D0vOBjwLEE+Gt2sXKm/9Df9wVivbxVo0bahV7dQWWlEiVapTcgk9qXe9h97TMc43C59ojbBLmcHma7RTRTjj5fHfjQlkR7bcfAYvgcdzKQoJKJWJggs3e5oAScFfELHyE5y1+gCm14BF3A5Y6uaJWIkI3pjokSYFTmdaxTe7gQ6aiz5miVINML6Kl8F8BHyL+7gjBMQyR4IrNl1jhHh9VP36nnoJU40qKwMBBP46frm/I9tNtpVTwT/g52HA0yl7jqxRHsfiWtwz6PnDDt5xYefeMpr372uQoJst656ipdB2odjNHg2VLazJ7zHdMbd8C+7gtfC8YkuEF8fBRXK/z66XrWisnrY10HS83FuX+bjNELbWNpSWBkYxns0HbkA3SO3qcJOBDDFxYxNFGK/qroH7oyp7Lzp6BQ/JHlm1z8rX5vDwibvuVk9MxFXZbpOW6u63Ih9bcdWu48p0l+fGiu/aHhmwp3rLPLhOGejCrbItlU9NzzviRKnRcf0Aqj9BE3g9N0s4NR8gcGh/B8w9A== x-ms-exchange-antispam-messagedata: YqCK+4SfwscWlJUpQk3Yd49zlZA+6IBGOVMFTN+Mo0aWr/J85FPskqmzKWHJ2raELT/jZC4RpmC/nj7GhQDuTyQ9SQjNldFeXqBYg7BPk71hxOrtW13UJ8l6XolVn1F5alCfXflJiQmDHmJUp7ChJw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="----=_NextPart_000_0220_01D5EBFD.FCF251D0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 980f7425-52c3-4c68-1018-08d7ba3f09d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 22:07:00.5531 (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-CrossTenant-userprincipalname: xl+tOiy4WBkfUa6C4qHzylCijvwAX3GFOY7eqgMQZOh6yUu3VM7dvtx27eYXqhyr X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3044 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 25 Feb 2020 22:07:08 -0000 ------=_NextPart_000_0220_01D5EBFD.FCF251D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0221_01D5EBFD.FCF251D0" ------=_NextPart_001_0221_01D5EBFD.FCF251D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Qin, =20 From: Qin Wu, February 24, 2020 6:33 AM Eric: I am wondering if a set of notification per message can be compressed = before being bundled, if the answer is yes, I think data compression = algorithm should be specified. I hadn't planned that we would need to support = per-YANG-Notification compression prior to bundling. Can you articulate = any requirements here? =20 =20 In addition, subscription mode or type (periodical, on change) can be = included as well. As period or on-change is known by the notification type = enclosed, i.e. or , this is already = supported. =20 Eric =20 -Qin =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B42=E6=9C=8821=E6=97=A5 = 21:51 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu >; Mahesh Jethanandani = > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Qin, =20 If the WG wants it, I have no problem adding this leaf-list. Good = catch. =20 Beyond that, do you have examples of such transport specific objects? = Transported objects would be named within the notification itself. And = the prefix associated with the object should be mappable. =20 =20 I believe it should be up to the receiver to correlate the prefix to the = right model. And putting more into each notification would make for = overhead. =20 Eric =20 From: Qin Wu, February 20, 2020 8:30 PM Yes, what I like to see is to have a leaf-list of augmenting models. If a set of specific transport objects within the model can be targeted, = that will also be nice to have. =20 -Qin=20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) [mailto:evoit@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B42=E6=9C=8820=E6=97=A5 = 0:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu >; Mahesh Jethanandani = > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Qin, =20 The parameter "yang-module" is just identifying the YANG module which = contains the definition of the encapsulated notification. I.e., some = reference to the transported objects is needed. =20 That said, the current solution doesn't provide a good solution when new = objects are augmented into an existing notification. So what you bring = up is a valid concern. Do you have suggestions on methods to handle = more complex augmented notifications? One possibility is to have a = leaf-list of augmenting models. Looking at the definitions of these = models would allow extraction of the prefixes used. There are more = complex possibilities here, however each adds to the payload. (It is = not an accident that IPFIX has template records.) =20 Eric=20 =20 From: Qin Wu >=20 Sent: Thursday, February 13, 2020 5:09 AM To: Mahesh Jethanandani >; Eric Voit (evoit) > Cc: netconf@ietf.org =20 Subject: RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? = (Was Re: Configured receiver capability exchange) =20 Eric:=20 Why structure message should tie to a single YANG data module with = =E2=80=9Cyang-module=E2=80=9D parameter, is this too restrictive? =20 -Qin =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 = 8:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) > =E6=8A=84=E9=80=81: netconf@ietf.org =20 =E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange) =20 Hi Eric, =20 This e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread. =20 You have indicated a desire that receiver capabilities should be = documented by the transport specific draft, e.g. = draft-ietf-netconf-https-notif, and not this draft. As such you believe = that the draft is ready. =20 To the WG, the authors have indicated a desire to wrap up this draft, = and would like us, the chairs, to issue a WGLC on it. Before we do that, = we wanted to ask if the WG believes that the document is ready, and that = there are no more issues that need to discussed/addressed by = draft-ietf-netconf-notification-messages document at this time. =20 Cheers. =20 Mahesh and Kent (as co-chairs). =20 On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) > wrote: =20 Hi Mahesh, =20 During the IETF 106 session, there was discussion on how both a = publisher might know if there is receiver support for = draft-ietf-netconf-notification-messages. Section = 6 highlights several of the considerations. Relevant are the = following: =20 (a) Remote device capability discovery from the point of view of the = Publisher needs to be enhanced to know if the far end can interpret = notification messages type beyond RFC-5277, Section 4. =20 (b) This capability discovery question is relevant for both configured = subscription receivers and dynamic subscribers. =20 =20 (c) The capability discovery question can be generalized beyond = subscriptions, as there are many reasons to know the available = capabilities of the far end. =20 =20 (d) Capability discovery advertisement has traditionally been discussed = within transport documents (e.g. RFC-6241 Section 8.1). =20 =20 =20 Based on (a)-(d), coming up with a transport independent point-solution = within = draft-ietf-netconf-notification-messages *just* to = discover this single element of client functionality seems = overkill/heavyweight. =20 I was fine with letting this remote capabilities discovery question sit = for a while. However = = draft-ietf-netconf-https-notif shows that we now must address this = question. Specifically should the diagram section 1.4.1 show this = capability exchange? =20 =20 It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway. These questions are: (1) Does the targeted HTTPS receiver support configured subscriptions? (2) Can the targeted HTTP@ receiver accept a new subscription as = described in a ? Only if these questions are "yes", should the be = responded to with an "OK". =20 Add to this a third question driven from (a)-(d): (3) Does the receiver support the message type within = "draft-ietf-netconf-notification-messages"? =20 A strawman way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = notification with an HTTP Status 202 (Accepted)" = acknowledgement. This 202 would include body elements listing supported = receiver resources. Maybe something YANG encoded via = ietf-yang-structure-ext containing: =20 urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0 =20 What do you think of this approach? =20 Eric =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 =20 ------=_NextPart_001_0221_01D5EBFD.FCF251D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Qin,

 

From:<= /b> = Qin Wu, February 24, 2020 6:33 AM

Eric:

I am wondering if a set of notification per = message can be compressed before being bundled, if the answer is yes, I = think data compression algorithm should be = specified.

<eric> I hadn't planned that we would need to = support per-YANG-Notification compression prior to bundling.=C2=A0 Can = you articulate any requirements here?=C2=A0

 

In addition, subscription mode or type = (periodical, on change) can be included as well.

<eric> As period or on-change is known by the = notification type enclosed,=C2=A0 i.e. <push-update> or = <push-change-update>, this is already = supported.

 

Eric

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA= : Eric Voit (evoit) [mailto:evoit@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B42=E6=9C=8821=E6=97=A5 21:51
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>; Mahesh = Jethanandani <mjethanandani@gmail.com>=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi Qin,

 

If the WG wants it, I have no problem adding this = leaf-list.  Good catch.

 

Beyond that, do you have examples of such transport = specific objects?   Transported objects would be named within = the notification itself.  And the prefix associated with the object = should be mappable. 

 

I believe it should be up to the receiver to correlate the = prefix to the right model. And putting more into each notification would = make for overhead.

 

Eric

 

From: Qin Wu, February 20, 2020 8:30 PM

Yes, what I like to see is to have a = leaf-list of augmenting models.

If a set of specific transport objects = within the model can be targeted, that will also be nice to = have.

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA= : Eric Voit (evoit) [mailto:evoit@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B42=E6=9C=8820=E6=97=A5 0:07
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>; Mahesh = Jethanandani <mjethanandani@gmail.com>=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: RE: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi Qin,

 

The parameter "yang-module" is just identifying = the YANG module which contains the definition of the encapsulated = notification.  I.e., some reference to the transported objects is = needed.

 

That said, the current solution doesn't provide a good = solution when new objects are augmented into an existing = notification.  So what you bring up is a valid concern.   = Do you have suggestions on methods to handle more complex augmented = notifications?  One possibility is to have a leaf-list of = augmenting models.  Looking at the definitions of these models = would allow extraction of the prefixes used.  There are more = complex possibilities here, however each adds to the payload.  =  (It is not an accident that IPFIX has template = records.)

 

Eric

 

From: Qin Wu <bill.wu@huawei.com> =
Sent: Thursday, February 13, 2020 5:09 AM
To: = Mahesh Jethanandani <mjethanandani@gmail.com>; = Eric Voit (evoit) <evoit@cisco.com>
Cc: netconf@ietf.org
Subject: = RE: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: = Configured receiver capability = exchange)

 

Eric: 

Why structure message should tie to = a single YANG data module with =E2=80=9Cyang-module=E2=80=9D parameter, = is this too restrictive?

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA= : netconf [mailto:netconf-bounces@ietf.org<= /a>] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B41=E6=9C=8828=E6=97=A5 8:19
=E6=94=B6=E4=BB=B6=E4=BA=BA: Eric Voit (evoit) = <evoit@cisco.com>
=E6=8A=84=E9=80=81: netconf@ietf.org
=E4=B8=BB=E9=A2=98: [netconf] WGLC on = draft-ietf-netconf-notification-messages? (Was Re: Configured receiver = capability exchange)

 

Hi = Eric,

 

This = e-mail triggers two responses. Let us deal with = draft-ietf-netconf-notification-messages here, and I will bring up = comments/questions related to draft-ietf-netconf-https-notif in the = other thread.

 

You = have indicated a desire that receiver capabilities should be documented = by the transport specific draft, e.g. draft-ietf-netconf-https-notif, = and not this draft. As such you believe that the draft is = ready.

 

To = the WG, the authors have indicated a desire to wrap up this draft, and = would like us, the chairs, to issue a WGLC on it. Before we do that, we = wanted to ask if the WG believes that the document is ready, and that = there are no more issues that need to discussed/addressed by = draft-ietf-netconf-notification-messages document at this = time.

 

Cheers.

<= div>

 

Mahesh and Kent (as = co-chairs).

 

(d) Capability discovery advertisement has traditionally = been discussed within transport documents (e.g. RFC-6241 Section = 8.1).   

 

 

I was fine with letting this remote capabilities discovery = question sit for a while.   However draft-ietf-netconf-https-notif shows that we now must = address this question.  Specifically should the diagram section = 1.4.1 show this capability exchange?  

 

It turns out that independent of = draft-ietf-netconf-notification-messages, there several questions in = draft-ietf-netconf-https-notif which need to be answered prior to the = section 1.4.1 arrow: "Send HTTPS POST message with YANG defined = notification #1" anyway.  These questions = are:

  (1) Does the targeted HTTPS receiver support = configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a new = subscription as described in a = <subscription-started>?

Only if these questions are "yes", should the = <subscription-started> be responded to with an = "OK".

 

Add to this a third question driven from = (a)-(d):

  (3) Does the receiver support the message type = within = "draft-ietf-netconf-notification-messages"?

 

A strawman way to handle the all three questions within = draft-ietf-netconf-https-notif would be to respond to a = <subscription-started> notification with an HTTP Status 202 = (Accepted)" acknowledgement.  This 202 would include body = elements listing supported receiver resources.  Maybe something = YANG encoded via ietf-yang-structure-ext = containing:

 

      <foo = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

        = <capabilities>

          = <capability>

          = ;  = urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

          = </capability>

    =     </capabilities>

=

      = </foo>

 

What do you think of this = approach?

 

Eric

 

Mahesh = Jethanandani

 

 

 

------=_NextPart_001_0221_01D5EBFD.FCF251D0-- ------=_NextPart_000_0220_01D5EBFD.FCF251D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMjI1MjIwNjU4WjAjBgkqhkiG 9w0BCQQxFgQUSXrE3ZnTt2uBAEtZecrqj62tlCswSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAtAr2pfTXp3exUu+cdF8EMvlKAnigEaISwwLOadl80n5URRj51zRlzVM19ti4yRW/8 UGzhl8MW2UNeMZx0Xh1Be7VISRX7C+smG5Jj/obzpaKxmKnPmX/zZounFv7wduqVhn+3p3q1G1lZ G6+355CjlqOwHJpONnaRqAPcDrmmxfaX03Ljl2bdcDx6od0Rgiv51vNcvbAjK1YO505ExTWO3Ji1 DS4gF+q7zIRdxYbuxmIycs0xl9oJl9N3fF7lDf59/9R9QLqYx2uRwzjC+HXVcMJlkIYS/ukk23Op pOOiZKZE9steuFjpMd2E8nPOFJ9eRxwWdUDmJEOFI4GfCHMXAAAAAAAA ------=_NextPart_000_0220_01D5EBFD.FCF251D0-- From nobody Thu Feb 27 05:24:37 2020 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 6CED43A082C for ; Thu, 27 Feb 2020 05:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pKzDfSKcdpYz for ; Thu, 27 Feb 2020 05:24:34 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F503A0814 for ; Thu, 27 Feb 2020 05:24:33 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4C115B4137DE91633CA5; Thu, 27 Feb 2020 13:24:32 +0000 (GMT) Received: from lhreml723-chm.china.huawei.com (10.201.108.74) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Feb 2020 13:24:31 +0000 Received: from lhreml723-chm.china.huawei.com (10.201.108.74) by lhreml723-chm.china.huawei.com (10.201.108.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 27 Feb 2020 13:24:31 +0000 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml723-chm.china.huawei.com (10.201.108.74) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 27 Feb 2020 13:24:31 +0000 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.89]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Thu, 27 Feb 2020 21:24:26 +0800 From: Qin Wu To: "Eric Voit (evoit)" , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) Thread-Index: AdXtcLrjrPvmg1iKSyiDRuU/SCm4gQ== Date: Thu, 27 Feb 2020 13:24:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.123] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD4E676Edggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange) 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, 27 Feb 2020 13:24:37 -0000 --_000_B8F9A780D330094D99AF023C5877DABAAD4E676Edggeml511mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYzoNCuWPkeS7tuS6ujogRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5j b21dDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQy5pyIMjbml6UgNjowNw0K5pS25Lu25Lq6OiBRaW4g V3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRh bmlAZ21haWwuY29tPg0K5oqE6YCBOiBuZXRjb25mQGlldGYub3JnDQrkuLvpopg6IFJFOiBbbmV0 Y29uZl0gV0dMQyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPyAo V2FzIFJlOiBDb25maWd1cmVkIHJlY2VpdmVyIGNhcGFiaWxpdHkgZXhjaGFuZ2UpDQoNCkhpIFFp biwNCg0KRnJvbTogUWluIFd1LCBGZWJydWFyeSAyNCwgMjAyMCA2OjMzIEFNDQpFcmljOg0KSSBh bSB3b25kZXJpbmcgaWYgYSBzZXQgb2Ygbm90aWZpY2F0aW9uIHBlciBtZXNzYWdlIGNhbiBiZSBj b21wcmVzc2VkIGJlZm9yZSBiZWluZyBidW5kbGVkLCBpZiB0aGUgYW5zd2VyIGlzIHllcywgSSB0 aGluayBkYXRhIGNvbXByZXNzaW9uIGFsZ29yaXRobSBzaG91bGQgYmUgc3BlY2lmaWVkLg0KPGVy aWM+IEkgaGFkbid0IHBsYW5uZWQgdGhhdCB3ZSB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgcGVyLVlB TkctTm90aWZpY2F0aW9uIGNvbXByZXNzaW9uIHByaW9yIHRvIGJ1bmRsaW5nLiAgQ2FuIHlvdSBh cnRpY3VsYXRlIGFueSByZXF1aXJlbWVudHMgaGVyZT8NCltRaW5dOiBZb3UgbWlnaHQgdXNlIGJ1 bmRsZWQgbWVzc2FnZSB0byBjYXJyeSBzb21lIGJ5dGVzdHJlYW0gY29udGVudCBvciBiaW5hcnkg ZW5jb2RlZCBkYXRhLiBTbyB5b3UgbWF5IG5lZWQgdG8gc3VwcG9ydCBnemlwLCBkZWZsYXQgY29t cHJlc3Npb24gYWxnb3JpdGhtcy4NCkluIGFkZGl0aW9uLCBzdWJzY3JpcHRpb24gbW9kZSBvciB0 eXBlIChwZXJpb2RpY2FsLCBvbiBjaGFuZ2UpIGNhbiBiZSBpbmNsdWRlZCBhcyB3ZWxsLg0KPGVy aWM+IEFzIHBlcmlvZCBvciBvbi1jaGFuZ2UgaXMga25vd24gYnkgdGhlIG5vdGlmaWNhdGlvbiB0 eXBlIGVuY2xvc2VkLCAgaS5lLiA8cHVzaC11cGRhdGU+IG9yIDxwdXNoLWNoYW5nZS11cGRhdGU+ LCB0aGlzIGlzIGFscmVhZHkgc3VwcG9ydGVkLg0KW1Fpbl06IEkga25vdywgYnV0IHlvdSBrbm93 IG5lZWQgdG8gc3VwcG9ydCBvdGhlciBzdWJzY3JpcHRpb24gdHlwZXMgc3VjaCBhcyBzdWJzY3Jp cHRpb24gdGhhdCBpcyBjb21iaW5hdGlvbiBvZiBwZXJpb2RpYyBzdWJzY3JpcHRpb24gYW5kIG9u LWNoYW5nZSBzdWJzY3JpcHRpb24sIHdlIGNhbiBjYWxsIGFkYXB0aXZlIHN1YnNjcmlwdGlvbi4N CkVyaWMNCg0KLVFpbg0K5Y+R5Lu25Lq6OiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0 QGNpc2NvLmNvbV0NCuWPkemAgeaXtumXtDogMjAyMOW5tDLmnIgyMeaXpSAyMTo1MQ0K5pS25Lu2 5Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29t Pj47IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+DQrmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmc+DQrkuLvpopg6IFJFOiBbbmV0Y29uZl0gV0dMQyBvbiBkcmFmdC1p ZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPyAoV2FzIFJlOiBDb25maWd1cmVkIHJl Y2VpdmVyIGNhcGFiaWxpdHkgZXhjaGFuZ2UpDQoNCkhpIFFpbiwNCg0KSWYgdGhlIFdHIHdhbnRz IGl0LCBJIGhhdmUgbm8gcHJvYmxlbSBhZGRpbmcgdGhpcyBsZWFmLWxpc3QuICBHb29kIGNhdGNo Lg0KDQpCZXlvbmQgdGhhdCwgZG8geW91IGhhdmUgZXhhbXBsZXMgb2Ygc3VjaCB0cmFuc3BvcnQg c3BlY2lmaWMgb2JqZWN0cz8gICBUcmFuc3BvcnRlZCBvYmplY3RzIHdvdWxkIGJlIG5hbWVkIHdp dGhpbiB0aGUgbm90aWZpY2F0aW9uIGl0c2VsZi4gIEFuZCB0aGUgcHJlZml4IGFzc29jaWF0ZWQg d2l0aCB0aGUgb2JqZWN0IHNob3VsZCBiZSBtYXBwYWJsZS4NCg0KSSBiZWxpZXZlIGl0IHNob3Vs ZCBiZSB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gY29ycmVsYXRlIHRoZSBwcmVmaXggdG8gdGhlIHJp Z2h0IG1vZGVsLiBBbmQgcHV0dGluZyBtb3JlIGludG8gZWFjaCBub3RpZmljYXRpb24gd291bGQg bWFrZSBmb3Igb3ZlcmhlYWQuDQoNCkVyaWMNCg0KRnJvbTogUWluIFd1LCBGZWJydWFyeSAyMCwg MjAyMCA4OjMwIFBNDQpZZXMsIHdoYXQgSSBsaWtlIHRvIHNlZSBpcyB0byBoYXZlIGEgbGVhZi1s aXN0IG9mIGF1Z21lbnRpbmcgbW9kZWxzLg0KSWYgYSBzZXQgb2Ygc3BlY2lmaWMgdHJhbnNwb3J0 IG9iamVjdHMgd2l0aGluIHRoZSBtb2RlbCBjYW4gYmUgdGFyZ2V0ZWQsIHRoYXQgd2lsbCBhbHNv IGJlIG5pY2UgdG8gaGF2ZS4NCg0KLVFpbg0K5Y+R5Lu25Lq6OiBFcmljIFZvaXQgKGV2b2l0KSBb bWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NCuWPkemAgeaXtumXtDogMjAyMOW5tDLmnIgyMOaXpSAw OjA3DQrmlLbku7bkuro6IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1 QGh1YXdlaS5jb20+PjsgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5j b208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4NCuaKhOmAgTogbmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCuS4u+mimDogUkU6IFtuZXRjb25mXSBXR0xD IG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENv bmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSkNCg0KSGkgUWluLA0KDQpUaGUg cGFyYW1ldGVyICJ5YW5nLW1vZHVsZSIgaXMganVzdCBpZGVudGlmeWluZyB0aGUgWUFORyBtb2R1 bGUgd2hpY2ggY29udGFpbnMgdGhlIGRlZmluaXRpb24gb2YgdGhlIGVuY2Fwc3VsYXRlZCBub3Rp ZmljYXRpb24uICBJLmUuLCBzb21lIHJlZmVyZW5jZSB0byB0aGUgdHJhbnNwb3J0ZWQgb2JqZWN0 cyBpcyBuZWVkZWQuDQoNClRoYXQgc2FpZCwgdGhlIGN1cnJlbnQgc29sdXRpb24gZG9lc24ndCBw cm92aWRlIGEgZ29vZCBzb2x1dGlvbiB3aGVuIG5ldyBvYmplY3RzIGFyZSBhdWdtZW50ZWQgaW50 byBhbiBleGlzdGluZyBub3RpZmljYXRpb24uICBTbyB3aGF0IHlvdSBicmluZyB1cCBpcyBhIHZh bGlkIGNvbmNlcm4uICAgRG8geW91IGhhdmUgc3VnZ2VzdGlvbnMgb24gbWV0aG9kcyB0byBoYW5k bGUgbW9yZSBjb21wbGV4IGF1Z21lbnRlZCBub3RpZmljYXRpb25zPyAgT25lIHBvc3NpYmlsaXR5 IGlzIHRvIGhhdmUgYSBsZWFmLWxpc3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuICBMb29raW5nIGF0 IHRoZSBkZWZpbml0aW9ucyBvZiB0aGVzZSBtb2RlbHMgd291bGQgYWxsb3cgZXh0cmFjdGlvbiBv ZiB0aGUgcHJlZml4ZXMgdXNlZC4gIFRoZXJlIGFyZSBtb3JlIGNvbXBsZXggcG9zc2liaWxpdGll cyBoZXJlLCBob3dldmVyIGVhY2ggYWRkcyB0byB0aGUgcGF5bG9hZC4gICAoSXQgaXMgbm90IGFu IGFjY2lkZW50IHRoYXQgSVBGSVggaGFzIHRlbXBsYXRlIHJlY29yZHMuKQ0KDQpFcmljDQoNCkZy b206IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+ Pg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDIwIDU6MDkgQU0NClRvOiBNYWhlc2gg SmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFu aUBnbWFpbC5jb20+PjsgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86 ZXZvaXRAY2lzY28uY29tPj4NCkNjOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGll dGYub3JnPg0KU3ViamVjdDogUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29u Zi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2Fw YWJpbGl0eSBleGNoYW5nZSkNCg0KRXJpYzoNCldoeSBzdHJ1Y3R1cmUgbWVzc2FnZSBzaG91bGQg dGllIHRvIGEgc2luZ2xlIFlBTkcgZGF0YSBtb2R1bGUgd2l0aCDigJx5YW5nLW1vZHVsZeKAnSBw YXJhbWV0ZXIsIGlzIHRoaXMgdG9vIHJlc3RyaWN0aXZlPw0KDQotUWluDQrlj5Hku7bkuro6IG5l dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBNYWhlc2ggSmV0 aGFuYW5kYW5pDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQx5pyIMjjml6UgODoxOQ0K5pS25Lu25Lq6 OiBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5j b20+Pg0K5oqE6YCBOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K 5Li76aKYOiBbbmV0Y29uZl0gV0dMQyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LW1lc3NhZ2VzPyAoV2FzIFJlOiBDb25maWd1cmVkIHJlY2VpdmVyIGNhcGFiaWxpdHkgZXhjaGFu Z2UpDQoNCkhpIEVyaWMsDQoNClRoaXMgZS1tYWlsIHRyaWdnZXJzIHR3byByZXNwb25zZXMuIExl dCB1cyBkZWFsIHdpdGggZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcyBo ZXJlLCBhbmQgSSB3aWxsIGJyaW5nIHVwIGNvbW1lbnRzL3F1ZXN0aW9ucyByZWxhdGVkIHRvIGRy YWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiBpbiB0aGUgb3RoZXIgdGhyZWFkLg0KDQpZb3Ug aGF2ZSBpbmRpY2F0ZWQgYSBkZXNpcmUgdGhhdCByZWNlaXZlciBjYXBhYmlsaXRpZXMgc2hvdWxk IGJlIGRvY3VtZW50ZWQgYnkgdGhlIHRyYW5zcG9ydCBzcGVjaWZpYyBkcmFmdCwgZS5nLiBkcmFm dC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYsIGFuZCBub3QgdGhpcyBkcmFmdC4gQXMgc3VjaCB5 b3UgYmVsaWV2ZSB0aGF0IHRoZSBkcmFmdCBpcyByZWFkeS4NCg0KVG8gdGhlIFdHLCB0aGUgYXV0 aG9ycyBoYXZlIGluZGljYXRlZCBhIGRlc2lyZSB0byB3cmFwIHVwIHRoaXMgZHJhZnQsIGFuZCB3 b3VsZCBsaWtlIHVzLCB0aGUgY2hhaXJzLCB0byBpc3N1ZSBhIFdHTEMgb24gaXQuIEJlZm9yZSB3 ZSBkbyB0aGF0LCB3ZSB3YW50ZWQgdG8gYXNrIGlmIHRoZSBXRyBiZWxpZXZlcyB0aGF0IHRoZSBk b2N1bWVudCBpcyByZWFkeSwgYW5kIHRoYXQgdGhlcmUgYXJlIG5vIG1vcmUgaXNzdWVzIHRoYXQg bmVlZCB0byBkaXNjdXNzZWQvYWRkcmVzc2VkIGJ5IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmlj YXRpb24tbWVzc2FnZXMgZG9jdW1lbnQgYXQgdGhpcyB0aW1lLg0KDQpDaGVlcnMuDQoNCk1haGVz aCBhbmQgS2VudCAoYXMgY28tY2hhaXJzKS4NCg0KT24gSmFuIDE1LCAyMDIwLCBhdCAxMjoyMyBQ TSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86ZXZvaXRAY2lzY28u Y29tPj4gd3JvdGU6DQoNCkhpIE1haGVzaCwNCg0KRHVyaW5nIHRoZSBJRVRGIDEwNiBzZXNzaW9u LCB0aGVyZSB3YXMgZGlzY3Vzc2lvbiBvbiBob3cgYm90aCBhIHB1Ymxpc2hlciBtaWdodCBrbm93 IGlmIHRoZXJlIGlzIHJlY2VpdmVyIHN1cHBvcnQgZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tbWVzc2FnZXM8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcy8/aW5jbHVkZV90ZXh0PTE+LiAgU2Vj dGlvbiA2IGhpZ2hsaWdodHMgc2V2ZXJhbCBvZiB0aGUgY29uc2lkZXJhdGlvbnMuICAgUmVsZXZh bnQgYXJlIHRoZSBmb2xsb3dpbmc6DQoNCihhKSBSZW1vdGUgZGV2aWNlIGNhcGFiaWxpdHkgZGlz Y292ZXJ5IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIFB1Ymxpc2hlciBuZWVkcyB0byBi ZSBlbmhhbmNlZCB0byBrbm93IGlmIHRoZSBmYXIgZW5kIGNhbiBpbnRlcnByZXQgbm90aWZpY2F0 aW9uIG1lc3NhZ2VzIHR5cGUgYmV5b25kIFJGQy01Mjc3LCBTZWN0aW9uIDQuDQoNCihiKSBUaGlz IGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1ZXN0aW9uIGlzIHJlbGV2YW50IGZvciBib3RoIGNvbmZp Z3VyZWQgc3Vic2NyaXB0aW9uIHJlY2VpdmVycyBhbmQgZHluYW1pYyBzdWJzY3JpYmVycy4NCg0K KGMpIFRoZSBjYXBhYmlsaXR5IGRpc2NvdmVyeSBxdWVzdGlvbiBjYW4gYmUgZ2VuZXJhbGl6ZWQg YmV5b25kIHN1YnNjcmlwdGlvbnMsIGFzIHRoZXJlIGFyZSBtYW55IHJlYXNvbnMgdG8ga25vdyB0 aGUgYXZhaWxhYmxlIGNhcGFiaWxpdGllcyBvZiB0aGUgZmFyIGVuZC4NCg0KKGQpIENhcGFiaWxp dHkgZGlzY292ZXJ5IGFkdmVydGlzZW1lbnQgaGFzIHRyYWRpdGlvbmFsbHkgYmVlbiBkaXNjdXNz ZWQgd2l0aGluIHRyYW5zcG9ydCBkb2N1bWVudHMgKGUuZy4gUkZDLTYyNDEgU2VjdGlvbiA4LjEp Lg0KDQoNCkJhc2VkIG9uIChhKS0oZCksIGNvbWluZyB1cCB3aXRoIGEgdHJhbnNwb3J0IGluZGVw ZW5kZW50IHBvaW50LXNvbHV0aW9uIHdpdGhpbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLW1lc3NhZ2VzPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2luY2x1ZGVfdGV4dD0xPiAqanVzdCogdG8g ZGlzY292ZXIgdGhpcyBzaW5nbGUgZWxlbWVudCBvZiBjbGllbnQgZnVuY3Rpb25hbGl0eSBzZWVt cyBvdmVya2lsbC9oZWF2eXdlaWdodC4NCg0KSSB3YXMgZmluZSB3aXRoIGxldHRpbmcgdGhpcyBy ZW1vdGUgY2FwYWJpbGl0aWVzIGRpc2NvdmVyeSBxdWVzdGlvbiBzaXQgZm9yIGEgd2hpbGUuICAg SG93ZXZlciBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWY8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wMT4gc2hvd3MgdGhhdCB3 ZSBub3cgbXVzdCBhZGRyZXNzIHRoaXMgcXVlc3Rpb24uICBTcGVjaWZpY2FsbHkgc2hvdWxkIHRo ZSBkaWFncmFtIHNlY3Rpb24gMS40LjEgc2hvdyB0aGlzIGNhcGFiaWxpdHkgZXhjaGFuZ2U/DQoN Ckl0IHR1cm5zIG91dCB0aGF0IGluZGVwZW5kZW50IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tbWVzc2FnZXMsIHRoZXJlIHNldmVyYWwgcXVlc3Rpb25zIGluIGRyYWZ0LWlldGYt bmV0Y29uZi1odHRwcy1ub3RpZiB3aGljaCBuZWVkIHRvIGJlIGFuc3dlcmVkIHByaW9yIHRvIHRo ZSBzZWN0aW9uIDEuNC4xIGFycm93OiAiU2VuZCBIVFRQUyBQT1NUIG1lc3NhZ2Ugd2l0aCBZQU5H IGRlZmluZWQgbm90aWZpY2F0aW9uICMxIiBhbnl3YXkuICBUaGVzZSBxdWVzdGlvbnMgYXJlOg0K ICAoMSkgRG9lcyB0aGUgdGFyZ2V0ZWQgSFRUUFMgcmVjZWl2ZXIgc3VwcG9ydCBjb25maWd1cmVk IHN1YnNjcmlwdGlvbnM/DQogICgyKSBDYW4gdGhlIHRhcmdldGVkIEhUVFBAIHJlY2VpdmVyIGFj Y2VwdCBhIG5ldyBzdWJzY3JpcHRpb24gYXMgZGVzY3JpYmVkIGluIGEgPHN1YnNjcmlwdGlvbi1z dGFydGVkPj8NCk9ubHkgaWYgdGhlc2UgcXVlc3Rpb25zIGFyZSAieWVzIiwgc2hvdWxkIHRoZSA8 c3Vic2NyaXB0aW9uLXN0YXJ0ZWQ+IGJlIHJlc3BvbmRlZCB0byB3aXRoIGFuICJPSyIuDQoNCkFk ZCB0byB0aGlzIGEgdGhpcmQgcXVlc3Rpb24gZHJpdmVuIGZyb20gKGEpLShkKToNCiAgKDMpIERv ZXMgdGhlIHJlY2VpdmVyIHN1cHBvcnQgdGhlIG1lc3NhZ2UgdHlwZSB3aXRoaW4gImRyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMiPw0KDQpBIHN0cmF3bWFuIHdheSB0byBo YW5kbGUgdGhlIGFsbCB0aHJlZSBxdWVzdGlvbnMgd2l0aGluIGRyYWZ0LWlldGYtbmV0Y29uZi1o dHRwcy1ub3RpZiB3b3VsZCBiZSB0byByZXNwb25kIHRvIGEgPHN1YnNjcmlwdGlvbi1zdGFydGVk PiBub3RpZmljYXRpb24gd2l0aCBhbiBIVFRQIFN0YXR1cyAyMDIgKEFjY2VwdGVkKSIgYWNrbm93 bGVkZ2VtZW50LiAgVGhpcyAyMDIgd291bGQgaW5jbHVkZSBib2R5IGVsZW1lbnRzIGxpc3Rpbmcg c3VwcG9ydGVkIHJlY2VpdmVyIHJlc291cmNlcy4gIE1heWJlIHNvbWV0aGluZyBZQU5HIGVuY29k ZWQgdmlhIGlldGYteWFuZy1zdHJ1Y3R1cmUtZXh0IGNvbnRhaW5pbmc6DQoNCiAgICAgIDxmb28g eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICAg IDxjYXBhYmlsaXRpZXM+DQogICAgICAgICAgPGNhcGFiaWxpdHk+DQogICAgICAgICAgICB1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1ub3RpZmljYXRpb24tbWVzc2FnZXM6MS4wDQog ICAgICAgICAgPC9jYXBhYmlsaXR5Pg0KICAgICAgICA8L2NhcGFiaWxpdGllcz4NCiAgICAgIDwv Zm9vPg0KDQpXaGF0IGRvIHlvdSB0aGluayBvZiB0aGlzIGFwcHJvYWNoPw0KDQpFcmljDQoNCk1h aGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFu YW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABAAD4E676Edggeml511mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBW b2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAyMDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjI8L3NwYW4+5pyI PHNwYW4gbGFuZz0iRU4tVVMiPjI2PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiA2OjA3 PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+IFFpbiBXdSAmbHQ7YmlsbC53dUBodWF3ZWkuY29tJmd0OzsgTWFo ZXNoIEpldGhhbmFuZGFuaSAmbHQ7bWpldGhhbmFuZGFuaUBnbWFpbC5jb20mZ3Q7PGJyPg0KPC9z cGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0i RU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IFtuZXRjb25mXSBXR0xD IG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENv bmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBRaW4sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBRaW4gV3UsIEZlYnJ1YXJ5IDI0LCAyMDIwIDY6MzMgQU08L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gd29uZGVyaW5nIGlmIGEgc2V0IG9m IG5vdGlmaWNhdGlvbiBwZXIgbWVzc2FnZSBjYW4gYmUgY29tcHJlc3NlZCBiZWZvcmUgYmVpbmcg YnVuZGxlZCwgaWYgdGhlIGFuc3dlciBpcyB5ZXMsIEkgdGhpbmsgZGF0YSBjb21wcmVzc2lvbiBh bGdvcml0aG0NCiBzaG91bGQgYmUgc3BlY2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDtlcmlj Jmd0OyBJIGhhZG4ndCBwbGFubmVkIHRoYXQgd2Ugd291bGQgbmVlZCB0byBzdXBwb3J0IHBlci1Z QU5HLU5vdGlmaWNhdGlvbiBjb21wcmVzc2lvbiBwcmlvciB0byBidW5kbGluZy4mbmJzcDsgQ2Fu IHlvdSBhcnRpY3VsYXRlIGFueSByZXF1aXJlbWVudHMgaGVyZT8mbmJzcDsNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFlvdSBtaWdodCB1c2UgYnVuZGxlZCBtZXNzYWdl IHRvIGNhcnJ5IHNvbWUgYnl0ZXN0cmVhbSBjb250ZW50IG9yIGJpbmFyeSBlbmNvZGVkIGRhdGEu IFNvIHlvdSBtYXkgbmVlZCB0byBzdXBwb3J0IGd6aXAsIGRlZmxhdCBjb21wcmVzc2lvbg0KIGFs Z29yaXRobXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gYWRkaXRpb24sIHN1YnNjcmlwdGlvbiBtb2RlIG9yIHR5 cGUgKHBlcmlvZGljYWwsIG9uIGNoYW5nZSkgY2FuIGJlIGluY2x1ZGVkIGFzIHdlbGwuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmx0O2VyaWMmZ3Q7IEFzIHBlcmlvZCBvciBvbi1jaGFuZ2UgaXMga25vd24g YnkgdGhlIG5vdGlmaWNhdGlvbiB0eXBlIGVuY2xvc2VkLCZuYnNwOyBpLmUuICZsdDtwdXNoLXVw ZGF0ZSZndDsgb3IgJmx0O3B1c2gtY2hhbmdlLXVwZGF0ZSZndDssIHRoaXMgaXMgYWxyZWFkeSBz dXBwb3J0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUWluXTogSSBrbm93LCBi dXQgeW91IGtub3cgbmVlZCB0byBzdXBwb3J0IG90aGVyIHN1YnNjcmlwdGlvbiB0eXBlcyBzdWNo IGFzIHN1YnNjcmlwdGlvbiB0aGF0IGlzIGNvbWJpbmF0aW9uIG9mIHBlcmlvZGljIHN1YnNjcmlw dGlvbiBhbmQgb24tY2hhbmdlDQogc3Vic2NyaXB0aW9uLCB3ZSBjYW4gY2FsbCBhZGFwdGl2ZSBz dWJzY3JpcHRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFZvaXQg KGV2b2l0KSBbPGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+bWFpbHRvOmV2b2l0QGNp c2NvLmNvbTwvYT5dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkemA geaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAyMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ 5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjI8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIxPC9z cGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAyMTo1MTxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBRaW4g V3UgJmx0OzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2Vp LmNvbTwvYT4mZ3Q7OyBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDs8YnI+ DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPg0KbmV0Y29uZkBp ZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVj ZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBRaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SWYgdGhlIFdHIHdhbnRzIGl0LCBJIGhhdmUgbm8gcHJvYmxlbSBhZGRp bmcgdGhpcyBsZWFmLWxpc3QuJm5ic3A7IEdvb2QgY2F0Y2guPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QmV5b25kIHRoYXQsIGRvIHlvdSBoYXZlIGV4YW1wbGVzIG9m IHN1Y2ggdHJhbnNwb3J0IHNwZWNpZmljIG9iamVjdHM/Jm5ic3A7Jm5ic3A7IFRyYW5zcG9ydGVk IG9iamVjdHMgd291bGQgYmUgbmFtZWQgd2l0aGluIHRoZSBub3RpZmljYXRpb24gaXRzZWxmLiZu YnNwOyBBbmQgdGhlIHByZWZpeCBhc3NvY2lhdGVkDQogd2l0aCB0aGUgb2JqZWN0IHNob3VsZCBi ZSBtYXBwYWJsZS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SSBiZWxpZXZlIGl0IHNob3VsZCBiZSB1cCB0byB0aGUgcmVjZWl2ZXIgdG8gY29ycmVsYXRl IHRoZSBwcmVmaXggdG8gdGhlIHJpZ2h0IG1vZGVsLiBBbmQgcHV0dGluZyBtb3JlIGludG8gZWFj aCBub3RpZmljYXRpb24gd291bGQgbWFrZSBmb3Igb3ZlcmhlYWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gUWluIFd1LCBGZWJydWFyeSAyMCwgMjAyMCA4OjMwIFBNPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgd2hhdCBJIGxpa2UgdG8g c2VlIGlzIHRvIGhhdmUgYSBsZWFmLWxpc3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBhIHNldCBvZiBzcGVjaWZpYyB0cmFuc3BvcnQgb2Jq ZWN0cyB3aXRoaW4gdGhlIG1vZGVsIGNhbiBiZSB0YXJnZXRlZCwgdGhhdCB3aWxsIGFsc28gYmUg bmljZSB0byBoYXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tUWluDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBWb2l0 IChldm9pdCkgWzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPm1haWx0bzpldm9pdEBj aXNjby5jb208L2E+XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4yPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMDwv c3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMDowNzxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBRaW4g V3UgJmx0OzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2Vp LmNvbTwvYT4mZ3Q7OyBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDs8YnI+ DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPg0KbmV0Y29uZkBp ZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWll dGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVj ZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5nZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBRaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhlIHBhcmFtZXRlciAmcXVvdDt5YW5nLW1vZHVsZSZxdW90OyBpcyBq dXN0IGlkZW50aWZ5aW5nIHRoZSBZQU5HIG1vZHVsZSB3aGljaCBjb250YWlucyB0aGUgZGVmaW5p dGlvbiBvZiB0aGUgZW5jYXBzdWxhdGVkIG5vdGlmaWNhdGlvbi4mbmJzcDsgSS5lLiwgc29tZSBy ZWZlcmVuY2UgdG8gdGhlIHRyYW5zcG9ydGVkDQogb2JqZWN0cyBpcyBuZWVkZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBzYWlkLCB0aGUgY3VycmVudCBz b2x1dGlvbiBkb2Vzbid0IHByb3ZpZGUgYSBnb29kIHNvbHV0aW9uIHdoZW4gbmV3IG9iamVjdHMg YXJlIGF1Z21lbnRlZCBpbnRvIGFuIGV4aXN0aW5nIG5vdGlmaWNhdGlvbi4mbmJzcDsgU28gd2hh dCB5b3UgYnJpbmcgdXAgaXMgYSB2YWxpZA0KIGNvbmNlcm4uJm5ic3A7Jm5ic3A7IERvIHlvdSBo YXZlIHN1Z2dlc3Rpb25zIG9uIG1ldGhvZHMgdG8gaGFuZGxlIG1vcmUgY29tcGxleCBhdWdtZW50 ZWQgbm90aWZpY2F0aW9ucz8mbmJzcDsgT25lIHBvc3NpYmlsaXR5IGlzIHRvIGhhdmUgYSBsZWFm LWxpc3Qgb2YgYXVnbWVudGluZyBtb2RlbHMuJm5ic3A7IExvb2tpbmcgYXQgdGhlIGRlZmluaXRp b25zIG9mIHRoZXNlIG1vZGVscyB3b3VsZCBhbGxvdyBleHRyYWN0aW9uIG9mIHRoZSBwcmVmaXhl cyB1c2VkLiZuYnNwOyBUaGVyZSBhcmUNCiBtb3JlIGNvbXBsZXggcG9zc2liaWxpdGllcyBoZXJl LCBob3dldmVyIGVhY2ggYWRkcyB0byB0aGUgcGF5bG9hZC4mbmJzcDsgJm5ic3A7KEl0IGlzIG5v dCBhbiBhY2NpZGVudCB0aGF0IElQRklYIGhhcyB0ZW1wbGF0ZSByZWNvcmRzLik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FcmljDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gUWluIFd1ICZsdDs8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3 ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBGZWJydWFyeSAxMywgMjAyMCA1OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBNYWhlc2gg SmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20i Pm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDs7IEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8 YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbmV0Y29uZl0gV0dMQyBvbiBk cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzPyAoV2FzIFJlOiBDb25maWd1 cmVkIHJlY2VpdmVyIGNhcGFiaWxpdHkgZXhjaGFuZ2UpPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTiI+RXJpYzombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+V2h5IHN0cnVjdHVyZSBtZXNzYWdlIHNob3VsZCB0aWUg dG8gYSBzaW5nbGUgWUFORyBkYXRhIG1vZHVsZSB3aXRoIOKAnHlhbmctbW9kdWxl4oCdIHBhcmFt ZXRlciwgaXMgdGhpcyB0b28gcmVzdHJpY3RpdmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj4tUWluPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZiI+IG5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZiI+TWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDIwPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTwvc3Bhbj7mnIg8c3BhbiBs YW5nPSJFTi1VUyI+Mjg8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDg6MTk8YnI+DQo8 L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBj aXNjby5jb20iPmV2b2l0QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxhIGhyZWY9 Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj4NCm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPC9z cGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFtuZXRjb25mXSBXR0xDIG9uIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t bWVzc2FnZXM/IChXYXMgUmU6IENvbmZpZ3VyZWQgcmVjZWl2ZXIgY2FwYWJpbGl0eSBleGNoYW5n ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgRXJpYyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGUtbWFpbCB0cmlnZ2Vy cyB0d28gcmVzcG9uc2VzLiBMZXQgdXMgZGVhbCB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tbWVzc2FnZXMgaGVyZSwgYW5kIEkgd2lsbCBicmluZyB1cCBjb21tZW50cy9xdWVz dGlvbnMgcmVsYXRlZCB0byBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgaW4gdGhlIG90 aGVyIHRocmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPllvdSBoYXZlIGluZGljYXRlZCBhIGRlc2lyZSB0aGF0IHJlY2VpdmVyIGNhcGFiaWxpdGll cyBzaG91bGQgYmUgZG9jdW1lbnRlZCBieSB0aGUgdHJhbnNwb3J0IHNwZWNpZmljIGRyYWZ0LCBl LmcuIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiwgYW5kIG5vdCB0aGlzIGRyYWZ0LiBB cyBzdWNoIHlvdSBiZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VG8gdGhlIFdHLCB0aGUgYXV0aG9y cyBoYXZlIGluZGljYXRlZCBhIGRlc2lyZSB0byB3cmFwIHVwIHRoaXMgZHJhZnQsIGFuZCB3b3Vs ZCBsaWtlIHVzLCB0aGUgY2hhaXJzLCB0byBpc3N1ZSBhIFdHTEMgb24gaXQuIEJlZm9yZSB3ZSBk byB0aGF0LCB3ZSB3YW50ZWQgdG8gYXNrIGlmIHRoZSBXRyBiZWxpZXZlcyB0aGF0IHRoZSBkb2N1 bWVudCBpcyByZWFkeSwgYW5kIHRoYXQgdGhlcmUNCiBhcmUgbm8gbW9yZSBpc3N1ZXMgdGhhdCBu ZWVkIHRvIGRpc2N1c3NlZC9hZGRyZXNzZWQgYnkgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNh dGlvbi1tZXNzYWdlcyBkb2N1bWVudCBhdCB0aGlzIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGVlcnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NYWhlc2ggYW5kIEtlbnQgKGFzIGNvLWNoYWly cykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBKYW4gMTUsIDIwMjAsIGF0IDEyOjIzIFBNLCBFcmljIFZvaXQgKGV2b2l0 KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5IaSBNYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RHVyaW5nIHRoZSBJRVRGIDEwNiBzZXNz aW9uLCB0aGVyZSB3YXMgZGlzY3Vzc2lvbiBvbiBob3cgYm90aCBhIHB1Ymxpc2hlciBtaWdodCBr bm93IGlmIHRoZXJlIGlzIHJlY2VpdmVyIHN1cHBvcnQgZm9yPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMvP2lu Y2x1ZGVfdGV4dD0xIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlczwvc3Bhbj48L2E+Lg0KICZuYnNwO1NlY3Rpb24gNiBo aWdobGlnaHRzIHNldmVyYWwgb2YgdGhlIGNvbnNpZGVyYXRpb25zLiZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyZuYnNwOzwvc3Bhbj5SZWxldmFudCBhcmUg dGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4oYSkgUmVtb3RlIGRldmljZSBjYXBhYmlsaXR5 IGRpc2NvdmVyeSBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBQdWJsaXNoZXIgbmVlZHMg dG8gYmUgZW5oYW5jZWQgdG8ga25vdyBpZiB0aGUgZmFyIGVuZCBjYW4gaW50ZXJwcmV0IG5vdGlm aWNhdGlvbiBtZXNzYWdlcw0KIHR5cGUgYmV5b25kIFJGQy01Mjc3LCBTZWN0aW9uIDQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+KGIpIFRoaXMgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgcXVlc3Rpb24gaXMgcmVsZXZh bnQgZm9yIGJvdGggY29uZmlndXJlZCBzdWJzY3JpcHRpb24gcmVjZWl2ZXJzIGFuZCBkeW5hbWlj IHN1YnNjcmliZXJzLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4oYykgVGhlIGNhcGFiaWxpdHkgZGlzY292ZXJ5IHF1 ZXN0aW9uIGNhbiBiZSBnZW5lcmFsaXplZCBiZXlvbmQgc3Vic2NyaXB0aW9ucywgYXMgdGhlcmUg YXJlIG1hbnkgcmVhc29ucyB0byBrbm93IHRoZSBhdmFpbGFibGUgY2FwYWJpbGl0aWVzIG9mIHRo ZSBmYXIgZW5kLiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4oZCkgQ2FwYWJpbGl0eSBkaXNjb3ZlcnkgYWR2 ZXJ0aXNlbWVudCBoYXMgdHJhZGl0aW9uYWxseSBiZWVuIGRpc2N1c3NlZCB3aXRoaW4gdHJhbnNw b3J0IGRvY3VtZW50cyAoZS5nLiBSRkMtNjI0MSBTZWN0aW9uIDguMSkuJm5ic3A7ICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJhc2Vk IG9uIChhKS0oZCksIGNvbWluZyB1cCB3aXRoIGEgdHJhbnNwb3J0IGluZGVwZW5kZW50IHBvaW50 LXNvbHV0aW9uIHdpdGhpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLz9pbmNsdWRlX3RleHQ9MSI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPmRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVz c2FnZXM8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4qanVzdCoNCiB0byBkaXNjb3ZlciB0aGlzIHNpbmdsZSBlbGVtZW50IG9mIGNsaWVu dCBmdW5jdGlvbmFsaXR5IHNlZW1zIG92ZXJraWxsL2hlYXZ5d2VpZ2h0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pkkgd2FzIGZpbmUgd2l0aCBsZXR0aW5nIHRoaXMgcmVtb3RlIGNhcGFiaWxpdGllcyBkaXNjb3Zl cnkgcXVlc3Rpb24gc2l0IGZvciBhIHdoaWxlLiZuYnNwOyZuYnNwOyBIb3dldmVyPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDEiPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWY8 L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5zaG93cw0KIHRoYXQgd2Ugbm93IG11c3QgYWRkcmVzcyB0aGlzIHF1ZXN0aW9uLiZuYnNwOyBT cGVjaWZpY2FsbHkgc2hvdWxkIHRoZSBkaWFncmFtIHNlY3Rpb24gMS40LjEgc2hvdyB0aGlzIGNh cGFiaWxpdHkgZXhjaGFuZ2U/Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IHR1cm5zIG91dCB0aGF0IGluZGVwZW5k ZW50IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIHRoZXJlIHNl dmVyYWwgcXVlc3Rpb25zIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZiB3aGljaCBu ZWVkIHRvIGJlIGFuc3dlcmVkDQogcHJpb3IgdG8gdGhlIHNlY3Rpb24gMS40LjEgYXJyb3c6ICZx dW90O1NlbmQgSFRUUFMgUE9TVCBtZXNzYWdlIHdpdGggWUFORyBkZWZpbmVkIG5vdGlmaWNhdGlv biAjMSZxdW90OyBhbnl3YXkuICZuYnNwO1RoZXNlIHF1ZXN0aW9ucyBhcmU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICgxKSBEb2VzIHRoZSB0YXJnZXRlZCBIVFRQUyBy ZWNlaXZlciBzdXBwb3J0IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgKDIpIENhbiB0aGUgdGFyZ2V0ZWQgSFRUUEAgcmVjZWl2 ZXIgYWNjZXB0IGEgbmV3IHN1YnNjcmlwdGlvbiBhcyBkZXNjcmliZWQgaW4gYSAmbHQ7c3Vic2Ny aXB0aW9uLXN0YXJ0ZWQmZ3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9ubHkg aWYgdGhlc2UgcXVlc3Rpb25zIGFyZSAmcXVvdDt5ZXMmcXVvdDssIHNob3VsZCB0aGUgJmx0O3N1 YnNjcmlwdGlvbi1zdGFydGVkJmd0OyBiZSByZXNwb25kZWQgdG8gd2l0aCBhbiAmcXVvdDtPSyZx dW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5BZGQgdG8gdGhpcyBhIHRoaXJkIHF1ZXN0aW9uIGRyaXZlbiBm cm9tIChhKS0oZCk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICgzKSBE b2VzIHRoZSByZWNlaXZlciBzdXBwb3J0IHRoZSBtZXNzYWdlIHR5cGUgd2l0aGluICZxdW90O2Ry YWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMmcXVvdDs/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QSBzdHJhd21hbiB3YXkgdG8gaGFuZGxlIHRoZSBhbGwgdGhyZWUgcXVlc3Rpb25zIHdpdGhp biBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYgd291bGQgYmUgdG8gcmVzcG9uZCB0byBh ICZsdDtzdWJzY3JpcHRpb24tc3RhcnRlZCZndDsgbm90aWZpY2F0aW9uIHdpdGggYW4gSFRUUA0K IFN0YXR1cyAyMDIgKEFjY2VwdGVkKSZxdW90OyBhY2tub3dsZWRnZW1lbnQuJm5ic3A7IFRoaXMg MjAyIHdvdWxkIGluY2x1ZGUgYm9keSBlbGVtZW50cyBsaXN0aW5nIHN1cHBvcnRlZCByZWNlaXZl ciByZXNvdXJjZXMuJm5ic3A7IE1heWJlIHNvbWV0aGluZyBZQU5HIGVuY29kZWQgdmlhIGlldGYt eWFuZy1zdHJ1Y3R1cmUtZXh0IGNvbnRhaW5pbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtmb28geG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnht bDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2Fw YWJpbGl0aWVzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Y2FwYWJpbGl0 eSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXJuOmlldGY6 cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzOjEuMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2NhcGFiaWxpdHkmZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZsdDsvY2FwYWJpbGl0aWVzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2ZvbyZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5XaGF0IGRvIHlvdSB0aGluayBvZiB0aGlzIGFwcHJvYWNoPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVyaWM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABAAD4E676Edggeml511mbxchi_-- From nobody Thu Feb 27 13:39:48 2020 Return-Path: <010001708897513a-bf8dd810-429b-48b1-947a-d7cc401aeda5-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 EF8293A0C88 for ; Thu, 27 Feb 2020 13:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 yJ1vGZ7284Cl for ; Thu, 27 Feb 2020 13:39:44 -0800 (PST) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99E23A0C84 for ; Thu, 27 Feb 2020 13:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1582839583; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=G/bMgLGOwdI4+ljhKhXGv2ak5UssWDG7qs8gw4NmcKg=; b=hUyxuW0MrCwm9LUianES9iQaW6ONx/z3ikKN4uoN+/MWBJM2hLBN0KBdKehh8VhH Lnh4bYIm3ApsvBqxpXHGcjVWttUVN6Sv70NZrkQ+jC1Kd+m6qpEcmcPPmgUU/2kmmgN wCI6EoNxQy8zdvWxi2UwF0Um/7bPjO/WmxcHFJFQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <20200225.183823.647044925138390997.id@4668.se> Date: Thu, 27 Feb 2020 21:39:43 +0000 Cc: olof@hagsand.se, "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001708897513a-bf8dd810-429b-48b1-947a-d7cc401aeda5-000000@email.amazonses.com> References: <4bca4ca8-0d9f-d986-4521-5c808a6e8a4d@hagsand.se> <20200224.201727.524298611078512416.id@4668.se> <0100017078d1f020-3514ea16-953a-48d7-85f2-ab358f2553c9-000000@email.amazonses.com> <20200225.183823.647044925138390997.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.02.27-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Question on restconf empty list reply 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, 27 Feb 2020 21:39:46 -0000 Hi Martin, >>> It should be 404, even if the list contains some entries. The = reason >>> for this is that there is no resource for the list itself, only for >>> list entries. See section 3.5 of RFC 8040. >>=20 >> Assuming you mean the first paragraph not explicitly listing = =E2=80=9Clist=E2=80=9D >> and =E2=80=9Cleaf-list=E2=80=9D, that conflicts with Section 4.3, = Paragraph 5. >=20 > Does it? Actually, that paragraph is not quite clear. What is a > "resource representing a YANG list object=E2=80=9D? Right, I read that to mean the =E2=80=98list=E2=80=99 object itself, not = any list-item. I think that this view is supported by the continuation = of that line: If a retrieval request for a data resource representing a YANG leaf-list or list object identifies more than one instance and XML encoding is used in the response, then an error response containing a "400 Bad Request" status-line MUST be returned by the server. =20 How else could something else return =E2=80=9Cmore than one instance=E2=80= =9D and, further, the text specially calls out the known XML encoding = limitation (i.e., that there has to be a single document root), so what = else could could it be? Lastly, the paragraph ends: Note that a non-configuration list is not required to define any = keys. In this case, the retrieval of a single list instance is not = possible. Which points to a case when keys are not (actually, cannot be) provided, = so it seems that this paragraph as a whole regards targeting the = =E2=80=98list=E2=80=99 as a resource when no keys are specified, = regardless if config true or false. Looking at our old restconf-collections draft, the examples in Appendix = C suggest that we intended to enable the =E2=80=98list=E2=80=99 itself = to be a resource. For example (hint: =E2=80=98album=E2=80=99 is a = =E2=80=98list=E2=80=99): GET /restconf/data/example-jukebox:jukebox/ library/artist=3DFoo%20Fighters/album/?limit=3D2 [I feel that there=E2=80=99s a spurious =E2=80=98/=E2=80=98 = before the =E2=80=98?' above, and we really meant "...album?limit=3D2=E2=80= =9D] But, regardless, no *keys* are being specified. Hence the inconsistency. = The immediate relief seems to be to either promote =E2=80=98list=E2=80=99= being a resource, or strike paragraph 5 in Section 4.3. That said, I imagine the long-term plan *is* to promote =E2=80=98list=E2=80= =99 to being a resource (via the restconf-collections draft or, perhaps, = YANG-next), as that enables the collection-specific query params to be = used. Enabling the =E2=80=98list=E2=80=99 to be a resource would also resolve = the issue how to GET a top-level =E2=80=98list=E2=80=99 without = filtering a datastore. For example: module ietf-audit-logs { =E2=80=A6 list audit-log { config false; =E2=80=A6 } } GET = /restconf//ds/ietf-datastores:operational/ietf-audit-logs:audit-log?limit=3D= 25 Versus the less-efficient: GET = /restconf//ds/ietf-datastores:operational?fields=3Dietf-audit-logs:audit-l= og [this example also struggles with if it=E2=80=99s legal to = specify the the collection-specific query params on a datastore = resource] Kent // contributor From nobody Fri Feb 28 14:35:15 2020 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 00A573A1F6F; Fri, 28 Feb 2020 14:34:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: netconf@ietf.org, ibagdona@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292929598.19931.14450774706803415489@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:34:55 -0800 Archived-At: Subject: [netconf] netconf - Requested session has been scheduled for IETF 107 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, 28 Feb 2020 22:35:04 -0000 Dear Mahesh Jethanandani, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netconf Session 1 (2:00 requested) Tuesday, 24 March 2020, Morning Session I 1000-1200 Room Name: Georgia B size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/netconf.ics Request Information: --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: netmod httpbis tcpm idr Technology Overlap: opsarea opsawg Key Participant Conflict: bfd People who must be present: Ignas Bagdonas Kent Watsen Mahesh Jethanandani Robert Wilton Resources Requested: Special Requests: Please place the session in the first half of the week (i.e., M-W). ---------------------------------------------------------